feat(i18n): dependency-free i18n foundation + Simplified Chinese (zh-CN) - #72
Draft
Brent (lizheng220) wants to merge 1 commit into
Draft
Conversation
The UI, dialogs, errors and accessibility labels are English-only even
though narration transcription already supports 99 languages. Add the
foundation for translating them, and Simplified Chinese as the first
locale.
The app ships a reviewed third-party manifest, so a runtime i18n library
would put a compliance review in the path of behaviour that fits in a
few lines: `translate()` does catalogue lookup, per-message English
fallback and `{name}` interpolation, and the English catalogue's keys
type every `t()` call.
The interface language is an explicit stored choice, else the OS locale.
`resolveUiLocale()` maps the tags `app.getLocale()` actually emits, with
script beating region so `zh-Hant-CN` is not read as Simplified. A
malformed preference file or an unwritable userData degrades instead of
failing. Because the recorder, controls, library and terminal each own a
React root in their own window, a change is broadcast from main.
Migrates RecordingControls as the proof surface; the remaining surfaces
follow separately. English output is unchanged.
Refs microsoft#64
|
Brent (@lizheng220) please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
Contributor License AgreementContribution License AgreementThis Contribution License Agreement (“Agreement”) is agreed to by the party signing below (“You”),
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.mjsat pack time. Addingi18next/react-i18nextwould put a compliance review in the path of behaviour that fits in ~40 lines. Sosrc/i18n/translate.tsis the whole engine: catalogue lookup, per-message English fallback,{name}interpolation. No new dependency,package-lock.jsonuntouched.What's here
common/locale.ts— supported UI locales andresolveUiLocale(), mapping the tagsapp.getLocale()/navigator.languageactually emit (zh,zh-CN,zh_CN,zh-Hans-CN,en-GB) onto one. Script beats region, sozh-Hant-CNisn't read as Simplified;zh-TW/zh-HKfall 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 importingelectron, so it tests under plain Node with no changes toevals/electron-stub.mjs. A missing, malformed or unsupported preference file resolves to the OS locale instead of failing startup; an unwritableuserDatastill applies the choice for the session and logs.src/i18n/— the English catalogue is the source of truth and its keys formMessageKey, sot()with an unknown key fails the build.zh-CNis typedPartial<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.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.UI language stays independent of the narration transcription language and of the generated Skill/Automation language, per the issue.
Scope
Foundation +
RecordingControls.tsxmigrated in full (43 messages) as the proof surface — it exercises text nodes,aria-label,titleand interpolation together. The remaining surfaces (Library.tsxis the big one at ~80 strings, thenRecorder.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_requireduntil a maintainer approves them, so here is what I ran locally (Windows 11, Node 24):npm run typecheck— cleannpm test— 188/188 pass, 12 of them new; no existing test modifiednpm run build:vite— builds (the >500 kB chunk warning is pre-existing: the renderer chunk is 701 kB, this adds ~5 kB){device}from one zh-CN message makeszh-CN keeps every placeholder its English message usesfail 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-CNdefines 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
narrationLanguageLabel()returns English names for all 99 Whisper languages, so that picker stays English underzh-CN. Localizing those is a separate and much larger job — follow-up, or out of scope?Based on
release/0.6.0per.github/copilot-instructions.md.