What the hell does HTTP_ACCEPT_LANGUAGE mean?

Maybe you know which setting in IE to tweak to make MS Knowledgebase reappear in english by default... This is clearly an international issue...

Not to mention that people may be using a browser whose settings they cannot control and may prefer a different language than the one the browser says the user wants.

Since the meaning is defined by HTTP it doesn't really depend.

HTTP_ACCEPT_LANGUAGE is based on the Accept-Language request header field, which simply means "content in these languages are acceptable to me, in this order of preference". The implication being that the user agent requesting the document will be able to understand text in the specified languages (and may not understand information in other languages).

That's all it means according to the spec; assigning the field any further meanings are always assumptions. Assuming too much frequently leads to problems.

The HTTP/1.1 RFC mentions none of these as is - since it was originally meant for formatted text documents, the Accept-Language was intended for the language the content is in.
It should be noted that this implies the UI language, if we have a web application, and the formatting/collation preferences, because those are part of the language.

I disagree with the idea that the Accept-Language header should ever be used to find out _about_ which language/locale to provide content, or for which location to provide information. The abstract information in a HTTP reply MUST, in my opinion, depend solely on the query string and, in the case of POST and PUT requests, the content. The purpose of Accept, Accept-Charset and Accept-Language is only to define the way (media type, character encoding and language, respectively) this information is to be transmitted.
If the abstract information contains differences based on any of the Accept headers, then I will consider your web site/application broken.

We should remember that HTTP was not designed for the reach type of things that are happening right now.
If something rich comes on top (Java, Flash, SOAP, whatever), it is the duty of that "think" to add the extra services. Many web sites offer a way to select a location. Many offer a way to select a language (ignoring HTTP_ACCEPT_LANGUAGE).

=============================
Lets see if something really important is missing from the low-level protocol that is HTTP:

* language/locale to use for the UI
* language/locale about which to provide content
On web, this two are pretty much the same thing, if by UI you mean the UI of a web-application. If you mean the UI of the browser, then it is irelevant. HTTP_ACCEPT_LANGUAGE is for comunication, why would the server care about the UI of the browser? I can tell you I hate Mac+Safari, for forcing me to change the UI of my system just to see a web page in French.
This is the real and only use for HTTP_ACCEPT_LANGUAGE: determine language of content. The fact that the content is dynamic, interactive, and we call it "application" is not that relevant.

* language/locale to use for formatting/collation preferences
I have always asked miself what is the real life scenario asking me to have French UI with Japanese date and time formats and Arabic numers. Cool, yes. Very useful, no.

* location for which to provide information
This is new even for Windows (XP was the first one to have it), and I still have to see an application using it. So it does not seem so dramatic if it is missing. I is not useless, but not vital.

"HTTP/1.1 RFC does not control the hearts and minds of people posting content on the Internet"

But it can, and it should, control the brains of browser developers. If the browsers don't support all these extra semantics for HTTP_ACCEPT_LANGUAGE, who would post such content?

Protocol standards establish rules for communication. Developers need to know what the rules are and what happens if you break them. They also have a responsibility for making it easy for users (who can't be expected to understand protocols beyond the most basic level) to do the right thing. We need these rules because you can't have cooperation if everyone makes up his own rules that work differently.

Accept-Language should not affect content or behaviour unrelated to language and an application ignoring this really is broken. If you want to deal with things as they are you either fix the application or, if that's not possible, complain and work around its bugs. Pretending that the rules mean different things than they say is at best hiding behind ignorance.

Michael, on a bare Windows install (using Virtual PC) it just depends on the language settings. Once I put "Deutsch" as accepted language to the top, the knowledgebase appears in german language. In addition the kb seems to use cookies as only deleting cookies helped me to get the english on my production XP.

Windows Server 2003 here, with English (US) UI, Italian (Italy) locale and Italy as the location. Browsers appear to send my locale for Accept-Language, and it generally works because luckily my location and locale are coherent - but I really wish web applications (such as webmails) presented me with English (US) GUIs (but I expect content in Italian about Italy) - it could be a lot worse

A little bit about the backstory on some of the Important changes in NLS that span Windows and the .NET...

Some of you seem to be missing the point all together.

HTTP_ACCEPT_LANGUAGE refers to the settings in the BROWSER of the user's computer - i.e. this is a USER setting, NOT a website setting.

Therefore, if the USER decides he lives in Italy and speaks English, then having HTTP_ACCEPT_LANGUAGE allows you to translate your content and/or format - OR NOT.