[ http://issues.apache.org/jira/browse/COCOON-1369?page=comments#action_12454577 ]
Sjur N. Moshagen commented on COCOON-1369:
------------------------------------------
Just to confirm this, the site http://www.risten.no/ is using both LocaleAction and LocaleMatcher, and is experiencing similar and related problems. Content negotiated using LocaleAction is always negotiated properly, whereas content negotiated using LocaleMatcher is not. Here's the sitemap LocaleMatcher config for the site:
<map:matcher name="i18n" src="org.apache.cocoon.matching.LocaleMatcher">
<locale-attribute>locale</locale-attribute>
<negotiate>true</negotiate>
<use-locale>true</use-locale>
<use-locales>true</use-locales>
<use-blank-locale>false</use-blank-locale>
<default-locale language="no" country="NO"/>
<store-in-request>true</store-in-request>
<create-session>true</create-session>
<store-in-session>true</store-in-session>
<store-in-cookie>true</store-in-cookie>
</map:matcher>
If you go to the site mentioned above, the main section of the page (below the tabs) is divided into three frames. The leftmost frame has content negotiated using LocaleAction, the middle frame has its content negotiated using LocaleMatcher (initially only, before one starts searching - the whole site is an interface to a db).
To see the negotiation errors, do the following:
1) open the site
2) depending on the language preferences of your browser, the languages of the left and middle frame might be the same, or they might be different (this is actually another problem (LocaleAction and LocaleMatcher giving different negotiated locale), and is not the point of this comment)
3) switch locale using the language list in the upper, right corner of the web page
4) notice how all text is now switched to the same language
5) switch languages several times, and notice how the middle frame after some switches get "stuck" in a certain language
The way out of the "stucked" situation varies a bit between browsers: with IE/Win the only option is to delete all cookies and cached web pages, with Safari (Mac) it is enough to reload the whole page/frameset (just hit reload). Firefox displays a third behaviour: it is always stuck with the first matched language in the browser's language pref list: given a language list of es,en,fi,nn,no,nb (from most to least preferred language), Firefox is completely stuck with 'en' (the first match), irrespective of the requested locale by other means.
In all browsers, all textual content negotiated with LocaleAction behaves correctly. It is *ONLY* LocaleMatcher that displays the problems discussed above.
Please note that setting @negotiate=false is not an option, as that will return a file-not-found error when the first browser language is not in the set of available languages. That is an even less desirable outcome than getting the wrong language.
> LocaleMatcher does not negotiate propertly
> ------------------------------------------
>
> Key: COCOON-1369
> URL: http://issues.apache.org/jira/browse/COCOON-1369
> Project: Cocoon
> Issue Type: Bug
> Components: * Cocoon Core
> Affects Versions: 2.2-dev (Current SVN)
> Environment: Operating System: Linux
> Platform: PC
> Reporter: Juan Jose Pablos
> Assigned To: Cocoon Developers Team
> Attachments: i18ntest.zip
>
>
> Trying to implement LocaleMatcher for forrest.
> given index.xml and index.es.xml and Accept-Language: es,en;q=0.5
> When the @negotiate=false works as expected the index.es.xml is displayed.
> But when using @negotiate=true index.xml is displayed, which is wrong. It should
> be index.es.xml.
> Added sitemap and files, if you have svn forrest installed it is easier to test:
> mkdir /var/tmp/fs; cd /var/tmp/fs;
> forrest seed;
> cd src/documentation; unzip i18ntest.zip
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira