Locale feature is unsatisfactory

• Key: STR-2128
• Type: Improvement
• Status: Open
• Priority: Minor
• Assignee: Unassigned
• Reporter: ron piterman
• Component/s: Core
• Affects Version/s: 1.1 RC2
• Fix Version/s: 1.4.x

Environment

Operating System: other
Platform: All

Description

Hi,
Currently, Struts uses the requests default locale.
This is so unsatisfactory it should be a bug.
I have never seen a serious commercial web application which gives different
locale-responses to different locale-clients.
The Locale is *always* based on the URL.
It would be therefore great if a local look-up would be supplied.
Thanx,
Ron

Comments

[Niall Pemberton]

I think you're mistaken on this.

Firstly Struts stores the locale in the user's session. The default
configuration is that it picks this up from the Request it there isn't already
one in the session and it has been set in the Request. However you can change
the configuration of Struts so that it doesn't do this at all by setting
the "locale=false" on the <controller> element in the struts-config.xml.

If you want your own custom locale look-up processing implementation then the
best way would be to override the processLocale() method in the
RequestProcessor. If you want Struts to be changed to work differently maybe
you could elaborate more specifically how the locale look-up should work -
example code would be good.

Niall

[ron piterman]

If you turn the "locale" to false, no locale tracking is made on the session,
meaning struts will get the locale from each query.
So if I change my browser to German, struts looks for german resources, does not
find them and I'm in trouble :(

The hook:

interface LocaleSupplier {
  public Locale getLocale(HttpServletRequest request);
}

class DefaultLocaleSupplier implements LocaleSupplier {
  public Locale getLocale(HttpServletRequest request) {
    Locale l = getlocaleFromSession(request);
    if (l == null)
       l = getLocaleFromURL(request);
    if (l == null)
       l = getLocaleFromApplication(request);
    if (l == 0)
       l = getLocaleFromSystem(request);
     return l;
   }

add to servlet configuration an optional parameter:
    <init-param>
      <param-name>locale-supplier</param-name>
      <param-value>full.qualified.class.Name</param-value>
    </init-param>

This has the advantages the locale has a decent default behaiviour :

in apache I could map mysite.com, mysite.de, mysite.nl, mysite.it all to the
same tomcat application. the getLocaleFromURL will check the domain name and
give back the correct locale.
One could also implement the getLocaleFromURL so that it functions in another
way, thus uses subdomains:

www.mysite.com,
de.mysite.com,
nl.mysite.com

or

www.mysite.com/en/
www.mysite.com/de/
www.mysite.com/nl/

These are all possible locale parsing methods.

Since the LocaleSupplier also checks the session, if the site-developer want to
give the user the option to change the locale, he just needs to save the locale
in the session - it will "override" the default one comming from the url.

How do you find this?

[Ted Husted]

Last time I looked, Struts did not obtain the locale from the browser. It
starts with the default locale of the server. After that, it must be changed
programatically to one of the locales that the individual application
supports. What's set on the browser shouldn't have anything to do with it.

-Ted.

[ron piterman]

First I did not look at the source, I just changed my browser to german - so all
resources disapeared :(
Now to the source code:

in util.RequestUtils.getLocale (static) the request Locale is being read.
in validatorResources.getLocale (static) the context locale is being read.
which one is used when?
which one is wrong?
does it mutter?
the fact is, you give a default behaiviour instead of enabling some plugins...
Why not plug some interface which does that?
The problem is also, Locale handling is not specified good enough - a note or an
Howto on that would be needed.
This is a very common feature, and struts does it abit strange...
cheers,
Ron

[ron piterman]

sorry - its the other way around with validator and util packages...

[Niall Pemberton]

Firstly I'm changing this to enhancement because Struts is working as designed
and therefore its not a bug.

I think your suggestion is good except for configuring it through the serlvet
<init-param> - its would be more in keeping with struts to configure it though
the <controller> element in the struts-config.xml.

Having said that this is exactly the kind of behaviour provided in struts-chain
(in the contrib area) and I believe that other committers are planning to move
to a "ComposableRequestProcessor" based on that for the next Struts version. At
the moment I personally wouldn't apply a patch to do your change until the
decision on that has been taken.

If you look at struts-chain:

http://cvs.apache.org/viewcvs.cgi/jakarta-struts/contrib/struts-
chain/src/java/org/apache/struts/chain/

The AbstractSelectLocale class is pretty much what you are proposing with
LocaleSupplier.

Niall

[Paul Benedict]

Why is LocaleAction a final class? It contains some functionality I would like
to extend.