我正在将开源项目从中文翻译成英文，我使用i18n（在这种情况下是babel）将代码与英文和中文翻译分开。
除了代码中的大量内联注释外，一切都已完成。
显然，babel无法内联翻译评论（无论如何，如果确实如此，那将是相当令人讨厌的。因为代码在语言中不是唯一的，因此不太容易验证。）
我看到它的方式有很多选择：
留下评论 -
Pro ：帮助原创作者等。
Con ：让正在进行的翻译和任何不会说这种语言的人分散注意力
删除所有评论 -
Pro ：代码与本机语言无关，因此有意义。谁还需要评论？使用来源，卢克！
Con ：违反SE原则。在理解代码如何工作方面可能会失去一些重要的东西 - 可能已经采取了一些措施来避免安全风险等。
将中文评论放在中文评论附近
（例如，可能移到上面的行，并以“EN”和“ZH”为前缀。）
Pro ：两全其美，评论保持接近代码
Con ：不利于字典式翻译。用更多语言可以变得笨重。
创建评论词典/备注
Pro ：将评论保存在单独的文件中以便于翻译。
Con ：很难与代码保持同步。更改coe时，记住更新与代码相关的注释并不直观。
在每个开发周期之前/之后为i18n使用不同的预处理器。
Pro ：评论等会使用您的语言。可以将它链接到git pull / push，这样你就只能看到你的语言代码。
Con ：庞大，非显而易见的过程。可能导致代码验证甚至编译错误。
这些似乎都不是很好的解决方案。
如果您做了很多这样的事情，并且代码是在不共享母语的开发人员之间公开共享的，那么是否有推荐的方法来处理代码本身的翻译（或不翻译） ？
答案 0 :(得分：0)
我不确定我理解......你说你将代码与语言部分分开了。所以现在你应该有代码（带注释）+英文资源+中文资源（我使用的资源用于编程语言用于存储可本地化内容的任何内容）
翻译人员只能看到资源，而不是代码和评论。对于开发人员来说，评论保持未翻译。
答案 1 :(得分：0)
简答
似乎是以下的混合物：
内联评论几乎总是微不足道的 - 剥离它们
功能性评论不具有侵扰性 - 翻译（可能带有i18n前缀，例如“[cn]：”或“[en]：”）。
<强>解释
我的微量研究倾向于表明较大的项目会强烈尝试减少评论并让代码解释自己，而是专注于代码质量，从而减少评论的需要。
e.g。来自Linux Kernel Coding guidelines：
永远不要试图解释你的代码如何在评论中发挥作用：它很多 最好编写代码，以便工作是显而易见的，而且它是 浪费时间来解释写得不好的代码。
...来自MySQL coding standards：
当您执行其他人可能认为的操作时，请注释您的代码 并非无足轻重。
这两个标准（以及其他标准）也建议使用最少的函数描述，因此对于理解代码并不那么突兀，而且，由于函数描述通常是多行的并且在代码本身之上，因此可以根据需要包含多种语言
也许有人在某个地方建立了一个可以将评论隔离到读者语言中的界面，但我还是（还）找不到任何这样做的界面。