Re: [tlug] Language localization in Javacript

["Stephen J. Turnbull" <stephen@example.com>]

Darren Cook writes:

 > > strings = {
 > > 	english: { hi: "Hello world", bye: "Goodbye" },
 > > 	japanese: { hi: "こんにちは舌皛逅跂勉闕\xA6", bye: "さよなら" },
 > > 	french: { hi: "Bonjour tout le monde", bye: "Au revoir" },
 > > }
 > > 
 > > var language = "english";
 > > 
 > > document.writeln( strings[language]["hi"] );
 > 
 > I'm glad I read all the posts before replying; Simon's answer above is
 > what I was going to suggest.

"Simon says, 'use a data structure'!"

The biggest advantage to use of a data structure is that it localizes
the string database in the program, making it easier to add languages
or update translations.

However, there are three potential maintenance problems with it.  The
first is that unless you have a very small number of strings, coming
up with barewords that do the job as indicies is going to be tedious
and mistake-prone.  (gettext solves this by using the model language
strings themselves as indicies.)

The second is that (again, unless you have a very small number of
strings) the model language (presumably English) is going to be "far"
(ie, many lines) from many of the languages, and in any case it's
going to be a PITA to match up changes to the English model to any
given target language.  gettext doesn't solve this by itself, but
because it's a mature solution tools have been written to extract the
indicies (ie, the model language strings) and provide a
"fill-in-the-blanks" form for translators.  They'll even mark the
translations that need to be updated for you.

A third potential problem is that this format is not very friendly to
non-programmer translators.  (gettext is a familiar format to many
translators already.)

You also may need to account for the possibilty of missing
translations.  What will the Javascript do in a Japanese locale if you
add

    johnnytest: "Didn't see /that/ coming!"

to the English and the program, but haven't updated the Japanese
translations to account for it?  (gettext returns the string from the
model language.  At least it's not a crash or an unsightly error
message.)

 > However, I'd still have a global var:
 > 
 > T=strings[language];
 > ...
 > document.writeln( T["hi"] );

Yup.  Very much like the gettext convention of using a macro such as

#define _(x) (gettext(x))

to make the call as lightweight as possible.

 > P.P.S. As others have said, this is all assuming you have a good
 > reason to have all languages statically embedded in an html
 > page. Which it sounds like you do.

"Static object" doesn't matter.  Generated things can be generated at
build time as well as at download time.