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/<localization>.toml到data/i18n/<localization>/<localization>.toml中的实际字符串配置的符号链接（请记住提交符号链接）。

例如，对于德语，字符串位于data/i18n/de/de.toml中，而i18n/de.toml是到data/i18n/de/de.toml的符号链接。

本地化社区行为准则

针对cncf/foundation存储库打开 PR，以添加您的语言的行为准则。

设置 OWNERS 文件

要设置每个为本地化做出贡献的用户的角色，请在特定于语言的子目录中创建一个OWNERS文件，其中包含

reviewers：具有评审者角色的 kubernetes 团队列表，在本例中，
sig-docs-**-reviews 团队在在 GitHub 中添加本地化团队中创建。
approvers：具有批准者角色的 Kubernetes 团队列表，在本例中是
sig-docs-**-owners 团队在在 GitHub 中添加本地化团队中创建。
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:
- 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
教程	Kubernetes 基础，Hello Minikube
站点字符串	在新的本地化 TOML 文件中所有站点字符串
版本	所有标题和副标题 URL

翻译后的文档必须位于其自己的 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（可缩放矢量图形）图像中的文本时，必须遵循某些准则，以确保不同语言版本的准确性和一致性。 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.31`
下一个版本	`dev-1.33`

main 分支包含当前版本 v1.32 的内容。发布团队在下一个版本 v1.33 之前创建一个 release-1.32 分支。

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-<source version>-<language code>.<team milestone>
例如，一个德语本地化团队的批准者直接针对 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.31 的本地化分支必须合并到 release-1.31 中。

注意

如果你的本地化分支是从 main 分支创建的，但在新的发布分支 release-1.32 创建之前没有合并到 main 分支，请将其合并到 main 和新的发布分支 release-1.32。要将你的本地化分支合并到新的发布分支 release-1.32，你需要将你的本地化分支的上游分支切换到 release-1.32。

在每个团队里程碑的开始，比较上一个本地化分支和当前本地化分支之间的上游更改会很有帮助。这里有两个脚本用于比较上游更改。

upstream_changes.py 用于检查对特定文件所做的更改。而
diff_l10n_branches.py 用于为特定的本地化分支创建过时文件列表。

虽然只有审批者才能创建新的本地化分支和合并拉取请求，但任何人都可以为新的本地化分支打开拉取请求。不需要特殊权限。

有关从 fork 工作或直接从仓库工作的更多信息，请参阅“fork 和克隆仓库”。

上游贡献

SIG Docs 欢迎对英文源进行上游贡献和更正。

上次修改时间：2024年4月17日下午4:48（太平洋标准时间）：更新 content/en/docs/contribute/localization.md (18f0cce616)