This does not happen with any other chromium based browser
My phone locale is set to Italian with English as second language. IP address is Italian. I’m not understanding why sites like f-droid, Google dev documentation, gitlab, are all defaulting to Chinese as I can’t read it…
Sometimes I can find a link to switch back to either English or Italian, but the next visit they revert to Chinese…
Cool site!
Now I know what’s going on. I added Chinese as a third language because of a bug of an app that defaults to gibberish if it’s not specified.
Firefox is sending
it-IT,en-US;q=0.8,zh-Hans-CN;q=0.5,zh-CN;q=0.3While chromium sends
it-IT,it;q=0.9,en-US;q=0.8,en;q=0.7,zh-CN;q=0.6,zh;q=0.5I checked some implementations of the check and some of them are bugged and assume that the language tag has only one hyphen. So they read
zh-Hans-CN;q=0.5and instead of understanding it as “priority 0.5 for zh-Hans-CN”, they understand it as “maximum priority for zh-Hans and priority 0.5 for CN”Screenshot of wrong parsing for the string sent by Firefox (the chromium one is parsed correctly)
Now what to do… It’s impossible to contact Google to fix their implementation of language detection…
Can you remove zh-Hans-cn from Firefox and just keep zh-cn?
Zh-Hans is redundant here - it is for simplified Chinese, while zh-Hant would be used for traditional chinese. But both are not well implemented and usually people only use the country codes. Zh-cn is already simplified Chinese. Zh-TW (for Taiwan) is often used to cover traditional chinese.
It’d be interesting to see if you get the same bug if zh-hans-cn is added to chrome, as it seems its the actual language tag that is causing the issue and possibly not related to the specific browser at all.
What do you mean by this? If the site parses the header incorrectly and displays a wrong language, then it’s a bug of the website, not the browser. You also said that chromium sends headers that are parsed correctly.
I mean that Google needs to fix their android dev documentation site to parse the header correctly, and I feel very unlikely that they’re going to fix if their own browser doesn’t send an header like that and doesn’t have the problem
At last ! Thanks for sharing the results, it was feeling weird having to change anytime going on gnu.org or whatever
Sorry, but this isn’t something Google could do anything about, even if you were able to contact them. Firefox isn’t based on Chrome, it’s based in their own Gecko engine. You could try to message Firefox though about it.
(if you are wondering, Firefox is based on the Gecko engine. https://firefox-source-docs.mozilla.org/overview/gecko.html
The header is parsed incorrectly on Google servers and return html in the wrong language. It’s google, f-droid , gitlab and many others that have to fix the parsing bug, which is very unlikely
At the beginning of your post, you wrote that “This does not happen with any other chromium based browser”. This would indicate that it’s a unique problem to Firefox and would in turn be a Gecko engine issue. Now, if this was an issue with other browsers, then I’d agree with you.
After investigating, it’s because chromium browsers don’t send “zh-Hans-CN” in the request header and it turns out that many server side language detection implementations are buggy.
So, it’s not technically a Firefox bug, but, considering the minuscule share of people that are
It’s extremely unlikely that hundreds of separate website owners will fix their implementation
I’m guessing the people with this issue are in the orders of dozens, not thousands
Your browser just sends the headers and doesn’t do any detection by itself, besides having a list of ‘locale to locale strings’. It’s possible that the 2 hyphens go against the official local spec. But from what I remember it does seem to be the correct locale string. So the problem would be in the implementation of the websites that display it wrong.