feat(i18n): dependency-free i18n foundation + Simplified Chinese (zh-CN)

[Brent (lizheng220)]

Closes nothing yet — opening this as a draft proposal for #64, which is still awaiting maintainer guidance on the preferred i18n architecture. I'd rather put something concrete on the table than ask in the abstract. Happy to reshape it, split it, or close it if you'd prefer a different direction.

Credit where it's due: #64 was filed by YouLin (@q438241zy), who offered to review Simplified Chinese terminology, contribute translations, and test on Windows 11 zh-CN. This PR deliberately leaves the bulk of the translation work open for exactly that.

Why

Narration transcription already supports 99 languages, but the UI, dialogs, error messages and accessibility labels are English-only. This adds the foundation for translating them, plus Simplified Chinese as the first locale.

Why no i18n library

The app ships a reviewed third-party manifest — scripts/compliance.mjs, THIRD-PARTY-NOTICES.md, per-package license archival, verify-packaged-compliance.mjs at pack time. Adding i18next/react-i18next would put a compliance review in the path of behaviour that fits in ~40 lines. So src/i18n/translate.ts is the whole engine: catalogue lookup, per-message English fallback, {name} interpolation. No new dependency, package-lock.json untouched.

What's here

• common/locale.ts — supported UI locales and resolveUiLocale(), mapping the tags app.getLocale()/navigator.language actually emit (zh, zh-CN, zh_CN, zh-Hans-CN, en-GB) onto one. Script beats region, so zh-Hant-CN isn't read as Simplified; zh-TW/zh-HK fall back to English until a Traditional catalogue exists.
• electron/ui-locale.ts — UiLocaleStore: an explicit stored choice, else the OS locale. Takes its dependencies as arguments rather than importing electron, so it tests under plain Node with no changes to evals/electron-stub.mjs. A missing, malformed or unsupported preference file resolves to the OS locale instead of failing startup; an unwritable userData still applies the choice for the session and logs.
• src/i18n/ — the English catalogue is the source of truth and its keys form MessageKey, so t() with an unknown key fails the build. zh-CN is typed Partial<Record<MessageKey, string>> on purpose: a translation is allowed to lag English, and anything missing or blank falls back per message rather than blocking a change to the source language.
• IPC (ui:locale / ui:set-locale / ui:locale-changed) — the recorder, controls, library and terminal each mount their own React root in their own window, so a language change is broadcast from main rather than shared through renderer state.
• An "App language" picker at the top of the existing recording-settings panel.

UI language stays independent of the narration transcription language and of the generated Skill/Automation language, per the issue.

Scope

Foundation + RecordingControls.tsx migrated in full (43 messages) as the proof surface — it exercises text nodes, aria-label, title and interpolation together. The remaining surfaces (Library.tsx is the big one at ~80 strings, then Recorder.tsx, plan-edit.tsx, WhatsRecorded.tsx, SensitiveReview.tsx, RecordingPrivacyWarning.tsx) would follow one PR per surface, so each stays reviewable. English output is unchanged at every step.

Verification

Workflow runs on fork PRs sit at action_required until a maintainer approves them, so here is what I ran locally (Windows 11, Node 24):

• npm run typecheck — clean
• npm test — 188/188 pass, 12 of them new; no existing test modified
• npm run build:vite — builds (the >500 kB chunk warning is pre-existing: the renderer chunk is 701 kB, this adds ~5 kB)
• Mutation check on the guard that matters: dropping {device} from one zh-CN message makes zh-CN keeps every placeholder its English message uses fail as intended, then passes again once restored — the test isn't decorative.

New tests cover locale resolution (including Traditional-vs-Simplified), store persistence, a corrupt preference file, an unwritable directory, fallback and interpolation, and two catalogue-integrity checks: that zh-CN defines no key English lacks, and that a translation preserves every placeholder its English message uses (a dropped {device} would otherwise silently lose the device name).

Two things I'd like your call on

1. The settings panel now shows App language (UI) directly above the existing Language (narration transcription). Would you like the existing label changed to something like "Narration language", or left alone to keep the diff surgical? I left it alone.
2. narrationLanguageLabel() returns English names for all 99 Whisper languages, so that picker stays English under zh-CN. Localizing those is a separate and much larger job — follow-up, or out of scope?

Based on release/0.6.0 per .github/copilot-instructions.md.

[Brent (lizheng220)]

@microsoft-github-policy-service agree