Is anyone up for convincing me that the HTTP accept header is a good idea?
I understand the theory: every resource should have the same URI, and should be able to deliver to clients in the format that they indicate they can best handle - eg an image served as WEBP to supporting clients but falling back to JPEG
But we have 20+ years of real-world experience with it now, and I'm not at all convinced that those theoretical benefits outweigh the drawbacks: mainly its lack of discoverability
I can't remember a time I've ever encountered an API that uses the accept header and thought "oh great, this is going to make my life easier, I'm glad they made that design decision"
I usually think "oh wow, the accept header: that's going to make this less convenient to work with, and I'd better remember that this API uses that or I'll run into all kinds of surprises in the future"
The accept-language header makes a bit more sense to me... but honestly I'm not completely sold on that one either
I'd rather have independent URLs for pages in different languages, so I can easily link to and compare them
Maybe use accept-language to redirect to the URL for their language, then allow them to override that with a cookie
But I have English as a first language, so maybe I'm entirely wrong about this and most users MUCH prefer the experience that accept-language can provide them
In constrast to Accept, I think that Accept-Language doesn't fit reality that well.
Let's assume we are in an ideal world where users can cause their browsers to emit Accept-Language values exactly like they want (in particular different ones for different sites), and UI affordances for temporarily/permanently/... switching that for a given site/... are intuitive for all.
Even in that world Accept-Language is insufficiently expressive. Let's say we have a site with UI translated into many languages and with automated translation for contents. There's no way to express a preference between "English UI, content auto-translated into English" and "English UI, German content in German, other languages auto-translated into English". Also, it's impossible to express different preferences for UI and content.
The situation for any site that offers search over a dataset in multiple languages is even weirder: should Accept-Language cause search to exclude or downrank some results?
Many people (in particular people learning a language) would want to be able to control all of these aspects independently, which wouldn't be possible if everyone took heed of Accept-Language.
I agree that having _a_ way to communicate one's language preferences via a unified in-browser UI (or browser's guesswork) would be a good thing. I don't think we can come up with something that wouldn't devolve to site-specific settings (e.g. with site-specific sets of types of content).
@robryk @simon but the problem is not really in header or not, the problem is that such complex requirements are bit implemented by any site at all, even if it is with login and settings. It would be equally hard.
Once we figure out how to express these affordances, and see that there are enough people out there who care, then we could move that to the browsers or OSes to implement.