-
-
Notifications
You must be signed in to change notification settings - Fork 592
Description
Current behavior
Actually, when we do change the app language, and reload the page, the currentLang
is lost and we start all over again.
Expected behavior
Being able, if wished, to keep the currentLang
even after reload.
What is the motivation / use case for changing the behavior?
- Opt-in for his first version, this would be just a real nice addition to the library.
- A lot of people are creating their own service just to deal with this. (Pretty sure every Ionic/Angular users in the fact)
- People doing there own things is sub-optimal, as
a. The library instantiate first -> fetch the default lang
b. The user instantiate his own service -> get the stored langage -> set this as being the used one
c. This trigger a new fetch for the new set of language -> AKA one useless request being sent.
How do you think that we should implement this?
- A new config
storage?: {
type: 'localStorage' | 'sessionStorage'
key?: 'CURRENT_LANG' | string
}
-
Type
The type let you select if you wish to have it saved inside the local or session storage.
Note: if wished and later down the road, other, more persistent storage type could be implemented -
Key
I would default toCURRENT_LANG
or something that is meaningful to the whom is reading the storage information -
Change in the
lang
/fallbackLang
logic
Note: can/should be done in a separate issue as it has some implication & require langs to be implemented.
If nolang
has been added to the config, I would use
a. The storage if the config exists
b. The browserLang if the value is found inside thelangs
array
c. The fallback if the config exists.
d. The firstlangs[0]
if the config exists
Therefore, if lang
is provided, this would override the storage
information.
Afterthought. (Test to be added)
such implementation will enable
- semi persistent storage
- The use of different storage in case of lazy loaded - library usage
- The use of the same storage/lang across external libraries.
- The use of
lang
to override the storage logic
Doc update
Even if this issue is not adding any breaking change, I would propose to update the doc, as a new more easy way will be enable for user to use an even more powerful library.
- You provide the
langs
, the storage, and you're free to go.