Internationalization 在执行i18n时处理代码中的注释

我正在将一个开源项目从中文翻译成英文，我使用了i18n（在本例中是babel）将代码与中英文翻译分开

一切都完成了，除了代码中有大量的内联注释

显然，babel不能内联翻译注释（无论如何，如果它这样做了，那将是相当令人讨厌的。因为代码在不同语言之间不是唯一的，因此不容易验证）

在我看来，有很多选择：

在中留下评论

赞成：帮助原创作者等

缺点：这会分散正在进行的翻译和不会说这种语言的人的注意力

删除所有评论-

赞成：代码与本机语言无关，所以它是有意义的。谁还需要评论？使用来源，卢克

缺点：违反SE原则。在理解代码如何工作时可能会丢失一些重要的东西-可能是为了避免安全风险而做了一些事情，等等

将英文评论放在中文评论旁边

（例如，可能移到上面的行并以“EN”和“ZH”作为前缀）

赞成：两全其美，注释与代码保持一致

缺点：不利于字典式翻译。使用更多的语言可能会变得笨重

创建注释词典/注释

优点：将注释保存在单独的文件中，以便于翻译

缺点：很难与代码保持同步。在更改coe时，记住更新与代码相关的注释并不直观

在每个开发周期之前/之后为i18n使用不同的预处理器。

赞成：评论等都是用你的语言。可以将此链接到git pull/push，这样您就只能看到您语言中的代码

缺点：笨重，不明显的过程。可能导致代码验证甚至编译错误

这些似乎都不是很好的解决方案

---

如果您做了很多这样的事情，并且代码是在不使用母语的开发人员之间公开共享的，那么有没有推荐的方法来处理代码本身中的注释翻译（或不翻译）？我不确定我是否理解。。。你说你把代码和语言部分分开了。所以现在您应该有代码（带注释）+英语资源+中文资源（我使用了用于存储可本地化内容的编程语言的资源）

---

翻译人员只看到资源，而不看到代码，也不看到注释。对于开发者来说，这些评论没有翻译。

我不确定我是否理解。。。你说你把代码和语言部分分开了。所以现在您应该有代码（带注释）+英语资源+中文资源（我使用了用于存储可本地化内容的编程语言的资源）

---

翻译人员只看到资源，而不看到代码，也不看到注释。对于开发者来说，这些评论没有翻译。

简短回答

这似乎是以下因素的混合：

去掉所有的评论，然后

将英文注释放在中文注释附近

内联评论几乎总是琐碎的-去掉它们

功能性的评论没有侵入性-翻译它们（可能带有i18n前缀，例如“[cn]：”或“[en]：”）

解释

我的少量研究倾向于建议大型项目大力减少注释，让代码自行解释，而不是关注代码质量，从而减少注释需求

e、 g.从以下方面：

千万不要试图在注释中解释你的代码是如何工作的：它非常有用 最好编写代码，使工作的显而易见，并且 解释写得不好的代码是浪费时间

…并从以下方面：

当您执行其他人可能认为是错误的操作时，请对代码进行注释 不平凡

这两个标准（以及其他标准）都建议使用最小的函数描述，因此这对理解代码来说并不那么麻烦，而且，由于函数描述通常是多行的，并且在代码本身之上，因此可以根据需要包括多种语言

---

也许有人在某处建立了一个界面，可以将评论隔离到读者语言中，但我（还）找不到任何这样做的界面。

简短回答

这似乎是以下因素的混合：

去掉所有的评论，然后

将英文注释放在中文注释附近

内联评论几乎总是琐碎的-去掉它们

功能性的评论没有侵入性-翻译它们（可能带有i18n前缀，例如“[cn]：”或“[en]：”）

解释

我的少量研究倾向于建议大型项目大力减少注释，让代码自行解释，而不是关注代码质量，从而减少注释需求

e、 g.从以下方面：

千万不要试图在注释中解释你的代码是如何工作的：它非常有用 最好编写代码，使工作的显而易见，并且 解释写得不好的代码是浪费时间

…并从以下方面：

当您执行其他人可能认为是错误的操作时，请对代码进行注释 不平凡

这两个标准（以及其他标准）都建议使用最小的函数描述，因此这对理解代码来说并不那么麻烦，而且，由于函数描述通常是多行的，并且在代码本身之上，因此可以根据需要包括多种语言

也许有人，某个地方已经建立了一个界面，可以将评论隔离到读者语言中，但我（还）不能