You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "Dave Newton (Commented) (JIRA)" <ji...@apache.org> on 2011/10/08 13:46:29 UTC

[jira] [Commented] (WW-3690) i18n don't work in jsp pages (accessed directly) when locale changed

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

Dave Newton commented on WW-3690:
---------------------------------

If you access a JSP page directly there's no action behind it: I18N works via the backing action's TextProvider implementation.

In other words, the tags depend on their being someone on the value stack that can do localized text lookup. No action, no stack, no I18N.

You shouldn't be accessing a JSP page directory anyway.
                
> i18n don't work in jsp pages (accessed directly) when locale changed
> --------------------------------------------------------------------
>
>                 Key: WW-3690
>                 URL: https://issues.apache.org/jira/browse/WW-3690
>             Project: Struts 2
>          Issue Type: Bug
>          Components: Dispatch Filter, Expression Language, Value Stack
>    Affects Versions: 2.1.8.1
>         Environment: tomcat 6.x, java jre1.5 , struts-2.1.8.1 + xwork-2.1.6
>            Reporter: tim shaw
>            Priority: Critical
>              Labels: i18n, locale,
>
> i found i18n tags in jsp pages rendered by action result work fine, but those in jsp pages accessed directly( for example http://localhost/abc/xyz.jsp) can't work properly according to the locale info which already set by the ActionContext.setLocale(locale).or ActionContext.getSession().set("WW_TRANS_I18N_LOCALE",locale) in some action.execute() method before.
> in my humble opinion, all of tags in jsp pages ( both accessed directly and rendered by some action result) should work in accordance with some locale take procedences like that: 
> 1: evaluate the request locale. if there is no locale info,then:
> 2: evaluate the session locale, if there is no locale info ,then:
> 3: evaluate the default locale configed by StrutsConstants.STRUTS_LOCALE
> 4: if there are still no locale info ,then jre system properties will give a hand.
> IS IT RIGHT?
> to found the problem, i navigated some code snipes  about the locale in struts 2.1.8.1
> StrutsPrepareAndExecuteFilter.doFilter method line 78: prepare.createActionContext(request, response); =>
> PrepareOperations(Line 78) stack.getContext().putAll(dispatcher.createContextMap(request, response, null, servletContext)); =>
> Dispatcher(Line 535)  Map<String,Object> extraContext = createContextMap(requestMap, params, session, application, request, response, context); =>
> Dispatcher.createContextMap (line 568)
>         Locale locale;
>         if (defaultLocale != null) {
>             locale = LocalizedTextUtil.localeFromString(defaultLocale, request.getLocale());
>         } else {
>             locale = request.getLocale();
>         }
> here,locale will take precedence like that,first defaultLocale,then request.getLocale().
> and thre result locale will be set in the ActionContext.setLocale()
> at last the jsp i18n tags' propertes evaluated by DefaultTextProvider.getText(String),Here is the code:
> DefaultTextProvider.java(Line 37 xwork-2.1.6.jar):
>         return LocalizedTextUtil.findDefaultText(key, ActionContext.getContext().getLocale());
> and i read the i18ninterceptor ,it will populate the ActionContext.locale by the session locale if no local info given by the current request. (but as we know ,all interceptor will execute only when we access some action!)
> so from then on, it seemed that i found the weird i18n tags in direct accessed JSP pages, because there are no further process for these direct accessed jsp pages ,just like the i18ninterceptor for actions.
> is there anything i missd or Is is a bug?
> btw,my english could be better,sorry for that.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira