Bug 752239 - at runtime, coregui.war should default to the "en" locale, not the "default" locale
Summary: at runtime, coregui.war should default to the "en" locale, not the "default" ...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: RHQ Project
Classification: Other
Component: Core UI
Version: 4.2
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: RHQ 4.3.0
Assignee: Charles Crouch
QA Contact: Mike Foley
URL:
Whiteboard:
Depends On:
Blocks: jon30-sprint8
TreeView+ depends on / blocked
 
Reported: 2011-11-08 22:13 UTC by Ian Springer
Modified: 2015-02-01 23:27 UTC (History)
3 users (show)

Fixed In Version: 4.3
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-08-31 10:12:04 UTC
Embargoed:


Attachments (Terms of Use)

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

http://code.google.com/webtoolkit/doc/latest/DevGuideI18nLocale.html#LocaleSpecifying

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 16:21:33 UTC
[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 18:43:00 UTC
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 19:28:56 UTC
verified jon 3 branch 11/10/2011

Comment 4 Ian Springer 2011-11-10 20:16:02 UTC
This fix only went in to master, so master should be verified, rather than the jon3 branch.

Comment 5 Mike Foley 2011-11-10 21:02:46 UTC
what was broken then?  it works just fine in jon 3.0 branch? apparently without the fix....

Comment 6 Mike Foley 2011-11-10 21:04:41 UTC
reducing the priority as it is not related to jon 3

Comment 7 Mike Foley 2011-11-10 21:05:33 UTC
editing the target release to remove jon 3 from the target release (per comment #4)

Comment 8 Ian Springer 2011-11-10 21:56:26 UTC
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 15:35:38 UTC
verified master 11/11/2011

Comment 12 Heiko W. Rupp 2013-08-31 10:12:04 UTC
Bulk close of old bugs in VERIFIED state.


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