Issue metadata
Sign in to add a comment
|
Regression: Navigator.language doesn't reflect browser default language
Reported by
aiman.an...@etouch.net,
Dec 18 2017
|
||||||||||||||||||||||
Issue descriptionChrome Version:65.0.3298.0 (Official Build) (cohort: 63_win_108)6586a208880a70a00856529493741971ecfea5c2-refs/heads/master@{#524617} (32/64-bit). OS: Win(7,8,10). Test URL: https://chrome.google.com/webstore/detail/pdf-viewer/oemmndcbldboiebfnladdacbdfmadadm?utm_source=chrome-ntp-icon Steps to reproduce: 1. Launch chrome go to the above URL and install extension. 2. Change the browser language to 'Arabic' from chrome://settings/languages and relaunch the browser. 3. Visit http://cb.vu/unixtoolbox.pdf and observe. Actual Result: Toolbar contents in pdf does not change its position according to browser language(Arabic). Expected Result: Toolbar contents in pdf should change its location according to browser language. This is regression issue broken in ‘M-65’ and and below is the bisect info Using the per-revision bisect providing the bisect results, Good build:65.0.3284.0(Revision:521228) Bad build:65.0.3285.0(Revision:521571) You are probably looking for a change made after 521393 (known good), but no later than 521394 (first known bad). CHANGELOG URL: The script might not always return single CL as suspect as some perf builds might get missing due to failure. https://chromium.googlesource.com/chromium/src/+log/5742a1c64e1351efcbd46bc48146f074e290ec49..a029f27a6e98a43e8f1492b85ca18007670d9b28 Suspect: https://chromium.googlesource.com/chromium/src/+/a029f27a6e98a43e8f1492b85ca18007670d9b28 @bokan:Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner. Note: Issue is not seen on Linux(14.04 LTS) and Mac(10.12.6,10.13.1,10.13.2) OS Thank You!
,
Dec 18 2017
This is indeed caused by the landed patch but I think we want to keep the change (since it improves interop). The break is caused because Chrome doesn't change the ordering of `navigator.languages` based on the browser language, it would previously change the `navigator.language` only. It probably makes sense that it should move the browser language to the front of `navigator.languages`. The issues ins't specific to extensions in any way. A clearer repro: 1) Change the browser language to a language that's not at the top of the preference list in chrome://settings/languages and restart the browser 2) Open a new tab and open dev tools (Ctrl-Shift-i) 3) In the console, evaluate `navigator.language` In M64 you'll get whatever language you selected in step #2 In M65 you'll get whatever language is at the top of the languages settings list, regardless of the "browser defualt language" Philip/Mounir, do you agree it makes sense that the browser language should be moved to the front of `navigator.languages`? If so, Juri, please fix the change. (I can't assign the bug to Juri but I'll keep it on myself).
,
Jan 4 2018
As far as I know, extensions are supposed to use browser.i18n.getUILanguage(), not navigator.language, thereby avoiding this problem. It seems to me therefore that if the change affects an extension, then the problem is more with the extension. Is this not correct? Currently, with my change, the languages settings list, the Accept-Languages list and the navigator.languages list are all consistently identical. Adding the default language to the front of the navigator.languages list would introduce inconsistency. It would also mean that it is again impossible to have a different UI language and content language (which is definitely a relatively common use case, at least here in Europe). I mean, I can do it, of course, I just would prefer not to :). At least, I would suggest then doing the same to the settings and Accept-Languages, pinning the default language always on top. This way all the different information sources would give consistent answers. As a side note, I also suspect that the way the language settings UI works might be a bit misleading for users. There is certainly a clear underlying logic to it: the UI language and the content languages are independent variables, therefore they can be configured independently. But this distinction between UI and content is not as clear as it could be in the settings. Perhaps a stronger visual separation would help? For example, by having one box for configuring the UI language, another for the content languages, instead of mixing the two together. And a stronger linguistic separation, by adding some qualifier before "language", "UI" vs "content", or something to that effect.
,
Jan 4 2018
Oh, and a happy New Year!
,
Jan 4 2018
I suppose that makes sense to me, but I have only a cursory understanding of i18n and languages in the browser so I'm definitely not the right person to make a decision here. Given that this does have potential to regress behavior we should at least make sure the right people know of the change, whether that requires UI changes, outreach, or we're just willing to accept the cost of the change. Marking as untriaged to make sure someone from language or extensions can take a look.
,
Jan 18 2018
From a product perspective, a user should be able to have a different language on top of their preferred language list than their browser UI language, when possible. So in my mind Navigator.language is doing the correct thing here, reflecting user prefs as they're stated and WAI.
,
Mar 7 2018
,
Mar 7 2018
,
Mar 28 2018
,
Mar 29 2018
As my issue has been merged into this one. posting the same query I had here too. Thank you for the detailed inputs. Going by the comments, if that's the intended behavior, is their any other way to retrieve the language that has "Display google chrome in this language" turned on ? navigator.language is giving first item in the list. navigator.languages gives all the list of languages. What's the way to get the language that has this setting turned on ? Please suggest. it would be really helpful, thanks in advance.
,
Mar 29 2018
I believe it's browser.i18n.getUILanguage() as mentioned by c3. This is x-browser supported. https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/i18n/getUILanguage#Browser_compatibility
,
Apr 1 2018
Yushkina, Thanks for the reply. How do I use this one in javascript? I tried browser.i18n.getUILanguage() and chrome.i18n.getUILanguage() in console of chrome65 browser, it was returning undefined error. Am I missing something ? Please suggest.
,
Apr 1 2018
Out of curiosity why do you need the user's locale language instead of their preferred language (navigator.language)?
,
Apr 1 2018
Based on the user's locale language we display our application in that language. Previously we used determine user's locale by navigator.language. then we make a fetch call to that corresponding json file and display our website in that language. Even if you observe all the Google's tab name ..search bar etc appear in user locale language but not in the preferred language. That's I would like to know a way to retrieve user locale. Can you please direct me how to use browser.i18n.? Do I have to install any package or extension. I work in node environment using reactjs on client side.
,
Apr 1 2018
Here's the documentation for it. https://developer.chrome.com/apps/i18n Note: this only applies to Chrome extensions. If you are asking for a web app, you should be using the user's preferred language like all web content.
,
Apr 2 2018
I have checked that chrome changes the language to user locale( the language that has "Display google chrome in this language" turned on) though preferred language is different. For example lets say my language list has 1) en 2) fr Now I turn the "Display google chrome in this language" on for french. Relaunch the browser. Now go to any tab, you would see the content in french language though the preferred language is English. We would like to reflect the same behaviour in our website. For which I need, the user locale language. Please suggest.
,
Apr 2 2018
Websites do not have direct access to UI language AFAIK. Preferred languages is what the user prefers to see content on the web in, irrespective of what their UI language is so you should be using that in either case. For what it's worth, for most users the UI language and the preferred web content language are going to be the same. But for those who prefer to see the web in a different language than their UI language, it makes sense to respect that preference.
,
Apr 2 2018
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by hnakashima@chromium.org
, Dec 18 2017