avansai / resolve-accept-language Goto Github PK

Hello,

thank you for this very useful package! It would be awesome if the type definitions supported a bit nicer inferring of return values. This way one could use literal string values.

Based on my testing something like this in resolveAcceptLanguage would already help:

const resolveAcceptLanguage = <TLocale extends string>(
  acceptLanguageHeader: string,
  locales: TLocale[],
  defaultLocale: TLocale
): TLocale => {

It would allow type inference like:

As mentionned here, Chrome seems to support additional locales like es-419 which is being filtered out by the current regular expression.

We need to update the RegExp to provide additional support.

Is there a specific reason why a new version is released so often? If only the dev dependencies are updated, I see no reason for a new release, but maybe I'm missing something.

As far as I can tell, es-419 is a valid tag, but I get an error saying invalid locale identifier 'es-419'.

Thank you for you great package.

In the event that no languages match, it can be interesting to serve language agnostic content (such as a language selector) rather than content in an arbitrary default language. Unfortunately the current API does not allow the caller to identify when no languages match. A suggested API might be to allow undefined to be passed as the default language, which would result in undefined being returned when no matches are found. This would admittedly make the return typing dirtier since it would force callers to check for undefined even when a default language was provided.

as documented, the locales array should be set as const, so that it can infer the types.

however as const makes the array readonly (which is correct), but this library does not accept readonly string array.

https://github.com/Avansai/resolve-accept-language/blob/main/src/index.ts#L76 should probably be extends readonly String[]

Hi @nbouvrette, thank you for the fantastic library! 🙌

One question though, should underscores also be considered in the resolving algorithm?

For example:

var resolveAcceptLanguage = require("resolve-accept-language")

console.log(
  resolveAcceptLanguage.default('de_DE;q=0.01,en-CA;q=0.1,en-US;q=0.001', ['en-US', 'fr-CA', 'de-DE'], 'en-US')
);

I would expect to be parsed to de-DE but results in en-US instead.

Wondering if this is intended behaviour and if so how come (for my own knowledge), or if this is a bug (edit: an improvement that makes sense for the library to have).

Hi,

When i have the the AcceptLangauage header: de,de-DE;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6 and then pass the locales: ['de-AT', 'de-DE']. The local de-AT gets matched based on the language.

I think the package should return the exact matcht. In this case de-DE

What do you think about this?

If you need more information please hit me up.

Hello, thank you for this library. I just have a suggestion for an additional (maybe optional) MatchType:

When all other MatchTypes have found nothing and the current implementation would return the defaultLocale, attempt the following match:

• Only look at the country codes. What is the highest quality country code that is also a country code in one of the supported locales?
• Return the first supported locale with that country code

This MatchType would basically be the same as the already implemented "relatedLocaleBased", just for countries instead of languages. The idea behind it is that if no language matches, it would be better to at least stay in the country you're accepting instead of using the default locale which is not in your language and probably also not your country.

Example:

• the user only accepts "af-ZA"
• the default locale is "en-US"
• none of the supported locales support the language "af", but one of those locales is "en-ZA"

With this new MatchType, the user would receive "en-ZA", which is a better match for them than the default "en-US" because at least the country would still match their preference.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Language#examples

please more support. Adding 2-language builds would also be good.