Bug 1031080 - Texts are displayed in the OS system language when the "English locale is selected"
Texts are displayed in the OS system language when the "English locale is sel...
Product: JBoss BPMS Platform 6
Classification: JBoss
Component: BAM (Show other bugs)
x86_64 Linux
medium Severity medium
: ER6
: 6.0.0
Assigned To: Roger Martínez
Ivo Bek
Depends On:
  Show dependency treegraph
Reported: 2013-11-15 10:02 EST by David Gutierrez
Modified: 2014-08-06 16:09 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-08-06 16:09:24 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Some texts not in English (195.89 KB, image/png)
2013-11-15 10:02 EST, David Gutierrez
no flags Details

  None (edit)
Description David Gutierrez 2013-11-15 10:02:27 EST
Created attachment 824575 [details]
Some texts not in English

Description of problem:

Installation of dashuilder in a non-english OS (JVM default locale non-english). The OS language must be one of the languages supported  by dashbuilder i.e:

Spanish (es)
German (de)
French (fr)
Chinese (zh)
Japanese (ja)
Portuguese (pt)

Once logged into the UI if the user selected the "English" language from the language selector menu some texts are displayed in the OS system language and not in English. For instance, Showcase>Administration>Data providers.

Version-Release number of selected component (if applicable):

How reproducible:


Steps to Reproduce:
1. Install on a host with a non-english supported language (or change the JVM default locale)
2. Do login as admin, select the English language.
3. Go to Showcase>Administration>Data providers.

Actual results:

Some texts displayed in the default OS language not in English.

Expected results:

All the texts displayed in English.

Additional info:
Comment 2 David Gutierrez 2013-11-15 12:43:58 EST
This issue is caused because the app's resource bundles in English are the default ones (with no language prefix: messages.properties). 

One work-around to deal with this is to set the JVM default locale to English  before running the app. In fact, we think this is the best approach since the app assumes English is set as the default.
Comment 3 Roger Martínez 2013-11-21 13:54:31 EST
We have found the cause and a possible solution:


- The default Oracle JVM ResourceBundle class implementation for the method getBundle(...) is based on:
   1.- Obtain the bundle using the locale argument
   2.- If the bundle for the locale argument does not exist, use the fallback bundle. In both JDK 6/7 the default fallback bundle is obtained using the default JVM locale.
   3.- If the bundle for default jvm locale is not found, use the global one.

- In the whole dashbuilder module there is no bundles for "en" region (the global ones are the english ones). 

-> So, if you run the dashbuilder web application using the Spanish locale and change it using the UI (language combo selector) to English, as the resource bundle for "en" is not found and by the other hand the resource bundle for default jvm locale ("ES") is found, the returned language will be Spanish.

-> This error only happens to static bundles (existing properties files in the module). For all dynamic texts introduced by the user or by the pre-installed workspaces it works fine, as they are not resource bundles, are database field. This is the reason why some texts are in english and some in spanish when reproducing this issue.


Change the behavior of the fallback bundle for ResourceBundle class implementation. For more information see http://docs.oracle.com/javase/6/docs/api/java/util/ResourceBundle.Control.html.

The idea is to encapsulate all dashbuilder module calls to ResourceBundle methods into the org.jboss.dashboard.LocaleManager class. Then, delegate to the JDK ResourceBundle but using a different ResourceBundle.Control implementation. The impl to use is ResourceBundle.NoFallbackControl.

This is the first approach, so the solution details are not commented yet.
Comment 4 Roger Martínez 2013-11-22 13:19:56 EST

The solution has been to encapsulate all calls to ResourceBundle#getBundle method into a new method in org.jboss.dashboard.LocaleManager#getBundle. This encapsulation uses a NoFallbackControl implementation for ResourceBundle.Control instance.

For jsp files, a new custom i18n tag class has been created to encapsulate the same logic.

Commits on master

- https://github.com/droolsjbpm/dashboard-builder/commit/24206ff35f6f0c45d2baf7dde23f6ae9e9864711
- https://github.com/droolsjbpm/jbpm-dashboard/commit/9477b6b145b2962cc5dd4556a8a50f3392fc9e80

Commits on 6.0.x

- https://github.com/droolsjbpm/dashboard-builder/commit/b9d98659e9d793b03faf4a964e945bf1ec85aaee
- https://github.com/droolsjbpm/jbpm-dashboard/commit/c38bed5a765974cc8a20f338938ff4c6d4b3b61c
Comment 5 Marek Baluch 2014-01-13 05:05:13 EST
Uuuups - wrong field.
Comment 6 Ivo Bek 2014-01-14 05:37:29 EST
Reproduced on Spanish OS (Fedora 20) and BPMS 6.0.0.ER5
Verified on Spanish OS (Fedora 20) and BPMS 6.0.0.ER7

Note You need to log in before you can comment on or make changes to this bug.