Skip to content

Default to the system language instead of a fixed English locale - #688

Open
Angle-AOB wants to merge 1 commit into
IridiumIO:masterfrom
Angle-AOB:feat/follow-system-language
Open

Angle-AOB wants to merge 1 commit into
IridiumIO:masterfrom
Angle-AOB:feat/follow-system-language

Conversation

@Angle-AOB

Copy link
Copy Markdown

What

An empty Language setting now means "follow the system language" instead of falling back to a hard-coded en-AU.

Resolution order, against the catalogues that are actually installed:

  1. exact culture match (zh-CN -> zh-CN.toml)
  2. primary language subtag (zh-TW/zh-HK -> zh-CN; en-US/en-GB -> en-AU)
  3. the en-AU source culture

The detected culture is deliberately not written back to settings.json - persisting it would freeze the value and stop the app following later changes to the Windows display language.

Refs #388.

Why no "follow system language" dropdown entry

The empty setting is the follow-system state. A dropdown row would need a second sentinel that survives the round trip through ComboBox.SelectedIndex, and picking a real language already makes the choice sticky via LoadLanguage(). The settings page keeps showing whichever language is actually active because CurrentLanguage reads L.CurrentCulture, not the setting.

Scope: new installs only, on purpose

SettingsService.LoadSettings() re-serialises settings on every start, so every existing install already has "language": "en-AU" on disk - indistinguishable from a deliberate choice. Migrating them would need either a new LanguageSetExplicitly field, or a SettingsVersion bump that resets every other setting. Neither seemed worth it for a default; happy to add the field if you'd rather upgraders picked this up too.

One existing path had to change

SettingsViewModel.CheckForLanguageUpdates() called LoadLanguage(AppSettings.Language) in both arms of an if/else whose branches were identical. With an empty setting that becomes L.TryLoadLanguage(""), which fails - silently turning the "Reload Languages" button into a no-op. It now reloads the culture that is actually loaded, and no longer re-persists a language the user never chose. CheckForLanguageUpdate() likewise keys off L.CurrentCulture.Name.

Verification

  • Builds Debug and Release; the 6 existing tests pass.
  • On a zh-CN Windows install with the setting empty, the UI comes up in Simplified Chinese, and the settings dropdown shows it selected.
  • Picking a language in the UI still persists and still wins over detection.
  • Not verified: a system language with no catalogue, where the catalogue is later downloaded.

Unrelated, but it blocked building

The committed NuGet.Config points at ..\LazyTranslate\artifacts, and neither LazyTranslate nor LazyTranslate.CatalogueBuilder is on nuget.org. The public IridiumIO/LazyTranslate master is at 0.1.0 and is missing three things this repo already uses - LocalisationOptions.ProgramVersion, .OutputMissingTranslationsToDebug, and the loc:MultiBinding markup extension - so dotnet restore fails from a clean clone. I patched a local copy to compile this. Flagging it in case the gap is unintentional rather than just an unpublished package.

An empty Language setting now means "follow CultureInfo.CurrentUICulture",
matched against the catalogues that are actually installed: exact culture
first, then the primary language subtag, then the en-AU source culture.

The detected culture is deliberately not written back to settings, so the
app keeps following later changes to the OS display language. Existing
installs keep whatever they already saved.
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