How should sites (Google and/or you) treat Accept-Language header

httplocalization

For a long time I've been not happy with the behavior of Google in the cases below, and after accidentally noting that 80+ other people feel the same way (and 20+ people upvote the idea of Google bug report) I thought it's useful to tap into SO's wisdom on HTTP protocols and the web culture.

This behavior appears every time I go to a different country and access google.com from my laptop or install a new browser. In many countries, including Vietnam, google automatically redirects to a localized version (e.g. google.com.vn), the one I can't actually read so I scan it in a desperate attempt to find Google.com in English link.

The first time it happened I was puzzled and spent some time finding out what could be wrong with my request headers; as I expected, my Accept-Language is always en-US or something like en-US,ru;q=0.5. Further tests with different IPs confirmed that they do IP geolocation, even when you are logged in. Later I learned there is a language query ?hl=..., but still.

So, my question would be: do you think this is reasonable and expected behavior, webculture-wise? Do other sites do it too? If you were to design a multilanguage site what would you do with a person who comes from .vn IP but with en-US language?

I imagine there are different approaches to IP geolocation:

  • contra: I think this is impolite: I tell you explicitly what I want,
    what's good about giving me something else?

  • pro: It could be that a person has just installed browser with the default language pack, without any idea about Accept-* headers, and still would prefer to see localized version of a website.

  • contra: And yet, non-techie people can easily change accept-language by installing a language pack. In fact, if you go to download Firefox, chances are you'll download the one in the language you want, with the accept-language header that respects your wishes.

Note that I read the HTTP 1.1 specification from 1999 but they seem to omit the question of how much the Accept-Language should be really taken into consideration.

I believe this question belongs to SO as a web-app design question. And I'm still thinking about filing a formal bug report (if I am correct that this behavior is far from web standards).

Best Solution

I think there are really two separate issues at play here. Language and country. They most definitely are not the same thing. The HTTP spec explicitly defines the Accept-Language request-header field as language specifier, not a country specifier.

For example: en-US refers to a specific language (the version of English spoken mostly in the United States), en-GB refers to another language (the version of English spoken mostly in the United Kingdom). This really has nothing to do with where you currently are in the world, it just defines what language is most acceptable to you when viewing a website. And that should be respected because even novice users should have a browser in their language which will by default send the correct request-header field.

But that's not what sites traditionally use it as. Like another poster, I've noticed that sites equate language with country and tailor their site to that country's unique political restrictions/freedoms/the company's offerings there, not necessarily for the language. The example given was a company that doesn't sell a particular product in a particular country but does in others.

In the case of what products to display for different countries, geolocating the IP address would be better than making decisions based off the language but it still wouldn't be perfect. What if I'm in another country temporarily but want to order something and have it delivered back home? What if my IP address doesn't reflect where I physically am, it's not perfect?

Yes, things work correctly for most people most of the time. But why on Earth would you make it hard for people to get the site in the language that they ask for?? It's just bad UI design.