2009/9/3 Ceki Gulcu <ceki@qos.ch>
<snipped> I am actually considering removing the parent-child relationship between language and language+country. It just does not make sense to do a different translation for en_UK and en_US. You would do one translation for English "en" serving all English speaking countries. Similarly, it does not make sense to do a French translation for France and another for Switzerland as the language is the same (French). Doing a Swiss version of a German web-site could make sense because Swiss-German is considerably different than the German spoken in Germany. Actually, the Swiss-German spoken in different regions of Switzerland have notable differences as well. But given that Swiss-German is *not* a written language, a web-site for Swiss-German customers would be written in German. As far as I can tell, for most practical purposes, it's the language that matters, not the country and (almost) certainly not the region.
For translation purposes, "en_UK" and "en_US" can just map to "en". This does not mean that en_UK and en_US should be reduced to "en" because the respective currency or date format conventions are likely to be different. In CAI10 the emphasis is on translations.
... Translating applications to different languages is an expensive and
cumbersome process.
I understand and agree with your emphasis on translation, and the difference between translation and other localisation issues. But I don't agree that this leads us away from Java's Locale as the basis for Cal10n. I like things to be kept simple - however, on the principle of least surprise, maintaining the existing well-known model keeps Cal10n more approachable to potential users. In the case of English, UK and US share almost all locale settings except for date format, but the grammar and spellings are a little different so the translation is a little different. It is clear that organisations *do* feel they need to support finer-grained translation than just "English" or "French". For example, Mozilla and Open Office are both available with en-UK language packs as well as en-US. Cal10n *must not* cut off such usage, IMHO. Therefore I recommend you keep the parent-child relationship between language and language+country. As I said before, I think it would be wise to retain the region level as well, although I have a less-strong view on that (I can't remember ever seeing a serious use of it).
Hopefully, CAL10N can alleviate some of the pain with a more streamline process. My next goal is to eliminate native2ascii converter from the translation process.
Wahey!!! One UTF-8 to rule them all! (Or maybe UTF-8 or UTF-16 using the Unicode BOM to indicate which, with UTF-8 being the default.) Native2ascii was one of Sun's early short-sighted mistakes. I hope you can appreciate my well-intended frank views. :) Rick -- Big Bee Consultants Limited : Registered in England & Wales No. 6397941 Registered Office: 71 The Hundred, Romsey, Hampshire, SO51 8BZ