韩语语言包 ara-hwang/dsh-ko-locale

dsh-ko-locale

DeepSeek Harness 桌面端与 Web GUI 的韩语（한국어）语言包。

它把 ko 加进语言目录，并为随客户端插件注册的每一个命名空间提供韩语文案——56 个命名空间、2,412 条字符串，覆盖整个 Web GUI 界面（聊天、会话、轨迹、工作区、侧边栏、设置、插件、任务、子代理、交付物、日程、语音输入……）。

你能得到什么

- 设置 → 通用 → 语言里出现韩语。 它排在 English 和中文旁边，选中后和其他 DSH 语言选项一样会被持久保存。
- 韩语系统上自动显示韩语。 全新配置档所在的机器，只要系统或浏览器语言要求韩语，界面就以韩语打开。显式选择语言时始终以你的选择为准。
- 按键回退。 语言包没有覆盖的字符串（比如 DSH 更新新增的文案，或你之后装的插件），会回退到随包发布的英文词典，而不是显示原始键名。

安装

语言包已发布到 npm，一条命令即可装好依赖并选中该 bundle：

dsh plugin --profile desktop add dsh-ko-locale

用你实际运行的配置档：桌面应用用 desktop，dsh web 用 web。然后重新加载 GUI（Ctrl+R）。之后如果包有改动，需要完全重启应用，因为 Host 会保留已经加载的模块代际。

没有 npm 访问权限时，同一条命令可以直接指向仓库——构建好的浏览器 bundle 已提交，无需构建步骤：

dsh plugin --profile desktop add github:ara-hwang/dsh-ko-locale

dsh 随桌面应用一起发布，位于 resources/runtime/cli/bin/dsh.cmd。设置 → 插件页面执行的是同样两步，当该目录不在 PATH 上时这是更省事的方式。安装失败会自动还原 package.json 和 lockfile。

手动安装

如果想针对本地检出开发而不是已发布版本，把配置档清单指向它。编辑 ~/.dsh/profiles/<profile>/package.json：

{
"dependencies": {
"dsh-ko-locale": "file:../../path/to/dsh-ko-locale"
},
"dsh": {
"profile": {
"bundles": [
"@deepseek-ai/dsh-base",
"@deepseek-ai/dsh-web-app",
"dsh-ko-locale"
]
}
}
}

然后在配置档目录里运行 pnpm install。file: 依赖会硬链接进配置档，所以在这里重新构建会就地替换已安装的 bundle——运行中的应用会在下次重组或重启时用上新产物。

卸载

从 dsh.profile.bundles 和 dependencies 里删掉 "dsh-ko-locale"，然后在配置档目录里再运行一次 pnpm install 并重启。韩语目录条目和 overlay 都是插件自己拥有的 effect，所以 GUI 会回到英文，不留任何残留。

工作原理

两项贡献，都是同一个客户端插件自己拥有的 effect：
1. 语言定义 —— ctx.locale.addLanguage({ id: 'ko', label: '한국어', fallback: 'en' })，这是 @deepseek-ai/dsh-client-locale 里公开的入口。
2. 字典覆盖层，装在 LocaleRuntime.prototype.lookup 上。

为什么用覆盖层，而不是直接用 ctx.locale.register

LocaleRuntime.register 会拒绝已经存在的 namespace/locale 组合：

for (const [locale] of pairs) if (locales.has(localeKey(locale)))
throw new Error(locale namespace "${ns}" already has locale "${locale}")

这个语言包要翻译的每个 namespace，都已经由它所属的包为 zh 和 en 注册过了，而且没有替换或合并的入口。所以语言包没法通过公开的字典 API 接管内置 namespace。lookup 是所有翻译读取都会经过的唯一缝隙（bind → translate → lookup），覆盖它就能触达全部文案——包括插槽渲染的文本——而且不用改动任何包。

有两个后果需要显式处理：

- register 也要包一层。 如果某个别的插件把某个 namespace 本地化成了韩语，就记录下来，这个语言包让位给它，这样自带 ko 字典的插件会胜过覆盖层。
- publish 会让当前语言的缓存失效，所以切换语言能立刻生效。

自主启动

LocaleRuntime 在构造函数里就推导出临时语言，早于任何语言包注册，而 addLanguage 通过 publishCatalog → localeList → resolveActive 发布，这几步读的是上一份快照。所以两处都要调整：

- localeList 上报目录，这样正在添加的语言不会从它正被加进去的列表里掉出去。
- resolveActive 在什么都没存储时重新决定临时语言，这样韩语机器会以韩语打开，而不是英语。

这个语言包碰过的所有东西都由它的 disposer 还原；禁用插件后运行时回到原来的行为（已在 tools/smoke-test.mjs 中验证）。

目录结构

| 路径 | 作用 |
| src/client.js | 浏览器端——目录注册、覆盖层、启动规则 |
| src/index.js | 宿主端——空挂载点（见文件里的注释） |
| data/ko.json | 随包发布的韩语字典，namespace -> { key: text } |
| data/en.json、data/zh.json | 源英语/中文，留作审计 |
| data/overrides.json | 翻译合并后应用的已审核修正 |
| lib/client.js | 生成的 bundle，字典已内联 |
| lib/index.js | 生成的宿主端 |
| cordis.patch.yml | bundle 层：这个包插入的唯一一行 loader |
| tools/asar.mjs | 针对已安装应用的迷你 ASAR 读取器（list / extract） |
| tools/extract-dictionaries.mjs | 从 app.asar 里抽出所有随包发布的 zh/en 字典 |
| tools/prepare-translation.mjs | 把这些字典打包成均衡的翻译分块 |
| tools/verify-translations.mjs | 对照英文原文检查翻译分块 |
| tools/assemble.mjs | 把翻译分块合并进 data/.json |
| tools/audit-untranslated.mjs | 列出仍是英文的值，并给出中文供参考 |
| tools/build.mjs | 把 data/ko.json 内联进 lib/client.js |
| tools/smoke-test.mjs | 拿真实 LocaleRuntime 跑一遍语言包 |
| tools/probe-bundle-route.mjs | 向运行中的应用查询它实际提供的 bundle |

lib/ 是生成出来的 —— 改 src/ 和 data/，然后运行 node tools/build.mjs。

验证

node tools/smoke-test.mjs [path/to/@deepseek-ai/dsh-client-locale/lib/client.js]

测试直接从已安装应用的 app.asar 里读出真实的 LocaleRuntime（只有想测另一个构建时才传显式路径），断言 28 项行为：目录注册、在韩文机器上激活韩文、显式选择、逐键回退英文、销毁后恢复运行时，以及数据完整性（没有空值、没有空命名空间、占位符 token 与英文原文一致）。

想确认运行中的 Host 真的组装并提供了这个语言包 —— 也确认页面的加载器能按 bundle 注册的 id 找到它 —— 就向线上 web 载体询问按 revision 寻址的路由：

node tools/probe-bundle-route.mjs # prints status, bytes and Hangul count

不是已启用 loader 条目的包，对任何 revision 都返回 404；所以 200 加上可观的韩文字符数，就证明了整条链路：配置档依赖 → bundle 补丁 → loader 行 → 启动图 → 提供的 bundle。

DSH 升级后如何更新

DSH 升级可能新增或改写英文字符串。新增内容会自动回退到英文，所以语言包不会坏 —— 只是变得不完整。补齐的办法：

node tools/extract-dictionaries.mjs # app.asar -> ../_work/extracted.json
node tools/prepare-translation.mjs # -> ../_work/chunks/chunk-.json
translate each chunk into ../_work/ko/<chunkId>.json as
{ "id": "<chunkId>", "groups": [{ "ns", "ko": { key: text } }] }
node tools/verify-translations.mjs # missing/blank/odd keys
node tools/assemble.mjs # -> data/en.json, data/zh.json, data/ko.json
node tools/audit-untranslated.mjs # review values that stayed English
node tools/build.mjs # -> lib/client.js
node tools/smoke-test.mjs # behavior against the real runtime

然后在配置档目录里重新运行 pnpm install，重启应用。assemble 这一步会打印覆盖率，所以翻译只做了一部分也能在发布前看出来；你在审阅 audit 输出时做的任何修正，都该写进 data/overrides.json，这样下次重新生成时还能保留。

上面每个路径默认都指向本仓库旁边的临时目录（../_work），该目录不受版本跟踪；每个工具也都可以显式传参。
data/ 和生成的 lib/ 之外，仓库里不会写入任何东西。

发布

先改 package.json 里的版本号，然后发布：

npm publish # add --otp= when the account enforces 2FA

prepublishOnly 会重新构建 lib/，并针对已安装的 LocaleRuntime 跑一遍冒烟测试，所以打包产物一旦和运行时对不上，就进不了 registry。tarball 里只有 LICENSE、README.md、cordis.patch.yml 和生成的 lib/ 文件——共七个文件，打包后约 84 kB——因为配置档解析并加载插件所需的就这些；src/、data/ 和 tools/ 留在仓库里。

把 lib/ 提交进仓库是刻意为之。file: 依赖不会走 prepare，而 DSH 的插件管理器在净化过的环境里跑 pnpm，安装脚本一旦失败整个操作就失败，所以构建好的 bundle 直接随仓库和 tarball 一起发布，而不是在安装时生成。

已知限制

- overlay 面向内部。 它依赖 LocaleRuntime 的方法名（lookup、register、localeList、resolveActive、publish）。DSH 新版本若改了这些名字，这个包会被禁用并在控制台报错，而不会损坏任何东西——它会打印 dsh-ko-locale: unrecognized locale runtime，然后什么都不做。
- 没有复数规则。 和随包发布的语言一样，这个包就是一本扁平字典；韩语复数靠措辞处理，不靠 locale registry。
- 宿主侧文案不在范围内。 有些字符串在 Node 那一半（工具描述、命令行输出、窗口边框）。这个包翻译的是浏览器客户端，也就是桌面 GUI 渲染的那部分。
- 包元数据保持英文。 Plugin 列表通过 ctx.locale.resolveText 渲染每个已安装插件的标题和描述，而它读取的是插件自己 manifest 里写的 LocalizedText 映射。manifest 只带 en/zh，客户端语言包没法往里加条目，所以这些行保持作者写下的语言。
- 注册时捕获的文本（比如在 slot 渲染路径之外注册一次的 command description）会一直保持注册时的语言，直到重新注册——这是 locale 服务本身的限制，不是这个包的问题。

License

MIT — 见 LICENSE。

韩语字符串是参照 DeepSeek Harness 桌面应用内置的英文和中文词典产出的。那些词典归其作者所有；本仓库只包含派生出的韩语译文、提供译文的 overlay，以及重新生成译文的工具。