[cal10n-dev] Simplified lookup - too simple?

[Ralph Goers]

On Sep 3, 2009, at 4:33 AM, Ceki Gulcu wrote:

> Hi Rick,
>
> Thank you for your comments.
>
> As you stated, the simplification is driven be verification purposes.
> Partially incomplete translations will fail only if the keys are
> missing, otherwise, verification for such translations will succeed.
>
> As for region support, it could be easily added. However, if someone
> comes with a concrete use-case, then the issue can be rectified. I
> just don't see anyone doing a translation by region. In Switzerland
> for example, we have 4 national languages, German, French, Italian and
> Romanch, which are spoken in different linguistic regions. Romanch is
> spoken by a very small minority. Bundles for each of the 3 major
> regions can be specified as ge_CH, fr_CH, it_CH (ignoring romanch).

Nonsense. English in Lousiana is very different than in California.

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

That is even more nonsensical. US english vs UK english vs  
Austriallian english are not even close.  The same is true for spanish  
in Spain vs Mexico. The folks who thought up locales put this stuff in  
for good reason. You're free to not support it but then this project  
won't have much of a following.

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

There are lots of words that are spelled differently. For example, it  
is Organization in the U.S and Organisation in the UK. (See http://en.wikipedia.org/wiki/American_and_British_English_spelling_differences#-ise.2C_-ize 
  to be thoroughly confused).

> Translating applications to different languages is an expensive and
> cumbersome process.  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.

This is why you should be using XML instead of property files. XML  
allows the encoding to be specified in the document. Ironically, java  
property files can be specified in XML but I don't believe resource  
bundles support them.
>
>
> Rick Beton wrote:
>> Hi,
>> Referring to the simplified lookup (http://cal10n.qos.ch/manual.html#simplifiedLookup 
>> ), I think this has been simplified too far.
>> Firstly, I think your simplification by removing the default  
>> properties file is justified because it makes it easier to test the  
>> robustness of the application, which is a Good Thing.  The decision  
>> may be controversial because it means that translations have to be  
>> done to completion or not at all; partially complete translations  
>> will fail.  But it is consistent with Cal10n's stated objective of  
>> supporting verifiably self-consistent resource bundles.
>> However, there is another issue that I am unhappy about.  Java's  
>> Locale allows language, country and region to be specified.  You  
>> have removed the region (or not documented it).  Although the  
>> region is not often used, I think it is necessary and should be  
>> supported.
>> Rick
>
> -- 
> Ceki Gülcü
> Logback: The reliable, generic, fast and flexible logging framework  
> for Java.
> http://logback.qos.ch
> _______________________________________________
> cal10n-dev mailing list
> cal10n-dev at qos.ch
> http://qos.ch/mailman/listinfo/cal10n-dev