Hi Bernhard,
This is what i logged with log4j within my action
LOGGER.debug("Request Locale " + request.getLocale() );
LOGGER.debug("Current locale: " + getLocale(request));
log file snipplet:
2003-02-14 13:26:16,089 DEBUG [de.grob.portal.action.LoginAction] Request
Locale de
2003-02-14 13:26:16,089 DEBUG [de.grob.portal.action.LoginAction] Current
locale: en
Interesting. Seems that the getLocale(HttpRequest request) method does not
work correclty.
Here ist the source of this method:
/**
* Return the user's currently selected Locale.
*
* @param request The request we are processing
*/
protected Locale getLocale(HttpServletRequest request) {
HttpSession session = request.getSession();
Locale locale = (Locale) session.getAttribute(Globals.LOCALE_KEY);
if (locale == null)
locale = defaultLocale;
return (locale);
}
I gues the session does not contain the Globals.LOCALE_KEY. Mhm.
Since
defaultLocale == Locale.getDefault() the OS Locale is choosen, which is
incorrect and overwrite the feature.
As far as I see the correct behavoir should be :
/**
* Return the user's currently selected Locale.
*
* @param request The request we are processing
*/
protected Locale getLocale(HttpServletRequest request) {
HttpSession session = request.getSession();
Locale locale = (Locale) session.getAttribute(Globals.LOCALE_KEY);
if (locale == null)
locale = request.getLocale();
// ^^^^^^^^^^^^^^^^^^^^
return (locale);
}
This ensures that the correct language is choosen. What do you think?
Bye
Toby
> -----Original Message-----
> From: Hirschmann, Bernhard [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 14, 2003 12:48 PM
> To: 'Struts Users Mailing List'; '[EMAIL PROTECTED]'
> Subject: AW: bean:message problems with i18n
>
>
>
> Hi Toby,
>
> I solved this problem doing something different: I instantiate now the
> Locale object only with the language parameter, and *without*
> the country
> parameter.
> new Locale("en","");
>
> This locale object is then stored in the session using the method:
> org.apache.struts.action.Action.setLocale(javax.servlet.http.H
> ttpServletRequ
> est request, java.util.Locale locale);
>
> This way it works - don't ask me why.
>
> I guess it could be a bug in the <bean:message> tag.
>
> Regards,
> Bernhard
>
>
> -----Ursprüngliche Nachricht-----
> Von: Rademacher Tobias [mailto:[EMAIL PROTECTED]]
> Gesendet: Freitag, 14. Februar 2003 12:08
> An: 'Struts Users Mailing List'
> Betreff: RE: bean:message problems with i18n
>
>
> Hi Bernhard,
>
> I have the same problems as you.
>
> Application.properties (fallback english)
> Application_de_DE.properties( German translation )
>
> I'm using 1.1b2. If your OS language is German the German
> property is used.
> If not the English one.
> My application does seem to use session saved Locales.
>
> Do you save the locale in the session?
>
> Maybe you try:
>
> <controller
> nochache="true"
> locale="true"
> />
>
> in your struts-config.xml.
>
> I tried locale with 1.1b2 but not with nocache. Maybe that
> work in 1.1b3 and
> with both set to true.
> If it works with 1.1.b3 could you inform me?
>
> Bye
> Toby
>
> > -----Original Message-----
> > From: Hirschmann, Bernhard
> [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, February 13, 2003 7:15 PM
> > To: 'Struts Users Mailing List'
> > Subject: AW: bean:message problems with i18n
> >
> >
> >
> > James, thanks for your help!
> >
> > I tried it in different browser types and in different
> > windows. So this
> > appears also in different HTTPSessions. I can reload as much
> > as I want, and
> > I do not use any proxies for that. So I guess it is not a
> > caching issue.
> >
> > I checked the <html:html> tag. The lang attribute has always
> > the correct
> > value, like set in the Action.setLocale() method. However, the wrong
> > messages are always in the language, in which the
> > <bean:message> tag has
> > requested the message the very first time. The fallback
> mechanism just
> > doesn't work anymore.
> >
> > Does the <bean:message> tag use some kind of caching using
> > the resources?
> >
> > I also tried to switch back to struts 1.1b2, but with the
> same result.
> >
> > Bernhard
> >
> >
> > -----Ursprüngliche Nachricht-----
> > Von: James Childers [mailto:[EMAIL PROTECTED]]
> > Gesendet: Donnerstag, 13. Februar 2003 18:57
> > An: Struts Users Mailing List
> > Betreff: RE: bean:message problems with i18n
>
> >
> >
> > Have you tried opening up a new browser and trying again?
> > Sounds like it may
> > be a caching issue. Also, check that your <html:html> tag is
> > generating the
> > correct "lang" attribute. Reload the page and view source,
> > then check the
> > HTML tag.
> >
> > -= J
> >
> > > -----Original Message-----
> > > From: Hirschmann, Bernhard
> > [mailto:[EMAIL PROTECTED]]
> > > Sent: Thursday, February 13, 2003 11:41 AM
> > > To: Struts User Mailing List (E-Mail)
> > > Subject: bean:message problems with i18n
> > >
> > > We have big problems with the use of the i18n messages,
> > used with the
> > > bean:message tag. But the problems encounter only in a
> > > special scenario:
> > >
> > > 1.) A German user loggs in -> a German locale is set using
> > > Action.setLocale()
> > >
> > > -> exploring some JSPs, all messages are in German, that's good.
> > >
> > > 2.) The German user loggs out.
> > >
> > > 3.) A English user loggs in -> a English locale is set using
> > > Action.setLocale()
> > >
> > > -> all messages already show in 1.) are still shown in
> > > German. But messages
> > > from other JSPs not visited in 1.) are shown correctly in English.
> > >
> > >
> > > We use two ApplicationResources:
> > > ApplicationResources.properties (the fallback version, in
> > > English language)
> > > ApplicationResources_de.properties (the German variant)
> > >
> > >
> > > It seems to me, that the mechanism using the
> > > ApplicationResources is the
> > > reason, but I'm not sure... I debuged through the sources but
> > > didn't find
> > > the problem.
> > >
> > > Another strange thing is, that this has worked earlier, but
> > > now something
> > > must have happend while our further developing processes, so
> > > that this 'bug'
> > > is appearing. So I tried some older versions of this product
> > > we delivered to
> > > our customers, and suddenly in those versions is this bug
> > > also present.
> > > Maybe something on our application server has happend (WS
> > > 4.0.4), but I have
> > > no clue what this could be... In WSAD 4.0.2 it's the same
> > > like in WS 4.0.4.
> > >
> > > Any hint is highly appretiated. (I'm working on this the
> > > whole day now...)
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
