I18N bug

[tiny]

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.

[tiny]

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 }

[tiny]

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 }

[tiny]

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 }

[tiny]

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.

[sgwood]

I have put this fix into CVS.

Sherman