I’ve been working with Cristina from International Planned Parenthood Foundation(IPPF), and one of the topics that keeps coming up is managing translations. They are currently running a 3.2 version which we are in the process of updating.
Back when they first started, OpenEMR’s translations were in much worse shape than they are today. As an example SOAP was translated into Spanish as jabón (a substance with which one would wash) instead of the appropriate acronym. As a result IPPF has been managing the translation on their own instead of using the “community” translations. We reviewed the current OpenEMR google doc, and it’s clear that the status is much better today than when IPPF first started.
I’m starting this thread in the hopes of figuring out a way to leverage the efforts of both the “at-large” and “IPPF” translators.
An interesting first exercise would be to figure out where IPPF’s translations differ from the community translations. How best to manage an “conflicts” between entries is a problem as well.
keep up the spirit and continue. Sometimes it is best to change translations during usage. You find a terrible wrong translation and you go directly to the Google translation spreadsheet to make a correction. Importing the translation spreadsheet is easy. This can be done after a complete session of changes. If you have the time and resources, it is best to make the changes using the Spanish column but being alert for the 5000 fields in the spreadsheet is a rather visual and brain straining effort.
Also, I remember there are some translations specific for pregnancy and contraception etc, there you might find translations that are eye openers for the other translators.
Recommend leveraging the solution that was created to deal with following issue:
How to allow a user to use their own translations and the most current official translation set at the same time?
This was done in OpenEMR 4.0.0 where a table called lang_custom was added. Everything that is done in the Language Editor at Administration->Other-> with translations, constants and even new languages are added to the lang_custom table. This then allows a user to do a import of the official translation set (which replaces all the lang_* tables except for lang_custom) and then they can magically bring back their customized translations etc. from the lang_custom table using the “Manage Translations”->“Synchronize"in the Language Editor. If you understand how the lang_custom stores the information (it’s very simple), then easy to use it for many other things (for example, some use it for their locales; ie. they use a Language Editor” to create their lang_custom table and then bring it into other instances along with the official translation set).
In your case, could do following:
Upgrade OpenEMR.
Throw all of IPPF’s current translations into a lang_custom table(via a quick hack/script).
Import most recent openemr official translation set.
Click “Manage Translations”->“Synchronize” in the Language Editor.
If wanted to efficiently find where the translations differ then a couple well placed error_log() calls during step 4 should suffice. Ideally, then the IPPF translators would then contribute these changes and future changes directly to the google docs spreadsheet, which we’d be glad to give them access to.
Good points Rod,
The basic issue is that IPPF has some translations that are “better” (or fill in missing constants) than the community translations. However, they also have translations which are just “different” (specific to their preferences/workflow). (client vs. patient, encounter vs. visit, etc…) (restating Rod’s Level 2)
Without understanding the language(s) it will be difficult to know the difference. We can kind of tell based on whether IPPF has created “English to English” entries for a given constant.
Brady, it looks like there’s significant existing functionality that we can leverage. Thanks for pointing it out.
Hi,
Probably not ideal to muck up the official translation doc with a bunch of customized languages, which also end up being options on the login screen. I’m confident they’ll find an adequate solution using the lang_custom table (if want robust translations management that requires 3 independent layers 1) could create a lang_custom2 table or 2) use a custom mechanism that builds lang_custom from two separate lists).
-brady OpenEMR
Brady,
If I remember correctly you have some sort of tool where you can audit/review changes to translations submitted through the google doc spreadsheet. If I’m not delusional about that, can you share details?
Hi Kevin,
I use two mechanisms to monitor the translations:
The google doc itself has Tools->Notification Rules:
I have rule to send a daily digest on all changes and a rule to send a notificaiton right away if anybody modifies the stuff that should not be modified. Note I don’t look at the daily diff unless the email summary is suspicious or the mechanism below shows an issue.
I monitor the github repo for the translations: http://github.com/openemr/translations_development_openemr/commits/master
Note that a commit only happens if changes have happened in the spreadsheet and can quickly see what languages were modified in the commit. Also, if there is a Fail, that means something critical in the spreadsheet has been changed.
Pretty much at a point where I can quickly scan and integrate both the diff email (and not the actual doc diff which takes too long) and the github commit for issues; about once a month an issue arises or something is suspicious which requires further analysis or fixing.
The overriding goal of this project and scripts were to be robust (ie. avoid losing or breaking constants/translations, which is what happened in OpenEMR 3.0 ).
Recommend reading through the README in detail which should explain how it works. To specifically address your question above, if a constant is not surrounded within an xl() type function then it will not be collected in the collectConstants.pl script and needs to be manually added to the manuallyAddedConstants.txt file before running collectConstants.pl script. Also, the ID’s for the constants are not permanent; they change whenever new constants are added. Best way to add stuff for customized layout/list/LBF is to add them within OpenEMR (then can use the lang_custom mechanism described above to keep them permanent and reproduce them whilst also using most updated official translation set).
SQL Query to populate lang_custom from existing definitions.
insert into lang_custom(constant_name,definition,lang_code,lang_description) select lang_constants.constant_name, lang_definitions.definition, lang_languages.lang_code, lang_languages.lang_description from lang_languages,lang_constants, lang_definitions
WHERE lang_constants.cons_id=lang_definitions.cons_id AND lang_definitions.lang_id=lang_languages.lang_id;