User "Platonides" posted a comment on MediaWiki.r102205.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102205#c25616
Commit summary:
[TsIntuition] Minor fixes in acceptableLanguages()
* Adding an example of the static utility function to demo/demo6
* Moving the function out of the TsIntuition class into TsIntuitionUtil where
the other static utility functions are, renaming to getAcceptableLanguages
* Improving documentation/variable naming a little bit
* Whitespace / curly braces fixes
* Although I'm not 100% sure about this, I've added a FIXME about the q-val
defaulting to 1. It needs a look-ahead technique to be more solid, right now
low-level accept-languages are getting too high. Example:
-- code
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"
}
-- /code
See demo6 for more this in action
* Follows-up r100234
Comment:
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-
_______________________________________________
MediaWiki-CodeReview mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
