V3.3 multilingual UI and localization foundation

[sanskarIN]

Goal

Prepare SpellChecker 3.3.0 as the next minor release after the V3.2 cross-platform/release-distribution stabilization line.

V3.3 should improve multilingual usability without changing the privacy-first local analysis model or coupling application UI language to the selected spelling language.

Proposed scope

1. Searchable spelling-language selection

• Replace the increasingly crowded 13-item language dropdown with an accessible searchable picker.
• Search by display name and stable language ID.
• Preserve the current selected-language persistence and recheck behavior.
• Keep keyboard navigation and large-text/narrow-layout behavior usable.
• Do not add a new persistence key unless the UX genuinely requires one.

2. Flutter UI localization foundation

• Use Flutter's current source-generated localization flow (flutter_localizations, generated app-localization source, ARB resources).
• Keep UI locale separate from SpellLanguagePack; changing spelling language must not silently change application UI language.
• Keep English as the fallback/default UI locale.
• Add the first reviewed non-English UI locale only when the complete user-facing string surface for the chosen scope is translated and tested; avoid a misleading partially localized interface.
• Ensure generated localization source is kept within the app source tree rather than relying on the removed synthetic flutter_gen package path.

3. Accessibility and layout

• Verify locale changes at large text scale and narrow widths.
• Preserve semantic labels, F1 shortcut help, Writing insights keyboard flows, and issue navigation.
• Review expansion-prone translated strings for overflow instead of assuming English geometry.

4. Compatibility and privacy

• No cloud translation, telemetry, accounts, document upload, or runtime language downloads.
• Spelling language IDs, writing-rule IDs, Portable Settings format, personal-dictionary format, and existing preference semantics remain compatible unless explicitly redesigned.
• UI locale is a presentation concern and must not alter deterministic spelling/writing results.

5. Validation

• Canonical Dart formatting.
• flutter analyze.
• Full Flutter test suite.
• Locale-resolution and searchable-language-picker widget regressions.
• Existing benchmark smoke.
• Documentation/metadata audit.
• Six-platform release-mode build matrix.

6. Release preparation

• Target package identity: 3.3.0+26 once the release branch is ready to become the current package line.
• Update About/version assertions, changelog, current-version docs, release history, roadmap, accessibility/user/configuration docs, and platform/release evidence together with the version bump.
• Do not tag or publish V3.3 until the complete release gates are green on the exact reviewed commit.

Non-goals

• Automatic spelling-language detection.
• Cloud translation or generative rewriting.
• Dynamic downloading/execution of translation or plugin code.
• Coupling UI locale to document/spelling language.
• Production store signing/notarization work that requires private credentials.

Sequencing

1. Finish and merge the remaining V3.2 tagged-release hardening.
2. Create the V3.3 working branch from that exact final main.
3. Land searchable language-picker UX and regressions.
4. Add localization infrastructure and the first fully reviewed locale scope.
5. Perform the coordinated 3.3.0+26 release-identity/documentation update only after feature behavior is stable.