Skip to content

Feat/dynamic content languages#515

Open
tentamdin wants to merge 5 commits into
developfrom
feat/dynamic-content-languages
Open

Feat/dynamic content languages#515
tentamdin wants to merge 5 commits into
developfrom
feat/dynamic-content-languages

Conversation

@tentamdin

Copy link
Copy Markdown
Member

spilt localisation for system and content under the hood

…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.
@greptile-apps

greptile-apps Bot commented Jul 20, 2026

Copy link
Copy Markdown
Contributor

Confidence Score: 4/5

The reconciliation race should be fixed before merging.

  • Startup initialization now preserves explicit selections.
  • Empty and disabled language responses are reconciled.
  • A concurrent user selection can still leave the UI and content languages different.

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

Comment thread lib/core/config/locale/locale_notifier.dart Outdated
Comment thread lib/core/localization/data/languages_remote_datasource.dart
- 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.
Comment thread lib/core/localization/languages_providers.dart
Comment thread lib/core/config/locale/locale_notifier.dart
- 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.
Comment on lines +34 to +35
if (switched != null) {
await ref.read(localeProvider.notifier).applyUiLocaleForContent(switched);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Stale fallback splits state

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant