javaserverfaces-spec-public
  1. javaserverfaces-spec-public
  2. JAVASERVERFACES_SPEC_PUBLIC-1065

ResourceManager only checks the Accept-Language to localize resources

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.2
    • Component/s: Lifecycle
    • Labels:
      None

      Description

      Copied from <http://java.net/jira/browse/JAVASERVERFACES-1858>.

      Now, it's not possible to programatically change the locale of resources like we
      do with bundles of messages.

      Now, we have to define an entry for javax.faces.resource.localePrefix at
      localized files referred at faces-config.xml by a <message-bundle> tag.

      Studying the code, I found the ResourceManager class
      (com.sun.faces.application.resources). This class has a method called
      getLocalePrefix(FacesContext) which finds the localized value for
      javax.faces.resource.localePrefix.

      The problem is that ResourceManager doesn't work like UIViewRoot which stores
      the locale supplied by the user. It just call
      context.getApplication().getViewHandler().calculateLocale(FacesContext);

      This last method calls the context.getExternalContext().getRequestLocale(). In
      other words, the ResourceManager only checks the HTTP header Accept-Language to
      reach the resources.

      The UIViewRoot, in other hand, has the method setLocale() to store the locale
      picked by the user.

      So I made changes inside the ResourceManager.getLocalePrefix(FacesContext) to
      call the UIViewRoot.getLocale() when there is a viewroot (it was necessary to
      fix the "loc" http parameter), and to just return the "loc" parameter when there
      is one (at the second request for the resource itself).

      That's the new method's body:

      private String getLocalePrefix(FacesContext context) {

      String localePrefix = null;
      String appBundleName = context.getApplication().getMessageBundle();
      if (null != appBundleName) {

      /** ******** **

      NEW CODE **

                    • **/
                      if (context.getExternalContext().getRequestParameterMap().get("loc") !=
                      null) { return context.getExternalContext().getRequestParameterMap().get("loc"); }

                      Locale locale = null;
                      if (context.getViewRoot() != null)

                      { locale = context.getViewRoot().getLocale(); }

                      else

                      { locale = context.getApplication().getViewHandler().calculateLocale(context); }

                      /** ************ **
                      END NEW CODE **

                            • **/
                              try { ResourceBundle appBundle = ResourceBundle.getBundle(appBundleName, locale, Util.getCurrentLoader(ResourceManager.class)); localePrefix = appBundle .getString(ResourceHandler.LOCALE_PREFIX); }

                              catch (MissingResourceException ignored) { }
                              }

      return localePrefix;

      }

      For me, the i18n capabilities is fully ok, now.

      If any developer wants to make a form to give the user a chance to choose one
      locale, the message and now the resources will be translated.

        Issue Links

          Activity

          Hide
          Ed Burns added a comment -

          Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ResourceManager.java
          Transmitting file data .
          Committed revision 9612.

          Show
          Ed Burns added a comment - Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ResourceManager.java Transmitting file data . Committed revision 9612.
          Hide
          Manfred Riem added a comment -

          Closing resolved issue out

          Show
          Manfred Riem added a comment - Closing resolved issue out

            People

            • Assignee:
              Ed Burns
              Reporter:
              Ed Burns
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 2 days
                2d
                Remaining:
                Remaining Estimate - 2 days
                2d
                Logged:
                Time Spent - Not Specified
                Not Specified