Even Accept-Language headers aren't really a particularly good solution. I might prefer some sites in Danish, but others I'd like to have en English. Unless browsers allow you to set language on a per site basis, we still aren't really capturing the nuances of language preference.
Accept-Language could be a pretty good indicator of a persons language skills, but it's just to far into the browsers settings to be something that a normal user would adjust. I can see why checking the domain is quicker and perhaps more inline with a persons intent, even if it is ignoring travelling.
We where trying to book a table at a restaurant, it's part of a fairly large chain. We where in Sweden, but the chain also operates in Denmark, so we know that they have a Danish version of their website and ordering app, you just can't use the Danish language when you are in Sweden. You can get English for some reason, but not the Danish version. That to me seem like a missed opportunity.
> I might prefer some sites in Danish, but others I'd like to have en English. Unless browsers allow you to set language on a per site basis, we still aren't really capturing the nuances of language preference.
This problem is solved already by competent sites. On your first visit to a site, it uses Accept-Language to guess what language you want to see. If you use a language switcher menu to pick a different language, a cookie is used to save your choice. On your next visit to the site, the cookie is sent and that takes precedence over Accept-Language to send you the page in your preferred language. Easy.
If/when you decide to create a user account on the site (if the site even supports that) then your language preference can be stored with your user data so you would see it automatically after you log in even if you're on a different browser/device.
As with many other things, there are already best practices on how to do all this stuff. It's just a matter of getting web devs and their managers to be aware of them and/or care enough about providing a good experience for their users (unfortunately this has turned out to be a huge ask) to find and implement them.
> […] picking your preferred language is an unskippable step of setting up a new phone.
This does not address, or more precisely it even prevents the notion of:
> I might prefer some sites in Danish, but others I'd like to have en English.
, i.e. what you set in your OS or UA (browser) is always one preferred and optionally some fallback languages. I second that granular per-site control would be preferable for me either: some texts I prefer in my mother tongue (news, non-tech encyclopedic articles), the rest, namely technical documentation I prefer in English. (Also, I have very bad experiences with localised GUIs, where 1. familiarity with English "original" vastly helps when searching and 2. translations tend to range from bad to hilariously comical.)
But I must admit that most websites serving of content in multiple languages, support client-side pref pretty well, so the situation is not so terrible, in my experience.
Yet, the problematic of content negotiation and user <-> agent <-> author (provider) information passing is interesting and I'd say even under-engineered, and currently terribly suffer from security (anti-tracking) constraints.
I do not ever use any OS or other software in my native language, however I do want most non-technical websites to display in it when possible. How do I communicate that?
My hunch is that Accept-Language became the best way to determine a user's language about the time it became common to bring a laptop while traveling. People use arguments today against Accept-Language that have been wrong for decades.
No they don't? I have never got that at least. It asks for my UX language, not for my preferred languages for websites. My preferred UX language is always English since most translations to Swedish are horrible while Swedish made websites are best read in Swedish and not a potentially bad English translation.
accept-language is a list. Do I want English or Spanish first? What if your content is better in the second? I'm much better at English than Spanish, but I'm better at Spanish than the AI translation to English. Plus I may be watching that video in German to learn German even though I'm so bad at German I wouldn't put it in...
Accept-language is accurate, but just isn't easy change it which is required to handle all the possible situations and get the right answer. Still everything else is worse.
Accept-Language headers aren't used in a particularly good way by browsers and servers. If used better, they would be a particularly good solution.
The idea you mentioned of browsers allowing the header to be set on a per-site basis would be particularly good.
Another very good solution would be for servers to assign weight to the languages they support, and to combine their weights with the Accept-Language weights to choose the best language in common.
But even as they're implemented and used now, Accept-Language headers are already a way better approach than geo-ip.
Accept-Language could be a pretty good indicator of a persons language skills, but it's just to far into the browsers settings to be something that a normal user would adjust. I can see why checking the domain is quicker and perhaps more inline with a persons intent, even if it is ignoring travelling.
We where trying to book a table at a restaurant, it's part of a fairly large chain. We where in Sweden, but the chain also operates in Denmark, so we know that they have a Danish version of their website and ordering app, you just can't use the Danish language when you are in Sweden. You can get English for some reason, but not the Danish version. That to me seem like a missed opportunity.