第 8 章。国际化与翻译

目录

8.1. Debian 中如何处理翻译
8.2. 维护者 I18N & L10N 常见问题解答
8.2.1. 如何翻译给定的文本
8.2.2. 如何审查给定的翻译
8.2.3. 如何更新给定的翻译
8.2.4. 如何处理关于翻译的错误报告
8.3. 译者 I18N & L10N 常见问题解答
8.3.1. 如何帮助翻译工作
8.3.2. 如何提供翻译以包含在软件包中
8.4. 关于 l10n 的最佳实践

Debian 支持越来越多的自然语言。即使您是以英语为母语的人,并且不会说任何其他语言,了解国际化问题(缩写为 i18n,因为 internationalization 中 'i' 和 'n' 之间有 18 个字母)也是您作为维护者职责的一部分。因此,即使您对仅使用英语的程序感到满意,也应该阅读本章的大部分内容。

根据 Tomohiro KUBOTA 的 i18n 简介,I18N(国际化)是指修改软件或相关技术,以便软件可以潜在地处理世界上多种语言、习俗等等,而 L10N(本地化)是指为已经国际化的软件实现特定语言。

l10n 和 i18n 是相互关联的,但与它们相关的困难却大相径庭。允许程序根据用户设置更改显示文本的语言并不是真的很难,但实际翻译这些消息非常耗时。另一方面,设置字符编码是微不足道的,但调整代码以使用多种字符编码却是一个非常困难的问题。

抛开 i18n 问题不谈,在这些问题上无法给出通用指南,实际上 Debian 中没有可以与移植的 buildd 机制相提并论的 l10n 中央基础设施。因此,大部分工作必须手动完成。

8.1. Debian 中如何处理翻译

处理软件包中包含的文本的翻译仍然是一项手动任务,并且该过程取决于您希望翻译的文本类型。

对于程序消息,大多数时候使用 gettext 基础设施。大多数时候,翻译在上游项目中处理,例如 Free Translation ProjectGnome translation ProjectKDE one。Debian 中唯一的集中资源是 Debian 中央翻译统计,您可以在其中找到有关实际软件包中找到的翻译文件的一些统计信息,但没有真正的基础设施来简化翻译过程。

翻译软件包描述的工作很久以前就开始了,即使工具为实际使用它们提供的支持很少(即,只有 APT 可以在正确配置时使用它们)。维护者不需要做任何特殊的事情来支持翻译后的软件包描述;译者应该使用 Debian 描述翻译项目 (DDTP)

对于 debconf 模板,维护者应该使用 po-debconf 软件包来简化译者的工作,译者可以使用 DDTP 来完成他们的工作(但法国和巴西团队没有这样做)。一些统计信息可以在 DDTP 站点(关于实际翻译的内容)和 Debian 中央翻译统计站点(关于软件包中集成的部分)上找到。

对于网页,每个 l10n 团队都有权访问相关的 VCS,并且统计信息可从 Debian 中央翻译统计站点获得。

对于关于 Debian 的通用文档,该过程与网页的过程大致相同(译者有权访问 VCS),但没有统计页面。

对于特定于软件包的文档(man 页面、info 文档、其他格式),几乎所有事情都还有待完成。

最值得注意的是,KDE 项目以与其程序消息相同的方式处理其文档的翻译。

正在努力在 特定的 VCS 存储库中处理 Debian 特定的 man 页面。

8.2. 维护者 I18N & L10N 常见问题解答

这是维护者可能面临的关于 i18n 和 l10n 的问题列表。在阅读本文时,请记住 Debian 内部在这些问题上没有真正的共识,这仅仅是建议。如果您对给定的问题有更好的想法,或者如果您不同意某些观点,请随时提供您的反馈,以便可以改进本文档。

8.2.1. 如何翻译给定的文本

要翻译软件包描述或 debconf 模板,您无需执行任何操作;DDTP 基础设施会将要翻译的材料分发给志愿者,而无需您的互动。

对于所有其他材料(gettext 文件、man 页面或其他文档),最好的解决方案是将您的文本放在 Internet 上的某个位置,并在 debian-i18n 上请求不同语言的翻译。一些翻译团队成员订阅了此列表,他们将负责翻译和审查过程。完成后,您将从他们的邮箱中收到翻译后的文档。

8.2.2. 如何审查给定的翻译

有时,个人会翻译您软件包中的一些文本,并要求您将翻译包含在软件包中。如果您不精通给定的语言,这可能会成为问题。最好将文档发送到相应的 l10n 邮件列表,请求审查。完成后,您应该对翻译的质量更有信心,并且可以安全地将其包含在您的软件包中。

8.2.3. 如何更新给定的翻译

如果您手头有一些给定文本的翻译,每次您更新原文时,都应该要求之前的译者使用您的新更改来更新翻译。请记住,此任务需要时间;至少需要一周的时间才能完成更新审查等等。

如果译者没有回应,您可以向相应的 l10n 邮件列表寻求帮助。如果一切都失败了,请不要忘记在翻译后的文档中添加警告,说明翻译已过时,并且读者应尽可能参考原始文档。

避免因为翻译过时而完全删除翻译。对于非英语使用者来说,旧文档通常比没有文档要好。

8.2.4. 如何处理关于翻译的错误报告

最好的解决方案可能是将错误标记为已转发到上游,并将其转发给之前的译者及其团队(使用相应的 debian-l10n-XXX 邮件列表)。

8.3. 译者 I18N & L10N 常见问题解答

在阅读本文时,请记住 Debian 内部在这些问题上没有通用的程序,并且在任何情况下,您都应该与您的团队和软件包维护者合作。

8.3.1. 如何帮助翻译工作

选择您要翻译的内容,确保没有人已经在处理它(使用您的 debian-l10n-XXX 邮件列表),翻译它,在您的 l10n 邮件列表上由其他母语人士审查它,并将其提供给软件包的维护者(见下一点)。

8.3.2. 如何提供翻译以包含在软件包中

在提供翻译以包含之前,请确保您的翻译是正确的(在您的 l10n 邮件列表上请求审查)。这将节省大家的时间,并避免在错误报告中出现同一文档的多个版本而造成的混乱。

最好的解决方案是针对软件包提交一个包含翻译的常规错误报告。确保使用 'PATCH' 标签,并且不要使用高于 'wishlist' 的严重性,因为缺少翻译永远不会阻止程序运行。

8.4. 关于 l10n 的最佳实践

  • 作为维护者,在没有在相应的 l10n 邮件列表上询问的情况下,永远不要以任何方式编辑翻译(即使是重新格式化布局)。例如,您这样做有可能会破坏文件的编码。此外,您认为的错误在给定的语言中可能是正确的(甚至是必需的)。

  • 作为译者,如果您在原文中发现错误,请务必报告。译者通常是对给定文本最认真的读者,如果他们不报告他们发现的错误,就没有人会报告。

  • 在任何情况下,请记住 l10n 的主要问题是它需要多人合作,并且由于误解,很容易就小问题引发口水战。因此,如果您与您的对话者有问题,请在相应的 l10n 邮件列表、debian-i18n 甚至 debian-devel 上寻求帮助(但请注意,l10n 讨论在该列表上经常会变成口水战:)

  • 在任何情况下,合作只能通过 互相尊重 来实现。