We are now starting to collaborate with folks outside of Connexions to internationalize the text provided by our Rhaptos and Connexions templates. In particular, we are about to begin working with volunteers from OOPS and the Vietnam Education Foundation (VEF) to internationalize our software for Chinese and Vietnamese.

Plone internationalization in a nutshell

Internationalization of Plone products works like this:

• Each element to be translated in a Zope page template in a product is identified by a message id or msgid. The msgid is specified as the value of the i18n:translate attribute of the element, like so:
  
  <div class="formHelp" i18n:translate="workgroup_name">
Enter a name for the workgroup.
</div>
  Here, workgroup_name is the msgid that identifies the string "Enter a name for the workgroup." and its translations.
• When the i18n:translate attribute is present but has no value (and hence no explicit msgid, then the string itself in the default language (usually English) is used as the msgid.
• Mappings of msgids to translated strings are in .po files, of which there is one per product per language into which the product is translated. .po files are found in the i18n subdirectory of a Plone product. For translations of Plone simpliciter we are using the PloneTranslations product, whose .po files override the translations in CMFPlone's own i18n subdirectory.
• The name of a .po file follows this form: <productname>-<lang abbrev>.po. So the name of the .po file for the German translations of RhaptosSite might look like this: RhaptosSite-de.po
  There is some flexibility in the productname part, but not in the language code or the extension.
• Visitors to a Plone site send a list of acceptable language codes to the server when requesting a page. Plone uses the first supported language and, if it's not the default, substitutes whatever translations there are from the language-specific .po file based on the msgids of the elements in the page templates.
• .po files are generated from a master .pot file that should contain all msgids for translatable elements in the product in question.
• .pot files are generated from a set of page templates with the i18ndude script--a script suite, really. This tool provides a wide array of i18n functionality for the Plone developer and translator.

Process issues

Some of the issues that arise in this system are obvious.

• As the templates are developed, new elements will be added with new msgids, which must be merged into the master .pot file and thence into each .po file.
• At present, very few explicit msgids have been assigned to elements in Rhaptos-specific Plone products. This has at least two consequences: (1) Connexions folks must assign meaningful msgids to each element in each template in each product; and (2) since this will not be done before we hand off .po files to translators, we will eventually have to merge early .po files with literal instead of explicit msgids into newer .po files with explicit msgids for their elements.
• We shouldn't assume that all translatable elements have i18n:translate values--we may have to retrofit code with that attribute as well as assign useful msgids.
• A fair number of our ZPT files are not valid XML, which causes i18ndude to fail.

Priorities

Here are some things we need to do in rough order of priority:

• roll PloneTranslations 0.8 into production/trunk (Done!)
• hand off .po files (mostly with literal msgids, unfortunately) to Alvin (OOPS) and Hung (VEF)
• decide on conventions for creating msgids
• Elizabeth & I choose a product to which we start adding msgids
• fixing XML in ZPT files (Bug Day?) so that the i18n tools can work with them
• identify elements lacking i18n:translate attributes in existing code, and add attributes and msgids to them
• i18n Day for adding msgids to existing code? (wouldn't everybody love that?)
• explore tools/techniques for moving from literals to explicit msgids?
• look into meaning & usage of i18n:domain
• create a dev server for i18n work
• look into i18n tagging for Python code