Police Oversight form: Identify translation strategy

[amenity]

Requirements:

• For the initial MVP release, the form must be available in both English and Spanish
• In the future, the form will also need to be available in Vietnamese and Arabic
• The language of the confirmation email should correspond to the language that the form was submitted in, see Police Oversight form: Identify Spanish submissions in backend API #1037

For now, translations can be hardcoded/edited directly in yaml, json, etc.

[sergiogcx]

This is one library I have been looking at:

https://www.i18next.com/overview/configuration-options
https://react.i18next.com/
https://github.com/i18next/react-i18next

It supports:

• Json Configuration
• Interpolation
• Plurals
• Formatting
• etc.

There are others we can use or implement our own ...

[sergiogcx]

the json files can be stored and edited on github (as we have talked about during the sprint review on Jan 24)

[LauraTrujillo]

Translated content:

• Form and email
• Website content

[amenity]

@easherma is going to move forward with this looking at Babel.js and the Janis strategy: Is this something we can implement in a week? If so, let's create issues and get on it.

[easherma]

i18next/react-i18next#303

Comparison between react-i18next and react-intl. The latter is being used by Janis. I agree with @sergiogcx at first blush i18next seems more useful overall, but it also seems more geared for server side rendering.

Also related and cool-looking:
https://locize.com/

[sergiogcx]

I'm fine with react-intl, I liked react-i18next but it seemed difficult to work with especially given our multi-repo architecture.

I was looking at https://lingui.js.org/tutorials/react.html which seems a lot easier to implement, but did not have the time to play with it yet.

But I am totally fine with any framework of your choosing @easherma

[easherma]

@sergiogcx has this branch up: cityofaustin/officer-complaint-form#28
this is the POF for our contingency if we run out of time before launch to do translation the 'right' way

[easherma]

I am leaning towards react-i18next. At first glance, it is more intuitive to me. I also like that it is more framework-agnostic. Either way I'm trying to get a sense of how much re-writing of our code and us-forms systems either would require. I think I'll just try both in seperate branches.

@sergiogcx at first glance did anything stick out as easier to you in particular about lingui.js vs react-intl? They seemed very similar.

[easherma]

Also relevant threads:

usds/us-forms-system#170 <--- dependency of our forms
rjsf-team/react-jsonschema-form#739 <-- dependency of us-forms-system

[sergiogcx]

@easherma Lingui has a CLI that helps manage locales, not sure if react-intl does too. Anyhow, I think you would know which to choose best. Not married to the idea of trying any other not already mentioned,

[easherma]

This is tricky mainly because:

• us-forms system has some english 'embedded' in it's components
• the library it is based off of uses JSON to define schemas, so there are lots of nested titles and descriptions.

[easherma]

Outstanding question: Where is the 'best' place for this, architecture wise?

Option 1:
• start with us-forms, add dependency library,
• wrap components
• test
• translate buttons, UI stuff. probably going to run into problems with us-forms sytem + then the schema needs to be translated/translatable (there are github issues that address this)

Results if it works:
• we'd have a fork of a forms system that supports internationalization! (yay)
• we'll have tagged files ready to be updated by content to manage translations through whatever 'separate' process we set
• this may or may not line up with how janis works, and if we decide to refactor forms in a totally different way we'll need to include/consider internationalization along with it

Option 2:
• we search through the generated app for known string matches (this isn't super sustainable but is surprisingly common)
• we map translations to these strings as keys
• incorporate this process into the build pipeline

Results
• we'd have a pretty flexible process we could re-use in just about any other situation in a pinch ( yay python)
• we'd have a process ready for tagging content to be translated and have a better idea of how to avoid this mess in the future

[easherma]

We're going with @sergiogcx's branch to translate the forms after build for now.