search

tinganho / node-accept-language

BCP47 language negotiation
MIT License
85 stars 15 forks source link

Not resolving to less specific language #23

Closed SimeonC closed 7 years ago

SimeonC commented 7 years ago

Scenario:

const acceptLanguage = require('accept-language');
acceptLanguage.languages([ 'en',  'ja',  'zh',  'zh-TW',  'zh-HK',  'zh-CN',  'zh-MO',  'zh-HanS',  'zh-HanT',  'ko', 'fr' ]);
acceptLanguage.get('zh-HanS-TW'); // returns 'en', expected 'zh-HanS'
acceptLanguage.get('zh-SG'); // returns 'en', expected 'zh'
acceptLanguage.get('fr-BE'); // also returns 'en', expected 'fr'

As you can see in this example accept language doesn't fallback to the closest match. I'm not sure if this is a bug or the intended way of working. From your tests it appears you support the other way around - less specific get returns the closest defined language.

micky2be commented 7 years ago

I agree. If we propose ['en', 'fr'] in our list, 'fr-BE' or 'fr-FR' should match with 'fr' and not default to 'en'.

tinganho commented 7 years ago

hm, I probably misinterpretted RFC 4647 https://tools.ietf.org/html/rfc4647#section-3.4.

I thought, that it shouldn't match a more specific fr-BE with a more broader one fr. I have done the opposite. If you support zh-CN and the user requests zhit will return zh-CN, but not the other way around.

But after having read through the docs. It seems I've done wrong. I will read it more carefully later and maybe correct this.

micky2be commented 7 years ago

@tinganho any feedback on this yet?

tinganho commented 7 years ago

@micky2be Sorry for the delay. I will try to take a closer look in the very close future :)

But it seems like we should only revert the matching algo.

tinganho commented 7 years ago

This should be now fixed and it conforms now to RFC 4647 https://tools.ietf.org/html/rfc4647#section-3.4.