[jsword-devel] i18n config's help text

[DM Smith]

As I said I am nearly done. But I have found another thing that needs to
be translated: The drop down lists are ordered and the program has an
implicit mapping to that ordering. Each language needs to be able to
provide its own ordering. So I thought that I would revisit the
implementation choices. (So as to not bury the lead, I am playing with
the second choice)

I would like some feedback and even other alternatives.

Basically, I see two choices for internationalizing an XML file. One can
use xml:lang="xxx" in the xml file for each translation. I have not
looked into it but I don't know if the xml:lang attribute is *meant* to
handle localization (e.g. British and American spellings are different
[colour vs color], but both are EN). Perhaps I am missing something, but
the behavior of defaulting on a tree of translations (as a
ResourceBundle does), is not built into the parsing (crimson is used by
JSword) the XML file. It would be simple enough to write a XSLT to do it.

The other way is to put the translations into ResourceBundles and change
the XML to provide keys for the strings.

The advantage to doing it in XML and XSLT is that only one place in the
code needs to be changed. That is where config.xml is loaded into a
Document. Instead of passing that document, a new document would be
created via XSLT and that would be passed.

The disadvantage to that mechanism is that the XML file would need to be
presented for translation. The translators would need to understand XML
authoring and the results would need to be audited by a programmer. I
have tried this before and it does not work well.

The advantage of doing it in ResourceBundles is that the lookup
mechanism is already present and translating a ResourceBundle is fairly
simple and does not require careful auditing (still some is needed to
ensure that the keys did not change.)

The disadvantage is that the ResourceBundle needs to be accessible
everywhere translatable text is currently gotten out of the file. Since
config is written to allow more than one configuration per program one
either needs to pass it all over the place (which is relatively trivial)
or a static registry needs to be created that is accessible by each of
the methods where translations are needed.

Joe Walker wrote:
>>I am nearly done internationalizing the help text for config.
>>I noticed that it also uses the key as the label for the page of config.
>>So that will need to be changed.
> 
> 
> Good one - I'd thought that bit could be trickier.
> 
> Joe.