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_differenc... 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@qos.ch http://qos.ch/mailman/listinfo/cal10n-dev