But yea, just because you are visiting Japan doesn’t mean that everything has to be Japanese
Try living here. You think the site language is an issue? Try signing up to things via forms. Tell me your name in Kanji and Kana because those are required fields. And oh, if that Kanji and Kana doesn’t match up with your ID we are rejecting your application.
Don’t do step 2 unless you’re sure what you’re doing. There are many sites out there trying to be cute by defaulting Swedish into German. Swedes do not understand German at all (unless you’re part of the one percent that studied it in school and somehow retained it), whereas everyone understands English to at least some degree.
I’m ok here with different content (in fact, I am not, but it’s a completely different issue).
Talking only about language support in case if website already have multiple localized versions for the UI
Late to this party but so what? Use country domains. Google.com shouldn’t be google.es or google.fr. If I want a particular website, I can go there. Don’t need the server telling me what I can and can’t see based on near-arbitrary IP addresses.
The article you linked does NOT state that brave does not send the language header though. It states that per default it only sends the preferred language and may randomize the weights. Only if explicitly set to strict, it always sends ‘en’ - which kind of falls into the same category as setting preferred languages in the first place - most users won’t bother to tinker with the settings.
So in fact, most browsers do send a useful accept language header that reflects the users preferred language. For the ones that do not send it, I honestly would argue that we should assume that the user knows what he or she is doing. You can always fall back to IP based language for those cases.
Therefore I don’t think fingerprinting is a good argument against using the accept language header. Sure, you might make some users happy by guessing their language right, but on the other hand you’re probably making way more users unhappy by ignoring their preferred choice and making them find the language switch first.
Also to the point that very few people know how to configure their preferred language(s) - most Browsers default to the OS settings, which usually resemble the users most preferred language. At least it’s guaranteed that it’s a language they understand.
In summary, I agree with OP. We should consider the accept language header prinarily instead of guessing based on IP. It’s made exactly for the purpose of allowing browsers to communicate the users preferred language(s).
I’m fully aware of it, though IP-detected locale should be a backup option. But not the prioritized one, in case if browsed did sent the proper headers.
Personally as a user I don’t care about websites “tracking” me by the browser/os fingerprints.
for those “experienced” devs I would say, stop living in the past and keep your knowledge up to date. just cus it works, doesn’t make something a better solution.
Nobody is arguing that users should not be able to choose, this is about what the default should be (i.e when the user did not explicitly make a choice on the website).
I believe it is sensible to use the user’s general settings (language and theme for example) as defaults for when the user did not tell you what they prefer
UPD.: Also, for iOS, I had to switch the whole phone language to English to stop Google switching to other languages from any browsers (which are all using the same engine on ios, “thanks” to apple)