接手老项目看不懂英文代码注释？注释翻译实用方法

接手老项目最头疼的不是逻辑，是满屏的英文注释。原作者离职三年，注释写得又长又随意，看代码还得先过英语关。我接手过几个这种项目，趟出来一套注释翻译的流程：批量翻、挑重点翻、翻完归档，别傻乎乎一段一段贴着翻。开始翻之前先跑一遍项目，边跑边翻，很多注释描述的行为和实际代码对不上，实践对照着看才不会被老注释带偏。

福昕翻译在线：注释批量粘进来翻

1. 先通读文件结构，标出核心模块，注释优先翻核心模块的。

2. 把目标文件的注释批量摘出来，整段贴进福昕翻译在线的「文字翻译」输入框。

3. 语言方向英文转中文，点翻译，一次能接很长的文本，不用切成小段。

4. 对照着把译文回填到代码里，建议加个TODO或中文标记，和原注释区分开。

5. 设计文档是PDF或Word的话，用「文档翻译」整份上传，翻完排版不乱，对照着看架构。

6. 翻完的注释整理进项目wiki，后来人直接看中文版，这活儿就值了。

注意别把代码当文本翻，只翻注释和文档字符串，变量名函数名别动，翻错了改代码就出事了。

另外注意，注释翻译要分优先级：公共接口的文档字符串先翻，内部实现的注释后翻，废弃代码的注释不翻。翻译是为了接手和维护，不是做文献整理，时间要花在刀刃上。

注释里引用的工单号、人名、日期别翻也别删，这些是排查历史问题的线索，原样保留。翻完的注释建议标注翻译日期和翻译人，半年后有人再接手，知道这份中文注释是二手信息，会自己对照原文。

DeepL：技术长注释翻得最像人话

老程序员写的注释经常带口语和从句，DeepL翻出来逻辑清楚、语气自然，术语前后一致性好。配合术语表功能能把项目固定叫法锁住，团队用很合适。免费额度对个人够用。老注释的口语和从句它处理得自然，术语一致性也好，翻完不用大改。

Google翻译：整页看文档快

项目托管的wiki、README页面直接整页翻，滚动到哪翻到哪，代码块保留不动。快速建立项目全貌的时候好用。注释的细粒度翻译还是要复制出来精翻。托管平台上的README和wiki整页翻，快速建立项目全貌用。

微软翻译：VSCode里就近翻

编辑器生态的翻译插件多是接微软的引擎，选中注释右键就出结果，不用切窗口。翻完直接改在代码里，效率高。单句质量中规中矩，长难注释建议还是过一遍DeepL。编辑器插件选中即翻，翻完就地改在代码里，不切窗口效率高。

Immersive Translate：双语对照读文档

插件双语对照显示，读英文设计文档时原文译文逐段排，方便回查原文细节。对GitHub页面的适配好，issue和PR讨论也能翻。要纯中文结果的人会觉得排版啰嗦。GitHub页面双语对照，issue和PR讨论也能翻，接手开源项目好用。

Reverso：查注释里的行话

老注释里有些半行话的表述，比如某个俚语化的说法，用Reverso查真实语料里的双语例句，能看出这个词在这个语境下到底想说啥。查证工具，别当翻译工具用。查行话的时候把整条注释放进例句搜索，孤立查单词容易选错义项。

注释翻译的分寸感很重要：翻是手段，目的是理解代码，所以别追求完美译文，能准确传达意思就行。翻完的中文注释要不要提交回仓库，看团队规范，有的团队喜欢，有的嫌乱，先问一声再提交。我一般自己留一份中文笔记，仓库保持原样，两不耽误。注释翻译的产出是理解，不是译文本身，翻完顺手画一张模块关系图，比十页译文都管用，这是接手老项目最快的路。千万别信注释能百分百反映代码行为，注释是当时人的理解，代码才是事实，两者冲突时以代码为准，翻注释是辅助不是代替读代码。