本地化 Kubernetes 文档
本页面介绍如何本地化文档以适应不同的语言。
为现有本地化贡献内容
您可以帮助添加或改进现有本地化内容。在Kubernetes Slack中，您可以找到每个本地化的频道。还有一个通用的SIG Docs 本地化 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/<两位字母代码> 目录下。
建议更改
根据英文原文创建或更新您选择的本地化页面。有关更多详细信息，请参阅本地化内容。
如果您注意到上游（英文）文档存在技术不准确或其他问题，应先修复上游文档，然后通过更新您正在进行的本地化来重复进行等效的修复。
将一个拉取请求中的更改限制在单个本地化。审查更改多个本地化内容的拉取请求是存在问题的。
请遵循建议内容改进来提出对该本地化的更改。此过程与对上游（英文）内容提出更改类似。
开始新的本地化
如果您希望将 Kubernetes 文档本地化为一种新语言，您需要执行以下操作。
由于贡献者无法批准自己的拉取请求，因此您需要至少两名贡献者才能开始一项本地化工作。
所有本地化团队都必须自给自足。Kubernetes 网站很乐意托管您的工作，但翻译和保持现有本地化内容最新则取决于您。
您需要了解您语言的两位字母语言代码。查阅ISO 639-1 标准以查找您本地化的两位字母语言代码。例如，韩语的两字母代码是 ko。
如果您要开始本地化的语言在不同地区有显著差异，那么将 ISO-3166 国家代码的小写版本与两位字母语言代码结合使用可能更合适。例如，巴西葡萄牙语的本地化代码是 pt-br。
当您开始一项新的本地化时，必须本地化所有最低要求的内容，然后 Kubernetes 项目才能将您的更改发布到实时网站。
SIG Docs 可以帮助您在一个单独的分支上工作，以便您能够逐步实现此目标。
寻找社区
让 Kubernetes SIG Docs 知道您对创建本地化感兴趣！加入SIG Docs Slack 频道和SIG Docs 本地化 Slack 频道。其他本地化团队很乐意帮助您入门并回答您的问题。
另请考虑参加SIG Docs 本地化子组会议。SIG Docs 本地化子组的使命是与 SIG Docs 各本地化团队合作，共同定义和记录创建本地化贡献指南的流程。此外，SIG Docs 本地化子组还寻求机会跨本地化团队创建和共享通用工具，并识别 SIG Docs 领导团队的新需求。如果您对本次会议有任何疑问，请在SIG Docs 本地化 Slack 频道咨询。
您还可以在 kubernetes/community 仓库中为您的本地化创建一个 Slack 频道。有关添加 Slack 频道的示例，请参阅添加波斯语频道的 PR。
加入 Kubernetes GitHub 组织
当您打开一个本地化 PR 时，您可以成为 Kubernetes GitHub 组织的一员。团队中的每个人都需要在 kubernetes/org 仓库中创建自己的组织成员资格请求。
在 GitHub 中添加您的本地化团队
接下来，将您的 Kubernetes 本地化团队添加到sig-docs/teams.yaml。有关添加本地化团队的示例，请参阅添加西班牙语本地化团队的 PR。
@kubernetes/sig-docs-**-owners 的成员可以批准更改您的本地化目录（/content/**/）中内容的 PR。对于每个本地化，@kubernetes/sig-docs-**-reviews 团队会自动分配新 PR 的评审员。@kubernetes/website-maintainers 的成员可以创建新的本地化分支来协调翻译工作。@kubernetes/website-milestone-maintainers 的成员可以使用Prow 命令 /milestone 为问题或 PR 分配里程碑。
配置工作流
接下来，在 kubernetes/test-infra 仓库中为您的本地化添加一个 GitHub 标签。标签可让您按语言过滤问题和拉取请求。
有关添加标签的示例，请参阅添加意大利语标签的 PR。
修改站点配置
Kubernetes 网站使用 Hugo 作为其 Web 框架。网站的 Hugo 配置位于hugo.toml 文件中。您需要修改 hugo.toml 来支持新的本地化。
在现有的 [languages] 块下，为 hugo.toml 中的新语言添加一个配置块。例如，德语块如下所示：
[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团队。 - labels：要自动应用于 PR 的 GitHub 标签列表，在本例中是配置工作流中创建的语言标签。
有关 OWNERS 文件的更多信息，请参阅go.k8s.io/owners。
带有语言代码 es 的西班牙语 OWNERS 文件如下所示：
# 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
打开拉取请求
接下来，打开一个拉取请求 (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 文档是一项巨大的任务。从小处着手，随着时间的推移逐步扩展是可以的。
最低要求内容
最低限度，所有本地化必须包括：
| 描述 | URL |
|---|---|
| 主页 | 所有标题和副标题 URL |
| 设置 | 所有标题和副标题 URL |
| 教程 | Kubernetes 基础知识, Hello Minikube |
| 站点字符串 | 新本地化 TOML 文件中的所有站点字符串 |
| 发布 | 所有标题和副标题 URL |
翻译的文档必须位于其自己的 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.33 |
| 下一个版本 | dev-1.35 |
main 分支包含当前版本 v1.34 的内容。发布团队在下一个版本 v1.35 之前创建一个 release-1.34 分支。
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"
本地化站点字符串允许您自定义网站范围内的文本和功能：例如，每页页脚的法律版权文本。
特定语言的本地化指南
作为本地化团队，您可以创建特定语言的本地化指南来正式化您的团队遵循的最佳实践。
例如，请参阅韩语本地化指南，其中包含以下主题的内容：
- 冲刺周期和发布
- 分支策略
- 拉取请求工作流
- 样式指南
- 本地化和非本地化术语词汇表
- Markdown 约定
- Kubernetes API 对象术语
特定语言的 Zoom 会议
如果本地化项目需要单独的会议时间，请联系 SIG Docs 的联合主席或技术负责人，以创建一个新的定期 Zoom 会议和日历邀请。仅当团队规模足够大，能够维持并需要单独会议时才需要这样做。
根据 CNCF 的政策，本地化团队必须将他们的会议上传到 SIG Docs YouTube 播放列表。SIG Docs 的联合主席或技术负责人可以在自动化之前协助此过程。
分支策略
由于本地化项目是高度协作的努力，我们鼓励团队使用共享的本地化分支工作——尤其是在开始阶段且本地化尚未上线时。
要协作本地化分支
来自@kubernetes/website-maintainers 的团队成员从 https://github.com/kubernetes/website 上的源分支打开一个本地化分支。
您的团队批准者在您将添加您的本地化团队到
kubernetes/org仓库时，已加入@kubernetes/website-maintainers团队。我们推荐以下分支命名方案：
dev-<源版本>-<语言代码>.<团队里程碑>例如，德语本地化团队的一名批准者直接针对
kubernetes/website仓库打开本地化分支dev-1.12-de.1，该分支基于 Kubernetes v1.12 的源分支。个人贡献者基于本地化分支打开功能分支。
例如，一名德语贡献者从
username:local-branch-name打开一个包含对kubernetes:dev-1.12-de.1更改的拉取请求。批准者审查并合并功能分支到本地化分支。
定期，一名批准者会通过打开和批准一个新的拉取请求，将本地化分支与其源分支合并。请确保在批准拉取请求之前压缩提交。
根据需要重复步骤 1-4，直到本地化完成。例如，后续的德语本地化分支将是：dev-1.12-de.2、dev-1.12-de.3 等。
团队必须将本地化内容合并到从中获取内容的同一分支。例如：
- 从
main分支创建的本地化分支必须合并到main。 - 从
release-1.33分支创建的本地化分支必须合并到release-1.33。
注意
如果您的本地化分支是从main 分支创建的，但未在创建新发布分支 release-1.34 之前合并到 main，则将其合并到 main 和新发布分支 release-1.34。要将本地化分支合并到新的发布分支 release-1.34，您需要将本地化分支的上游分支切换到 release-1.34。在每个团队里程碑开始时，最好打开一个问题，比较上一个本地化分支和当前本地化分支之间的上游更改。有两个脚本可用于比较上游更改。
upstream_changes.py有助于检查对特定文件的更改。而diff_l10n_branches.py有助于为特定的本地化分支创建过时文件列表。
虽然只有批准者可以打开新的本地化分支和合并拉取请求，但任何人都可以为新的本地化分支打开拉取请求。不需要特殊权限。
有关从 fork 工作或直接从仓库工作的更多信息，请参阅“Fork 并克隆仓库”。
上游贡献
SIG Docs 欢迎对英文源进行上游贡献和更正。