OpenLMIS 2.0 - Contains translations for every language into which OpenLMIS 1 and 2.x has been localized. This project may be thought of as the 'master' project from which other projects (used for individual country deployments) draw the majority of their translations. Because our demo systems are not country-specific and therefore lack a need for particular customization, they typically retrieve their translations directly from this project.
OpenLMIS Global - A project that only contains French translations. As of 10/2016, it hasn't been updated for nearly a year and a half and has thus been archived.
OpenLMIS Mozambique- Used by the CHAI team for their ESMS project.
OpenLMIS-SELV - Contains all translations for Mozambique’s OpenLMIS implementation.
OpenLMIS-SIIL - Contains all translations for Benin’s OpenLMIS implementation. Note that historical translation files created prior to the adoption of Transifex reside in /Dropbox (VillageReach)/OpenLMIS Projects/SELV/Archived_SELV_Translation_Files.
testProject - A project currently configure for use with Transifex Live (discussed in the Context for Translators section below).
Historical Translation Files - SELV - Translation files used for SELV before the adoption of Transifex may be found at /Dropbox (VillageReach)/OpenLMIS Projects/SELV/Archived_SELV_Translation_Files.
By design, OpenLMIS’ various implementations share a lot in common. This includes webpages and the text that appears within them. Allowing translations to be shared amongst projects is thus important – and fundamentally congruent with OpenLMIS’ vision of shared benefit.
Transifex doesn’t offer a way of directly linking projects such that children inherit from parents and translations defined within the former don’t have to be duplicated within the later. It does, however, offer something called Translation Memory. This is a feature normally reserved for customers paying thousands of dollars a year. Because Transifex supports VillageReach’s mission, however, they’ve generously agreed to freely activate it for us. Transifex has already been hosting OpenLMIS’ projects free of charge for years. They deserve extreme gratitude for allowing us use of this advanced feature as well.
Translation Memory isn’t something we previously had access to. It’s anticipated that, at the inception of new projects, it will allow us to reuse the translations defined in existing ones.
Translation Reuse II – Lessons Learned
With neither the benefit of linked projects nor Translation Memory, our previous guidance to translators was to use tools like Beyond Compare and Text Mechanic to manually manage the reuse of translations among projects. Transifex allows translation key-value pairs to be easily uploaded and downloaded to/from projects. The idea for reusing translations in a source project within a preexisting destination project was thus to:
1. Download existing translations from the two projects.
2. Use Text Mechanic to alphabetically sort the two files, thereby making their content match line-by-line as closely as possible.
3. Use Beyond Compare to compare the resultant files, selectively overriding lines within the destination file with entries in the source file.
4. Upload the modified destination file into the destination project.
A variety of complications made this approach overly cumbersome for translators. The biggest problem is that, surprisingly, the data downloaded from a Transifex project doesn’t exactly mirror that content originally uploaded. Downloads are delivered as ISO-8859 files containing escaped characters as defined in the Java .properties file specification. These escape characters are treated as non-escaped content, however, when encountered within a file uploaded to Transifex. This incongruence means that downloading a file from Transifex and immediately uploading the exact same file back into Transifex will introduce erroneous escape character into your translations. The problem compounds every time you perform such an operation.
Other problems with manually managing files include:
* When uploading a file, it's easy to use the wrong encoding and thus to get garbled results within Transifex. Even worse is the fact that it’s easy to overlook the problem. This seems to have happened to SELV's Portuguese and to have gone unnoticed for a long time within our production system.
* Translations may optionally span multiple lines. In such cases, they’ll erroneously be broken apart when sorting the properties file.
* Translation files aren’t always consistent in terms of whitespace. Most entries are of the form "myKey = myValue," though some appear within files as "myKey=myValue" (sans whitespace). Such discrepancies degrade the usefulness of alphabetically sorting files, and inversely increase the difficulty of comparing them.
For these reasons, the manual approach to translation-management is likely to involve lots of developer time. As a developer responsible for helping a translation effort, I found it necessary to write scripts to sort files, strip whitespace, remove escape-characters, and merge translation files with one another. Even with the scripts, it was easy to make mistakes and difficult to catch them.
Our shift toward the use of Translation Memory is intended to return the art of translation exclusively back to translators.
See the Style Guide for instructions for using message keys and transifex.
Translations made within Transifex do automatically propagate to OpenLMIS as it is part of the build process. If translators use certain chacters or use the "enter" button, it will break the build. Please be mindful of how you conduct translations to decrease the risk of breaking things downstream. At this time we do not have a automated way to fix issues when input directly into Transifex.
You can either copy the whole source text OR click on the special character in the source text (as see below).