Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.8.2
    • Fix Version/s: 1.9
    • Component/s: i18n
    • Labels:
      None

      Description

      Bonjour

      I have worked on the ivan coro solution (http://issues.appfuse.org/browse/APF-141)
      to change the locale in code.
      This is an extension of his code to support any locale.

      I attach several files:

      a) LocaleAction.java:
      Save in session the locale set by the user
      and forwards to a page, based on request level
      parameters that are set (language, country, & forward).

      b) LocaleFilter.java:
      Filter to wrap request with a request including user preferred locale.

      c) LocaleRequestWrapper:
      HttpRequestWrapper embedding a request with user preferred locale.

      hope this help
      F

      1. LangSetterForm.java
        0.8 kB
        Francois D
      2. LocaleAction.java
        2 kB
        Francois D
      3. LocaleFilter.java
        2 kB
        Francois D
      4. LocaleRequestWrapper.java
        2 kB
        Francois D

        Activity

        Hide
        Francois D added a comment -

        LocaleAction.java file

        Show
        Francois D added a comment - LocaleAction.java file
        Hide
        Francois D added a comment -

        LocaleFilter.java

        Show
        Francois D added a comment - LocaleFilter.java
        Hide
        Francois D added a comment -

        LocaleRequestWrapper.java

        Show
        Francois D added a comment - LocaleRequestWrapper.java
        Hide
        Francois D added a comment -

        here is an addition in the filter-mappings.xml:
        -------------------------------------------------------

        <!-- locale filter - START -->
        <!-- The filters are invoked in the order in which filter mappings
        appear in the filter mapping list of a WAR.-->
        <filter-mapping>
        <filter-name>localeFilter</filter-name>
        <url-pattern>*.html</url-pattern>
        </filter-mapping>
        <filter-mapping>
        <filter-name>localeFilter</filter-name>
        <url-pattern>*.jsp</url-pattern>
        </filter-mapping>
        <!-- locale filter - END -->

        Show
        Francois D added a comment - here is an addition in the filter-mappings.xml: ------------------------------------------------------- <!-- locale filter - START --> <!-- The filters are invoked in the order in which filter mappings appear in the filter mapping list of a WAR.--> <filter-mapping> <filter-name>localeFilter</filter-name> <url-pattern>*.html</url-pattern> </filter-mapping> <filter-mapping> <filter-name>localeFilter</filter-name> <url-pattern>*.jsp</url-pattern> </filter-mapping> <!-- locale filter - END -->
        Hide
        Francois D added a comment -

        In the class org.appfuse.Constants.java

        please add the lines:
        /**

        • session scope attribute that holds the locale set by the user

        */

        public static final String PREFERRED_LOCALE_KEY = "preferredLocaleKey";

        Show
        Francois D added a comment - In the class org.appfuse.Constants.java please add the lines: /** session scope attribute that holds the locale set by the user */ public static final String PREFERRED_LOCALE_KEY = "preferredLocaleKey";
        Hide
        Francois D added a comment -

        I do not understand why
        but the solution described here worked fine for <fmt:message > tag
        only because in LocaleAction class
        I have put the line:
        Config.set(session, Config.FMT_LOCALE, locale);

        This previous line is not neccessary for the <nuke:label > tag

        I thought that wrapping the request was enough but no ...
        I use appfuse 1.8

        Show
        Francois D added a comment - I do not understand why but the solution described here worked fine for <fmt:message > tag only because in LocaleAction class I have put the line: Config.set(session, Config.FMT_LOCALE, locale); This previous line is not neccessary for the <nuke:label > tag I thought that wrapping the request was enough but no ... I use appfuse 1.8
        Hide
        Francois D added a comment -

        Sorry
        in my last comment
        please replace <nuke:label> tag by <appfuse:label> tag

        Show
        Francois D added a comment - Sorry in my last comment please replace <nuke:label> tag by <appfuse:label> tag
        Hide
        Francois D added a comment -

        ActionForm required by LocaleAction class

        Show
        Francois D added a comment - ActionForm required by LocaleAction class
        Hide
        Francois D added a comment -

        I just attach LangSetterForm.java
        It corresponds to the ActionForm required by LocaleAction class

        Show
        Francois D added a comment - I just attach LangSetterForm.java It corresponds to the ActionForm required by LocaleAction class
        Hide
        Lo Vui Keng added a comment -

        I've adopted APF-142 solution and have a followup on implementation: http://lifeasastruct.blogspot.com/2005/10/preferred-locale-on-appfuse.html. Thank you, Francois and Ivan!

        Show
        Lo Vui Keng added a comment - I've adopted APF-142 solution and have a followup on implementation: http://lifeasastruct.blogspot.com/2005/10/preferred-locale-on-appfuse.html . Thank you, Francois and Ivan!
        Hide
        Matt Raible added a comment -

        Fixed in CVS. Rather than having a form/action to do this - I just put in the Filter. If you pass in locale=fr (or something similar) to any link, the locale will be switched and persisted. If the locale is non-English, a link will show up to switch to English - the title on this link is $

        {webapp.name}

        in English.

        Show
        Matt Raible added a comment - Fixed in CVS. Rather than having a form/action to do this - I just put in the Filter. If you pass in locale=fr (or something similar) to any link, the locale will be switched and persisted. If the locale is non-English, a link will show up to switch to English - the title on this link is $ {webapp.name} in English.
        Hide
        Sanjiv Jivan added a comment -

        There were are few issues with the getLocales() method in the LocaleRequestWrapper class attached in the patch.

        1. It simply adds the users preferred locale to list of locales passed by the browser and this could result in duplicate locales being added to the Enumeration returned by this method.

        2. The significant bug was that the getLocales() method created an enumeration (in a non threadsafe way) and cached it. Subsequent calls to getLocales() returned the cached Enumerator. The problem with returning a cached Enumerator is that after the caller iterates over the Enumeration, its position remains at where the enumeration last stopped. This simple use case illustrates the problem :

        Set the browser language to have the language preferences in the following order zh (chinese), fr, en. Login in and you'll see the content in chinese. Hit the refresh page and you'll notice that some text has been rendered in french. This is because the position of the cached Enumeration has scrolled past the first entry of zh and the web container goes over the remaining values of languages supported by the browser and looks up the french resource bundle.

        Fixed the issue by not caching the Enumerator returned by getLocales()

        Show
        Sanjiv Jivan added a comment - There were are few issues with the getLocales() method in the LocaleRequestWrapper class attached in the patch. 1. It simply adds the users preferred locale to list of locales passed by the browser and this could result in duplicate locales being added to the Enumeration returned by this method. 2. The significant bug was that the getLocales() method created an enumeration (in a non threadsafe way) and cached it. Subsequent calls to getLocales() returned the cached Enumerator. The problem with returning a cached Enumerator is that after the caller iterates over the Enumeration, its position remains at where the enumeration last stopped. This simple use case illustrates the problem : Set the browser language to have the language preferences in the following order zh (chinese), fr, en. Login in and you'll see the content in chinese. Hit the refresh page and you'll notice that some text has been rendered in french. This is because the position of the cached Enumeration has scrolled past the first entry of zh and the web container goes over the remaining values of languages supported by the browser and looks up the french resource bundle. Fixed the issue by not caching the Enumerator returned by getLocales()

          People

          • Assignee:
            Matt Raible
            Reporter:
            Francois D
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: