Open emri99 opened 3 years ago
+1 same issue.
A workaround is to rename your own sharedpreferences key containing the expected locale to use ;)
A workaround is to rename your own sharedpreferences key containing the expected locale to use ;)
Yea, we did that, still annoying though :)
Depending on arguments passed to the
EasyLocalization
widget, thestartLocale
is not used.Problem encountered The device locale is used as initial locale even if we supply another value in
startLocale
argument.Why is this happenning ? In our case, this happens because we explicitly ask the widget not to handle save & restoration to handle it in our app, and we store the locale in SharedPreferences with the same key than this package.
Context to reproduce To get into this usecase :
locale
key (I think its value is not important, but it must exists)EasyLocalisation
wiget:saveLocale
argument must be set to falsestartLocale
argument must be supply optionally the same as saved inlocale
key, but at least it must be different of the device locale otherwise the issue is not visibleSource code issue explanation Source code of controller where the problem occurs annotated :
Potential resolution IMHO, the
locale
SharedPreferences key is too common and can conflict with the application one, I think it should be more package specific likeeasy_localization_locale
.