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 ).

---

Update 25-02-2008 Discussing with ​Stefano Costa I was pointed to ​pootle and ran into the ​XLIFF format which seems a good direction for us.

It will require rewriting the below to fit that obviously more standard approach.

I can see some relations to translated metadata content too :-)

---

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.