incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Jaquith (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JSPWIKI-333) language selection/detection doesn't always work
Date Thu, 21 Aug 2008 00:06:46 GMT

    [ https://issues.apache.org/jira/browse/JSPWIKI-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624198#action_12624198
] 

Andrew Jaquith commented on JSPWIKI-333:
----------------------------------------

The easiest thing to do would be to change (or add) an InputValidator constructor that accepts
an additional Locale parameter. This would make it easier to pass in the appropriate Locale,
for example from WikiContext. I don't see any obvious caveats. 

On a side note, InputValidator is (and always was) a hack. It provides the barest minimum
validation needed without doing much more. I plan on giving it a violent death in 3.0 courtesy
of Stripes, which provides a much better validation framework.

Janne and all -- with respect to having the user choose the language, I would like to withdraw
my previous remarks. In 3.0, the way we would integrate with Stripes is pretty simple. Stripes
itself provides a default LocalePicker that tries to figure out the user's language choice
based on their browser settings. The Locale that the LocalePicker picks is included in the
request wrapper, so that callers can simply call HttpServletRequest.getLocale() and be assured
that it is the right one. We could augment this with a subclass that overrides the pickLocale()
method so that we check the Preferences cookie first. We would also override the pickCharacterEncoding()
method so that it always specifies UTF-8, which would get rid of one of our more common issues
on the -user list. The effect of all this is that we could get rid of much of the "proper
logic" in WikiContext, because we'd know the Locale would always be right. :) 


> language selection/detection doesn't always work
> ------------------------------------------------
>
>                 Key: JSPWIKI-333
>                 URL: https://issues.apache.org/jira/browse/JSPWIKI-333
>             Project: JSPWiki
>          Issue Type: Bug
>    Affects Versions: 2.7.x
>            Reporter: Florian Holeczek
>             Fix For: 2.8
>
>
> JSPWiki doesn't always detect the preferred language from the browser. The intended behaviour
is that if there is no user-pref cookie, the language setting *should* follow the language
of the browser.
> This is a collection of facts from several mails on the list.
> Florian reports:
> {quote}
> I've got a personal wiki installed on Tomcat 6, which runs without this problem. This
installation (v2.7.0-alpha-9) has been upgraded successively from 2.6.
> I've deployed the JSPWiki v2.7.0-alpha-9 on a Glassfish 2ur2 server and get English as
the default language for a not yet configured browser (without JSPWiki cookies), although
it is set to select de-de as primary language. It's the same with Firefox 3 and IE 7.
> However, switching to german language in the user preferences works.
> {quote}
> Janne reports:
> {quote}
> Yup, just checked.  It works on 2.6.3, but not on any 2.8 alpha releases.
> {quote}
> Harry reports:
> {quote}
> I tested against v2.7.0-svn-44   <http://zwiki.rabobank.nl/rss.rdf>, it doesn't
work there.
> I checked the source of the latest version, could not find anything reading the Language
header, just reading the cookie contents (mainly Preferences class).
> Some additional testing (all with FF3 on XP) confirm the same results as Janne :
> v2.7.0-svn-44 ==> doesn't work
> v2.7.0-alpha-9 ==> doesn't work
> 2.6.3-rc-2 ==> works
> {quote}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message