i18n?

[andyjac]

Before our application gets too large should we be thinking about internationalization? I have limited experience implementing this, but have seen TypeScript applications leverage i18next to accomplish this. If folks have previous experience with this, more input would be great!

[dbalatero]

I use i18next on Checkout, and yes I'd recommend doing it now.

If you do it, part of this should be also to add eslint rules that ban raw strings.

[bion]

We had planned to do it after getting an initial release out since the current process is all english spreadsheets. Sounds like doing it earlier could avoid some pain down the line though?

[andyjac]

@dbalatero yeah, we use it at Outreach as well and +1 to having lint rules that ban string literals.

Outreach doesn't have support for any languages other than english, but they put the pieces in place early such that adding a second language would just mean a new json file with the right string values.

[coderbyheart]

I really like the preface of https://projectfluent.org/

Software localization has been dominated by an outdated paradigm: translations that map one-to-one to the English copy. The grammar of the source language imposes limits on the expressiveness of the translation.

We created Fluent to change this paradigm. Translators should be able to use the entire expressive power of their language without asking developers for permission. In Fluent, translations are asymmetric. A simple string in English can map to a complex multi-variant translation in another language.

Fluent makes it possible to cater to the grammar and style of many languages, independently of the source language. It happens in isolation; the fact that one language benefits from more advanced logic doesn’t require any other localization to apply it. Each localization is in control of how complex the translation becomes.

JavaScript implementation: https://github.com/projectfluent/fluent.js