翻译在哪里？

在解释了地球上很大一部分人不说英语，然后解释了如何为 Fedora 发行版做贡献之后，让我们看看软件的翻译在哪里。

翻译是代码的组成部分

翻译文件是程序运行所需源代码的一部分。包含翻译的文件格式因开发团队使用的工具而异。要了解主要的文件格式，可以参考 Weblate 翻译平台支持的格式列表。一般来说，Gettext 格式是编译型/桌面软件最常用的格式，而 JSON 格式则用于 Web 软件。每种格式都有其优缺点，这属于软件国际化领域，通常缩写为 i18n。

对翻译工作的影响

由于翻译是源代码的一部分，译者必须及时提交工作，以确保当前版本的每一处更改都被翻译。哪怕是一个字母或字符的微小变动，也需要检查每个翻译，以确定该变动是否影响了句子的含义或结构，因此变更对译者来说代价很高。

在大多数情况下，开发人员无法在修改代码时同步调整翻译，这是很正常的。因此，需要译者密切跟踪项目的开发进度，以便及时响应，避免项目新版本到达用户手中时，在已部分翻译的软件中出现英文字符串。

这里情况变得复杂了，自由软件项目至少有数千个，甚至数十万个。语言也有数千种，我们能否拥有足够多的各语种译者来跟踪所有这些项目呢？肯定不能。

翻译集成流程

现在让我们看几个项目的例子，了解软件开发和翻译流程之间的交互是如何组织的。

可翻译……但很过时！

Jitsi Meet 是一款在线视频会议软件，在其源代码中，lang 文件夹包含每种语言的一个 JSON 文件。

每次翻译都必须通过合并请求提交，这既复杂又耗时。

几分钟内我就找到了一个极端的例子，这个请求已等待超过 8 个月。然而，在此期间，包含软件待翻译字符串的文件已经更改了 19 次，并且已经发布了 8 个版本！

在 readme 中没有关于如何翻译的信息，贡献指南中也没有。

人数较多的语言社区可能凭借贡献者的数量花费必要的时间（但也不一定……），其他所有语言都将被抛在一边，软件只会为已经被过度代表的语言提供最新翻译。要跟踪变更，可能需要订阅 GitHub 项目的变更通知。

人们会对这种工作方式的效率产生质疑，虽然可以肯定允许翻译软件的努力，但我对这类贡献缺乏重视感到遗憾。我没有与 Jitsi Meet 团队进行讨论，事情并不总是这样的，过去曾经使用过翻译平台。

清晰……但非常特定于 GNOME

GNOME 项目使用类似的方式，但专注于翻译团队的需求。要将翻译提交到最终软件中，必须使用 git。但是，一个工具可供译者使用，让他们准确知道哪些内容需要翻译，并进行协作。此外，GNOME 生态系统中的大量软件遵循相同的新版本节奏和工作流程。因此，虽然流程不完美且需要手动操作，但工具大大降低了贡献者的管理成本。

高效……但非常特定于 Mozilla

Mozilla 项目将翻译视为其活动中的关键主题，如果您想为其做出贡献，可以访问 Pontoon 翻译平台（项目按翻译团队组织）。

了解哪些内容可以翻译很容易，找到联系人解答问题也同样容易。

这个项目非常庞大，您可能在理解翻译平台和软件发布之间的步骤时会遇到一些困难，但这重要吗？它运行得很好，软件发布日期是已知的，优先级是明确的。您可能需要花一些时间来建立团队和审核流程，所有工具都是 Mozilla 项目专用的，但总体来说，还是相当高效的。

自动化且通用，解放性的现代方式

可以提供一个专用于翻译活动的工具，允许订阅变更通知、多人协作以及异常检测。

而且，最大的优势是能够与软件源代码自动同步。

一个优秀的例子：Weblate 翻译平台展示了应该遵循的模式，一切都是连接和自动化的。翻译修改非常频繁，而影响翻译的变更也很容易找到。

许多项目都使用 Weblate，无论您的情况如何，这都是您应该做出的选择。在翻译平台生态系统中，Weblate 已经变得像 git 之于软件开发中的源代码管理一样显而易见和高效。

如果您的项目提供了这个平台，那么您就为语言贡献提供了行动能力，通过用心维护与这个庞大社区的关系，您将有很大的机会获得一个被翻译成多种语言的工具。

结论

项目技术生命周期与翻译之间的衔接对于翻译流程的效率至关重要。

已有充满有用功能和自动化的工具来方便每个人的工作。

开发团队只需要拥抱这些工具，就能让软件包含更多的翻译，支持越来越多的语言。

但是，当项目不再发布新版本时会发生什么？如何弥补一个沉睡的项目？这将是未来文章的主题。