click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob Schellink <>
Subject Re: Properties file UTF-8
Date Wed, 03 Nov 2010 10:00:01 GMT
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.


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
> 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
> -Wicket:
> properties file read using ResourceBundle (so ISO8859)
> Ability to use read XML based properties in UTF-8, see
> -Grails:
> properties file encoded in UTF-8 by default
> It seems they are read using an hack, see
> --
> 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
>> 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]:

View raw message