Hide Forgot
Description of problem: Non-english locales are loaded in the installer UI and the help links point to RHQ in the JON 3 CR2 How reproducible: Every time Steps to Reproduce: 1. Download the JON 3 CR2 2. Change your browser default locale to an RHQ support locale other than en-US (eg. de-DE) 3. Run the installer 4. Take note of the language and help links. Actual results: The language is non-english and the help links point to RHQ wiki. Expected results: All the text should be English and the links should point to JON official documentation. Additional info: This behaviour is identical for the old JSF UI. The problem occurs because there are non-english locale files copied during the JON re-bundling process. All those locale files should be removed from the application and the language bundle from faces-config.xml should be updated. This problem does NOT affect the GWT UI because the only locale compiled is en-US.
Simeon, I presume this is not a regression from JON2.4.x? Whats the level of effort on addressing this?
The change is limited to the JON bundling process. There are two changes required: 1) The actual locale files need to be removed from the server package 2) faces-config.xml needs to have references to non-english locales removed
I disagree that the fix and verification are that simple. I also do not think that the priority of this fix is 'high'. I think the priority on this one is low at best as JON is only supported in English at this time. If the customer is setting their browser to a non-english locale and is attempting to complete an installation of JON in a different language then the installer being incorrect is just the first of many difficulties that they will encounter. As we don't support install or usage patterns through the installed UI in other locales then we should do a better job preventing/deterring non-english locales. How one better communicates to non-english users stumbling into the JON installer without multi-locale support is unclear to me at this time as correct error messaging would require that same multi-locale support. Level of effort to address is not certain if you include the testing/verification of the proposed changes. It is not clear what removing all of the alternative locales will do. Localized files are used by jsp , jsf and gwt/smartGwt UI components in numerous places. I'm not certain that our testing will catch/cover all of the places in jsf 'installer', portal.war and coregui.war pages if we change them. Additionally we're dealing with four different i18n mechanisms (jsp/jsf/gwt/smartGWT) that we're thinking about removing unsupported locales for. Are we certain that all of these different approaches will respond correctly when we leave the i18n frameworks in place but remove the existing non-english locales? This change is too risky for JON3 given that it i)has unknown side effects and ii) only really helps customers who have already started down an unsupported path. Since JON has never been supported in non-english locales afaik then this is not a regression for JON2.4.x.
JON 2.4 and probably also 2.3 was delivered with German locale in installer, so removing that is a regression.
The solution: replace all the existing locale files with the English locale during JON bundling. With this change different locale files are still loaded at run-time however all of them will have only the correct English content. This approach minimizes the risk by preserving the file structure already tested but at the same time deliver the correct content to the browser. The fixes have been committed to JON repo (sha: 0490c9b564520aecabefcbccc3dd2a5c82315e8d & 9831838ce84d48b51fff6179d6e1019618f048c1)
To verify this change please download and install a browser plugin that allows fast browser locale changes. Quick Locale Switcher is a good example for Firefox; this plugin has an option to refresh the current page on locale changes which is very helpful for testing purposes. Test Case for installer: 1) Start JON server 2) Make your browser locale is set to a non-english locale supported by RHQ installer (eg: de, fr, pt, zh, ko). 2) Browse to the installer page 3) Verify that the text presented is in English and all the links point to JON official documentation. 4) Change the browser locale to another locale supported by RHQ and repeat Step 3. Repeat this for all the RHQ supported locales. 5) Change the browser locale to anything not supported by RHQ and repeat Step 3. Test Case for the rest of the application: 1) Start JON server 2) Make your browser locale is set to a non-english locale supported by RHQ application (eg: de, fr). 2) Browse to the application start page; after login navigate to a portion of the application that uses JSF portlets (eg. metrics and traits page for inventoried resources). 3) Verify that the text presented is in English. 4) Change the browser locale to another locale supported by RHQ and repeat Step 3. Repeat this for all the RHQ supported locales. 5) Change the browser locale to anything not supported by RHQ and repeat Step 3.
assigning to heiko for verification
Tested as follows: With Google-Chrome in Japanese and Korean locales ... tested all Help links. JSF portlets (metrics and traits for inventoried resources). Links were all to JON documentation (not RHQ) ..and text on JSF portlets in English. With Firefox and Quick Locale Switcher...tested as above with German, French, and Russian. No issues. To do: links from installer.
Verified links from installer with FF and Quick Locale Switcher for the following languages: English German Russian Chinese Japanese the links are valid and point to official JON documentaiton.
I find it odd that the "Configuring Agents and Server" link point to the same place as the "Agent users guide"
The documentation for agent and server has been combined into a single page for JON (unlike RHQ that has two pages). However, because I18N constructs an entry is required on that page so I updated the link for Agent to point to the same JON Server and Agent page.
re-verified in CR4
changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE