在处理i18n时处理代码中的注释

Question

我正在将开源项目从中文翻译成英文，并且我使用i18n（在这种情况下为babel）将代码与英文和中文翻译分开。

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

显然，巴贝尔无法翻译评论在线（这将是比较讨厌的，如果它没有，反正，由于代码不会是跨语言的唯一的，因此不太容易核查。）

我看到它的方式，也有多种选择：

1. 留言中 -

   临：帮助原作者等

   精读：使它分心正在进行翻译和谁不说当地语言

2. 去掉所有的评论 -

   临：代码为母语的语言 - 不可知论，所以它是有道理的。无论如何，谁需要评论？使用源码，卢克！

   合同：违背SE原则。可能会失去一些重要的东西理解代码是如何工作的 - 也许有什么地方做是为了避免安全风险等

3. 靠近中国评论

   将英文注释（可能已移动到上方的线条和前缀“ EN“和”ZH“）。

   临：两全其美，评论保持着密切的代码

   精读：不利于字典式的翻译。使用更多的语言会变得笨重。

4. 创建注释字典/注意到

   临：为便于翻译一个单独的文件保留的意见。

   合约：难以与代码保持同步。记住在更改coe时更新与代码相关的注释并不直观。

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

   专业：评论等将用你的语言。可以将它链接到git pull/push，这样你只能看到你的语言中的代码。

   合同：体积庞大，不明显的过程。可能导致代码验证甚至编译错误。

这些看起来都不是很好的解决方案。

如果你做了很多这样的事情，并且代码在不共享本地语言的开发者之间公开分享，是否有推荐的方式来处理代码本身的翻译（或不）注释？

Answer 1

简答

这似乎是一个混合物

去掉所有的评论和

将英文注释附近中文评论。

内嵌评论几乎都是微不足道的 - 剥夺他们

功能意见并不如侵入 - 与国际化前缀，如翻译他们（可能是 “[CN]：” 或“[EN]：”）。

说明

我的研究微薄量趋于表明，更大的项目作出强烈试图减少的意见和让代码解释本身，而不是专注于代码质量从而降低征求意见的必要性。

例如从Linux Kernel Coding guidelines：

切勿尝试解释如何使你的代码中的注释工作原理：它是多 更好地编写代码，以使工作是显而易见的，它的 的时间来解释写的不好的浪费码。

...从MySQL coding standards：

评论你的代码，当你做一些事情，别人可能认为是 不是小事。

这些标准（及其他）都建议最小的功能描述也，所以这不是突兀来理解代码，并且由于功能描述一般多行和代码本身上面，多语言可必要时包括在内。

也许有人在某个地方建立了一个界面，可以将评论与读者语言隔离开来，但是我还没有找到任何这样做的东西。

Answer 2

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

翻译只看到资源，而不是代码，也没有评论。评论保持未翻译，对于开发者。