Support an array of locales to set the current locale

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.

https://github.com/kaisermann/svelte-i18n/blob/0516bb417c4d510e5cd5d225b60cb6ad469118a5/src/runtime/stores/dictionary.ts#L36

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

[cupcakearmy]

Sure!

So immagine a site X has localised content for ['en', 'de', 'es']. A user Y has it’s browser/os setup with italian as first and spanish as second languge. this resulst in accept-language and window.navigator.languages to have a content similar to it,es.

Currently, as the lib only supports one language, the webpage would try to load locales for it, not finding them and falling back to en. However in theory they would have had es in common.

So we need to write additional code to handle this behavior.

1. Lookup what languages are available (en, de, es)
2. See what languages are preferred by the user (it, es) and generate subversions of it (it-IT -> it, etc.)
3. Match the first best, or default to the fallback one <- this behaviour is already in the library if i’m not mistaken

Hope this clears up the confusion 😃

[kaisermann]

I’ve released an alpha version 3.5.0-alpha.0 and this is the PR. I can’t test this within the scope of Svelte right now though