本地化 Kubernetes 文档

    你可以帮助添加或改进现有本地化的内容。在 Kubernetes Slack 中， 你能找到每个本地化的频道。还有一个通用的 ， 你可以在这里打个招呼。

    说明：

    如果你想处理已经存在的本地化，请在该本地化（如果存在）中检查此页面，而不是英文原版。 你可能会在那里看到额外的详细信息。

    首先，有关本地化的两个字母的语言代码，请参考 ISO 639-1 标准。 例如，韩国的两个字母代码是 。

    派生（fork）并且克隆仓库

    首先，为 kubernetes/website 仓库 。

    然后，克隆你的 website 仓库副本并通过 cd 命令进入 website 目录：

    网站内容目录包括每种语言的子目录。你想要助力的本地化位于 content/<two-letter-code> 中。

    建议更改

    根据英文原件创建或更新你选择的本地化页面。 有关更多详细信息，请参阅。

    如果你发现上游（英文）文档存在技术错误或其他问题， 你应该先修复上游文档，然后通过更新你正在处理的本地化来重复等效的修复。

    请将拉取请求限制为单个本地化，因为在多个本地化中更改内容的拉取请求可能难以审查。

    按照内容改进建议提出对该本地化的更改。 该过程与提议更改上游（英文）内容非常相似。

    如果你希望将 Kubernetes 文档本地化为一种新语言，你需要执行以下操作。

    因为贡献者不能批准他们自己的拉取请求，你需要 至少两个贡献者 来开始本地化。

    所有本地化团队都必须能够自我维持。 Kubernetes 网站很乐意托管你的作品，但要由你来翻译它并使现有的本地化内容保持最新。

    你需要知道你的语言的两个字母的语言代码。 请查阅 以查找你的本地化的两字母语言代码。例如，韩语的两字母代码是ko。

    当你开始新的本地化时，你必须先本地化所有最少要求的内容， Kubernetes 项目才能将你的更改发布到当前网站。

    SIG Docs 可以帮助你在单独的分支上工作，以便你可以逐步实现该目标。

    找到社区

    让 Kubernetes SIG Docs 知道你有兴趣创建本地化！ 加入 SIG Docs Slack 频道 和 。 其他本地化团队很乐意帮助你入门并回答你的任何问题。

    也请考虑参加 SIG Docs 本地化小组的会议。 SIG Docs 本地化小组的任务是与 SIG Docs 本地化团队合作， 共同定义和记录创建本地化贡献指南的流程。 此外，SIG Docs 本地化小组将寻找机会在本地化团队中创建和共享通用工具， 并为 SIG Docs 领导团队确定新要求。如果你对本次会议有任何疑问， 请在 中提问。

    你还可以在 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，并仅限这类 PR。

    对于每个本地化，@kubernetes/sig-docs-**-reviews 团队被自动分派新 PR 的审阅任务。

    @kubernetes/website-maintainers 成员可以创建新的本地化分支来协调翻译工作。

    @kubernetes/website-milestone-maintainers 成员可以使用 /milestone Prow 命令为 issues 或 PR 设定里程碑。

    配置工作流程

    接下来，在 kubernetes/test-infra 仓库中为你的本地化添加一个 GitHub 标签。 标签可让你过滤 issues 和针对特定语言的 PR。

    有关添加标签的示例，请参见添加意大利语标签的 PR。

    Kubernetes 网站使用 Hugo 作为其 Web 框架。网站的 Hugo 配置位于 文件中。 为了支持新的本地化，你需要修改 config.toml。

    在现有的 [languages] 下，将新语言的配置添加到 config.toml 中。 例如，下面是德语的配置示例：

    1. [languages.de]
    2. title = "Kubernetes"
    3. description = "Produktionsreife Container-Verwaltung"
    4. languageName = "Deutsch (German)"
    5. languageNameLatinScript = "German"
    6. contentDir = "content/de"
    7. weight = 8

    languageName 的值将列在语言选择栏中。 将 languageName 赋值为“本地脚本中的语言名称（拉丁脚本中的语言名称）”。 例如，languageName = "한국어 (Korean)"。 languageNameLatinScript 可用于访问拉丁脚本中的语言名称并在主题中使用。 将 languageNameLatinScript 赋值为“拉丁脚本中的语言名称”。 例如，languageNameLatinScript ="Korean"。

    为你的语言块分配一个 weight 参数时，找到权重最高的语言块并将其加 1。

    有关 Hugo 多语言支持的更多信息，请参阅”多语言模式“。

    添加一个新的本地化目录

    将特定语言的子目录添加到仓库中的 content 文件夹下。 例如，德语的两个字母的代码是 ：

    你还需要在 data/i18n 中为 创建一个目录； 以现有的本地化为例。要使用这些新字符串， 你还必须创建从 i18n/<localization>.toml 到 data/i18n/<localization>/<localization>.toml 中实际字符串配置的符号链接（记得提交符号链接关联）。

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

    本地化社区行为准则

    在 仓库提交 PR，添加你所用语言版本的行为准则。

    -->

    设置 OWNERS 文件

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

    • reviewers: 具有评审人角色的 kubernetes 团队的列表，在本例中为在 中创建的 sig-docs-**-reviews 团队。
    • approvers: 具有批准人角色的 kubernetes 团队的列表，在本例中为在 在 GitHub 中添加你的本地化团队 中创建的 sig-docs-**-owners 团队。
    • labels: 可以自动应用于 PR 的 GitHub 标签列表，在本例中为 中创建的语言标签。

    有关 OWNERS 文件的更多信息，请访问go.k8s.io/owners。

    语言代码为 es 的看起来像：

    1. # See the OWNERS docs at https://go.k8s.io/owners
    3. # This is the localization project for Spanish.
    4. # Teams and members are visible at https://github.com/orgs/kubernetes/teams.
    6. reviewers:
    7. - sig-docs-es-reviews
    8. approvers:
    9. - sig-docs-es-owners
    11. labels:
    12. - language/es

    添加了特定语言的 OWNERS 文件之后，使用新的 Kubernetes 本地化团队、 sig-docs-**-owners 和 sig-docs-**-reviews 列表更新 根目录下的 OWNERS_ALIAES 文件。

    对于每个团队，请按字母顺序添加 中所请求的 GitHub 用户列表。

    打开拉取请求

    接下来，（PR） 将本地化添加到 kubernetes/website 存储库。

    PR 必须包含所有最低要求内容才能获得批准。

    有关添加新本地化的示例， 请参阅 PR 以启用。

    添加本地化的 README 文件

    为了指导其他本地化贡献者，请在 的根目录添加一个新的 README-**.md， 其中 ** 是两个字母的语言代码。例如，德语 README 文件为 README-de.md。

    在本地化的 README-**.md 文件中为本地化贡献者提供指导。包含 中包含的相同信息，以及：

    • 本地化项目的联系人
    • 任何特定于本地化的信息

    创建本地化的 README 文件后，请在英语版文件 README.md 中添加指向该文件的链接， 并给出英文形式的联系信息。你可以提供 GitHub ID、电子邮件地址、 或其他联系方式。你还必须提供指向本地化的社区行为准则的链接。

    启动你的新本地化

    一旦本地化满足工作流程和最小输出的要求，SIG Docs 将：

    • 在网站上启用语言选择
    • 通过（CNCF）渠道， 包括 Kubernetes 博客，来宣传本地化的可用性。

    本地化所有 Kubernetes 文档是一项艰巨的任务。从小做起，循序渐进。

    所有本地化至少必须包括：

    翻译后的文档必须保存在自己的 content/**/ 子目录中，否则将遵循与英文源相同的 URL 路径。 例如，要准备将 教程翻译为德语， 请在 content/de/ 文件夹下创建一个子文件夹并复制英文源：

    1. mkdir -p content/de/docs/tutorials
    2. cp content/en/docs/tutorials/kubernetes-basics.md content/de/docs/tutorials/kubernetes-basics.md

    翻译工具可以加快翻译过程。例如，某些编辑器提供了用于快速翻译文本的插件。

    注意： 机器生成的翻译本身是不够的，本地化需要广泛的人工审核才能满足最低质量标准。

    为了确保语法和含义的准确性，本地化团队的成员应在发布之前仔细检查所有由机器生成的翻译。

    源文件

    要查找你的目标版本的源文件：

    1. 导航到 Kubernetes website 仓库，网址为 。

    2. 从下面的表格中选择你的目标版本分支：

      目标版本分支
      最新版本main
      上一个版本
      下一个版本dev-1.25

    main 分支中保存的是当前发行版本 v1.24 的内容。 发行团队会在下一个发行版本 v1.25 出现之前创建 release-1.24 分支。

    i18n/ 中的网站字符串

    本地化必须在新的语言特定文件中包含 data/i18n/en/en.toml 的内容。以德语为例：data/i18n/de/de.toml。

    将新的本地化文件和目录添加到 data/i18n/。例如德语 (de)：

    修改文件顶部的注释以适合你的本地化， 然后翻译每个字符串的值。例如，这是搜索表单的德语占位符文本：

    1. [ui_search_placeholder]
    2. other = "Suchen"

    本地化网站字符串允许你自定义网站范围的文本和特性：例如，每个页面页脚中的合法版权文本。

    特定语言的样式指南和词汇表

    一些语言团队有自己的特定语言样式指南和词汇表。 例如，请参见中文本地化指南。

    特定语言的 Zoom 会议

    如果本地化项目需要单独的会议时间， 请联系 SIG Docs 联合主席或技术主管以创建新的重复 Zoom 会议和日历邀请。 仅当团队维持在足够大的规模并需要单独的会议时才需要这样做。

    根据 CNCF 政策，本地化团队必须将他们的会议上传到 SIG Docs YouTube 播放列表。 SIG Docs 联合主席或技术主管可以帮助完成该过程，直到 SIG Docs 实现自动化。

    分支策略

    因为本地化项目是高度协同的工作，所以我们鼓励团队基于共享的本地化分支工作。

    • 特别是在开始并且本地化尚未生效时。

    在本地化分支上协作需要：

    1. 中的团队成员从 https://github.com/kubernetes/website 原有分支新建一个本地化分支。 当你给 kubernetes/org 仓库时， 你的团队批准人便加入了 @kubernetes/website-maintainers 团队。

      我们推荐以下分支命名方案：

      dev-<source version>-<language code>.<team milestone>

      例如，一个德语本地化团队的批准人基于 Kubernetes v1.12 版本的源分支， 直接新建了 k/website 仓库的本地化分支 dev-1.12-de.1。

    2. 个人贡献者基于本地化分支创建新的特性分支

      例如，一个德语贡献者新建了一个拉取请求，并将 username:local-branch-name 更改为 kubernetes:dev-1.12-de.1。

    3. 批准人审查功能分支并将其合并到本地化分支中。

    4. 批准人会定期发起并批准新的 PR，将本地化分支合并到其源分支。 在批准 PR 之前，请确保先 squash commits。

    根据需要重复步骤 1-4，直到完成本地化工作。例如，随后的德语本地化分支将是： dev-1.12-de.2、dev-1.12-de.3，等等。

    团队必须将本地化内容合入到发布分支中，该发布分支是内容的来源。

    例如：

    • 源于 release-{{ skew "prevMinorVersion" }} 的本地化分支必须被合并到 release-{{ skew "prevMinorVersion" }}。

    如果你的本地化分支是基于 main 分支创建的，但最终没有在新的发行 分支 release-1.24 被创建之前合并到 main 中，需要将其 同时将其合并到 main 和新的发行分支 release-1.24 中。 要将本地化分支合并到新的发行分支 中，你需要 将你本地化分支的上游分支切换到 release-1.24。

    在团队每个里程碑的开始时段，创建一个 issue 来比较先前的本地化分支 和当前的本地化分支之间的上游变化很有帮助。 现在有两个脚本用来比较上游的变化。 upstream_changes.py 对于检查对某个文件的变更很有用。 可以用来为某个特定本地化分支创建过时文件的列表。

    虽然只有批准人才能创建新的本地化分支并合并 PR，任何人都可以 为新的本地化分支提交一个拉取请求（PR）。不需要特殊权限。

    有关基于派生或直接从仓库开展工作的更多信息，请参见 “派生和克隆”。

    上游贡献

    Sig Docs 欢迎对英文原文的上游贡献和修正。