Bug 752239

Summary: at runtime, coregui.war should default to the "en" locale, not the "default" locale
Product: [Other] RHQ Project Reporter: Ian Springer <ian.springer>
Component: Core UIAssignee: Charles Crouch <ccrouch>
Status: CLOSED CURRENTRELEASE QA Contact: Mike Foley <mfoley>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.2CC: ccrouch, hbrock, hrupp
Target Milestone: ---   
Target Release: RHQ 4.3.0   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: 4.3 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-08-31 06:12:04 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 745494    

Description Ian Springer 2011-11-08 17:13:35 EST
We need to explicitly default to the "en" locale as described here:


That is, we need to add the following line to the <head> section of CoreGUI.html:

<meta name="gwt:property" content="locale=en">

This is important, because otherwise the locale will default to the "default" locale, which is best avoided. From http://code.google.com/webtoolkit/doc/latest/DevGuideI18nLocale.html#LocaleDefault:

In general, you should avoid running the app in the default locale — many things will produce surprising results. For example, only a small set of currencies will be supported, resulting in errors for applications that make use of other currencies, and no plural forms will be supported (since the language isn't known). If you really want to allow the application to continue running when the user requests an unsupported locale, you are probably better off choosing some real language as a default, such as en. You can set what value is used for the default by including the following in your module XML:

<set-property-fallback name="locale" value="en"/>

So we should add this as well, so that if a user tries adding ?locale=xy to the coregui URL, where xy is an unsupported locale, we will fallback to "en", rather than "default".
Comment 1 Ian Springer 2011-11-09 11:21:33 EST
[master 06ec3b2]:

1) at runtime, default to the "en" locale, not the "default" locale
2) use "en", rather than "default", as the fallback locale (i.e. the locale to fallback to if the user specifies an unsupported locale in the query string
Comment 2 Ian Springer 2011-11-10 13:43:00 EST
QE, test 1) and 2) as follows:

1) just go to the GUI and make sure everything still works and that all messages are English

2) go to http://localhost:7080/coregui/?locale=xy

and verify that the GUI comes up as usual and all messages are in English
Comment 3 Mike Foley 2011-11-10 14:28:56 EST
verified jon 3 branch 11/10/2011
Comment 4 Ian Springer 2011-11-10 15:16:02 EST
This fix only went in to master, so master should be verified, rather than the jon3 branch.
Comment 5 Mike Foley 2011-11-10 16:02:46 EST
what was broken then?  it works just fine in jon 3.0 branch? apparently without the fix....
Comment 6 Mike Foley 2011-11-10 16:04:41 EST
reducing the priority as it is not related to jon 3
Comment 7 Mike Foley 2011-11-10 16:05:33 EST
editing the target release to remove jon 3 from the target release (per comment #4)
Comment 8 Ian Springer 2011-11-10 16:56:26 EST
Nothing was broken per se. As described by the GWT docs link I included in this bug's description, if you use the "default" locale (what we were previously doing), it is not the same as using the "en" locale - numbers, dates, and currencies will not be formatted properly for English, and message pluralization will not work.

I know we had issues with pluralization not working when we first began internationalizing the GUI - this was probably why. I don't know if we currently had any issues due to using the "default" locale, but rather than wait for issues to arise, I decided to preemptively switch to the "en" locale, particularly since the GWT docs specifically recommend this.

QA for this is essentially making sure there are no regressions from the change (I don't expect any).
Comment 9 Mike Foley 2011-11-11 10:35:38 EST
verified master 11/11/2011
Comment 12 Heiko W. Rupp 2013-08-31 06:12:04 EDT
Bulk close of old bugs in VERIFIED state.