Under the Hood: Localizations with POEditor

At the Concord Consortium our goal is to increase the impact of our work so that more students in more places can engage in STEM inquiry. One way to do that is to translate our free STEM models and activities into different languages, an adaptation that’s called localization.

Years ago, I helped localize Fathom, our desktop application for data analysis and statistics. At that time the localization process involved emailing files of English strings to our translation partners and receiving files of translated strings in return, which were then manually merged back into the code base. As development proceeded, new English strings were added and existing strings were changed, which meant additional email exchanges. It was a time-consuming and error-prone process. Invariably, some localizations would become outdated. Managing the process was a significant amount of work.

Since then, a number of online translation services have significantly simplified the localization process, allowing users to import English strings files, manage the process online, and download the translated strings files to incorporate back into the code base. We chose POEditor for its features and UI, as well as its generous support of open-source software like those we develop.

With POEditor, each collection of strings is represented by a project. Translators are added to the project and POEditor manages email communications with translators and developers. The site tracks the translation progress and notifies translators when new strings are added or existing strings are changed.

To make use of POEditor, we started with three Concord Consortium projects—SageModeler, CODAP (Common Online Data Analysis Platform), and the Cloud File Manager. First, we converted each project’s strings file from CoffeeScript/JavaScript to JSON. Then, we wrote a few short scripts to simplify the process of automating the upload/download of strings files using POEditor’s web APIs. At this point, we ran into an issue with POEditor’s handling of Unicode escape characters. We use Unicode escapes to represent Unicode characters in ASCII source code files, e.g., \u2212, the Unicode MINUS SIGN. On upload, POEditor automatically converts these to the Unicode character. Since JSON files and JavaScript both support Unicode characters, this generally isn’t a problem, but there are some cases where the Unicode escape character is preferable in source code.

Furthermore, sometimes the correct translation for a particular string is the empty string—when that string isn’t needed for a specific localization, for example.

If a translated string is left blank, POEditor assumes that it just hasn’t been translated yet, and flags it as incomplete. Thus, we need a way to represent a string that is effectively empty, but not actually empty, for which the Unicode character \u2ØØb, the ZERO WIDTH SPACE, is ideally suited. Since POEditor doesn’t maintain Unicode escapes, we adopted the convention that [u2ØØb] represents a Unicode escape character, and then modified our scripts to convert them to their canonical form on download. The resulting bash scripts use the curl utility to upload/ download the strings files and the sed utility to convert the Unicode escapes.

In our software development, developers modify the English strings file. Whenever the file is changed, a script is run that uploads the strings to POEditor, which flags strings that have been added or changed in each translation and notifies the appropriate translators automatically. When translators have made the corresponding changes, a script is run that downloads the translated strings files where they can be built into the application. In short, POEditor allows us to automate much of the localization process so that developers can focus on developing and translators on translating.

Kirk Swenson (kswenson@concord.org) is a senior software engineer.

This material is based upon work supported by the National Science Foundation under grant DRL-1417809. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.