Difference between revisions of "DevTools:JSword/Internationalization"
m (→Marking text for i18n) |
m (→Chosen mechanism) |
||
Line 12: | Line 12: | ||
==Chosen mechanism== | ==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. | + | GNU's [http://www.gnu.org/software/gettext/manual/gettext.html 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: | Some work has already been done to that end: |
Revision as of 10:36, 25 October 2010
Contents
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:
- 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.
- 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.
- In Msg create a gettext API that replaces the Msg.SYMBOLIC_NAME.toString(...) API.
- Migrate to using these strings with the new API rather than symbolic constants and symbolic keys to do the lookup.
Marking text for i18n
To use GNU's GetText mechanism, translatable text is marked in a simple way and comments are co-located with the string. GNU's GetText mechanism allows for programatic extraction of text needing translation and associated comments.
This section discusses how to mark up the text and comment it in the way that GNU's GetText extraction tools expects them. Later will be how to do the extraction.
Marking strings needing translation
Simply surround it with a call to gettext!
For simple strings:
String s = Msg.gettext("this should be translated");
or if it has variable parts:
String s = Msg.gettext("{0} should be translated", params);
Marking Comments
All comments that immediately precede the call to gettext will be included in the extraction. The comments follow the conventions defined in the GNU GetText mechanism. All of it can be used, but at a minimum we'll use the following form:
// TRANSLATOR: Clear English explanation of // how this string is semantically used in the program. // It should explain everything that the translator needs // to know in order to translate the string. // It can span several lines.