dcouot wrote on Monday, May 07, 2012:
Hi everyone,
Over the last few month, we have been working on the Spanish(Spain) Translation. As we progress to the end of the work, we would like to propose a change in the way translations are managed.
First the translation environment.
So far, the translation is done in a GoogleDocs document which gets significantly bigger every time a new language is added and is very cumbersome to manage for translation purpose. Once translated, Brady take over and convert such file with a perl script to load into openEMR compliant format.
We have been using a service called Transifex (www.transifex.net) for various other Open Source Project. The service is free for Open Source solutions such as OpenEMR and with subscription for Commercial solutions.
It is an online user friendly collaborative translation environment. You can read more on their pages. It allows for the creation of several language files in a lot of file formats to be later reinserted in the original project. It comes with user management (Project leader, team leaders for translations, translators and validators….)
Basically it works in a two column environment with a master (reference language) and a translation language. If helpful, additional languages can be added to the reference column to ease the translator’s effort (this allows to see how certain concepts are being translated in a different language other than English in this case).
Additional translation requests can be added to the master file
From a workload perspective for Brady, since we have been playing around the Community Edition of Transifex in one of our servers for several months now to translate OpenEMR, we have most of the languages reformatted in a UTF-8 compliant format that can be loaded into Transifex. We also have a small VB app that converts the translation file back into a SQL scripts to upgrade the OpenEMR package.
For Brady, I guess it would require opening an account for the project, fill in the various required info, and rewrite his perl scripts to use one of the output format. We are currently using the Joomla ini format for simplicity but the list is extensive.
Now the translation organization standpoint.
To understand the following point, let me clarify that I am not a medical expert. I work on the system side.
I think that the translation file should be split in sub files reflecting categories to be translated: i.e. system related subjects (database, communication setup), patient demographics, medications, treatments and so on…
The reason is that it would make it easier to find more specialized resources to translate correctly each of the sections (doctors, pharmacists, techies,…) instead of facing a full 5500+ lines and searching for what they can translate. Additionally, the segmentation would help when expanding / updating / validating the translation by being able to direct the translation request to the right resource.
Well, that’s all for now. Waiting for your input.
Thanks for reading my prose.
Dominique