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.HttpServletRequ 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]
AW: bean:message problems with i18n
Hi Tobby,
I guess you're right.
I'm working on a bug in our application and was also on exactly the same
method:
Action.getLocale(request);
Sometimes I get the right locale, sometimes not.
Maybe it has something to do with a change in the struts sources:
The constant Globals.LOCALE_KEY has once been Actions.LOCALE_KEY, I
could imagine that something is mixed up now because of this. Is that
possible?
Ted, Craig? :-)
Regards,
Bernhard
-Ursprüngliche Nachricht-
Von: Rademacher Tobias [mailto:[EMAIL PROTECTED]]
Gesendet: Freitag, 14. Februar 2003 13:42
An: Hirschmann, Bernhard; 'Struts Users Mailing List'; Rademacher Tobias
Betreff: RE: bean:message problems with i18n
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
AW: bean:message problems with i18n
I forgot: we use the struts version 1.1b3 -Ursprüngliche Nachricht- Von: Hirschmann, Bernhard Gesendet: Donnerstag, 13. Februar 2003 18:41 An: Struts User Mailing List (E-Mail) Betreff: 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...) Regards, Bernhard - 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]
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]
AW: bean:message problems with i18n
Hello all! this is still an open thread for me. It's horrifying... Any help highly appreciated! Regards, Bernhard -Ursprüngliche Nachricht- Von: Hirschmann, Bernhard Gesendet: Donnerstag, 13. Februar 2003 19:15 An: 'Struts Users Mailing List' Betreff: 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]
