Bug 1501098 - Service UI not taking 'user default' language
Summary: Service UI not taking 'user default' language
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: UI - Service
Version: 5.9.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: GA
: 5.10.0
Assignee: Oleg Barenboim
QA Contact: Shveta
Depends On:
Blocks: 1553477
TreeView+ depends on / blocked
Reported: 2017-10-12 06:23 UTC by Vatsal Parekh
Modified: 2019-02-07 23:03 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1553477 (view as bug list)
Last Closed: 2019-02-07 23:02:54 UTC
Category: ---
Cloudforms Team: ---
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2019:0212 None None None 2019-02-07 23:03:07 UTC

Description Vatsal Parekh 2017-10-12 06:23:25 UTC
Description of problem:
After changing the language from configuration->Default Locale, if we logout, and go to service ui, with keeping the option "Language: user default" shown in the login UI, the language is still English, where it should have changed to the one changed in the configuration.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:

Actual results:
Language not changed

Expected results:
Should have changed

Additional info:

Comment 4 Milan Zázrivec 2017-10-16 09:38:23 UTC
In OPS-UI, it's possible to configure i18n on user level and on server (i.e. appliance) level.
For user, you can either set the language explicitly, or set global default, which defaults
to the server (i.e. appliance) settings.

On the appliance level, you can either set the language explicitly, or default to browser

The fact, that OPS UI won't honor the language selection from the login screen is either
problem of the API (which might not be sending the correct info, which I doubt) or Service UI.

Also, it could be, that Service UI simply doesn't / isn't supposed to reflect the settings
made in OPS UI.

Nevertheless, this is not a problem in OPS UI, and lack of some settings in Service UI has
nothing to do with this (unlike comment #2 suggests).

Comment 5 Allen W 2017-10-18 16:44:26 UTC
I really wish this was an SUI issue, then I could apply the swift fix! Sadly it is not.

SUI does this call `GET http://localhost:3000/api?attributes=authorization` to get the all the pertinent deets about the user, in that response we rely on the value `response.ui_service.display.locale` to set the display language. This value remains unchanged when the Default Locale in the OPS is updated.

I logged into OPS, changed the default language, logged out, logged into SUI and checked, still being supplied `en`.  Also checked the other spot this might have been set, `response.settings.locale` annnnnnnnd its also `en`.  (Note, query above was run on an http client as to completely bypass SUI metaling)

Comment 7 Jillian Tullo 2018-01-05 21:13:52 UTC
After playing around with this setting, I see that the service ui language setting is different than that in the Classic UI. In order to set the language for the Service UI, you can set it upon login or from the User menu in the top right corner of the SUI --> Switch Language. 

I have verified that the API endpoint Allen mentioned above, `/api?attributes=authorization`  response.ui_service.display.locale gets updated accordingly when the language setting is set both from the login screen and from the settings. 

In addition, I have played around with the language settings in the OPS UI and have confirmed that those get returned properly from the API as well: it is returned under settings.locale and settings.display.locale, both of which were accurate. 

I do not believe that this is an API from what I can see above, and am not sure it is a bug at all. Will need more insight from the SUI and UI teams to see if there is a disconnect on what the language should be set to.

Comment 8 Jillian Tullo 2018-01-08 17:00:04 UTC
Reassigning to SUI as they're likely the best suited to determine whether it is a bug or not

Comment 9 Dave Johnson 2018-01-11 15:10:36 UTC
Bumping up the priority, I think this should be a little more important than the general medium severity bz so I want it to be called out.  In addition, we have some movement that hopefully we can act upon and not let it go stale.

Comment 10 Chris Hale 2018-01-31 18:56:16 UTC
GH PR.  https://github.com/ManageIQ/manageiq-ui-service/pull/1375

Comment 12 Shveta 2018-09-28 19:40:47 UTC
Fixed .
Verified in

Comment 15 errata-xmlrpc 2019-02-07 23:02:54 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.


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