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