-
-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Accept-Language comparing standard currently differs between getLanguagePriority
and compareSpecs
#54
Comments
How coincidental, I just ran into this issue as well. var Negotiator = require('negotiator');
var req = { headers: { 'accept-language': 'en-CA,en;q=0.9,en-GB;q=0.8,en-US;q=0.7,fr;q=0.6,pt;q=0.5,th;q=0.4' } }
var negotiator = new Negotiator(req);
negotiator.languages(['en-GB', 'en-US', 'en-x-pirate']);
[ 'en-x-pirate', 'en-GB', 'en-US' ] // output In my scenario the |
@tangye1234 #46 provides a bit more context, and @dougwilson has shown that this module adheres to RFC 4647, so this unfortunately is a |
@julianlam, I think @dougwilson is trying to explain the case Apache mod_negotiation and jshttp/negotiator behave the same, but that is not what rfc4647 describes, the RFC only describes that in this case language cannot be selected out, but only be filtered with a fallback list, while users would decide for their own. Maybe he is right because the negotiator cannot make decisions for the user, unless user send another accept-language list:
|
Hi everyone, sorry I have been away with other things. For Accept-Language header, this module specifically only implements the algo linked to from the HTTP RFC (https://tools.ietf.org/html/rfc7231#section-5.3.5). To quote from that section of RFC 7231:
The "Basic Filtering" algo is what this module currently implements for Accept-Language header, as it is the algo web servers have always traditionally implemented for selecting a language from a set list for HTTP applications. The full test of this algo is in RFC 4647 here: https://tools.ietf.org/html/rfc4647#section-3.3.1 How the basic filter algo works is also illustrated in a previous comment I made here #46 (comment) which applies to the original post as well. I'm not really familiar with the ago in RFC 4647 that would produce the expected results in the original post. @tangye1234 would you be able to link directly to the section in RFC 4647 that defines the algo you're expected and than use your example to walk though it? I'm 100% open to adding additional defined algos to the list such that you can choose which one to use when matching language tags 👍 the PR above was changing the existing standards-defined algo which is why it was marked as I hope this makes sense. |
Assuming we want to define additional algos to the call to negotiator, how would this be achieved, as a second argument for |
Let's make the request
Accept-Language: zh, zh-CN;q=0.9
and
We provided backlist: ['zh-CN', 'zh-TW']
Coding:
Actual:
'zh-TW'
Expect:
'zh-CN' for sure
Analysis:
In the code, we get two comparing code snippets:
But when codes come here
WHICH LEADS:
when comparing
zh-CN
to acceptedzh, zh-CN;q=0.9
,we get a high matching level zh-CN with a lower quality weight 0.9
and then comparing
zh-TW
to acceptedzh, zh-CN;q=0.9
,we get the the only half-matched
zh
with a high quality weight 1finally, we use
compareSpecs
to select a higher quality languagezh-TW
rather than the lower but 100% percent matched onezh-CN
Read the rfc4647, it is not defined whether this expectation should be reasonable.
It only reads:
So the accepted language with
zh, zh-CN;q=0.9
is not comformed to this user decision.But I think, the comparing logic should be the same ( q > s > o), such that
The text was updated successfully, but these errors were encountered: