[whatwg] Accept-Language DOM API proposal

On Thu, 29 Mar 2012, Matthew Nuzum wrote:
>
> Hello, on every HTTP request your browser sends header called 
> Accept-Language with a value something like this:
> 
>     en-gb,en-us;q=0.7,en;q=0.3
> 
> This is sent to all domains wither your request is for an image, an html 
> file, a js script, or whatever. This gives server-side code some nice 
> capabilities, one of the foremost being the ability to localize content.
> 
> As you all are well aware, more and more application logic is being done 
> on the client side. In some cases, even HTML templating is being done 
> there. In a few project I've been involved with recently it would have 
> been nice to be able to identify the user's preferred language client 
> side.
> 
> Browsers support a value called navigator.language but it does not 
> convey the same information as the HTTP header. On many browsers it 
> simply indicates which language the browser is localized in. For 
> example, if you speak Spanish but buy a computer in America which comes 
> with Firefox pre-installed then despite what language you prefer it will 
> be en-us.
> 
> Some browsers have gotten smarter and now send the first value from the 
> user's language preference, which is definitely an improvement. I 
> suspect this was done in order to preserve backwards compatibility, so 
> much of the useful information is left out.
> 
> What would be great is if client side scripts could access the same 
> information the server side code could access. That could be done simply 
> be creating a new property that contains the same string as is sent to 
> the server. It's easily parseable. But if we're going to make a new 
> interface then maybe it would be good to make one that reduces the 
> amount of work that client side developers would need to do. [...]

On Fri, 30 Mar 2012, Henri Sivonen wrote:
> 
> Is there a reason to believe that this client-side solution would be 
> used significantly considering that the HTTP header has not been used 
> that much?

On Fri, 30 Mar 2012, Matthew Nuzum wrote:
> 
> I've used the HTTP header numerous times and I know many people that 
> have. It is so commonly used that Apache even has built in support to 
> make use of it when serving content.
> 
> For example, if you visit http://start.ubuntu.com/9.04/ you'll be 
> presented with a page that is probably in your language (we translated 
> it into 42 languages). The way the content negotiation feature of Apache 
> works is that you name pages in a pattern like this: index.html.en, 
> index.html.fi, etc. You can see how we did that here: 
> http://bazaar.launchpad.net/~ubuntu-start-page/ubuntu-start-page/trunk/files/head:/www/9.04/
> 
> It's quite easy to make use of this feature and I think it might be more 
> commonly done than you suspect. And if we were to make it even easier to 
> do I think that it would increase in use.
> 
> For example, maybe a site can't afford translation but a small library 
> could be included that formats dates and numbers based on a user's 
> language preference. No more wondering if 2/3/12 is in March or in 
> February.

On Fri, 30 Mar 2012, Henri Sivonen wrote:
> 
> The reader doesn't know that the site tries to be smart about dates (but 
> not smart enough to just use ISO dates), so scrambling the order of date 
> components not to match the convention of the language of the page is 
> probably worse than using the convention that's congruent with the 
> language of the page.

On Wed, 4 Apr 2012, Mark Callow wrote:
>
> I would love it, if more sites would use these headers. As someone else 
> pointed out, some web servers make it very easy. I would support an 
> equivalent client-side query.
> 
> The current favourite algorithm among servers seems to be to serve a 
> language based on their perception of your current location. There are 
> so many reasons why this causes them to serve the wrong language, it is 
> beyond my understanding why so many sites do it. As a native English 
> speaker living in Japan, I suffer from it every day. The HTTP headers 
> provide a much better mechanism.

I haven't added anything to expose this; it's not clear to me that it 
would actually be worth it in practice, since there doesn't seem to be 
much chance of many authors using it, the browsers don't really expose the 
relevant settings UI well, and pragmatically most sites that do 
translation are going to want to be shipping different bits in the first 
place for performance reasons (you don't want to wait a round-trip to get 
the UI strings, and you don't want to send all the UI strings, typically), 
so HTTP headers would be enough. However, I'd love to be proved wrong, so 
my recommendation would be to advocate this to browser vendors and see 
what they are willing to implement.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'