Kubernetes 文档本地化
此页面向您展示如何本地化不同语言的文档。
贡献到现有的本地化
您可以帮助添加或改进现有本地化的内容。在 Kubernetes Slack 中，您可以找到每个本地化对应的频道。还有一个通用的 SIG Docs Localizations Slack 频道，您可以在那里问好。
说明
有关如何贡献到特定本地化的更多详细信息，请查找该页面的本地化版本。查找您的双字母语言代码
首先，请查阅 ISO 639-1 标准 以查找您的本地化的双字母语言代码。例如，韩语的双字母代码是 ko。
有些语言使用 ISO-3166 定义的国家/地区代码的小写版本以及它们的语言代码。例如，巴西葡萄牙语的语言代码是 pt-br。
Fork 并克隆仓库
首先，创建您自己的 fork 的 kubernetes/website 仓库。
然后，克隆您的 fork 并 cd 进入它
git clone https://github.com/<username>/website
cd website
网站内容目录包含每个语言的子目录。您想要帮助的本地化位于 content/<two-letter-code> 内部。
建议更改
根据英文原文创建或更新您选择的本地化页面。有关更多详细信息，请参阅 本地化内容。
如果您发现上游（英文）文档中的技术错误或其他问题，您应该首先修复上游文档，然后通过更新您正在处理的本地化来重复相同的修复。
请将拉取请求中的更改限制为单个本地化。审查更改多个本地化内容的拉取请求会比较麻烦。
按照 建议内容改进 提出对该本地化的更改。该过程与向上游（英文）内容提出更改类似。
开始新的本地化
如果您希望将 Kubernetes 文档本地化为新的语言，您需要执行以下操作。
由于贡献者无法批准自己的拉取请求，因此您需要至少两位贡献者才能开始本地化。
所有本地化团队必须自给自足。Kubernetes 网站很高兴托管您的工作，但翻译它并保持现有本地化内容的最新状态由您负责。
您需要知道您的语言的双字母语言代码。请查阅 ISO 639-1 标准 以查找您的本地化的双字母语言代码。例如，韩语的双字母代码是 ko。
如果您的语言在不同的地方使用，并且变体之间存在显着差异，那么将小写的 ISO-3166 国家/地区代码与语言双字母代码结合起来可能是有意义的。例如，巴西葡萄牙语本地化为 pt-br。
当您开始新的本地化时，您必须本地化所有 最低要求的内容，然后 Kubernetes 项目才能将您的更改发布到实时网站。
SIG Docs 可以帮助您在单独的分支上工作，以便逐步实现该目标。
寻找社区
让 Kubernetes SIG Docs 知道您有兴趣创建本地化！加入 SIG Docs Slack 频道 和 SIG Docs Localizations Slack 频道。其他本地化团队很乐意帮助您入门并解答您的问题。
请考虑参加 SIG Docs Localization Subgroup 会议。SIG Docs 本地化子组的任务是跨 SIG Docs 本地化团队合作，定义和记录创建本地化贡献指南的流程。此外，SIG Docs 本地化子组寻找机会在本地化团队之间创建和共享通用工具，并确定 SIG Docs 领导团队的新需求。如果您对此会议有任何疑问，请在 SIG Docs Localizations Slack 频道 上咨询。
您还可以在 kubernetes/community 仓库中为您的本地化创建一个 Slack 频道。有关添加频道的示例，请参阅 为波斯语添加频道 的 PR。
加入 Kubernetes GitHub 组织
当您打开本地化 PR 时，您可以成为 Kubernetes GitHub 组织的成员。团队中的每个人都需要在 kubernetes/org 仓库中创建一个 组织成员资格请求。
在 GitHub 中添加您的本地化团队
接下来，将您的 Kubernetes 本地化团队添加到 sig-docs/teams.yaml。有关添加本地化团队的示例，请参阅 添加西班牙语本地化团队 的 PR。
@kubernetes/sig-docs-**-owners 的成员可以批准更改内容（且仅更改内容）的 PR，即 /content/**/。对于每个本地化，@kubernetes/sig-docs-**-reviews 团队会自动为新的 PR 分配审查任务。@kubernetes/website-maintainers 的成员可以创建新的本地化分支以协调翻译工作。@kubernetes/website-milestone-maintainers 的成员可以使用 /milestone Prow 命令 将里程碑分配给问题或 PR。
配置工作流
接下来，在 kubernetes/test-infra 仓库中为您的本地化添加一个 GitHub 标签。标签允许您过滤特定语言的问题和拉取请求。
有关添加标签的示例，请参阅 添加意大利语标签 的 PR。
修改站点配置
Kubernetes 网站使用 Hugo 作为其 Web 框架。网站的 Hugo 配置位于 hugo.toml 文件中。您需要修改 hugo.toml 以支持新的本地化。
将新的配置块添加到 hugo.toml 中现有的 [languages] 块下。例如，德语块如下所示
[languages.de]
title = "Kubernetes"
languageName = "Deutsch (German)"
weight = 5
contentDir = "content/de"
languagedirection = "ltr"
[languages.de.params]
time_format_blog = "02.01.2006"
language_alternatives = ["en"]
description = "Produktionsreife Container-Orchestrierung"
languageNameLatinScript = "Deutsch"
语言选择栏显示 languageName 的值。将“本地语言脚本和语言（拉丁脚本中的英语语言名称）”分配给 languageName。例如，languageName = "한국어 (Korean)" 或 languageName = "Deutsch (German)"。
languageNameLatinScript 可用于访问拉丁脚本中的语言名称并在主题中使用它。将“拉丁脚本中的语言名称”分配给 languageNameLatinScript。例如，languageNameLatinScript ="Korean" 或 languageNameLatinScript = "Deutsch"。
weight 参数确定语言选择栏中语言的顺序。较低的权重优先，导致该语言首先出现。在分配 weight 参数时，重要的是检查现有的语言块并调整它们的权重，以确保它们相对于所有语言（包括任何新添加的语言）进行排序。
有关 Hugo 的多语言支持的更多信息，请参阅 "多语言模式"。
添加新的本地化目录
将特定于语言的子目录添加到仓库的 content 文件夹中。例如，德语的双字母代码是 de
mkdir content/de
您还需要在 i18n 内部创建一个目录来存储 本地化字符串；请查看现有的本地化以获取示例。
例如，对于德语，字符串位于 i18n/de.toml。
本地化社区行为准则
打开针对 cncf/foundation 仓库的 PR，以添加您的语言的行为准则。
设置 OWNERS 文件
要设置每个为本地化做出贡献的用户角色，请在特定于语言的子目录中创建一个 OWNERS 文件，其中包含
- reviewers：具有审查角色的 Kubernetes 团队列表，在本例中，
- 在 在 GitHub 中添加您的本地化团队 中创建的
sig-docs-**-reviews团队。 - approvers：具有批准角色的 Kubernetes 团队列表，在本例中，
- 由在 在 GitHub 中添加您的本地化团队 中创建的
sig-docs-**-owners团队创建。 - 标签：要自动应用于 PR 的 GitHub 标签列表，在本例中，是在 配置工作流 中创建的语言标签。
有关 OWNERS 文件的更多信息，请参见 go.k8s.io/owners。
西班牙语 OWNERS 文件，语言代码为 es，如下所示
# See the OWNERS docs at https://go.k8s.io/owners
# This is the localization project for Spanish.
# Teams and members are visible at https://github.com/orgs/kubernetes/teams.
reviewers:
- sig-docs-es-reviews
approvers:
- sig-docs-es-owners
labels:
- area/localization
- language/es
添加特定于语言的 OWNERS 文件后，使用本地化新的 Kubernetes 团队，sig-docs-**-owners 和 sig-docs-**-reviews 更新根 OWNERS_ALIASES 文件。
对于每个团队，请按照 在 GitHub 中添加您的本地化团队 中请求的列表，按字母顺序添加 GitHub 用户。
--- a/OWNERS_ALIASES
+++ b/OWNERS_ALIASES
@@ -48,6 +48,14 @@ aliases:
- stewart-yu
- xiangpengzhao
- zhangxiaoyu-zidif
+ sig-docs-es-owners: # Admins for Spanish content
+ - alexbrand
+ - raelga
+ sig-docs-es-reviews: # PR reviews for Spanish content
+ - alexbrand
+ - electrocucaracha
+ - glo-pena
+ - raelga
sig-docs-fr-owners: # Admins for French content
- perriea
- remyleone
打开一个 pull request
接下来，打开一个 pull request (PR) 以将本地化添加到 kubernetes/website 仓库。 在 PR 可以被批准之前，必须包含所有 最低要求的内容。
有关添加新本地化的示例，请参阅启用 法语文档 的 PR。
添加本地化的 README 文件
为了指导其他本地化贡献者，请在 kubernetes/website 的顶层添加一个新的 README-**.md，其中 ** 是两位字母的语言代码。 例如，德语 README 文件将是 README-de.md。
在本地化的 README-**.md 文件中指导本地化贡献者。 包含与 README.md 相同的信息，以及
- 本地化项目的联系人
- 特定于本地化的任何信息
创建本地化的 README 后，从主要的英语 README.md 添加指向该文件的链接，并包含英语联系信息。 您可以提供 GitHub ID、电子邮件地址、Slack 频道 或其他联系方式。 您还必须提供指向您的本地化行为准则的链接。
启动您的新本地化
当本地化满足工作流和最低输出要求时，SIG Docs 会执行以下操作
- 启用网站上的语言选择。
- 通过 云原生计算基金会(CNCF) 渠道，包括 Kubernetes 博客，宣传本地化的可用性。
本地化内容
本地化所有 Kubernetes 文档是一项巨大的任务。 从小处着手并随着时间的推移进行扩展是可以的。
最低要求内容
至少，所有本地化必须包括
| 描述 | URLs |
|---|---|
| 首页 | 所有标题和副标题 URLs |
| 设置 | 所有标题和副标题 URLs |
| 教程 | Kubernetes 基础知识、Hello Minikube |
| 站点字符串 | 所有站点字符串 在一个新的本地化 TOML 文件中 |
| 发布版本 | 所有标题和副标题 URLs |
翻译后的文档必须位于其自身的 content/**/ 子目录中，但除此之外，应遵循与英语源文件相同的 URL 路径。 例如，要为 Kubernetes 基础知识 教程准备德语翻译，请在 content/ 目录中创建一个子目录，并复制英语源文件或目录
mkdir -p content/docs/tutorials
cp -ra content/en/docs/tutorials/kubernetes-basics/ content/docs/tutorials/
翻译工具可以加快翻译过程。 例如，一些编辑器提供插件来快速翻译文本。
注意
机器生成的翻译本身是不够的。 本地化需要广泛的人工审查才能达到最低质量标准。为了确保语法和含义的准确性，您的本地化团队成员应在发布之前仔细审查所有机器生成的翻译。
本地化 SVG 图像
Kubernetes 项目建议尽可能使用矢量 (SVG) 图像，因为这些图像更容易由本地化团队编辑。 如果您发现需要本地化的栅格图像，请首先考虑将英语版本重新绘制为矢量图像，然后本地化该图像。
在翻译 SVG（可缩放矢量图形）图像中的文本时，遵循某些准则至关重要，以确保准确性和跨不同语言版本的一致性。 SVG 图像通常用于 Kubernetes 文档中，以说明概念、工作流程和图表。
识别可翻译的文本：首先识别 SVG 图像中需要翻译的文本元素。 这些元素通常包括标签、标题、注释或任何传达信息的文本。
编辑 SVG 文件：SVG 文件是基于 XML 的，这意味着可以使用文本编辑器进行编辑。 但是，重要的是要注意，Kubernetes 文档中的大多数图像已经将文本转换为曲线，以避免字体兼容性问题。 在这种情况下，建议使用专门的 SVG 编辑软件，例如 Inkscape，打开 SVG 文件并找到需要翻译的文本元素。
翻译文本：用所需的语言替换原始文本。 确保翻译后的文本准确地传达了预期的含义，并适合图像中的可用空间。 在使用拉丁字母的语言时，应使用 Open Sans 字体系列。 您可以从这里下载 Open Sans 字体：Open Sans 字体。
将文本转换为曲线：如前所述，为了解决字体兼容性问题，建议将翻译后的文本转换为曲线或路径。 将文本转换为曲线可确保最终图像正确显示翻译后的文本，即使用户的系统没有原始 SVG 中使用的确切字体。
审查和测试：在进行必要的翻译并转换文本为曲线后，保存并审查更新后的 SVG 图像，以确保文本正确显示和对齐。 检查 本地预览您的更改。
源文件
本地化必须基于本地化团队针对的目标版本中的英语文件。 每个本地化团队可以决定要针对哪个版本，如下文中的目标版本 所述。
查找目标版本的文件
导航到 Kubernetes 网站仓库 https://github.com/kubernetes/website。
从下表中选择目标版本的分支
| 目标版本 | 分支 |
|---|---|
| 最新版本 | main |
| 上一个版本 | release-1.34 |
| 下一个版本 | dev-1.36 |
main 分支包含当前版本 v1.35 的内容。 发布团队在下一个版本发布之前创建 release-1.35 分支：v1.36。
i18n 中的站点字符串
本地化必须包含 i18n/en/en.toml 的内容，并放入一个新的特定于语言的文件中。 以德语为例：i18n/de.toml。
将一个新的本地化目录和文件添加到 i18n/。 例如，使用德语 (de)
mkdir -p i18n/de
cp i18n/en/en.toml i18n/de.toml
修改文件顶部的注释以适应您的本地化，然后翻译每个字符串的值。 例如，这是搜索表单的德语占位符文本
[ui_search]
other = "Suchen"
本地化站点字符串可让您自定义整个站点的文本和功能：例如，每个页面页脚中的法律版权文本。
特定于语言的本地化指南
作为本地化团队，您可以创建特定于语言的本地化指南，以正式化您的团队遵循的最佳实践。
例如，请参阅 韩语本地化指南，其中包含以下主题的内容
- 冲刺节奏和发布版本
- 分支策略
- Pull request 工作流程
- 风格指南
- 本地化和非本地化术语词汇表
- Markdown 约定
- Kubernetes API 对象术语
特定于语言的 Zoom 会议
如果本地化项目需要单独的会议时间，请联系 SIG Docs 联合主席或技术负责人，以创建一个新的定期 Zoom 会议和日历邀请。 仅当团队足够大以维持和需要单独会议时才需要这样做。
根据 CNCF 政策，本地化团队必须将他们的会议上传到 SIG Docs YouTube 播放列表。 SIG Docs 联合主席或技术负责人可以帮助完成此过程，直到 SIG Docs 实现自动化为止。
分支策略
由于本地化项目是高度协作的努力，我们鼓励团队在共享本地化分支中工作 - 尤其是在开始时并且本地化尚未生效时。
要协作本地化分支
来自 @kubernetes/website-maintainers 的团队成员在 https://github.com/kubernetes/website 上从源分支打开一个本地化分支。
您的团队批准者在您将本地化团队添加到
kubernetes/org仓库时加入了@kubernetes/website-maintainers团队。我们建议以下分支命名方案
dev-<源版本>-<语言代码>.<团队里程碑>例如，德语本地化团队的批准者直接在
kubernetes/website仓库上，基于 Kubernetes v1.12 的源分支打开本地化分支dev-1.12-de.1。个人贡献者基于本地化分支打开功能分支。
例如，一位德语贡献者打开一个 pull request，将更改从
username:local-branch-name应用到kubernetes:dev-1.12-de.1。批准者审查并合并功能分支到本地化分支。
定期地，批准者通过打开和批准一个新的 pull request 将本地化分支与源分支合并。 在批准 pull request 之前，请务必压缩提交。
根据需要重复步骤 1-4，直到本地化完成。 例如，后续的德语本地化分支将是：dev-1.12-de.2、dev-1.12-de.3 等。
团队必须将本地化内容合并到与内容来源相同的分支中。 例如
- 从
main来源的本地化分支必须合并到main。 - 从
release-1.34来源的本地化分支必须合并到release-1.34。
说明
如果您的本地化分支是从main 分支创建的，但在新发布分支 release-1.35 创建之前未合并到 main，请将其合并到 main 和新的发布分支 release-1.35 中。要将您的本地化分支合并到新的发布分支 release-1.35，您需要将本地化分支的上游分支切换到 release-1.35。在每个团队里程碑的开始，比较前一个本地化分支和当前本地化分支之间的上游更改会很有帮助。有两个脚本可用于比较上游更改。
upstream_changes.py对于检查特定文件所做的更改非常有用。并且diff_l10n_branches.py对于为特定的本地化分支创建过时文件列表非常有用。
虽然只有审批者可以打开新的本地化分支并合并拉取请求，但任何人都可以为新的本地化分支打开拉取请求。不需要特殊权限。
有关从 fork 或直接从仓库进行操作的更多信息，请参阅 “fork 和 clone 仓库”。
上游贡献
SIG Docs 欢迎对英文源稿的上游贡献和更正。