本地化 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 的成员可以批准更改您本地化目录（且仅限于该目录）内内容的 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 以支持新的本地化版本。
在现有 [languages] 块下的 hugo.toml 中为新语言添加一个配置块。例如，德语块如下所示
[languages.de]
title = "Kubernetes"
description = "Produktionsreife Container-Verwaltung"
languageName = "Deutsch (German)"
languageNameLatinScript = "Deutsch"
contentDir = "content/de"
weight = 8
语言选择栏列出了 languageName 的值。将“以本地脚本和语言表示的语言名称（以拉丁文脚本表示的英语语言名称）”分配给 languageName。例如，languageName = "한국어 (Korean)" 或 languageName = "Deutsch (German)"。
languageNameLatinScript 可用于访问拉丁文脚本的语言名称，并在主题中使用它。将“以拉丁文脚本表示的语言名称”分配给 languageNameLatinScript。例如，languageNameLatinScript ="Korean" 或 languageNameLatinScript = "Deutsch"。
weight 参数确定语言选择栏中语言的顺序。权重越低，优先级越高，导致该语言首先出现。分配 weight 参数时，重要的是检查现有的语言块并调整其权重，以确保它们相对于所有语言（包括任何新添加的语言）按排序顺序排列。
有关 Hugo 多语言支持的更多信息，请参阅“多语言模式”。
添加新的本地化目录
将特定于语言的子目录添加到仓库中的 content 文件夹。例如，德语的两位字母代码是 de
mkdir content/de
您还需要在 data/i18n 中创建一个目录，用于存放 本地化字符串；查看现有本地化版本以获取示例。要使用这些新字符串，您还必须创建一个从 i18n/<本地化版本>.toml 到 data/i18n/<本地化版本>/<本地化版本>.toml 中实际字符串配置的符号链接（请记住提交符号链接）。
例如，对于德语，字符串位于 data/i18n/de/de.toml 中，而 i18n/de.toml 是指向 data/i18n/de/de.toml 的符号链接。
本地化社区行为准则
针对 cncf/foundation 仓库打开一个 PR，以添加您语言的行为准则。
设置 OWNERS 文件
要设置每个贡献本地化用户的角色，请在特定于语言的子目录中创建一个 OWNERS 文件，其中包含
- 审查者：具有审查者角色的 kubernetes 团队列表，在本例中为
- 在 GitHub 中添加您的本地化团队 中创建的
sig-docs-**-reviews团队。 - 批准者：具有批准者角色的 Kubernetes 团队列表，在本例中为：
- 在 GitHub 中添加您的本地化团队 中创建的
sig-docs-**-owners团队。 - 标签：要自动应用于 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:
- 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 文档是一项艰巨的任务。可以先从小处着手，然后随着时间的推移逐步扩展。
最低要求内容
所有本地化至少必须包含
| 描述 | 网址 |
|---|---|
| 首页 | 所有标题和副标题的网址 |
| 设置 | 所有标题和副标题的网址 |
| 教程 | Kubernetes 基础知识，Hello Minikube |
| 网站字符串 | 新本地化 TOML 文件中的 所有网站字符串 |
| 版本 | 所有标题和副标题的网址 |
翻译后的文档必须位于其自己的 content/**/ 子目录中，但在其他方面，请遵循与英语源相同的 URL 路径。例如，要准备将 Kubernetes 基础知识 教程翻译成德语，请在 content/de/ 目录下创建一个子目录，并复制英语源或目录
mkdir -p content/de/docs/tutorials
cp -ra content/en/docs/tutorials/kubernetes-basics/ content/de/docs/tutorials/
翻译工具可以加快翻译速度。例如，一些编辑器提供插件来快速翻译文本。
注意
机器翻译本身是不够的。本地化需要大量的人工审查才能达到最低质量标准。为了确保语法和意义的准确性，您的本地化团队的成员应在发布之前仔细审查所有机器翻译。
本地化 SVG 图像
Kubernetes 项目建议尽可能使用矢量 (SVG) 图像，因为这些图像更容易由本地化团队编辑。如果您发现需要本地化的栅格图像，请首先考虑将英文版本重新绘制为矢量图像，然后对其进行本地化。
翻译 SVG（可缩放矢量图形）图像中的文本时，必须遵循某些准则，以确保准确性并在不同语言版本之间保持一致性。Kubernetes 文档中通常使用 SVG 图像来说明概念、工作流程和图表。
识别可翻译文本：首先识别 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.29 |
| 下一个版本 | dev-1.31 |
main 分支包含当前版本 v1.30 的内容。发布团队在下一个版本 v1.31 之前创建 release-1.30 分支。
i18n 中的网站字符串
本地化必须在新语言特定文件中包含 data/i18n/en/en.toml 的内容。以德语为例：data/i18n/de/de.toml。
将新的本地化目录和文件添加到 data/i18n/。例如，使用德语 (de)
mkdir -p data/i18n/de
cp data/i18n/en/en.toml data/i18n/de/de.toml
修改文件顶部的注释以适合您的本地化，然后翻译每个字符串的值。例如，这是搜索表单的德语占位符文本
[ui_search_placeholder]
other = "Suchen"
本地化网站字符串允许您自定义网站范围的文本和功能：例如，每页页脚中的法律版权文本。
特定于语言的本地化指南
作为本地化团队，您可以通过创建特定于语言的本地化指南来规范团队遵循的最佳实践。
例如，请参阅 韩语本地化指南，其中包含以下主题的内容
- 冲刺节奏和发布
- 分支策略
- 拉取请求工作流程
- 风格指南
- 本地化和非本地化术语词汇表
- 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 v1.12 的源分支直接针对
kubernetes/website存储库打开本地化分支dev-1.12-de.1。个人贡献者根据本地化分支打开功能分支。
例如，德语贡献者从
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.29获取的本地化分支必须合并到release-1.29中。
注意
如果您的本地化分支是从main 分支创建的，但在创建新的发布分支 release-1.30 之前没有合并到 main 分支，请将其合并到 main 分支和新的发布分支 release-1.30。要将您的本地化分支合并到新的发布分支 release-1.30，您需要将本地化分支的上游分支切换到 release-1.30。在每个团队里程碑开始时，最好创建一个问题，比较上一个本地化分支和当前本地化分支之间的上游更改。有两个脚本可以用来比较上游更改。
upstream_changes.py对于检查对特定文件的更改很有用。而diff_l10n_branches.py对于创建特定本地化分支的过时文件列表很有用。
虽然只有审批者可以打开新的本地化分支和合并拉取请求，但任何人都可以为新的本地化分支打开拉取请求。不需要特殊权限。
有关从分支或直接从存储库进行工作的更多信息，请参阅“分支和克隆存储库”。
上游贡献
SIG Docs 欢迎对英文源代码进行上游贡献和更正。