Version 3 (modified by 17 years ago) ( diff ) | ,
---|
Translation / localization issues
Some ideas on how translation of the software can be improved in the future. I (Jeroen) started some discussion on this topic on the mailinglist (see: http://www.nabble.com/Localization-issues-tf4097440s18419.html ).
Our current structure of language files is the following one:
English:
<strings> <about>About</about> <abstract>Abstract</abstract> <accept>Accept</accept> <add>add</add> <addNewMetadata>Add new metadata</addNewMetadata> </strings>
Arabic:
<strings> <about>عن البرنامج</about> <abstract>مقدمة</abstract> <accept>قبول</accept> <add>إضافة</add> <addNewMetadata>بيانات أساسية Metadata جديدة</addNewMetadata> </strings>
A possible solution to improve this structure is:
English:
<strings> <string i18n_key="about">About</string> <string i18n_key="abstract">Abstract</string> <string i18n_key="accept">Accept</string> <string i18n_key="add">add</string> <string i18n_key="addNewMetadata">Add new metadata</string> </strings>
Arabic:
<strings> <string i18n_key="about">عن البرنامج</string> <string i18n_key="abstract">مقدمة</string> <string i18n_key="accept">قبول</string> <string i18n_key="add">إضافة</string> <string i18n_key="addNewMetadata">بيانات أساسية Metadata جديدة</string> </strings>
This can have the following advantages:
- This has minimal impact on our existing stylesheets that generate the localized output.
- It is pretty trivial to generate a list of i18n_keys in use in the software.
- The generated output can be used to highlight missing and obsolete keys in each language file.
- There is the potential to store all keys and language strings in a database that has a simple translation user interface accessible through the web. Such translation mechanism has already been implemented in GeoNetwork opensource for the non-static strings in the system. It could be setup on the developer website to work as the central translation facility. The static files required for a release can be generated as language packages automatically and be stored in SVN. It would require an import function to merge new strings in and flag missing ones. It would also need an XSL based export function to generate the appropriate output files.
Note:
See TracWiki
for help on using the wiki.