Support an array of locales to set the current locale
See original GitHub issueIs 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:
- Either expose those functions so they don’t need to be duplicated by the dev.
- 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
Issue Analytics
- State:
- Created 10 months ago
- Comments:8 (8 by maintainers)
Sure!
So immagine a site
X
has localised content for['en', 'de', 'es']
. A userY
has it’s browser/os setup with italian as first and spanish as second languge. this resulst inaccept-language
andwindow.navigator.languages
to have a content similar toit,es
.Currently, as the lib only supports one language, the webpage would try to load locales for
it
, not finding them and falling back toen
. However in theory they would have hades
in common.So we need to write additional code to handle this behavior.
Hope this clears up the confusion 😃
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