roller-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Allen Gilliland (JIRA)" <nore...@atlassian.com>
Subject [Roller-JIRA] Commented: (ROL-1413) i18n locale determine problems of roller ui and rendering system
Date Wed, 23 May 2007 19:15:55 GMT

    [ 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

        

Mime
View raw message