[
https://issues.apache.org/jira/browse/TAPESTRY-1997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12606314#action_12606314
]
Andy Blower commented on TAPESTRY-1997:
---------------------------------------
I decided to take a look into this (just trying to do my bit.. ;-) and I think
I've found what the problem is. The problem is not with the list of supported
codes or storing the current locale in the cookie, it's incorrect use of a
Locale constructor in PersistentLocaleImpl line 45 when retrieving the current
locale:
return localeCookieValue != null ? new Locale(localeCookieValue) : null;
This is fine if localeCookieValue is just a language code, but if it's a
language and country (and/or variant) like "en_GB" then the Locale object
created contains a language code of "en_gb" (lowercased in the Locale class as
language codes should be lc) and no country code. To construct a Locale with
language and country codes, you need to separate them and use the two (or
three) string constructor. Personally I don't bother with this and simply use
the LocaleUtils class from the commons-lang.jar like this:
LocaleUtils.toLocale(str)
So line 45 of PersistantLocaleImpl could simply become:
return localeCookieValue != null ?
LocaleUtils.toLocale(localeCookieValue) : null;
There may be other changes to T5 code required as a consequence of this change,
I don't have enough familiarity with the codebase yet to know. Adding the
commons lang dependency is your choice, but it's so generally useful I'd be
surprised if it wasn't used in most webapps anyway - I know I've used it in
every webapp I've developed for several years now.
> PersistentLocale is lower-casing locales
> ----------------------------------------
>
> Key: TAPESTRY-1997
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1997
> Project: Tapestry
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.0.6
> Reporter: Geoff Callender
> Assignee: Howard M. Lewis Ship
>
> An issue affecting localization: PersistentLocale is converting locales from
> mixed case to all lower case, which is useless for formatting. For example,
> if page 1 sets the locale like this:
> @Inject
> private PersistentLocale _persistentLocaleService;
> Locale locale = Locale.UK;
> _persistentLocaleService.set(locale);
> System.out.println("locale is " + locale + " - " +
> locale.getDisplayName());
>
> then this is what prints:
> locale is en_GB - English (United Kingdom)
> But when I'm in page 2 I get the locale and find it has mutated...
> Locale locale = _persistentLocaleService.get();
> System.out.println("locale is " + locale + " - " +
> locale.getDisplayName());
> ...this is what prints:
> locale is en_gb - en_gb
> This mutated locale in page 2 is useless for formatting. Code like the
> following produces default-styling instead of the styling for en_GB:
> _myDateFormat = DateFormat.getDateInstance(DateFormat.LONG, locale);
> System.out.println(_myDateFormat.format(new Date()));
> It seems this has also adversely affected how supported-locales are declared
> (maybe in previous releases only). See
> http://thread.gmane.org/gmane.comp.java.tapestry.user/56526/focus=56527
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
