Is your feature request related to a problem? Please describe.

This lib has the notion of a single locale store. From there possible variations are extrapolated.

However in the real world both the Accept-Language headers and navigator.languages expose multiple languages, in order of user preference. This is a very useful feature as they can be used as a fallback if a specific is not available, before falling back to the global fallbackLocale

The issue is that right now this logic is not exposed and needs to be handled by the developer by iterating the available languages, creating subsets (en, en-US, etc.) and then match them agains the $locales available in the lib.

Describe the solution you'd like

Since the language matching feature is already in the codabase and does basically that one could:

1. Either expose those functions so they don't need to be duplicated by the dev.
2. Allow the $locale store to also, beside a string, give a list of strings.

Personally I'd say options 2 is the way to go

Describe alternatives you've considered

Write the logic in every project, for every dev. def. duable but it's a pity as most of the logic, as stated above, is alrady in the lib.

How important is this feature to you?

Not dealbreaking but it would def. be a welcome addition.

Additional context

• https://developer.mozilla.org/en-US/docs/Web/API/Navigator/languages
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Language