Bug 1257618

Summary: "Console Client Resources" page always use the browser language
Product: Red Hat Enterprise Virtualization Manager Reporter: Christophe Fergeau <cfergeau>
Component: rhevm-branding-rhevAssignee: Alexander Wels <awels>
Status: CLOSED CURRENTRELEASE QA Contact: meital avital <mavital>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 3.6.0CC: awels, gklein, lsurette, mavital, mgoldboi, rbalakri, Rhev-m-bugs, srevivo, ykaul
Target Milestone: ovirt-3.6.0-rc   
Target Release: 3.6.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 3.6.0-15 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-04-20 01:31:00 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Virt RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Christophe Fergeau 2015-08-27 13:10:41 UTC
If you go to the very first page of the RHEV web UI (https://rhevm36.example.com), you have a 'Console Client Resources' under a 'Downloads' headers. When I click on this link, I get a webpage in French (default language I set for my browser) regardless of the language setting I picked on the RHEV home page. This page should follow the RHEV language setting rather than use the browser default language.

Comment 1 Einav Cohen 2015-08-28 15:38:03 UTC
@Alexander - this would require having this page go through our locale filter (or similar) that we have, I believe? is that possible?

Comment 2 Alexander Wels 2015-09-08 12:20:11 UTC
Looking at the console client resources web.xml it makes reference to the locale filter. So one of two things is happening.

1. Because the console client resources is in its own ear file it doesn't have access to the correct class and thus isn't applying the filter. At which point I guess maybe jboss is setting the global locale to the browser Accept header value.
2. It does have access to the filter, but it can't read the cookie with the locale in it. One of the fallback mechanisms in the filter is to use the locale the browser passes to it. The order goes like this:
   a. Use the locale parameter.
   b. If no parameter, use the locale cookie.
   c. If no cookie, use the Accept header from the browser.
   d. If no header, default to US English.

The most likely thing we are seeing is option 2.c where the cookie cannot be read and it falls back to the browser accept header.

Comment 3 Alexander Wels 2015-09-24 13:53:15 UTC
The cause of the issue was two fold:

1. The web.xml didn't have the correct filter statements to invoke the LocaleFilter (which reads the cookie).
2. The resource page didn't have the statement to read the locale once it was available. The associated patch fixes both.

Comment 5 meital avital 2015-11-19 12:02:55 UTC
Verified - Version: 3.6.0.3-0.1.el6