What the hell does HTTP_ACCEPT_LANGUAGE mean?
by Michael S. Kaplan, published on 2005/08/23 19:12 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/08/23/455359.aspx
The question is a simple one: what the hell does HTTP_ACCEPT_LANGUAGE mean?
The answer is also quite simple: IT DEPENDS.
The user is sending information from their browser, and could mean any of the following things:
- language/locale to use for formatting/collation preferences
- language/locale to use for the UI
- language/locale about which to provide content
- location for which to provide information
Now sometimes all of the settings will be the same. It is obviously more common for that to be the case. But it is a huge Internet and frankly there are a lot of times that they're not the same. It is unfortunate and all of these different items have to be filtered through a single setting across all of the browsers. But life is about dealing with things as that are, not as we want them to be.
It is therefore
importantcrucial to recognize that a user may have any of these in mind, and be careful not to assume too much based on the HTTP_ACCEPT_LANGUAGE -- giving them an easy way to change the settings if you assumed more than they wanted you to....
This post brought to you by "Ǯ" (U+01ee, a.k.a. LATIN CAPITAL LETTER EZH WITH CARON)
# Meikel Weber on 23 Aug 2005 9:34 PM:
Maybe you know which setting in IE to tweak to make MS Knowledgebase reappear in english by default... This is clearly an international issue...
# Philip Newton on 24 Aug 2005 1:40 AM:
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.
# Johan Petersson on 24 Aug 2005 2:48 AM:
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.
# CornedBee on 24 Aug 2005 6:13 AM:
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.
# Michael S. Kaplan on 24 Aug 2005 10:14 AM:
Johan and CornedBee -- HTTP/1.1 RFC does not control the hearts and minds of people posting content on the Internet -- and all of those options EXIST. As I like to say, life is about dealing with things as they are, not as we want them to be. Hiding bedhind "the standard says ________ and anyone who does not do that is broken" is just ignoring the reality of how things are.
# Michael S. Kaplan on 24 Aug 2005 12:31 PM:
Meikel, it is an example of why having only this setting is a problem. What is your HTTP_ACCEPT_LANGUAGE, exactly?
# Mihai on 24 Aug 2005 2:54 PM:
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.
# Ambarish Sridharanarayanan on 24 Aug 2005 4:01 PM:
"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?
# Johan Petersson on 24 Aug 2005 5:29 PM:
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 S. Kaplan on 24 Aug 2005 9:11 PM:
Personally I think if the page is all about learning to speak Japanese and someone wants to tag it Japanese rather than the language it is in, then that is fine. I do not believe that web site content owner to be either ignorant or stupid. Especially given how non-specific the standard's language is.... I suppose we will have to agree to disagree.
# Meikel Weber on 25 Aug 2005 5:35 AM:
# Michael S. Kaplan on 25 Aug 2005 9:42 AM:
Hmmm.... it does not update the cookie if you update the accept-lang?
# KJK::Hyperion on 25 Aug 2005 11:42 AM:
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
# Blake on 21 Oct 2008 9:36 PM:
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.
Please consider a donation
to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.
go to newer or older post, or back to index or month or day