Proposal: ship Korean as a built-in locale (branch ready)

[v9bm4pfnz6-hue]

dsh ships two built-in locales (Chinese and English), so a Korean reader has no selectable language: the settings Language row offers only 中文 and English, and browser language matching has nothing to resolve for ko.

I prepared a branch that adds Korean as a third built-in locale and translates the shipped UI. Since CONTRIBUTING says external pull requests are not accepted yet, this post is the public record; the branch is ready to pull in or rebase.

What the branch changes

• LOCALE_IDS becomes ['zh', 'ko', 'en'] with a 한국어 definition falling back to en, so selection, persistence, browser matching, and <html lang> cover Korean through the existing definition path. The desktop shell resolver (apps/desktop/src/locale.ts) accepts ko for its menus, welcome window, and update dialogs.
• Every typed ctx.locale.register(ns, …) now requires the Korean dictionary: adding the id to BuiltInLocaleId makes the existing Record<BuiltInLocaleId, LocaleDictOf<N>> seat demand it, so a package that adds copy without Korean fails typecheck. Every shipped client namespace, the shared common vocabulary, settings rows, the desktop shell dictionary, and the shared frequency and zoom fragments are translated (~2,900 keys across 66 dictionaries).
• scripts/locale-dictionary-parity.spec.ts now requires every shipped locale for each discovered dictionary group with identical keys against the zh source of truth, covering the inline-array and spread shapes a single type cannot reach.
• An Agent Note (.agents/notes/implemented/architecture/2026-10-23-korean-built-in-locale.md) records the decision and rejects the alternative: an external pack through addLanguage cannot force coverage, so untranslated keys would silently fall back to English. The language-pack path stays available for languages that will never be complete.
• No command, configuration, API, protocol, or persistence-format change, and no model-facing change.

Verification

pnpm run typecheck (host/client compilers and aggregates), pnpm run test:gui (10,764 passed), npx vitest run scripts/locale-dictionary-parity.spec.ts, pnpm run verify-client-ui-i18n (1,061 client UI sources), pnpm run build:artifacts + pnpm run build:check, pnpm run verify-md-links, plus a served-bundle check on a built install.

Links

• Branch: https://github.com/v9bm4pfnz6-hue/deepseek-harness/tree/feat/korean-locale
• Diff against master: master...v9bm4pfnz6-hue:feat/korean-locale
• Single commit: 1091f232fd

Happy to rebase, split the change (catalog + gates first, translations after), or turn it into anything that fits the roadmap.

[Nolitor]

Thank you for preparing such an extensive and thorough translation work. Having Korean available makes a huge difference for daily productivity.

While reviewing your proposal, I noticed that directly modifying LOCALE_IDS and core dictionaries requires rebuilding from source, which makes upstream maintenance tricky and introduces runtime isolation concerns before an official PR is merged.

To provide an immediately usable and safe alternative, I packaged these translations using DSH’s official external plugin API (ctx.locale.addLanguage + ctx.locale.register), complete with scoped typography enhancements:

Complete Isolation: Packaged cleanly as an independent plugin without touching any core engine files or global environments. It supports instant 1-click install and 100% clean rollback.

Full Translation Parity: Reused and verified all 65 client namespaces (~2,910 keys) with zero key/placeholder mismatches.

Scoped Typography: Injected an optimized Korean font-family fallback stack (Pretendard Variable, SUIT, Apple SD Gothic Neo, etc.) scoped strictly to html:lang(ko) body. Monospace seats (--ds-font-family-code, terminal) and user-defined custom theme settings remain completely untouched.

Graceful Yielding: Built with an initial guard so it automatically steps aside without conflicts if DSH upstream introduces built-in Korean support later on.

For anyone who wants to use Korean right away without waiting for core merges or altering local builds, the repository and installation steps are available here:

👉 linuxsung/dsh-korean-locale

Huge thanks again for kickstarting the localization effort!

[unera]

Related proposal, may matter for how this one ships: make the UI locale an ordered preference list (e.g. ru → en → zh) instead of a single choice, so a partly translated UI falls back to a language the user actually reads rather than to untranslated islands and Chinese source keys. It also keeps the shipped-locale set from being a closed enum.

Details and a link list of the other language threads: #11699