跳转到：导航, 搜索

注意：我们已于 2015 年 9 月切换到使用 Zanata 进行 Liberty 周期。请将问题发送至 openstack-i18n 邮件列表，并更新下面的文档以完整解释 Zanata。

OpenStack 中的翻译、国际化和本地化

OpenStack 致力于广泛的国际支持，因此必须持续关注使 OpenStack 对所有受众可用。这包括开发人员正确使用国际化和本地化工具，以及为用户界面消息和文档提供高质量的翻译。

翻译与管理

让我们从一个工作定义开始：翻译是将一种语言的书面材料转换为另一种语言的最有意义的方式。在 OpenStack 方面，翻译发生在书面文档和代码库中标记为翻译的字符串上。

注意：有关如何准备您的代码或文档以进行翻译的信息，请参阅下面的国际化部分。

Zanata

OpenStack 正在使用位于 https://translate.openstack.org/ 的 Zanata 实例作为翻译管理平台。

下载翻译文件

如果您想下载翻译文件（.po 文件），您可以选择您感兴趣的语言，然后单击您要下载的项目资源名称。在出现的模态对话框中，您可以根据您的使用情况使用任何“下载”选项。

在网站上翻译

最有效的方式是在 Zanata 网站上进行翻译。您无需下载任何文件或应用程序即可开始。

如果您的语言已存在，请选择一个项目，选择“master”版本，选择您的语言，然后选择一个文档开始翻译。

下载翻译文件

您也可以下载翻译文件并本地翻译。

待办事项：详细说明如何使用 Zanata 完成此操作。

发布周期

管理开源项目中的翻译最具挑战性的方面之一是处理发布周期期间翻译人员和开发人员之间的相互作用。这个等式的关键是“字符串冻结”。

字符串冻结

注意：OpenStack 的字符串冻结发生在开发周期的最后一个里程碑结束时，让翻译人员在整个 RC 期间更新翻译。

在发布周期的预定义时间，将进行“字符串冻结”，这意味着在此之后，代码库中标记为翻译的字符串不能再更改，除非出现关键优先级的错误。

一旦字符串冻结生效，Zanata 中的翻译文件可以被假定为静态，并且翻译工作应该全力进行。这并不是说翻译不能一直进行。但在开发过程中，字符串可能会更改，并且翻译工作可能会被浪费。

RC 期间的任何更改都应仔细审查，以确保它们不会更改或添加翻译字符串，或者与翻译人员协调，以确保妥善处理更改。

请查看 https://docs.openstack.org/project-team-guide/release-management.html 以获取更多详细信息。

重新合并翻译

OpenStack 基础设施团队已设置自动生成翻译审查，以便可以随时以最少的努力重新合并它们。对于在我们的 CI 基础设施中设置此功能的每个项目，每天都会运行一个作业。此作业会重新生成原始 pot 文件并导入所有翻译良好的文件，然后将它们作为补丁提交给项目。只有翻译字符串达到 75% 或以上的的文件才会被下载。

当前开放的提议导入列表可在 review.openstack.org 上找到。

最重要的是，在每个 Release Candidate 的发布之前，以及在每个版本的 Final Release 之前，翻译文件应合并回各自的项目，以确保它们与发布一起正确分发。

目前，这是每个项目 PTL 或指定的翻译经理的责任，但 OpenStack 的发布经理、翻译团队协调员等也鼓励帮助确保顺利进行。

稳定版本和回溯

目前，翻译的更改不会回溯到稳定版本分支。这样做需要维护每个翻译集完全独立的副本，并大大增加翻译人员的负担。

国际化 (i18n)

术语国际化用于广泛描述允许软件适应不同地区语言和技术差异的编码实践。这包括标记字符串以进行翻译、支持非 ASCII 字符集等实践。

将翻译集成到您的项目中

Python 项目（通用）

对于大多数 OpenStack 核心项目（以及使用 Python 的任何项目），国际化的首选工具是 gettext 和 babel（Debian/Ubuntu 包名称 python-pybabel）。入门非常容易

采用 oslo.i18n

第一步是在您的项目中采用 oslo.i18n - 如何在您的应用程序或库中使用 oslo.i18n

提取消息

一旦您有了要翻译的消息，我们需要使用 Babel 提取这些消息。最简单的方法是在 py27 venv 中运行“python setup.py extract_messages”。

配置您的项目以使用 Babel 轻松创建翻译文件。首先，将 `Babel` 添加到您的 requirements.txt 文件（或您跟踪依赖项的位置）。其次，在项目的根目录中创建一个 `babel.cfg` 文件；最简单的情况下，它可以只包含这一行

[python: **.py]

最后，将以下内容添加到您的 `setup.cfg` 文件

[extract_messages]
keywords = _ gettext ngettext l_ lazy_gettext
mapping_file = babel.cfg
output_file = <project name>/locale/<project name>.pot

这将允许您运行 `python setup.py extract_messages` 并自动生成项目的基本翻译资源文件。

现在您准备将生成的文件合并到您的项目中（参见示例 review）。请注意，需要将初始文件导入到您的项目中，才能与翻译站点交互的脚本正常工作。

设置 Zanata 服务器，导入和导出翻译

现在您准备好设置 Zanata 和 CI 基础设施。阅读 Infra 手册了解如何操作。

Horizon (Django)

Django 具有内置的国际化工具，这些工具远远超出了 `gettext` 的基本功能，以确保整个代码库中都具有适当的 Unicode 支持，并使高级功能更容易访问。因此，Horizon 使用 Django 的 `ugettext` 函数系列。

#!highlight python
from django.utils.translation import ugettext, ugettext_lazy  # ..., etc.

有关 Django 提供的国际化工具的更多信息，请参阅 Django i18n 文档。

文档 (DocBook)

虽然可以仅用英语维护项目开发人员文档，但 OpenStack Docs 团队制作和维护的用户面向文档也是翻译的重中之重。这包括安装和管理手册。

注意：对于第一个版本，这不包括 API 文档。这些通常在 `openstack-manuals` 项目中获取。

有关 OpenStack 文档的翻译，请参阅 Documentation/Translation。

要翻译的内容

目前，约定是翻译所有用户界面字符串。这意味着 API 消息、CLI 响应、文档、帮助文本等。

有关翻译日志消息的信息，请参阅 LoggingStandards#Log_Translation。

异常文本不应标记为翻译，因为如果发生异常，则无法保证翻译机制正常工作。

本地化 (L10n)

术语本地化比国际化更具体地用于描述允许软件的输入和输出特征适应不同地区风格差异的编码实践。这包括日期和数字格式等。

日期、数字和其他注意事项

超越国际化所实现的内容，最重要的方面是考虑日期和数字格式的区域差异。例如：

Dates:
    04/01/2012 == April 1st, 2012 (US)
    04/01/2012 == January 4th, 2012 (UK)

Numbers:
    1,000.42 == One thousand and 42 hundredths (US)
    1.000,42 == One thousand and 42 hundredths (EU)

接受任何格式并天真地将其传递到我们的代码中会严重破坏一切。仅接受一种格式会排除世界上很大一部分人。因此，我们使用本地化工具来接受这些格式并将它们规范化为 Python 可以普遍处理的数据结构，并在输出时将它们转换回用户期望的格式。

另一个不太常见（对于 OpenStack）的与本地化相关的问题涉及名称格式，这些格式因文化而异。西方风格的“名字”和“姓氏”不适合许多文化命名约定。软件工具无法解决这个问题，因此对于此类问题，最好的解决方案是尽可能接受最广泛的输入（例如，单个“名称”字段）。