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

Question

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

一切都完成了，除了代码中有相当多的内联 cmets。

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

在我看来，有很多选择：

1. 将 cmets 留在 -

   专业版：帮助原作者等

   骗局：让正在进行的翻译和不会说该语言的人分心

2. 去掉所有的 cmets -

   Pro：代码与本机语言无关，因此很有意义。谁还需要cmets？使用源，卢克！

   Con：违背 SE 原则。在理解代码的工作原理方面可能会丢失一些重要的东西——也许已经做了一些事情来避免安全风险，等等。

3. 在中文 cmets 附近放置英文 cmets

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

   专业版：两全其美，cmets 与代码保持密切联系

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

4. 创建评论字典/注释

   专业版：将 cmets 保存在单独的文件中以便于翻译。

   Con：难以与代码保持同步。更改 coe 时不直观记得更新与代码相关的 cmets。

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

   Pro：Comments et al 会使用您的语言。可以将此链接到 git pull/push，这样您就只能看到您的语言的代码。

   Con：庞大、不明显的过程。可能导致代码验证甚至编译错误。

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

如果您经常这样做，并且代码在不使用母语的开发人员之间公开共享，是否有推荐的方法来处理代码本身中的翻译（或不翻译）cmets ?

Answer 1

我不确定我是否理解...您说您将代码与语言部分分开。所以现在你应该有代码（使用 cmets）+ 英文资源 + 中文资源（我使用了你的任何编程语言用来存储可本地化内容的资源）

译者只看到资源，看不到代码，也看不到 cmets。对于开发人员来说，cmets 保持未翻译状态。

Answer 2

简答

这似乎是一种混合：

1. 去掉所有的cmets，然后
2. 在中文 cmets 附近放置英文 cmets。

内联 cmets 几乎总是微不足道的 - 剥离它们

功能性 cmets 不那么具有侵入性 - 翻译它们（可能带有 i18n 前缀，例如“[cn]:”或“[en]:”）。

说明

我的少量研究倾向于表明，大型项目会大力尝试减少 cmets 并让代码自行解释，而不是专注于减少对 cme​​ts 需求的代码质量。

例如来自Linux Kernel Coding guidelines：

永远不要试图在评论中解释你的代码是如何工作的：这太多了 更好地编写代码，以便 工作 是显而易见的，它是 解释写得不好的代码是浪费时间。

...来自MySQL coding standards:

当你做别人可能认为是的事情时，评论你的代码 不是微不足道的。

这两个标准（和其他标准）也都建议使用最少的函数描述，这样对理解代码就不会那么突兀，而且，由于函数描述通常是多行的并且高于代码本身，因此可以根据需要包含多种语言.

也许有人在某处建立了一个接口，可以将 cmets 隔离到阅读器语言中，但我（还）找不到任何这样做的。