As the product owner, you may wish to have your Django web system offered in multiple languages, especially here in Canada where we have two official languages. This article introduces three ways of achieving it.
The technical jargon “i18n” abbreviates the long word “internationalization” by its 18 letters, but doesn’t necessarily simplify the underlying efforts that make it happen.
1. The default way: Programmers manage the translations
By default, Django utilizes GNU gettext, as the regular practice of open source software. Programmers run the Django command “makemessages” to find out all texts marked as translatable in the code base.
The “makemessages” command produces a series of PO files, corresponding to the number of languages and number of modules. Fortunately, PO files are simply text files and there also exist a number of editing tools. Thus these files can be emailed to translators who will work on them.
Once PO files are completed, programmers receive these final files and load into Django by “compilemessages.” At the same time, these files are checked into version control of the web system.
The default way follows the traditional procedure of version-based software development. It is always stable, as proved throughout the years (since 1990s when GNU gettext was created). But for a fast-paced development cycle, the default way requires too many repetitions between programmers and translators that usually don’t work on the same pace, and may frustrate both parties as project develops.
2. The Agile way: Offer translators the tools to edit translations
We think the system to exist as code but may want the translations to exist as data. The default way is sometimes too Von Neumann. Then, the Agile way proposes to separate the workflows of programmers and translators. Studio theYANG analyzes two examples below.
In one project that Studio theYANG has been working with SOCODEVI, the web system provides five languages in the user interface. We created a dedicated translator interface built upon Django Rosetta for translators. A button in the admin interface can trigger the update of PO files, calling “makemessages” command behind the scene but completely transparent to the admin users.
Django Rosetta in fact provides a simple but private tool for editing PO files. The integration has to be implemented by programmers as an initial work. It has been so far proven easy and user-friendly.
In other projects Studio theYANG has seen usages of translation platforms, such as Transifex. Although still in need of an explicit integration into any development workflow, these platforms provide more flexible choices, for example, being capable of updating and synchronizing with Git repository. Programmers are free to release blank PO files and check them into version control at any time, and completed PO files stay in the code repository, testable backwards by programmers.
3. The customized way: If there are special needs
We may or may not want to rely on Django’s “makemessage” command. We may not, when there are special needs. Another SOCODEVI project recently requests the separation of “formal translations” and “adaptations to local context,” with the former provided by dedicated translators and the latter entered by privileged system users when they need.
The special needs, such as above-mentioned, can go out of GNU gettext model. Django’s “makemessage” command will not be sufficient, but fortunately Django has provided extensible programming tools to help achieve the desired functionalities without an overhaul of the system.
Whichever situation you are in, Studio theYANG will always be able to find out the proper solutions for your internalization (i18n) needs.
Studio theYANG 