Bug 1257618 - "Console Client Resources" page always use the browser language
"Console Client Resources" page always use the browser language
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: rhevm-branding-rhev (Show other bugs)
Unspecified Unspecified
unspecified Severity medium
: ovirt-3.6.0-rc
: 3.6.0
Assigned To: Alexander Wels
meital avital
Depends On:
  Show dependency treegraph
Reported: 2015-08-27 09:10 EDT by Christophe Fergeau
Modified: 2016-04-19 21:31 EDT (History)
9 users (show)

See Also:
Fixed In Version: 3.6.0-15
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-04-19 21:31:00 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: Virt
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Christophe Fergeau 2015-08-27 09:10:41 EDT
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 11:38:03 EDT
@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 08:20:11 EDT
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 09:53:15 EDT
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 07:02:55 EST
Verified - Version:

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