Hei Craig,
yes!
but there is always a best guess for example GB2312 for zh.
And exactly that could be done by app logic if the contentType would be in
the session.
I wrote a little tag (not scriptlet) that exactly that does.
My hole point is that placing the contentType in the session would allow a
per user handling in the logic not the presentation.
My guess is that the oneLocale-oneContentType will be the 90% case and in
the other cases you still have the possibilities described or use UTF-8.
So I still think it is a suggestion but I can live with out it.
Thanxs for the quick response
Best regards
Georg
-----Ursprüngliche Nachricht-----
Von: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Gesendet: Dienstag, 9. Januar 2001 20:58
An: [EMAIL PROTECTED]
Betreff: Re: Inconsistent Localization behavior
"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
