Kubernetes 文档库有多种语言:
我们鼓励你添加新的本地化!
本地化必须满足工作流(*如何*本地化)和输出(本地化*内容*)的一些要求。
要添加 Kubernetes 文档库的新的本地化,你需要修改网站配置 和目录结构来更新网站。然后你就可以开始翻译文档了!
Note:本地化相关的拉取请求 示例,请参见向 Kubernetes 文档库 Kubernetes website 仓库 合入韩语本地化的这个拉取请求。
让 Kubernetes SIG Docs 知道你对创建本地化感兴趣!加入 SIG Docs Slack channel。我们很乐意帮助你快速上手并回答你的任何问题。
所有本地化团队必须使用自身的资源独立工作。我们很高兴支持你的工作,但无法为你翻译。
首先,在 kubernetes/website 中创建你自己的分支。
然后,克隆 website 仓库并通过 cd
命令进入 website 目录:
git clone https://github.com/kubernetes/website
cd website
Note:
k/website
的贡献者必须创建一个分支,从创建拉取请求。对于本地化,我们还要求:
- 团队审批者直接从 https://github.com/kubernetes/website 新建开发分支。
- 本地化贡献者创建分支进行工作,其分支基于当前的开发分支。
这是因为本地化项目是在长期进行的分支上的协同工作,类似于 Kubernetes 发布周期的开发分支。有关本地化拉取请求,请参见“分支策略”。
有关本地化的两个字母的国家代码,请参考 ISO 639-1 标准。例如,德语的两个字母代码是 de
。
Note:这些说明遵循 ISO 639-1 语言代码标准,以德语(
de
)为例。目前没有针对德语的 Kubernetes 本地化,但欢迎你创建一个!
Kubernetes 网站使用 Hugo 作为其 web 框架。网站的 Hugo 配置位于 config.toml
文件中。要支持新的本地化,你需要修改 config.toml
。
将新语言的配置块添加到 config.toml
中现有的 [languages]
块下。例如,德语块如下所示:
[languages.de]
title = "Kubernetes"
description = "Produktionsreife Container-Verwaltung"
languageName = "Deutsch"
contentDir = "content/de"
weight = 3
为块分配 weight
参数时,请查找权重最大的语言块,并对该值加 1。
有关 Hugo 多语言支持的更多信息,请参见 “多语言模式”。
将特定语言的子目录添加到仓库中的 content
目录中。例如,德语的两个字母代码是 de
:
mkdir content/de
要指导其他本地化贡献者,请将新的 README-**.md
添加到 k/website 的顶层,其中 **
是两个字母的语言代码。例如,德语的自述文件是 README-de.md
。
在本地化的 README-**.md
文件中为本地化贡献者提供指导。包括 README.md
中包含的相同信息以及:
创建本地化的自述文件后,请在主英文文件中添加指向该文件的链接,[README.md
’s Localizing Kubernetes Documentation],并以英文包含联系信息。你可以提供 GitHub ID、电子邮箱、Slack channel 或其他联系方式。
本地化所有 Kubernetes 文档是一项艰巨的任务。从小做起,循序渐进。
所有本地化至少必须包括:
描述 | 网址 |
---|---|
主页 | 所有标题和副标题网址 |
安装 | 所有标题和副标题网址 |
教程 | Kubernetes 基础, Hello Minikube |
网站字符串 | 新的本地化 TOML 文件中的所有网站字符串 |
翻译后的文档必须保存在自己的 content/**/
子目录中,否则将遵循与英文源相同的 URL 路径。例如,要准备将 Kubernetes 基础 教程翻译为德语,请在 content/de/
文件夹下创建一个子文件夹并复制英文源:
mkdir -p content/de/docs/tutorials
cp content/en/docs/tutorials/kubernetes-basics.md content/de/docs/tutorials/kubernetes-basics.md
本地化相关的拉取请求 示例,请参见向 Kubernetes 文档库 Kubernetes website 仓库 合入韩语本地化的这个拉取请求。
本地化必须使用最新版本的英文文件作为其源。最新版本是 **v1.17 **。
要查找最新版本的源文件,请执行以下操作:
release-1.X
分支作为最新版本。最新版本是 **v1.17
**,所以最新的发布分支是 release-1.17
。
本地化必须在新的语言特定文件中包含 i18n/en.toml
的内容。以德语为例:i18n/de.toml
。
将新的本地化文件添加到 i18n/
。例如德语 (de
):
cp i18n/en.toml i18n/de.toml
然后转换每个字符串的值:
[docs_label_i_am]
other = "ICH BIN..."
本地化网站字符串允许你自定义网站范围的文本和特性:例如,每个页面页脚中的合法版权文本。
开始新的本地化时,请联系 Kubernetes SIG Docs 中的主席之一。
每个本地化存储库必须提供自己的维护人员。维护人员可以来自单个组织或多个组织。只要可能,本地化的拉取请求应该由来自不同组织的评审者批准,而不是由翻译人员批准。
本地化必须至少提供两个维护人员。(不能评审和批准自己的工作。)
因为本地化项目是高度协同的工作,所以我们鼓励团队基于共享的开发分支工作。
在开发分支上协作:
我们推荐以下分支命名方案:
`dev-<source version>-<language code>.<team milestone>`
例如,一个德语本地化团队的审批者基于 Kubernetes v1.12 版本的源分支直接新建了 k/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
,等等。
团队必须将本地化内容合入到发布分支中,该发布分支也正是内容的来源。例如,源于 release-1.17 的开发分支必须基于 release-1.17 。
审批者必须通过使开发分支与源分支保持最新并解决合并冲突来维护开发分支。开发分支的存在时间越长,通常需要的维护工作就越多。考虑定期合并开发分支并新建分支,而不是维护一个运行非常长的开发分支。
虽然只有审批者可以合入拉取请求,但任何人都可以为新的开发分支新建拉取请求。不需要特殊权限。
有关基于克隆或直接从仓库开展工作的更多信息,请参见 “fork and clone the repo”。
Sig Docs 欢迎上游贡献和更正 到英文源。
一旦 l10n 满足工作流和最小输出的要求,SIG docs 将:
此页是否对您有帮助?
Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on Stack Overflow. Open an issue in the GitHub repo if you want to report a problem or suggest an improvement.