So the q values are removed, which are not important for us. The this list is added to the language selection priority order if the elements are acceptable for the site. Well, we don't have a manual under the "en-us" name, so "ja" is choosed for you, as your preferred language. Language codes are basically the dir names on php.net, and we don't have en-us, en-gb and the like...
Interesting. What are the q values for?
From the HTTP 1.1 RFC:
| 14.4 Accept-Language
|
| The Accept-Language request-header field is similar to Accept, but
| restricts the set of natural languages that are preferred as a
| response to the request. Language tags are defined in section 3.10.
|
| Accept-Language = "Accept-Language" ":"
| 1#( language-range [ ";" "q" "=" qvalue ] )
| language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )
|
| 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". For
| example,
|
| Accept-Language: da, en-gb;q=0.8, en;q=0.7
|
| would mean: "I prefer Danish, but will accept British English and
| other types of English." A language-range matches a language-tag if
| it exactly equals the tag, or if it exactly equals a prefix of the
| tag such that the first tag character following the prefix is "-".
Well, we make no use of the quality, as we provide content in the first found language, regardless of how well it will be received.
Do you think we should convert en-us and en-gb to en while processing the accept language string?
Yes I do. As it stands, there's no way for me to control Safari's language string, but I'm not moving away from Safari. I'm sure there are other people out there that are being bitten by this also, so I would very much appreciate this?
OK, your post also revealed another bug, which have been fixed now. We host the several Chinese versions under different names then they are provided in the Accept language, so I have also added a translation table. Please wait a few minutes, while the changes go up to the site and everything should be OK (I hope so :).
Now, every language flavor specification is stipped out in case it is not significant for us, so en-gb and en-us will also mean "en". The only significant flavor specs are pt-br and the Chinese variants, which are handled now ;)
Thanks for your report,
Goba