Sending a full locale string (instead of only language) may tell a web application much more about the user, for example about its currency, its way to read date and time, etc. So a es_US locale may return a spanish page with dollars instead of euros or pesos.

Yes, things will break for some time, but Apache will fix/improve the way it manages languages very easily.

The real problem is as a result of the definition of HTTP 1.1, not that of any web server manufacturer.

The HTTP RFC 2616 Section 15.1.4 also indicates that the practice of declaring precise accept-language may introduce security issues too.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.1.4

I strongly support Richard’s suggestion that putting just the language, with a lower q score, as well as the language and region would solve the issues.

Let’s use perhaps a clearer example. Suppose I am American. I emigrate to New Zealand. US English remaines my first language and my preferred dialect. But I don’t want to read the New Zealand English version of a web page if there’s an American English version. My language preference therefore should be en-US, not en-NZ.

If I’m in New Zealand, it would be *very nice* if websites got a geographic fix for New Zealand, since network connections are closer from California and Japan than from New York or London. But the language preference isn’t the place to get that fix.

While en-US,en is clearly a better client setting, I suspect that in practice, an en-US request will result in en rourses being served up.

Internet Explorer should help the user to set up a meaningful list (like say, a preference for Australian English, followed by British English, then any other English variant) and it doesn’t seem to do a decent job of that despite a /clear warning/ in the HTTP standard that this is needed.

Secondly the geographical location stuff described above is mistaken. A Frenchman in the US almost certainly wants either fr-FR (French) or en-US (American English) or perhaps both in that order, and if he pops over into Canada he doesn’t suddenly want fr-CA (Canadian French). All Accept-Language does is tell you as precisely as possible what language the user prefers to read documents in. It should NOT be used to try to determine where the user is currently, or where they live.

Trouble is, by my experience, people don’t really have a good idea how to do this (as you showed ) – even if they are aware that it is even possible or necessary after installation. That’s why I’m concerned about the missing fr in the default setup.