From what I've seen, strings are not getting translated in pure React pages coming from plugins. Translations work as long they are being done on the backend, but if they are done on the frontend, they end up not translated.
When updated translations are pulled in Foreman, a po_to_json rake task is called which converts the *.po files into javascript files under app/assets/javascripts/locale/$lang/app.js. These files usually look like this
var locales = locales || {}
locales['it'] = {
"domain": "app",
"locale_data": {
"Failed to fetch: ": ["Recupero fallito:"],
...
}
}These files are then loaded from base layout as a <script> and evaluated. Once react components get mounted, a window singleton of Jed is created with the translation data from the locales variable.
The impact of this is that only translations of strings extracted from Foreman are available.
Nothing like this is done for plugins. It seems we need to:
- generate these files for every plugin
- load each of the files generated in the previous step
- either somehow merge all objects of Foreman and per-plugin translations into a single object or feed them to Jed as separate domains
The po_to_json rake task comes from webhippie/gettext_i18n_rails_js, which in turn uses webhippie/po_to_json (ie. third party projects), both of these assume there is only a single domain. The javascript file they generate (see above), build a flat locales[$LANG] = $TRANSLATIONS structure. We have to somehow aggregate the loaded files, otherwise they would just overwrite each other.
Merging all the translations into a single object would probably be easier, but then we could run into situations where if a single string has multiple different translations from different sources, one of the translations would just win.
Feeding the translations to Jed as separate domains would require code changes all over the place to make sure translations are done within the right domain.