whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge pull request #33648 from windsonsea/patch-1

Browse Source 
[zh] updated 2 files in content/zh/docs/contribute/new-content/
This commit is contained in:
Kubernetes Prow Robot
2022-05-15 01:24:16 -07:00
committed by GitHub
parent 0a49e7b9b0 c2ff40963c
commit 7f1283be8a
2 changed files with 300 additions and 71 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/contribute/new-content/blogs-case-studies.md
+101 -14
View File
@@ -34,14 +34,78 @@ Anyone can write a blog post and submit it for review.
-->
## Kubernetes 博客
Kubernetes 博客用于项目发布新功能特性、社区报告以及其他一些可能对整个社区
很重要的新闻。
Kubernetes 博客用于项目发布新功能特性、
社区报告以及其他一些可能对整个社区很重要的新闻。
其读者包括最终用户和开发人员。
大多数博客的内容是关于核心项目中正在发生的事情，不过我们也鼓励你提交一些
关于生态系统中其他地方发生的事情的博客。
大多数博客的内容是关于核心项目中正在发生的事情，
不过我们也鼓励你提交一些有关生态系统中其他时事的博客。
任何人都可以撰写博客并提交评阅。
<!--
### Submit a Post
Blog posts should not be commercial in nature and should consist of original content that applies broadly to the Kubernetes community.
Appropriate blog content includes:
- New Kubernetes capabilities
- Kubernetes projects updates
- Updates from Special Interest Groups
- Tutorials and walkthroughs
- Thought leadership around Kubernetes
- Kubernetes Partner OSS integration
- **Original content only**
-->
### 提交博文
博文不应该是商业性质的，应该包含广泛适用于 Kubernetes 社区的原创内容。
合适的博客内容包括：
- Kubernetes 新能力
- Kubernetes 项目更新信息
- 来自特别兴趣小组（Special Interest Groups, SIG）的更新信息
- 教程和演练
- 有关 Kubernetes 的纲领性理念
- Kubernetes 合作伙伴 OSS 集成信息
- **仅限原创内容**
<!--
Unsuitable content includes:
- Vendor product pitches
- Partner updates without an integration and customer story
- Syndicated posts (language translations ok)
-->
不合适的博客内容包括：
- 供应商产品推介
- 不含集成信息和客户故事的合作伙伴更新信息
- 已发表的博文（可刊登博文译稿）
<!--
To submit a blog post, follow these steps:
1. [Sign the CLA](https://kubernetes.io/docs/contribute/start/#sign-the-cla) if you have not yet done so.
1. Have a look at the Markdown format for existing blog posts in the [website repository](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts).
1. Write out your blog post in a text editor of your choice.
1. On the same link from step 2, click the Create new file button. Paste your content into the editor. Name the file to match the proposed title of the blog post, but don’t put the date in the file name. The blog reviewers will work with you on the final file name and the date the blog will be published.
1. When you save the file, GitHub will walk you through the pull request process.
1. A blog post reviewer will review your submission and work with you on feedback and final details. When the blog post is approved, the blog will be scheduled for publication.
-->
要提交博文，你可以遵从以下步骤：
1. 如果你还未签署 CLA，请先[签署 CLA](https://kubernetes.io/docs/contribute/start/#sign-the-cla)。
2. 查阅[网站仓库](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts)中现有博文的 Markdown 格式。
3. 在你所选的文本编辑器中撰写你的博文。
4. 在第 2 步的同一链接上，点击 **Create new file** 按钮。
将你的内容粘贴到编辑器中。为文件命名，使其与提议的博文标题一致，
但不要在文件名中写日期。
博客评阅者将与你一起确定最终的文件名和发表博客的日期。
5. 保存文件时，GitHub 将引导你完成 PR 流程。
6. 博客评阅者将评阅你提交的内容，并与你一起处理反馈和最终细节。
当博文被批准后，博客将排期发表。
<!--
### Guidelines and expectations
@@ -74,7 +138,7 @@ Kubernetes 博客用于项目发布新功能特性、社区报告以及其他一
- 博客内容并非在某特定日期发表。
- 文章会交由社区自愿者评阅。我们会尽力满足特定的时限要求，只是无法就此作出承诺。
- Kubernetes 项目的很多核心组件会在发布窗口期内提交博客文章，导致发表时间被推迟。
因此，请考虑在发布周期内较为平静的时间段提交博文。
因此，请考虑在发布周期内较为平静的时间段提交博客文章。
- 如果你希望就博文发表日期上进行较大范围的协调，请联系
[CNCF 推广团队](https://www.cncf.io/about/contact/)。
这也许是比提交博客文章更合适的一种选择。
@@ -87,6 +151,7 @@ Kubernetes 博客用于项目发布新功能特性、社区报告以及其他一
- The components of Kubernetes are purposely modular, so tools that use existing integration points like CNI and CSI are on topic.
- Posts about other CNCF projects may or may not be on topic. We recommend asking the blog team before submitting a draft.
- Many CNCF projects have their own blog. These are often a better choice for posts. There are times of major feature or milestone for a CNCF project that users would be interested in reading on the Kubernetes blog.
- Blog posts about contributing to the Kubernetes project should be in the [Kubernetes Contributors site](https://kubernetes.dev)
-->
- 博客内容应该对 Kubernetes 用户有用。
- 与参与 Kubernetes SIGs 活动相关，或者与这类活动的结果相关的主题通常是切题的。
@@ -98,6 +163,7 @@ Kubernetes 博客用于项目发布新功能特性、社区报告以及其他一
- 很多 CNCF 项目有自己的博客。这些博客通常是更好的选择。
有些时候，某个 CNCF 项目的主要功能特性或者里程碑的变化可能是用户有兴趣在
Kubernetes 博客上阅读的内容。
- 关于为 Kubernetes 项目做贡献的博客内容应该放在 [Kubernetes 贡献者站点](https://kubernetes.dev)上。
<!--
- Blog posts should be original content
- The official blog is not for repurposing existing content from a third party as new content.
@@ -126,7 +192,7 @@ We recognize that this requirement makes the process more difficult for less-fam
-->
### 提交博客的技术考虑
所提交的内容应该是 Markdown 格式的，以便能够被[Hugo](https://gohugo.io/) 生成器来处理。
所提交的内容应该是 Markdown 格式的，以便能够被 [Hugo](https://gohugo.io/) 生成器来处理。
关于如何使用相关技术，有[很多可用的资源](https://gohugo.io/documentation/)。
我们知道这一需求可能给那些对此过程不熟悉的朋友们带来不便，
@@ -141,7 +207,6 @@ To submit a blog post follow these directions:
SIG Docs [博客子项目](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject) 负责管理博客的评阅过程。
更多信息可参考[提交博文](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject#submit-a-post)。
要提交博文，你可以遵从以下指南：
<!--
- [Open a pull request](/docs/contribute/new-content/open-a-pr/#fork-the-repo) with a new blog post. New blog posts go under the [`content/en/blog/_posts`](https://github.com/kubernetes/website/tree/main/content/en/blog/_posts) directory.
@@ -152,7 +217,7 @@ SIG Docs [博客子项目](https://github.com/kubernetes/community/tree/master/s
- Do **not** include dots in the filename. A name like `2020-01-01-whats-new-in-1.19.md` causes failures during a build.
- The front matter must include the following:
-->
- [发起一个包含博文的 PR](/zh/docs/contribute/new-content/open-a-pr/#fork-the-repo)。
- [发起一个包含新博文的 PR](/zh/docs/contribute/new-content/open-a-pr/#fork-the-repo)。
新博文要创建于 [`content/en/blog/_posts`](https://github.com/kubernetes/website/tree/main/content/en/blog/_posts) 目录下。
- 确保你的博文遵从合适的命名规范，并带有下面的引言（元数据）信息：
@@ -198,6 +263,30 @@ SIG Docs [博客子项目](https://github.com/kubernetes/community/tree/master/s
- 博客团队会对 PR 内容进行评阅，为你提供一些评语以便修订。
之后，机器人会将你的博文合并并发表。
<!--
- If the content of the blog post contains only content that is not expected to require updates to stay accurate for the reader, it can be marked as evergreen and exempted from the automatic warning about outdated content added to blog posts older than one year.
- To mark a blog post as evergreen, add this to the front matter:
```yaml
evergreen: true
```
- Examples of content that should not be marked evergreen:
- **Tutorials** that only apply to specific releases or versions and not all future versions
- References to pre-GA APIs or features
-->
- 如果博文的内容仅包含预期无需更新就能对读者保持精准的内容，
则可以将这篇博文标记为长期有效（evergreen），
且免除添加博文发表一年后内容过期的自动警告。
- 要将一篇博文标记为长期有效，请在引言部分添加以下标记：
```yaml
evergreen: true
```
- 不应标记为长期有效的内容示例：
- 仅适用于特定发行版或版本而不是所有未来版本的**教程**
- 对非正式发行（Pre-GA）API 或功能特性的引用
<!--
## Submit a case study
@@ -212,13 +301,11 @@ Refer to the [case study guidelines](https://github.com/cncf/foundation/blob/mas
## 提交案例分析
案例分析用来概述组织如何使用 Kubernetes 解决现实世界的问题。
Kubernetes 市场化团队和 {{< glossary_tooltip text="CNCF" term_id="cncf" >}} 成员
会与你一起工作，撰写所有的案例分析。
Kubernetes 市场化团队和 {{< glossary_tooltip text="CNCF" term_id="cncf" >}} 成员会与你一起工作，
撰写所有的案例分析。
请查看
[现有案例分析](https://github.com/kubernetes/website/tree/main/content/en/case-studies)
的源码。
请查看[现有案例分析](https://github.com/kubernetes/website/tree/main/content/en/case-studies)的源码。
参考[案例分析指南](https://github.com/cncf/foundation/blob/master/case-study-guidelines.md)
参考[案例分析指南](https://github.com/cncf/foundation/blob/master/case-study-guidelines.md)，
根据指南中的注意事项提交你的 PR 请求。
content/zh/docs/contribute/new-content/open-a-pr.md
+199 -57
View File
@@ -26,13 +26,12 @@ upcoming Kubernetes release, see
To contribute new content pages or improve existing content pages, open a pull request (PR). Make sure you follow all the requirements in the [Before you begin](/docs/contribute/new-content/overview/#before-you-begin) section.
-->
{{< note >}}
**代码开发者们**：如果你在为下一个 Kubernetes 发行版本中的某功能特性
撰写文档，请参考[为新功能撰写文档](/zh/docs/contribute/new-content/new-features/)。
**代码开发者们**：如果你在为下一个 Kubernetes 发行版本中的某功能特性撰写文档，
请参考[为发行版本撰写功能特性文档](/zh/docs/contribute/new-content/new-features/)。
{{< /note >}}
要贡献新的内容页面或者改进已有内容页面，请发起拉取请求（PR）。
请确保你满足了[开始之前](/zh/docs/contribute/new-content/overview/#before-you-begin)
节中所列举的所有要求。
请确保你满足了[开始之前](/zh/docs/contribute/new-content/#before-you-begin)一节中所列举的所有要求。
<!--
If your change is small, or you're unfamiliar with git, read [Changes using
@@ -45,16 +44,55 @@ learn how to make changes locally on your computer.
[使用 GitHub 提交变更](#changes-using-github)以了解如何编辑页面。
如果所提交的变更较大，请阅读[基于本地克隆副本开展工作](#fork-the-repo)以学习
如何在你本地计算机上构造变更。
如何在你本地计算机上进行修改。
<!-- body -->
<!--
<!--
## Changes using GitHub
If you're less experienced with git workflows, here's an easier method of
opening a pull request.
opening a pull request. The figure below outlines the steps and the details follow.
-->
## 使用 GitHub 提交变更 {#changes-using-github}
如果你在 git 工作流方面欠缺经验，这里有一种发起拉取请求的更为简单的方法。
下图勾勒了后续的步骤和细节。
<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
{{< mermaid >}}
flowchart LR
A([fa:fa-user 新的<br>贡献者]) --- id1[(K8s/Website<br>GitHub)]
subgraph tasks[使用 GitHub 提交变更]
direction TB
0[ ] -.-
1[1. 编辑此页] --> 2[2. 使用 GitHub markdown<br>编辑器进行修改]
2 --> 3[3. 填写 Propose file change]
end
subgraph tasks2[ ]
direction TB
4[4. 选择 Propose file change] --> 5[5. 选择 Create pull request] --> 6[6. 填写 Open a pull request]
6 --> 7[7. 选择 Create pull request]
end
id1 --> tasks --> tasks2
classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:1px,color:#fff;
classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
class A,1,2,3,4,5,6,7 grey
class 0 spacewhite
class tasks,tasks2 white
class id1 k8s
{{</ mermaid >}}
***插图 - 使用 GitHub 发起一个 PR 的步骤***
<!--
1. On the page where you see the issue, select the pencil icon at the top right.
You can also scroll to the bottom of the page and select **Edit this page**.
2. Make your changes in the GitHub markdown editor.
@@ -62,19 +100,21 @@ opening a pull request.
form. In the first field, give your commit message a title. In
the second field, provide a description.
-->
## 使用 GitHub 提交变更 {#changes-using-github}
如果你在 git 工作流方面欠缺经验，这里有一种发起拉取请求的更为简单的方法。
1. 在你发现问题的网页，选择右上角的铅笔图标。你也可以滚动到页面底端，选择
**编辑此页面**。
1. 在你发现问题的网页，选择右上角的铅笔图标。
你也可以滚动到页面底端，选择**编辑此页**。
2. 在 GitHub 的 Markdown 编辑器中修改内容。
3. 在编辑器的下方，填写 **建议文件变更** 表单。
3. 在编辑器的下方，填写 **Propose file change** 表单。
在第一个字段中，为你的提交消息取一个标题。
在第二个字段中，为你的提交写一些描述文字。
<!--
{{< note >}}
Do not use any [GitHub Keywords](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) in your commit message. You can add those to the pull request
description later.
{{< /note >}}
-->
{{< note >}}
不要在提交消息中使用 [GitHub 关键词](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)
不要在提交消息中使用 [GitHub 关键词](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)。
你可以在后续的 PR 描述中使用这些关键词。
{{< /note >}}
<!--
@@ -91,13 +131,14 @@ opening a pull request.
details the template text asks for, then delete the extra template text.
- Leave the **Allow edits from maintainers** checkbox selected.
-->
4. 选择 **Propose File Change**.
5. 选择 **Create pull request**.
6. 在 **Open a pull request** 屏幕上填写表单：
4. 选择 **Propose File Change**。
5. 选择 **Create pull request**。
6. 出现 **Open a pull request** 界面。填写表单：
- **Subject** 字段默认为提交的概要信息。你可以根据需要修改它。
- **Body** 字段包含更为详细的提交消息，如果你之前有填写过的话，以及一些模板文字。
填写模板所要求的详细信息，之后删除多余的模板文字。
- **Body** 字段包含更为详细的提交消息，如果你之前有填写过的话，
以及一些模板文字。填写模板所要求的详细信息，
之后删除多余的模板文字。
- 确保 **Allow edits from maintainers** 复选框被勾选。
<!--
@@ -106,11 +147,11 @@ opening a pull request.
-->
{{< note >}}
PR 描述信息是帮助 PR 评阅人了解你所提议的变更的重要途径。
更多信息请参考[发起一个 PR](#open-a-pr).
更多信息请参考[发起一个 PR](#open-a-pr)。
{{< /note >}}
<!-- 7. Select **Create pull request**. -->
7. 选择 **Create pull request**.
7. 选择 **Create pull request**。
<!--
### Addressing feedback in GitHub
@@ -159,6 +200,8 @@ If you're more experienced with git, or if your changes are larger than a few li
work from a local fork.
Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) installed on your computer. You can also use a git UI application.
The figure below shows the steps to follow when you work from a local fork. The details for each step follow.
-->
## 基于本地克隆副本开展工作 {#work-from-a-local-fork}
@@ -168,6 +211,42 @@ Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installi
首先要确保你在本地计算机上安装了 [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)。
你也可以使用 git 的带用户界面的应用。
下图显示了基于本地克隆副本开展工作的步骤。
每个步骤的细节如下。
<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
{{< mermaid >}}
flowchart LR
1[派生 K8s/website<br>仓库] --> 2[创建本地克隆副本<br>并指定 upstream 仓库]
subgraph changes[你的变更]
direction TB
S[ ] -.-
3[创建一个分支<br>例如: my_new_branch] --> 3a[使用文本编辑器<br>进行修改] --> 4["使用 Hugo 在本地<br>预览你的变更<br>(localhost:1313)<br>或构建容器镜像"]
end
subgraph changes2[提交 / 推送]
direction TB
T[ ] -.-
5[提交你的变更] --> 6[将提交推送到<br>origin/my_new_branch]
end
2 --> changes --> changes2
classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:1px,color:#fff;
classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
class 1,2,3,3a,4,5,6 grey
class S,T spacewhite
class changes,changes2 white
{{</ mermaid >}}
<!--
***Figure - Working from a local fork to make your changes***
-->
***插图 - 使用本地克隆副本进行修改***
<!--
### Fork the kubernetes/website repository
@@ -182,14 +261,16 @@ Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installi
<!--
### Create a local clone and set the upstream
3. In a terminal window, clone your fork:
3. In a terminal window, clone your fork and update the [Docsy Hugo theme](https://github.com/google/docsy#readme):
-->
### 创建一个本地克隆副本并指定 upstream 仓库
3. 打开终端窗口，克隆你所派生的副本：
3. 打开终端窗口，克隆你所派生的副本，并更新 [Docsy Hugo 主题](https://github.com/google/docsy#readme)：
```bash
git clone git@github.com/<github_username>/website
cd website
git submodule update --init --recursive --depth 1
```
<!--
@@ -236,7 +317,9 @@ Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installi
这样可以确保你本地的仓库在开始工作前是最新的。
<!--
{{< note >}}
This workflow is different than the [Kubernetes Community GitHub Workflow](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md). You do not need to merge your local copy of `main` with `upstream/main` before pushing updates to your fork.
{{< /note >}}
-->
{{< note >}}
此工作流程与 [Kubernetes 社区 GitHub 工作流](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md)有所不同。
@@ -262,12 +345,12 @@ Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installi
1. 决定你要基于哪个分支来开展工作：
- 针对已有内容的改进，请使用 `upstream/main`；
- 针对已有功能特性的新文档内容，请使用 `upstream/main`；
- 针对已有内容的改进，请使用 `upstream/main`。
- 针对已有功能特性的新文档内容，请使用 `upstream/main`。
- 对于本地化内容，请基于本地化的约定。
可参考[对 Kubernetes 文档进行本地化](/zh/docs/contribute/localization/)了解详细信息。
可参考[本地化 Kubernetes 文档](/zh/docs/contribute/localization/)了解详细信息。
- 对于在下一个 Kubernetes 版本中新功能特性的文档，使用独立的功能特性分支。
参考[为发行版本功能特性撰写文档](/zh/docs/contribute/new-content/new-features/)了解更多信息。
参考[为发行版本撰写功能特性文档](/zh/docs/contribute/new-content/new-features/)了解更多信息。
- 对于很多 SIG Docs 共同参与的，需较长时间才完成的任务，例如内容的重构，
请使用为该任务创建的特性分支。
@@ -276,7 +359,7 @@ Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installi
<!--
2. Create a new branch based on the branch identified in step 1. This example assumes the base branch is `upstream/main`:
-->
2. 基于第一步中选定的分支，创建新分支。
2. 基于第 1 步中选定的分支，创建新分支。
下面的例子假定基础分支是 `upstream/main`：
```bash
@@ -285,11 +368,13 @@ Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installi
<!--
3. Make your changes using a text editor.
-->
3. 使用文本编辑器开始构造变更。
3. 使用文本编辑器进行修改。
<!--
At any time, use the `git status` command to see what files you've changed.
-->
在任何时候，都可以使用 `git status` 命令查看你所改变了的文件列表。
<!--
@@ -379,8 +464,8 @@ When you are ready to submit a pull request, commit your changes.
```
{{< note >}}
不要在提交消息中使用任何 [GitHub 关键字](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)。
你可以在后面创建 PR 时使用这些关键字。
不要在提交消息中使用任何 [GitHub 关键词](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)。
你可以在后续的 PR 描述中使用这些关键词。
{{< /note >}}
<!--
4. Push your local branch and its new commit to your remote fork:
@@ -404,29 +489,30 @@ You can either build the website's container image or run Hugo locally. Building
-->
### 在本地预览你的变更 {#preview-locally}
在推送变更或者发起 PR 之前在本地查看一下预览是个不错的注意。
在推送变更或者发起 PR 之前在本地查看一下预览是个不错的主意。
通过预览你可以发现构建错误或者 Markdown 格式问题。
你可以构造网站的容器镜像或者在本地运行 Hugo。
构造容器镜像的方式比较慢，不过能够显示 [Hugo 短代码（shortcodes）](/zh/docs/contribute/style/hugo-shortcodes/)，
你可以构建网站的容器镜像或者在本地运行 Hugo。
构建容器镜像的方式比较慢，不过能够显示 [Hugo 短代码（shortcodes）](/zh/docs/contribute/style/hugo-shortcodes/)，
因此对于调试是很有用的。
{{< tabs name="tab_with_hugo" >}}
{{% tab name="在容器内执行 Hugo" %}}
<!--
The following commmand uses Docker as the default container engine.
You can set up the `CONTAINER_ENGINE` to override this behavior.
{{< note >}}
The commands below use Docker as default container engine. Set the `CONTAINER_ENGINE` environment variable to override this behaviour.
{{< /note >}}
-->
{{< note >}}
下面的命令中使用 Docker 作为默认的容器引擎。
如果需要重载这一行为，可以设置 `CONTAINER_ENGINE`。
如果需要重载这一行为，可以设置 `CONTAINER_ENGINE` 环境变量。
{{< /note >}}
<!--
1. Build the image locally:
-->
1. 在本地构造镜像；
1. 在本地构建镜像：
```bash
# 使用 docker (默认)
@@ -441,7 +527,7 @@ You can set up the `CONTAINER_ENGINE` to override this behavior.
<!--
2. After building the `kubernetes-hugo` image locally, build and serve the site:
-->
2. 在本地构造了 `kubernetes-hugo` 镜像之后，可以构造并启动网站：
2. 在本地构建了 `kubernetes-hugo` 镜像之后，可以构建并启动网站：
```bash
# 使用 docker (默认)
@@ -473,24 +559,37 @@ Alternately, install and use the `hugo` command on your computer:
<!--
1. Install the [Hugo](https://gohugo.io/getting-started/installing/) version specified in [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/main/netlify.toml).
2. In a terminal, go to your Kubernetes website repository and start the Hugo server:
2. If you have not updated your website repository, the `website/themes/docsy` directory is empty.
The site cannot build without a local copy of the theme. To update the website theme, run:
3. In a terminal, go to your Kubernetes website repository and start the Hugo server:
-->
1. 安装 [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/main/netlify.toml)
文件中指定的 [Hugo](https://gohugo.io/getting-started/installing/) 版本。
2. 启动一个终端窗口，进入 Kubernetes 网站仓库目录，启动 Hugo 服务器：
2. 如果你尚未更新你的网站仓库，则 `website/themes/docsy` 目录是空的。
如果本地缺少主题的副本，则该站点无法构建。
要更新网站主题，运行以下命令：
```bash
git submodule update --init --recursive --depth 1
```
3. 启动一个终端窗口，进入 Kubernetes 网站仓库目录，启动 Hugo 服务器：
```bash
cd <path_to_your_repo>/website
hugo server
```
<!--
3. In your browser’s address bar, enter `https://localhost:1313`.
4. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C`,
4. In a web browser, navigate to `https://localhost:1313`. Hugo watches the
changes and rebuilds the site as needed.
5. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C`,
or close the terminal window.
-->
3. 在浏览器的地址栏输入： `https://localhost:1313`。
4. 要停止本地 Hugo 实例，返回到终端窗口并输入 `Ctrl+C` 或者关闭终端窗口。
4. 在浏览器的地址栏输入： `https://localhost:1313`。
Hugo 会监测文件的变更并根据需要重新构建网站。
5. 要停止本地 Hugo 实例，返回到终端窗口并输入 `Ctrl+C` 或者关闭终端窗口。
{{% /tab %}}
{{< /tabs >}}
@@ -499,6 +598,42 @@ Alternately, install and use the `hugo` command on your computer:
-->
### 从你的克隆副本向 kubernetes/website 发起拉取请求（PR） {#open-a-pr}
<!--
The figure below shows the steps to open a PR from your fork to the K8s/website. The details follow.
-->
下图显示了从你的克隆副本向 K8s/website 发起 PR 的步骤。
详细信息如下。
<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
{{< mermaid >}}
flowchart LR
subgraph first[ ]
direction TB
1[1. 前往 K8s/website 仓库] --> 2[2. 选择 New Pull Request]
2 --> 3[3. 选择 compare across forks]
3 --> 4[4. 从 head repository 下拉菜单<br>选择你的克隆副本]
end
subgraph second [ ]
direction TB
5[5. 从 compare 下拉菜单<br>选择你的分支] --> 6[6. 选择 Create Pull Request]
6 --> 7[7. 为你的 PR<br>添加一个描述]
7 --> 8[8. 选择 Create pull request]
end
first --> second
classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
class 1,2,3,4,5,6,7,8 grey
class first,second white
{{</ mermaid >}}
<!--
***Figure - Steps to open a PR from your fork to the K8s/website***
-->
***插图 - 从你的克隆副本向 K8s/website 发起一个 PR 的步骤***
<!--
1. In a web browser, go to the [`kubernetes/website`](https://github.com/kubernetes/website/) repository.
2. Select **New Pull Request**.
@@ -527,10 +662,10 @@ Alternately, install and use the `hugo` command on your computer:
- 如果存在一个相关联的 GitHub Issue，可以在描述中包含 `Fixes #12345` 或
`Closes #12345`。GitHub 的自动化设施能够在当前 PR 被合并时自动关闭所提及
的 Issue。如果有其他相关联的 PR，也可以添加对它们的链接。
- 如果你尤其希望获得某方面的建议，可以在描述中包含你希望评阅人思考的问题。
- 如果你特别希望获得某方面的建议，可以在描述中包含你希望评阅人思考的问题。
8. 点击 **Create pull request** 按钮。
祝贺你! 你的拉取请求现在出现在 [Pull Requests](https://github.com/kubernetes/website/pulls) 列表中了！
祝贺你！你的拉取请求现在出现在 [Pull Requests](https://github.com/kubernetes/website/pulls) 列表中了！
<!--
After opening a PR, GitHub runs automated tests and tries to deploy a preview using [Netlify](https://www.netlify.com/).
@@ -577,11 +712,12 @@ GitHub 也会自动为 PR 分派一些标签，以帮助评阅人。
3. Use `git push origin <my_new_branch>` to push your changes and re-run the Netlify tests.
-->
2. 如果有必要，更新你的提交消息；
3. 使用 `git push origin <my_new_branch>` 来推送你的变更，重新出发 Netlify 测试。
3. 使用 `git push origin <my_new_branch>` 来推送你的变更，重新触发 Netlify 测试。
<!--
If you use `git commit -m` instead of amending, you must
[squash your commits](#squashing-commits) before merging.
{{< note >}}
If you use `git commit -m` instead of amending, you must [squash your commits](#squashing-commits) before merging.
{{< /note >}}
-->
{{< note >}}
如果你使用 `git commit -m` 而不是增补参数，在 PR 最终合并之前你必须
@@ -626,7 +762,7 @@ For more information, see [Git Branching - Basic Branching and Merging](https://
{{< note >}}
要了解更多信息，可参考
[Git 分支管理 - 基本分支和合并](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging#_basic_merge_conflicts)、
[高级合并](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging)、
[高级合并](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging)，
或者在 `#sig-docs` Slack 频道寻求帮助。
{{< /note >}}
@@ -730,7 +866,9 @@ If another contributor commits changes to the same file in another PR, it can cr
### 压缩（Squashing）提交 {#squashing-commits}
<!--
{{< note >}}
For more information, see [Git Tools - Rewriting History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History), or ask in the `#sig-docs` Slack channel for help.
{{< /note >}}
-->
{{< note >}}
要了解更多信息，可参看
@@ -793,7 +931,9 @@ If your PR has multiple commits, you must squash them into a single commit befor
就重设基线操作本身，我们关注 `squash` 和 `pick` 选项。
<!--
{{< note >}}
For more information, see [Interactive Mode](https://git-scm.com/docs/git-rebase#_interactive_mode).
{{< /note >}}
-->
{{< note >}}
进一步的详细信息可参考 [Interactive Mode](https://git-scm.com/docs/git-rebase#_interactive_mode)。
@@ -866,12 +1006,14 @@ Most repositories use issue and PR templates. Have a look through some open
issues and PRs to get a feel for that team's processes. Make sure to fill out
the templates with as much detail as possible when you file issues or PRs.
-->
每个仓库有其自己的流程和过程。在登记 Issue 或者发起 PR 之前，记得阅读仓库的
`README.md`、`CONTRIBUTING.md` 和 `code-of-conduct.md` 文件，如果有的话。
每个仓库有其自己的流程和过程。在登记 Issue 或者发起 PR 之前，
记得阅读仓库可能存在的 `README.md`、`CONTRIBUTING.md` 和
`code-of-conduct.md` 文件。
大多数仓库都有自己的 Issue 和 PR 模版。通过查看一些待解决的 Issues 和
PR，也可以添加对它们的链接。你可以多少了解该团队的流程。
在登记 Issue 或提出 PR 时，务必尽量填充所给的模版，多提供详细信息。
大多数仓库都有自己的 Issue 和 PR 模板。
通过查看一些待解决的 Issue 和 PR，
你可以大致了解协作的流程。
在登记 Issue 或提出 PR 时，务必尽量填充所给的模板，多提供详细信息。
## {{% heading "whatsnext" %}}