You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Tobias Haupt (Jira)" <ji...@apache.org> on 2021/06/25 12:53:00 UTC

[jira] [Commented] (WICKET-6898) StringResourceModel does not respect getLocale for messages

    [ https://issues.apache.org/jira/browse/WICKET-6898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17369445#comment-17369445 ] 

Tobias Haupt commented on WICKET-6898:
--------------------------------------

Ok, I didn't notice the javadoc that states that the locale should only be used for formatting. But then WICKET-5668 is not fixed, is it? Isn't it weird to use the locale for formatting only? How can it be useful, to only format parameters using a custom locale and fetching the message from a diffferent one?
The problem here is, that I want to use the standard formatting API of StringResourceModel but from a thread that performs a background task that does not have access to a component. StringResourceModel works with null components.

> StringResourceModel does not respect getLocale for messages
> -----------------------------------------------------------
>
>                 Key: WICKET-6898
>                 URL: https://issues.apache.org/jira/browse/WICKET-6898
>             Project: Wicket
>          Issue Type: Improvement
>          Components: wicket-core
>    Affects Versions: 9.3.0, 8.12.0
>            Reporter: Tobias Haupt
>            Priority: Minor
>
> WICKET-5668 states that StringResourceModel has a method getLocale that can be overwritten to provide a custom locale when the messages should be differently localized than the context (Component, Session, default) states.
> The method getString only uses the custom locale when parsing the message with MessageFormat but not to retrieve the message from the Localizer. The locale parameter is null there (Lines 439, 445 / wicket9)
> In my usecase I use the StringResourceModel without a component but want't to provide a custom locale. Instead the Locale.defaultLocale is used to resolve the ressource.
> *Solution:* use the custom Locale getLocal() as parameter for localizer.getString. (The resolving of the locale is implemented the same way in StringResourceModel.getLocale and Localizer.getStringIgnoreSettings anyway.)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)