Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

startLocale may not be used #430

Open
emri99 opened this issue Sep 10, 2021 · 3 comments · May be fixed by #683
Open

startLocale may not be used #430

emri99 opened this issue Sep 10, 2021 · 3 comments · May be fixed by #683
Labels
bug Something isn't working

Comments

@emri99
Copy link

emri99 commented Sep 10, 2021

Depending on arguments passed to the EasyLocalization widget, the startLocale 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 :

  • A locale must be saved in sharedPreferences as locale key (I think its value is not important, but it must exists)
  • When instanciating EasyLocalisationwiget:
    • saveLocale argument must be set to false
    • startLocale argument must be supply
      optionally the same as saved in locale key, but at least it must be different of the device locale otherwise the issue is not visible

Source code issue explanation
Source code of controller where the problem occurs annotated :

class EasyLocalizationController extends ChangeNotifier {
  static Locale? _savedLocale;   ## value initialized in static method
                                 ## initEasyLocation
  // ....

  EasyLocalizationController({
    // ....
    required this.saveLocale,  # false
    // ....
    Locale? startLocale,   # value initialized to anything else than device locale to see the problem
    // ....
  }) {
    _fallbackLocale = fallbackLocale;
    if (forceLocale != null) {
      _locale = forceLocale;

   // #### ISSUE IS HERE #####
   // #### startLocale is NOT USED because the `_savedLocale` is read ####
   // #### from the `locale` SharedPreferences key, which is the one ####
   // #### we use internally in our app ####
    } else if (_savedLocale == null && startLocale != null) {
      _locale = _getFallbackLocale(supportedLocales, startLocale);
      EasyLocalization.logger('Start locale loaded ${_locale.toString()}');
    }

    // ####
    // #### It don't match this condition neither as `saveLocale` is false ####
    // If saved locale then get
    else if (saveLocale && _savedLocale != null) {
      EasyLocalization.logger('Saved locale loaded ${_savedLocale.toString()}');
      _locale = _savedLocale!;

    // ####
    // #### so although we supply a startLocale, it's ignored ####
    // #### and the device locale is used ####
    } else {
      // From Device Locale
      _locale = supportedLocales.firstWhere(
          (locale) => _checkInitLocale(locale, _deviceLocale),
          orElse: () => _getFallbackLocale(supportedLocales, fallbackLocale));
    }
  // ...

  
  static Future<void> initEasyLocation() async {
    final _preferences = await SharedPreferences.getInstance();

    // #### read from SharedPreferences that can be written easily ####
    // #### outside of this class due to a too common SP key ####
    final _strLocale = _preferences.getString('locale');
    _savedLocale = _strLocale != null ? _strLocale.toLocale() : null;

  // ...

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 like easy_localization_locale.

@jgoyvaerts
Copy link

+1 same issue.

@emri99
Copy link
Author

emri99 commented Apr 26, 2022

A workaround is to rename your own sharedpreferences key containing the expected locale to use ;)

@jgoyvaerts
Copy link

A workaround is to rename your own sharedpreferences key containing the expected locale to use ;)

Yea, we did that, still annoying though :)

@bw-flagship bw-flagship added the bug Something isn't working label May 14, 2023
gkhloptov added a commit to gkhloptov/easy_localization that referenced this issue Dec 21, 2023
gkhloptov added a commit to gkhloptov/easy_localization that referenced this issue Jun 3, 2024
gkhloptov added a commit to gkhloptov/easy_localization that referenced this issue Jun 3, 2024
Ignore _savedLocale on start when saveLocale is false (aissat#430)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants