ICEfaces
  1. ICEfaces
  2. ICE-1505

SelectInputDate: inconsistent week-start localization rendering in fr-CA locale

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.6DR#3
    • Fix Version/s: 1.7DR#3, 1.7
    • Component/s: ICE-Components
    • Labels:
      None
    • Environment:
      any

      Description

       
      forum user wrote:
      I use selectInputDate. No popup. When I put my locale to, for instance, fr-CA, the months and days are in french. But the first day of the week is "lun." (mon.). It should be "dim" (sun.)

      The thing is, if I click on the right or left arrow to change the month, the order of the days change automatically and "dim." appears suddenly to be the first day of the week! During the rest of the session, the calendars are from now on correctly set to the locale, the order of the days is correct. If I logout and relog, the same strange behavior appears.

        Issue Links

          Activity

          Hide
          Mandeep Hayher added a comment -

          Following behaviour seen with Icefaces1.6.2:
          When the page is loaded the first time the week starts with"dim" but when some date in the current month is selected the starting day of the week changes to "lun".

          Show
          Mandeep Hayher added a comment - Following behaviour seen with Icefaces1.6.2: When the page is loaded the first time the week starts with"dim" but when some date in the current month is selected the starting day of the week changes to "lun".
          Hide
          Mark Collette added a comment -

          Duplicated by using JSP + JSF 1.2 + trunk ICEfaces (post 1.7 DR2) on JBoss 4.2.1. My web browser was configured to send "fr-FR,fr;q=0.9,en-us;q=0.7,en;q=0.6,fr-fr;q=0.4" as my Accept-Language request header, and my faces-config.xml had:

          <locale-config>
          <default-locale>fr_CA</default-locale>
          <supported-locale>fr_CA</supported-locale>
          </locale-config>

          What happens is that when the UIViewRoot does not have a specific Locale set in it, UIViewRoot.getLocale() delegates to ViewHandler.calculateLocale(FacesContext) for selecting the Locale, based on the faces-config.xml's locale-config section, and the web browser's Accept-Language request header.

          On the initial page load, calculateLocale will select one of the latter locales specified in the Accept-Language request header, which has higher precedence in the faces-config.xml's locale-config section's list of supported-locale entries. On the post-pack, from the first Ajax interaction, the JSF RI 1.2 code in com.sun.faces.lifecycle.RestoreViewPhase.execute(FacesContext) will simply grab the first locale in the Accept-Language request header, and set that in the UIViewRoot. This locale may have a different starting day of the week, or any other number of differences from the previously used locale. In my tests, it was going from fr-CA to fr-FR that exhibited that difference. My browser was configured to prefer fr-FR, and calculateLocale saw that fr-CA was the most compatible supported-locale. But on the second lifecycle it just stomped fr-FR in, regardless of the configured supported-locale entries.

          That code path in RestoreViewPhase.execute only happens with ICEfaces + JSP + JSF 1.2, because we keep our component tree, instead of rebuilding it each lifecycle. So, in theory we could change that, but it would be quite an undertaking.

          The simplest solution is for the user to simply add a <supported-locale>fr_FR</supported-locale> entry to their faces-confg.xml, so that French users from France will get that locale on their first lifecycle, and when it stomps fr-FR into the UIViewRoot, they'll just be continuing to use the same locale.

          But, to take the burden off of developers, what might be a more elegant approach, would be to render out the UIViewRoot's current locale, and have the bridge code in the browser set that as the first locale in its Accept-Language request header, so that it will always be specifying to continue using whatever locale the server has just served out.

          Show
          Mark Collette added a comment - Duplicated by using JSP + JSF 1.2 + trunk ICEfaces (post 1.7 DR2) on JBoss 4.2.1. My web browser was configured to send "fr-FR,fr;q=0.9,en-us;q=0.7,en;q=0.6,fr-fr;q=0.4" as my Accept-Language request header, and my faces-config.xml had: <locale-config> <default-locale>fr_CA</default-locale> <supported-locale>fr_CA</supported-locale> </locale-config> What happens is that when the UIViewRoot does not have a specific Locale set in it, UIViewRoot.getLocale() delegates to ViewHandler.calculateLocale(FacesContext) for selecting the Locale, based on the faces-config.xml's locale-config section, and the web browser's Accept-Language request header. On the initial page load, calculateLocale will select one of the latter locales specified in the Accept-Language request header, which has higher precedence in the faces-config.xml's locale-config section's list of supported-locale entries. On the post-pack, from the first Ajax interaction, the JSF RI 1.2 code in com.sun.faces.lifecycle.RestoreViewPhase.execute(FacesContext) will simply grab the first locale in the Accept-Language request header, and set that in the UIViewRoot. This locale may have a different starting day of the week, or any other number of differences from the previously used locale. In my tests, it was going from fr-CA to fr-FR that exhibited that difference. My browser was configured to prefer fr-FR, and calculateLocale saw that fr-CA was the most compatible supported-locale. But on the second lifecycle it just stomped fr-FR in, regardless of the configured supported-locale entries. That code path in RestoreViewPhase.execute only happens with ICEfaces + JSP + JSF 1.2, because we keep our component tree, instead of rebuilding it each lifecycle. So, in theory we could change that, but it would be quite an undertaking. The simplest solution is for the user to simply add a <supported-locale>fr_FR</supported-locale> entry to their faces-confg.xml, so that French users from France will get that locale on their first lifecycle, and when it stomps fr-FR into the UIViewRoot, they'll just be continuing to use the same locale. But, to take the burden off of developers, what might be a more elegant approach, would be to render out the UIViewRoot's current locale, and have the bridge code in the browser set that as the first locale in its Accept-Language request header, so that it will always be specifying to continue using whatever locale the server has just served out.
          Hide
          Philip Breau added a comment -

          a somewhat related jira is ICE-2419 (Locale reverts when dynamically set)

          Show
          Philip Breau added a comment - a somewhat related jira is ICE-2419 (Locale reverts when dynamically set)
          Hide
          Mark Collette added a comment -

          I made Jira ICE-2485, but Mircea found a simpler way of addressing it there. I probably should have committed this change under that Jira - oh well.

          Subversion 15471
          icefaces\core\src\com\icesoft\faces\application\D2DViewHandler.java

          Show
          Mark Collette added a comment - I made Jira ICE-2485 , but Mircea found a simpler way of addressing it there. I probably should have committed this change under that Jira - oh well. Subversion 15471 icefaces\core\src\com\icesoft\faces\application\D2DViewHandler.java
          Hide
          Mark Collette added a comment -

          Removed the Java 1.5 dependency, and removed the redundant call to UIViewRoot.setLocale(Locale) in D2DViewHandler.createView.

          Subversion 15483
          icefaces\core\src\com\icesoft\faces\application\D2DViewHandler.java

          Show
          Mark Collette added a comment - Removed the Java 1.5 dependency, and removed the redundant call to UIViewRoot.setLocale(Locale) in D2DViewHandler.createView . Subversion 15483 icefaces\core\src\com\icesoft\faces\application\D2DViewHandler.java

            People

            • Assignee:
              Unassigned
              Reporter:
              Philip Breau
            • Votes:
              1 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: