Ideally we don't have to reinvent the wheel on this. Sounds as if JDK6 solves this in a clean way by using a reader. While Click itself cannot use this mechanism yet, users could plug in a custom MessageMap that uses the UTF-8 reader.
Bob On 3/11/2010 03:47, Lorenzo Simionato wrote: > 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 >> >
