[ 
https://issues.apache.org/jira/browse/TAP5-2028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jochen Kemnade closed TAP5-2028.
--------------------------------
    Resolution: Incomplete

We assume this is no longer relevant and therefore close it.
If you still have this issue in a recent Tapestry version (such as 5.4.1 or 
newer), feel free to provide the necessary information and reopen.

> org.apache.tapestry5.ioc.internal.util.MessagesImpl should load messages with 
> UTF-8 encoding
> --------------------------------------------------------------------------------------------
>
>                 Key: TAP5-2028
>                 URL: https://issues.apache.org/jira/browse/TAP5-2028
>             Project: Tapestry 5
>          Issue Type: Improvement
>          Components: tapestry-ioc
>    Affects Versions: 5.3.6
>            Reporter: Balázs Palcsó
>              Labels: bulk-close-candidate
>         Attachments: MessagesImplUTF8.patch
>
>
> In my tests I'd like to verify the content of the generated HTML. Instead of 
> duplicating and hard coding the output messages that already exist in 
> properties file I would like to load the messages from the properties file of 
> the page classes I am testing.
> I was looking around the possibilities and I found that MessagesImpl would 
> fit my needs. (and also asked on the users list: 
> http://tapestry.1045711.n5.nabble.com/Unable-to-load-messages-in-UTF-8-encoding-in-test-class-in-different-class-than-messages-belong-to-tp5717808.html)
> private final Messages messages = MessagesImpl.forClass(Registration.class);
> would be the proper solution to load messages of my Registration page if
> MessagesImpl.forClass(Class) used UTF-8 encoding instead of the default
> ISO-8859-1 (latin1) when loading properties files.
> In pages and components my UTF-8 encoded properties files work correctly as
> documented at http://tapestry.apache.org/localization.html
> Currently MessagesImpl is part of the internal package, but I think this 
> class would be useful wider usage therefore I would suggest moving this class 
> to a "public" package.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to