If in the next release Click will have a pluggable messages Map this could resolve most of the problems, in fact as of now one must modify the click jar! If click targets java 1.5 it seems that the only solution is the self made resource bundle (given that the hack is not a very clean solution).
How the situation is handled in a couple of existing framework: -Tapestry: properties file encoded in UTF-8 by default. They are read using an hack, see http://tinyurl.com/2g5m8zu -Wicket: properties file read using ResourceBundle (so ISO8859) Ability to use read XML based properties in UTF-8, see http://tinyurl.com/37frn4m -Grails: properties file encoded in UTF-8 by default It seems they are read using an hack, see http://www.grails.org/Internationalization -- Lorenzo On Nov 2, 2010, at 0:58 , Bob Schellink wrote: > Hi Lorenzo, > > his has been brought up before but I can't recall if a proper solution was > suggested. > > I know Java 5 introduced XML based properties, but I think key/value > properties are preferred as > language packs. Java6 introduced more flexibility around loading bundles, but > I'm not sure how that > works, and Click targets Java5. > > I'm not familiar with how Wicket and Tapestry solved the issue? Did they > reimplement ResourceBundle? > > The next Click release will have a pluggable messages Map factory to change > the default > implementation. Still I'd be interested to know if there is an easy way to > achieve UTF-8 support. > > There is this hack[1], but hacks make me nervous. > > Kind regards > > Bob > > [1]: http://www.thoughtsabout.net/blog/archives/000044.html >
