I'm curious about how the Accept-language header field works, as outlined at http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html and if we could take advantage of that with i18n. My understanding is that the browser would send its preferred language(s) through the get header, so the server could parse that and return an appropriate page.
An example of this is given at http://www.w3.org/TR/cooluris/#conneg
GET /people/alice HTTP/1.1
Host: www.example.com
Accept: text/html, application/xhtml+xml
Accept-Language: en, demight return:
HTTP/1.1 200 OK
Content-Type: text/html
Content-Language: en
Content-Location: http://www.example.com/people.en.htmlfollowed by the content in English.
I guess the only question is, how adopted is this specification with browsers? If the big name browsers follow it, then it makes sense that we should as well. Obviously, if, for instance, Firefox follows it but IE doesn't, then it wouldn't be of any use.
Feel free to correct me if my understanding of the specification is incorrect, or we already use this and I hadn't realized it, or if there's some technical reason we couldn't use the specification.
Thanks,
Aaron Winborn
Comments
language detection
The "Path prefix with language fallback" language negotiation setting makes use of this for anonymous users. Unfortunately it introduces language prefixes to all URLs, which is why I made this patch: http://drupal.org/node/335699