[cal10n-dev] Better annotations?
Ceki Gulcu
ceki at qos.ch
Fri Sep 4 12:35:43 CEST 2009
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
More information about the cal10n-dev
mailing list