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