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