r102205 MediaWiki - Code Review archive

I disagree. nl-be,nl;q=0.7,en-us,en;q=0.3 would be equivalent to nl-be;q=1,nl;q=0.7,en-us;q=1,en;q=0.3

The order is not relevant in the list. (I would personally have prefered to sort by order of appearance in the header for values with the same q-value, but php sort algorithm are not a stable sort)

Note that having 'en' with q-value 1 (as the comment suggest, in opposition to your summary) would indeed be a bug, but is not happening.

Or are you refering to the "prefix matching rule" (which is not implemented)? I think that rule would just allow serving an en-us document for a user which only provided on its accept-language en. So not relevant to this example-

+			// @FIXME: In case "nl-be,nl;q=0.7,en-us,en;q=0.3", "en" gets defaulted to '1',

should be

			// @FIXME: In case "nl-be,nl;q=0.7,en-us,en;q=0.3", "en-us" gets defaulted to '1',

That was a typo

Like I said in the commit message: " Although I'm not 100% sure about this, I've added a FIXME about the q-val defaulting to 1.".

When I add languages in Firefox preferences, the default for me was "nl, en-us, en". Which ended up like "nl;q=0.7,en-us,en;q=0.3" in the HTTP header. There for it appears that Firefox is not adding q-values for all languages codes, which to me clearly suggests that it assumes that whatever is processing that header is using either look-ahead or look-behind, NOT directly default to something.

So that "nl-be,nl;q=0.7, en-us,en;q=0.3" would be equivalent to "nl-be;q=0.7nl;q=0.7, en-us;q=0.3en;q=0.3"

If the specification says otherwise, I have no problem keeping it like it is. If the specification agrees however than the below comments are correct:

getAcceptableLanguages: ( 'nl-be,nl;q=0.7,en-us,en;q=0.3' ):
array(4) {
["nl-be"]=>
string(1) "1" // should be 0.7
["en-us"]=>
string(1) "1" // should be 0.3
["nl"]=>
string(3) "0.7"
["en"]=>
string(3) "0.3"
}

The relevant standard I followed is rfc 2616. The most relevant piece

(from section 14.4) would be:

Each language-range MAY be given an associated quality value 
which represents an estimate of the user's preference for the 
languages specified by that range. The quality value defaults to "q=1".

If you find the standard to imply otherwise, please share.

Now to the Firefox behavior: I couldn't reproduce it.

When I add nl, en-us and en in Firefox languages, I get

nl,en-us;q=0.7,en;q=0.3

which is consistent with what I expected.

Ordering, 'nl, en-us, en' it's

nl,en-us;q=0.7,en;q=0.3

Setting also nl-be:

nl-be,nl;q=0.8,en-us;q=0.5,en;q=0.3

How did you get "nl-be,nl;q=0.7,en-us,en;q=0.3" from Firefox interface?

I looked for a Firefox bug like that, but didn't find it.

Yet, there are some interesting ones like 55800 or

58034: Accept-Language header needs q values which

supports my view in the opening comment:

You can change the priority of the languages within the preferences, but no q
values are attached to each language. Thus, true content negotiators such as
mod_negotiation in Apache view all languages as being preferred equally, as
according to HTTP/1.1 (IE properly adds q values to the languages)

That bug follows to the patch adding q-values, with comment 7 explaining

firefox algorithm for q-value assignation:

1 is divided amongst the languages present. For
example, if you have three languages, the first gets a q of 1.000, the second
gets 0.667, the third gets 0.333.

I don't know how that unqvalued 'en-us' arrived to your Accept-Language header.

Alrighty, that's exactly what I was looking for. Removed fixme in r102453.