And before that, another system designed to be multi-lingual from very beginning. It was pain start developing application by creating dictionary, and adding every stupid message as database entry. But translation was easy: Person knowing both accounting AND german translated our system into german in about two weeks. Compile it in new language environment, resolve some screen issues (some german words are much longer), and you are done! Piece of cake!

When thinking about multi-language system, you need to think also about translating abbreviations for codes. I.e. "BK" is excellent abbreviation for "Bankruptcy" in english, but not in italian. So your need to translate easy mnemonic status codes into other language, too. It is long way before settling on Standard Intragalactic Language...;-)

pmas
To make errors is human. But to make million errors per second, you need a computer.

I've worked inside of several internationalized applications. All have been able to get by with a combination of separate "externalized strings" files for each supported language, plus a few extras, such as the equivalent of a custom sprintf that knew how to dynamically alter the order (position) of substitutions.

In the early 90's, for an embedded PC that controlled a scanning densitometer, I came up with a C++ class that fit our needs.

An associative array was indexed by a string value, which could have some nmenonic value to the code it's called from, and is easier to make unique and maintain in a large program than sequencial ID numbers as favored by MicroSoft.

The "hash" was populated from a translation file at program startup. The format of the file was the key followed by each available translation.

I liked the idea of having all translations of one string together, rather than a different file for each language like some schemes. I think Win32's language stuff (using FormatMessage, not the string table resource) works that way too, but is not nearly as powerful. FormatMessage has the dynamic positioning of strings like you mention; I don't remember how my old program handled that.

In a modern Perl solution, I think we can address the dynamic ordering easily enough:

If you pulled in the string with a function call, such as $x->format ($a,$b,$c); and the string contained markers $1, $2, and $3, you get the idea. But function calls don't interpolate in Perl 5, so using a tied hash for syntactic sugar might help.

I'd also like to see the format function automatically take care of changes based on the actual paramters, such as number and gender. E.g. $x->format(17) would cough up "There were 17 files processed." but $x->format(1) would produce "There was 1 file processed". Changes in words due to singular/plural is so common that an escape code could specify that. E.g. the translation string holds 'There $?n1(were,was,were) $1 file$?n1(,,s) processed.'. $ followed by digit is a substitution. $? followed by code/flags/etc then digit is fancy stuff: ?n for "number", followed by forms for zero,singular,plural cases.

—John

The work I do for Kodak supports English, Spanish, Italian, Brazilian Portugese, German, French, and Japanese.

In a script like Shadox's, it's pretty clear that only two language may be standard for his shop. Likewise in Canada and Texas border towns. That is, the problem set is indeed farily well known ahead of time.

So my thoughts at this point are: Major software engineering project with a full-blown UI (possibly GUI) should keep the UI elements (including strings) separate from the program logic. But a simple script with a few strings for prompts, warnings, and short results might be more easily done in-line.

Note that my scheme doesn't have to be in-line. All the strings can be grouped together at the top of the file, for example.

—John