[cal10n-dev] LocaleNames

[Ceki Gulcu]

Hello all,

Ralph recently pointed out that the conventions followed by the
ResourceBundle class entailed bundle chaining and the concept of a
default bundle. The steps followed by ResourceBundle to find resource
bundles are well detailed in the getBundle(String, Locale,
ClassLoader) method [1].

I intended to modify CAL10N so that when given a locale, it only takes
into account that locale, ignoring the default locale and the resource
bundle corresponding to the naked base name, i.e. the default resource
bundle.

However, if the locale has both a language *and* a country, and
corresponding locales exist, then CAL10N will take into account both
bundles, establishing the same parent child relationship as the JDK
ResourceBundle class.

For example, for base name "foobar" if the following bundles exist on
the class path:

  foobar.properties
  foobar_en_US.properties
  foobar_en.properties
  foobar_fr_FR.properties

and the system's default locale is "fr_FR", when CAL10N is asked to
find the resource bundles corresponding to the "en_US" locale, it will
ignore the foobar.properties (~ default bundle) and
foobar_fr_FR.properties (~ default locale), while combining the
foobar_en_US.properties and foobar_en.properties bundles in the usual
parent-child relationship.

My premise assumes that JDK's ResourceBundle lookup convention [1] is
unreasonably complicated. I hope I am not being too presumptuous.

Your comments are welcome.

[1] http://tinyurl.com/ldgej8

Ceki Gulcu wrote:
> Hi Ralph,
> 
> Given an enum type, the LocaleNames is used by tools such as the 
> maven-cai10n-plugin to determine which locales to check for. The 
> annotation is also used by the verifyAllLocales method in 
> IMessageKeyVerifier to... verrify all locales in one go. This is also 
> mentioned in the section entitled "One test to rule them all" in the 
> manual.
> 
> However, your point about the default locale and locale resource bundle 
> chaining are important. I need to study this a bit further before 
> reaching conclusions, but with CAL10N you could safely remove the 
> default resource bundle without fearing to have missed a key.
> 
> Cheers,
> 
> Ralph Goers wrote:
>> I'm not sure what the point of LocaleNames.java is. In a "normal" 
>> environment I would expect to see
>> colors_en_us.properties
>> colors_en.properties
>> colors_jp.properties
>> cololrs.properties
>>
>> In a lot of cases (in the U.S. anyway) colors.properties and 
>> colors_en.properties would be identical. But if the locale is set to 
>> something like es_MX, which doesn't exist in the list above, then 
>> colors.properties is going to be used.
>>
>> The other aspect to this is that property files can be chained. So 
>> colors_en_us.properties might only contain the keys for us specific 
>> phrases while colors_en.properties would contain definitions of all keys.
>>
>> The point is that in a "properly" configured system the key verifier 
>> should only fail if there is no key in the default file.
> 

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