Plainbox offers a way for test authors to create localized testing experience. This allows test developers to mark certain strings as translatable and make them a part of existing internationalization and localization frameworks.
In practical terms, the summary and description of each job definition can now be translated to other languages. The provider management tool (manage.py) can now extract, merge and build translation catalogs that will be familiar to many developers.
The job definition file format already supported this syntax but it was not supported by Plainbox before, if you are maintaining an existing provider the only new thing, for you, may be the fact that a job name (summary) is now also translatable and that there are dedicated tools that make the process easier.
Looking at an example job definition from the Provider Template:
id: examples/trivial/always-pass
_summary: A test that always passes
_description:
A test that always passes
.
This simple test will always succeed, assuming your
platform has a 'true' command that returns 0.
plugin: shell
estimated_duration: 0.01
command: true
The summary and description fields are prefixed with _ which allows their value to be collected to a translation catalog.
Whenever you edit those fields you should run ./manage.py i18n. This command will perform several steps:
Each of those actions can be individually disabled. See manage.py i18n --help for details. This may be something you need to do in your build system.
After generating the template file at least once you can translate all of the job definitions into other languages.
There are many tools available to make this task easier. To get started just copy the .pot file to LL.po where LL code of the language you want to translate to and start editing. Run manage.py i18n often to spot syntax issues and get updated values as you typically will edit code and translations at the same time. Make sure that your editor can detect when a file is being overwritten and offer to refresh the edited copy, manage.py i18n almost always changes the layout of the file.
Once you commit the template file to your version control then you can use tooling support offered by code hosting sites, such as Launchpad.net, to allow the community to contribute translations. You can also seek paid services that offer professional translations on a deadline. In both cases you should end up with additional .po files in your repository.
Note
If English is not your first language it’s a very good idea to try to keep all of the strings translated to your language of choice and use the translated version daily. This process allows you to think about the English text, correct confusing statements, reword sentences and think about the terminology used throughout your tests. It will also show missing strings (those that are not marked for translation) or missing translator comments.
Remember: If you, the author of the test, cannot reasonably translate your test definitions into your native language, how can anyone else do it?
Test definitions are not the whole story. It is probably even more important to translate various testing programs or utilities that your test definitions depend on.
Standard development practices apply, you should make properly translated testing applications. It is advisable to reuse the same gettext domain as your test definitions so that you can reasonably measure how much of your test definition content is available in a given language.
For third party applications you may consider ensuring that they can be localized and translated, file bugs or contribute patches, including translations, for the languages that you care about.
It is advisable to separate commits that change the original string to the commits that update the translation template file and individual translation catalogues. The latter tend to be very long and almost impossible for anyone to review without specialized tools.
Keep in mind that changes to actual translations that are not caused by updates to the template file should be separated as well. This will allow reviewers to actually look at the changes in text (assuming that more than one person on the team knows that language).
Lastly you should never commit any of the build/ files (especially the generated, compiled .mo files) into the version control system.
You may find those links handy: