我正在将一个开源项目从中文翻译成英语，我已经使用了i18 n（在本例中是babel）将代码与英文和中文翻译分开。
除了代码中有大量的内联注解外，其他一切都已完成。
显然，babel不能翻译内联注解（如果它这样做的话，无论如何，这将是相当令人讨厌的。因为代码在不同的语言中不是唯一的，因此不太容易验证。）
在我看来，有很多选择：
1.请在-中留言
- Pro*：帮助原作者等。
- 缺点 *：使正在进行的翻译和任何不会说该语言的人分心
1."把所有的评论都删掉“
- 赞成 *：代码是不可知的，所以它是有意义的。谁需要注解呢？使用源代码，Luke！
- 缺点 *：违背SE原则。可能会丢失一些重要的东西，无法理解代码是如何工作的--可能已经采取了一些措施来避免安全风险，等等。
1.将英语注解放在中文注解旁边
（例如，可能移动到上面的行并以“EN”和“ZH”为前缀）。
- 优点 *：两全其美，注解靠近代码
- 缺点 *：不利于字典式的翻译。使用更多语言会变得很笨重。
1.创建注解词典/注解
- Pro*：将注解保存在单独的文件中，以便于翻译。
- 缺点 *：很难与代码保持同步。当更改代码时，不直观地记住更新与代码相关的注解。
1.在每个开发周期之前/之后为i18 n使用不同的预处理器。
- Pro*：注解等将使用您的语言。可以将其链接到git pull/push，这样您就只能看到您的语言的代码。
- 缺点 *：庞大、不明显的进程。可能导致代码验证甚至编译错误。
这些似乎都不是真正好的解决方案。
如果您做了很多这样的工作，并且代码是在不使用同一种母语的开发人员之间公开共享的，那么有没有推荐的方法来处理代码本身中的翻译（或不翻译）注解？
3条答案
按热度按时间qacovj5a1#
我不确定我是否理解...您说您将代码与语言部分分离。所以现在您应该有代码（带注解）+英语资源+中文资源（我使用了任何编程语言的资源来存储可本地化的内容）
翻译人员只看到资源，看不到代码，也看不到注解。对于开发人员来说，注解保持未翻译状态。
1sbrub3j2#
简短回答
它似乎是一种混合物：
1.* 删除所有评论 ，以及
1. 将英语注解放在中文注解旁边 *。
内联注解几乎总是琐碎的-删除它们
功能性注解不具有侵入性-对其进行翻译（可能带有国际化前缀，例如“[cn]：“或“[en]：“）。
说明
我的少量研究倾向于建议大型项目做出强烈的尝试来减少注解，让代码自己解释，而不是专注于代码质量，这减少了对注解的需要。
例如，从Linux Kernel Coding guidelines：
永远不要试图在注解中解释你的代码是如何工作的：最好是编写代码，使工作显而易见，解释编写得不好的代码是浪费时间。
...从MySQL coding standards：
当您执行其他人可能认为不简单的操作时，请对代码进行注解。
这两个标准（以及其他标准）都建议使用最少的函数描述，这样就不会妨碍对代码的理解，而且，由于函数描述通常是多行的，并且位于代码本身之上，因此可以根据需要使用多种语言。
也许有人，在某个地方已经建立了一个界面，可以隔离评论到读者的语言，但我不能（还）找到任何这样做。
6bc51xsx3#
我一直认为项目中导出的API注解和开源项目中的私有注解都应该国际化，这对其他国家的开发者来说非常方便。
在Github上，其实也有很多开发者用自己的国家语言来评论一些知名的开源项目和自己的一些注解，大部分原因是如果不翻译，开发者阅读评论的效率很低。
类似于TypeScript中的
.d.ts，我认为函数注解翻译也可以采取类似的形式，这样更方便社区反馈翻译内容，因为事实上很多开发者都愿意这么做。