Fundamentally the issue for me is, this behavior can't be automated in an elegant way.
Having priorities and weight and language lists in the manifest help for negociation, but at the core of it, the user will want to choose language based on context and content.
> Language selection should be done on the client side, not on the server.
Yes.
Using a site specific list on the client side could also do it (let's say I always want Facebook in a language and Google in another, Linkedin in yet another etc.). It still will be pretty cumbersome, probably needs an auto-save and sync of the preferences, and still hits problematic cases, but it would be the most pragmatic solution.
The worst instance of it is IMHO the way Google Maps work, changing language based on the country gives the best display (local names in the proper writing, no internationalization), I wish there was an easier way than screwing with the Google account preferences. As you point out, having clients able to unambiguously request a specific version at each requests would gives us so many more options.
> Having priorities and weight and language lists in the manifest help for negociation, but at the core of it, the user will want to choose language based on context and content.
Yup, agreed. I highly doubt most websites even look at those weights in the Accept-Language header anyways.
Having a list of supported langs in the manifest costs nothing. Lazy-load the manifest when the user goes to use the language selection dropdown, or when the response from the server is in a different language than the one requested in Accept-Language (check Content-Language or html `lang` attr).
That's IMO the original sin: no automatic selection will cover 99% of use cases, that in itself it to me a fantasy that isn't worth pursuing.
People are complicated and having simple heuristics to predict what more than half of them want is not feasible at our level of technology.
Sure any single person will have somewhat simple rules to decide what languages they want, you could come up with simple rules for the people in your life. But you're not trying to solve it for a specific group of people. The target is 8 billion people, most of which we have no idea what their life is.
Having priorities and weight and language lists in the manifest help for negociation, but at the core of it, the user will want to choose language based on context and content.
> Language selection should be done on the client side, not on the server.
Yes.
Using a site specific list on the client side could also do it (let's say I always want Facebook in a language and Google in another, Linkedin in yet another etc.). It still will be pretty cumbersome, probably needs an auto-save and sync of the preferences, and still hits problematic cases, but it would be the most pragmatic solution.
The worst instance of it is IMHO the way Google Maps work, changing language based on the country gives the best display (local names in the proper writing, no internationalization), I wish there was an easier way than screwing with the Google account preferences. As you point out, having clients able to unambiguously request a specific version at each requests would gives us so many more options.