[sf-perl] Internationalizing a Perl application

Joe Brenner doom at kzsu.stanford.edu
Thu Jan 25 01:16:33 PST 2007


Quinn Weaver <quinn at fairpath.com> wrote:

> David Fetter wrote:

> > * What pains can I avoid, and how?

Don't use built-up strings.  Programmers like to do clever things like
write a generic message where nouns are filled in like a game of 
madlibs:  

  Could not find the ____ named _____, please try a different one.

Then they hand that off to be localized, even though it's effectively
impossible to do it (e.g. in many languages different nouns have
different "gender", which changes the appropriate determiner to use in
place of "the").

Other potential gotchas:

  The order of words can change in translation.
  Plurals don't just get an "s" tacked on the end.

You can cover your self on almost all of these problems if you code all
messages in complete sentences.  In the above example you want to have a
separate "Could not find" string for each noun, even if it seems really
redundant to do it that way in English.  It's probably okay to have a
string you're going to substitute a number into ("Found ___ matches."),
but you should keep in mind you'll want separate strings for the
singular and plural case.  

Complete sentences also help provide a little context for the linguists,
who can easily have trouble figuring out how a string is used by the
software (if you just see the string "file", how do you know if that's a
noun or a verb?).

There are other potential headaches that hopefully you won't be stung
by.  For one thing, strings can expand a lot in translation (english is
a pretty tight language).  Even if you're using an automatic layout
manager, that can still be a problem (differential expansion rates can
invert a ratio: the designer expected one line would always be shorter
than another, but... ).

Another good one is when you need to choose keyboard shortcuts that use
letters in the command names.  Some languages work a smaller set of
letters harder than English does, making it impossible to choose an
unambiguous set of shortcuts for a given menu.

One of my all time favorite problems was running into a synonym shortage
in the target language: The English app had commands to "search",
"find", "seek", "browse"... and there were only two available similar
words we could use in translation.  That then messed up the context
sensitive help (which could no longer figure out which
search/find/seek/browse thingie we were talking about).

(I used to do this stuff for a living, in case you couldn't tell, though
that was a long time ago...  we had only barely heard of UTF8 in those
days.)



More information about the SanFrancisco-pm mailing list