Re: #428 Accept-Language ordering for identical qvalues

[Amos Jeffries <[e-mail]>]

On 19/01/2013 1:50 a.m., Nicholas Shanks wrote:
>>> On 2013-01-18 09:46, Amos Jeffries wrote:
>>>> I'm with Roy on this one. It's not adding any new requirement about
> I feel I concur with Julian the most.
>
> On 18 January 2013 12:11, Roy T. Fielding <[e-mail]> wrote:
>> Yes.  It would also be conformant to send Mäori text.
> Use a macron or leave it off ;-)
> [Option-a] [a] on a Mac with one of the "Extended" keyboard layouts
>
>> Ignoring the preferences sent in Accept-Language is conforming behavior.
>>
>> Conformance is not a relevant issue here.  What matters is what the
>> user actually prefers. It is my opinion that when a user sets an
>> Accept-Language header to
>>
>>    Accept-Language: en, de
>>
>> what they are actually saying is that they accept both languages
>> but would prefer en if the de representation is no better.
> You cannot assume that. They are either using a broken client, or both
> are acceptable. Please don't change the standard to accomodate broken
> clients, especially as these are going to become fewer in number as
> time progresses and machines get upgraded.
>
>> The reason I believe this is because user agents that allow a
>> user to send such a header field have explicitly instructed the
>> user that the field is ordered (or based the value on some other
>> ordered list for the host UI, as is the case for some cell phones).
> All UAs I know of that allow users to set an ordered list of
> languages, also send auto-generated q-values.
>
> Do you actually have any statistics to back up your belief, or is it
> just a gut feeling?
> Some numbers to say that "versions x and earlier of so-and-so browser
> on X-series phones allow users to define an ordered list but do not
> send q-values; those browsers currently have a worldwide market share
> of 0.0001%" would be useful to know whether it's worth ignoring such
> broken UAs to pandering to them.
>
>
> FWIW, my usual AL string, in browsers that let you set one, is:
> "en-GB, en-IE, en-AU, en-US;q=0, en;q=0.95, fr;q=0.5, de;q=0.5,
> zh-Hant;q=0.1, *;q=0.2"
> My goals should be self-evident from the q-values, specifically to get
> english, french or german, to demote 'complicated' Han script and fall
> back to anything else. The US thing is to see if sites are actually
> obeying my preferences (I get many more "y'all"s than 406's sadly!)

According to the 2616 spec we are quibbling over you would get en-GB, 
en-IE, or en-AU if any of them were available. These being assumed to be 
q=1 and all equal valued; one is supposed to be selected *randomly*.

Now suppose you had a blog page with each comment loaded by XHR as a 
separate GET request using that AL header and auto-translation of 
comments - your page looks like a group of multi-cultural responses some 
possibly with pidgin-English style wording despite probably all actually 
being en-US text to begin with. AND if you refresh the page everybodies 
language changes from what it was last load.

Versus a server which assumed en-GB, en-IE, en-AU were equal q=1 and 
ordered by preference would supply you with the en-GB for each response 
part of the page.

Which is the better outcome for web developers to rely on?
Which one is easier for servers to write fast code for?

Amos