Inconsistent Localization behavior

["Lenz, Georg" <ge...@sap.com>]

Hei,

I think the localization behavior of struts is a little bit inconsistent. 
On the one hand you might have a locale per user/session 
that defines the locale for the user very conveniently using the Accept-** 
header info about the client. 
On the other side the content Type is handled on the application level 
by setting content Type in the web.xml file. But the content Type depends 
on the local of the user.
So my suggestion would be to move content Type to the session and leave 
it to the user to implement a relation between locale and content Type or 
keep the App default. 
That would be win-win solution.


Best regards
Georg Lenz

Re: Inconsistent Localization behavior

["Craig R. McClanahan" <Cr...@eng.sun.com>]

"Lenz, Georg" wrote:

> Hei,
>
> I think the localization behavior of struts is a little bit inconsistent.
> On the one hand you might have a locale per user/session
> that defines the locale for the user very conveniently using the Accept-**
> header info about the client.
> On the other side the content Type is handled on the application level
> by setting content Type in the web.xml file. But the content Type depends
> on the local of the user.

Technically, only the *characer encoding* portion of the content type is
dependent on the user's Locale, and then only when you need a character set
other than the default (ISO-8859-1).

The "text/html" part of the content type (if you are generating HTML pages) is
the same for all users, no matter what Locale they are in.

>
> So my suggestion would be to move content Type to the session and leave
> it to the user to implement a relation between locale and content Type or
> keep the App default.
> That would be win-win solution.
>

In a typical Struts application, the content type actually gets set by the JSP
page that you ultimately forward to, not by the controller servlet or your
application's Action.  It is based on what you specify in the <%@ page %>
directive:

    <%@ page ... contentType="text/html;charset=EUC-KR" ... %>

As you can see from the example above, the value is a constant string, specified
when the page is compiled.

It would be possible to write a scriptlet (or custom tag) to modify the
generated content type dynamically at runtime, but what character encoding
should be used?  It is not obvious from the contents of a java.util.Locale --
and there are some scenarios where several different character encodings might
be appropriate for the same Locale.

>
> Best regards
> Georg Lenz

Craig McClanahan