[cal10n-dev] Simplified lookup - too simple?

[Rick Beton]

2009/9/3 Ceki Gulcu <ceki at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://qos.ch/pipermail/cal10n-dev/attachments/20090903/98f99d9f/attachment.htm>