The problem is that it's surprisingly difficult to make accept-language negotiation actually work (unless users specifically dig into their configuration and make it so, no browser I've tried gets this right out of the box)
Lets take a reasonable scenario - the wikipedia articles for Birmingham (UK). In English, the article is as fleshed out as you'd expect, for the second-largest city in the UK. In Slovak, there's a couple of pretty pictures, and two sentences.
A user arrives with the header "Accept-Language: sk-SK,en-US;q=0.8,en;q=0.6". Which article to I send them?
The 'naive' approach is to send them the two-line summary in Slovak. Their preference is Slovak, I have Slovak, let's do this. Easy.
The 'weighted' approach is score my available translations, decide that, eg, my English article has a weight of '1' (it's the best translation of this material I have), my Slovak article has a weight of 0.2 (it's a pretty crap translation). Content weight * User weight gives me 0.8 for my English article (1 * 0.8), and 0.2 (1 * 0.2) for my Slovak article. So I deliver the English article - the user has expressed that English is "pretty good", and I can deliver much better content in English. As a programmer, I love this approach, it saves delivering poor translations to users who don't need them.
Now, the reality. The user has sent en_US;q=0.8 not because they speak a single word of English, but because Chrome will by default, send the OS environment as 1st preference, en_US as second, and en as third. Being clever failed.
Any time we have to admit that our translations are not made equal, accept-language (or rather, current browsers' default configurations of it) is simply too naive.
Lets take a reasonable scenario - the wikipedia articles for Birmingham (UK). In English, the article is as fleshed out as you'd expect, for the second-largest city in the UK. In Slovak, there's a couple of pretty pictures, and two sentences.
A user arrives with the header "Accept-Language: sk-SK,en-US;q=0.8,en;q=0.6". Which article to I send them?
The 'naive' approach is to send them the two-line summary in Slovak. Their preference is Slovak, I have Slovak, let's do this. Easy.
The 'weighted' approach is score my available translations, decide that, eg, my English article has a weight of '1' (it's the best translation of this material I have), my Slovak article has a weight of 0.2 (it's a pretty crap translation). Content weight * User weight gives me 0.8 for my English article (1 * 0.8), and 0.2 (1 * 0.2) for my Slovak article. So I deliver the English article - the user has expressed that English is "pretty good", and I can deliver much better content in English. As a programmer, I love this approach, it saves delivering poor translations to users who don't need them.
Now, the reality. The user has sent en_US;q=0.8 not because they speak a single word of English, but because Chrome will by default, send the OS environment as 1st preference, en_US as second, and en as third. Being clever failed.
Any time we have to admit that our translations are not made equal, accept-language (or rather, current browsers' default configurations of it) is simply too naive.