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.