Difference between revisions of "DevTools:JSword/Internationalization"

Revision as of 21:50, 24 October 2010

Internationalization (i18n)

This page is a placeholder.

JSword's and BibleDesktop's mechanism for i18n uses one Java property file per Java project for strings and another for UI controls. In order to translate BibleDesktop into another language, each of these needs to be translated. These files lack comments, and they are an ASCII representation of UTF-8. For a user to translate BibleDesktop, these files have to be converted into UTF-8, modified and then converted back. Together this has resulted in BibleDesktop being translated into very few languages.

The request of translators is to:

• co-locate the files
• use as few files as possible
• have the files in UTF-8
• comment each string that needs to be translated
• use a format and tooling familiar to translators

Chosen mechanism

GNU's GetText will be used as it satisfies the needs of translators. However, it cannot be used directly as there is no Java implementation. Thus, we'll grow our own, evolving the current mechanism of CWAction and Msg.

Some work has already been done to that end:

1. Remove //$NON-NLS-1 markers that are throughout the code. These were used to mark what did not need to be i18n'ed. These are no longer helpful and can be eliminated.
2. Transform the current keys in the property files to the format needed for the GetText mechanism. Currently the keys are a complex symbolic representation of the purpose of the string. These were wrapped in a symbolic constant. These will be replaced with the actual English text.
3. In Msg create a gettext API that replaces the Msg.SYMBOLIC_NAME.toString(...) API.
4. Migrate to using these strings with the new API rather than symbolic constants and symbolic keys to do the lookup.

Marking text for i18n

Marking strings needing translation

Marking Comments

Creating a POT file

Updating a POT file

Creating PO files per language

Converting POT and PO files into Java property files