本地化 Kubernetes 文档

    由于贡献者无法批准他们自己的请求，因此您至少需要两个贡献者才能开始本地化。

    所有本地化团队必须使用自身的资源持续工作。我们很高兴托管你的产出，但无法为你翻译。

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

    派生（fork）并且克隆仓库

    首先，为 kubernetes/website 仓库 。

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

    发起拉取请求（PR）

    接下来，， 将本地化添加到 kubernetes/website 仓库。

    该 PR 必须包含所有最低要求的内容，然后才能被批准。

    有关添加新本地化的示例，请参见添加 的 PR。

    加入到 Kubernetes GitHub 组织

    提交本地化 PR 后，你可以成为 Kubernetes GitHub 组织的成员。 团队中的每个人都需要在 kubernetes/org 仓库中创建自己的 。

    在 GitHub 中添加你的本地化团队

    接下来，将你的 Kubernetes 本地化团队添加到 。 有关添加本地化团队的示例，请参见添加西班牙本地化团队 的 PR。

    @kubernetes/sig-docs-**-owners 成员可以批准更改对应本地化目录 /content/**/ 中内容的 PR，并仅限这类 PR。

    @kubernetes/sig-docs-**-reviews 团队被自动分派新 PR 的审阅任务。

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

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

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

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

    寻找社区

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

    你还可以在 kubernetes/community 仓库中为你的本地化创建一个 Slack 频道。 有关添加 Slack 频道的示例，请参见的 PR。

    修改站点配置

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

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

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

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

    添加一个新的本地化目录

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

    本地化社区行为准则

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

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

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

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

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

    设置 OWNERS 文件

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

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

    有关 OWNERS 文件的更多信息，请访问。

    语言代码为 es 的西班牙语 OWNERS 文件看起来像：

    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.
    5. reviewers:
    6. - sig-docs-es-reviews
    8. approvers:
    9. - sig-docs-es-owners
    11. labels:
    12. - language/es

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

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

    本地化所有 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

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

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

    源文件

    本地化必须基于最新版本 v1.21 中的英文文件。

    要查找最新版本的源文件：

    1. 导航到 Kubernetes website 仓库，网址为 。
    2. 选择最新版本的 release-1.X 分支。

    最新版本是 v1.21，所以最新的发行分支是 release-1.21。

    i18n/ 中的网站字符串

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

    然后翻译每个字符串的值：

    1. [docs_label_i_am]
    2. other = "ICH BIN..."

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

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

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

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

    在开发分支上协作需要：

    1. @kubernetes/website-maintainers 中的团队成员从 原有分支新建一个开发分支。 当你给 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、，等等。

    团队必须将本地化内容合入到发布分支中，该发布分支也正是内容的来源。 例如，源于 release-1.21 的开发分支必须基于 release-1.21。

    approver 必须通过使开发分支与源分支保持最新并解决合并冲突来维护开发分支。 开发分支的存在时间越长，通常需要的维护工作就越多。 考虑定期合并开发分支并新建分支，而不是维护一个持续时间很长的开发分支。

    在团队每个里程碑的起点，创建一个 issue 来比较先前的开发分支和当前的开发分支之间的上游变化很有帮助。 虽然只有批准人才能创建新的开发分支并合并 PR，但任何人都可以为新的开发分支提交一个拉取请求（PR）。 不需要特殊权限。

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

    上游贡献

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

    本地化满足工作流程和最低输出要求后，SIG 文档将：