yary wrote:
Reminds me of an article of yore from The Perl Journal "Localizing
Your Perl Programs" http://interglacial.com/tpj/13/ which discusses
the reasoning behind Locale::Maketext
the point of which is that the "values" you're looking up should be
able to be functions, to handle some edge cases where nothing else
will do. That module isn't exactly what Darren is looking for since
the keys are English strings with a little meta-language mixed in, but
the rest of it is worth referencing.
Functions are fine. My main point is that all languages are treated in exactly
the same way as far as where their user text is stored and what format it has.
The common format could in fact be a Perl module for each language containing
the user text, and these all do a common role representing all the messages that
could be used.
You should not be treating the user text for one language differently from
others, by using the text of one language to look up the text of another, or by
embedding one user language in the main program code.
Now, this isn't to say that the common key can't resemble English, but you
should still have the separate copies of all the messages that are the actual
user text, and the common English-like key can be a simplified version.
A main point here is that if any translator or human-interfaces person wants to
tweak user text, say to capitalize a word or fix a misspelling, they shouldn't
have to go into the main program code to do it, and the process is the same for
every language, and you only have to update not more than one copy or location
per language.
Something I want to avoid is the actual English user text being used to look up
the others, because then if you want to tweak a misspelling or something in
English, you'd then have to find an change all the other copies of the text in
order for the mapping to be maintained.
Its a similar problem actually to a bad relational database design, where you
use something descriptive and likely to mutate (such as the English name of a
product for sale) as the column that a foreign key copies and points to, in
contrast to say a less descriptive product code. What I am proposing is to use
the analogy of the product code in your main code rather than the English
product name. But the code can still be quite English like.
Such as a role's function name can be English like.
-- Darren Duncan
