Accept-Language and Localization Preference Cookies

[dsheets]

As discussed in #409, we would like to more automatically surface language translations for non-anglolexic visitors. Specifically, some combination of respecting the Accept-language HTTP header, a user preference cookie, a language selection mechanism, Content-language and Vary response headers, and <link> tags should be used.

In #409, @dbuenzli describes the scheme he uses on his personal site which is probably a good starting point for this sort of effort.

[dbuenzli]

One thing that may work less well for this site, is that in my site all pages have a translation, so something should be done for point 2. of my comment when there are links to pages that are not translated yet. Making the link to the english version and add "in english" in the native language and in parens to indicate that the visitor is going to switch language maybe an idea.

The main point I wanted to make is that http content negotiation is a bad idea for humans in general, it makes a terrible user experience if you don't agree with what was negociated. Avoid it at all costs, except for the toplevel landing page.

The reason for point 1. of my comment is that links are usually used to point to precise content between individuals and the person who communicates the link refers to that precise content. This is the reason why you should not try to switch to another language when a link is followed. A simple example is someone sending a link to the caml-list on an english webpage telling there's an error, I don't want to be presented with the french webpage when I follow the link. Again here, take example on the biggest multilingual website that wikipedia is it doesn't switch language if you get to a page that is not in your language. The idea here is that each URI implicitely encodes a language and what you follow is what you get.

The reason for point 2. is that of course once you are reading something in a language you expect to further browse in that language.

The reason for point 3. is that these are the only instants where there's a true ambiguity about language: the toplevel URI has (or should have) no implied language encoded and so do 404 errors of course.

Finally accept-language is not something that should be taken too seriously: someone may be browsing with someone else browser. The user may prefer some other language for certain content (e.g. I prefer english for technical writing, I want to browse debian.org website in english but these idiots won't let me do so if I don't change my browser preferences which may have impact on other sites I browse). So doing things solely according to accept-language without being able to escape the mechanism is a very bad idea.