Re: #428 Accept-Language ordering for identical qvalues

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 <fielding@gbiv.com> 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

Received on Saturday, 19 January 2013 04:29:52 UTC