Red Hat Bugzilla – Bug 838456
PRD33 - [RFE] Localization of landing / welcome / splash page
Last modified: 2015-09-22 09:09 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.
(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.
Patchset available here:
(In reply to comment #2)
> Patchset available here:
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.
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.
With latest is1 build:
# rpm -q rhevm
Created attachment 758466 [details]
The portals link address's locale for Japanese should be ja_JP but not ja
Also reproduced for fr_FR, should be locale=fr_FR but not fr.
Looks like http://gerrit.ovirt.org/#/c/14409/ never got applied downstream.
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.
Created attachment 759171 [details]
screen-shot: welcome page
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]
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.
Will verify on is16 build or later build testing env with reports portal set up.
Verified it's fixed on is18 build: rhevm-3.3.0-0.25.beta1.el6ev.noarch.rpm
Please see the attached screenshot.
Created attachment 811495 [details]
Fixed on is18
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.
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.