Blueprint for an Upgrade to the Translation Functionality

Current situation

Sahana Eden uses the translation features of web2py. For the application programmer this requires the use of the function T() when displaying strings which will be displayed on the screen and so will need to be translated. The core web2py translation functionality extracts the strings and stores them in a *.py file, unfortunately this file only has space for the original and the translated string. For the translator it is often helpful to have a comment that can explain the context of a particular phrase. For other features to be introduced as part of this work it would also be necessary to know the origin of the string, this would be the file and possibly also the line number. (Note the sting may have more than one origin, i.e. it appears in the code in more than one place).

Changes to the core translation functionality

The standard web2py function should be extended to support an optional comment, ideally this would be done with the call to T() but a alternative separated solution may be acceptable.

When an instance of Sahana-Eden is deployed it may require translation, if this is during an emergency their may not be a lot of time and so only a select subset of strings need to be translated. This subset might be the front facing part of the deployment or it may include just the modules that have been deployed. However, when the files for translation are created their is no link back to the code and so it is difficult to know where the string came from. What is required is for the function to extract the location of the string this can then be used to determine which module the string belongs to. This functionality may have several iterations but with the final goal of being able to download strings for translation that belong to various modules, this might involve a UI that allows the translation administrator to select which modules (or parts) of the system they want to translate.

Round-trip translation UI

The journey from a untranslated string to a translated one can involve several different tools and can take different paths. The idea here is to integrate these tools (so this is not really about replacing them) into a single portal. One such route is as follows:

• Extract the strings from Eden
• build a spreadsheet that can be given to the translators
• convert the spreadsheet back to a *.py language file
• add back into Eden trunk

Then the code changes and a string needs to be modified. At this point the person managing the translation doesn't specifically know that a string is no longer required and so redundant strings hang around in the translated files (and some that may not yet have been translated which have since been superseded are still awaiting translation)

A second, and different, approach to translating the string it to use the Pootle tool, the integration of this would be nice but the key area is to be able to identify the strings for translation.

Once the strings for translation have been identified then the UI needs to provide a seamless mechanism to integrate them back into Sahana-Eden.

Technical help

For the translation process see the chapter in the book on ​Localisation For the translation code see web2py gluon/langauges.py file