Hello all, CAL10N just added the functionality to load resource bundles in the encoding chosen by the user. Say bye bye to native2ascii. In order to specify the encoding for the resource bundle corresponding to a given locale, the @LocaleNames annotation had to be changed. Previously, one wrote: @BaseName("colors") @LocaleNames({"en_UK", "fr", "tr_TR", "el_GR"d }) public enum Colors { BLUE, RED, YELLOW; } To express the same information, now (in 0.7-SNAPSHOT) one has writte: @BaseName("colors") @LocaleData({ @Locale("en_UK"), @Locale("fr_FR") @Locale("tr_TR") @Locale("el_GR") }) public enum Colors { BLUE, RED, GREEN; } As you can see, the @LocaleData annotation includes multiple @Locale annotations. This is more verbose than what we had previously but allows us to write: @BaseName("colors") @LocaleData( defaultCharset="UTF8", value = { @Locale("en_UK"), @Locale("fr_FR"), @Locale( value="tr_TR", charset = "ISO8859_3"), @Locale( value="el_GR", charset = "ISO8859_7") } ) public enum Colors { BLUE, RED, GREEN; } It would have been preferable to write @BaseName("colors") @Locale("en_UK") @Locale( value="fr_FR", charset = "ISO8859_1") // compiler error @Locale( value="tr_TR", charset = "ISO8859_3") // compiler error @Locale( value="el_GR", charset = "ISO8859_7") // compiler error public enum Fruit { APPLE, ORANGE; } but the compiler forbids multiple instances of the same annotation. Can you think of a more elegant approach which still allows the user to designate the charset for a given locale? Cheers, -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch