5 Replies Latest reply on Apr 6, 2004 6:17 AM by Sherman Wood

    I18N bug

    tiny Newbie

      The following code in nukes/src/main/org/jboss/nukes/core/modules/core/CoreModule.java
      do not work properly if the client's first preference is US locale and second preference is another locale and the server support both locale. In the described scenario, the server will choose the second preference instead of Locale.US.


      377 // If nothing is right we will endup with en_US locale.
      378 Locale preferedLocale = Locale.US;
      379 for (Enumeration e = req.getLocales();e.hasMoreElements();)
      380 {
      381 Locale requestedLocale = (Locale)e.nextElement();
      382 ResourceBundle requestedResourceBundle = getResourceBundle(requestedLocale);
      383
      384 // It returns Locale.US if tmpLocale is not supported
      385 if (!requestedResourceBundle.getLocale().equals(Locale.US))
      386 {
      387 preferedLocale = requestedLocale;
      388 break;
      389 }
      390 }


      To fix this problem of discriminating US locale, we can add the following codes before the line 385

      if (requestedResourceBundle.getLocale().equals(requestedLocale))
      {
      preferedLocale = requestedLocale;
      break;
      }

      Can some one fix this problem in CVS so that nukes will properly handle US locale as first preference.

        • 1. Re: I18N bug
          tiny Newbie

          There is another problem, according to java API, the resource bundle is is loaded in following order (language1, country1 is the specified locale; language2 and country 2 is the default locale of the Java Virtual Machine).


          baseName + "_" + language1 + "_" + country1 + "_" + variant1
          baseName + "_" + language1 + "_" + country1
          baseName + "_" + language1
          baseName + "_" + language2 + "_" + country2 + "_" + variant2
          baseName + "_" + language2 + "_" + country2
          baseName + "_" + language2
          baseName


          If the JVM is running with chinese locale and there is a resource for chinese locale.
          If the client's first preference is not supported by server, no matter how the client specifies the other preference, the chinese locale is always selected by the original code. To fix this problem, we should change the code to


          377 // If nothing is right we will endup with en_US locale.
          378 Locale preferedLocale = Locale.US;
          379 for (Enumeration e = req.getLocales();e.hasMoreElements();)
          380 {
          381 Locale requestedLocale = (Locale)e.nextElement();
          382 ResourceBundle requestedResourceBundle = getResourceBundl 383
          384 // If there is an exact match, return it
          385 if (requestedResourceBundle.getLocale().equals(requestedL 386 {
          387 preferedLocale = requestLocale;
          388 break;
          389 }
          390 // Ensure we do not return the bundle for default locale
          391 // when mismatch occur
          392 if (requestedResourceBundle.getLocale().equals(Locale.get 393 {
          394 continue;
          395 }
          396 // It returns Locale.US if tmpLocale is not supported
          397 if (!requestedResourceBundle.getLocale().equals(Locale.US 398 {
          399 preferedLocale = requestedLocale;
          400 break;
          401 }

          • 2. Re: I18N bug
            tiny Newbie

            Code in previous post was incomplete, here is the complete one.

            377 // If nothing is right we will endup with en_US locale.
            378 Locale preferedLocale = Locale.US;
            379 for (Enumeration e = req.getLocales();e.hasMoreElements();)
            380 {
            381 Locale requestedLocale = (Locale)e.nextElement();
            382 ResourceBundle requestedResourceBundle = getResourceBundl e(requestedLocale);
            383
            384 // If there is an exact match, return it
            385 if (requestedResourceBundle.getLocale().equals(requestedL ocale))
            386 {
            387 preferedLocale = requestLocale;
            388 break;
            389 }
            390 // Ensure we do not return the bundle for default locale
            of JVM
            391 // when mismatch occur
            392 if (requestedResourceBundle.getLocale().equals(Locale.get Default()))
            393 {
            394 continue;
            395 }
            396 // It returns Locale.US if tmpLocale is not supported
            397 if (!requestedResourceBundle.getLocale().equals(Locale.US ))
            398 {
            399 preferedLocale = requestedLocale;
            400 break;
            401 }

            • 3. Re: I18N bug
              tiny Newbie

              Sorry the proposed fix still has subtle bugs.

              What we really want is the following order of lookup resource bundles


              baseName+"_"+language1+"_"+country1+"_"+variant1
              baseName+"_"+language1+"_"+country1
              baseName+"_"+language1
              baseName+"_"+language2+"_"+country2+"_"+variant2
              baseName+"_"+language2+"_"+country2
              baseName+"_"+language2
              ....
              baseName+"_"+defaultLanguage+"_"+defaultCountry+"_"+defualtVariant
              baseName+"_"+defaultLanguage+"_"+defaultCountry
              baseName+"_"+defaultLanguage


              Where language1,country1,variant1 is the first prefered locale;
              language2,country2,variant2 is the second prefered locale; ....
              when no prefered locale is supported by the server we use a designated default locale. (We can not use the default locale of JVM, which is JVM specific. The current approach is to handed code it to be en_US, which works fine).
              The following code will correctly implement the above order of searching.


              377 // If nothing is right we will endup with en_US locale.
              378 Locale preferedLocale = Locale.US;
              379 for (Enumeration e = req.getLocales();e.hasMoreElements();)
              380 {
              381 Locale requestedLocale = (Locale)e.nextElement();
              382 String requestedLanguage = requestLocale.getLanguage();
              383 ResourceBundle requestedResourceBundle = bundles.get(locale);
              384 if (requestedResourceBundle != null)
              385 {
              386 Locale actualLocale = requestedResourceBundle.getLocale();
              387 String actualLanguage = actualLocale.getLanguage();
              388 if (actualLanguage.equals(requestedLanguage)) {
              389 preferedLocale = requestedLocale;
              390 break;
              391 }
              392 }
              393 }

              • 4. Re: I18N bug
                tiny Newbie

                The updated class can be found here
                CoreModule.java.

                You can apply the following patch to the old version to fix the bug
                CoreModule.java.patch


                patch CoreModule.java < CoreModule.java.patch



                Hope someone with write access to CVS can fix the bug as soon as possible.

                • 5. Re: I18N bug
                  Sherman Wood Apprentice


                  I have put this fix into CVS.

                  Sherman