🎁 福利专区全网大模型免费应用 + 新用户福利 + 注册活动入口,低成本玩转 AI

中文界面英译 oiupoyt/chinese2english

DeepSeek 客户端
oiupoyt13 天前有提交已提供中文文档扫描:未发现敏感能力兼容 / 相关生态

把第三方插件里的中文界面文本自动改写为英文

30.7/100
综合分
1
GitHub 星标
—
npm 周下载
—/5
用户评分

数据截至 2026/10/22 · 周下载取自 npm 全网(含 CI / 镜像),非本站安装数;综合分由星标、活跃度与兼容性检查合成。

相关生态插件(非 dsh 原生,按其对应运行时安装)
git clone https://github.com/oiupoyt/chinese2english.git

状态速览

判定依据:实装验证 · 静态安装检查 · 自动扫描 · 仓库维护状态
信任档位:仅索引
是什么
生态应用
桌面端 / Web 外壳,不以 dsh plugin add 安装
装得上吗
本站尚未做安装检查
L4 · 真实安装等级说明 →
安全吗
本站尚未对该插件做风险分级
暂未覆盖,不等同于无风险
还在维护吗
活跃:最近一次提交在 13 天前
档位由哪些信号合成

本站实装验证(真实安装 L4 覆盖全站;L5 为运行时冒烟或实机截图,覆盖范围小于 L4) · 验证所用 dsh 版本 · 静态安装检查 · 风险分级 · 仓库维护状态。 下方各区块是它的证据明细。

验证判据与等级说明 →
社区实装还没有人打卡 · 装过的第一个就是你
安全扫描自动 · 静态分析源码
v2.7.0
🟢 扫描:未发现敏感能力尚无人工评估
展开查看扫描说明与证据 ↓

静态扫描未发现敏感能力:最多只发网络请求、读取自身元数据或只读文件,未发现执行命令、文件写入或敏感信息读取。

扫描于 2026/11/3(1 天前) · 范围 入口闭包 + 发布文件清单 · 来源 GitHub 仓库

静态扫描只反映源码中出现的调用,不构成安全背书;人工评估与自动扫描相互独立、互不覆盖。

依赖的 DSH / Cordis 模块
@deepseek-ai/cordis
给这个插件打分还没有人投票↓
用户评分
还没有人投票,来当第一个

在 DeepSeek Harness 第三方插件里,把中文界面文案以英文在服务端渲染。

README

由 DeepSeek 最新模型翻译生成
chinese2english 把 DeepSeek Harness 第三方插件里的中文界面文本渲染成英文。 多数社区插件硬编码了中文,界面语言设置管不到它们。这个插件在服务端改写这些文本,赶在它们到达浏览器之前。 工作原理 文本从两条路径进来,所以有两个切入点。 插件包。 clientModules 通过 /plugins/... 提供每个插件包。包一层 clientModules.bundleResource,解码每个 JavaScript 响应,改写其中能翻译的中文字符串字面量,再返回结果。一次拦截覆盖所有插件,包括打包了几十个插件的组合包,而且它在任何插件代码执行之前就跑完了。 API 文案。 插件描述符、模型名和服务商名、设置说明从来不出现在插件包里:它们以 JSON 形式经 /api 到达浏览器。网关每次请求都自己解析 dispatchRpc,所以覆盖这个实例方法就能拦截这些响应,又不用抢占网关已经占用的拦截器槽位。 三个刻意的选择: - 字面量全有或全无。 中文没有词边界,所以把已知词替换到任何出现的地方都会弄坏更大的词(当前工作区 会变成 Saat IniWorkspace)。只有当一个字面量里的每个汉字都被词典条目覆盖时,才翻译它;其余一律保留中文,因为翻一半的文本比不翻更难读。 - 编译闸门。
展开完整文档(README 剩余 1 节)
chinese2english

把 DeepSeek Harness 第三方插件里的中文界面文本渲染成英文。

多数社区插件硬编码了中文,界面语言设置管不到它们。这个插件在服务端改写这些文本,赶在它们到达浏览器之前。

工作原理

文本从两条路径进来,所以有两个切入点。

插件包。 clientModules 通过 /plugins/... 提供每个插件包。包一层 clientModules.bundleResource,解码每个 JavaScript 响应,改写其中能翻译的中文字符串字面量,再返回结果。一次拦截覆盖所有插件,包括打包了几十个插件的组合包,而且它在任何插件代码执行之前就跑完了。

API 文案。 插件描述符、模型名和服务商名、设置说明从来不出现在插件包里:它们以 JSON 形式经 /api 到达浏览器。网关每次请求都自己解析 dispatchRpc,所以覆盖这个实例方法就能拦截这些响应,又不用抢占网关已经占用的拦截器槽位。

三个刻意的选择:

- 字面量全有或全无。 中文没有词边界,所以把已知词替换到任何出现的地方都会弄坏更大的词(当前工作区 会变成 Saat IniWorkspace)。只有当一个字面量里的每个汉字都被词典条目覆盖时,才翻译它;其余一律保留中文,因为翻一半的文本比不翻更难读。
- 编译闸门。 每个改写后的包在送出之前都用 new Function 解析一遍。万一改写产出了非法 JavaScript,就改送原始字节,所以一条坏词典条目弄不坏界面。
- 端点白名单。 只改写返回服务端撰写文案的端点。比如 /api/session/list 返回的是你自己的提示词和对话记录,就不动它。

作者本来就写了英文的地方,用那段英文,不用词典:locale 映射({ zh, en })取英文那一侧,用 · 连接的双语描述符保留英文那一半。

客户端那一半只做一件事:通过 ctx.locale.setLocale 选中 en locale,这个偏好会持久化。它从不碰 DOM。

不覆盖的范围

- 渲染在 、canvas 或其他非文本载荷里的文本。
- 运行时从第三方服务器拉取的内容(公告、远程目录),而不是来自 DSH 本身的内容。
- 匹配中文输入的正则表达式里的中文。/失败|错误|无法/ 用来给状态消息分类,/^[一-龥]{2}$/ 校验两字姓名;翻译这些会改变插件行为,而不是去掉文本。四个包里共 111 个字符,全是代码,不是文案。

界面渲染的一切都已翻译。通过运行时实测线上实例实际提供的 bundle 里:字符串字面量中的中文从 50,399 降到 0,而实际提供的字节中任何位置的中文从 55,345 降到 111。

安装

dsh plugin --profile web add chinese2english

卸载用 dsh plugin --profile web remove chinese2english。

安装后重启 DSH,让插件加载、传输层包装器在第一次 bundle 请求之前装好。

开发

npm run dict # rebuild the dictionaries from their sources
npm run build # bundle the server and client halves into lib/

词典来源按以下顺序合并(后者覆盖前者):

1. dshmarket_dict.json —— 采集到的词对。
2. patch-plugins.py 里的 UI_TRANSLATIONS —— 采集到的词对。
3. src/dictionary.extra.json —— 人工整理的条目。
4. src/dictionary.mt.json —— 采集字面量的机器翻译。
5. src/dictionary.residual.json —— 实测仍未翻译的字面量。
6. locale-pairs.json —— 作者手写的 { zh, en } 词对,取自插件 locale 映射;质量最高,因此覆盖以上全部。

注释是另一本词典 src/dictionary.comments.json,由 scripts/merge-comments.mjs 生成。只有整条注释完全匹配才会替换,这样那些注释里的制表符框线和 * 对齐结构能原样保留。

在 src/dictionary.extra.json 里新增或修正译文,然后运行 npm run dict && npm run build。

衡量覆盖率

进度被虚报过两次,两次都是因为量错了对象,所以测量改成脚本化,不靠肉眼:

node scripts/served.mjs /tmp/boot.html served.json # resolve served bundles
npm run measure served.json # count Chinese left

先从运行中的实例保存启动 HTML(/?token=…),因为真正到达浏览器的是实际提供的那一组 bundle。这两个脚本堵上了两个坑:

- 扫实际提供的集合,不要扫插件根目录。 58 个 bundle 里有 55 个在 dsh 安装树里。只扫配置档目录树,会报告几乎全部已翻译,而整屏界面仍是中文。
- 先解码再计数。 打包器把非 ASCII 输出成 \uXXXX,所以一个 bundle 可能通篇是中文,却一个 CJK 字符都没有。

许可证

MIT © oiupoyt
预览分享卡片长什么样 ↓oiupoyt/chinese2english
分享 · DeepSeek Harness Hub
oiupoyt/chinese2english

把第三方插件里的中文界面文本自动改写为英文

这是你的仓库?认领条目

回到顶部