探秘 GitHub 汉化插件内部一份 3 万行词库如何完成界面中文化【免费下载链接】github-chineseGitHub 汉化插件GitHub 中文化界面。 (GitHub Translation To Chinese)项目地址: https://gitcode.com/gh_mirrors/gi/github-chinese深夜Pull Request 页面跳出红色的 Merge conflict 警告我点开 Tampermonkey 面板GitHub 汉化插件正在后台运行——界面上其余的英文几乎都已被替换成中文。这个由沙漠之子维护的开源用户脚本代码本体不过一个 main.user.js 加上一份 locals.js却要应对 GitHub 数百种页面和不断改版的 React 前端。它的运转方式远比查字典替换复杂。这篇文章尝试把它拆开看看一个词库驱动的汉化系统究竟如何工作。表面之下先回答哪些页面要翻译打开项目源码最先注意到的是一份 29623 行的 locals.js——整个仓库最大的单个文件。它并不是简单的英中对照表而是三层结构匹配 pathname 的正则规则、翻译忽略规则、按页面归类的词条库。文件头部的版权注释记录了它的来路2016 至 2021 年由楼教主维护2021 年起由沙漠之子接手GPL-3.0 协议。I18N.conf是这一切的入口。它先用正则匹配当前 URL 的 pathname把页面归类为 repository/tree、issues、profile、gist 等类型每个类型下再挂上对应的词条和选择器。main.user.js 里另有一张站点域名映射表把 skills.github.com、education.github.com、gist.github.com 这类子站点单独区分。翻译不是全文扫描而是先确定这是哪一页、该用哪组规则。时机问题为什么刷新瞬间界面就已变成中文词库就位后第二个问题是如何在正确的时机下手。脚本声明了run-at document-start赶在页面渲染前注入真正支撑动态内容的是一个配置精细的 MutationObserver——childList 监听节点增删、characterData 监听文本变化attributeFilter 则盯住 value、placeholder、aria-label 这些属性。为了不让翻译操作自身触发新的观察事件脚本还维护了两套忽略配置分别作用于初始遍历与后续变化。这套机制最直接的收益体现在应对 GitHub 自身的迭代上。2026 年 6 月的更新日志里连续几个小版本都在与 React 机制周旋头部导航改用 React 渲染导致搜索框消失、Primer 弹层与页面主体共享导致下拉菜单翻译延迟、搜索模块忽略范围过宽导致仓库议题页失译。每一次兼容修复都是观察器与页面生命周期赛跑的结果。精确性翻译的误伤防线机械替换文本最怕误伤把用户自己写的代码注释、README 内容也一并翻掉。项目为此设了两道防线。第一道是忽略规则——.highlight、.notranslate、[translateno]这类选择器直接排除article.markdown-body内的仓库 README 正文也明确不参与翻译避免把仓库介绍变成一段机翻残片。第二道防线是回归测试。仓库 test/ 目录下躺着 issue-700、issue-702、issue-761 三个回归用例用 Node 内置的 test runner 加载 locals.js断言忽略规则确实存在于两套配置之中。README 示例代码不被翻译不是靠运气而是被测试钉死的约定这几条规则对应的正是历史 issue 里用户真实踩过的坑。词库之外机器翻译与开发者模式静态词条覆盖不了的内容项目引入了人机协作。仓库描述这类用户自定义文本会通过讯飞听见的在线翻译接口做即时翻译CONFIG.DEV true打开开发者模式后会激活未命中词条管理器——脚本把匹配不到词条的英文记录下来维护者可以在菜单里一键导出 JSON、查看统计或清空记录。翻译覆盖率不是拍脑袋定的而是由使用者不断反馈驱动的增量过程。主题适配也在这个层面完成。项目为浅色与深色两套主题分别维护样式变量翻译后的按钮、提示框在暗色背景下依然可读而不是简单地把文字颜色压暗了事。让它持续运转版本节奏与协作机制汉化是个无底洞——GitHub 每次改版词库都要跟着迭代。项目因此拆成双版本线开发版每周五自动更新词库稳定版每周一同步一次后者更保守适合生产环境使用者。词库的维护也不再依赖单人劳作docs/ai-review.md 记录了一套基于 DeepSeek 的 AI 代码审查工作流任何人提交的 PR 都会以机器人身份获得结构化中文审查意见密钥只存在请求者自己的 fork 中上游仓库零密钥。项目还留了一条不依赖 Tampermonkey 的路径——vscode-extension/ 目录下的 VS Code 集成浏览器扩展让编辑器里的 GitHub 预览同样呈现中文界面。从浏览器脚本到桌面工具同一套词库被复用了多次。回头看这个项目最值得琢磨的不是翻译了什么而是它如何回答三个问题哪些页面要翻、什么时候翻、哪些绝对不能翻。3 万行词库只是答案的载体真正的骨架是正则路由 观察器 忽略规则 回归测试这套组合。如果你也在维护一个依赖外部平台动态内容的工具这套思路或许比翻译结果本身更有借鉴价值——那么当 GitHub 下一次改版时你手里的工具准备好接招了吗【免费下载链接】github-chineseGitHub 汉化插件GitHub 中文化界面。 (GitHub Translation To Chinese)项目地址: https://gitcode.com/gh_mirrors/gi/github-chinese创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
探秘 GitHub 汉化插件内部一份 3 万行词库如何完成界面中文化【免费下载链接】github-chineseGitHub 汉化插件GitHub 中文化界面。 (GitHub Translation To Chinese)项目地址: https://gitcode.com/gh_mirrors/gi/github-chinese深夜Pull Request 页面跳出红色的 Merge conflict 警告我点开 Tampermonkey 面板GitHub 汉化插件正在后台运行——界面上其余的英文几乎都已被替换成中文。这个由沙漠之子维护的开源用户脚本代码本体不过一个 main.user.js 加上一份 locals.js却要应对 GitHub 数百种页面和不断改版的 React 前端。它的运转方式远比查字典替换复杂。这篇文章尝试把它拆开看看一个词库驱动的汉化系统究竟如何工作。表面之下先回答哪些页面要翻译打开项目源码最先注意到的是一份 29623 行的 locals.js——整个仓库最大的单个文件。它并不是简单的英中对照表而是三层结构匹配 pathname 的正则规则、翻译忽略规则、按页面归类的词条库。文件头部的版权注释记录了它的来路2016 至 2021 年由楼教主维护2021 年起由沙漠之子接手GPL-3.0 协议。I18N.conf是这一切的入口。它先用正则匹配当前 URL 的 pathname把页面归类为 repository/tree、issues、profile、gist 等类型每个类型下再挂上对应的词条和选择器。main.user.js 里另有一张站点域名映射表把 skills.github.com、education.github.com、gist.github.com 这类子站点单独区分。翻译不是全文扫描而是先确定这是哪一页、该用哪组规则。时机问题为什么刷新瞬间界面就已变成中文词库就位后第二个问题是如何在正确的时机下手。脚本声明了run-at document-start赶在页面渲染前注入真正支撑动态内容的是一个配置精细的 MutationObserver——childList 监听节点增删、characterData 监听文本变化attributeFilter 则盯住 value、placeholder、aria-label 这些属性。为了不让翻译操作自身触发新的观察事件脚本还维护了两套忽略配置分别作用于初始遍历与后续变化。这套机制最直接的收益体现在应对 GitHub 自身的迭代上。2026 年 6 月的更新日志里连续几个小版本都在与 React 机制周旋头部导航改用 React 渲染导致搜索框消失、Primer 弹层与页面主体共享导致下拉菜单翻译延迟、搜索模块忽略范围过宽导致仓库议题页失译。每一次兼容修复都是观察器与页面生命周期赛跑的结果。精确性翻译的误伤防线机械替换文本最怕误伤把用户自己写的代码注释、README 内容也一并翻掉。项目为此设了两道防线。第一道是忽略规则——.highlight、.notranslate、[translateno]这类选择器直接排除article.markdown-body内的仓库 README 正文也明确不参与翻译避免把仓库介绍变成一段机翻残片。第二道防线是回归测试。仓库 test/ 目录下躺着 issue-700、issue-702、issue-761 三个回归用例用 Node 内置的 test runner 加载 locals.js断言忽略规则确实存在于两套配置之中。README 示例代码不被翻译不是靠运气而是被测试钉死的约定这几条规则对应的正是历史 issue 里用户真实踩过的坑。词库之外机器翻译与开发者模式静态词条覆盖不了的内容项目引入了人机协作。仓库描述这类用户自定义文本会通过讯飞听见的在线翻译接口做即时翻译CONFIG.DEV true打开开发者模式后会激活未命中词条管理器——脚本把匹配不到词条的英文记录下来维护者可以在菜单里一键导出 JSON、查看统计或清空记录。翻译覆盖率不是拍脑袋定的而是由使用者不断反馈驱动的增量过程。主题适配也在这个层面完成。项目为浅色与深色两套主题分别维护样式变量翻译后的按钮、提示框在暗色背景下依然可读而不是简单地把文字颜色压暗了事。让它持续运转版本节奏与协作机制汉化是个无底洞——GitHub 每次改版词库都要跟着迭代。项目因此拆成双版本线开发版每周五自动更新词库稳定版每周一同步一次后者更保守适合生产环境使用者。词库的维护也不再依赖单人劳作docs/ai-review.md 记录了一套基于 DeepSeek 的 AI 代码审查工作流任何人提交的 PR 都会以机器人身份获得结构化中文审查意见密钥只存在请求者自己的 fork 中上游仓库零密钥。项目还留了一条不依赖 Tampermonkey 的路径——vscode-extension/ 目录下的 VS Code 集成浏览器扩展让编辑器里的 GitHub 预览同样呈现中文界面。从浏览器脚本到桌面工具同一套词库被复用了多次。回头看这个项目最值得琢磨的不是翻译了什么而是它如何回答三个问题哪些页面要翻、什么时候翻、哪些绝对不能翻。3 万行词库只是答案的载体真正的骨架是正则路由 观察器 忽略规则 回归测试这套组合。如果你也在维护一个依赖外部平台动态内容的工具这套思路或许比翻译结果本身更有借鉴价值——那么当 GitHub 下一次改版时你手里的工具准备好接招了吗【免费下载链接】github-chineseGitHub 汉化插件GitHub 中文化界面。 (GitHub Translation To Chinese)项目地址: https://gitcode.com/gh_mirrors/gi/github-chinese创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
