Open clochix opened 7 years ago
Additionally, this header isn't always accurate. The example you provide have been witnessed on a browser just after I switched its language from English to French (which can often come right after a fresh install), but is still asking English as the preferred language.
A working fix would be to switch this detection from server to client, relying on the window.navigator.language
property which, in my experience, has always been accurate.
Another user is finding this issue annoying “j’ai un peu galéré pour le passer en français, c’est étonnant que la langue ne soit pas détectée automatiquement où qu’on nous propose de la changer directement par message, sans avoir à chercher où ça se trouve”
This was working fine for me. I can make a PR for it if you want (but not sure it is still required with the upcoming go refactor?).
We woudl be glad to accept your PR @Phyks. The new stack won't be released before a few months, so its worth fixing this annoying issue. Thanks!
Sorry, I missed the fact that this was done server-side at the moment. Putting it client-side seems to actually be more work than expected :/
I had a deeper look at the issue, and I am not convinced at all the explanation provided is the good one. Especially since locale
should parse Accept-language
headers.
l = require('locale')
l.Locales("en-US,en;q=0.8,de;q=0.6,fr;q=0.4")
And dumping the constructed Locale
objects, I have:
Locale { code: 'en', language: 'en', normalized: 'en', score: 0.8 }
Locale { code: 'de', language: 'de', normalized: 'de', score: 0.6 }
Locale { code: 'fr', language: 'fr', normalized: 'fr', score: 0.4 }
See this thread
On registration, we use the request header
accept-language
to detect the user language, but don't parse it (for example, it may containAccept-Language: en-US,en;q=0.8,de;q=0.6,fr;q=0.4
), so the detection doesn't seem to work.