A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

Communicating your home location


Is there a standard way for a user to inform a website about which localized version of the website they prefer. Example: A German user is on vacation in Italy and would like to continue to receive the German versions of websites they browse on their mobile device.

Some websites let users set this, but it would of course be better if there was a standard which browsers could implement, so that websites could get this information for free.

I can see this existing as a opt-in setting in the browser, which would instruct the browser to send a specific HTTP request header, unless of course, there already exists something like this…

Update: Ok, so that would be the Accept-Language header. I guess, this header should be able to take care of this issue.


In PHP there is even a very neat function named http_negotiate_language(), that is very savvy in determining, which language is requested. Also takes into request the q parameter in the accept-Language header.


An interesting question though is why the Accept-Language header is not more widely used. In many cases, we find that a site uses rough IP geolocation to guess our language more than they use an explicit set of languages from the user. Is it just too difficult to get users to choose this in the UI and so sites don’t check or trust this header value? Do site implementers not know about it?


One explanation I’ve heard for not using the OS user’s locale for the language is the “foreign webcafé” use case. Imagine you go to a web café in a foreign country, whose written language you don’t understand, to check a news website. The OS is probably configured in kiosk mode and for the language of the foreign country, so you can’t change the OS user’s locale/language setting. If the browser and news website just use the OS user locale language setting, then you won’t be able to view the news website in English, short of resorting to Google Translate.

Contrariwise, there’s also the case of the bilingual tourist, whose mobile device is set to use their native language for comfort, but they might prefer to view websites related to their trip in the local language even if the sites are multilingual, because the translated versions might be incomplete or the translations might be of poor quality, etc.

I’m guessing that’s what the browser vendors have concluded, for whatever reason, though I can’t recall any browser that’s attempted to expose any language selector button or menu item outside of their Preferences windows (and of course average users never touch the Preferences).


Chrome has the “This page is in X, translate it into: Y” dropdown it pops up on pages that it suspects to be written in a “foreign” language. It seems to me like having a persistent Translate UI element (even just on the hambuger menu, maybe replacing the useless Encoding menu) would be a good segue into introducing Language as a first-level browser concept.