[
http://opensource.atlassian.com/projects/roller/browse/ROL-1413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_13774
]
Allen Gilliland commented on ROL-1413:
--------------------------------------
I took a look at this patch and while it does improve a number of things I'm
not convinced that it really solves the problem in the ideal way. In
particular i'm too keen on using TLS for things, especially not for providing
shared access to something like a locale key. Instead I would prefer to see an
approach where any component which is dealing with data which will be displayed
to the user is properly aware of how to take locale and timeZone into account
in it's operations.
So, as an alternative to the submitted patch I have some code which does
roughly the same thing but in a slightly different fashion. The major change
is that instead of having the MessageUtilities class remain static it will
provide a static factory which will dispense immutable instances which are tied
to a specific locale. The idea here being that any class which wants to do
messaging can ask for access to a MessageUtilities instance, but it must supply
a locale that the messages will be in.
Once this is done we can begin touching up the rest of the code to properly get
an instance of the MessageUtilities class in the locale that should be used.
I'll be committing some of this code pretty soon, so please feel free to review
and offer feedback.
Side Note: a number of the classes & jsps originally listed have already been
EOLed as part of the struts1 -> struts2 migration and therefore are no longer
of concern. The new struts2 ui does i18n solely using browser language
preferences, which is the most consistent approach.
> i18n locale determine problems of roller ui and rendering system
> ----------------------------------------------------------------
>
> Key: ROL-1413
> URL:
> http://opensource.atlassian.com/projects/roller/browse/ROL-1413
> Project: Roller
> Issue Type: Bug
> Components: User Interface - General
> Environment: Any
> Reporter: Miles Huang
> Assignee: Roller Unassigned
> Attachments: i18n.patch
>
>
> Roller uses many ways to implement i18n messages.
> Consider following locales:
> Locale.getDefaultLocale(),
> request.getLocale(),
> RollerSession.getRollerSession(request).getAuthenticatedUser().getLocale()
> More cumbersome, current codes use different locales to get i18n message,
> which leads to different languages even on a single page.
> For a real web site for global users, it's quit common that all these locales
> have different values.
> In detail, following java classes and JSP pages have problem on i18n locale
> determine algorithm:
> The MessageUtilities.java: Use JVM default locale blindly, leave user
> preferred locale unchecked.
> The UtilitiesModel: Its formatDate methods use JVM default locale blindly.
> The StrutsCharEncodingFilter.java and taglibs.jsp: new Locale(String) will
> construct a locale instance which has only language part without country
> part, passing a '_' delimited locale string to the construtor , eg. new
> Locale("en_US"), is buggy. Everywhere there are getLocaleInstance() methods
> which do the right thing.
> The taglibs.jsp: Change JSTL fmt locale to authenticated user's locale only,
> leaves struts MessageResource locale setting along.
> The WeblogTemplateFormAction, BasePageModel, CommentServlet,
> SearchResultsModel, SearchResultsFeedModel, SearchResultsPager,
> SearchResultsFeedPager: Use a static ResourceBundle instance for all
> requests, does every one speaking same language? ;-)
> The StrutsUtil: single localeBeans and timeZoneBeans for the whole world.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/roller/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
