Accept-Language is de_DE despite language being set to English |
|||||
Issue description
Chrome Version : 70.0.3538.110
OS Version: 11021.81.0
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari:
Firefox:
IE/Edge:
What steps will reproduce the problem?
1. Get a corp Chromebook in Switzerland
2. Set Language (in chrome://settings) to English
What is the expected result?
Accept-Language should be "en"
What happens instead of that?
Settings: https://screenshot.googleplex.com/jkNR9pyaQcP
Accept-Language: https://screenshot.googleplex.com/vOFcAaTpWB1
Please provide any additional information below. Attach a screenshot if
possible.
UserAgentString: Mozilla/5.0 (X11; CrOS x86_64 11021.81.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36
,
Jan 7
I am unfamiliar with Accept-Language, it appears to be part of an HTTP header, apparently as part of a GET request? I expect it is including Accept-Language entries from sources other than the language setting (I notice that 'en' and 'en-US' are also included). +jam@ based on blame for accept_header_browsertest.cc: https://cs.chromium.org/chromium/src/content/browser/net/accept_header_browsertest.cc?q=Accept-Header&sq=package:chromium&dr=C&l=94
,
Jan 7
I'm not familiar with the precise mechanics of how the header value is picked. The header value comes from ComputeAcceptLanguageFromPref, which calls into HttpUtil::GenerateAcceptLanguageHeader. Looks like these haven't been touched for a while. +a few net/OWNERS
,
Jan 7
What actually matters here is the string passed to GenerateAcceptLanguageHeader, which comes from a pref, populated by some language-y code somewhere, I believe.
,
Jan 8
This sounds like the same problem as Issue 918449, in which the language prefs seems wedged on a wrong value. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by pmarko@chromium.org
, Jan 7