<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Sep 3, 2009, at 6:24 AM, Rick Beton wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote"><span style="color: rgb(102, 102, 102);" dir="ltr">2009/9/3 Ceki Gulcu <<a href="mailto:ceki@qos.ch">ceki@qos.ch</a>></span><br style="color: rgb(102, 102, 102);"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<span style="color: rgb(102, 102, 102);"><snipped></span><br style="color: rgb(102, 102, 102);"><span style="color: rgb(102, 102, 102);">
I am actually considering removing the parent-child relationship</span><br style="color: rgb(102, 102, 102);"><span style="color: rgb(102, 102, 102);">
between language and language+country. It just does not make sense to</span><br style="color: rgb(102, 102, 102);"><span style="color: rgb(102, 102, 102);">
do a different translation for en_UK and en_US. You would do one</span><br style="color: rgb(102, 102, 102);"><span style="color: rgb(102, 102, 102);">
translation for English "en" serving all English speaking</span><br style="color: rgb(102, 102, 102);"><span style="color: rgb(102, 102, 102);">
countries. Similarly, it does not make sense to do a French</span><br style="color: rgb(102, 102, 102);"><span style="color: rgb(102, 102, 102);">
translation for France and another for Switzerland as the language is</span><br style="color: rgb(102, 102, 102);"><span style="color: rgb(102, 102, 102);">
the same (French). Doing a Swiss version of a German web-site could</span><br style="color: rgb(102, 102, 102);"><span style="color: rgb(102, 102, 102);">
make sense because Swiss-German is considerably different than the</span><br style="color: rgb(102, 102, 102);"><span style="color: rgb(102, 102, 102);">
German spoken in Germany. Actually, the Swiss-German spoken in</span><br style="color: rgb(102, 102, 102);"><span style="color: rgb(102, 102, 102);">
different regions of Switzerland have notable differences as well. But</span><br style="color: rgb(102, 102, 102);"><span style="color: rgb(102, 102, 102);">
given that Swiss-German is *not* a written language, a web-site for</span><br style="color: rgb(102, 102, 102);"><span style="color: rgb(102, 102, 102);">
Swiss-German customers would be written in German. As far as I can</span><br style="color: rgb(102, 102, 102);"><span style="color: rgb(102, 102, 102);">
tell, for most practical purposes, it's the language that matters, not</span><br style="color: rgb(102, 102, 102);"><span style="color: rgb(102, 102, 102);">
the country and (almost) certainly not the region.</span><br style="color: rgb(102, 102, 102);">
<br style="color: rgb(102, 102, 102);"><span style="color: rgb(102, 102, 102);">
For translation purposes, "en_UK" and "en_US" can just map to</span><br style="color: rgb(102, 102, 102);"><span style="color: rgb(102, 102, 102);">
"en". This does not mean that en_UK and en_US should be reduced to</span><br style="color: rgb(102, 102, 102);"><span style="color: rgb(102, 102, 102);">
"en" because the respective currency or date format conventions are</span><br style="color: rgb(102, 102, 102);"><span style="color: rgb(102, 102, 102);">
likely to be different. In CAI10 the emphasis is on translations.</span> <br></blockquote><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex; color: rgb(102, 102, 102);" class="gmail_quote">
<div>...
Translating applications to different languages is an expensive and<br>
cumbersome process. </div></blockquote><div><br>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.<br>
<br>It is clear that organisations <i>do</i> 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 <i>must not</i> cut off such usage, IMHO.<br></div></div></blockquote><div><br></div>LOL. You must be in the UK! (See my prior message on spelling differences).</div><div><br><blockquote type="cite"><div class="gmail_quote"><div>
<br><span style="color: rgb(0, 0, 0);">Therefore I recommend you keep the parent-child relationship
between language and language+country</span>. 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). <br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex; color: rgb(102, 102, 102);">Hopefully, CAL10N can alleviate some of the pain<br>
with a more streamline process. My next goal is to eliminate<br>
native2ascii converter from the translation process.</blockquote></div><br><br>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.<br>
<br>I hope you can appreciate my well-intended frank views. :)<br clear="all">Rick<br>-- <br>Big Bee Consultants Limited : Registered in England & Wales No. 6397941<br>Registered Office: 71 The Hundred, Romsey, Hampshire, SO51 8BZ<br>
_______________________________________________<br>cal10n-dev mailing list<br><a href="mailto:cal10n-dev@qos.ch">cal10n-dev@qos.ch</a><br>http://qos.ch/mailman/listinfo/cal10n-dev<br></blockquote></div><br></body></html>