从硬啃英文 README 到代码被翻坏：我重新捋了一遍 GitHub 的读法

先说结论：如果你也常逛 GitHub，在「逐段硬啃英文」和「开翻译怕代码被毁」之间来回摇摆，这事值得重新捋一遍——问题不在要不要开翻译，在于翻译工具能不能分清代码和说明文字。

我为什么一直不敢开翻译

看开源项目这几年，我的状态一直是两种切换：状态好的时候逐段硬啃，一段架构说明来回读三遍；赶时间就开浏览器自带的整页翻译，然后等着收惊吓——变量名成了中文，终端命令变了样，示例代码复制下来直接跑不动。

最难受的是翻完还不敢信。译文里 pip install 长什么样我不确定，报错信息被翻成中文后，拿去搜索都搜不到原题。后来我干脆回到硬啃模式，翻译只用来查单个词。

转折点：搞清楚「代码块不翻」这件事

后来用上沉浸式翻译这个浏览器插件，第一件事就是验证它会不会动代码。实测下来，它对 GitHub 做了专门适配：翻译时自动跳过识别到的代码块、文件树、导航栏和页面控件。落到页面上就是——README 的说明段落出现中文译文，紧挨着的安装命令、示例代码原封不动，缩进和语法高亮都不受影响。

这里有个细节要说清楚：这种保护依赖页面语义结构。只有被 GitHub 渲染为代码块或行内代码的内容才能被识别保留；代码如果直接混在普通段落里，任何工具都无法与自然语言区分。换句话说，规范标记的文档（主流项目基本都是）保护得很稳，随手贴代码的页面就要留个心眼。

现在我的读法

读 README 和项目文档：开双语对照，原文在上、译文在下。译文说不通的架构描述，往上看一眼原文核实；拿不准的术语直接对照英文原词。原文始终在场，这是我敢开翻译的底气。

翻 Issue 讨论：讨论内容是自然语言，正常翻译；里面贴的代码片段、报错日志原样保留。排查 Bug 翻几百条英文讨论时，讨论看得快、日志看得准，报错关键词没被改写，拿去搜索定位不受影响。

读 Wiki 和教程：长文用段落对照顺读；个别生词选中即弹译文和发音；想单独确认某段，悬停段落按快捷键出译文。查词和看段两种方式分工着用。

回 Issue：这是让我意外的一块。参与国际项目、给依赖库提 Bug，通常更适合用英文写。我现在的做法是先用中文把复现步骤一条条写准确，在输入框里连按三次空格或用设置好的快捷键，转换成英文，检查一遍版本号、函数名、报错信息没被改写，再提交。英文表达交给自己组织的时候，我总在关键细节上词不达意；交给机器转换，反而稳。

用下来值得说的几点

第一，敢开翻译了。代码块原样保留这条边界确认之后，「开翻译怕代码被毁」的顾虑就没了，读英文文档的速度回到中文水平。

第二，关键信息心里有底。双语对照下原文一直在，API 名称、参数、命令随时核对。机器译文不是百分之百准确，但原文在场，核对成本很低。

第三，从读到写打通了。以前看懂了讨论也插不上话，现在中文写完转英文，参与开源的门槛降了一截。

两个要说清楚的地方

一是术语库不是万能的。用 AI 翻译服务时可以通过术语库约束关键术语的固定译法，普通机器翻译服务不一定支持。

二是翻译只作用于当前页面的显示内容，不会修改仓库里的代码，也不会产生任何提交——这点一开始我也有疑虑，实测确认过。

写在最后

把上面这些捋清楚之后，我现在开翻译读 GitHub 文档，基本不用再纠结了。代码块原样保留、说明文字双语对照、原文始终在场——确认了这三条边界，之前在硬啃和怕翻坏之间反复横跳的状态就算过去了。机器译文毕竟不是百分百准确，所以关键的 API 名称、参数、命令，我仍然会对照原文确认一遍，这一步不会因为工具顺手就省掉。