Front page | perl.perl6.language |
Postings from June 2010
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 DuncanThread Previous | Thread Next