I would like to weigh in on the side of indirection.
My experience was as part of a very small company (I was the software
guy), where I created our application initially in English. When we
ready to translate, all the translator would have to do is edit ".ini"
files, which only consisted of key=value. I was even nice enough to have
separate files, e.g., ids.ini for dialog/menu fields, and help.ini for
setToolTipText. For a decent sized application, i.e., one with 30 or
so dialogs, there were about 1000 ids.ini and 500 help.ini lines to
translate. But there's more - we had about 6 separate applications.
Well, for each application, there was a global ini file that could be
shared (how many times do you have to translate: "File not found: ").
Bottom line - over 3000 lines to translate. But as painful as this
sounds, it was a no-brainer to determine with a few short ksh scripts
if the translator accidentally deleted/mangled a line. This was only
possible because the translator was 100% isolated from the dialog/menu
files, because I made it a policy to never have a single line of
"English" in the dialog/menu files. Finally, I bundled all the
translations in a a single res.jar.
Now it's 2005. I've tossed all my home grown code from reading ".ini"
files and now use ini4j from SourceForge (it uses Properties rather than
BundledResources). I am *not* an authority on SwixML, having only used
it for less than one week, however, I would find it nearly impossible
to guarantee the integrity of a translation if the xml files are edited
directly. *Every* field in the xml file should be exposed to
indirection. Further, to have the xml files directly exposed directly,
rather than bundled in a jar file is not acceptable (do you honestly
want to let uses to fool around with the xml files?) . I was successful
passing to swix.render a URL for the .xml from a jar file, but gave up
trying to pass a translation file via URL.
Now if you ever change you mind, I would suggest button text="${ok} />
rather than button text="@ok" /> because it would allow for a more
sophistacted buttontext="${how}${now}${brown}${cow}". This is not my
idea, ini4j also allows "[EMAIL PROTECTED]/key}" if coming from the properties
file
and [EMAIL PROTECTED]/key} if coming from the environment. Very cool.
Steve
_______________________________________________
Forum mailing list
Forum@carlsbadcubes.com
http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
