[cal10n-dev] Simplified lookup - too simple?

[Ceki Gulcu]

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

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


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