Bug 838456 - PRD33 - [RFE] Localization of landing / welcome / splash page
PRD33 - [RFE] Localization of landing / welcome / splash page
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: RFEs (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: 3.3.0
Assigned To: Alexander Wels
Lijun Li
: FutureFeature, i18n, Translation
Depends On:
Blocks: 978122 1019470
  Show dependency treegraph
Reported: 2012-07-09 03:26 EDT by Andrew Cathrow
Modified: 2015-09-22 09 EDT (History)
13 users (show)

See Also:
Fixed In Version: is8
Doc Type: Enhancement
Doc Text:
This feature makes it possible to view the content of the welcome page for the Red Hat Enterprise Virtualization Manager in accordance with the desired locale. With this feature, the welcome page now automatically determines the locale of the browser and presents content in the language of that locale. A button has also been added to the welcome page that allows administrators to select their desired locale. This preference is stored across sessions.
Story Points: ---
Clone Of:
: 978122 (view as bug list)
Last Closed: 2014-01-21 12:27:53 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
The portals link address's locale for Japanese should be ja_JP but not ja (139.49 KB, image/png)
2013-06-08 02:35 EDT, Lijun Li
no flags Details
screen-shot: welcome page (40.94 KB, image/png)
2013-06-10 08:56 EDT, Einav Cohen
no flags Details
Fixed on is18 (138.70 KB, image/png)
2013-10-11 23:00 EDT, Lijun Li
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 12695 None None None Never
oVirt gerrit 15520 None None None Never
oVirt gerrit 16359 None None None Never

  None (edit)
Description Andrew Cathrow 2012-07-09 03:26:15 EDT
Landing page should support localization based on browser locale.
There should also be a way for a user to change the locale which should support a cookie to save the users preference.

Links to documentation should use the redirection servlet to point to the currently selected language.
Comment 1 Einav Cohen 2012-12-08 19:18:24 EST
(In reply to comment #0)
> Links to documentation should use the redirection servlet to point to the
> currently selected language.

I think there is no need to do that: 

if we will implement the localization of the landing-page by simply creating a dedicated HTML page for each one of the locales, then we can put in each one of these pages a direct-link to the localized-documentation (e.g. the "ja" landing page will contain the link to the "ja" documentation, etc.).

There should be a fallback mechanism (currently implemented by symblic-links, might move to a redirection-servlet) that in case "ja" documentation doesn't exist, for example, the user will be redirected to the default (English) documentation.
Comment 2 Alexander Wels 2012-12-20 11:08:00 EST
Patchset available here:
Comment 3 Alexander Wels 2012-12-20 11:14:56 EST
(In reply to comment #2)
> Patchset available here:
> http://gerrit.ovirt.org/#/c/10065/

I guess it helps if I actually say what was implemented:
We replaced the index.html with an index.jsp file which is served from the SplashServlet that was added. We implemented a filter that takes the locale in the following order:
1. If a locale parameter is passed, use that.
2. If no parameter exists, check for a locale cookie, use that.
3. If no cookie exists, check the browser preference (Accept header), use that.
4. If none of the above exist, use the default English (US) locale.

The index.jsp uses a java resource bundle to i18n the content of the splash page. There is also an available languages bundle which is used to populate the language/locale selection box.
Comment 7 Lijun Li 2013-06-08 02:26:03 EDT
Verified it's not fixed for ja_JP, 
The portals link address's locale for Japanese should be ja_JP but not ja.

Please refer to the screenshot.

Moving to ASSIGNED.
Comment 8 Lijun Li 2013-06-08 02:27:00 EDT
With latest is1 build:
# rpm -q rhevm
Comment 9 Lijun Li 2013-06-08 02:35:09 EDT
Created attachment 758466 [details]
The portals link address's locale for Japanese should be ja_JP but not ja
Comment 10 Lijun Li 2013-06-08 02:43:47 EDT
Also reproduced for fr_FR, should be locale=fr_FR but not fr.
Comment 11 Alexander Wels 2013-06-10 08:24:31 EDT
Looks like http://gerrit.ovirt.org/#/c/14409/ never got applied downstream.
Comment 12 Alexander Wels 2013-06-10 08:53:37 EDT
No I was wrong, that patch is applied. The problem happens if the default locale of the browser is not one of the supported locales. ja != ja_JP. The locale filter properly determined the locale of the browser, but didn't determine it was not supported and therefore couldn't properly select the drop down or set the cookie.
Comment 13 Einav Cohen 2013-06-10 08:56:59 EDT
Created attachment 759171 [details]
screen-shot: welcome page
Comment 14 Einav Cohen 2013-06-10 09:01:31 EDT
currently, when the default browser locale doesn't *exactly match* one of RHEV-M's supported locales, it puts question marks ("????") in the locale drop-down and configures the different links to include the default browser locale (e.g. "...?locale=ja") - see attachment 759171 [details] for a screen-shot of the welcome page when the default browser locale is 'ja'.

when the default browser locale doesn't *exactly match* one of RHEV-M's supported locales, need to fallback to U.S. English (both in the locale drop-down and in the links). 
[the user will then be able to change that default to one of RHEV-M's other supported locales, using the drop-down]
Comment 17 Einav Cohen 2013-06-25 23:03:10 EDT
QE: need to verify the correct behavior of the page in the context of this bug (e.g. need to make sure that the issue described in Comment #7 is fixed, make sure that the links within the page lead to content in the selected locale, etc.)

verification of the *translation* of the page's textual content should be done in the context of Bug 978122.
Comment 21 Lijun Li 2013-09-27 04:58:10 EDT
Will verify on is16 build or later build testing env with reports portal set up.
Comment 22 Lijun Li 2013-10-11 22:52:51 EDT
Verified it's fixed on is18 build: rhevm-3.3.0-0.25.beta1.el6ev.noarch.rpm

Please see the attached screenshot.
Comment 23 Lijun Li 2013-10-11 23:00:17 EDT
Created attachment 811495 [details]
Fixed on is18
Comment 24 Charlie 2013-11-27 19:07:43 EST
This bug is currently attached to errata RHEA-2013:15231. If this change is not to be documented in the text for this errata please either remove it from the errata, set the requires_doc_text flag to minus (-), or leave a "Doc Text" value of "--no tech note required" if you do not have permission to alter the flag.

Otherwise to aid in the development of relevant and accurate release documentation, please fill out the "Doc Text" field above with these four (4) pieces of information:

* Cause: What actions or circumstances cause this bug to present.
* Consequence: What happens when the bug presents.
* Fix: What was done to fix the bug.
* Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore')

Once filled out, please set the "Doc Type" field to the appropriate value for the type of change made and submit your edits to the bug.

For further details on the Cause, Consequence, Fix, Result format please refer to:


Thanks in advance.
Comment 26 errata-xmlrpc 2014-01-21 12:27:53 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


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