Bahmni: Changes in locale_en.json, should I update Transifex as well?

Hi guys!

As for BAH-311: Fill L10n gaps in Bahmni Apps I have added translation keys into locale_en.json. (See the PR#110 for more details).




I am not sure what is the process to folllow when adding new translation keys in Bahmni.

Should I add the keys+translation in every locale, ie, is Bahmni maintained in multiple language?

And are the translations maintained in the code (in openmrs-module-bahmniapps) or in Transifex?

(subject for PAT call tmr?)



@mksrom you need to put the English translations in the locale_en.json file in the code. Any other languages would be translated in Transifex. (As a dev you are welcome to do the translations into languages you’re proficient in, but you shouldn’t go off and use Google Translate for languages you’re not.)

I believe this is documented on the wiki here, but maybe you can suggest how to phrase this more clearly?

FYI, this file is where you see locale_en.json defined as the source file:

OK thanks.

Does this mean that Transifex automatically pulls locale_en.json so its knows that there is new keys to translate? (and I don’t need to worry about Transifex at all)

Not exactly related to this question, one thing I don’t understand is the correct process to use a given translation for an implementation.

From the doc article on how use i18n in Bahmni (Product Internationalization), at point 2, it says that one should download the file version appropriate for the language needed.

So, if you want to add support for the Russian language, you just need to add a file named locale_ru.json in all modules.

But doing so will then force an implementation to always fork Bahmni Apps right?

Or maybe should the transifex pull -l xx command (where xx is the locale) be run each time I set up a new server? So the locale_xx.json files are never saved in the code but fetched from Transifex always.


Back at these questions. @angshuonline and @darius what is the right process to follow here?

From the PAT call last week, @binduak informed me that yes, Transifex is automatically pulling the locale_en.json files to be used as the reference for message keys.

This means that if someone needs to add new keys, he/her must add them in the appropriate locale_en.json file and only the ‘en’ ones.

I think this also means that only ‘en’ locale should be maintained in the source code. The other locales being maintained in Transifex, we could have some conflicts between the files in GitHub and the ones in Transifex.

@angshuonline @darius Do you agree that we should remove the ‘locale_es’, ‘fr’ and ‘pt_BR’ JSON files from the GitHub repo? (especially knowing that in fact Bahmni does not yet handle Internationalization at all but only Localization -and not fully)

I think it is necessary to define and document how implementations can localize Bahmni, ie use their own locale files (likely already translated/maintained in Transifex), without having to maintain a fork of Bahmni Apps to hold the files.

Transifex does not let us maintain versions of the locale files (@binduak do you confirm this?) so it could be risky to pull the files from Transifex each time one starts a new server. That’s why each implementation still has to save the translation files on a repo somewhere (and occasionally pull/sync from Transifex to get updates).

So we could as well recommend to use the Bahmni Config repository! (since implementations will always fork it anyway)

@angshuonline informed me that we can have as many locale files as we want in Bahmni Config as soon as they are suffixed by ‘xx_json’. For instance for ‘fr’ locale, what about having those 2 files:

tree ~/repos/bahmni-config/openmrs/
├── i18n
    │   ├── registration
    │   │   ├── config_locale_fr.json
    │   │   ├── bahmniapps_locale_fr.json

Yes @mksrom, Transifex doesn’t maintain versions of locale files. If we remove any key from locale_en.json then the same will be deleted from the Transifex source file. So one should be careful while moving or deleting the keys from locale_en.json.

On this, Can you list what could be the possible issues that you see

Well if we can not ensure that a given version of the Transifex JSON file is downloaded, then it can always happen that suddenly a string in the app is not translated anymore, or incorrectly translated. (This is similar to depend on SNAPSHOTs of OMOD rather than release artifacts, things can be suddenly broken).

For instance if someone is accidentally removing a key from the locale_en.json file, then the change gets propagated in Transifex, in every locale: pulling the files will result in missing a translation on screen.

Or if someone is incorrectly changing a ‘fr’ translation value in Transifex: pulling the files will bring the faulty value.

In the case of an implementer who wants to start a new demo server, confident that everything will be fine (since he did it the day before already), will pull the translations and suddenly have a string not translated/incorrectly translated in there.

And that is for demo servers but could happen for a production server that would have to urgently be rebuilt, in a disastrous scenario, and the Transifex files pulled again.

So that’s why I suggest that we suggest to save the localization files for each implementation in the ad-hoc Bahmni Config repo.

1 Like