Feat/dynamic content languages#515
Conversation
…ents - Introduced ContentLanguageNotifier to manage the content language sent to backend APIs, allowing for independent selection from the UI locale. - Added AppLanguage class to represent content languages with properties for code, name, and native name. - Implemented languagesRemoteDatasource to fetch available content languages from the backend, with fallback to bundled languages. - Updated locale management in MoreScreen and OnboardingScreen to synchronize UI locale and content language selection. - Enhanced storage keys to accommodate new content language preferences. - Added tests for ContentLanguageNotifier to ensure proper functionality and migration from legacy UI locale.
Confidence Score: 4/5The reconciliation race should be fixed before merging.
lib/core/localization/languages_providers.dart and lib/core/config/locale/locale_notifier.dart Reviews (3): Last reviewed commit: "refactor: improve content language recon..." | Re-trigger Greptile |
- Introduced a user selection flag in LocaleNotifier and ContentLanguageNotifier to prioritize explicit user choices over automatic initialization reads. - Updated logic to prevent clobbering user-selected languages during the initialization phase. - Added a new blocking storage class for testing, allowing for controlled resolution of storage reads during initialization. - Enhanced tests to verify that user selections persist correctly even when legacy data is present.
- Implemented reconcileToAvailable in ContentLanguageNotifier to enforce server-side language availability, ensuring that disabled languages are replaced with a valid selection. - Updated availableContentLanguagesProvider to call reconcileToAvailable when fetching languages from the backend.
- Updated the reconcileToAvailable method to return the fallback language when the current selection is disabled, ensuring a valid language is always set. - Enhanced the availableContentLanguagesProvider to handle authoritative empty responses correctly, maintaining UI locale consistency.
| if (switched != null) { | ||
| await ref.read(localeProvider.notifier).applyUiLocaleForContent(switched); |
There was a problem hiding this comment.
switched records the fallback chosen before reconcileToAvailable finishes its asynchronous storage write. If the user selects another enabled language while that write is pending, selectAppLanguage can update both states to the new choice before this continuation applies the stale fallback to the UI only. Content requests then use the user's language while the interface uses the fallback. Reconciliation must be coordinated with explicit selection, or confirm that the content language still equals switched before updating the UI locale.
spilt localisation for system and content under the hood