[
http://opensource.atlassian.com/projects/roller/browse/ROL-1413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_13777
]
Allen Gilliland commented on ROL-1413:
--------------------------------------
A first attempt at some fixes for this issue have been committed at trunk
revision 541035.
The commit note is as follows ...
initial fix for ROL-1337 and ROL-1413 which aim to improve and consistify the
i18n situation in Roller. this commit attempts to simplify and unify the
strategy for dealing with i18n message strings primarily in places used for
weblog rendering.
The main changes here include ...
1. changing the static MessageUtilites class into an instantiable I18nMessages
class which is tied to a specific locale.
2. updating places in the code which used to use the old MessageUtilities class
to make use of the new I18nMessages class and do so using the most appropriate
locale possible.
> 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
