kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #29488 from howieyuen/contribution-2 

[zh]sync contribution files for 1.22(Part-2)
This commit is contained in:
Kubernetes Prow Robot 2021-09-04 00:49:19 -07:00 committed by GitHub
parent 1393a4abd7 742824d491
commit 67c7cc9924
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
6 changed files with 82 additions and 72 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

62
content/zh/docs/contribute/generate-ref-docs/contribute-upstream.md
View File

@ -159,12 +159,12 @@ will be different in your situation.
<!--
Here's an example of editing a comment in the Kubernetes source code.
In your local kubernetes/kubernetes repository, check out the master branch,
In your local kubernetes/kubernetes repository, check out the default branch,
and make sure it is up to date:
-->
以下在 Kubernetes 源代码中编辑注释的示例。
在您本地的 kubernetes/kubernetes 代码仓库中，检出 master 分支，并确保它是最新的：
在您本地的 kubernetes/kubernetes 代码仓库中，检出默认分支，并确保它是最新的：
```shell
cd <k8s-base>
@ -173,9 +173,9 @@ git pull https://github.com/kubernetes/kubernetes master
```
<!--
Suppose this source file in the master branch has the typo "atmost":
Suppose this source file in that default branch has the typo "atmost":
-->
假设 master 分支中的下面源文件中包含拼写错误 "atmost"：
假设默认分支中的下面源文件中包含拼写错误 "atmost"：
[kubernetes/kubernetes/staging/src/k8s.io/api/apps/v1/types.go](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/api/apps/v1/types.go)
@ -228,7 +228,6 @@ Go to `<k8s-base>` and run these scripts:
hack/update-generated-swagger-docs.sh
hack/update-openapi-spec.sh
hack/update-generated-protobuf.sh
hack/update-api-reference-docs.sh
```
<!-- Run `git status` to see what was generated. -->
@ -238,8 +237,6 @@ hack/update-api-reference-docs.sh
On branch master
...
modified: api/openapi-spec/swagger.json
modified: api/swagger-spec/apps_v1.json
modified: docs/api-reference/apps/v1/definitions.html
modified: staging/src/k8s.io/api/apps/v1/generated.proto
modified: staging/src/k8s.io/api/apps/v1/types.go
modified: staging/src/k8s.io/api/apps/v1/types_swagger_doc_generated.go
@ -310,24 +307,27 @@ In the preceding section, you edited a file in the master branch and then ran sc
to generate an OpenAPI spec and related files. Then you submitted your changes in a pull request
to the master branch of the kubernetes/kubernetes repository. Now suppose you want to backport
your change into a release branch. For example, suppose the master branch is being used to develop
Kubernetes version 1.10, and you want to backport your change into the release-1.9 branch.
Kubernetes version {{< skew latestVersion >}}, and you want to backport your change into the
release-{{< skew prevMinorVersion >}} branch.
-->
### 将你的提交 Cherrypick 到发布分支
在上一节中，你在 master 分支中编辑了一个文件，然后运行了脚本用来生成 OpenAPI 规范和相关文件。
然后用 PR 将你的更改提交到 kubernetes/kubernetes 代码仓库的 master 分支中。
现在，需要将你的更改反向移植到已经发布的分支。
例如，假设 master 分支被用来开发 Kubernetes 1.10 版，并且你想将更改反向移植到 release-1.9 分支。
例如，假设 master 分支被用来开发 Kubernetes {{< skew latestVersion >}} 版，
并且你想将更改反向移植到 release-{{< skew prevMinorVersion >}} 分支。
<!--
Recall that your pull request has two commits: one for editing `types.go`
and one for the files generated by scripts. The next step is to propose a cherry pick of your first
commit into the release-1.9 branch. The idea is to cherry pick the commit that edited `types.go`, but not
the commit that has the results of running the scripts. For instructions, see
commit into the release-{{< skew prevMinorVersion >}} branch. The idea is to cherry pick the commit
that edited `types.go`, but not the commit that has the results of running the scripts. For instructions, see
[Propose a Cherry Pick](https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md).
-->
回想一下，您的 PR 有两个提交：一个用于编辑 `types.go`，一个用于由脚本生成的文件。
下一步是将你的第一次提交 cherrypick 到 release-1.9 分支。这样做的原因是仅 cherrypick 编辑了 types.go 的提交，
下一步是将你的第一次提交 cherrypick 到 release-{{< skew prevMinorVersion >}} 分支。
这样做的原因是仅 cherrypick 编辑了 types.go 的提交，
而不是具有脚本运行结果的提交。
有关说明，请参见[提出 Cherry Pick](https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md)。
@ -337,16 +337,17 @@ pull request. If you don't have those permissions, you will need to work with so
and milestone for you.
-->
{{< note >}}
提出 Cherry Pick 要求你有权在 PR 中设置标签和里程碑。如果您没有这些权限，
提出 Cherry Pick 要求你有权在 PR 中设置标签和里程碑。如果你没有这些权限，
则需要与可以为你设置标签和里程碑的人员合作。
{{< /note >}}
<!--
When you have a pull request in place for cherry picking your one commit into the release-1.9 branch,
the next step is to run these scripts in the release-1.9 branch of your local environment.
When you have a pull request in place for cherry picking your one commit into the
release-{{< skew prevMinorVersion >}} branch, the next step is to run these scripts in the
release-{{< skew prevMinorVersion >}} branch of your local environment.
-->
当你发起 PR 将你的一个提交 cherry pick 到 release-1.9 分支中时，下一步是在本地环境的 release-1.9
分支中运行如下脚本。
当你发起 PR 将你的一个提交 cherry pick 到 release-{{< skew prevMinorVersion >}} 分支中时，
下一步是在本地环境的 release-{{< skew prevMinorVersion >}} 分支中运行如下脚本。
```shell
hack/update-generated-swagger-docs.sh
@ -357,24 +358,29 @@ hack/update-api-reference-docs.sh
<!--
Now add a commit to your cherry-pick pull request that has the recently generated OpenAPI spec
and related files. Monitor your pull request until it gets merged into the release-1.9 branch.
and related files. Monitor your pull request until it gets merged into the
release-{{< skew prevMinorVersion >}} branch.
-->
现在将提交添加到您的 Cherry-Pick PR 中，该 PR 中包含最新生成的 OpenAPI 规范和相关文件。
关注你的 PR，直到其合并到 release-1.9 分支中为止。
关注你的 PR，直到其合并到 release-{{< skew prevMinorVersion >}} 分支中为止。
<!--
At this point, both the master branch and the release-1.9 branch have your updated `types.go`
At this point, both the master branch and the release-{{< skew prevMinorVersion >}} branch have your updated `types.go`
file and a set of generated files that reflect the change you made to `types.go`. Note that the
generated OpenAPI spec and other generated files in the release-1.9 branch are not necessarily
the same as the generated files in the master branch. The generated files in the release-1.9 branch
contain API elements only from Kubernetes 1.9. The generated files in the master branch might contain
API elements that are not in 1.9, but are under development for 1.10.
generated OpenAPI spec and other generated files in the release-{{< skew prevMinorVersion >}} branch are not necessarily
the same as the generated files in the master branch. The generated files in the release-{{< skew prevMinorVersion >}} branch
contain API elements only from Kubernetes {{< skew prevMinorVersion >}}. The generated files in the master branch might contain
API elements that are not in {{< skew prevMinorVersion >}}, but are under development for {{< skew latestVersion >}}.
-->
此时，master 分支和 release-1.9 分支都具有更新的 `types.go` 文件和一组生成的文件，
此时，master 分支和 release-{{< skew prevMinorVersion >}}
分支都具有更新的 `types.go` 文件和一组生成的文件，
这些文件反映了对 `types.go` 所做的更改。
请注意，生成的 OpenAPI 规范和其他 release-1.9 分支中生成的文件不一定与 master 分支中生成的文件相同。
release-1.9 分支中生成的文件仅包含来自 Kubernetes 1.9 的 API 元素。
master 分支中生成的文件可能包含不在 1.9 中但正在为 1.10 开发的 API 元素。
请注意，生成的 OpenAPI 规范和其他 release-{{< skew prevMinorVersion >}}
分支中生成的文件不一定与 master 分支中生成的文件相同。
release-{{< skew prevMinorVersion >}} 分支中生成的文件仅包含来自
Kubernetes {{< skew prevMinorVersion >}} 的 API 元素。
master 分支中生成的文件可能包含不在 {{< skew prevMinorVersion >}}
中但正在为 {{< skew latestVersion >}} 开发的 API 元素。
<!--
## Generating the published reference docs

36
content/zh/docs/contribute/generate-ref-docs/kubectl.md
View File

@ -133,15 +133,15 @@ The remaining steps refer to your base directory as `<rdocs-base>`. -->
<!--
In your local k8s.io/kubernetes repository, check out the branch of interest,
and make sure it is up to date. For example, if you want to generate docs for
Kubernetes 1.17, you could use these commands:
Kubernetes {{< skew prevMinorVersion >}}.0, you could use these commands:
-->
在本地的 k8s.io/kubernetes 仓库中，检出感兴趣的分支并确保它是最新的。例如，
如果你想要生成 Kubernetes 1.17 的文档，可以使用以下命令：
如果你想要生成 Kubernetes {{< skew prevMinorVersion >}}.0 的文档，可以使用以下命令：
```shell
cd <k8s-base>
git checkout v1.17.0
git pull https://github.com/kubernetes/kubernetes v1.17.0
git checkout v{{< skew prevMinorVersion >}}.0
git pull https://github.com/kubernetes/kubernetes {{< skew prevMinorVersion >}}.0
```
<!--
@ -172,13 +172,13 @@ kubectl 源码中的一个或多个注释开始。在本地 kubernetes/kubernete
is an example of a pull request that fixes a typo in the kubectl source code.
Monitor your pull request, and respond to reviewer comments. Continue to monitor your
pull request until it is merged into the master branch of the kubernetes/kubernetes repository.
pull request until it is merged into the target branch of the kubernetes/kubernetes repository.
-->
[PR 56673](https://github.com/kubernetes/kubernetes/pull/56673/files) 是一个对 kubectl
源码中的笔误进行修复的 PR 示例。
跟踪你的 PR，并回应评审人的评论。继续跟踪你的 PR，直到它合入到 kubernetes/kubernetes 仓库的 master 分支中。
跟踪你的 PR，并回应评审人的评论。继续跟踪你的 PR，直到它合入到 kubernetes/kubernetes 仓库的目标分支中。
<!--
## Cherry picking your change into a release branch
@ -195,15 +195,17 @@ cherry picked into the release branch.
cherry-pick 方式合入已发布分支。
<!--
For example, suppose the master branch is being used to develop Kubernetes 1.10,
and you want to backport your change to the release-1.15 branch. For instructions
For example, suppose the master branch is being used to develop Kubernetes
{{< skew currentVersion >}}
and you want to backport your change to the release-{{< skew prevMinorVersion >}} branch. For instructions
on how to do this, see
[Propose a Cherry Pick](https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md).
Monitor your cherry-pick pull request until it is merged into the release branch.
-->
例如，假设 master 分支正用于开发 Kubernetes 1.16 版本，而你希望将修改合入到已发布的 1.15 版本分支。
例如，假设 master 分支正用于开发 Kubernetes {{< skew currentVersion >}} 版本，
而你希望将修改合入到 release-{{< skew prevMinorVersion >}} 版本分支。
相关的操作指南，请参见
[提议一个 cherry-pick](https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md)。
@ -233,21 +235,22 @@ Go to `<rdocs-base>`, and open the `Makefile` for editing:
* Set `K8S_ROOT` to `<k8s-base>`.
* Set `K8S_WEBROOT` to `<web-base>`.
* Set `K8S_RELEASE` to the version of the docs you want to build.
For example, if you want to build docs for Kubernetes 1.17, set `K8S_RELEASE` to 1.17.
For example, if you want to build docs for Kubernetes {{< skew prevMinorVersion >}}, set `K8S_RELEASE` to {{< skew prevMinorVersion >}}.
For example, update the following variables:
-->
* 设置 `K8S_ROOT` 为 `<k8s-base>`。
* 设置 `K8S_WEBROOT` 为 `<web-base>`。
* 设置 `K8S_RELEASE` 为要构建文档的版本。
例如，如果您想为 Kubernetes 1.17 构建文档，请将 `K8S_RELEASE` 设置为 1.17。
例如，如果您想为 Kubernetes {{< skew prevMinorVersion >}} 构建文档，
请将 `K8S_RELEASE` 设置为 {{< skew prevMinorVersion >}}。
例如：
```
export K8S_WEBROOT=$(GOPATH)/src/github.com/<your-username>/website
export K8S_ROOT=$(GOPATH)/src/k8s.io/kubernetes
export K8S_RELEASE=1.17
export K8S_RELEASE={{< skew prevMinorVersion >}}
```
<!--
@ -281,19 +284,20 @@ make createversiondirs
In your local <k8s-base> repository, checkout the branch that has
the version of Kubernetes that you want to document. For example, if you want
to generate docs for Kubernetes 1.15, checkout the release-1.15 branch. Make sure
to generate docs for Kubernetes {{< skew prevMinorVersion >}}.0, checkout the `v{{< skew prevMinorVersion >}}` tag. Make sure
you local branch is up to date.
-->
## 从 kubernetes/kubernetes 检出一个分支
在本地 `<k8s-base>` 仓库中，检出你想要生成文档的、包含 Kubernetes 版本的分支。
例如，如果希望为 Kubernetes 1.17 版本生成文档，请检出 `v1.17.0` 标记。
例如，如果希望为 Kubernetes {{< skew prevMinorVersion >}}.0 版本生成文档，
请检出 `v{{< skew prevMinorVersion >}}` 标记。
确保本地分支是最新的。
```shell
cd <k8s-base>
git checkout v1.17.0
git pull https://github.com/kubernetes/kubernetes v1.17.0
git checkout v{{< skew prevMinorVersion >}}.0
git pull https://github.com/kubernetes/kubernetes v{{< skew prevMinorVersion >}}.0
```
<!--

36
content/zh/docs/contribute/generate-ref-docs/quickstart.md
View File

@ -12,11 +12,11 @@ weight: 40
<!-- overview -->
<!--
This page shows how to use the `update-imported-docs` script to generate
This page shows how to use the `update-imported-docs.py` script to generate
the Kubernetes reference documentation. The script automates
the build setup and generates the reference documentation for a release.
-->
本页讨论如何使用 `update-imported-docs` 脚本来生成 Kubernetes 参考文档。
本页讨论如何使用 `update-imported-docs.py` 脚本来生成 Kubernetes 参考文档。
此脚本将构建的配置过程自动化，并为某个发行版本生成参考文档。
## {{% heading "prerequisites" %}}
@ -27,13 +27,13 @@ the build setup and generates the reference documentation for a release.
<!--
## Getting the docs repository
Make sure your `website` fork is up-to-date with the `kubernetes/website` master and clone
your `website` fork.
Make sure your `website` fork is up-to-date with the `kubernetes/website` remote on
GitHub (`main` branch), and clone your `website` fork.
-->
## 获取文档仓库 {#getting-the-docs-repository}
确保你的 `website` 派生仓库与 `kubernetes/website` 主分支一致，并克隆
你的派生仓库。
确保你的 `website` 派生仓库与 GitHub 上的 `kubernetes/website` 远程仓库（`main` 分支）保持同步，
并克隆你的派生仓库。
```shell
mkdir github.com
@ -63,7 +63,7 @@ see the [contributing upstream guide](/docs/contribute/generate-ref-docs/contrib
<!--
## Overview of update-imported-docs
The `update-imported-docs` script is located in the `<web-base>/update-imported-docs/`
The `update-imported-docs.py` script is located in the `<web-base>/update-imported-docs/`
directory.
The script builds the following references:
@ -74,7 +74,7 @@ The script builds the following references:
-->
## update-imported-docs 的概述
脚本 `update-imported-docs` 位于 `<web-base>/update-imported-docs/` 目录下，
脚本 `update-imported-docs.py` 位于 `<web-base>/update-imported-docs/` 目录下，
能够生成以下参考文档：
* Kubernetes 组件和工具的参考页面
@ -82,7 +82,7 @@ The script builds the following references:
* Kubernetes API 参考文档
<!--
The `update-imported-docs` script generates the Kubernetes reference documentation
The `update-imported-docs.py` script generates the Kubernetes reference documentation
from the Kubernetes source code. The script creates a temporary directory
under `/tmp` on your machine and clones the required repositories: `kubernetes/kubernetes` and
`kubernetes-sigs/reference-docs` into this directory.
@ -93,7 +93,7 @@ Three additional environment variables are set:
* `K8S_ROOT`
* `K8S_WEBROOT`
-->
脚本 `update-imported-docs` 基于 Kubernetes 源代码生成参考文档。
脚本 `update-imported-docs.py` 基于 Kubernetes 源代码生成参考文档。
过程中会在你的机器的 `/tmp` 目录下创建临时目录，克隆所需要的仓库
`kubernetes/kubernetes` 和 `kubernetes-sigs/reference-docs` 到此临时目录。
脚本会将 `GOPATH` 环境变量设置为指向此临时目录。
@ -124,7 +124,7 @@ determines the version of the release.
变量 `K8S_RELEASE` 用来确定所针对的发行版本。
<!--
The `update-imported-docs` script performs the following steps:
The `update-imported-docs.py` script performs the following steps:
1. Clones the related repositories specified in a configuration file. For the
purpose of generating reference docs, the repository that is cloned by
@ -136,7 +136,7 @@ The `update-imported-docs` script performs the following steps:
1. Updates `kubectl` command links from `kubectl`.md to the refer to
the sections in the `kubectl` command reference.
-->
脚本 `update-imported-docs` 执行以下步骤：
脚本 `update-imported-docs.py` 执行以下步骤：
1. 克隆配置文件中所指定的相关仓库。就生成参考文档这一目的而言，要克隆的
仓库默认为 `kubernetes-sigs/reference-docs`。
@ -260,22 +260,22 @@ For example:
<!--
## Running the update-imported-docs tool
You can run the `update-imported-docs` tool as follows:
You can run the `update-imported-docs.py` tool as follows:
-->
## 运行 update-imported-docs 工具
你可以用如下方式运行 `update-imported-docs` 工具：
你可以用如下方式运行 `update-imported-docs.py` 工具：
```shell
cd <web-base>/update-imported-docs
./update-imported-docs <configuration-file.yml> <release-version>
./update-imported-docs.py <configuration-file.yml> <release-version>
```
<!-- For example: -->
例如：
```shell
./update-imported-docs reference.yml 1.17
./update-imported-docs.py reference.yml 1.17
```
<!-- Revisit: is the release configuration used -->
@ -284,13 +284,13 @@ cd <web-base>/update-imported-docs
The `release.yml` configuration file contains instructions to fix relative links.
To fix relative links within your imported files, set the`gen-absolute-links`
property to `true`. You can find an example of this in
[`release.yml`](https://github.com/kubernetes/website/blob/master/update-imported-docs/release.yml).
[`release.yml`](https://github.com/kubernetes/website/blob/main/update-imported-docs/release.yml).
-->
## 修复链接
配置文件 `release.yml` 中包含用来修复相对链接的指令。
若要修复导入文件中的相对链接，将 `gen-absolute-links` 属性设置为 `true`。
你可以在 [`release.yml`](https://github.com/kubernetes/website/blob/master/update-imported-docs/release.yml)
你可以在 [`release.yml`](https://github.com/kubernetes/website/blob/main/update-imported-docs/release.yml)
文件中找到示例。
<!--

4
content/zh/docs/contribute/style/hugo-shortcodes/index.md
View File

@ -96,10 +96,10 @@ page content.
除了包含工具提示外，你还可以重用页面内容中词汇表中的定义。
<!--
The raw data for glossary terms is stored at [https://github.com/kubernetes/website/tree/master/content/en/docs/reference/glossary](https://github.com/kubernetes/website/tree/master/content/en/docs/reference/glossary), with a content file for each glossary term.
The raw data for glossary terms is stored at [https://github.com/kubernetes/website/tree/main/content/en/docs/reference/glossary](https://github.com/kubernetes/website/tree/main/content/en/docs/reference/glossary), with a content file for each glossary term.
-->
词汇术语的原始数据保存在 [https://github.com/kubernetes/website/tree/master/content/en/docs/reference/glossary](https://github.com/kubernetes/website/tree/master/content/en/docs/reference/glossary)，每个内容文件对应相应的术语解释。
词汇术语的原始数据保存在 [https://github.com/kubernetes/website/tree/main/content/en/docs/reference/glossary](https://github.com/kubernetes/website/tree/main/content/en/docs/reference/glossary)，每个内容文件对应相应的术语解释。
<!--
### Glossary demo

12
content/zh/docs/contribute/style/style-guide.md
View File

@ -54,7 +54,7 @@ Kubernetes 文档使用带调整的 [Goldmark Markdown 解释器](https://github
## Language
Kubernetes documentation has been translated into multiple languages
(see [Localization READMEs](https://github.com/kubernetes/website/blob/master/README.md#localization-readmemds)).
(see [Localization READMEs](https://github.com/kubernetes/website/blob/main/README.md#localization-readmemds)).
The way of localizing the docs for a different language is described in [Localizing Kubernetes Documentation](/docs/contribute/localization/).
@ -65,7 +65,7 @@ The English-language documentation uses U.S. English spelling and grammar.
## 语言 {#language}
Kubernetes 文档已经被翻译为多个语种
（参见 [本地化 READMEs](https://github.com/kubernetes/website/blob/master/README.md#localization-readmemds)）。
（参见 [本地化 READMEs](https://github.com/kubernetes/website/blob/main/README.md#localization-readmemds)）。
为文档提供一种新的语言翻译的途径可以在
[本地化 Kubernetes 文档](/zh/docs/contribute/localization/)中找到。
@ -1247,8 +1247,8 @@ Do | Don't
:--| :-----
Include one command in ... | Include just one command in ...
Run the container ... | Simply run the container ...
You can easily remove ... | You can remove ...
These simple steps ... | These steps ...
You can remove ... | You can easily remove ...
These steps ... | These simple steps ...
{{< /table >}}
-->
### 避免使用隐含用户对某技术有一定理解的词汇
@ -1261,8 +1261,8 @@ These simple steps ... | These steps ...
:--| :-----
在 ... 中包含一个命令 | 只需要在... 中包含一个命令
运行容器 ... | 只需运行该容器...
你可以很容易地移除... | 你可以移除...
这些简单的步骤... | 这些步骤...
你可以移除... | 你可以很容易地移除...
这些步骤... | 这些简单的步骤...
{{< /table >}}
## {{% heading "whatsnext" %}}

4
content/zh/docs/contribute/suggesting-improvements.md
View File

@ -26,7 +26,7 @@ In most cases, new work on Kubernetes documentation begins with an issue in GitH
then review, categorize and tag issues as needed. Next, you or another member
of the Kubernetes community open a pull request with changes to resolve the issue.
-->
如果你发现 Kubernetes 文档中存在问题，或者你有一个关于新内容的想法，可以考虑
如果你发现 Kubernetes 文档中存在问题或者你有一个关于新内容的想法，可以考虑
提出一个问题（issue）。你只需要具有 [GitHub 账号](https://github.com/join)和 Web
浏览器就可以完成这件事。
@ -53,7 +53,7 @@ they can take action on your issue.
-->
## 创建问题 {#opening-an-issue}
如果你希望就改进已有内容提出建议，或者在文档中发现了错误，请创建一个问题（issue）。
如果你希望就改进已有内容提出建议或者在文档中发现了错误，请创建一个问题（issue）。
1. 滚动到页面底部，点击“报告问题”按钮。浏览器会重定向到一个 GitHub 问题页面，其中
包含了一些预先填充的内容。