Cocoon
  1. Cocoon
  2. COCOON-1369

LocaleMatcher does not negotiate propertly

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.2
    • Fix Version/s: None
    • Component/s: * Cocoon Core
    • Labels:
      None
    • Environment:
      Operating System: Linux
      Platform: PC

      Description

      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

        Activity

        Juan Jose Pablos created issue -
        Hide
        Juan Jose Pablos added a comment -
        Created an attachment (id=13668)
        Sitemap and files for a seeded forrest project
        Show
        Juan Jose Pablos added a comment - Created an attachment (id=13668) Sitemap and files for a seeded forrest project
        Jeff Turner made changes -
        Field Original Value New Value
        issue.field.bugzillaimportkey 32560 12324678
        Pier Fumagalli made changes -
        Workflow jira [ 12341113 ] Cocoon Workflow [ 12341515 ]
        Hide
        Sjur N. Moshagen added a comment -
        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.
        Show
        Sjur N. Moshagen added a comment - 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.
        Mark Thomas made changes -
        Assignee Cocoon Developers Team [ cocoon ]

          People

          • Assignee:
            Unassigned
            Reporter:
            Juan Jose Pablos
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development