.pick ignores quality?

[mrkurt]

I'm trying to use incoming HTTP headers to serve up the most appropriate translation of a site, and it seems like .pick is exactly what I need, but it's not respecting the quality value of headers. When I run this:

parser.pick(["en", "nl"], "en-GB,nl;q=0.5"

I would expect it to return en, but it's giving me nl. Is this on purpose or would you like a PR to fix it?

[matteofigus]

This is correct. In the pick, you should use the full languages you support, like ['en-GB', 'nl-NL']. In that scenario, the picked would be en-GB. If you want to have just en check the loose option in the README.

[mrkurt]

Ah! loose actually returns the same, presumably because nl is an exact match?

[Bramzor]

I would advise to put full locales and nog languages in the array of options. Together with loose, you will in that case always get the full locale and will solve your issue:

parser.pick(["en-US", "nl-BE"], "en-GB,nl;q=0.5"

Should in this case indeed return en-US as language matches. Using split you can extract the language from the locale.

[bamapookie]

I added some tests for the readme examples and corrected the readme based on the results here: https://github.com/opentable/accept-language-parser/pull/35

[FMCorz]

I ran into specificity issues as well.

acceptLanguageParser.pick(['en-GB', 'es', 'en'], 'en')

The expected result, to me, would be en as it's a perfect match, but instead if returns en-GB.

[alex-piccione]

parser.pick(["en", "nl"], "en-GB,nl;q=0.5"

I think It is correct to return "nl" for this scenario.
"nl" and "en-GB" have the same priority (q=0.5), so why a non-matching locale should be preferred to a matching one?
The user expects "nl" or "en-GB", why give him "en" instead of something that is what they asks for? ("en" is also much more like en-US than en-GB in terms of date-time formats).
Typical Accept-Language values are:

• fr-CH, fr;q=0.9, en;q=0.8, de;q=0.7, *;q=0.5
• en-US,en;q=0.5

"en-GB,nl" is like the first example replacing "fr" with "nl", so why it should provide "fr" if "en" or "de" are accepted (also within the same q in your scenario)?
In that scenario, the missing "en" seems to indicate it really doesn't want it.

[bamapookie]

I believe in this case, en-GB has a weight of 1. When the ;q= is missing, the q value is 1.

See here: https://developer.mozilla.org/en-US/docs/Glossary/Quality_values

Since this is a strict search, though, nl wins because that value is in the supported language array.

[danjunger]

pick does ignore quality though. if you look at the source, there's literally nothing in there that even looks at the quality number.

// en-GB: 0.2, en-US: 0.4
// this returns en-GB because it's the first match
parser.pick(['en-GB','fr-FR','en-US'], 'zh-CN,zh;q=0.8,en;q=0.6,en-US;q=0.4,en-GB;q=0.2')