一行清晰的代码注释所作出的诠释，是一座能跨越技术语言以及文化隔阂的桥梁。它不是简单地进行文字转换，而是要求译者同时拥有扎实的编程知识，对原文上下文有着精准的把握，还有目标语言的流畅表达。在全球化协作以及开源项目盛行的当下，高质量的注释翻译能够极大地降低非母语开发者的理解成本，是提升代码可维护性以及团队协作效率的关键一环。忽视这项工作，可能会致使误解、延误甚至引入错误。
为什么要重视代码注释翻译
代码之说明书乃注释，其阐释之为何如此编写，并非仅代码自身之所做。对外语非母语之开发者而言，特别是初学者，径直阅读英文注释或存障碍，此将延缓学习、调试以及协作之进程。一份佳译可致知识更平等地流动，降低技术门槛。反之，劣译或径直忽略翻译，会使代码库成仅部分人能懂之“黑盒”，不利于项目之长远发展与知识传承。
从实际存在的项目情形而言，一个具备把中文所表达的意思阐述得极为完备精确注释的、在软件世界里深受大众欢迎且被广泛传播的开源库，于国内的从事程序开发相关工作的群体所聚合形成的社区范围之内，会被以更为广泛的程度去开展学习以及进行运用。这种情况不仅仅是在以星标数量多少来体现，更是在以问题反馈以及代码合并请求的质量高低方面得以展现。当参与开发的人员能够以轻松容易的状态去领会明白设计所蕴含的意图之际，他们就更有发生可能性去奉献出具备有价值意义的代码或者提出具有建设性作用的意见。所以，把注释内容翻译成中文这种行为，是针对开放源码社区生态环境所进行的一类有着积极意义的投入行为。
代码注释翻译有哪些基本原则
首要原则为“准确忠实于技术意图” ，译者得去理解，那注释所指代的代码逻辑 ，要确保，翻译后的文字在技术含义上与原文全然一致，不会出现歧义或者错误 。比如说，把“cache”译为“缓存”而非“隐藏” ，把“thread”译为“线程”而非“线索” 。任何偏离原意的“意译”在技术文档里都是危险的 。
第二个原则为“保持简洁与一致性”，注释自身一般力求简短，翻译事宜同样也是这样，要避免去加之没必要的修饰词，与此同时，整个项目或者同一模块之内的术语务必得统一，像比如说吧，一旦把“framework”确定为“框架”，那么全文统统都应该持续沿用，绝不能够时而使用“架构”时而使用“框架”，构建并且维护一份项目专用的术语表是特别有效的方法。
如何选择合适的代码注释翻译工具
当下不存在专门针对代码注释的那种“完美”的全自动翻译的工具。谷歌翻译、Deep L等这类通用工具能够当作初稿的辅助工具，然而它们没办法理解代码的上下文情境状态情况，经常在专业术语以及句式方面出现错误。比如说，它们有可能没办法区分程序里的“string”（也就是字符串）和日常普通说法里的“string”（即线）。所以，绝对不可以去依赖没有经过审核审定核查的机器翻译的结果。
较为可行的方案是把翻译记忆工具（像是 Smartcat、MemoQ 这类）与之作结合来使用，还有术语管理工具。翻译记忆库能够保证相似句子的翻译具备一致性，进而提高效率。与此同时，把确认好正确的术语导入到术语库当中，工具会在从事翻译的过程里进行提示以及强制应用，如此一来能够极大地提升翻译质量以及团队协作的效率。
代码注释翻译的常见难点有哪些
其中一个难点是，处理代码里的“行内注释”以及变量名。比如说，注释“Sets the max retry count”，它紧挨着变量 maxRetryCount。直接把它翻译为“设置最大重试次数”，这样是通顺的。然而，有时候变量名自身就是一种注释呢。平常情况下，我们会保留变量名的原文，仅仅去翻译完整的句子。而难点便在于，怎样能够让这两者在中文句子里自然地结合起来 。
又一个难点在于处理幽默、文化梗，或者极为口语化的注释，国外开发者有时会在注释里写下笑话，或者引用流行文化，直译的话可能会让中文读者摸不着头脑，这时候，要在“保留趣味性”与“保证清晰性”之间进行权衡，通常的建议是，把传达核心信息当作首要目标 ，要是文化梗不影响理解，就可以保留并加上简要说明，要是造成了困扰，那就不妨将其转化为中文环境下类似的表达，或者直接省略 。
人工审核在注释翻译中为何不可替代
不管工具究竟有多先进，人工审核都是保障质量的最终且最为关键的关口。审核者务必同时具备开发能力以及双语能力。他的任务不单单是校对文字，更是开展“技术验证”，得检查翻译是不是精准地呈现了代码行为，术语在上下文之中是否适用，还要看整个注释读起来是否如同一位中国开发者所撰写的自然说明 。
审核的进程常常能够发觉那机器翻译乃至那初级译员都没能察觉到的深层方面的问题，比如说，原本的文字注释自身有可能就是存在着模糊不清或者已然过时的状况，出色的审核人员会把代码的逻辑给结合起来，进而提出对于原本文字注释的修正方面的建议，并且和原本代码的维护人员去进行沟通，这样的情形致使翻译的进程变成了对于代码文档质量的一回整体性质的提升 。
如何管理大型项目的注释翻译工作
针对大型或者活跃的开源项目而言，注释翻译应当是持续开展的流程，并非一次性的任务。建议采用类似于代码版本管理的模式，把翻译文件纳入版本控制系统，比如 Git，为翻译工作构建独立的分支或者目录结构。当源代码出现更新状况时，能够凭借工具对照出哪些注释出现了新增加或者修改的情况，接着有针对性地进行更新翻译。
建立一个规模较小的、处于稳定状态的翻译贡献者社区这件事是至关重要的。要制定出清晰明确的翻译风格指南以及贡献流程，并且运用代码审查也就是Pull Request Review机制去评审每一回的翻译提交。这样做不但能够保证质量，而且还能够培养出新的翻译贡献者。把翻译工作划分成模块，并且记录下贡献者，能够有效地激励社区进行长期的参与。
于你参与或者发起的项目里头，是不是曾因注释语言方面的问题碰到遭受理解的阻碍？你是更偏向去阅读毫不修饰的英文注释，还是期望能见到质量上乘的本土化翻译？欢迎在评论区域分享自身的经历以及看法，要是觉着这篇文章有帮助的话，同样请点赞予以支持，并且分享给更多有处理国际化项目需求的伙伴。
原创文章，作者：有道翻译，如若转载，请注明出处：https://fanyi-youdao.net/archives/958
