[webkit-dev] exposing the value of Accept-Language via window.navigation.acceptLanguage ?

[Darin Adler]

On Jul 22, 2009, at 10:36 PM, Darin Fisher wrote:

> Firefox and Chrome send very similar A-L headers. Given FF's  
> marketshare, I'm surprised you observed compat problems with doing  
> the same. Was that a recent observation? Can you provide more  
> details about the issues you observed?

I’m not familiar with how Chrome approaches this, but Firefox handles  
this by offering a browser setting to explicitly configure a list of  
languages for web browsing. Roughly speaking, it’s a direct control of  
the Accept-Languages header field. Very few web servers look at this  
header field at all.

> It should be noted that normally people only have one value (or one  
> family of values: "en" and "en-US" for example) on the A-L list

Exactly; this is true across browsers. Thus a single value is the  
configuration that’s most tested.

Thus the issue is not Firefox market share number that matters, but  
rather the vastly smaller number of people using any browser who have  
gone to the trouble to put multiple languages in the language list.


What we discovered in 2003 and 2004 was that making a multiple- 
language list the norm for people who don’t opt in to it resulted in  
many broken websites. Further, almost no websites worked better with a  
more complete Accept-Language header field.

We discovered sites that had difficulty with long Accept-Language  
header fields containing a large numbers of characters. Here are a few  
examples:

- The official Irish Tourist Board site www.ireland.travel.ie did not  
load because of the long Accept-Language header.

- A site called termpro.com gave us a “Firewall Security Alert”  
because the header was too long. Presumably that’s not the only site  
that was affected by this firewall.

- Servers using the Netscape Directory Gateway failed because of the  
long header. At the time this included sites such as these:

     calendar.gwu.edu
     co.stanford.edu
     directory.princeton.edu
     gun.teipir.gr
     ldap.chapman.edu
     www.inami.fgov.be

Symptoms were variable and it took us a long time to figure out the  
issue was because of long header.

- Another site that had problems with the long list was dirtypictureshow.com 
.

Later, we discovered a few other problems. For example, for a while  
eBay treated users as if they were browsing from Germany if the German  
language appeared anywhere in the list, blocking certain auctions.  
Using the languages list from Mac OS X as our default meant that  
German would be included for most users.

Once we changed the Safari Accept-Language to be shorter we didn’t get  
any more data about the problem, naturally. But I don’t think it is  
right to assume that these problematic sites disappeared. It’s not as  
if there are a large number of users with any browser that are testing  
behavior with a long Accept-Language header field.

I think this boils down to a question of the value of having an  
explicit browser preference setting solely to configure the value of  
the Accept-Language header field. It seems this is one of those  
settings that experts love to tweak, but has little relevance to the  
real web. Do we really expect users to go out of their way to  
configure such things so they can browse the web? Can’t we just make  
the web work for them?

     -- Darin