[jsword-devel] i18n config's help text

[Joe Walker]

Currently we could fairly simply iterate over the i18n strings. Since 
everything comes from MsgBase all we need is to make sure that all the 
Msg classes have been classloaded and we could:
- check that there was a 1-1 between Msg.ENTRY and properties entry
- have a simple gui to help with the i18n task

Both could turn out to be a huge boon.
If we moved to a totally separate method (XML/XSL) then we break this, 
so my gut reaction is to keep it as close the the current scheme as 
possible.

I don't have a problem with a static registry since the strings are 
static anyway.

Good stuff, you're way ahead of me on this one.

Joe.

DM Smith wrote:
> 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.
> 
> 
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel