[cal10n-dev] Simplified lookup - too simple?

[Ralph Goers]

On Sep 3, 2009, at 6:24 AM, Rick Beton wrote:

> 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.

LOL. You must be in the UK! (See my prior message on spelling  
differences).

>
> 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
> _______________________________________________
> cal10n-dev mailing list
> cal10n-dev at qos.ch
> http://qos.ch/mailman/listinfo/cal10n-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://qos.ch/pipermail/cal10n-dev/attachments/20090903/6bead7a2/attachment.htm>