[whatwg] Client side value for language preference

[Jukka K. Korpela]

2012-03-29 22:02, 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
– –
> Browsers support a value called navigator.language but it does not
> convey the same information as the HTTP header.

Browsers have different features in this respect, but indeed they are 
quite distinct from the language preferences.

The language preferences used to have little impact, because few sites 
made use of them. And most users never learned about them, and there was 
little reason to learn… and therefore the settings are often inadequate, 
so it was a vicious circle. Well, still is. But interactive applications 
like many Google services are changing the situation: the language 
preferences sent are used to affect the language in generated texts and 
user interfaces, rather than just selecting between language versions of 
documents.

> Some browsers have gotten smarter and now send the first value from
> the user's language preference, which is definitely an improvement.

I think browsers have generally sent an Accept-Language header 
constructed from user preferences, for many years. The problem is that 
these settings seldom reflect the user’s real preferences, because the 
defaults generally depend on the browser language, or on the system 
language, not on any action by the user. If you use an English-language 
browser, the preference defaults might contain just English in different 
flavors, even though English might be the user’s fourth-best language.

> What would be great is if client side scripts could access the same
> information the server side code could access.

Sounds like a useful thing. It would support the idea of enabling 
standalone applications that can run offline, too. Along similar lines, 
it might be useful to give access to other settings that affect HTTP 
headers, but language settings seem to be far more important than other 
settings.

Note, however, that the idea postulates a simple model where the header 
only depends on certain settings and is the same for all resources. But 
this is probably acceptable. It is difficult to imagine a situation 
where a user preferred HTML documents in French and images in Italian, 
for example.

> 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.

I think the simple idea of a string is the best way to go. Anything 
beyond that can be handled by a library that can be written in a 
cross-browser way—not quite trivial, but surely doable. The problem is 
to get some basic data from the browser in well-defined way. I’d suggest 
a name like

navigator.acceptLanguage

> A very naive and probably flawed example could be:
>
> navigator.language.preference = [{lang:'en-gb', weight: 0.7},{lang:
> 'en-us', weight: 0.7},{lang:'en', weight: 0.3}];
>
> Then JS could:
>
> var n = navigator.language.preferences
> for (i in n) {
>    // check if n[i].lang is supported by the application, if so do
> something about it
> }
>
> This would give users a list of languages with the first in the list
> being the most preferred.

Actually, it’s the q (weight) values that matter, not the order, so a 
routine that selects the most preferred language would need to compare 
them. Moreover, the language negotiation mechanism can be more 
complicated: it need not select the language with highest q value, since 
the resources themselves may have been classified as having different 
qualities. This might not matter in most cases, but applications should 
still have access to the full information, with q values, either in form 
of an Accept-Header string or as a constructed array or object. I’m just 
spelling this out to emphasize that simple information about the most 
preferred language is not enough, even if the information is taken from 
user preferences.

Yucca