[cal10n-dev] Simplified lookup - too simple?

[Ceki Gulcu]

Rick Beton wrote:
> 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.

Point well taken.

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

OK.

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

The user will able to specify the encoding used for the property file for a 
given locale. This means that you will be able to encode the property file for 
for the "en_US" locale in US-ASCII charset, the file for the "fr" locale in 
ISO-8859-1 charset, the file for "gr" (Greek) in ISO_8859-7 charset, the file 
for "hb" (Hebrew) in ISO_8859-8, the "jp" file in whatever is appropriate in 
Japanese.

The @LocaleNames annotation had to be expande to something more verbose to cope 
with this need. So, you'd say:

@BaseName("colors")
@LocaleData({
   @Locale("en_UK"),
   @Locale("fr", "ISO_8859-1")
   @Locale("gr", "ISO_8859-7")
   })
public enum Colors {
   RED,
   BLUE,
   GREEN;
}

You could also opt for "UTF-8" for everything...

> I hope you can appreciate my well-intended frank views.  :)

Indeed I do. Thank you.

-- 
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch