注意

此页面包含关于翻译基础设施的当前和旧的信息，以及旧的 Transifex 信息。请访问 Translation infrastructure 页面以获取最新信息。

翻译基础设施流程和设置

OpenStack Infrastructure 团队使用一系列脚本与 Zanata（一个翻译平台）交互，以管理翻译更改。本文档解释了基础设施流程和用于完成此目的的脚本。

这些脚本在每次项目更改后运行，以将更改推送到 Zanata。每天 UTC 时间 6:00，“OpenStack Proposal Bot”会导入这些更改，主题为“Imported Translations from Zanata”。

有关翻译的更多信息，请参阅 translations page 和 i18n team page。

Zanata 信息

已设置翻译的所有项目列表：https://translate.openstack.org/project/list

项目是从 projects.yaml 设置的，用于将“translate”选项设置为 on 的仓库。

受影响的文件

这些脚本处理 $PROJECT/locale 中的所有文件。仅在初始翻译设置或出现问题时，才需要对这些文件进行手动补丁。

项目

Zanata 为每个 OpenStack 项目都有一个单独的项目。

对于 Zanata 中的每个 Python 项目，都有几个资源，例如 Barbican - 就像所有 Python 项目一样 - 具有以下文档

barbican-log-critical-translations: LOG.critical 消息的翻译
barbican-log-error-translations: LOG.error 消息的翻译
barbican-log-info-translations: LOG.info 消息的翻译
barbican-log-warning-translations: LOG.warn 消息的翻译
barbican-translations: “正常”消息的翻译

UI 项目（如 horizon）和文档项目具有不同的要翻译的文档。

翻译百分比

所有翻译都存储在 Zanata 中， $PROJECT 中的副本只是副本。为了保持一致性，我们希望翻译文件被充分翻译，如果 5 个字符串中只有 1 个被翻译，其余的都是英文，则没有意义。因此，我们与 I18n 团队定义了百分比类型，并且百分比值在 https://docs.openstack.org/developer/i18n/infra.html#translation-jobs 中描述。

工作流程

所有 Python 项目的设置方式相同，所以这里使用 $PROJECT。$PROJECT 是仓库的名称。

文件位于 $PROJECT 仓库目录 $PROJECT/locale/。

流程如下

对 $PROJECT 的补丁合并到 git（这适用于每个补丁）
运行一个名为 $PROJECT-upstream-translation-update 的 post job，该 job 调用 upstream_translation_update.sh
该脚本提取任何标记用于翻译的字符串，并更新 $PROJECT/locale/ 中的 pot 文件。
该脚本将这些更改发送到 Zanata 实例

现在翻译过程开始，翻译人员为项目的每个资源编写翻译。翻译人员也可以在 Zanata 中查看翻译。每天早上 UTC 时间 6:00，我们的定期脚本会执行

执行 job $PROJECT-propose-translation-update，它签出仓库并调用脚本 propose_translation_update.sh。
该脚本连接到 Zanata 并请求下载每个资源的所有“充分翻译”的文件。我们定义“充分”为至少 X 百分比的字符串被翻译。
该脚本连接到 Zanata 并请求下载每个现有资源的更新。
该脚本生成项目的 pot 文件，因为 pot 文件已过时（upstream_translation_update 不会触及 git 仓库）。
该脚本合并翻译和 pot 文件
该脚本删除不再有字符串或翻译少于 Y 百分比的翻译文件
该脚本过滤翻译的文件并进行一些启发式方法，以避免过于频繁的更新（例如，如果项目没有翻译文件的更新，则它不会更新 pot 文件）。
该脚本删除语言文件中的位置信息和空字符串。
如果仓库中有更改，则会向项目提出一个补丁
该补丁经过 Gerrit 中的常规审查流程，但有一个例外：大多数项目不会等待第二个核心并检查它是否通过所有测试。核心不会审查翻译，审查由 Zanata 中的翻译人员完成。核心只是审查整体内容是否良好。
如果补丁出现问题，核心应向 i18n 团队发送消息，并告知他们问题。然后有人需要调查翻译或工具是否损坏。

由于定期脚本每天早上（UTC）运行，因此通常会发生更新

这些脚本检查是否有旧补丁并重用 ChangeID，以便它是一个新的补丁集
任何对补丁的投票都会重置（因此，+1、-1、WIP 和 +2 - -2 是持久的）
一个注意事项：如果一个补丁被批准并且在 gate 中，则不会提出新的补丁。我们有时会有很长的队列（超过 25 小时），如果没有此测试，一个补丁可能永远不会进入，因为每 24 小时都会提出一个新的补丁，然后需要时间来批准它。
如果一个补丁被核心放弃，如果内容有更新，则会提出一个新的补丁。

已经充分翻译的项目，例如 Nova，几乎每天都会提出一个新的补丁。尚未翻译的项目，例如 Swift，不应提出任何补丁。

请注意，只有 *.pot 文件包含文件名和行号等位置信息，并将这些信息推送到 Zanata。翻译文件 (*.po) 没有位置信息，也没有空字符串。如果您需要这些，请从 Zanata 下载完整的 po 文件，或运行 msgmerge POT-FILE PO-FILE -o FULL-PO-FILE

标记用于翻译

字符串在 Python 代码中使用 gettext 约定标记（请参阅 oslo.i18n docu）

_("some string") - 是一个可翻译的字符串，例如 print (_("translate me"))
对于日志记录，它是 LOG.info(_LI("info message")) - 并且也有 _LE 用于 LOG.error、_LW 用于 LOG.warning、_LC 用于 LOG.critical
像 print("Do not translate") 这样的普通字符串不会被翻译

Horizon

翻译过程基本上与上述相同，除了需要安装 Horizon 才能提取 Django 项目的字符串。更多详细信息在公共脚本部分中描述：project-config/jenkins/common_translation_update.sh。

文档项目

对于 api-site、ha-guide、openstack-manuals、operations-guide 和 security-guide 等文档仓库，也使用一个单独的项目。

流程与 Python 项目相同，但有以下区别

由于文档文件不标记字符串，因此提取所有字符串进行翻译。
文档文件位于像 $PROJECT/doc 和 $PROJECT/install-guide 这样的子文件夹中。从 RST 生成的 PO 文件存储在 source/locale/ 子文件夹中。

这些差异由上述脚本通过公共脚本部分管理：project-config/jenkins/common_translation_update.sh。

所有具有翻译的文档项目还具有一个单独的 Jenkins 检查，该检查会构建本地化的手册 - 并且这些手册也会发布在 docs.openstack.org 上。

对于构建本地化的文档，使用脚本 `doc-tools-check-languages`，它位于 openstack-doc-tools 仓库中。它通过 `doc-tools-check-languages.conf` 进行配置。同步脚本也会解析此文件。

在 `doc-tools-check-languages.config` 中，数组 `SPECIAL_BOOKS` 由同步脚本使用。其他值由 `doc-tools-check-languages` 使用

`skip`: 不要将此目录的内容发送到翻译服务器
`RST`: 此目录使用 RST 作为文档格式，因此需要与 DocBook XML 文件不同对待。

字符串冻结

请注意，字符串冻结是针对开发人员的。目标是让翻译人员有机会赶上进度，而不是让字符串一直变化。我们的基础设施中没有强制执行字符串冻结。

发布处理

请注意，以下信息是 Liberty 版本（2015 年 10 月）的当前信息。

挑战：如何在主分支已经开放用于新发布时翻译发布分支？

提案：为所有具有当前翻译和主文件的项目创建稳定分支（因此，不仅仅是 LOG 文件）。

目标

更新翻译的文件，这些文件被充分翻译（> X %）
更新 po 源文件，反映仓库的状态
没有空/主要未翻译的语言文件（< Z % 是经验法则）

项目列表

以下项目具有翻译和分支，并将获得稳定分支

具有翻译分支的项目列表

openstack/aodh
openstack/ceilometer
openstack/cinder
openstack/designate-dashboard
openstack/django_openstack_auth
openstack/glance
openstack/heat
openstack/horizon
openstack/keystone
openstack/neutron
openstack/nova
openstack/swift
openstack/zaqar

稍后分支的项目列表

openstack/openstack-manuals - 翻译安装指南

未翻译的项目

分支中没有翻译的仓库列表

openstack/designate
openstack/ironic-inspector
openstack/magnum
openstack/magnum-ui
openstack/manila
openstack/sahara
openstack/searchlight

仅具有 LOG 翻译的仓库列表

openstack/barbican
openstack/glance_store
openstack/ironic
openstack/trove

不分支的项目列表

openstack/api-site
openstack/ha-guide
openstack/operations-guide
openstack/security-doc

库和客户端列表，我们现在不为它们创建单独的分支

openstack/oslo.cache
openstack/oslo.concurrency
openstack/oslo.db
openstack/oslo.i18n
openstack/oslo.log
openstack/oslo.messaging
openstack/oslo.middleware
openstack/oslo.policy
openstack/oslo.reports
openstack/oslo.service
openstack/oslo.utils
openstack/oslo.versionedobjects
openstack/oslo.vmware
openstack/python-magnumclient
openstack/python-openstackclient

流程

. 在 RC1 切割之前，翻译人员使用主版本。
. 当切割稳定分支时，Zanata 中也会创建分支。将启用它们之间的同步。
. 翻译人员专注于翻译稳定分支。主分支设置为只读。
. 一旦翻译人员完成翻译，Zanata 中会将稳定分支的新翻译复制到主分支。
. 打开主版本以接受翻译。

注意：在 RC1 时间，会向稳定分支和主分支（如果已切割）提出一个补丁，以清理“旧”翻译，删除 git 中少于 Y % 翻译的任何翻译（基础设施作业只会删除少于 Y % 的文件，以避免过于频繁的删除）。

新提案

以下提案需要稳定维护团队和 I18n 团队的同意

在 RC1 切割之前，翻译人员使用主版本。
当切割稳定分支时，Zanata 中也会创建分支。将启用它们之间的同步。
翻译人员专注于翻译稳定分支。主分支设置为只读。
发布经理将在 RC1 之后 10 天左右切割 RC2，其中包括翻译人员工作的当前状态。
创建 RC2 后，Zanata 中会将稳定分支的新翻译复制到主分支。
主分支设置为可写，现在可以为稳定分支和主分支进行翻译。
稳定分支的翻译将继续同步，翻译人员可以继续翻译。
简而言之，在下一个稳定版本的 RC1 切割之前，Zanata 中的稳定分支将被关闭。因此，始终只有一个稳定分支（最新版本）和一个用于翻译的主分支。

请注意，在 RC2 合并之后，不会自动从稳定分支复制到主分支。如果选择继续翻译稳定分支，翻译团队需要为特定项目请求合并。

请注意，只有在仓库中至少有一个主文件的翻译的情况下，才会创建稳定分支。仅包含日志文件翻译或没有翻译的仓库不会分支。如果至少 X 百分比的消息被翻译，我们认为一个文件被翻译。

注意：在 RC1 时间，会向主分支（如果已切割，则向稳定分支）提出一个补丁，以清理“旧”翻译文件，删除 git 中少于 Y % 翻译的任何翻译（基础设施作业只会删除少于 Y % 的文件，以避免过于频繁的删除）。

翻译/基础设施

目录