Production internationalization

[Qrtn]

Description

In order for our app to actually make it into production, the text in the app needs to support being translated.

We're currently using react-i18next, but there is a light-weight, easier to use solution available called LinguiJS. You can check out the documentation here: https://lingui.js.org/

We need to switch to LinguIJS. At the same time, the text in our app needs to be standardized (as much as possible) to what text was already on the old Falling Fruit website and has translations.

Learning objectives

• PIcking up external libraries quickly
• Understanding how to internationalize an app
• Nuances, like pluralization, etc.
• Standard file formats that carry translations
• Learning Phrase app, the platform on which translators collaborate with developers

Todo

• Understand how to use LinguiJS
• Understand the current approach for internationalization
  • https://github.com/hack4impact-uiuc/falling-fruit/pull/108
• Replace current react-i18next calls with LinguiJS
• Replace things like detecting locale, etc. with LinguiJS-specific plugin
• Standardize text in the app with translations that are already available on Phrase app

Useful links

• https://lingui.js.org/
• https://lingui.js.org/tutorials/react.html
• https://phrase.com/blog/posts/localizing-javascript-react-apps-with-linguijs/
• Access to Phrase app workspace (need to ask Ethan to give to appropriate developer once assigned)

[ezwelty]

@Qrtn Looking over these tools (linguijs and react-i18next), I notice that the native locale lives on in the source code, rather than loaded from a catalog like all the other locales. The way I am used to translations in source is more like:

• translate("map") (rather than <translate id="map">Map</translate>)
• translate("map", count={count}) (rather than <plural id="map" value={count} one="Map" other="Maps" />)

I see the benefit to developers of being able to read and write English in the source and automatically extract and update the translation catalogs. Especially when it comes to translation messages with HTML markup. But then it seems important to me to always set an explicit id rather than rely on using the source code English as an implicit id? Otherwise, couldn't the English diverge from what appears in the source code?

It would be wise to test out a developer-translator workflow, using linguijs and Phrase, before we get too deep updating the code. I can help coordinate, at least on the Phrase side. Note that Phrase has a CLI for syncing translation catalogs (https://phrase.com/cli). Phrase supports PO files and ICU Message format.

[Qrtn]

Ethan, thanks for pointing this out. We can choose to always set an explicit id, especially since Phrase already contains ids. We also don't necessarily need to include a default English translation in the code.