i18n PoC

[Dschoordsch]

As we might try to do a PoC soon here are some things to consider.

Library

There are 2 main libraries out there react-i18next and react-intl. The former is relative easy to use with adding only little clutter^1 while the latter seems to require quite a bit more boilerplate for every string^2. Having also worked with react-i18next and not ran into major issues, we should use this library going forward. Supposedly i18next also works on server side, which would allow us to localize the summaries ^3

Translatable texts

There are multiple areas where we use text which would need to be translated 1) Texts used directly in the app This would be the easiest to translate and apart from the library and translations only requires some small layout tweaks and probably a UI to choose the language. This should also be the first step when trying a PoC 2) Meeting summary Once a user can choose a language, it should be stored on the User table and also used for summaries. This could be a stretch goal. 3) Error messages Error messages are strings on the server side. These should not be translated on the server side, but since we have a limited number of fixed error messages we show, we can translate those on client side. 4) Retro and Poker templates This would require changing the data structure so that we can query templates for a certain language and probably fall back to English if a template is not available as translation. This can be worked around by the users themselves by creating their own templates 5) Marketing page and marketing emails This is out of scope apart maybe of marking the users preferred language in HubSpot

Acceptance criteria for PoC

• [ ] language is detected by browser locale and a UI element allows switching language
• [ ] language setting is stored in User table
• [ ] strings in app are translated

Acceptance criteria production

• [ ] PoC
• [ ] estimation of long term effects on development effort taking into consideration the number of translations and members speaking those languages

[JimmyLv]

I also have a strong interest in i18n, which is the basics of Chinese/Spanish version of Parabol. react-i18next has very good correlative tools, like Static extraction tools. Manual is definitely the least efficient way for this extraction translation thing. And i18next-scanner, i18next-parser and babel- plugin-i18next-extract can read through code files to automatically find and export translation keys. ^1

There're already a lot of translatable texts used directly in the app, so this part can be reduced as much as possible.

[Dschoordsch]

@JimmyLv I think that's a good idea. Let's see how good it works with nested elements, like links in text. We might need to manually work on those after that, but it still reduces the overall work.

[JimmyLv]

cool~ I'll create an additional issue to track the effect of i18next-scanner to see how much work it can automate to reduce the workload. Let's see what the remaining nested elements include and how much work it takes.

[github-actions[bot]]

Stale issue

[jordanh]

Eines tages