Bug 838456

Summary: PRD33 - [RFE] Localization of landing / welcome / splash page
Product: Red Hat Enterprise Virtualization Manager Reporter: Andrew Cathrow <acathrow>
Component: RFEsAssignee: Alexander Wels <awels>
Status: CLOSED ERRATA QA Contact: Lijun Li <lijli>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 3.1.0CC: abaron, acathrow, adahms, awels, ecohen, eedri, eng-l10n-bugs, htaira, iheim, lpeer, rbalakri, sgordon, ykatabam
Target Milestone: ---Keywords: FutureFeature, i18n, Translation
Target Release: 3.3.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: ux
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) Environment:
Last Closed: 2014-01-21 17:27:53 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 978122, 1019470    
Attachments:
Description Flags
The portals link address's locale for Japanese should be ja_JP but not ja
none
screen-shot: welcome page
none
Fixed on is18 none

Description Andrew Cathrow 2012-07-09 07:26:15 UTC
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-09 00:18:24 UTC
(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 16:08:00 UTC
Patchset available here:
http://gerrit.ovirt.org/#/c/10065/

Comment 3 Alexander Wels 2012-12-20 16:14:56 UTC
(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 06:26:03 UTC
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 06:27:00 UTC
With latest is1 build:
# rpm -q rhevm
rhevm-3.3.0-0.3.master.el6ev.noarch

Comment 9 Lijun Li 2013-06-08 06:35:09 UTC
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 06:43:47 UTC
Also reproduced for fr_FR, should be locale=fr_FR but not fr.

Comment 11 Alexander Wels 2013-06-10 12:24:31 UTC
Looks like http://gerrit.ovirt.org/#/c/14409/ never got applied downstream.

Comment 12 Alexander Wels 2013-06-10 12:53:37 UTC
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 12:56:59 UTC
Created attachment 759171 [details]
screen-shot: welcome page

Comment 14 Einav Cohen 2013-06-10 13:01:31 UTC
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-26 03:03:10 UTC
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 08:58:10 UTC
Will verify on is16 build or later build testing env with reports portal set up.

Comment 22 Lijun Li 2013-10-12 02:52:51 UTC
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-12 03:00:17 UTC
Created attachment 811495 [details]
Fixed on is18

Comment 24 Charlie 2013-11-28 00:07:43 UTC
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:

https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes 

Thanks in advance.

Comment 26 errata-xmlrpc 2014-01-21 17:27:53 UTC
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.

http://rhn.redhat.com/errata/RHSA-2014-0038.html