diff --git a/translations/zh-CN/content/actions/automating-builds-and-tests/about-continuous-integration.md b/translations/zh-CN/content/actions/automating-builds-and-tests/about-continuous-integration.md
index c93ac3bc0f84..5c1d123b114a 100644
--- a/translations/zh-CN/content/actions/automating-builds-and-tests/about-continuous-integration.md
+++ b/translations/zh-CN/content/actions/automating-builds-and-tests/about-continuous-integration.md
@@ -27,27 +27,27 @@ ms.locfileid: '147880659'
 
 ## 关于持续集成
 
-持续集成 (CI) 是一种需要频繁提交代码到共享仓库的软件实践。 频繁提交代码能较早检测到错误，减少在查找错误来源时开发者需要调试的代码量。 频繁的代码更新也更便于从软件开发团队的不同成员合并更改。 这对开发者非常有益，他们可以将更多时间用于编写代码，而减少在调试错误或解决合并冲突上所花的时间。
+持续集成 (CI) 是一种需要频繁提交代码到共享仓库的软件实践。频繁提交代码能较早检测到错误，减少在查找错误来源时开发者需要调试的代码量。频繁的代码更新也更便于从软件开发团队的不同成员合并更改。这对开发者非常有益，他们可以将更多时间用于编写代码，而减少在调试错误或解决合并冲突上所花的时间。
 
-提交代码到仓库时，可以持续创建并测试代码，以确保提交未引入错误。 您的测试可以包括代码语法检查（检查样式格式）、安全性检查、代码覆盖率、功能测试及其他自定义检查。
+提交代码到仓库时，可以持续创建并测试代码，以确保提交未引入错误。您的测试可以包括代码语法检查（检查样式格式）、安全性检查、代码覆盖率、功能测试及其他自定义检查。
 
-创建和测试代码需要服务器。 您可以在推送代码到仓库之前在本地创建并测试更新，也可以使用 CI 服务器检查仓库中的新代码提交。
+创建和测试代码需要服务器。您可以在推送代码到仓库之前在本地创建并测试更新，也可以使用 CI 服务器检查仓库中的新代码提交。
 
 ## 关于使用 {% data variables.product.prodname_actions %} 的持续集成
 
-{% ifversion ghae %}使用 {% data variables.product.prodname_actions %} 的 CI 提供可以在存储库中生成代码并运行测试的工作流。 工作流程可以在您托管的运行器系统上运行。 有关详细信息，请参阅[关于自承载运行器](/actions/hosting-your-own-runners/about-self-hosted-runners)。
-{% else %}使用 {% data variables.product.prodname_actions %} 的 CI 提供可以在仓库中构建代码并运行测试的工作流程。 工作流程可在 {% data variables.product.prodname_dotcom %} 托管的虚拟机或您自行托管的机器上运行。 有关详细信息，请参阅“[关于 {% data variables.product.prodname_dotcom %} 托管的运行器](/actions/using-github-hosted-runners/about-github-hosted-runners)”和“[关于自托管运行器](/actions/automating-your-workflow-with-github-actions/about-self-hosted-runners)”。
+{% ifversion ghae %}使用 {% data variables.product.prodname_actions %} 的 CI 提供可以在存储库中生成代码并运行测试的工作流。工作流程可以在您托管的运行器系统上运行。有关详细信息，请参阅[关于自承载运行器](/actions/hosting-your-own-runners/about-self-hosted-runners)。
+{% else %}使用 {% data variables.product.prodname_actions %} 的 CI 提供可以在仓库中构建代码并运行测试的工作流程。工作流程可在 {% data variables.product.prodname_dotcom %} 托管的虚拟机或您自行托管的机器上运行。有关详细信息，请参阅“[关于 {% data variables.product.prodname_dotcom %} 托管的运行器](/actions/using-github-hosted-runners/about-github-hosted-runners)”和“[关于自托管运行器](/actions/automating-your-workflow-with-github-actions/about-self-hosted-runners)”。
 {% endif %}
 
 可以配置 CI 工作流，使其在 {% data variables.product.prodname_dotcom %} 事件发生时（例如，当新代码推送到存储库时）运行、按设定的时间表运行，或在使用存储库分发 Webhook 的外部事件发生时运行。
 
-{% data variables.product.product_name %} 运行 CI 测试并在拉取请求中提供每次测试的结果，因此您可以查看分支中的更改是否引入错误。 如果工作流程中的所有 CI 测试通过，您推送的更改可供团队成员审查或合并 如果测试失败，则是其中某项更改导致了失败。
+{% data variables.product.product_name %} 运行 CI 测试并在拉取请求中提供每次测试的结果，因此您可以查看分支中的更改是否引入错误。如果工作流程中的所有 CI 测试通过，您推送的更改可供团队成员审查或合并 如果测试失败，则是其中某项更改导致了失败。
 
-如果在仓库中设置了 CI，{% data variables.product.product_name %} 会分析仓库中的代码，并根据仓库中的语言和框架推荐 CI 工作流程。 例如，如果使用 [Node.js](https://nodejs.org/en/)，{% data variables.product.product_name %} 将建议使用入门工作流来安装 Node.js 包并运行测试。 您可以使用 {% data variables.product.product_name %} 建议的 CI 入门工作流程，自定义建议的入门工作流程，或创建自己的自定义工作流程文件来运行 CI 测试。
+如果在仓库中设置了 CI，{% data variables.product.product_name %} 会分析仓库中的代码，并根据仓库中的语言和框架推荐 CI 工作流程。例如，如果使用 [Node.js](https://nodejs.org/en/)，{% data variables.product.product_name %} 将建议使用入门工作流来安装 Node.js 包并运行测试。您可以使用 {% data variables.product.product_name %} 建议的 CI 入门工作流程，自定义建议的入门工作流程，或创建自己的自定义工作流程文件来运行 CI 测试。
 
 ![建议的持续集成入门工作流程屏幕截图](/assets/images/help/repository/ci-with-actions-template-picker.png)
 
-除了帮助设置项目的 CI 工作流程之外，您还可以使用 {% data variables.product.prodname_actions %} 创建跨整个软件开发生命周期的工作流程。 例如，您可以使用操作来部署、封装或发行项目。 有关详细信息，请参阅“[关于 {% data variables.product.prodname_actions %}](/articles/about-github-actions)”。
+除了帮助设置项目的 CI 工作流程之外，您还可以使用 {% data variables.product.prodname_actions %} 创建跨整个软件开发生命周期的工作流程。例如，您可以使用操作来部署、封装或发行项目。有关详细信息，请参阅“[关于 {% data variables.product.prodname_actions %}](/articles/about-github-actions)”。
 
 有关常用术语的定义，请参阅“[{% data variables.product.prodname_actions %} 的核心概念](/github/automating-your-workflow-with-github-actions/core-concepts-for-github-actions)”。
 
diff --git a/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-go.md b/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-go.md
index 34faafc9da12..80df6c7899f4 100644
--- a/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-go.md
+++ b/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-go.md
@@ -23,18 +23,18 @@ ms.locfileid: '147079572'
 
 本指南介绍如何构建、测试和发布 Go 包。
 
-{% ifversion ghae %} {% data reusables.actions.self-hosted-runners-software %} {% else %} {% data variables.product.prodname_dotcom %} 托管的运行器有一个带有预装软件的工具缓存，其中包括 Go 的依赖项。 有关最新软件和 Go 预安装版本的完整列表，请参阅“[关于 {% data variables.product.prodname_dotcom %} 托管的运行器](/actions/using-github-hosted-runners/about-github-hosted-runners#preinstalled-software)”。
+{% ifversion ghae %} {% data reusables.actions.self-hosted-runners-software %} {% else %} {% data variables.product.prodname_dotcom %} 托管的运行器有一个带有预装软件的工具缓存，其中包括 Go 的依赖项。有关最新软件和 Go 预安装版本的完整列表，请参阅“[关于 {% data variables.product.prodname_dotcom %} 托管的运行器](/actions/using-github-hosted-runners/about-github-hosted-runners#preinstalled-software)”。
 {% endif %}
 
 ## 先决条件
 
-您应该已经熟悉 YAML 语法及其如何与 {% data variables.product.prodname_actions %} 结合使用。 有关详细信息，请参阅“[{% data variables.product.prodname_actions %} 的工作流语法](/actions/using-workflows/workflow-syntax-for-github-actions)”。
+您应该已经熟悉 YAML 语法及其如何与 {% data variables.product.prodname_actions %} 结合使用。有关详细信息，请参阅“[{% data variables.product.prodname_actions %} 的工作流语法](/actions/using-workflows/workflow-syntax-for-github-actions)”。
 
-建议你对 Go 语言有基本的了解。 有关详细信息，请参阅 [Go 入门](https://golang.org/doc/tutorial/getting-started)。
+建议你对 Go 语言有基本的了解。有关详细信息，请参阅 [Go 入门](https://golang.org/doc/tutorial/getting-started)。
 
 ## 使用 Go 入门工作流程
 
-{% data variables.product.prodname_dotcom %} 提供了一个适用于大多数 Go 项目的 Go 入门工作流程。 本指南包含可用于自定义入门工作流程的示例。 有关详细信息，请参阅 [Go 入门工作流](https://github.com/actions/starter-workflows/blob/main/ci/go.yml)。
+{% data variables.product.prodname_dotcom %} 提供了一个适用于大多数 Go 项目的 Go 入门工作流程。本指南包含可用于自定义入门工作流程的示例。有关详细信息，请参阅 [Go 入门工作流](https://github.com/actions/starter-workflows/blob/main/ci/go.yml)。
 
 若要快速开始，请将起始工作流添加到存储库的 `.github/workflows` 目录。
 
@@ -64,11 +64,11 @@ jobs:
 
 ## 指定 Go 版本
 
-指定 Go 版本的最简单方法是使用由 {% data variables.product.prodname_dotcom %} 提供的 `setup-go` 操作。 有关详细信息，请参阅 [`setup-go` 操作](https://github.com/actions/setup-go/)。
+指定 Go 版本的最简单方法是使用由 {% data variables.product.prodname_dotcom %} 提供的 `setup-go` 操作。有关详细信息，请参阅 [`setup-go` 操作](https://github.com/actions/setup-go/)。
 
-若要在 {% data variables.product.prodname_dotcom %} 托管的运行器上使用 Go 的预安装版本，请将相关版本传递给 `setup-go` 操作的 `go-version` 属性。 此操作从每个运行器上的工具缓存中查找特定版本的 Go，并将必要的二进制文件添加到 `PATH`。 这些更改将持续用于作业的其余部分。
+若要在 {% data variables.product.prodname_dotcom %} 托管的运行器上使用 Go 的预安装版本，请将相关版本传递给 `setup-go` 操作的 `go-version` 属性。此操作从每个运行器上的工具缓存中查找特定版本的 Go，并将必要的二进制文件添加到 `PATH`。这些更改将持续用于作业的其余部分。
 
-`setup-go` 操作是 Go与 {% data variables.product.prodname_actions %} 结合使用时的推荐方式，因为它帮助确保不同运行器和不同版本的 Go 行为一致。 如果使用自托管运行器，则必须安装 Go 并将其添加到 `PATH`。
+`setup-go` 操作是 Go 与 {% data variables.product.prodname_actions %} 结合使用时的推荐方式，因为它帮助确保不同运行器和不同版本的 Go 行为一致。如果使用自托管运行器，则必须安装 Go 并将其添加到 `PATH`。
 
 ### 使用多个版本的 Go
 
@@ -98,7 +98,7 @@ jobs:
 
 ### 使用特定的 Go 版本
 
-可以将作业配置为使用 Go 的特定版本，例如 `1.16.2`。 或者，您也可以使用语义版本语法来获得最新的次要版本。 此示例使用 Go 1.16 最新的修补程序版本：
+可以将作业配置为使用 Go 的特定版本，例如 `1.16.2`。或者，您也可以使用语义版本语法来获得最新的次要版本。此示例使用 Go 1.16 最新的修补程序版本：
 
 ```yaml{:copy}
       - name: Setup Go 1.16.x
@@ -130,7 +130,7 @@ jobs:
 
 ### 缓存依赖项
 
-可以使用 [`setup-go` 操作](https://github.com/actions/setup-go)缓存和还原依赖项。 默认情况下，缓存处于禁用状态，但可以通过将参数 `cache` 设置为 `true` 来启用它。
+可以使用 [`setup-go` 操作](https://github.com/actions/setup-go)缓存和还原依赖项。默认情况下，缓存处于禁用状态，但可以通过将参数 `cache` 设置为 `true` 来启用它。
 
 启用缓存后，`setup-go` 操作将在存储库根目录中搜索依赖项文件 `go.sum`，并使用依赖项文件的哈希作为缓存密钥的一部分。
 
@@ -152,13 +152,13 @@ jobs:
           cache-dependency-path: subdir/go.sum
 ```
 
-如果有自定义要求或需要更精细的缓存控制，可以使用 [`cache` 操作](https://github.com/marketplace/actions/cache)。 有关详细信息，请参阅“[缓存依赖项以加快工作流](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)”。
+如果有自定义要求或需要更精细的缓存控制，可以使用 [`cache` 操作](https://github.com/marketplace/actions/cache)。有关详细信息，请参阅“[缓存依赖项以加快工作流](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)”。
 
 {% endif %}
 
 ## 构建和测试代码
 
-您可以使用与本地相同的命令来构建和测试代码。 此示例工作流演示如何在作业中使用 `go build` 和 `go test`：
+您可以使用与本地相同的命令来构建和测试代码。此示例工作流演示如何在作业中使用 `go build` 和 `go test`：
 
 ```yaml{:copy}
 name: Go
@@ -184,7 +184,7 @@ jobs:
 
 ## 将工作流数据打包为构件
 
-工作流程完成后，您可以上传产生的项目进行分析。 例如，您可能需要保存日志文件、核心转储、测试结果或屏幕截图。 以下示例演示如何使用 `upload-artifact` 操作上传测试结果。
+工作流程完成后，您可以上传产生的项目进行分析。例如，您可能需要保存日志文件、核心转储、测试结果或屏幕截图。以下示例演示如何使用 `upload-artifact` 操作上传测试结果。
 
 有关详细信息，请参阅“[将工作流数据存储为构件](/actions/using-workflows/storing-workflow-data-as-artifacts)”。
 
diff --git a/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-java-with-ant.md b/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-java-with-ant.md
index d0397ae3d979..7ca0fa8904f6 100644
--- a/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-java-with-ant.md
+++ b/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-java-with-ant.md
@@ -26,26 +26,26 @@ ms.locfileid: '145084729'
 
 ## 简介
 
-本指南介绍如何使用 Ant 构建系统为 Java 项目创建执行持续集成 (CI) 的工作流程。 您创建的工作流程将允许您查看拉取请求提交何时会在默认分支上导致构建或测试失败； 这个方法可帮助确保您的代码始终是健康的。 您可以扩展 CI 工作流程以从工作流程运行上传构件。
+本指南介绍如何使用 Ant 构建系统为 Java 项目创建执行持续集成 (CI) 的工作流程。您创建的工作流程将允许您查看拉取请求提交何时会在默认分支上导致构建或测试失败；这个方法可帮助确保您的代码始终是健康的。您可以扩展 CI 工作流程以从工作流程运行上传构件。
 
-{% ifversion ghae %} {% data reusables.actions.self-hosted-runners-software %} {% else %} {% data variables.product.prodname_dotcom %} 托管的运行器有一个带有预安装软件的工具缓存，其中包括 Java 开发工具包 (JDK) 和 Ant。 有关 JDK 和 Ant 的软件和预安装版本的列表，请参阅“[{% data variables.product.prodname_dotcom %} 托管的运行器规范](/actions/reference/specifications-for-github-hosted-runners/#supported-software)”。
+{% ifversion ghae %} {% data reusables.actions.self-hosted-runners-software %} {% else %} {% data variables.product.prodname_dotcom %} 托管的运行器有一个带有预安装软件的工具缓存，其中包括 Java 开发工具包 (JDK) 和 Ant。有关 JDK 和 Ant 的软件和预安装版本的列表，请参阅“[{% data variables.product.prodname_dotcom %} 托管的运行器规范](/actions/reference/specifications-for-github-hosted-runners/#supported-software)”。
 {% endif %}
 
 ## 先决条件
 
-您应该熟悉 YAML 和 {% data variables.product.prodname_actions %} 的语法。 有关详细信息，请参阅：
+您应该熟悉 YAML 和 {% data variables.product.prodname_actions %} 的语法。有关详细信息，请参阅：
 - “[{% data variables.product.prodname_actions %} 工作流语法](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions)”
 - “[了解 {% data variables.product.prodname_actions %}](/actions/learn-github-actions)”
 
-建议您对 Java 和 Ant 框架有个基本的了解。 有关详细信息，请参阅 [Apache Ant 手册](https://ant.apache.org/manual/)。
+建议您对 Java 和 Ant 框架有个基本的了解。有关详细信息，请参阅 [Apache Ant 手册](https://ant.apache.org/manual/)。
 
 {% data reusables.actions.enterprise-setup-prereq %}
 
 ## 使用 Ant 入门工作流程
 
-{% data variables.product.prodname_dotcom %} 提供有 Ant 入门工作流程，适用于大多数基于 Ant 的 Java 项目。 有关详细信息，请参阅 [Ant 入门工作流](https://github.com/actions/starter-workflows/blob/main/ci/ant.yml)。
+{% data variables.product.prodname_dotcom %} 提供有 Ant 入门工作流程，适用于大多数基于 Ant 的 Java 项目。有关详细信息，请参阅 [Ant 入门工作流](https://github.com/actions/starter-workflows/blob/main/ci/ant.yml)。
 
-要快速开始，您可以在创建新工作流程时选择预配置的 Ant 入门工作流程。 有关详细信息，请参阅“[{% data variables.product.prodname_actions %} 快速入门](/actions/quickstart)”。
+要快速开始，您可以在创建新工作流程时选择预配置的 Ant 入门工作流程。有关详细信息，请参阅“[{% data variables.product.prodname_actions %} 快速入门](/actions/quickstart)”。
 
 也可以通过在存储库的 `.github/workflows` 目录中创建新文件来手动添加此工作流。
 
@@ -85,9 +85,9 @@ jobs:
 
 您可以使用与本地相同的命令来构建和测试代码。
 
-入门工作流将运行“build.xml”文件中指定的默认目标。  默认目标通常设置为将类、运行测试和包类设置为其可分发格式，例如 JAR 文件。
+入门工作流将运行“build.xml”文件中指定的默认目标。默认目标通常设置为将类、运行测试和包类设置为其可分发格式，例如 JAR 文件。
 
-如果使用不同的命令来构建项目，或者想要运行不同的目标，则可以指定这些命令。 例如，你可能想要运行在 `_build-ci.xml_` 文件中配置的 `jar` 目标。
+如果使用不同的命令来构建项目，或者想要运行不同的目标，则可以指定这些命令。例如，你可能想要运行在 `_build-ci.xml_` 文件中配置的 `jar` 目标。
 
 ```yaml{:copy}
 steps:
@@ -102,9 +102,9 @@ steps:
 
 ## 将工作流数据打包为构件
 
-构建成功且测试通过后，您可能想要上传生成的 Java 包作为构件。 这会将构建的包存储为工作流程运行的一部分，并允许您下载它们。 构件可帮助您在拉取请求合并之前在本地环境中测试并调试它们。 有关详细信息，请参阅“[使用项目保留工作流数据](/actions/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)”。
+构建成功且测试通过后，您可能想要上传生成的 Java 包作为构件。这会将构建的包存储为工作流程运行的一部分，并允许您下载它们。构件可帮助您在拉取请求合并之前在本地环境中测试并调试它们。有关详细信息，请参阅“[使用项目保留工作流数据](/actions/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)”。
 
-Ant 通常会在 `build/jar` 目录中创建 JAR、EAR 或 WAR 等输出文件。 可以使用 `upload-artifact` 操作上传该目录的内容。
+Ant 通常会在 `build/jar` 目录中创建 JAR、EAR 或 WAR 等输出文件。可以使用 `upload-artifact` 操作上传该目录的内容。
 
 ```yaml{:copy}
 steps:
diff --git a/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-java-with-gradle.md b/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-java-with-gradle.md
index 008734967b88..ca53c9d62403 100644
--- a/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-java-with-gradle.md
+++ b/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-java-with-gradle.md
@@ -26,26 +26,26 @@ ms.locfileid: '147410441'
 
 ## 简介
 
-本指南介绍如何使用 Gradle 构建系统为 Java 项目创建执行持续集成 (CI) 的工作流程。 您创建的工作流程将允许您查看拉取请求提交何时会在默认分支上导致构建或测试失败； 这个方法可帮助确保您的代码始终是健康的。 你可以将 CI 工作流扩展到{% ifversion actions-caching %}缓存文件并{% endif %}从工作流运行上传项目。
+本指南介绍如何使用 Gradle 构建系统为 Java 项目创建执行持续集成 (CI) 的工作流程。您创建的工作流程将允许您查看拉取请求提交何时会在默认分支上导致构建或测试失败；这个方法可帮助确保您的代码始终是健康的。你可以将 CI 工作流扩展到{% ifversion actions-caching %}缓存文件并{% endif %}从工作流运行上传项目。
 
-{% ifversion ghae %} {% data reusables.actions.self-hosted-runners-software %} {% else %} {% data variables.product.prodname_dotcom %} 托管的运行器有一个带有预装软件的工具缓存，其中包括 Java 开发工具包 (JDK) 和 Gradle。 有关软件以及 JDK 和 Gradle 的预安装版本的列表，请参阅“[{% data variables.product.prodname_dotcom %} 托管的运行器规范](/actions/reference/specifications-for-github-hosted-runners/#supported-software)”。
+{% ifversion ghae %} {% data reusables.actions.self-hosted-runners-software %} {% else %} {% data variables.product.prodname_dotcom %} 托管的运行器有一个带有预装软件的工具缓存，其中包括 Java 开发工具包 (JDK) 和 Gradle。有关软件以及 JDK 和 Gradle 的预安装版本的列表，请参阅“[{% data variables.product.prodname_dotcom %} 托管的运行器规范](/actions/reference/specifications-for-github-hosted-runners/#supported-software)”。
 {% endif %}
 
 ## 先决条件
 
-您应该熟悉 YAML 和 {% data variables.product.prodname_actions %} 的语法。 有关详细信息，请参阅：
+您应该熟悉 YAML 和 {% data variables.product.prodname_actions %} 的语法。有关详细信息，请参阅：
 - “[{% data variables.product.prodname_actions %} 工作流语法](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions)”
 - “[了解 {% data variables.product.prodname_actions %}](/actions/learn-github-actions)”
 
-建议您对 Java 和 Gradle 框架有个基本的了解。 有关详细信息，请参阅 Gradle 文档中的“[入门](https://docs.gradle.org/current/userguide/getting_started.html)”。
+建议您对 Java 和 Gradle 框架有个基本的了解。有关详细信息，请参阅 Gradle 文档中的“[入门](https://docs.gradle.org/current/userguide/getting_started.html)”。
 
 {% data reusables.actions.enterprise-setup-prereq %}
 
 ## 使用 Gradle 入门工作流程
 
-{% data variables.product.prodname_dotcom %} 提供有 Gradle 入门工作流程，适用于大多数基于 Gradle 的 Java 项目。 有关详细信息，请参阅 [Gradle 入门工作流](https://github.com/actions/starter-workflows/blob/main/ci/gradle.yml)。
+{% data variables.product.prodname_dotcom %} 提供有 Gradle 入门工作流程，适用于大多数基于 Gradle 的 Java 项目。有关详细信息，请参阅 [Gradle 入门工作流](https://github.com/actions/starter-workflows/blob/main/ci/gradle.yml)。
 
-要快速开始，您可以在创建新工作流程时选择预配置的 Gradle 入门工作流程。 有关详细信息，请参阅“[{% data variables.product.prodname_actions %} 快速入门](/actions/quickstart)”。
+要快速开始，您可以在创建新工作流程时选择预配置的 Gradle 入门工作流程。有关详细信息，请参阅“[{% data variables.product.prodname_actions %} 快速入门](/actions/quickstart)”。
 
 也可以通过在存储库的 `.github/workflows` 目录中创建新文件来手动添加此工作流。
 
@@ -82,7 +82,7 @@ jobs:
 1. `checkout` 步骤在运行器上下载存储库的副本。
 2. `setup-java` 步骤通过 Adoptium 配置 Java 11 JDK。
 3. “验证 Gradle 包装器”步骤验证源树中存在的 Gradle Wrapper JAR 文件的校验和。
-4. “使用 Gradle 生成”步骤使用 Gradle 组织在 {% data variables.product.prodname_dotcom %} 上提供的 `gradle/gradle-build-action` 操作进行生成。 该操作负责调用 Gradle、收集结果以及在作业之间缓存状态。 有关详细信息，请参阅 [`gradle/gradle-build-action`](https://github.com/gradle/gradle-build-action)。
+4. “使用 Gradle 生成”步骤使用 Gradle 组织在 {% data variables.product.prodname_dotcom %} 上提供的 `gradle/gradle-build-action` 操作进行生成。该操作负责调用 Gradle、收集结果以及在作业之间缓存状态。有关详细信息，请参阅 [`gradle/gradle-build-action`](https://github.com/gradle/gradle-build-action)。
 
 在创建构建和测试工作流程时，默认入门工作流程是很好的起点，然后您可以自定义入门工作流程以满足项目的需求。
 
@@ -94,9 +94,9 @@ jobs:
 
 您可以使用与本地相同的命令来构建和测试代码。
 
-默认情况下，入门工作流将运行 `build` 任务。 在默认的 Gradle 配置中，此命令将下载依赖项、构建类别、运行测试并将类别打包为可分发格式，如 JAR 文件。
+默认情况下，入门工作流将运行 `build` 任务。在默认的 Gradle 配置中，此命令将下载依赖项、构建类别、运行测试并将类别打包为可分发格式，如 JAR 文件。
 
-如果使用不同的命令来构建项目，或者想要使用不同的任务，则可以指定这些命令。 例如，你可能想要运行在 ci.gradle 文件中配置的 `package` 任务。
+如果使用不同的命令来构建项目，或者想要使用不同的任务，则可以指定这些命令。例如，你可能想要运行在 ci.gradle 文件中配置的 `package` 任务。
 
 ```yaml{:copy}
 steps:
@@ -117,17 +117,17 @@ steps:
 
 ## 缓存依赖项
 
-可以缓存生成依赖项以加快工作流运行。 成功运行后，`gradle/gradle-build-action` 会缓存 Gradle 用户主目录的重要部分。 在将来的作业中，将还原缓存，这样就不需要重新编译构建脚本，也不需要从远程包存储库下载依赖项。
+可以缓存生成依赖项以加快工作流运行。成功运行后，`gradle/gradle-build-action` 会缓存 Gradle 用户主目录的重要部分。在将来的作业中，将还原缓存，这样就不需要重新编译构建脚本，也不需要从远程包存储库下载依赖项。
 
-使用 `gradle/gradle-build-action` 操作时，默认启用缓存。 有关详细信息，请参阅 [`gradle/gradle-build-action`](https://github.com/gradle/gradle-build-action#caching)。
+使用 `gradle/gradle-build-action` 操作时，默认启用缓存。有关详细信息，请参阅 [`gradle/gradle-build-action`](https://github.com/gradle/gradle-build-action#caching)。
 
 {% endif %}
 
 ## 将工作流数据打包为构件
 
-构建成功且测试通过后，您可能想要上传生成的 Java 包作为构件。 这会将构建的包存储为工作流程运行的一部分，并允许您下载它们。 构件可帮助您在拉取请求合并之前在本地环境中测试并调试它们。 有关详细信息，请参阅“[使用项目持久保存工作流数据](/actions/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)”。
+构建成功且测试通过后，您可能想要上传生成的 Java 包作为构件。这会将构建的包存储为工作流程运行的一部分，并允许您下载它们。构件可帮助您在拉取请求合并之前在本地环境中测试并调试它们。有关详细信息，请参阅“[使用项目持久保存工作流数据](/actions/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)”。
 
-Gradle 通常会在 `build/libs` 目录中创建 JAR、EAR 或 WAR 等输出文件。 可以使用 `upload-artifact` 操作上传该目录的内容。
+Gradle 通常会在 `build/libs` 目录中创建 JAR、EAR 或 WAR 等输出文件。可以使用 `upload-artifact` 操作上传该目录的内容。
 
 ```yaml{:copy}
 steps:
diff --git a/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-java-with-maven.md b/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-java-with-maven.md
index cd522935c18b..b05d31bf8b9d 100644
--- a/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-java-with-maven.md
+++ b/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-java-with-maven.md
@@ -26,26 +26,26 @@ ms.locfileid: '146179805'
 
 ## 简介
 
-本指南介绍如何使用 Maven 软件项目管理工具为 Java 项目创建执行持续集成 (CI) 的工作流程。 您创建的工作流程将允许您查看拉取请求提交何时会在默认分支上导致构建或测试失败； 这个方法可帮助确保您的代码始终是健康的。 你可以将 CI 工作流扩展到{% ifversion actions-caching %}缓存文件并且{% endif %}从工作流运行上传项目。
+本指南介绍如何使用 Maven 软件项目管理工具为 Java 项目创建执行持续集成 (CI) 的工作流程。您创建的工作流程将允许您查看拉取请求提交何时会在默认分支上导致构建或测试失败；这个方法可帮助确保您的代码始终是健康的。你可以将 CI 工作流扩展到{% ifversion actions-caching %}缓存文件并且{% endif %}从工作流运行上传项目。
 
-{% ifversion ghae %} {% data reusables.actions.self-hosted-runners-software %} {% else %} {% data variables.product.prodname_dotcom %} 托管的运行器有一个带有预安装软件的工具缓存，其中包括 Java 开发工具包 (JDK) 和 Maven。 有关软件以及 JDK 和 Maven 的预安装版本的列表，请参阅“[{% data variables.product.prodname_dotcom %} 托管的运行器规范](/actions/reference/specifications-for-github-hosted-runners/#supported-software)”。
+{% ifversion ghae %} {% data reusables.actions.self-hosted-runners-software %} {% else %} {% data variables.product.prodname_dotcom %} 托管的运行器有一个带有预安装软件的工具缓存，其中包括 Java 开发工具包 (JDK) 和 Maven。有关软件以及 JDK 和 Maven 的预安装版本的列表，请参阅“[{% data variables.product.prodname_dotcom %} 托管的运行器规范](/actions/reference/specifications-for-github-hosted-runners/#supported-software)”。
 {% endif %}
 
 ## 先决条件
 
-您应该熟悉 YAML 和 {% data variables.product.prodname_actions %} 的语法。 有关详细信息，请参阅：
+您应该熟悉 YAML 和 {% data variables.product.prodname_actions %} 的语法。有关详细信息，请参阅：
 - “[{% data variables.product.prodname_actions %} 工作流语法](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions)”
 - [了解 {% data variables.product.prodname_actions %}](/actions/learn-github-actions)
 
-建议您对 Java 和 Maven 框架有个基本的了解。 有关详细信息，请参阅 Maven 文档中的 [Maven 入门指南](http://maven.apache.org/guides/getting-started/index.html)。
+建议您对 Java 和 Maven 框架有个基本的了解。有关详细信息，请参阅 Maven 文档中的 [Maven 入门指南](http://maven.apache.org/guides/getting-started/index.html)。
 
 {% data reusables.actions.enterprise-setup-prereq %}
 
 ## 使用 Maven 入门工作流程
 
-{% data variables.product.prodname_dotcom %} 提供有 Maven 入门工作流程，适用于大多数基于 Maven 的 Java 项目。 有关详细信息，请参阅 [Maven 入门工作流](https://github.com/actions/starter-workflows/blob/main/ci/maven.yml)。
+{% data variables.product.prodname_dotcom %} 提供有 Maven 入门工作流程，适用于大多数基于 Maven 的 Java 项目。有关详细信息，请参阅 [Maven 入门工作流](https://github.com/actions/starter-workflows/blob/main/ci/maven.yml)。
 
-要快速开始，您可以在创建新工作流程时选择预配置的 Maven 入门工作流程。 有关详细信息，请参阅“[{% data variables.product.prodname_actions %} 快速入门](/actions/quickstart)”。
+要快速开始，您可以在创建新工作流程时选择预配置的 Maven 入门工作流程。有关详细信息，请参阅“[{% data variables.product.prodname_actions %} 快速入门](/actions/quickstart)”。
 
 也可以通过在存储库的 `.github/workflows` 目录中创建新文件来手动添加此工作流。
 
@@ -85,9 +85,9 @@ jobs:
 
 您可以使用与本地相同的命令来构建和测试代码。
 
-默认情况下，入门工作流将运行 `package` 目标。 在默认的 Maven 配置中，此命令将下载依赖项、构建类别、运行测试并将类别打包为可分发格式，如 JAR 文件。
+默认情况下，入门工作流将运行 `package` 目标。在默认的 Maven 配置中，此命令将下载依赖项、构建类别、运行测试并将类别打包为可分发格式，如 JAR 文件。
 
-如果使用不同的命令来构建项目，或者想要使用不同的目标，则可以指定这些命令。 例如，你可能想要运行在 pom-ci.xml 文件中配置的 `verify` 目标。
+如果使用不同的命令来构建项目，或者想要使用不同的目标，则可以指定这些命令。例如，你可能想要运行在 pom-ci.xml 文件中配置的 `verify` 目标。
 
 ```yaml{:copy}
 steps:
@@ -104,7 +104,7 @@ steps:
 
 ## 缓存依赖项
 
-您可以缓存依赖项来加快工作流程运行。 成功运行后，本地 Maven 存储库将存储在缓存中。 在未来的工作流程运行中，缓存将会恢复，因此不需要从远程 Maven 仓库下载依赖项。 可以简单地使用 [`setup-java` 操作](https://github.com/marketplace/actions/setup-java-jdk)缓存依赖项，也 可以使用 [`cache` 操作](https://github.com/actions/cache)进行自定义和更高级的配置。
+您可以缓存依赖项来加快工作流程运行。成功运行后，本地 Maven 存储库将存储在缓存中。在未来的工作流程运行中，缓存将会恢复，因此不需要从远程 Maven 仓库下载依赖项。可以简单地使用 [`setup-java` 操作](https://github.com/marketplace/actions/setup-java-jdk)缓存依赖项，也 可以使用 [`cache` 操作](https://github.com/actions/cache)进行自定义和更高级的配置。
 
 ```yaml{:copy}
 steps:
@@ -119,15 +119,15 @@ steps:
     run: mvn --batch-mode --update-snapshots verify
 ```
 
-此工作流程将保存本地 Maven 存储库的内容，该存储库位于运行器主目录的 `.m2` 目录。 缓存密钥将是 pom.xml 的哈希内容，因此更改 pom.xml 会使缓存失效 。
+此工作流程将保存本地 Maven 存储库的内容，该存储库位于运行器主目录的 `.m2` 目录。缓存密钥将是 pom.xml 的哈希内容，因此更改 pom.xml 会使缓存失效。
 
 {% endif %}
 
 ## 将工作流数据打包为构件
 
-构建成功且测试通过后，您可能想要上传生成的 Java 包作为构件。 这会将构建的包存储为工作流程运行的一部分，并允许您下载它们。 构件可帮助您在拉取请求合并之前在本地环境中测试并调试它们。 有关详细信息，请参阅“[使用工件持久保存工作流数据](/actions/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)”。
+构建成功且测试通过后，您可能想要上传生成的 Java 包作为构件。这会将构建的包存储为工作流程运行的一部分，并允许您下载它们。构件可帮助您在拉取请求合并之前在本地环境中测试并调试它们。有关详细信息，请参阅“[使用工件持久保存工作流数据](/actions/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)”。
 
-Maven 通常会在 `target` 目录中创建 JAR、EAR 或 WAR 等输出文件。 要将这些项目上传为构件，可以将它们复制到包含要上传的构件的新目录中。 例如，可创建一个名为 `staging` 的目录。 然后，可以使用 `upload-artifact` 操作上传该目录的内容。
+Maven 通常会在 `target` 目录中创建 JAR、EAR 或 WAR 等输出文件。要将这些项目上传为构件，可以将它们复制到包含要上传的构件的新目录中。例如，可创建一个名为 `staging` 的目录。然后，可以使用 `upload-artifact` 操作上传该目录的内容。
 
 ```yaml{:copy}
 steps:
diff --git a/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-net.md b/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-net.md
index 66c4796be867..ed45c31b7732 100644
--- a/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-net.md
+++ b/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-net.md
@@ -22,18 +22,18 @@ ms.locfileid: '147063616'
 
 本指南介绍如何构建、测试和发布 .NET 包。
 
-{% ifversion ghae %} 若要在 {% data variables.product.prodname_ghe_managed %} 上构建和测试 .NET 项目，需要 .NET Core SDK。 {% data reusables.actions.self-hosted-runners-software %} {% else %} {% data variables.product.prodname_dotcom %} 托管的运行器有一个带有预装软件的工具缓存，其中包括 .NET Core SDK。 有关最新软件和 .NET Core SDK 预安装版本的完整列表，请参阅[安装在 {% data variables.product.prodname_dotcom %} 托管的运行器上的软件](/actions/reference/specifications-for-github-hosted-runners)。
+{% ifversion ghae %} 若要在 {% data variables.product.prodname_ghe_managed %} 上构建和测试 .NET 项目，需要 .NET Core SDK。 {% data reusables.actions.self-hosted-runners-software %} {% else %} {% data variables.product.prodname_dotcom %} 托管的运行器有一个带有预装软件的工具缓存，其中包括 .NET Core SDK。有关最新软件和 .NET Core SDK 预安装版本的完整列表，请参阅[安装在 {% data variables.product.prodname_dotcom %} 托管的运行器上的软件](/actions/reference/specifications-for-github-hosted-runners)。
 {% endif %}
 
 ## 先决条件
 
-您应该已经熟悉 YAML 语法及其如何与 {% data variables.product.prodname_actions %} 结合使用。 有关详细信息，请参阅“[{% data variables.product.prodname_actions %} 的工作流语法](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions)”。
+您应该已经熟悉 YAML 语法及其如何与 {% data variables.product.prodname_actions %} 结合使用。有关详细信息，请参阅“[{% data variables.product.prodname_actions %} 的工作流语法](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions)”。
 
-建议您对 .NET Core SDK 有个基本的了解。 有关详细信息，请参阅 [.NET 入门](https://dotnet.microsoft.com/learn)。
+建议您对 .NET Core SDK 有个基本的了解。有关详细信息，请参阅 [.NET 入门](https://dotnet.microsoft.com/learn)。
 
 ## 使用 .NET 入门工作流程
 
-{% data variables.product.prodname_dotcom %} 提供有 .NET 入门工作流程，应适合大多数 .NET 项目，本指南包括演示如何自定义此入门工作流程的示例。 有关详细信息，请参阅 [.NET 起始工作流](https://github.com/actions/setup-dotnet)。
+{% data variables.product.prodname_dotcom %} 提供有 .NET 入门工作流程，应适合大多数 .NET 项目，本指南包括演示如何自定义此入门工作流程的示例。有关详细信息，请参阅 [.NET 起始工作流](https://github.com/actions/setup-dotnet)。
 
 若要快速开始，请将起始工作流添加到存储库的 `.github/workflows` 目录。
 
@@ -66,9 +66,9 @@ jobs:
 
 ## 指定 .NET 版本
 
-若要在 {% data variables.product.prodname_dotcom %} 托管的运行器上使用预安装的 .NET Core SDK 版本，请使用 `setup-dotnet` 操作。 此操作从每个运行器上的工具缓存中查找特定版本的 .NET，并将必要的二进制文件添加到 `PATH`。 这些更改将持续用于作业的其余部分。
+若要在 {% data variables.product.prodname_dotcom %} 托管的运行器上使用预安装的 .NET Core SDK 版本，请使用 `setup-dotnet` 操作。此操作从每个运行器上的工具缓存中查找特定版本的 .NET，并将必要的二进制文件添加到 `PATH`。这些更改将持续用于作业的其余部分。
 
-`setup-dotnet` 操作是 .NET 与 {% data variables.product.prodname_actions %} 结合使用时的推荐方式，因为它能确保不同运行器和不同版本的 .NET 行为一致。 如果使用自托管运行器，则必须安装 .NET 并将其添加到 `PATH`。 有关详细信息，请参阅 [`setup-dotnet`](https://github.com/marketplace/actions/setup-net-core-sdk) 一文。
+`setup-dotnet` 操作是 .NET 与 {% data variables.product.prodname_actions %} 结合使用时的推荐方式，因为它能确保不同运行器和不同版本的 .NET 行为一致。如果使用自托管运行器，则必须安装 .NET 并将其添加到 `PATH`。有关详细信息，请参阅 [`setup-dotnet`](https://github.com/marketplace/actions/setup-net-core-sdk) 一文。
 
 ### 使用多个 .NET 版本
 
@@ -98,7 +98,7 @@ jobs:
 
 ### 使用特定的 .NET 版本
 
-可以将作业配置为使用 .NET 的特定版本，例如 `3.1.3`。 或者，您也可以使用语义版本语法来获得最新的次要版本。 此示例使用 .NET 3 最新的次要版本。
+可以将作业配置为使用 .NET 的特定版本，例如 `3.1.3`。或者，您也可以使用语义版本语法来获得最新的次要版本。此示例使用 .NET 3 最新的次要版本。
 
 ```yaml
     - name: Setup .NET 3.x
@@ -110,7 +110,7 @@ jobs:
 
 ## 安装依赖关系
 
-{% data variables.product.prodname_dotcom %} 托管的运行器安装了 NuGet 软件包管理器。 在构建和测试代码之前，您可以使用 dotnet CLI 从 NuGet 软件包注册表安装依赖项。 例如，下面的 YAML 会安装 `Newtonsoft` 包。
+{% data variables.product.prodname_dotcom %} 托管的运行器安装了 NuGet 软件包管理器。在构建和测试代码之前，您可以使用 dotnet CLI 从 NuGet 软件包注册表安装依赖项。例如，下面的 YAML 会安装 `Newtonsoft` 包。
 
 ```yaml
 steps:
@@ -127,7 +127,7 @@ steps:
 
 ### 缓存依赖项
 
-可使用唯一的键来缓存 NuGet 依赖项，这样就可以通过 [`cache`](https://github.com/marketplace/actions/cache) 操作还原未来工作流的依赖项。 例如，下面的 YAML 会安装 `Newtonsoft` 包。
+可使用唯一的键来缓存 NuGet 依赖项，这样就可以通过 [`cache`](https://github.com/marketplace/actions/cache) 操作还原未来工作流的依赖项。例如，下面的 YAML 会安装 `Newtonsoft` 包。
 
 有关详细信息，请参阅“[缓存依赖项以加快工作流](/actions/guides/caching-dependencies-to-speed-up-workflows)”。
 
@@ -151,7 +151,7 @@ steps:
 
 {% note %}
 
-注意：根据依赖项的数量，使用依赖项缓存可能会更快。 有很多大型依赖项的项目应该能看到性能明显提升，因为下载所需的时间会缩短。 依赖项较少的项目可能看不到明显的性提升，甚至可能由于 NuGet 安装缓存依赖项的方式而看到性能略有下降。 性能因项目而异。
+注意：根据依赖项的数量，使用依赖项缓存可能会更快。有很多大型依赖项的项目应该能看到性能明显提升，因为下载所需的时间会缩短。依赖项较少的项目可能看不到明显的性提升，甚至可能由于 NuGet 安装缓存依赖项的方式而看到性能略有下降。性能因项目而异。
 
 {% endnote %}
 
@@ -159,7 +159,7 @@ steps:
 
 ## 构建和测试代码
 
-您可以使用与本地相同的命令来构建和测试代码。 此示例演示如何在作业中使用 `dotnet build` 和 `dotnet test`：
+您可以使用与本地相同的命令来构建和测试代码。此示例演示如何在作业中使用 `dotnet build` 和 `dotnet test`：
 
 ```yaml
 steps:
@@ -178,7 +178,7 @@ steps:
 
 ## 将工作流数据打包为构件
 
-工作流程完成后，您可以上传产生的项目进行分析。 例如，您可能需要保存日志文件、核心转储、测试结果或屏幕截图。 以下示例演示如何使用 `upload-artifact` 操作上传测试结果。
+工作流程完成后，您可以上传产生的项目进行分析。例如，您可能需要保存日志文件、核心转储、测试结果或屏幕截图。以下示例演示如何使用 `upload-artifact` 操作上传测试结果。
 
 有关详细信息，请参阅“[使用项目持久保存工作流数据](/github/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)”。
 
@@ -216,7 +216,7 @@ jobs:
 
 ## 发布到包注册表
 
-您可以配置工作流程在 CI 测试通过后将 .NET 包发布到包注册表。 您可以使用仓库机密来存储发布二进制文件所需的任何令牌或凭据。 以下示例使用 `dotnet core cli` 创建包并将其发布到 {% data variables.product.prodname_registry %}。
+您可以配置工作流程在 CI 测试通过后将 .NET 包发布到包注册表。您可以使用仓库机密来存储发布二进制文件所需的任何令牌或凭据。以下示例使用 `dotnet core cli` 创建包并将其发布到 {% data variables.product.prodname_registry %}。
 
 ```yaml
 name: Upload dotnet package
diff --git a/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-nodejs.md b/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-nodejs.md
index 2f4577a49703..188abd298e87 100644
--- a/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-nodejs.md
+++ b/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-nodejs.md
@@ -27,11 +27,11 @@ ms.locfileid: '146179021'
 
 ## 简介
 
-本指南介绍如何创建用来生成和测试 Node.js 代码的持续集成 (CI) 工作流程。 如果 CI 测试通过，您可能想要部署代码或发布包。
+本指南介绍如何创建用来生成和测试 Node.js 代码的持续集成 (CI) 工作流程。如果 CI 测试通过，您可能想要部署代码或发布包。
 
 ## 先决条件
 
-建议基本了解 Node.js、YAML、工作流程配置选项以及如何创建工作流程文件。 有关详细信息，请参阅：
+建议基本了解 Node.js、YAML、工作流程配置选项以及如何创建工作流程文件。有关详细信息，请参阅：
 
 - [了解 {% data variables.product.prodname_actions %}](/actions/learn-github-actions)
 - [Node.js 入门](https://nodejs.org/en/docs/guides/getting-started-guide/)
@@ -40,9 +40,9 @@ ms.locfileid: '146179021'
 
 ## 使用 Node.js 入门工作流程
 
-{% data variables.product.prodname_dotcom %} 提供有 Node.js 入门工作流程，该工作流程将适用于大多数 Node.js 项目。 本指南包含可用于自定义入门工作流程的 npm 和 Yarn 示例。 有关详细信息，请参阅 [Node.js 起始工作流](https://github.com/actions/starter-workflows/blob/main/ci/node.js.yml)。
+{% data variables.product.prodname_dotcom %} 提供有 Node.js 入门工作流程，该工作流程将适用于大多数 Node.js 项目。本指南包含可用于自定义入门工作流程的 npm 和 Yarn 示例。有关详细信息，请参阅 [Node.js 起始工作流](https://github.com/actions/starter-workflows/blob/main/ci/node.js.yml)。
 
-要快速入门，请将起始工作流添加到存储库的 `.github/workflows` 目录。 下面显示的工作流假定存储库的默认分支为 `main`。
+要快速入门，请将起始工作流添加到存储库的 `.github/workflows` 目录。下面显示的工作流假定存储库的默认分支为 `main`。
 
 ```yaml{:copy}
 name: Node.js CI
@@ -77,13 +77,13 @@ jobs:
 
 ## 指定 Node.js 版本
 
-指定 Node.js 版本的最简单方法是使用由 {% data variables.product.prodname_dotcom %} 提供的 `setup-node` 操作。 有关详细信息，请参阅“[`setup-node`](https://github.com/actions/setup-node/)”。
+指定 Node.js 版本的最简单方法是使用由 {% data variables.product.prodname_dotcom %} 提供的 `setup-node` 操作。有关详细信息，请参阅“[`setup-node`](https://github.com/actions/setup-node/)”。
 
-`setup-node` 操作将 Node.js 版本作为输入并在运行器上配置该版本。 此 `setup-node` 操作从每个运行器上的工具缓存中查找特定版本的 Node.js，并将必要的二进制文件添加到 `PATH`，这可继续用于作业的其余部分。 使用 `setup-node` 是 Node.js 与 {% data variables.product.prodname_actions %} 结合使用时的推荐方式，因为它能确保不同运行器和不同版本的 Node.js 行为一致。 如果使用自托管运行器，则必须安装 Node.js 并将其添加到 `PATH`。
+`setup-node` 操作将 Node.js 版本作为输入并在运行器上配置该版本。此 `setup-node` 操作从每个运行器上的工具缓存中查找特定版本的 Node.js，并将必要的二进制文件添加到 `PATH`，这可继续用于作业的其余部分。使用 `setup-node` 是 Node.js 与 {% data variables.product.prodname_actions %} 结合使用时的推荐方式，因为它能确保不同运行器和不同版本的 Node.js 行为一致。如果使用自托管运行器，则必须安装 Node.js 并将其添加到 `PATH`。
 
 入门工作流程包含一个矩阵策略：用四个 Node.js 版本 10.x、12.x、14.x 和 15.x 构建和测试代码， "x" 是一个通配符，与版本的最新次要版本和修补程序版本匹配。 `node-version` 数组中指定的每个 Node.js 版本都会创建一个运行相同步骤的作业。
 
-每个作业都可以使用 `matrix` 上下文访问矩阵 `node-version` 阵列中定义的值。 该 `setup-node` 操作使用上下文作为 `node-version` 输入。 `setup-node` 操作在构建和测试代码之前使用不同的 Node.js 版本配置每个作业。 有关矩阵策略和上下文的详细信息，请参阅“[{% data variables.product.prodname_actions %} 的工作流语法](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix)”和“[上下文](/actions/learn-github-actions/contexts)”。
+每个作业都可以使用 `matrix` 上下文访问矩阵 `node-version` 阵列中定义的值。该 `setup-node` 操作使用上下文作为 `node-version` 输入。 `setup-node` 操作在构建和测试代码之前使用不同的 Node.js 版本配置每个作业。有关矩阵策略和上下文的详细信息，请参阅“[{% data variables.product.prodname_actions %} 的工作流语法](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix)”和“[上下文](/actions/learn-github-actions/contexts)”。
 
 ```yaml{:copy}
 strategy:
@@ -135,13 +135,13 @@ jobs:
 
 ## 安装依赖关系
 
-{% data variables.product.prodname_dotcom %} 托管的运行器安装了 npm 和 Yarn 依赖项管理器。 在构建和测试代码之前，可以使用 npm 和 Yarn 在工作流程中安装依赖项。 Windows 和 Linux {% data variables.product.prodname_dotcom %} 托管的运行器也安装了 Grunt、Gulp 和 Bower。
+{% data variables.product.prodname_dotcom %} 托管的运行器安装了 npm 和 Yarn 依赖项管理器。在构建和测试代码之前，可以使用 npm 和 Yarn 在工作流程中安装依赖项。Windows 和 Linux {% data variables.product.prodname_dotcom %} 托管的运行器也安装了 Grunt、Gulp 和 Bower。
 
-{% ifversion actions-caching %}还可缓存依赖项来加快工作流的速度。 有关详细信息，请参阅“[缓存依赖项以加快工作流](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)”。{% endif %}
+{% ifversion actions-caching %}还可缓存依赖项来加快工作流的速度。有关详细信息，请参阅“[缓存依赖项以加快工作流](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)”。{% endif %}
 
 ### 使用 npm 的示例
 
-此示例安装 package.json 文件中定义的依赖项。 有关详细信息，请参阅 [`npm install`](https://docs.npmjs.com/cli/install)。
+此示例安装 package.json 文件中定义的依赖项。有关详细信息，请参阅 [`npm install`](https://docs.npmjs.com/cli/install)。
 
 ```yaml{:copy}
 steps:
@@ -154,7 +154,7 @@ steps:
   run: npm install
 ```
 
-使用 `npm ci` 安装 package-lock.json 或 npm-shrinkwraw.json 文件中的版本并阻止对锁定文件的更新 。 使用 `npm ci` 通常比运行 `npm install` 更快。 有关详细信息，请参阅 [`npm ci`](https://docs.npmjs.com/cli/ci.html) 和“[引入 `npm ci` 以实现更快、更可靠的生成](https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable)”。
+使用 `npm ci` 安装 package-lock.json 或 npm-shrinkwraw.json 文件中的版本并阻止对锁定文件的更新。使用 `npm ci` 通常比运行 `npm install` 更快。有关详细信息，请参阅 [`npm ci`](https://docs.npmjs.com/cli/ci.html) 和“[引入 `npm ci` 以实现更快、更可靠的生成](https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable)”。
 
 ```yaml{:copy}
 steps:
@@ -169,7 +169,7 @@ steps:
 
 ### 使用 Yarn 的示例
 
-此示例安装 package.json 文件中定义的依赖项。 有关详细信息，请参阅 [`yarn install`](https://yarnpkg.com/en/docs/cli/install)。
+此示例安装 package.json 文件中定义的依赖项。有关详细信息，请参阅 [`yarn install`](https://yarnpkg.com/en/docs/cli/install)。
 
 ```yaml{:copy}
 steps:
@@ -199,11 +199,11 @@ steps:
 
 {% data reusables.actions.setup-node-intro %}
 
-要验证您的私有注册表，需要将 npm 身份验证令牌存储为密码。 例如，创建名为 `NPM_TOKEN` 的存储库机密。 有关详细信息，请参阅“[创建和使用已加密的机密](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)”。
+要验证您的私有注册表，需要将 npm 身份验证令牌存储为密码。例如，创建名为 `NPM_TOKEN` 的存储库机密。有关详细信息，请参阅“[创建和使用已加密的机密](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)”。
 
-在下面的示例中，机密 `NPM_TOKEN` 用于存储 npm 身份验证令牌。 `setup-node` 操作配置 .npmrc 文件从 `NODE_AUTH_TOKEN` 环境变量读取 npm 身份验证令牌。 使用 `setup-node` 操作创建 .npmrc 文件时，必须使用包含 npm 身份验证令牌的密码设置 `NODE_AUTH_TOKEN` 环境变量。
+在下面的示例中，机密 `NPM_TOKEN` 用于存储 npm 身份验证令牌。 `setup-node` 操作配置 .npmrc 文件从 `NODE_AUTH_TOKEN` 环境变量读取 npm 身份验证令牌。使用 `setup-node` 操作创建 .npmrc 文件时，必须使用包含 npm 身份验证令牌的密码设置 `NODE_AUTH_TOKEN` 环境变量。
 
-在安装依赖项之前，使用 `setup-node` 操作创建 .npmrc 文件。 该操作有两个输入参数。 `node-version` 参数设置 Node.js 版本，`registry-url` 参数设置默认注册表。 如果包注册表使用作用域，你必须使用 `scope` 参数。 有关详细信息，请参阅 [`npm-scope`](https://docs.npmjs.com/misc/scope)。
+在安装依赖项之前，使用 `setup-node` 操作创建 .npmrc 文件。该操作有两个输入参数。 `node-version` 参数设置 Node.js 版本，`registry-url` 参数设置默认注册表。如果包注册表使用作用域，你必须使用 `scope` 参数。有关详细信息，请参阅 [`npm-scope`](https://docs.npmjs.com/misc/scope)。
 
 ```yaml{:copy}
 steps:
@@ -281,13 +281,13 @@ steps:
 - run: pnpm test
 ```
 
-如果有自定义要求或需要更精细的缓存控制，可以使用 [`cache` 操作](https://github.com/marketplace/actions/cache)。 有关详细信息，请参阅“[缓存依赖项以加快工作流](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)”。
+如果有自定义要求或需要更精细的缓存控制，可以使用 [`cache` 操作](https://github.com/marketplace/actions/cache)。有关详细信息，请参阅“[缓存依赖项以加快工作流](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)”。
 
 {% endif %}
 
 ## 构建和测试代码
 
-您可以使用与本地相同的命令来构建和测试代码。 例如，如果你运行 `npm run build` 来运行 package.json 文件中定义的构建步骤，且运行 `npm test` 来运行测试套件，请在工作流文件中添加以下命令。
+您可以使用与本地相同的命令来构建和测试代码。例如，如果你运行 `npm run build` 来运行 package.json 文件中定义的构建步骤，且运行 `npm test` 来运行测试套件，请在工作流文件中添加以下命令。
 
 ```yaml{:copy}
 steps:
@@ -303,8 +303,8 @@ steps:
 
 ## 将工作流数据打包为构件
 
-您可以保存构建和测试步骤中的构件以在作业完成后查看。 例如，您可能需要保存日志文件、核心转储、测试结果或屏幕截图。 有关详细信息，请参阅“[使用项目持久保存工作流数据](/actions/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)”。
+您可以保存构建和测试步骤中的构件以在作业完成后查看。例如，您可能需要保存日志文件、核心转储、测试结果或屏幕截图。有关详细信息，请参阅“[使用项目持久保存工作流数据](/actions/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)”。
 
 ## 发布到包注册表
 
-您可以配置工作流程在 CI 测试通过后将 Node.js 包发布到包注册表。 有关发布到 npm 和 {% data variables.product.prodname_registry %} 的更多信息，请参阅“[发布 Node.js 包](/actions/automating-your-workflow-with-github-actions/publishing-nodejs-packages)”。
+您可以配置工作流程在 CI 测试通过后将 Node.js 包发布到包注册表。有关发布到 npm 和 {% data variables.product.prodname_registry %} 的更多信息，请参阅“[发布 Node.js 包](/actions/automating-your-workflow-with-github-actions/publishing-nodejs-packages)”。
diff --git a/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-powershell.md b/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-powershell.md
index ea515dfab90f..5e81edfe64a3 100644
--- a/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-powershell.md
+++ b/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-powershell.md
@@ -26,7 +26,7 @@ ms.locfileid: '146180213'
 
 ## 简介
 
-本指南演示如何将 PowerShell 用于 CI。 它介绍了如何使用 Pester、安装依赖项、测试模块以及发布到 PowerShell Gallery。
+本指南演示如何将 PowerShell 用于 CI。它介绍了如何使用 Pester、安装依赖项、测试模块以及发布到 PowerShell Gallery。
 
 {% data variables.product.prodname_dotcom %} 托管的运行器具有预安装了软件的工具缓存，包括 PowerShell 和 Pester。 
 
@@ -35,9 +35,9 @@ ms.locfileid: '146180213'
 
 ## 先决条件
 
-您应该熟悉 YAML 和 {% data variables.product.prodname_actions %} 的语法。 有关详细信息，请参阅“[了解 {% data variables.product.prodname_actions %}](/actions/learn-github-actions)”。
+您应该熟悉 YAML 和 {% data variables.product.prodname_actions %} 的语法。有关详细信息，请参阅“[了解 {% data variables.product.prodname_actions %}](/actions/learn-github-actions)”。
 
-建议您对 PowerShell 和 Pester 有个基本的了解。 有关详细信息，请参阅：
+建议您对 PowerShell 和 Pester 有个基本的了解。有关详细信息，请参阅：
 - [开始使用 PowerShell](https://docs.microsoft.com/powershell/scripting/learn/ps101/01-getting-started)
 - [Pester](https://pester.dev)
 
@@ -45,7 +45,7 @@ ms.locfileid: '146180213'
 
 ## 为 Pester 添加工作流程
 
-要使用 PowerShell 和 Pester 自动执行测试，您可以添加在每次将更改推送到仓库时运行的工作流程。 在以下示例中，`Test-Path` 用于检查名为 `resultsfile.log` 的文件是否存在。
+要使用 PowerShell 和 Pester 自动执行测试，您可以添加在每次将更改推送到仓库时运行的工作流程。在以下示例中，`Test-Path` 用于检查名为 `resultsfile.log` 的文件是否存在。
 
 必须将此示例工作流文件添加到存储库的 `.github/workflows/` 目录：
 
@@ -71,13 +71,13 @@ jobs:
 
 * `shell: pwsh` - 将作业配置为在运行 `run` 命令时使用 PowerShell。
 * `run: Test-Path resultsfile.log` - 检查存储库的根目录中是否存在名为 `resultsfile.log` 的文件。
-* `Should -Be $true` - 使用 Pester 定义预期结果。 如果结果是非预期的，则 {% data variables.product.prodname_actions %} 会将此标记为失败的测试。 例如：
+* `Should -Be $true` - 使用 Pester 定义预期结果。如果结果是非预期的，则 {% data variables.product.prodname_actions %} 会将此标记为失败的测试。例如：
 
   
   ![失败的 Pester 测试](/assets/images/help/repository/actions-failed-pester-test-updated.png)
   
 
-* `Invoke-Pester Unit.Tests.ps1 -Passthru` - 使用 Pester 执行在名为 `Unit.Tests.ps1` 的文件中定义的测试。 例如，若要执行上述相同的测试，`Unit.Tests.ps1` 将包含以下命令：
+* `Invoke-Pester Unit.Tests.ps1 -Passthru` - 使用 Pester 执行在名为 `Unit.Tests.ps1` 的文件中定义的测试。例如，若要执行上述相同的测试，`Unit.Tests.ps1` 将包含以下命令：
   ```
   Describe "Check results file is present" {
       It "Check results file is present" {
@@ -98,15 +98,15 @@ jobs:
 
 ## 安装依赖关系
 
-{% data variables.product.prodname_dotcom %} 托管的运行器安装了 PowerShell 7 和 Pester。 在生成和测试代码之前，可使用 `Install-Module` 从 PowerShell 库安装其他依赖项。
+{% data variables.product.prodname_dotcom %} 托管的运行器安装了 PowerShell 7 和 Pester。在生成和测试代码之前，可使用 `Install-Module` 从 PowerShell 库安装其他依赖项。
 
 {% note %}
 
-注意：由 {% data variables.product.prodname_dotcom %} 托管的运行器使用的预安装包（如 Pester）会定期更新，并且可能会引入重大更改。 因此，建议始终通过将 `Install-Module` 与 `-MaximumVersion` 结合使用来指定所需的包版本。
+注意：由 {% data variables.product.prodname_dotcom %} 托管的运行器使用的预安装包（如 Pester）会定期更新，并且可能会引入重大更改。因此，建议始终通过将 `Install-Module` 与 `-MaximumVersion` 结合使用来指定所需的包版本。
 
 {% endnote %}
 
-{% ifversion actions-caching %}你还可以缓存依赖项以加快工作流。 有关详细信息，请参阅“[缓存依赖项以加快工作流](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)”。{% endif %}
+{% ifversion actions-caching %}你还可以缓存依赖项以加快工作流。有关详细信息，请参阅“[缓存依赖项以加快工作流](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)”。{% endif %}
 
 例如，以下作业安装 `SqlServer` 和 `PSScriptAnalyzer` 模块：
 
@@ -126,7 +126,7 @@ jobs:
 
 {% note %}
 
-注意：默认情况下，PowerShell 不信任任何存储库。 从 PowerShell 库安装模块时，必须将 `PSGallery` 的安装策略显式设置为 `Trusted`。
+注意：默认情况下，PowerShell 不信任任何存储库。从 PowerShell 库安装模块时，必须将 `PSGallery` 的安装策略显式设置为 `Trusted`。
 
 {% endnote %}
 
@@ -134,9 +134,9 @@ jobs:
 
 ### 缓存依赖项
 
-可使用唯一的键来缓存 PowerShell 依赖项，这样就可以通过 [`cache`](https://github.com/marketplace/actions/cache) 操作还原未来工作流的依赖项。 有关详细信息，请参阅“[缓存依赖项以加快工作流](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)”。
+可使用唯一的键来缓存 PowerShell 依赖项，这样就可以通过 [`cache`](https://github.com/marketplace/actions/cache) 操作还原未来工作流的依赖项。有关详细信息，请参阅“[缓存依赖项以加快工作流](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)”。
 
-PowerShell 根据运行器的操作系统将其依赖项缓存在不同的位置。 例如，对于 Windows 操作系统，以下 Ubuntu 示例中使用的 `path` 位置将有所不同。
+PowerShell 根据运行器的操作系统将其依赖项缓存在不同的位置。例如，对于 Windows 操作系统，以下 Ubuntu 示例中使用的 `path` 位置将有所不同。
 
 ```yaml
 steps:
@@ -163,7 +163,7 @@ steps:
 
 ### 使用 PSScriptAnalyzer 链接代码
 
-以下示例安装 `PSScriptAnalyzer` 并使用它对存储库中的所有 `ps1` 文件执行 lint 操作。 有关详细信息，请参阅 [GitHub 上的 PSScriptAnalyzer](https://github.com/PowerShell/PSScriptAnalyzer)。
+以下示例安装 `PSScriptAnalyzer` 并使用它对存储库中的所有 `ps1` 文件执行 lint 操作。有关详细信息，请参阅 [GitHub 上的 PSScriptAnalyzer](https://github.com/PowerShell/PSScriptAnalyzer)。
 
 ```yaml
   lint-with-PSScriptAnalyzer:
@@ -191,9 +191,9 @@ steps:
 
 ## 将工作流数据打包为构件
 
-您可以在工作流程完成后上传构件以查看。 例如，您可能需要保存日志文件、核心转储、测试结果或屏幕截图。 有关详细信息，请参阅“[使用项目持久保存工作流数据](/github/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)”。
+您可以在工作流程完成后上传构件以查看。例如，您可能需要保存日志文件、核心转储、测试结果或屏幕截图。有关详细信息，请参阅“[使用项目持久保存工作流数据](/github/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)”。
 
-以下示例演示如何使用 `upload-artifact` 操作来存档从 `Invoke-Pester` 收到的测试结果。 有关详细信息，请参阅 [`upload-artifact` 操作](https://github.com/actions/upload-artifact)。
+以下示例演示如何使用 `upload-artifact` 操作来存档从 `Invoke-Pester` 收到的测试结果。有关详细信息，请参阅 [`upload-artifact` 操作](https://github.com/actions/upload-artifact)。
 
 ```yaml
 name: Upload artifact from Ubuntu
@@ -217,11 +217,11 @@ jobs:
     if: {% raw %}${{ always() }}{% endraw %}
 ```
 
-`always()` 函数将作业配置为即使存在测试失败也要继续处理。 有关详细信息，请参阅“[always](/actions/reference/context-and-expression-syntax-for-github-actions#always)”。
+`always()` 函数将作业配置为即使存在测试失败也要继续处理。有关详细信息，请参阅“[always](/actions/reference/context-and-expression-syntax-for-github-actions#always)”。
 
 ## 发布到 PowerShell Gallery
 
-您可以配置工作流程在 CI 测试通过时将 PowerShell 模块发布到 PowerShell Gallery。 您可以使用机密来存储发布软件包所需的任何令牌或凭据。 有关详细信息，请参阅“[创建和使用已加密的机密](/github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)”。
+您可以配置工作流程在 CI 测试通过时将 PowerShell 模块发布到 PowerShell Gallery。您可以使用机密来存储发布软件包所需的任何令牌或凭据。有关详细信息，请参阅“[创建和使用已加密的机密](/github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)”。
 
 以下示例创建一个包并使用 `Publish-Module` 将其发布到 PowerShell 库：
 
diff --git a/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-python.md b/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-python.md
index e71e398a1005..0f40c19cc16e 100644
--- a/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-python.md
+++ b/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-python.md
@@ -28,14 +28,14 @@ ms.locfileid: '147409465'
 
 本指南介绍如何构建、测试和发布 Python 包。
 
-{% ifversion ghae %} {% data reusables.actions.self-hosted-runners-software %} {% else %} {% data variables.product.prodname_dotcom %} 托管的运行器有一个带有预装软件的工具缓存，其中包括 Python 和 PyPy。 您无需安装任何项目！ 有关最新版软件以及 Python 和 PyPy 预安装版本的完整列表，请参阅“[{% data variables.product.prodname_dotcom %} 托管的运行器规范](/actions/reference/specifications-for-github-hosted-runners/#supported-software)”。
+{% ifversion ghae %} {% data reusables.actions.self-hosted-runners-software %} {% else %} {% data variables.product.prodname_dotcom %} 托管的运行器有一个带有预装软件的工具缓存，其中包括 Python 和 PyPy。您无需安装任何项目！有关最新版软件以及 Python 和 PyPy 预安装版本的完整列表，请参阅“[{% data variables.product.prodname_dotcom %} 托管的运行器规范](/actions/reference/specifications-for-github-hosted-runners/#supported-software)”。
 {% endif %}
 
 ## 先决条件
 
-您应该熟悉 YAML 和 {% data variables.product.prodname_actions %} 的语法。 有关详细信息，请参阅“[了解 {% data variables.product.prodname_actions %}](/actions/learn-github-actions)”。
+您应该熟悉 YAML 和 {% data variables.product.prodname_actions %} 的语法。有关详细信息，请参阅“[了解 {% data variables.product.prodname_actions %}](/actions/learn-github-actions)”。
 
-建议您对 Python、PyPy 和 pip 有个基本的了解。 有关详细信息，请参阅：
+建议您对 Python、PyPy 和 pip 有个基本的了解。有关详细信息，请参阅：
 - [Python 入门](https://www.python.org/about/gettingstarted/)
 - [PyPy](https://pypy.org/)
 - [Pip 包管理器](https://pypi.org/project/pip/)
@@ -44,7 +44,7 @@ ms.locfileid: '147409465'
 
 ## 使用 Python 入门工作流程
 
-{% data variables.product.prodname_dotcom %} 提供了一个适用于大多数 Python 项目的 Python 入门工作流程。 本指南包含可用于自定义入门工作流程的示例。 有关详细信息，请参阅 [Python 起始工作流](https://github.com/actions/starter-workflows/blob/main/ci/python-package.yml)。
+{% data variables.product.prodname_dotcom %} 提供了一个适用于大多数 Python 项目的 Python 入门工作流程。本指南包含可用于自定义入门工作流程的示例。有关详细信息，请参阅 [Python 起始工作流](https://github.com/actions/starter-workflows/blob/main/ci/python-package.yml)。
 
 若要快速开始，请将起始工作流添加到存储库的 `.github/workflows` 目录。
 
@@ -85,9 +85,9 @@ jobs:
 
 ## 指定 Python 版本
 
-若要在 {% data variables.product.prodname_dotcom %} 托管的运行器上使用 Python 或 PyPy 的预安装版本，请使用 `setup-python` 操作。 此操作从每个运行器上的工具缓存中查找特定版本的 Python 或 PyPy，并将必要的二进制文件添加到 `PATH`，这可继续用于作业的其余部分。 如果工具缓存中未预装特定版本的 Python，则 `setup-python` 操作将从 [`python-versions`](https://github.com/actions/python-versions) 存储库下载并设置适当的版本。
+若要在 {% data variables.product.prodname_dotcom %} 托管的运行器上使用 Python 或 PyPy 的预安装版本，请使用 `setup-python` 操作。此操作从每个运行器上的工具缓存中查找特定版本的 Python 或 PyPy，并将必要的二进制文件添加到 `PATH`，这可继续用于作业的其余部分。如果工具缓存中未预装特定版本的 Python，则 `setup-python` 操作将从 [`python-versions`](https://github.com/actions/python-versions) 存储库下载并设置适当的版本。
 
-使用 `setup-python` 是 Python 与 {% data variables.product.prodname_actions %} 结合使用时的推荐方式，因为它能确保不同运行器和不同版本的 Python 行为一致。 如果使用自托管运行器，则必须安装 Python 并将其添加到 `PATH`。 有关详细信息，请参阅 [`setup-python` 操作](https://github.com/marketplace/actions/setup-python)。
+使用 `setup-python` 是 Python 与 {% data variables.product.prodname_actions %} 结合使用时的推荐方式，因为它能确保不同运行器和不同版本的 Python 行为一致。如果使用自托管运行器，则必须安装 Python 并将其添加到 `PATH`。有关详细信息，请参阅 [`setup-python` 操作](https://github.com/marketplace/actions/setup-python)。
 
 下表描述了每个 {% data variables.product.prodname_dotcom %} 托管的运行器中工具缓存的位置。
 
@@ -97,9 +97,9 @@ jobs:
 |Python 工具缓存|`/opt/hostedtoolcache/Python/*`|`/Users/runner/hostedtoolcache/Python/*`|`C:\hostedtoolcache\windows\Python\*`|
 |PyPy 工具缓存|`/opt/hostedtoolcache/PyPy/*`|`/Users/runner/hostedtoolcache/PyPy/*`|`C:\hostedtoolcache\windows\PyPy\*`|
 
-如果使用的是自托管运行器，则可以将运行器配置为使用 `setup-python` 操作来管理依赖项。 有关详细信息，请参阅 `setup-python` 自述文件中的[将 setup-python 与自托管运行器结合使用](https://github.com/actions/setup-python#using-setup-python-with-a-self-hosted-runner)。
+如果使用的是自托管运行器，则可以将运行器配置为使用 `setup-python` 操作来管理依赖项。有关详细信息，请参阅 `setup-python` 自述文件中的[将 setup-python 与自托管运行器结合使用](https://github.com/actions/setup-python#using-setup-python-with-a-self-hosted-runner)。
 
-{% data variables.product.prodname_dotcom %} 支持语义版本控制语法。 有关详细信息，请参阅“[使用语义版本控制](https://docs.npmjs.com/about-semantic-versioning#using-semantic-versioning-to-specify-update-types-your-package-can-accept)”和“[语义版本控制规范](https://semver.org/)”。
+{% data variables.product.prodname_dotcom %} 支持语义版本控制语法。有关详细信息，请参阅“[使用语义版本控制](https://docs.npmjs.com/about-semantic-versioning#using-semantic-versioning-to-specify-update-types-your-package-can-accept)”和“[语义版本控制规范](https://semver.org/)”。
 
 ### 使用多个 Python 版本
 
@@ -131,7 +131,7 @@ jobs:
 
 ### 使用特定的 Python 版本
 
-您可以配置 python 的特定版本。 例如，3.9。 或者，您也可以使用语义版本语法来获得最新的次要版本。 此示例使用 Python 3 最新的次要版本。
+您可以配置 python 的特定版本。例如，3.9。或者，您也可以使用语义版本语法来获得最新的次要版本。此示例使用 Python 3 最新的次要版本。
 
 ```yaml{:copy}
 name: Python package
@@ -159,9 +159,9 @@ jobs:
 
 ### 排除版本
 
-如果指定的 Python 版本不可用，则 `setup-python` 将失败并出现错误，例如：`##[error]Version 3.4 with arch x64 not found`。 错误消息包含可用的版本。
+如果指定的 Python 版本不可用，则 `setup-python` 将失败并出现错误，例如：`##[error]Version 3.4 with arch x64 not found`。错误消息包含可用的版本。
 
-如果存在不想运行的 Python 配置，也可以在工作流中使用 `exclude` 关键字。 有关详细信息，请参阅“[{% data variables.product.prodname_actions %} 的工作流语法](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategy)”。
+如果存在不想运行的 Python 配置，也可以在工作流中使用 `exclude` 关键字。有关详细信息，请参阅“[{% data variables.product.prodname_actions %} 的工作流语法](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategy)”。
 
 ```yaml{:copy}
 name: Python package
@@ -185,19 +185,19 @@ jobs:
 
 ### 使用默认 Python 版本
 
-建议使用 `setup-python` 来配置工作流中使用的 Python 版本，因为它有助于明确依赖项。 如果不使用 `setup-python`，当调用 `python` 时，将在任何 shell 中使用 `PATH` 中设置的默认 Python 版本。 {% data variables.product.prodname_dotcom %} 托管的运行器之间有不同的 Python 默认版本，这可能导致非预期的更改或使用的版本比预期更旧。
+建议使用 `setup-python` 来配置工作流中使用的 Python 版本，因为它有助于明确依赖项。如果不使用 `setup-python`，当调用 `python` 时，将在任何 shell 中使用 `PATH` 中设置的默认 Python 版本。 {% data variables.product.prodname_dotcom %} 托管的运行器之间有不同的 Python 默认版本，这可能导致非预期的更改或使用的版本比预期更旧。
 
 | {% data variables.product.prodname_dotcom %} 托管的运行器 | 说明 |
 |----|----|
 | Ubuntu | Ubuntu 运行器在 `/usr/bin/python` 和 `/usr/bin/python3` 下安装了多个版本的系统 Python。 {% data variables.product.prodname_dotcom %} 除了安装在工具缓存中的版本，还有与 Ubuntu 一起打包的 Python 版本。 |
-| Windows | 不包括工具缓存中的 Python 版本，Windows 未随附同等版本的系统 Python。 为保持与其他运行器一致的行为，并允许 Python 在没有 `setup-python` 操作的情况下开箱即用，{% data variables.product.prodname_dotcom %} 将从工具缓存中添加几个版本到 `PATH`。|
-| macOS | 除了作为工具缓存一部分的版本外，macOS 运行器还安装了多个版本的系统 Python。 系统 Python 版本位于 `/usr/local/Cellar/python/*` 目录中。 |
+| Windows | 不包括工具缓存中的 Python 版本，Windows 未随附同等版本的系统 Python。为保持与其他运行器一致的行为，并允许 Python 在没有 `setup-python` 操作的情况下开箱即用，{% data variables.product.prodname_dotcom %} 将从工具缓存中添加几个版本到 `PATH`。|
+| macOS | 除了作为工具缓存一部分的版本外，macOS 运行器还安装了多个版本的系统 Python。系统 Python 版本位于 `/usr/local/Cellar/python/*` 目录中。 |
 
 ## 安装依赖关系
 
-{% data variables.product.prodname_dotcom %} 托管的运行器安装了 pip 软件包管理器。 在构建和测试代码之前，您可以使用 pip 从 PyPI 软件包注册表安装依赖项。 例如，下面的 YAML 安装或升级 `pip` 包安装程序以及 `setuptools` 和 `wheel` 包。
+{% data variables.product.prodname_dotcom %} 托管的运行器安装了 pip 软件包管理器。在构建和测试代码之前，您可以使用 pip 从 PyPI 软件包注册表安装依赖项。例如，下面的 YAML 安装或升级 `pip` 包安装程序以及 `setuptools` 和 `wheel` 包。
 
-{% ifversion actions-caching %}还可缓存依赖项来加快工作流的速度。 有关详细信息，请参阅“[缓存依赖项以加快工作流](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)”。{% endif %}
+{% ifversion actions-caching %}还可缓存依赖项来加快工作流的速度。有关详细信息，请参阅“[缓存依赖项以加快工作流](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)”。{% endif %}
 
 ```yaml{:copy}
 steps:
@@ -212,7 +212,7 @@ steps:
 
 ### 要求文件
 
-更新 `pip` 后，下一步通常是从 requirements.txt 安装依赖项。 有关详细信息，请参阅 [pip](https://pip.pypa.io/en/stable/cli/pip_install/#example-requirements-file)。
+更新 `pip` 后，下一步通常是从 requirements.txt 安装依赖项。有关详细信息，请参阅 [pip](https://pip.pypa.io/en/stable/cli/pip_install/#example-requirements-file)。
 
 ```yaml{:copy}
 steps:
@@ -246,9 +246,9 @@ steps:
 - run: pip test
 ```
 
-默认情况下，`setup-python` 操作将在整个存储库中搜索依赖项文件（对于 pip，该文件为 `requirements.txt`；对于 pipenv，文件为 `Pipfile.lock`；对于 poetry，则为 `poetry.lock`）。 有关详细信息，请参阅 `setup-python` README 中的“[缓存包依赖项](https://github.com/actions/setup-python#caching-packages-dependencies)”。
+默认情况下，`setup-python` 操作将在整个存储库中搜索依赖项文件（对于 pip，该文件为 `requirements.txt`；对于 pipenv，文件为 `Pipfile.lock`；对于 poetry，则为 `poetry.lock`）。有关详细信息，请参阅 `setup-python` README 中的“[缓存包依赖项](https://github.com/actions/setup-python#caching-packages-dependencies)”。
 
-如果有自定义要求或需要更精细的缓存控制，可以使用 [`cache` 操作](https://github.com/marketplace/actions/cache)。 Pip 根据运行器的操作系统将依赖项缓存在不同的位置。 您需要缓存的路径可能不同于上面的 Ubuntu 示例，具体取决于您使用的操作系统。 有关详细信息，请参阅 `cache` 操作存储库中的 [Python 缓存示例](https://github.com/actions/cache/blob/main/examples.md#python---pip)。
+如果有自定义要求或需要更精细的缓存控制，可以使用 [`cache` 操作](https://github.com/marketplace/actions/cache)。Pip 根据运行器的操作系统将依赖项缓存在不同的位置。您需要缓存的路径可能不同于上面的 Ubuntu 示例，具体取决于您使用的操作系统。有关详细信息，请参阅 `cache` 操作存储库中的 [Python 缓存示例](https://github.com/actions/cache/blob/main/examples.md#python---pip)。
 
 {% endif %}
 
@@ -258,7 +258,7 @@ steps:
 
 ### 使用 pytest 和 pytest-cov 测试
 
-此示例安装或升级 `pytest` 和 `pytest-cov`。 然后进行测试并以 JUnit 格式输出，而代码覆盖结果则以 Cobertura 输出。 有关详细信息，请参阅 [JUnit](https://junit.org/junit5/) 和 [Cobertura](https://cobertura.github.io/cobertura/)。
+此示例安装或升级 `pytest` 和 `pytest-cov`。然后进行测试并以 JUnit 格式输出，而代码覆盖结果则以 Cobertura 输出。有关详细信息，请参阅 [JUnit](https://junit.org/junit5/) 和 [Cobertura](https://cobertura.github.io/cobertura/)。
 
 ```yaml{:copy}
 steps:
@@ -280,7 +280,7 @@ steps:
 
 ### 使用 Flake8 嵌入代码
 
-以下示例安装或升级 `flake8` 并使用它对所有文件执行 lint 操作。 有关详细信息，请参阅 [Flake8](http://flake8.pycqa.org/en/latest/)。
+以下示例安装或升级 `flake8` 并使用它对所有文件执行 lint 操作。有关详细信息，请参阅 [Flake8](http://flake8.pycqa.org/en/latest/)。
 
 ```yaml{:copy}
 steps:
@@ -300,11 +300,11 @@ steps:
   continue-on-error: true
 ```
 
-Lint 分析步骤设置了 `continue-on-error: true`。 这可防止在嵌入步骤不成功时工作流程失败。 解决所有嵌入错误后，您可以删除此选项，以便工作流程捕获新问题。
+Lint 分析步骤设置了 `continue-on-error: true`。这可防止在嵌入步骤不成功时工作流程失败。解决所有嵌入错误后，您可以删除此选项，以便工作流程捕获新问题。
 
 ### 使用 tox 运行测试
 
-通过 {% data variables.product.prodname_actions %}，您可以使用 tox 运行测试并将工作分散到多个作业。 需要使用 `-e py` 选项调用 tox，以选择 `PATH` 中的 Python 版本，而不是指定特定版本。 有关详细信息，请参阅 [tox](https://tox.readthedocs.io/en/latest/)。
+通过 {% data variables.product.prodname_actions %}，您可以使用 tox 运行测试并将工作分散到多个作业。需要使用 `-e py` 选项调用 tox，以选择 `PATH` 中的 Python 版本，而不是指定特定版本。有关详细信息，请参阅 [tox](https://tox.readthedocs.io/en/latest/)。
 
 ```yaml{:copy}
 name: Python package
@@ -334,9 +334,9 @@ jobs:
 
 ## 将工作流数据打包为构件
 
-您可以在工作流程完成后上传构件以查看。 例如，您可能需要保存日志文件、核心转储、测试结果或屏幕截图。 有关详细信息，请参阅“[使用项目持久保存工作流数据](/github/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)”。
+您可以在工作流程完成后上传构件以查看。例如，您可能需要保存日志文件、核心转储、测试结果或屏幕截图。有关详细信息，请参阅“[使用项目持久保存工作流数据](/github/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)”。
 
-以下示例演示如何使用 `upload-artifact` 操作来存档运行 `pytest` 得到的测试结果。 有关详细信息，请参阅 [`upload-artifact` 操作](https://github.com/actions/upload-artifact)。
+以下示例演示如何使用 `upload-artifact` 操作来存档运行 `pytest` 得到的测试结果。有关详细信息，请参阅 [`upload-artifact` 操作](https://github.com/actions/upload-artifact)。
 
 ```yaml{:copy}
 name: Python package
@@ -375,9 +375,9 @@ jobs:
 
 ## 发布到包注册表
 
-您可以配置工作流程在 CI 测试通过后将 Python 包发布到包注册表。 本部分演示如何在每次[发布版本](/github/administering-a-repository/managing-releases-in-a-repository)时使用 {% data variables.product.prodname_actions %} 将包上传到 PyPI。 
+您可以配置工作流程在 CI 测试通过后将 Python 包发布到包注册表。本部分演示如何在每次[发布版本](/github/administering-a-repository/managing-releases-in-a-repository)时使用 {% data variables.product.prodname_actions %} 将包上传到 PyPI。 
 
-对于此示例，需要创建两个 [PyPI API 令牌](https://pypi.org/help/#apitoken)。 您可以使用机密来存储发布软件包所需的访问令牌或凭据。 有关详细信息，请参阅“[创建和使用已加密的机密](/github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)”。
+对于此示例，需要创建两个 [PyPI API 令牌](https://pypi.org/help/#apitoken)。您可以使用机密来存储发布软件包所需的访问令牌或凭据。有关详细信息，请参阅“[创建和使用已加密的机密](/github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)”。
 
 ```yaml{:copy}
 {% data reusables.actions.actions-not-certified-by-github-comment %}
diff --git a/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-ruby.md b/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-ruby.md
index 0e153f967bc5..d77382aa6e7e 100644
--- a/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-ruby.md
+++ b/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-ruby.md
@@ -24,20 +24,20 @@ ms.locfileid: '147408985'
 
 ## 简介
 
-本指南介绍如何创建用来生成和测试 Ruby 应用程序的持续集成 (CI) 工作流程。 如果 CI 测试通过，您可能想要部署代码或发布 gem。
+本指南介绍如何创建用来生成和测试 Ruby 应用程序的持续集成 (CI) 工作流程。如果 CI 测试通过，您可能想要部署代码或发布 gem。
 
 ## 先决条件
 
-建议基本了解 Ruby、YAML、工作流程配置选项以及如何创建工作流程文件。 有关详细信息，请参阅：
+建议基本了解 Ruby、YAML、工作流程配置选项以及如何创建工作流程文件。有关详细信息，请参阅：
 
 - [了解 {% data variables.product.prodname_actions %}](/actions/learn-github-actions)
 - [用 20 分钟的时间来了解 Ruby](https://www.ruby-lang.org/en/documentation/quickstart/)
 
 ## 使用 Ruby 入门工作流程
 
-{% data variables.product.prodname_dotcom %} 提供有 Ruby 入门工作流程，该工作流程将适用于大多数 Ruby 项目。 有关详细信息，请参阅 [Ruby 起始工作流](https://github.com/actions/starter-workflows/blob/master/ci/ruby.yml)。
+{% data variables.product.prodname_dotcom %} 提供有 Ruby 入门工作流程，该工作流程将适用于大多数 Ruby 项目。有关详细信息，请参阅 [Ruby 起始工作流](https://github.com/actions/starter-workflows/blob/master/ci/ruby.yml)。
 
-若要快速开始，请将起始工作流添加到存储库的 `.github/workflows` 目录。 下面显示的工作流假定存储库的默认分支为 `main`。
+若要快速开始，请将起始工作流添加到存储库的 `.github/workflows` 目录。下面显示的工作流假定存储库的默认分支为 `main`。
 
 ```yaml
 {% data reusables.actions.actions-not-certified-by-github-comment %}
@@ -71,7 +71,7 @@ jobs:
 
 ## 指定 Ruby 版本
 
-指定 Ruby 版本的最简单方法是使用 GitHub 上的 Ruby 组织提供的 `ruby/setup-ruby` 操作。 对于工作流中运行的每个作业，该操作会将任何受支持的 Ruby 版本添加到 `PATH`。 有关详细信息和可用的 Ruby 版本，请参阅 [`ruby/setup-ruby`](https://github.com/ruby/setup-ruby)。
+指定 Ruby 版本的最简单方法是使用 GitHub 上的 Ruby 组织提供的 `ruby/setup-ruby` 操作。对于工作流中运行的每个作业，该操作会将任何受支持的 Ruby 版本添加到 `PATH`。有关详细信息和可用的 Ruby 版本，请参阅 [`ruby/setup-ruby`](https://github.com/ruby/setup-ruby)。
 
 使用 Ruby 的 `ruby/setup-ruby` 操作是将 Ruby 与 GitHub Actions 结合使用的推荐方式，因为它能确保不同运行器和不同版本的 Ruby 行为一致。
 
@@ -91,7 +91,7 @@ steps:
 
 ## 使用多个版本的 Ruby 进行测试
 
-您可以添加矩阵策略，以在多个版本的 Ruby 上运行工作流程。 例如，您可以根据版本 3.1、3.0 和 2.7 的最新修补程序版本测试代码。
+您可以添加矩阵策略，以在多个版本的 Ruby 上运行工作流程。例如，您可以根据版本 3.1、3.0 和 2.7 的最新修补程序版本测试代码。
 
 {% raw %}
 ```yaml
@@ -101,7 +101,7 @@ strategy:
 ```
 {% endraw %}
 
-`ruby-version` 数组中指定的每个 Ruby 版本都会创建一个运行相同步骤的作业。 {% raw %}`${{ matrix.ruby-version }}`{% endraw %} 上下文用于访问当前作业的版本。 有关矩阵策略和上下文的详细信息，请参阅“[{% data variables.product.prodname_actions %} 的工作流语法](/actions/learn-github-actions/workflow-syntax-for-github-actions)”和“[上下文](/actions/learn-github-actions/contexts)”。
+`ruby-version` 数组中指定的每个 Ruby 版本都会创建一个运行相同步骤的作业。 {% raw %}`${{ matrix.ruby-version }}`{% endraw %} 上下文用于访问当前作业的版本。有关矩阵策略和上下文的详细信息，请参阅“[{% data variables.product.prodname_actions %} 的工作流语法](/actions/learn-github-actions/workflow-syntax-for-github-actions)”和“[上下文](/actions/learn-github-actions/contexts)”。
 
 包含矩阵策略的完整更新工作流程可能看起如下：
 
@@ -141,7 +141,7 @@ jobs:
 
 ## 使用 Bundler 安装依赖项
 
-`setup-ruby` 操作将自动安装捆绑程序。 版本由 `gemfile.lock` 文件决定。 如果您的锁定文件中没有版本，则会安装最新的兼容版本。
+`setup-ruby` 操作将自动安装捆绑程序。版本由 `gemfile.lock` 文件决定。如果您的锁定文件中没有版本，则会安装最新的兼容版本。
 
 ```yaml
 steps:
@@ -169,11 +169,11 @@ steps:
 ```
 {% endraw %}
 
-这将配置捆绑程序以将 gem 安装到 `vendor/cache`。 对于工作流的每次成功运行，此文件夹将由 {% data variables.product.prodname_actions %} 缓存，并重新下载用于后续的工作流运行。 gemfile.lock 和 Ruby 版本的哈希值用作缓存密钥。 如果安装任何新 Gem 或更改版本，缓存将失效，Bundler 将进行全新安装。
+这将配置捆绑程序以将 gem 安装到 `vendor/cache`。对于工作流的每次成功运行，此文件夹将由 {% data variables.product.prodname_actions %} 缓存，并重新下载用于后续的工作流运行。gemfile.lock 和 Ruby 版本的哈希值用作缓存密钥。如果安装任何新 Gem 或更改版本，缓存将失效，Bundler 将进行全新安装。
 
 不使用 setup-ruby 进行缓存
 
-为了更好地控制缓存，可以直接使用 `actions/cache` 操作。 有关详细信息，请参阅“[缓存依赖项以加快工作流](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)”。
+为了更好地控制缓存，可以直接使用 `actions/cache` 操作。有关详细信息，请参阅“[缓存依赖项以加快工作流](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)”。
 
 ```yaml
 steps:
@@ -189,7 +189,7 @@ steps:
     bundle install --jobs 4 --retry 3
 ```
 
-如果您使用的是矩阵构建，您将会想要在缓存密钥中包含矩阵变量。 例如，如果提供了针对不同 Ruby 版本 (`matrix.ruby-version`) 和不同操作系统 (`matrix.os`) 的矩阵策略，工作流步骤可能如下所示：
+如果您使用的是矩阵构建，您将会想要在缓存密钥中包含矩阵变量。例如，如果提供了针对不同 Ruby 版本 (`matrix.ruby-version`) 和不同操作系统 (`matrix.os`) 的矩阵策略，工作流步骤可能如下所示：
 
 ```yaml
 steps:
@@ -244,7 +244,7 @@ jobs:
 
 ## 嵌入代码
 
-以下示例安装 `rubocop` 并使用它对所有文件进行 lint 操作。 有关详细信息，请参阅 [RuboCop](https://github.com/rubocop-hq/rubocop)。 可以[配置 Rubocop](https://docs.rubocop.org/rubocop/configuration.html) 以决定具体的 Lint 分析规则。
+以下示例安装 `rubocop` 并使用它对所有文件进行 lint 操作。有关详细信息，请参阅 [RuboCop](https://github.com/rubocop-hq/rubocop)。可以[配置 Rubocop](https://docs.rubocop.org/rubocop/configuration.html) 以决定具体的 Lint 分析规则。
 
 ```yaml
 {% data reusables.actions.actions-not-certified-by-github-comment %}
@@ -272,7 +272,7 @@ jobs:
 
 您可以配置工作流程在 CI 测试通过时将 Ruby 包发布到您想要的任何包注册表。
 
-您可以使用仓库密码存储发布软件包所需的访问令牌或凭据。 以下示例创建包并将其发布到 `GitHub Package Registry` 和 `RubyGems`。
+您可以使用仓库密码存储发布软件包所需的访问令牌或凭据。以下示例创建包并将其发布到 `GitHub Package Registry` 和 `RubyGems`。
 
 ```yaml
 {% data reusables.actions.actions-not-certified-by-github-comment %}
diff --git a/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-swift.md b/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-swift.md
index 760f91df18d0..1bcaec229db1 100644
--- a/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-swift.md
+++ b/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-swift.md
@@ -26,17 +26,17 @@ ms.locfileid: '147408993'
 
 本指南介绍如何构建和测试 Swift 包。
 
-{% ifversion ghae %} 要在 {% data variables.product.prodname_ghe_managed %}上构建和测试 Swift 项目，需要必要的 Swift 依赖项。 {% data reusables.actions.self-hosted-runners-software %} {% else %}{% data variables.product.prodname_dotcom %} 托管的运行器带有预装软件的工具缓存，Ubuntu 和 macOS 运行器包括用于构建 Swift 包的依赖项。 有关最新软件和预安装版本的 Swift 和 Xcode 的完整列表，请参阅“[关于 GitHub 托管的运行器](/actions/using-github-hosted-runners/about-github-hosted-runners#supported-software)”。{% endif %}
+{% ifversion ghae %} 要在 {% data variables.product.prodname_ghe_managed %}上构建和测试 Swift 项目，需要必要的 Swift 依赖项。 {% data reusables.actions.self-hosted-runners-software %} {% else %}{% data variables.product.prodname_dotcom %} 托管的运行器带有预装软件的工具缓存，Ubuntu 和 macOS 运行器包括用于构建 Swift 包的依赖项。有关最新软件和预安装版本的 Swift 和 Xcode 的完整列表，请参阅“[关于 GitHub 托管的运行器](/actions/using-github-hosted-runners/about-github-hosted-runners#supported-software)”。{% endif %}
 
 ## 先决条件
 
-您应该已经熟悉 YAML 语法及其如何与 {% data variables.product.prodname_actions %} 结合使用。 有关详细信息，请参阅“[{% data variables.product.prodname_actions %} 的工作流语法](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions)”。
+您应该已经熟悉 YAML 语法及其如何与 {% data variables.product.prodname_actions %} 结合使用。有关详细信息，请参阅“[{% data variables.product.prodname_actions %} 的工作流语法](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions)”。
 
-我们建议您对 Swift 包有基本的了解。 有关详细信息，请参阅 Apple 开发人员文档中的“[Swift 包](https://developer.apple.com/documentation/swift_packages)”。
+我们建议您对 Swift 包有基本的了解。有关详细信息，请参阅 Apple 开发人员文档中的“[Swift 包](https://developer.apple.com/documentation/swift_packages)”。
 
 ## 使用 Swift 入门工作流程
 
-{% data variables.product.prodname_dotcom %} 提供有 Swift 入门工作流程，应适合大多数 Swift 项目，本指南包括演示如何自定义此入门工作流程的示例。 有关详细信息，请参阅 [Swift 入门工作流](https://github.com/actions/starter-workflows/blob/main/ci/swift.yml)。
+{% data variables.product.prodname_dotcom %} 提供有 Swift 入门工作流程，应适合大多数 Swift 项目，本指南包括演示如何自定义此入门工作流程的示例。有关详细信息，请参阅 [Swift 入门工作流](https://github.com/actions/starter-workflows/blob/main/ci/swift.yml)。
 
 若要快速入门，请将入门工作流添加到存储库的 `.github/workflows` 目录。
 
@@ -60,7 +60,7 @@ jobs:
 
 ## 指定 Swift 版本
 
-要在 {% data variables.product.prodname_dotcom %} 托管的运行器上使用特定的预安装 Swift 版本，请使用 `fwal/setup-swift` 操作。 此操作从运行器上的工具缓存中查找特定版本的 Swift，并将必要的二进制文件添加到 `PATH`。 这些更改将持续用于作业的其余部分。 有关详细信息，请参阅 [`fwal/setup-swift`](https://github.com/marketplace/actions/setup-swift) 操作。
+要在 {% data variables.product.prodname_dotcom %} 托管的运行器上使用特定的预安装 Swift 版本，请使用 `fwal/setup-swift` 操作。此操作从运行器上的工具缓存中查找特定版本的 Swift，并将必要的二进制文件添加到 `PATH`。这些更改将持续用于作业的其余部分。有关详细信息，请参阅 [`fwal/setup-swift`](https://github.com/marketplace/actions/setup-swift) 操作。
 
 如果使用自托管运行程序，则必须安装所需的 Swift 版本并将它们添加到 `PATH`。
 
@@ -117,7 +117,7 @@ steps:
 
 ## 构建和测试代码
 
-您可以使用与本地相同的命令来使用 Swift 构建和测试代码。 此示例演示如何在作业中使用 `swift build` 和 `swift test`：
+您可以使用与本地相同的命令来使用 Swift 构建和测试代码。此示例演示如何在作业中使用 `swift build` 和 `swift test`：
 
 ```yaml{:copy}
 steps:
diff --git a/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-xamarin-applications.md b/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-xamarin-applications.md
index bac55fd40260..b49da884bb7d 100644
--- a/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-xamarin-applications.md
+++ b/translations/zh-CN/content/actions/automating-builds-and-tests/building-and-testing-xamarin-applications.md
@@ -28,7 +28,7 @@ ms.locfileid: '147518926'
 
 ## 简介
 
-本指南介绍如何为 Xamarin 项目创建执行持续集成 (CI) 的工作流程。 您创建的工作流程将允许您查看拉取请求提交何时会在默认分支上导致构建或测试失败； 这个方法可帮助确保您的代码始终是健康的。
+本指南介绍如何为 Xamarin 项目创建执行持续集成 (CI) 的工作流程。您创建的工作流程将允许您查看拉取请求提交何时会在默认分支上导致构建或测试失败；这个方法可帮助确保您的代码始终是健康的。
 
 在 {% data variables.product.prodname_actions %} 托管的 macOS 运行器上有可用的 Xamarin SDK 版本的完整列表，请参阅文档：
 
@@ -39,7 +39,7 @@ ms.locfileid: '147518926'
 
 ## 先决条件
 
-建议基本了解 Xamarin、.NET Core SDK、YAML、工作流程配置选项以及如何创建工作流程文件。 有关详细信息，请参阅：
+建议基本了解 Xamarin、.NET Core SDK、YAML、工作流程配置选项以及如何创建工作流程文件。有关详细信息，请参阅：
 
 - “[{% data variables.product.prodname_actions %} 的工作流语法](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions)”
 - “[.NET 入门](https://dotnet.microsoft.com/learn)”
@@ -117,6 +117,6 @@ jobs:
 
 ## 指定 .NET 版本
 
-若要在 {% data variables.product.prodname_dotcom %} 托管的运行器上使用预安装的 .NET Core SDK 版本，请使用 `setup-dotnet` 操作。 此操作从每个运行器上的工具缓存中查找特定版本的 .NET，并将必要的二进制文件添加到 `PATH`。 这些更改将持续用于作业的其余部分。
+若要在 {% data variables.product.prodname_dotcom %} 托管的运行器上使用预安装的 .NET Core SDK 版本，请使用 `setup-dotnet` 操作。此操作从每个运行器上的工具缓存中查找特定版本的 .NET，并将必要的二进制文件添加到 `PATH`。这些更改将持续用于作业的其余部分。
  
-`setup-dotnet` 操作是 .NET 与 {% data variables.product.prodname_actions %} 结合使用时的推荐方式，因为它能确保不同运行器和不同版本的 .NET 行为一致。 如果使用自托管运行器，则必须安装 .NET 并将其添加到 `PATH`。 有关详细信息，请参阅 [`setup-dotnet`](https://github.com/marketplace/actions/setup-net-core-sdk) 操作。
+`setup-dotnet` 操作是 .NET 与 {% data variables.product.prodname_actions %} 结合使用时的推荐方式，因为它能确保不同运行器和不同版本的 .NET 行为一致。如果使用自托管运行器，则必须安装 .NET 并将其添加到 `PATH`。有关详细信息，请参阅 [`setup-dotnet`](https://github.com/marketplace/actions/setup-net-core-sdk) 操作。
diff --git a/translations/zh-CN/content/actions/creating-actions/about-custom-actions.md b/translations/zh-CN/content/actions/creating-actions/about-custom-actions.md
index 9870f4ff2ede..599c2ca43b0c 100644
--- a/translations/zh-CN/content/actions/creating-actions/about-custom-actions.md
+++ b/translations/zh-CN/content/actions/creating-actions/about-custom-actions.md
@@ -1,6 +1,6 @@
 ---
 title: 关于自定义操作
-intro: '操作是可以组合来创建作业和自定义工作流程的单个任务。 您可以创建自己的操作，或者使用和自定义 {% data variables.product.prodname_dotcom %} 社区分享的操作。'
+intro: '操作是可以组合来创建作业和自定义工作流程的单个任务。您可以创建自己的操作，或者使用和自定义 {% data variables.product.prodname_dotcom %} 社区分享的操作。'
 redirect_from:
   - /articles/about-actions
   - /github/automating-your-workflow-with-github-actions/about-actions
@@ -27,15 +27,15 @@ ms.locfileid: '147154571'
 
 ## 关于自定义操作
 
-您可以编写自定义代码来创建操作，以您喜欢的方式与仓库交互，包括使用 {% data variables.product.prodname_dotcom %} 的 API 以及任何公开的第三方 API 进行交互。 例如，操作可以发布 npm 模块、在创建紧急问题时发送短信提醒，或者部署可用于生产的代码。
+您可以编写自定义代码来创建操作，以您喜欢的方式与仓库交互，包括使用 {% data variables.product.prodname_dotcom %} 的 API 以及任何公开的第三方 API 进行交互。例如，操作可以发布 npm 模块、在创建紧急问题时发送短信提醒，或者部署可用于生产的代码。
 
-{% ifversion fpt or ghec %} 你可以编写自己的操作以用于工作流，或者与 {% data variables.product.prodname_dotcom %} 社区共享你创建的操作。 要与每个人共享您创建的操作，您的仓库必须是公共的。 {% ifversion internal-actions %}若要仅在企业内共享操作，存储库必须是内部的。{% endif %} {% endif %}
+{% ifversion fpt or ghec %} 你可以编写自己的操作以用于工作流，或者与 {% data variables.product.prodname_dotcom %} 社区共享你创建的操作。要与每个人共享您创建的操作，您的仓库必须是公共的。 {% ifversion internal-actions %}若要仅在企业内共享操作，存储库必须是内部的。{% endif %} {% endif %}
 
-操作可以直接在计算机或 Docker 容器中运行。 您可以定义操作的输入、输出和环境变量。
+操作可以直接在计算机或 Docker 容器中运行。您可以定义操作的输入、输出和环境变量。
 
 ## 操作的类型
 
-您可以创建 Docker 容器和 JavaScript 操作。 操作需要元数据文件来定义操作的输入、输出和主要进入点。 元数据文件名必须为 `action.yml` 或 `action.yaml`。 有关详细信息，请参阅“[{% data variables.product.prodname_actions %} 的元数据语法](/articles/metadata-syntax-for-github-actions)”。
+您可以创建 Docker 容器和 JavaScript 操作。操作需要元数据文件来定义操作的输入、输出和主要进入点。元数据文件名必须为 `action.yml` 或 `action.yaml`。有关详细信息，请参阅“[{% data variables.product.prodname_actions %} 的元数据语法](/articles/metadata-syntax-for-github-actions)”。
 
 | 类型 | 操作系统 |
 | ---- | ------------------- |
@@ -45,38 +45,38 @@ ms.locfileid: '147154571'
 
 ### Docker 容器操作
 
-Docker 容器使用 {% data variables.product.prodname_actions %} 代码封装环境。 这会创建更加一致、可靠的工作单位，因为操作的使用者不需要担心工具或依赖项。
+Docker 容器使用 {% data variables.product.prodname_actions %} 代码封装环境。这会创建更加一致、可靠的工作单位，因为操作的使用者不需要担心工具或依赖项。
 
-Docker 容器允许使用特定版本的操作系统、依赖项、工具和代码。 对于必须在特定环境配置中运行的操作，Docker 是一个理想的选择，因为您可以自定义操作系统和工具。 由于创建和检索容器的延时，Docker 容器操作慢于 JavaScript 操作。
+Docker 容器允许使用特定版本的操作系统、依赖项、工具和代码。对于必须在特定环境配置中运行的操作，Docker 是一个理想的选择，因为您可以自定义操作系统和工具。由于创建和检索容器的延时，Docker 容器操作慢于 JavaScript 操作。
 
 Docker 容器操作只能在使用 Linux 操作系统的运行器上执行。 {% data reusables.actions.self-hosted-runner-reqs-docker %}
 
 ### JavaScript 操作
 
-JavaScript 操作可以直接在运行器计算机上运行，并将操作代码与用于运行代码的环境分开。 使用 JavaScript 操作可简化操作代码，执行速度快于 Docker 容器操作。
+JavaScript 操作可以直接在运行器计算机上运行，并将操作代码与用于运行代码的环境分开。使用 JavaScript 操作可简化操作代码，执行速度快于 Docker 容器操作。
 
 {% data reusables.actions.pure-javascript %}
 
-如果您正在开发 Node.js 项目，{% data variables.product.prodname_actions %} 工具包提供可用于项目中加速开发的软件包。 有关详细信息，请参阅 [actions/toolkit](https://github.com/actions/toolkit) 存储库。
+如果您正在开发 Node.js 项目，{% data variables.product.prodname_actions %} 工具包提供可用于项目中加速开发的软件包。有关详细信息，请参阅 [actions/toolkit](https://github.com/actions/toolkit) 存储库。
 
 ### 复合操作
 
-复合操作允许你在一个操作中组合多个工作流步骤。 例如，您可以使用此功能将多个运行命令捆绑到一个操作中，然后获得使用该操作在单一步骤中执行捆绑命令的工作流程。 若要查看示例，请查看“[创建复合操作](/actions/creating-actions/creating-a-composite-action)”。
+复合操作允许你在一个操作中组合多个工作流步骤。例如，您可以使用此功能将多个运行命令捆绑到一个操作中，然后获得使用该操作在单一步骤中执行捆绑命令的工作流程。若要查看示例，请查看“[创建复合操作](/actions/creating-actions/creating-a-composite-action)”。
 
 ## 选择操作的位置
 
-如果是开发供其他人使用的操作，我们建议将该操作保持在其自己的仓库中，而不是与其他应用程序代码一起捆绑。 这可让您管理操作版本以及跟踪和发行操作，就像任何其他软件一样。
+如果是开发供其他人使用的操作，我们建议将该操作保持在其自己的仓库中，而不是与其他应用程序代码一起捆绑。这可让您管理操作版本以及跟踪和发行操作，就像任何其他软件一样。
 
 {% ifversion fpt or ghec %} 将操作存储在其自己的存储库中更便于 {% data variables.product.prodname_dotcom %} 社区发现操作，缩小代码库范围以便开发者修复问题和扩展操作，以及从其他应用程序代码的版本解耦操作的版本。
 {% endif %}
 
 {% data reusables.actions.internal-actions-summary %}
 
-{% ifversion fpt or ghec %}如果创建不打算供他人使用的操作，您{% else %}您{% endif %}可以将操作的文件存储在您的仓库中的任何位置。 如果计划将操作、工作流和应用程序代码合并到一个存储库中，建议将操作存储在 `.github` 目录中。 例如，`.github/actions/action-a` 和 `.github/actions/action-b`。
+{% ifversion fpt or ghec %}如果创建不打算供他人使用的操作，您{% else %}您{% endif %}可以将操作的文件存储在您的仓库中的任何位置。如果计划将操作、工作流和应用程序代码合并到一个存储库中，建议将操作存储在 `.github` 目录中。例如，`.github/actions/action-a` 和 `.github/actions/action-b`。
 
 ## 与 {% data variables.product.prodname_ghe_server %} 的兼容性
 
-为了确保操作与 {% data variables.product.prodname_ghe_server %} 兼容，应确保不使用任何硬编码引用来引用 {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} API URL。 您应该改用环境变量来引用 {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} API：
+为了确保操作与 {% data variables.product.prodname_ghe_server %} 兼容，应确保不使用任何硬编码引用来引用 {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} API URL。您应该改用环境变量来引用 {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} API：
 
 - 对于 REST API，请使用 `GITHUB_API_URL` 环境变量。
 - 对于 GraphQL，请使用 `GITHUB_GRAPHQL_URL` 环境变量。
@@ -89,21 +89,21 @@ JavaScript 操作可以直接在运行器计算机上运行，并将操作代码
 
 ### 发行版管理的良好做法
 
-如果您正在开发供其他人使用的操作，建议使用发行版管理来控制分发更新的方式。 用户期望操作的补丁版本包括必要的关键修补程序和安全补丁，同时仍与其现有工作流程保持兼容。 每当更改影响兼容性时，应考虑发布新的主要版本。
+如果您正在开发供其他人使用的操作，建议使用发行版管理来控制分发更新的方式。用户期望操作的补丁版本包括必要的关键修补程序和安全补丁，同时仍与其现有工作流程保持兼容。每当更改影响兼容性时，应考虑发布新的主要版本。
 
-在此发行版管理方法下，用户不应引用操作的默认分支，因为它可能包含最新的代码，因此可能不稳定。 相反地，您可以建议用户在使用您的操作时指定主要版本，并且仅在遇到问题时将其定向到更具体的版本。
+在此发行版管理方法下，用户不应引用操作的默认分支，因为它可能包含最新的代码，因此可能不稳定。相反地，您可以建议用户在使用您的操作时指定主要版本，并且仅在遇到问题时将其定向到更具体的版本。
 
-要使用特定的操作版本，用户可以配置其 {% data variables.product.prodname_actions %} 工作流程定向标记、 提交的 SHA 或为发行版指定的分支。
+要使用特定的操作版本，用户可以配置其 {% data variables.product.prodname_actions %} 工作流程定向标记、提交的 SHA 或为发行版指定的分支。
 
 ### 使用标记进行发行版管理
 
-建议使用标记进行操作发行版管理。 使用这种方法，您的用户可以轻松地区分主要和次要版本：
+建议使用标记进行操作发行版管理。使用这种方法，您的用户可以轻松地区分主要和次要版本：
 
 - 创建发布标记（例如 `v1.0.2`）之前，创建并验证发布分支上的发布（例如 `release/v1`）。
-- 使用语义版本管理创建发行版。 有关详细信息，请参阅“[创建版本](/articles/creating-releases)”。
-- 移动主要版本标记（例如 `v1`、`v2`），以指向当前发布的 Git 引用。 有关详细信息，请参阅“[Git 基础知识 - 标记](https://git-scm.com/book/en/v2/Git-Basics-Tagging)“。
-- 针对破坏现有工作流的更改引入新的主要版本标记 (`v2`)。 例如，更改操作的输入就是破坏性的更改。
-- 主要版本最初发布时可以使用 `beta` 标记来指示其状态，例如 `v2-beta`。 准备就绪后，可以删除 `-beta` 标记。
+- 使用语义版本管理创建发行版。有关详细信息，请参阅“[创建版本](/articles/creating-releases)”。
+- 移动主要版本标记（例如 `v1`、`v2`），以指向当前发布的 Git 引用。有关详细信息，请参阅“[Git 基础知识 - 标记](https://git-scm.com/book/en/v2/Git-Basics-Tagging)“。
+- 针对破坏现有工作流的更改引入新的主要版本标记 (`v2`)。例如，更改操作的输入就是破坏性的更改。
+- 主要版本最初发布时可以使用 `beta` 标记来指示其状态，例如 `v2-beta`。准备就绪后，可以删除 `-beta` 标记。
 
 此示例演示用户如何引用主要发行版标记：
 
@@ -130,7 +130,7 @@ steps:
 
 ### 使用提交的 SHA 进行发行版管理
 
-每个 Git 提交都会收到一个计算出来的 SHA 值，该值是唯一且不可更改的。 您操作的用户可能更喜欢依赖提交的 SHA 值，因为此方法会比指定可删除或移动的标记更可靠。 但是，这意味着用户将不会收到对该操作所做的进一步更新。 必须使用提交的完整 SHA 值，而不是缩写值。
+每个 Git 提交都会收到一个计算出来的 SHA 值，该值是唯一且不可更改的。您操作的用户可能更喜欢依赖提交的 SHA 值，因为此方法会比指定可删除或移动的标记更可靠。但是，这意味着用户将不会收到对该操作所做的进一步更新。必须使用提交的完整 SHA 值，而不是缩写值。
 
 ```yaml
 steps:
@@ -139,7 +139,7 @@ steps:
 
 ## 为操作创建自述文件
 
-如果计划公开分享您的操作，建议创建自述文件以帮助人们了解如何使用您的操作。 可以将此信息包含在 `README.md` 中：
+如果计划公开分享您的操作，建议创建自述文件以帮助人们了解如何使用您的操作。可以将此信息包含在 `README.md` 中：
 
 - 操作的详细描述
 - 必要的输入和输出变量
@@ -150,7 +150,7 @@ steps:
 
 ## 比较 {% data variables.product.prodname_actions %}与 {% data variables.product.prodname_github_apps %}
 
-{% data variables.product.prodname_marketplace %} 提供用于改进工作流程的工具。 了解每种工具的差异和优势将使您能够选择最适合自己作业的工具。 有关构建应用的详细信息，请参阅“[关于应用](/apps/about-apps/)”。
+{% data variables.product.prodname_marketplace %} 提供用于改进工作流程的工具。了解每种工具的差异和优势将使您能够选择最适合自己作业的工具。有关构建应用的详细信息，请参阅“[关于应用](/apps/about-apps/)”。
 
 ### GitHub Actions 和 GitHub 应用程序的设置
 
diff --git a/translations/zh-CN/content/actions/creating-actions/creating-a-composite-action.md b/translations/zh-CN/content/actions/creating-actions/creating-a-composite-action.md
index 2e3abe41c709..2eb277f2202f 100644
--- a/translations/zh-CN/content/actions/creating-actions/creating-a-composite-action.md
+++ b/translations/zh-CN/content/actions/creating-actions/creating-a-composite-action.md
@@ -23,7 +23,7 @@ ms.locfileid: '145084710'
 
 ## 简介
 
-在本指南中，您将了解创建和使用打包的组合操作所需的基本组件。 本指南的重点是打包操作所需的组件，因此很少讲操作代码的功能。 该操作将依次打印 "Hello World" 和 "Goodbye"，如果您提供自定义名称，则将依次打印 "Hello [who-to-greet]" 和 "Goodbye"。 该操作还会将随机数映射到 `random-number` 输出变量，并运行名为 `goodbye.sh` 的脚本。
+在本指南中，您将了解创建和使用打包的组合操作所需的基本组件。本指南的重点是打包操作所需的组件，因此很少讲操作代码的功能。该操作将依次打印 "Hello World" 和 "Goodbye"，如果您提供自定义名称，则将依次打印 "Hello [who-to-greet]" 和 "Goodbye"。该操作还会将随机数映射到 `random-number` 输出变量，并运行名为 `goodbye.sh` 的脚本。
 
 完成此项目后，您应了解如何构建自己的组合操作和在工作流程测试该操作。
 
@@ -33,9 +33,9 @@ ms.locfileid: '145084710'
 
 在开始之前，您将在 {% ifversion ghae %}{% data variables.product.product_name %}{% else %}{% data variables.product.product_location %}{% endif %} 上创建一个存储库。
 
-1. 在 {% data variables.product.product_location %} 上创建公共仓库 可以选择任何存储库名称，或使用以下 `hello-world-composite-action` 示例。 您可以在项目推送到 {% data variables.product.product_name %} 之后添加这些文件。 有关详细信息，请参阅“[创建新存储库](/articles/creating-a-new-repository)”。
+1. 在 {% data variables.product.product_location %} 上创建公共仓库 可以选择任何存储库名称，或使用以下 `hello-world-composite-action` 示例。您可以在项目推送到 {% data variables.product.product_name %} 之后添加这些文件。有关详细信息，请参阅“[创建新存储库](/articles/creating-a-new-repository)”。
 
-1. 将仓库克隆到计算机。 有关详细信息，请参阅“[克隆存储库](/articles/cloning-a-repository)”。
+1. 将仓库克隆到计算机。有关详细信息，请参阅“[克隆存储库](/articles/cloning-a-repository)”。
 
 1. 从您的终端，将目录更改为新仓库。
 
@@ -64,7 +64,7 @@ ms.locfileid: '145084710'
 
 ## 创建操作元数据文件
 
-1. 在 `hello-world-composite-action` 存储库中，新建一个名为 `action.yml` 的文件，并添加以下示例代码。 有关此语法的详细信息，请参阅“[组合操作的 `runs`](/actions/creating-actions/metadata-syntax-for-github-actions#runs-for-composite-actions)”。
+1. 在 `hello-world-composite-action` 存储库中，新建一个名为 `action.yml` 的文件，并添加以下示例代码。有关此语法的详细信息，请参阅“[组合操作的 `runs`](/actions/creating-actions/metadata-syntax-for-github-actions#runs-for-composite-actions)”。
 
     {% raw %} action.yml
     ```yaml
@@ -92,7 +92,7 @@ ms.locfileid: '145084710'
         - run: goodbye.sh
           shell: bash
     ```
-    {% endraw %} 此文件定义 `who-to-greet` 输入，将随机生成的数字映射到 `random-number` 输出变量，并运行 `goodbye.sh` 脚本。 它还告诉运行器如何执行组合操作。
+    {% endraw %} 此文件定义 `who-to-greet` 输入，将随机生成的数字映射到 `random-number` 输出变量，并运行 `goodbye.sh` 脚本。它还告诉运行器如何执行组合操作。
 
   有关管理输出的详细信息，请参阅“[组合操作的 `outputs`](/actions/creating-actions/metadata-syntax-for-github-actions#outputs-for-composite-actions)”。
 
@@ -106,7 +106,7 @@ ms.locfileid: '145084710'
   git push
   ```
 
-1. 从终端添加标记。 本示例使用名为 `v1` 的标记。 有关详细信息，请参阅“[关于操作](/actions/creating-actions/about-actions#using-release-management-for-actions)”。
+1. 从终端添加标记。本示例使用名为 `v1` 的标记。有关详细信息，请参阅“[关于操作](/actions/creating-actions/about-actions#using-release-management-for-actions)”。
 
   ```shell
   git tag -a -m "Description of this release" v1
@@ -117,7 +117,7 @@ ms.locfileid: '145084710'
 
 以下工作流代码使用你在“[创建操作元数据文件](/actions/creating-actions/creating-a-composite-action#creating-an-action-metadata-file)”中完成的 hello world 操作。
 
-将工作流代码复制到另一个存储库中的 `.github/workflows/main.yml` 文件中，但将 `actions/hello-world-composite-action@v1` 替换为你创建的存储库和标记。 还可以将 `who-to-greet` 输入替换为你的名称。
+将工作流代码复制到另一个存储库中的 `.github/workflows/main.yml` 文件中，但将 `actions/hello-world-composite-action@v1` 替换为你创建的存储库和标记。还可以将 `who-to-greet` 输入替换为你的名称。
 
 .github/workflows/main.yml
 ```yaml
@@ -137,4 +137,4 @@ jobs:
         shell: bash
 ```
 
-从存储库中，单击“操作”选项卡，然后选择最新的工作流运行。 输出应包括："Hello Mona the Octocat"、"Goodbye" 脚本的结果以及随机数字。
+从存储库中，单击“操作”选项卡，然后选择最新的工作流运行。输出应包括："Hello Mona the Octocat"、"Goodbye" 脚本的结果以及随机数字。
diff --git a/translations/zh-CN/content/actions/creating-actions/creating-a-docker-container-action.md b/translations/zh-CN/content/actions/creating-actions/creating-a-docker-container-action.md
index 0ddda1a6c91d..f7ba5a0acde1 100644
--- a/translations/zh-CN/content/actions/creating-actions/creating-a-docker-container-action.md
+++ b/translations/zh-CN/content/actions/creating-actions/creating-a-docker-container-action.md
@@ -27,7 +27,7 @@ ms.locfileid: '147518782'
 
 ## 简介
 
-在本指南中，您将了解创建和使用打包的 Docker 容器操作所需的基本组件。 本指南的重点是打包操作所需的组件，因此很少讲操作代码的功能。 操作将在日志文件中打印“Hello World”或“Hello [who-to-greet]”（如果您提供自定义名称）。
+在本指南中，您将了解创建和使用打包的 Docker 容器操作所需的基本组件。本指南的重点是打包操作所需的组件，因此很少讲操作代码的功能。操作将在日志文件中打印“Hello World”或“Hello [who-to-greet]”（如果您提供自定义名称）。
 
 完成此项目后，您应了解如何构建自己的 Docker 容器操作和在工作流程测试该操作。
 
@@ -46,9 +46,9 @@ ms.locfileid: '147518782'
 
 在开始之前，您需要创建 {% data variables.product.prodname_dotcom %} 仓库。
 
-1. 在 {% data variables.product.product_location %} 上新建存储库。 您可以选择任何仓库名称或如本例一样使用“hello-world-docker-action”。 有关详细信息，请参阅“[创建新存储库](/articles/creating-a-new-repository)”。
+1. 在 {% data variables.product.product_location %} 上新建存储库。您可以选择任何仓库名称或如本例一样使用“hello-world-docker-action”。有关详细信息，请参阅“[创建新存储库](/articles/creating-a-new-repository)”。
 
-1. 将仓库克隆到计算机。 有关详细信息，请参阅“[克隆存储库](/articles/cloning-a-repository)”。
+1. 将仓库克隆到计算机。有关详细信息，请参阅“[克隆存储库](/articles/cloning-a-repository)”。
 
 1. 从您的终端，将目录更改为新仓库。
 
@@ -58,7 +58,7 @@ ms.locfileid: '147518782'
 
 ## 创建 Dockerfile
 
-在新的 `hello-world-docker-action` 目录中，创建一个新的 `Dockerfile` 文件。 如果你有问题，请确保你的文件名正确大写（使用大写字母 `D` 但不要大写 `f`）。 有关详细信息，请参阅“[{% data variables.product.prodname_actions %} 的 Dockerfile 支持](/actions/creating-actions/dockerfile-support-for-github-actions)”。
+在新的 `hello-world-docker-action` 目录中，创建一个新的 `Dockerfile` 文件。如果你有问题，请确保你的文件名正确大写（使用大写字母 `D` 但不要大写 `f`）。有关详细信息，请参阅“[{% data variables.product.prodname_actions %} 的 Dockerfile 支持](/actions/creating-actions/dockerfile-support-for-github-actions)”。
 
 **Dockerfile**
 ```Dockerfile{:copy}
@@ -74,7 +74,7 @@ ENTRYPOINT ["/entrypoint.sh"]
 
 ## 创建操作元数据文件
 
-在上面创建的 `hello-world-docker-action` 目录中创建一个新的 `action.yml` 文件。 有关详细信息，请参阅“[{% data variables.product.prodname_actions %} 的元数据语法](/actions/creating-actions/metadata-syntax-for-github-actions)”。
+在上面创建的 `hello-world-docker-action` 目录中创建一个新的 `action.yml` 文件。有关详细信息，请参阅“[{% data variables.product.prodname_actions %} 的元数据语法](/actions/creating-actions/metadata-syntax-for-github-actions)”。
 
 {% raw %} action.yml
 ```yaml{:copy}
@@ -97,15 +97,15 @@ runs:
 ```
 {% endraw %}
 
-此元数据定义一个 `who-to-greet` 输入和一个 `time` 输出参数。 若要将输入传递给 Docker 容器，应使用 `inputs` 声明输入并在 `args` 关键字中传递输入。 你包含在 `args` 中的所有内容都会传递给容器，但为了让用户更好地发现你的操作，建议使用输入。
+此元数据定义一个 `who-to-greet` 输入和一个 `time` 输出参数。若要将输入传递给 Docker 容器，应使用 `inputs` 声明输入并在 `args` 关键字中传递输入。你包含在 `args` 中的所有内容都会传递给容器，但为了让用户更好地发现你的操作，建议使用输入。
 
 {% data variables.product.prodname_dotcom %} 将从 `Dockerfile` 构建映像，然后使用此映像在新容器中运行命令。
 
 ## 编写操作代码
 
-您可以选择任何基础 Docker 映像，并因此为您的操作选择任何语言。 以下 shell 脚本示例使用 `who-to-greet` 输入变量在日志文件中打印“Hello [who-to-greet]”。
+您可以选择任何基础 Docker 映像，并因此为您的操作选择任何语言。以下 shell 脚本示例使用 `who-to-greet` 输入变量在日志文件中打印“Hello [who-to-greet]”。
 
-接下来，该脚本会获取当前时间并将其设置为作业中稍后运行的操作可以使用的输出变量。 为便于 {% data variables.product.prodname_dotcom %} 识别输出变量，必须以特定语法使用工作流命令：`echo "::set-output name=<output name>::<value>"`。 有关详细信息，请参阅“[{% data variables.product.prodname_actions %} 的工作流命令](/actions/reference/workflow-commands-for-github-actions#setting-an-output-parameter)”。
+接下来，该脚本会获取当前时间并将其设置为作业中稍后运行的操作可以使用的输出变量。为便于 {% data variables.product.prodname_dotcom %} 识别输出变量，必须以特定语法使用工作流命令：`echo "::set-output name=<output name>::<value>"`。有关详细信息，请参阅“[{% data variables.product.prodname_actions %} 的工作流命令](/actions/reference/workflow-commands-for-github-actions#setting-an-output-parameter)”。
 
 1. 在 `hello-world-docker-action` 目录中创建一个新的 `entrypoint.sh` 文件。
 
@@ -119,7 +119,7 @@ runs:
   time=$(date)
   echo "::set-output name=time::$time"
   ```
-  如果 `entrypoint.sh` 执行没有任何错误，则操作的状态设置为 `success`。 您还可以在操作的代码中显式设置退出代码以提供操作的状态。 有关详细信息，请参阅“[为操作设置退出代码](/actions/creating-actions/setting-exit-codes-for-actions)”。
+  如果 `entrypoint.sh` 执行没有任何错误，则操作的状态设置为 `success`。您还可以在操作的代码中显式设置退出代码以提供操作的状态。有关详细信息，请参阅“[为操作设置退出代码](/actions/creating-actions/setting-exit-codes-for-actions)”。
 
 1. 通过在系统上运行以下命令使 `entrypoint.sh` 文件可执行。
 
@@ -129,7 +129,7 @@ runs:
 
 ## 创建自述文件
 
-要让人们了解如何使用您的操作，您可以创建自述文件。 自述文件在您计划公开分享操作时最有用，但也是提醒您或您的团队如何使用该操作的绝佳方式。
+要让人们了解如何使用您的操作，您可以创建自述文件。自述文件在您计划公开分享操作时最有用，但也是提醒您或您的团队如何使用该操作的绝佳方式。
 
 在 `hello-world-docker-action` 目录中，创建一个用于指定以下信息的 `README.md` 文件：
 
@@ -169,7 +169,7 @@ with:
 
 从终端中提交 `action.yml`、`entrypoint.sh`、`Dockerfile` 和 `README.md` 文件。
 
-最佳做法是同时为操作版本添加版本标记。 有关对操作进行版本控制的详细信息，请参阅“[关于操作](/actions/automating-your-workflow-with-github-actions/about-actions#using-release-management-for-actions)”。
+最佳做法是同时为操作版本添加版本标记。有关对操作进行版本控制的详细信息，请参阅“[关于操作](/actions/automating-your-workflow-with-github-actions/about-actions#using-release-management-for-actions)”。
 
 ```shell{:copy}
 git add action.yml entrypoint.sh Dockerfile README.md
@@ -180,13 +180,13 @@ git push --follow-tags
 
 ## 在工作流程中测试您的操作
 
-现在，您已准备好在工作流程中测试您的操作。 当某项操作位于专用存储库中时，该操作只能在同一存储库的工作流中使用。 位于任何存储库内的工作流均可使用公共操作。
+现在，您已准备好在工作流程中测试您的操作。当某项操作位于专用存储库中时，该操作只能在同一存储库的工作流中使用。位于任何存储库内的工作流均可使用公共操作。
 
 {% data reusables.actions.enterprise-marketplace-actions %}
 
 ### 使用公共操作的示例
 
-以下工作流代码使用公共 [`actions/hello-world-docker-action`](https://github.com/actions/hello-world-docker-action) 存储库中已完成的 hello world 操作。 将以下工作流示例代码复制到 `.github/workflows/main.yml` 文件中，但将 `actions/hello-world-docker-action` 替换为存储库和操作名称。 还可以将 `who-to-greet` 输入替换为你的名称。 {% ifversion fpt or ghec %}公共操作即使未发布到 {% data variables.product.prodname_marketplace %} 也可使用。 有关详细信息，请参阅“[发布操作](/actions/creating-actions/publishing-actions-in-github-marketplace#publishing-an-action)”。 {% endif %}
+以下工作流代码使用公共 [`actions/hello-world-docker-action`](https://github.com/actions/hello-world-docker-action) 存储库中已完成的 hello world 操作。将以下工作流示例代码复制到 `.github/workflows/main.yml` 文件中，但将 `actions/hello-world-docker-action` 替换为存储库和操作名称。还可以将 `who-to-greet` 输入替换为你的名称。 {% ifversion fpt or ghec %}公共操作即使未发布到 {% data variables.product.prodname_marketplace %} 也可使用。有关详细信息，请参阅“[发布操作](/actions/creating-actions/publishing-actions-in-github-marketplace#publishing-an-action)”。 {% endif %}
 
 {% raw %} .github/workflows/main.yml
 ```yaml{:copy}
@@ -210,7 +210,7 @@ jobs:
 
 ### 使用私有操作的示例
 
-将以下示例工作流代码复制到操作存储库中的 `.github/workflows/main.yml` 文件中。 还可以将 `who-to-greet` 输入替换为你的名称。 {% ifversion fpt or ghec %}此操作不能发布到 {% data variables.product.prodname_marketplace %}，并且只能在此仓库中使用。{% endif %}
+将以下示例工作流代码复制到操作存储库中的 `.github/workflows/main.yml` 文件中。还可以将 `who-to-greet` 输入替换为你的名称。 {% ifversion fpt or ghec %}此操作不能发布到 {% data variables.product.prodname_marketplace %}，并且只能在此仓库中使用。{% endif %}
 
 .github/workflows/main.yml
 ```yaml{:copy}
@@ -235,7 +235,7 @@ jobs:
         run: echo "The time was {% raw %}${{ steps.hello.outputs.time }}"{% endraw %}
 ```
 
-从存储库中，单击“操作”选项卡，然后选择最新的工作流运行。 在“作业”下或可视化图中，单击“表示问候的作业” 。 应会看到“Hello Mona the Octocat”或你用于 `who-to-greet` 输入的名称以及日志中打印的时间戳。
+从存储库中，单击“操作”选项卡，然后选择最新的工作流运行。在“作业”下或可视化图中，单击“表示问候的作业” 。应会看到“Hello Mona the Octocat”或你用于 `who-to-greet` 输入的名称以及日志中打印的时间戳。
 
 ![在工作流中使用操作的屏幕截图](/assets/images/help/repository/docker-action-workflow-run-updated.png)
 
diff --git a/translations/zh-CN/content/actions/creating-actions/developing-a-third-party-cli-action.md b/translations/zh-CN/content/actions/creating-actions/developing-a-third-party-cli-action.md
index 6a814a12e3f4..f6ad7a129f81 100644
--- a/translations/zh-CN/content/actions/creating-actions/developing-a-third-party-cli-action.md
+++ b/translations/zh-CN/content/actions/creating-actions/developing-a-third-party-cli-action.md
@@ -28,17 +28,17 @@ ms.locfileid: '145086712'
 - 跨 {% data variables.product.product_name %} 托管和自托管运行器工作
 - 尽可能利用社区工具
 
-本文将演示如何编写一个操作来检索特定版本的 CLI、安装它、将其添加到路径以及（可选）缓存它。 这种类型的操作（设置工具的操作）通常命名为 `setup-$TOOL`。 
+本文将演示如何编写一个操作来检索特定版本的 CLI、安装它、将其添加到路径以及（可选）缓存它。这种类型的操作（设置工具的操作）通常命名为 `setup-$TOOL`。 
 
 ## 先决条件
 
-您应该了解如何编写自定义操作。 有关详细信息，请参阅“[关于自定义操作](/actions/creating-actions/about-custom-actions)”。 有关如何编写自定义操作的更详细指南，请参阅“[创建 JavaScript 操作](/actions/creating-actions/creating-a-javascript-action)”。
+您应该了解如何编写自定义操作。有关详细信息，请参阅“[关于自定义操作](/actions/creating-actions/about-custom-actions)”。有关如何编写自定义操作的更详细指南，请参阅“[创建 JavaScript 操作](/actions/creating-actions/creating-a-javascript-action)”。
 
 ## 示例
 
 以下脚本演示如何获取用户指定的版本作为输入，下载并提取 CLI 的特定版本，然后将 CLI 添加到路径中。
 
-{% data variables.product.prodname_dotcom %} 提供 [`actions/toolkit`](https://github.com/actions/toolkit)，这是一组可帮助你创建操作的包。 此示例使用 [`actions/core`](https://github.com/actions/toolkit/tree/main/packages/core) 和 [`actions/tool-cache`](https://github.com/actions/toolkit/tree/main/packages/tool-cache) 包。
+{% data variables.product.prodname_dotcom %} 提供 [`actions/toolkit`](https://github.com/actions/toolkit)，这是一组可帮助你创建操作的包。此示例使用 [`actions/core`](https://github.com/actions/toolkit/tree/main/packages/core) 和 [`actions/tool-cache`](https://github.com/actions/toolkit/tree/main/packages/tool-cache) 包。
 
 {% raw %}
 ```javascript{:copy}
@@ -63,13 +63,13 @@ module.exports = setup
 ```
 {% endraw %}
 
-若要使用此脚本，请将 `getDownloadURL` 替换为下载 CLI 的函数。 还需要创建一个接受 `version` 输入并运行此脚本的操作元数据文件 (`action.yml`)。 有关如何创建操作的完整详细信息，请参阅“[创建 JavaScript 操作](/actions/creating-actions/creating-a-javascript-action)”。
+若要使用此脚本，请将 `getDownloadURL` 替换为下载 CLI 的函数。还需要创建一个接受 `version` 输入并运行此脚本的操作元数据文件 (`action.yml`)。有关如何创建操作的完整详细信息，请参阅“[创建 JavaScript 操作](/actions/creating-actions/creating-a-javascript-action)”。
 
 有关如何设置此操作的完整示例，请参阅 [example-setup-gh](https://github.com/github-developer/example-setup-gh)。
 
 ## 延伸阅读
 
-此模式用于多个操作。 有关更多示例，请参阅：
+此模式用于多个操作。有关更多示例，请参阅：
 
 * [`ruby/setup-ruby`](https://github.com/ruby/setup-ruby)
 * [`google-github-actions/setup-gcloud`](https://github.com/google-github-actions/setup-gcloud)
diff --git a/translations/zh-CN/content/actions/creating-actions/dockerfile-support-for-github-actions.md b/translations/zh-CN/content/actions/creating-actions/dockerfile-support-for-github-actions.md
index 46bb9cac3a78..1119dbf49246 100644
--- a/translations/zh-CN/content/actions/creating-actions/dockerfile-support-for-github-actions.md
+++ b/translations/zh-CN/content/actions/creating-actions/dockerfile-support-for-github-actions.md
@@ -21,45 +21,45 @@ ms.locfileid: '145084707'
 
 ## 关于 Dockerfile 指令
 
-`Dockerfile` 包含用于定义 Docker 容器内容和启动行为的指令和参数。 有关 Docker 支持的指令的详细信息，请参阅 Docker 文档中的“[Dockerfile 参考](https://docs.docker.com/engine/reference/builder/)”。
+`Dockerfile` 包含用于定义 Docker 容器内容和启动行为的指令和参数。有关 Docker 支持的指令的详细信息，请参阅 Docker 文档中的“[Dockerfile 参考](https://docs.docker.com/engine/reference/builder/)”。
 
 ## Dockerfile 指令和覆盖
 
-某些 Docker 指令与 GitHub Actions 交互，操作的元数据文件可以覆盖某些 Docker 指令。 确保您熟悉 Dockerfile 如何与 {% data variables.product.prodname_actions %} 交互以防止任何意外行为。
+某些 Docker 指令与 GitHub Actions 交互，操作的元数据文件可以覆盖某些 Docker 指令。确保您熟悉 Dockerfile 如何与 {% data variables.product.prodname_actions %} 交互以防止任何意外行为。
 
 ### USER
 
-Docker 操作必须由默认 Docker 用户 (root) 运行。 不要在 `Dockerfile` 中使用 `USER` 指令，因为你将无法访问 `GITHUB_WORKSPACE`。 有关详细信息，请参阅 Docker 文档中的“[使用环境变量](/actions/configuring-and-managing-workflows/using-environment-variables)”和 [USER 参考](https://docs.docker.com/engine/reference/builder/#user)。
+Docker 操作必须由默认 Docker 用户 (root) 运行。不要在 `Dockerfile` 中使用 `USER` 指令，因为你将无法访问 `GITHUB_WORKSPACE`。有关详细信息，请参阅 Docker 文档中的“[使用环境变量](/actions/configuring-and-managing-workflows/using-environment-variables)”和 [USER 参考](https://docs.docker.com/engine/reference/builder/#user)。
 
 ### FROM
 
-`Dockerfile` 中的第一条指令必须为 `FROM`，该指令用于选择 Docker 基础映像。 有关详细信息，请参阅 Docker 文档中的 [FROM 参考](https://docs.docker.com/engine/reference/builder/#from)。
+`Dockerfile` 中的第一条指令必须为 `FROM`，该指令用于选择 Docker 基础映像。有关详细信息，请参阅 Docker 文档中的 [FROM 参考](https://docs.docker.com/engine/reference/builder/#from)。
 
 以下是设置 `FROM` 参数时的一些最佳做法：
 
-- 建议使用正式的 Docker 映像。 例如，`python` 或 `ruby`。
-- 使用版本标记（如果有），最好使用主要版本。 例如，请使用 `node:10` 而不是 `node:latest`。
+- 建议使用正式的 Docker 映像。例如，`python` 或 `ruby`。
+- 使用版本标记（如果有），最好使用主要版本。例如，请使用 `node:10` 而不是 `node:latest`。
 - 建议使用基于 [Debian](https://www.debian.org/) 操作系统的 Docker 映像。
 
 ### WORKDIR
 
-{% data variables.product.product_name %} 在 `GITHUB_WORKSPACE` 环境变量中设置工作目录路径。 建议不要在 `Dockerfile` 中使用 `WORKDIR` 指令。 在操作执行之前，{% data variables.product.product_name %} 将在 Docker 映像中位于该位置的任何项目上安装 `GITHUB_WORKSPACE` 目录，并将 `GITHUB_WORKSPACE` 设置为工作目录。 有关详细信息，请参阅 Docker 文档中的“[使用环境变量](/actions/configuring-and-managing-workflows/using-environment-variables)”和 [WORKDIR 参考](https://docs.docker.com/engine/reference/builder/#workdir)。
+{% data variables.product.product_name %} 在 `GITHUB_WORKSPACE` 环境变量中设置工作目录路径。建议不要在 `Dockerfile` 中使用 `WORKDIR` 指令。在操作执行之前，{% data variables.product.product_name %} 将在 Docker 映像中位于该位置的任何项目上安装 `GITHUB_WORKSPACE` 目录，并将 `GITHUB_WORKSPACE` 设置为工作目录。有关详细信息，请参阅 Docker 文档中的“[使用环境变量](/actions/configuring-and-managing-workflows/using-environment-variables)”和 [WORKDIR 参考](https://docs.docker.com/engine/reference/builder/#workdir)。
 
 ### ENTRYPOINT
 
-如果在操作的元数据文件中定义 `entrypoint`，它将替代 `Dockerfile` 中定义的 `ENTRYPOINT`。 有关详细信息，请参阅“[{% data variables.product.prodname_actions %} 的元数据语法](/actions/creating-actions/metadata-syntax-for-github-actions/#runsentrypoint)”。
+如果在操作的元数据文件中定义 `entrypoint`，它将替代 `Dockerfile` 中定义的 `ENTRYPOINT`。有关详细信息，请参阅“[{% data variables.product.prodname_actions %} 的元数据语法](/actions/creating-actions/metadata-syntax-for-github-actions/#runsentrypoint)”。
 
-Docker `ENTRYPOINT` 指令具有 shell 形式和 exec 形式 。 Docker `ENTRYPOINT` 文档建议使用 `ENTRYPOINT` 指令的 exec 形式。 有关 exec 和 shell 形式的详细信息，请参阅 Docker 文档中的 [ENTRYPOINT 参考](https://docs.docker.com/engine/reference/builder/#entrypoint) 。
+Docker `ENTRYPOINT` 指令具有 shell 形式和 exec 形式。Docker `ENTRYPOINT` 文档建议使用 `ENTRYPOINT` 指令的 exec 形式。有关 exec 和 shell 形式的详细信息，请参阅 Docker 文档中的 [ENTRYPOINT 参考](https://docs.docker.com/engine/reference/builder/#entrypoint) 。
 
-不应使用 `WORKDIR` 在 Dockerfile 中指定入口点。 而应使用绝对路径。 有关详细信息，请参阅 [WORKDIR](#workdir)。
+不应使用 `WORKDIR` 在 Dockerfile 中指定入口点。而应使用绝对路径。有关详细信息，请参阅 [WORKDIR](#workdir)。
 
-如果将容器配置为使用 `ENTRYPOINT` 指令的 exec 形式，则在操作的元数据文件中配置的 `args` 将不会在命令 shell 中运行。 如果操作的 `args` 包含环境变量，则不会替换该变量。 例如，使用以下 exec 格式将不会打印存储在 `$GITHUB_SHA` 中的值，而是会打印 `"$GITHUB_SHA"`。
+如果将容器配置为使用 `ENTRYPOINT` 指令的 exec 形式，则在操作的元数据文件中配置的 `args` 将不会在命令 shell 中运行。如果操作的 `args` 包含环境变量，则不会替换该变量。例如，使用以下 exec 格式将不会打印存储在 `$GITHUB_SHA` 中的值，而是会打印 `"$GITHUB_SHA"`。
 
 ```dockerfile
 ENTRYPOINT ["echo $GITHUB_SHA"]
 ```
 
- 如果需要变量替换，则可以使用 shell 形式或直接执行 shell。 例如，如果使用以下 exec 格式，可执行 shell 以打印存储在 `GITHUB_SHA` 环境变量中的值。
+ 如果需要变量替换，则可以使用 shell 形式或直接执行 shell。例如，如果使用以下 exec 格式，可执行 shell 以打印存储在 `GITHUB_SHA` 环境变量中的值。
 
 ```dockerfile
 ENTRYPOINT ["sh", "-c", "echo $GITHUB_SHA"]
@@ -82,7 +82,7 @@ ENTRYPOINT ["/entrypoint.sh"]
 
 #### 示例 entrypoint.sh 文件
 
-使用上面的示例 Dockerfile，{% data variables.product.product_name %} 会将在操作的元数据文件中配置的 `args` 以参数形式发送给 `entrypoint.sh`。 在 `entrypoint.sh` 文件的顶部添加 `#!/bin/sh` [shebang](https://en.wikipedia.org/wiki/Shebang_(Unix))，以显式地使用系统的与 [POSIX](https://en.wikipedia.org/wiki/POSIX) 兼容的 shell。
+使用上面的示例 Dockerfile，{% data variables.product.product_name %} 会将在操作的元数据文件中配置的 `args` 以参数形式发送给 `entrypoint.sh`。在 `entrypoint.sh` 文件的顶部添加 `#!/bin/sh` [shebang](https://en.wikipedia.org/wiki/Shebang_(Unix))，以显式地使用系统的与 [POSIX](https://en.wikipedia.org/wiki/POSIX) 兼容的 shell。
 
 ``` sh
 #!/bin/sh
@@ -92,7 +92,7 @@ ENTRYPOINT ["/entrypoint.sh"]
 sh -c "echo $*"
 ```
 
-您的代码必须是可执行的。 在工作流中使用 `entrypoint.sh` 文件之前，请确保该文件具有 `execute` 权限。 您可以使用此命令从终端修改权限：
+您的代码必须是可执行的。在工作流中使用 `entrypoint.sh` 文件之前，请确保该文件具有 `execute` 权限。您可以使用此命令从终端修改权限：
   ``` sh
   chmod +x entrypoint.sh
   ```
@@ -105,7 +105,7 @@ Error response from daemon: OCI runtime create failed: container_linux.go:348: s
 
 ### CMD
 
-如果在操作的元数据文件中定义 `args`，`args` 将替代 `Dockerfile` 中指定的 `CMD` 指令。 有关详细信息，请参阅“[{% data variables.product.prodname_actions %} 的元数据语法](/actions/creating-actions/metadata-syntax-for-github-actions#runsargs)”。
+如果在操作的元数据文件中定义 `args`，`args` 将替代 `Dockerfile` 中指定的 `CMD` 指令。有关详细信息，请参阅“[{% data variables.product.prodname_actions %} 的元数据语法](/actions/creating-actions/metadata-syntax-for-github-actions#runsargs)”。
 
 如果在 `Dockerfile` 中使用 `CMD`，请遵循以下准则：
 
@@ -113,4 +113,4 @@ Error response from daemon: OCI runtime create failed: container_linux.go:348: s
 
 ## 支持的 Linux 功能
 
-{% data variables.product.prodname_actions %} 支持 Docker 所支持的默认 Linux 功能。 无法添加或删除功能。 有关 Docker 支持的默认 Linux 功能的详细信息，请参阅 Docker 文档中的“[运行时权限和 Linux 功能](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities)”。 若要详细了解 Linux 功能，请参阅 Linux 手册页中的“[Linux 功能概述](http://man7.org/linux/man-pages/man7/capabilities.7.html)”。
+{% data variables.product.prodname_actions %} 支持 Docker 所支持的默认 Linux 功能。无法添加或删除功能。有关 Docker 支持的默认 Linux 功能的详细信息，请参阅 Docker 文档中的“[运行时权限和 Linux 功能](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities)”。若要详细了解 Linux 功能，请参阅 Linux 手册页中的“[Linux 功能概述](http://man7.org/linux/man-pages/man7/capabilities.7.html)”。
diff --git a/translations/zh-CN/content/actions/creating-actions/publishing-actions-in-github-marketplace.md b/translations/zh-CN/content/actions/creating-actions/publishing-actions-in-github-marketplace.md
index d5f5de6dca72..89e3e303dc2f 100644
--- a/translations/zh-CN/content/actions/creating-actions/publishing-actions-in-github-marketplace.md
+++ b/translations/zh-CN/content/actions/creating-actions/publishing-actions-in-github-marketplace.md
@@ -21,9 +21,9 @@ ms.locfileid: '147884299'
 
 ## 关于发布操作
 
-必须先在您的仓库中创建操作，然后才可发布操作。 有关详细信息，请参阅“[创建操作](/actions/creating-actions)”。
+必须先在您的仓库中创建操作，然后才可发布操作。有关详细信息，请参阅“[创建操作](/actions/creating-actions)”。
 
-计划发布操作到 {% data variables.product.prodname_marketplace %} 时， 您需要确保仓库仅包含该操作的元数据文件、代码和文件。 为操作创建单个仓库允许您在单一单元中标记、发布和打包代码。 {% data variables.product.prodname_dotcom %} 还使用 {% data variables.product.prodname_marketplace %} 页面上的操作元数据。
+计划发布操作到 {% data variables.product.prodname_marketplace %} 时，您需要确保仓库仅包含该操作的元数据文件、代码和文件。为操作创建单个仓库允许您在单一单元中标记、发布和打包代码。 {% data variables.product.prodname_dotcom %} 还使用 {% data variables.product.prodname_marketplace %} 页面上的操作元数据。
 
 操作立即发布到 {% data variables.product.prodname_marketplace %}，只要符合以下要求，就不会受到 {% data variables.product.prodname_dotcom %} 审查：
 
@@ -32,7 +32,7 @@ ms.locfileid: '147884299'
 - 操作的元数据文件（`action.yml` 或 `action.yaml`）必须位于存储库的根目录中。
 - 操作的元数据文件中的 `name` 必须是唯一的。
   - `name` 与 {% data variables.product.prodname_marketplace %} 上发布的现有操作名称不匹配。
-  - `name` 与 {% data variables.product.prodname_dotcom %} 上的用户或组织不匹配，除非用户或组织所有者正在发布操作。 例如，只有 {% data variables.product.prodname_dotcom %} 组织可以发布名为 `github` 的操作。
+  - `name` 与 {% data variables.product.prodname_dotcom %} 上的用户或组织不匹配，除非用户或组织所有者正在发布操作。例如，只有 {% data variables.product.prodname_dotcom %} 组织可以发布名为 `github` 的操作。
   - `name` 与现有的 {% data variables.product.prodname_marketplace %} 类别不匹配。
   - {% data variables.product.prodname_dotcom %} 将保留 {% data variables.product.prodname_dotcom %} 功能的名称。
 
@@ -43,25 +43,25 @@ ms.locfileid: '147884299'
 要草拟新发行版并将操作发布到 {% data variables.product.prodname_marketplace %}，请遵循以下说明：
 
 {% data reusables.repositories.navigate-to-repo %}
-1. 导航到存储库中的操作元数据文件（`action.yml` 或 `action.yaml`），将看到用于将操作发布到 {% data variables.product.prodname_marketplace %} 的横幅。 单击“草稿版本”。
+1. 导航到存储库中的操作元数据文件（`action.yml` 或 `action.yaml`），将看到用于将操作发布到 {% data variables.product.prodname_marketplace %} 的横幅。单击“草稿版本”。
 
    ![“将此操作发布到市场”按钮](/assets/images/help/repository/publish-github-action-to-marketplace-button.png)
-1. 在“发布操作”下，选中将操作发布到 {% data variables.product.prodname_marketplace %} 的复选框。 如果无法选中该复选框，则必须先单击链接以阅读并接受 {% data variables.product.prodname_marketplace %} 开发人员协议。
+1. 在“发布操作”下，选中将操作发布到 {% data variables.product.prodname_marketplace %} 的复选框。如果无法选中该复选框，则必须先单击链接以阅读并接受 {% data variables.product.prodname_marketplace %} 开发人员协议。
 ![选择发布到市场](/assets/images/help/repository/marketplace_actions_publish.png)
 1. 如果元数据文件中的标签包含任何问题，您将看到一条错误消息。
 ![查看通知](/assets/images/help/repository/marketplace_actions_fixerrors.png)
-1. 如果您看到任何屏幕上的建议，请通过更新元数据文件来解决这些问题。 完成后，你将看到“看起来一切正常!”消息 消息作为响应。
+1. 如果您看到任何屏幕上的建议，请通过更新元数据文件来解决这些问题。完成后，你将看到“看起来一切正常!”消息 消息作为响应。
 ![修复错误](/assets/images/help/repository/marketplace_actions_looksgood.png)
 1. 选择“Primary Category（主要类别）”，然后按需要选择“Another Category（另一个类别）”，这将有助于人们找到您的 {% data variables.product.prodname_marketplace %} 中的操作。
 ![选择类别](/assets/images/help/repository/marketplace_actions_categories.png)
-1. 使用版本标记操作，并添加发行版标题。 这有助于人们知道发行版包含哪些变化或特征。 人们将在操作的专门 {% data variables.product.prodname_marketplace %} 页面中看到版本。
+1. 使用版本标记操作，并添加发行版标题。这有助于人们知道发行版包含哪些变化或特征。人们将在操作的专门 {% data variables.product.prodname_marketplace %} 页面中看到版本。
 ![标记版本](/assets/images/help/repository/marketplace_actions_version.png)
-1. 完成所有其他字段，然后单击“发布版本”。 发布需要使用双重身份验证。 有关详细信息，请参阅“[双因素身份验证](/articles/configuring-two-factor-authentication/)”。
+1. 完成所有其他字段，然后单击“发布版本”。发布需要使用双重身份验证。有关详细信息，请参阅“[双因素身份验证](/articles/configuring-two-factor-authentication/)”。
 ![发布版本](/assets/images/help/repository/marketplace_actions_publishrelease.png)
 
 ## 从 {% data variables.product.prodname_marketplace %} 删除操作
 
-要从 {% data variables.product.prodname_marketplace %} 删除已发布的操作，您需要更新每个已发布的发行版。 对已发布到 {% data variables.product.prodname_marketplace %} 的操作的每个发行版执行以下步骤。
+要从 {% data variables.product.prodname_marketplace %} 删除已发布的操作，您需要更新每个已发布的发行版。对已发布到 {% data variables.product.prodname_marketplace %} 的操作的每个发行版执行以下步骤。
 
 {% data reusables.repositories.navigate-to-repo %} {% data reusables.repositories.releases %}
 3. 单击“版本”页上要编辑的版本右侧的“编辑”。
diff --git a/translations/zh-CN/content/actions/creating-actions/releasing-and-maintaining-actions.md b/translations/zh-CN/content/actions/creating-actions/releasing-and-maintaining-actions.md
index cdbce2340ffa..9cc681449469 100644
--- a/translations/zh-CN/content/actions/creating-actions/releasing-and-maintaining-actions.md
+++ b/translations/zh-CN/content/actions/creating-actions/releasing-and-maintaining-actions.md
@@ -23,7 +23,7 @@ ms.locfileid: '145066879'
 
 ## 简介
 
-创建操作后，您需要继续发布新功能，同时处理社区贡献。 本教程介绍了一个示例过程，您可以遵循该过程在开源中发布和维护操作。 示例：
+创建操作后，您需要继续发布新功能，同时处理社区贡献。本教程介绍了一个示例过程，您可以遵循该过程在开源中发布和维护操作。示例：
 
 * 利用 {% data variables.product.prodname_actions %} 实现持续集成、依赖项更新、版本管理和任务自动化。
 * 通过自动化测试和构建徽章提供信心。
@@ -38,9 +38,9 @@ ms.locfileid: '145066879'
 
 ### 关于 JavaScript 操作
 
-JavaScript 操作是具有元数据的 Node.js 存储库。 但是，与传统的 Node.js 项目相比，JavaScript 操作具有其他属性：
+JavaScript 操作是具有元数据的 Node.js 存储库。但是，与传统的 Node.js 项目相比，JavaScript 操作具有其他属性：
 
-* Dependent 包与代码一起提交，通常采用编译和缩小的形式。 这意味着自动化构建和安全的社区贡献非常重要。
+* Dependent 包与代码一起提交，通常采用编译和缩小的形式。这意味着自动化构建和安全的社区贡献非常重要。
 
 {% ifversion fpt or ghec %}
 
@@ -54,41 +54,41 @@ JavaScript 操作是具有元数据的 Node.js 存储库。 但是，与传统
 
 要在下一节中支持开发人员流程，请将两个 {% data variables.product.prodname_actions %} 工作流程添加到存储库中：
 
-1. 添加在将提交推送到功能分支或 `main` 或者创建拉取请求时触发的工作流。 配置工作流程以运行单元和集成测试。 有关示例，请参阅[此工作流](https://github.com/github-developer/javascript-action/blob/963a3b9a9c662fd499419a240ed8c49411ff5add/.github/workflows/test.yml)。
-2. 添加在发布或编辑发布时触发的工作流程。 配置工作流程以确保语义标记已就位。 可以使用 [JasonEtco/build-and-tag-action](https://github.com/JasonEtco/build-and-tag-action) 等操作来编译和捆绑 JavaScript 和元数据文件，并强制推送语义主要、次要和补丁标记。 有关示例，请参阅[此工作流](https://github.com/github-developer/javascript-action/blob/963a3b9a9c662fd499419a240ed8c49411ff5add/.github/workflows/publish.yml)。 有关语义标记的详细信息，请参阅“[关于语义版本控制](https://docs.npmjs.com/about-semantic-versioning)”。
+1. 添加在将提交推送到功能分支或 `main` 或者创建拉取请求时触发的工作流。配置工作流程以运行单元和集成测试。有关示例，请参阅[此工作流](https://github.com/github-developer/javascript-action/blob/963a3b9a9c662fd499419a240ed8c49411ff5add/.github/workflows/test.yml)。
+2. 添加在发布或编辑发布时触发的工作流程。配置工作流程以确保语义标记已就位。可以使用 [JasonEtco/build-and-tag-action](https://github.com/JasonEtco/build-and-tag-action) 等操作来编译和捆绑 JavaScript 和元数据文件，并强制推送语义主要、次要和补丁标记。有关示例，请参阅[此工作流](https://github.com/github-developer/javascript-action/blob/963a3b9a9c662fd499419a240ed8c49411ff5add/.github/workflows/publish.yml)。有关语义标记的详细信息，请参阅“[关于语义版本控制](https://docs.npmjs.com/about-semantic-versioning)”。
 
 ### 示例开发者流程
 
 下面是一个示例过程，您可以遵循该过程来自动运行测试、创建发行版{% ifversion fpt or ghec%}并发布到 {% data variables.product.prodname_marketplace %}{% endif %}，然后发布您的操作。
 
-1. 在每个 GitHub 流程的分支中执行功能工作。 有关详细信息，请参阅“[GitHub 流](/get-started/quickstart/github-flow)”。
+1. 在每个 GitHub 流程的分支中执行功能工作。有关详细信息，请参阅“[GitHub 流](/get-started/quickstart/github-flow)”。
    * 每当将提交推送到功能分支时，测试工作流程将自动运行测试。
 
 2. 创建对 `main` 分支的拉取请求以启动讨论和审查，并在准备就绪时合并。
 
    * 当从分支或复刻打开拉取请求时，测试工作流将再次运行测试，这次是合并提交。
 
-   * 注意：出于安全原因，由分支中的 `pull_request` 触发的工作流具有受限的 `GITHUB_TOKEN` 权限，并且无权访问机密。 如果拉取请求时触发的测试或其他工作流需要访问机密，请考虑使用不同的事件，例如[手动触发器](/actions/reference/events-that-trigger-workflows#manual-events)或 [`pull_request_target`](/actions/reference/events-that-trigger-workflows#pull_request_target)。 在[此处](/actions/reference/events-that-trigger-workflows#pull-request-events-for-forked-repositories)了解详细信息。
+   * 注意：出于安全原因，由分支中的 `pull_request` 触发的工作流具有受限的 `GITHUB_TOKEN` 权限，并且无权访问机密。如果拉取请求时触发的测试或其他工作流需要访问机密，请考虑使用不同的事件，例如[手动触发器](/actions/reference/events-that-trigger-workflows#manual-events)或 [`pull_request_target`](/actions/reference/events-that-trigger-workflows#pull_request_target)。在[此处](/actions/reference/events-that-trigger-workflows#pull-request-events-for-forked-repositories)了解详细信息。
 
 3. 创建语义标记的版本。 {% ifversion fpt or ghec %} 您也可以使用简单的复选框发布到 {% data variables.product.prodname_marketplace %}。 {% endif %} 有关详细信息，请参阅“[管理存储库中的版本](/github/administering-a-repository/managing-releases-in-a-repository#creating-a-release)”{% ifversion fpt or ghec %} 和“[在 {% data variables.product.prodname_marketplace %} 中发布操作](/actions/creating-actions/publishing-actions-in-github-marketplace#publishing-an-action)”{% endif %}。
 
    * 发布或编辑版本时，发行版工作流程将自动负责编译和调整标记。
 
-   * 建议使用语义版本化的标记（例如 `v1.1.3`）创建版本，并让主要 (`v1`) 和次要 (`v1.1`) 标记与最新的相应提交保持同步。 有关详细信息，请参阅“[关于自定义操作](/actions/creating-actions/about-custom-actions#using-release-management-for-actions)”和“[关于语义版本控制](https://docs.npmjs.com/about-semantic-versioning)”。
+   * 建议使用语义版本化的标记（例如 `v1.1.3`）创建版本，并让主要 (`v1`) 和次要 (`v1.1`) 标记与最新的相应提交保持同步。有关详细信息，请参阅“[关于自定义操作](/actions/creating-actions/about-custom-actions#using-release-management-for-actions)”和“[关于语义版本控制](https://docs.npmjs.com/about-semantic-versioning)”。
 
 ### 结果
 
-与其他一些自动发布管理策略不同，此过程有意不将依赖项提交到 `main` 分支，而仅提交已标记的版本。 这样做，可以鼓励操作用户引用已命名的标记或 `sha`，并且通过在发布过程中自己执行构建来帮助确保第三方拉取请求的安全性。
+与其他一些自动发布管理策略不同，此过程有意不将依赖项提交到 `main` 分支，而仅提交已标记的版本。这样做，可以鼓励操作用户引用已命名的标记或 `sha`，并且通过在发布过程中自己执行构建来帮助确保第三方拉取请求的安全性。
 
 使用语义发行版意味着操作的用户可以将其工作流程固定到某个版本，并且知道他们可能会继续接收最新的稳定、不间断功能，具体取决于他们的舒适度：
 
 ## 与社区合作
 
-{% data variables.product.product_name %} 提供工具和指南，帮助您与开源社区合作。 以下是我们建议为健康的双向通信设置的一些工具。 通过向社区提供以下信号，您可以鼓励其他人使用、修改和参与您的操作：
+{% data variables.product.product_name %} 提供工具和指南，帮助您与开源社区合作。以下是我们建议为健康的双向通信设置的一些工具。通过向社区提供以下信号，您可以鼓励其他人使用、修改和参与您的操作：
 
-* 维护其中包含大量用法示例和指导的 `README`。 有关详细信息，请参阅“[关于自述文件](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes)”。
-* 在 `README` 文件中添加工作流状态徽章。 有关详细信息，请参阅“[添加工作流状态徽章](/actions/managing-workflow-runs/adding-a-workflow-status-badge)”。 若要了解可添加的其他徽章，另请访问 [shields.io](https://shields.io/)。{% ifversion fpt or ghec %}
-* 添加社区运行状况文件，如 `CODE_OF_CONDUCT`、`CONTRIBUTING` 和 `SECURITY`。 有关详细信息，请参阅“[创建默认社区运行状况文件](/github/building-a-strong-community/creating-a-default-community-health-file#supported-file-types)”。{% endif %}
+* 维护其中包含大量用法示例和指导的 `README`。有关详细信息，请参阅“[关于自述文件](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes)”。
+* 在 `README` 文件中添加工作流状态徽章。有关详细信息，请参阅“[添加工作流状态徽章](/actions/managing-workflow-runs/adding-a-workflow-status-badge)”。若要了解可添加的其他徽章，另请访问 [shields.io](https://shields.io/)。{% ifversion fpt or ghec %}
+* 添加社区运行状况文件，如 `CODE_OF_CONDUCT`、`CONTRIBUTING` 和 `SECURITY`。有关详细信息，请参阅“[创建默认社区运行状况文件](/github/building-a-strong-community/creating-a-default-community-health-file#supported-file-types)”。{% endif %}
 * 利用 [actions/stale](https://github.com/actions/stale) 等操作使问题保持最新。
 
 ## 延伸阅读
diff --git a/translations/zh-CN/content/actions/creating-actions/setting-exit-codes-for-actions.md b/translations/zh-CN/content/actions/creating-actions/setting-exit-codes-for-actions.md
index 60fb196d14b1..a458afe688aa 100644
--- a/translations/zh-CN/content/actions/creating-actions/setting-exit-codes-for-actions.md
+++ b/translations/zh-CN/content/actions/creating-actions/setting-exit-codes-for-actions.md
@@ -26,11 +26,11 @@ ms.locfileid: '145084703'
 退出状态 | 检查运行状态 | 说明
 ------------|------------------|------------
 `0` | `success` | 操作已成功完成，依赖它的其他操作可以开始。
-非零值（0 除外的任何整数）| `failure` | 任何其他退出代码都表示操作失败。 当操作失败时，所有同时进行的操作都会取消，且跳过未来的操作。 检查运行和检查套件都将收到 `failure` 状态。
+非零值（0 除外的任何整数）| `failure` | 任何其他退出代码都表示操作失败。当操作失败时，所有同时进行的操作都会取消，且跳过未来的操作。检查运行和检查套件都将收到 `failure` 状态。
 
 ## 在 JavaScript 操作中设置失败退出代码
 
-如需创建 JavaScript 操作，可以使用操作工具包 [`@actions/core`](https://github.com/actions/toolkit/tree/main/packages/core) 程序包来记录消息并设置失败退出代码。 例如：
+如需创建 JavaScript 操作，可以使用操作工具包 [`@actions/core`](https://github.com/actions/toolkit/tree/main/packages/core) 程序包来记录消息并设置失败退出代码。例如：
 
 ```javascript
 try {
@@ -44,7 +44,7 @@ try {
 
 ## 在 Docker 容器操作中设置失败退出代码
 
-如需创建 Docker 容器操作，可以在 `entrypoint.sh` 脚本中设置失败退出代码。 例如：
+如需创建 Docker 容器操作，可以在 `entrypoint.sh` 脚本中设置失败退出代码。例如：
 
 ```
 if <condition> ; then
diff --git a/translations/zh-CN/content/actions/creating-actions/sharing-actions-and-workflows-with-your-enterprise.md b/translations/zh-CN/content/actions/creating-actions/sharing-actions-and-workflows-with-your-enterprise.md
index a25b2a66ab7c..5417a1bafaf0 100644
--- a/translations/zh-CN/content/actions/creating-actions/sharing-actions-and-workflows-with-your-enterprise.md
+++ b/translations/zh-CN/content/actions/creating-actions/sharing-actions-and-workflows-with-your-enterprise.md
@@ -19,7 +19,7 @@ ms.locfileid: '145066878'
 
 如果组织由企业帐户所有，可以通过允许 {% data variables.product.prodname_actions %} 工作流访问包含该操作或工作流的内部存储库，在企业内共享操作和工作流，而无需公开发布该操作或工作流。 
 
-存储在内部存储库中的任何操作或工作流都可以用于同一组织或企业拥有的任何组织所拥有的其他专用或内部存储库中定义的工作流。 存储在内部存储库中的操作和工作流不能在公共存储库中使用。
+存储在内部存储库中的任何操作或工作流都可以用于同一组织或企业拥有的任何组织所拥有的其他专用或内部存储库中定义的工作流。存储在内部存储库中的操作和工作流不能在公共存储库中使用。
 
 {% warning %}
 
@@ -29,8 +29,8 @@ ms.locfileid: '145066878'
 
 ## 与企业共享操作和工作流
 
-1. 将操作或工作流存储在内部存储库中。 有关详细信息，请参阅“[关于存储库](/repositories/creating-and-managing-repositories/about-repositories#about-internal-repositories)”。
-1. 配置存储库以允许访问其他专用存储库和内部存储库中的工作流。 有关详细信息，请参阅“[管理存储库的 {% data variables.product.prodname_actions %} 设置](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-access-to-components-in-an-internal-repository)”。
+1. 将操作或工作流存储在内部存储库中。有关详细信息，请参阅“[关于存储库](/repositories/creating-and-managing-repositories/about-repositories#about-internal-repositories)”。
+1. 配置存储库以允许访问其他专用存储库和内部存储库中的工作流。有关详细信息，请参阅“[管理存储库的 {% data variables.product.prodname_actions %} 设置](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-access-to-components-in-an-internal-repository)”。
 
 ## 延伸阅读
 
diff --git a/translations/zh-CN/content/actions/deployment/about-deployments/deploying-with-github-actions.md b/translations/zh-CN/content/actions/deployment/about-deployments/deploying-with-github-actions.md
index 196b7c07b272..369548ae6782 100644
--- a/translations/zh-CN/content/actions/deployment/about-deployments/deploying-with-github-actions.md
+++ b/translations/zh-CN/content/actions/deployment/about-deployments/deploying-with-github-actions.md
@@ -23,7 +23,7 @@ ms.locfileid: '145179182'
 
 ## 简介
 
-{% data variables.product.prodname_actions %} 提供了允许您控制部署的功能。 方法：
+{% data variables.product.prodname_actions %} 提供了允许您控制部署的功能。方法：
 
 - 使用各种事件触发工作流程。
 - 配置环境以在作业可以继续之前设置规则，并限制对机密的访问。
@@ -33,11 +33,11 @@ ms.locfileid: '145179182'
 
 ## 先决条件
 
-您应该熟悉 {% data variables.product.prodname_actions %} 的语法。 有关详细信息，请参阅“[了解 {% data variables.product.prodname_actions %}](/actions/learn-github-actions)”。
+您应该熟悉 {% data variables.product.prodname_actions %} 的语法。有关详细信息，请参阅“[了解 {% data variables.product.prodname_actions %}](/actions/learn-github-actions)”。
 
 ## 触发部署
 
-您可以使用各种事件来触发您的部署工作流程。 一些最常见的事件包括：`pull_request`、`push` 和 `workflow_dispatch`。
+您可以使用各种事件来触发您的部署工作流程。一些最常见的事件包括：`pull_request`、`push` 和 `workflow_dispatch`。
 
 例如，具有以下触发器的工作流在以下情况下会运行：
 
@@ -64,15 +64,15 @@ on:
 
 ## 使用并发
 
-并发确保只有使用相同并发组的单一作业或工作流程才会同时运行。 您可以使用并发，以便环境中每次最多有一个正在进行的部署和一个待处理的部署。
+并发确保只有使用相同并发组的单一作业或工作流程才会同时运行。您可以使用并发，以便环境中每次最多有一个正在进行的部署和一个待处理的部署。
 
 {% note %}
 
-注意：`concurrency` 和 `environment` 未连接。 并发值可以是任何字符串；它无需是环境名称。 此外，如果另一个工作流程使用相同的环境，但未指定并发性，则该工作流程将不受任何并发规则的约束。
+注意：`concurrency` 和 `environment` 未连接。并发值可以是任何字符串；它无需是环境名称。此外，如果另一个工作流程使用相同的环境，但未指定并发性，则该工作流程将不受任何并发规则的约束。
 
 {% endnote %}
 
-例如，当以下工作流运行时，如果使用 `production` 并发组的任何作业或工作流正在进行中，则它将暂停并且状态为 `pending`。 它还将取消使用 `production` 并发组且状态为 `pending` 的任何作业或工作流。 这意味着，由于使用了 `production` 并发组，因此最多有一个正在运行和一个待处理的作业或工作流。
+例如，当以下工作流运行时，如果使用 `production` 并发组的任何作业或工作流正在进行中，则它将暂停并且状态为 `pending`。它还将取消使用 `production` 并发组且状态为 `pending` 的任何作业或工作流。这意味着，由于使用了 `production` 并发组，因此最多有一个正在运行和一个待处理的作业或工作流。
 
 ```yaml
 name: Deployment
@@ -93,7 +93,7 @@ jobs:
         # ...deployment-specific steps
 ```
 
-您也可以在作业级别指定并发性。 这将允许工作流中的其他作业继续，即使并发作业的状态为 `pending`。
+您也可以在作业级别指定并发性。这将允许工作流中的其他作业继续，即使并发作业的状态为 `pending`。
 
 ```yaml
 name: Deployment
@@ -140,17 +140,17 @@ jobs:
 
 ## 查看部署历史记录
 
-当 {% data variables.product.prodname_actions %} 工作流部署到某个环境时，该环境将显示在存储库的主页上。 有关如何查看环境部署的详细信息，请参阅“[查看部署历史记录](/developers/overview/viewing-deployment-history)”。
+当 {% data variables.product.prodname_actions %} 工作流部署到某个环境时，该环境将显示在存储库的主页上。有关如何查看环境部署的详细信息，请参阅“[查看部署历史记录](/developers/overview/viewing-deployment-history)”。
 
 ## 监控工作流程运行
 
-每个工作流程运行都会生成一个实时图表，说明运行进度。 您可以使用此图表来监控和调试部署。 有关详细信息，请参阅“[使用可视化效果图](/actions/monitoring-and-troubleshooting-workflows/using-the-visualization-graph)”。
+每个工作流程运行都会生成一个实时图表，说明运行进度。您可以使用此图表来监控和调试部署。有关详细信息，请参阅“[使用可视化效果图](/actions/monitoring-and-troubleshooting-workflows/using-the-visualization-graph)”。
 
-您还可以查看每个工作流程运行的日志和工作流程运行的历史记录。 有关详细信息，请参阅“[查看工作流运行历史记录](/actions/monitoring-and-troubleshooting-workflows/viewing-workflow-run-history)”。
+您还可以查看每个工作流程运行的日志和工作流程运行的历史记录。有关详细信息，请参阅“[查看工作流运行历史记录](/actions/monitoring-and-troubleshooting-workflows/viewing-workflow-run-history)”。
 
 ## 通过应用跟踪部署
 
-{% ifversion fpt or ghec %} 如果在 {% ifversion ghae %}{% data variables.product.product_name %}{% else %}{% data variables.product.product_location %}{% endif %} 上的个人帐户或组织与 Microsoft Teams 或 Slack 集成，可以通过 Microsoft Teams 或 Slack 跟踪使用环境的部署。 例如，当部署正在等待批准、部署获得批准或部署状态更改时，您可以通过应用接收通知。 有关如何集成 Microsoft Teams 或 Slack 的详细信息，请参阅“[GitHub 扩展和集成](/github/customizing-your-github-workflow/exploring-integrations/github-extensions-and-integrations#team-communication-tools)”。
+{% ifversion fpt or ghec %} 如果在 {% ifversion ghae %}{% data variables.product.product_name %}{% else %}{% data variables.product.product_location %}{% endif %} 上的个人帐户或组织与 Microsoft Teams 或 Slack 集成，可以通过 Microsoft Teams 或 Slack 跟踪使用环境的部署。例如，当部署正在等待批准、部署获得批准或部署状态更改时，您可以通过应用接收通知。有关如何集成 Microsoft Teams 或 Slack 的详细信息，请参阅“[GitHub 扩展和集成](/github/customizing-your-github-workflow/exploring-integrations/github-extensions-and-integrations#team-communication-tools)”。
 {% endif %}
 
 你还可以构建一个应用，该应用使用部署和部署状态 web 挂钩来跟踪部署。 {% data reusables.actions.environment-deployment-event %} 有关详细信息，请参阅“[应用](/developers/apps)”和“[Webhook 事件和有效负载](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#deployment)”。
@@ -159,7 +159,7 @@ jobs:
 
 ## 选择运行器
 
-您可以在 {% data variables.product.company_short %} 托管的运行器或自托管运行器上运行部署工作流程。 来自 {% data variables.product.company_short %} 托管的运行器的流量可能来自[各种网络地址](/rest/reference/meta#get-github-meta-information)。 如果要部署到内部环境，并且公司将外部流量限制到专用网络，则在 {% data variables.product.company_short %} 托管的运行器上运行的 {% data variables.product.prodname_actions %} 工作流可能无法与内部服务或资源通信。 为了克服这一点，您可以托管自己的运行器。 有关详细信息，请参阅“[关于自托管运行器](/actions/hosting-your-own-runners/about-self-hosted-runners)”和“[关于 GitHub 托管的运行器](/actions/using-github-hosted-runners/about-github-hosted-runners)”。
+您可以在 {% data variables.product.company_short %} 托管的运行器或自托管运行器上运行部署工作流程。来自 {% data variables.product.company_short %} 托管的运行器的流量可能来自[各种网络地址](/rest/reference/meta#get-github-meta-information)。如果要部署到内部环境，并且公司将外部流量限制到专用网络，则在 {% data variables.product.company_short %} 托管的运行器上运行的 {% data variables.product.prodname_actions %} 工作流可能无法与内部服务或资源通信。为了克服这一点，您可以托管自己的运行器。有关详细信息，请参阅“[关于自托管运行器](/actions/hosting-your-own-runners/about-self-hosted-runners)”和“[关于 GitHub 托管的运行器](/actions/using-github-hosted-runners/about-github-hosted-runners)”。
 
 {% endif %}
 
diff --git a/translations/zh-CN/content/actions/deployment/deploying-xcode-applications/installing-an-apple-certificate-on-macos-runners-for-xcode-development.md b/translations/zh-CN/content/actions/deployment/deploying-xcode-applications/installing-an-apple-certificate-on-macos-runners-for-xcode-development.md
index 24ccb039fab9..722c40aa1446 100644
--- a/translations/zh-CN/content/actions/deployment/deploying-xcode-applications/installing-an-apple-certificate-on-macos-runners-for-xcode-development.md
+++ b/translations/zh-CN/content/actions/deployment/deploying-xcode-applications/installing-an-apple-certificate-on-macos-runners-for-xcode-development.md
@@ -25,30 +25,30 @@ ms.locfileid: '145086688'
 
 ## 简介
 
-本指南显示如何在持续集成 (CI) 工作流程中添加一个步骤，以在 {% data variables.product.prodname_actions %} 运行器上安装 Apple 代码签名证书和预配配置文件。 这将允许您签署您的 Xcode 应用以发布到 Apple App Store 或分发到测试组。
+本指南显示如何在持续集成 (CI) 工作流程中添加一个步骤，以在 {% data variables.product.prodname_actions %} 运行器上安装 Apple 代码签名证书和预配配置文件。这将允许您签署您的 Xcode 应用以发布到 Apple App Store 或分发到测试组。
 
 ## 先决条件
 
-您应该熟悉 YAML 和 {% data variables.product.prodname_actions %} 的语法。 有关详细信息，请参阅：
+您应该熟悉 YAML 和 {% data variables.product.prodname_actions %} 的语法。有关详细信息，请参阅：
 
 - [了解 {% data variables.product.prodname_actions %}](/actions/learn-github-actions)
 - [{% data variables.product.prodname_actions %} 工作流语法](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions)
 
-您应该了解 Xcode 应用的构建和签名。 有关详细信息，请参阅 [Apple 开发人员文档](https://developer.apple.com/documentation/)。
+您应该了解 Xcode 应用的构建和签名。有关详细信息，请参阅 [Apple 开发人员文档](https://developer.apple.com/documentation/)。
 
 ## 为您的证书和预配配置文件创建密码
 
 签名过程包括存储证书和预配配置文件、将它们传输给运行器、将它们导入运行器的密钥链，以及在构建中使用它们。
 
-要在运行器上使用您的证书和预配配置文件，我们强烈建议您使用 {% data variables.product.prodname_dotcom %} 密码。 有关创建机密并在工作流中使用它们的详细信息，请参阅“[加密的机密](/actions/reference/encrypted-secrets)”。
+要在运行器上使用您的证书和预配配置文件，我们强烈建议您使用 {% data variables.product.prodname_dotcom %} 密码。有关创建机密并在工作流中使用它们的详细信息，请参阅“[加密的机密](/actions/reference/encrypted-secrets)”。
 
 在您的仓库或组织中为下列项目创建密钥：
 
 * 您的 Apple 签名证书。
 
-  - 这是你的 `p12` 证书文件。 有关从 Xcode 导出签名证书的详细信息，请参阅 [Xcode 文档](https://help.apple.com/xcode/mac/current/#/dev154b28f09)。
+  - 这是你的 `p12` 证书文件。有关从 Xcode 导出签名证书的详细信息，请参阅 [Xcode 文档](https://help.apple.com/xcode/mac/current/#/dev154b28f09)。
   
-  - 当您将证书保存为密钥时，您应该将其转换为 Base64 。 在此示例中，机密命名为 `BUILD_CERTIFICATE_BASE64`。
+  - 当您将证书保存为密钥时，您应该将其转换为 Base64。在此示例中，机密命名为 `BUILD_CERTIFICATE_BASE64`。
 
   - 使用以下命令将证书转换为 Base64 并将其复制到剪贴板：
 
@@ -62,7 +62,7 @@ ms.locfileid: '145086688'
 
   - 有关从 Xcode 导出预置描述文件的详细信息，请参阅 [Xcode 文档](https://help.apple.com/xcode/mac/current/#/deva899b4fe5)。
 
-  - 当您将预配配置文件保存为密钥时，您应该将其转换为 Base64 。 在此示例中，机密命名为 `BUILD_PROVISION_PROFILE_BASE64`。
+  - 当您将预配配置文件保存为密钥时，您应该将其转换为 Base64。在此示例中，机密命名为 `BUILD_PROVISION_PROFILE_BASE64`。
 
   - 使用以下命令将预配配置文件转换为 Base64 并将其复制到剪贴板：
   
@@ -72,7 +72,7 @@ ms.locfileid: '145086688'
 
 * 密钥链密码。
 
-  - 将在运行器上创建一个新的密钥链，因此新密钥链的密码可以是任何新的随机字符串。 在此示例中，机密命名为 `KEYCHAIN_PASSWORD`。
+  - 将在运行器上创建一个新的密钥链，因此新密钥链的密码可以是任何新的随机字符串。在此示例中，机密命名为 `KEYCHAIN_PASSWORD`。
 
 ## 在工作流程中添加一个步骤
 
@@ -123,11 +123,11 @@ jobs:
 
 ## 自托管运行器上的必要清理
 
-{% data variables.product.prodname_dotcom %} 托管的运行器是孤立的虚拟机器，在作业执行结束时自动销毁。 这意味着在运行器中使用的证书和预配配置文件将在运行器完成任务后被销毁。
+{% data variables.product.prodname_dotcom %} 托管的运行器是孤立的虚拟机器，在作业执行结束时自动销毁。这意味着在运行器中使用的证书和预配配置文件将在运行器完成任务后被销毁。
 
 在自托管运行器上，`$RUNNER_TEMP` 目录在任务执行结束时被清除，但在运行器上可能仍然存在密钥链和预置描述文件。
 
-如果您使用自托管的运行器， 您应该在工作流程中添加最后一步，以帮助确保这些敏感文件在作业结束时被删除。 下面显示的工作流程步骤是如何执行此操作的一个示例。
+如果您使用自托管的运行器，您应该在工作流程中添加最后一步，以帮助确保这些敏感文件在作业结束时被删除。下面显示的工作流程步骤是如何执行此操作的一个示例。
 
 {% raw %}
 ```yaml
diff --git a/translations/zh-CN/content/actions/deployment/managing-your-deployments/viewing-deployment-history.md b/translations/zh-CN/content/actions/deployment/managing-your-deployments/viewing-deployment-history.md
index 00f618b7fb2f..3ce8d201727f 100644
--- a/translations/zh-CN/content/actions/deployment/managing-your-deployments/viewing-deployment-history.md
+++ b/translations/zh-CN/content/actions/deployment/managing-your-deployments/viewing-deployment-history.md
@@ -24,8 +24,8 @@ ms.locfileid: '145087316'
 要查看当前和过去的部署，请在存储库的主页上单击“环境”。
 {% ifversion ghae %} ![环境](/assets/images/enterprise/2.22/environments-sidebar.png){% else %} ![环境](/assets/images/environments-sidebar.png){% endif %}
 
-部署页显示仓库中每个环境的最新活动部署。 如果部署包含环境 URL，则部署旁边将显示链接到 URL 的“查看部署”按钮。
+部署页显示仓库中每个环境的最新活动部署。如果部署包含环境 URL，则部署旁边将显示链接到 URL 的“查看部署”按钮。
 
-活动日志显示环境的部署历史记录。 默认情况下，只有环境的最新部署为 `Active` 状态；所有先前的活动部署为 `Inactive` 状态。 有关自动失活部署的更多信息，请参阅“[非活动部署](/rest/reference/deployments#inactive-deployments)”。
+活动日志显示环境的部署历史记录。默认情况下，只有环境的最新部署为 `Active` 状态；所有先前的活动部署为 `Inactive` 状态。有关自动失活部署的更多信息，请参阅“[非活动部署](/rest/reference/deployments#inactive-deployments)”。
 
-您也可以使用 REST API 来获取有关部署的信息。 有关详细信息，请参阅“[存储库](/rest/reference/repos#deployments)”。
+您也可以使用 REST API 来获取有关部署的信息。有关详细信息，请参阅“[存储库](/rest/reference/repos#deployments)”。
diff --git a/translations/zh-CN/content/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services.md b/translations/zh-CN/content/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services.md
index ecdf9badd23a..8a0fcda29d67 100644
--- a/translations/zh-CN/content/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services.md
+++ b/translations/zh-CN/content/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services.md
@@ -42,7 +42,7 @@ OpenID Connect (OIDC) 允许您的 {% data variables.product.prodname_actions %}
 
 要在 IAM 中配置角色和信任，请参阅[“假定角色”](https://github.com/aws-actions/configure-aws-credentials#assuming-a-role)和[“为 Web 身份或 OpenID 连接联合创建角色”](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp_oidc.html)的 AWS 文档。
 
-编辑信任策略以将 `sub` 字段添加到验证条件。 例如：
+编辑信任策略以将 `sub` 字段添加到验证条件。例如：
 
 ```json{:copy}
 "Condition": {
@@ -53,7 +53,7 @@ OpenID Connect (OIDC) 允许您的 {% data variables.product.prodname_actions %}
 }
 ```
 
-在以下示例中，`ForAllValues` 用于匹配多个条件键，`StringLike` 用于匹配指定存储库中的任何 ref。 请注意，`ForAllValues` [过于宽松](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_multi-value-conditions.html)，不应在 `Allow` 效果中单独使用。 对于此示例，包含 `StringLike` 表示 `ForAllValues` 中的空集仍然不会传递条件：
+在以下示例中，`ForAllValues` 用于匹配多个条件键，`StringLike` 用于匹配指定存储库中的任何 ref。请注意，`ForAllValues` [过于宽松](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_multi-value-conditions.html)，不应在 `Allow` 效果中单独使用。对于此示例，包含 `StringLike` 表示 `ForAllValues` 中的空集仍然不会传递条件：
 
 ```json{:copy}
 {
@@ -92,7 +92,7 @@ OpenID Connect (OIDC) 允许您的 {% data variables.product.prodname_actions %}
 
 ### 请求访问令牌
 
-`aws-actions/configure-aws-credentials` 操作从 {% data variables.product.prodname_dotcom %} OIDC 提供商接收 JWT，然后从 AWS 请求访问令牌。 有关详细信息，请参阅 [AWS 文档](https://github.com/aws-actions/configure-aws-credentials)。
+`aws-actions/configure-aws-credentials` 操作从 {% data variables.product.prodname_dotcom %} OIDC 提供商接收 JWT，然后从 AWS 请求访问令牌。有关详细信息，请参阅 [AWS 文档](https://github.com/aws-actions/configure-aws-credentials)。
 
 - `<example-bucket-name>`：在此处添加 S3 Bucket 的名称。
 - `<role-to-assume>`：将示例替换为你的 AWS 角色。
diff --git a/translations/zh-CN/content/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-azure.md b/translations/zh-CN/content/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-azure.md
index 403577316166..d6c3ffaa3762 100644
--- a/translations/zh-CN/content/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-azure.md
+++ b/translations/zh-CN/content/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-azure.md
@@ -33,9 +33,9 @@ OpenID Connect (OIDC) 允许您的 {% data variables.product.prodname_actions %}
 
 ## 将联合凭据添加到 Azure
 
-{% data variables.product.prodname_dotcom %} 的 OIDC 提供商与 Azure 的工作负载联合身份验证配合使用。 有关概述，请参阅“[工作负载联合身份验证](https://docs.microsoft.com/en-us/azure/active-directory/develop/workload-identity-federation)”中的 Microsoft 文档。
+{% data variables.product.prodname_dotcom %} 的 OIDC 提供商与 Azure 的工作负载联合身份验证配合使用。有关概述，请参阅“[工作负载联合身份验证](https://docs.microsoft.com/en-us/azure/active-directory/develop/workload-identity-federation)”中的 Microsoft 文档。
 
-要在 Azure 中配置 OIDC 身份提供商，您需要执行以下配置。 有关进行这些更改的说明，请参阅 [Azure 文档](https://docs.microsoft.com/en-us/azure/developer/github/connect-from-azure)。
+要在 Azure 中配置 OIDC 身份提供商，您需要执行以下配置。有关进行这些更改的说明，请参阅 [Azure 文档](https://docs.microsoft.com/en-us/azure/developer/github/connect-from-azure)。
 
 1. 创建 Azure Active Directory 应用程序和服务主体。
 2. 为 Azure Active Directory 应用程序添加联合凭据。
@@ -43,7 +43,7 @@ OpenID Connect (OIDC) 允许您的 {% data variables.product.prodname_actions %}
 
 配置身份提供商的附加指导：
 
-- 有关安全强化，请确保已查看[“使用云配置 OIDC 信任”](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#configuring-the-oidc-trust-with-the-cloud)。 有关示例，请参阅“[在云提供商中配置主题](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#configuring-the-subject-in-your-cloud-provider)”。
+- 有关安全强化，请确保已查看[“使用云配置 OIDC 信任”](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#configuring-the-oidc-trust-with-the-cloud)。有关示例，请参阅“[在云提供商中配置主题](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#configuring-the-subject-in-your-cloud-provider)”。
 - 对于 `audience` 设置，建议使用 `api://AzureADTokenExchange` 值，但也可以在此处指定其他值。
 
 ## 更新 {% data variables.product.prodname_actions %} 工作流程
@@ -58,7 +58,7 @@ OpenID Connect (OIDC) 允许您的 {% data variables.product.prodname_actions %}
 
 ### 请求访问令牌
 
-[`azure/login`](https://github.com/Azure/login) 操作从 {% data variables.product.prodname_dotcom %} OIDC 提供商接收 JWT，然后从 Azure 请求访问令牌。 有关详细信息，请参阅 [`azure/login`](https://github.com/Azure/login) 文档。
+[`azure/login`](https://github.com/Azure/login) 操作从 {% data variables.product.prodname_dotcom %} OIDC 提供商接收 JWT，然后从 Azure 请求访问令牌。有关详细信息，请参阅 [`azure/login`](https://github.com/Azure/login) 文档。
 
 以下示例将 OIDC ID 令牌与 Azure 交换以接收访问令牌，然后可以使用该令牌访问云资源。
 
diff --git a/translations/zh-CN/content/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-cloud-providers.md b/translations/zh-CN/content/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-cloud-providers.md
index 5b5fb5fc7071..3dea8c761a91 100644
--- a/translations/zh-CN/content/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-cloud-providers.md
+++ b/translations/zh-CN/content/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-cloud-providers.md
@@ -45,13 +45,13 @@ OpenID Connect (OIDC) 允许您的 {% data variables.product.prodname_actions %}
 
 ### 使用官方操作
 
-如果您的云提供商已创建将 OIDC 与 {% data variables.product.prodname_actions %} 结合使用的官方操作，它将允许您轻松地将 OIDC 令牌交换为访问令牌。 然后，可以更新工作流程，以便在访问云资源时使用此令牌。
+如果您的云提供商已创建将 OIDC 与 {% data variables.product.prodname_actions %} 结合使用的官方操作，它将允许您轻松地将 OIDC 令牌交换为访问令牌。然后，可以更新工作流程，以便在访问云资源时使用此令牌。
 
 ## 使用自定义操作
 
 如果您的云提供商没有官方操作，或者您更喜欢创建自定义脚本，则可以手动向 {% data variables.product.prodname_dotcom %}的 OIDC 提供商请求 JSON Web 令牌 (JWT)。 
 
-如果您没有使用官方操作，则 {% data variables.product.prodname_dotcom %} 建议您使用 Actions 核心工具包。 也可使用以下环境变量来检索令牌：`ACTIONS_RUNTIME_TOKEN`、`ACTIONS_ID_TOKEN_REQUEST_URL`。
+如果您没有使用官方操作，则 {% data variables.product.prodname_dotcom %} 建议您使用 Actions 核心工具包。也可使用以下环境变量来检索令牌：`ACTIONS_RUNTIME_TOKEN`、`ACTIONS_ID_TOKEN_REQUEST_URL`。
 
 要使用此方法更新工作流程，您需要对 YAML 进行三项更改：
 
@@ -61,7 +61,7 @@ OpenID Connect (OIDC) 允许您的 {% data variables.product.prodname_actions %}
 
 ### 使用 Actions 核心工具包请求 JWT
 
-以下示例演示如何将 `actions/github-script` 与 `core` 工具包一起使用，从 {% data variables.product.prodname_dotcom %} 的 OIDC 提供商那里请求 JWT。 有关详细信息，请参阅“[添加操作工具包](/actions/creating-actions/creating-a-javascript-action#adding-actions-toolkit-packages)”。
+以下示例演示如何将 `actions/github-script` 与 `core` 工具包一起使用，从 {% data variables.product.prodname_dotcom %} 的 OIDC 提供商那里请求 JWT。有关详细信息，请参阅“[添加操作工具包](/actions/creating-actions/creating-a-javascript-action#adding-actions-toolkit-packages)”。
 
 ```yaml
 jobs:
@@ -85,7 +85,7 @@ jobs:
 
 下面的示例演示如何使用环境变量来请求 JSON Web 令牌。
 
-对于部署作业，需要使用 `actions/github-script` 和 `core` 工具包来定义令牌设置。 有关详细信息，请参阅“[添加操作工具包](/actions/creating-actions/creating-a-javascript-action#adding-actions-toolkit-packages)”。
+对于部署作业，需要使用 `actions/github-script` 和 `core` 工具包来定义令牌设置。有关详细信息，请参阅“[添加操作工具包](/actions/creating-actions/creating-a-javascript-action#adding-actions-toolkit-packages)”。
 
 例如：
 
@@ -106,7 +106,7 @@ jobs:
           core.setOutput('IDTOKENURL', runtimeUrl.trim())
 ```
 
-然后，可使用 `curl` 从 {% data variables.product.prodname_dotcom %} OIDC 提供商那里检索 JWT。 例如：
+然后，可使用 `curl` 从 {% data variables.product.prodname_dotcom %} OIDC 提供商那里检索 JWT。例如：
 
 ```yaml
     - run: |
@@ -127,11 +127,11 @@ jobs:
 
 您需要向云提供商提供 OIDC JSON Web 令牌，以便获取访问令牌。
 
-对于每个部署，您的工作流程必须使用云登录操作（或自定义脚本），以提取 OIDC 令牌并将其提供给您的云提供商。 然后，云提供商验证令牌中的声明；如果成功，它将提供仅可用于该作业运行的云访问令牌。 然后，作业中的后续操作可以使用提供的访问令牌连接到云并部署到其资源。
+对于每个部署，您的工作流程必须使用云登录操作（或自定义脚本），以提取 OIDC 令牌并将其提供给您的云提供商。然后，云提供商验证令牌中的声明；如果成功，它将提供仅可用于该作业运行的云访问令牌。然后，作业中的后续操作可以使用提供的访问令牌连接到云并部署到其资源。
 
 将 OIDC 令牌交换为访问令牌的步骤因每个云提供商而异。 
  
 ### 访问云提供商中的资源
 
-获取访问令牌后，可以使用特定的云操作或脚本向云提供商进行身份验证并部署到其资源。 对于每个云提供商，这些步骤可能会有所不同。
+获取访问令牌后，可以使用特定的云操作或脚本向云提供商进行身份验证并部署到其资源。对于每个云提供商，这些步骤可能会有所不同。
 此外，此访问令牌的默认过期时间可能因每个云而异，并且可以在云提供商端进行配置。
diff --git a/translations/zh-CN/content/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-google-cloud-platform.md b/translations/zh-CN/content/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-google-cloud-platform.md
index 6994e40b6168..6a04339c13e4 100644
--- a/translations/zh-CN/content/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-google-cloud-platform.md
+++ b/translations/zh-CN/content/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-google-cloud-platform.md
@@ -33,7 +33,7 @@ OpenID Connect (OIDC) 允许您的 {% data variables.product.prodname_actions %}
 
 ## 添加 Google Cloud 工作负载身份提供商
 
-要在 GCP 中配置 OIDC 身份提供商，您需要执行以下配置。 若要了解如何进行这些更改，请参阅 [GCP 文档](https://github.com/google-github-actions/auth)。
+要在 GCP 中配置 OIDC 身份提供商，您需要执行以下配置。若要了解如何进行这些更改，请参阅 [GCP 文档](https://github.com/google-github-actions/auth)。
 
 1. 创建新的身份池。
 2. 配置映射并添加条件。
@@ -41,8 +41,8 @@ OpenID Connect (OIDC) 允许您的 {% data variables.product.prodname_actions %}
 
 配置身份提供商的附加指导：
 
-- 有关安全强化，请确保已查看[“使用云配置 OIDC 信任”](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#configuring-the-oidc-trust-with-the-cloud)。 有关示例，请参阅[“在云提供商中配置主题”](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#configuring-the-subject-in-your-cloud-provider)。
-- 要使服务帐户可用于配置，需要将其分配给 `roles/iam.workloadIdentityUser` 角色。 有关详细信息，请参阅 [GCP 文档](https://cloud.google.com/iam/docs/workload-identity-federation?_ga=2.114275588.-285296507.1634918453#conditions)。
+- 有关安全强化，请确保已查看[“使用云配置 OIDC 信任”](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#configuring-the-oidc-trust-with-the-cloud)。有关示例，请参阅[“在云提供商中配置主题”](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#configuring-the-subject-in-your-cloud-provider)。
+- 要使服务帐户可用于配置，需要将其分配给 `roles/iam.workloadIdentityUser` 角色。有关详细信息，请参阅 [GCP 文档](https://cloud.google.com/iam/docs/workload-identity-federation?_ga=2.114275588.-285296507.1634918453#conditions)。
 - 要使用的颁发者 URL：{% ifversion ghes %}`https://HOSTNAME/_services/token`{% else %}`https://token.actions.githubusercontent.com`{% endif %}
 
 ## 更新 {% data variables.product.prodname_actions %} 工作流程
@@ -57,11 +57,11 @@ OpenID Connect (OIDC) 允许您的 {% data variables.product.prodname_actions %}
 
 ### 请求访问令牌
 
-`google-github-actions/auth` 操作从 {% data variables.product.prodname_dotcom %} OIDC 提供商接收 JWT，然后从 GCP 请求访问令牌。 有关详细信息，请参阅 [GCP 文档](https://github.com/google-github-actions/auth)。
+`google-github-actions/auth` 操作从 {% data variables.product.prodname_dotcom %} OIDC 提供商接收 JWT，然后从 GCP 请求访问令牌。有关详细信息，请参阅 [GCP 文档](https://github.com/google-github-actions/auth)。
 
 此示例有一个名为 `Get_OIDC_ID_token` 的作业，该作业使用操作从 GCP 请求服务列表。
 
-- `<example-workload-identity-provider>`：将此值替换为指向 GCP 中标识提供者的路径。 例如： `projects/<example-project-id>/locations/global/workloadIdentityPools/<name-of-pool/providers/<name-of-provider>`
+- `<example-workload-identity-provider>`：将此值替换为指向 GCP 中标识提供者的路径。例如： `projects/<example-project-id>/locations/global/workloadIdentityPools/<name-of-pool/providers/<name-of-provider>`
 - `<example-service-account>`：将此值替换为你在 GCP 中的服务帐户的名称。
 - `<project-id>`：将此值替换为 GCP 项目的 ID。
 
diff --git a/translations/zh-CN/content/actions/deployment/security-hardening-your-deployments/using-openid-connect-with-reusable-workflows.md b/translations/zh-CN/content/actions/deployment/security-hardening-your-deployments/using-openid-connect-with-reusable-workflows.md
index 85cda1e07723..ef2a74cdddcc 100644
--- a/translations/zh-CN/content/actions/deployment/security-hardening-your-deployments/using-openid-connect-with-reusable-workflows.md
+++ b/translations/zh-CN/content/actions/deployment/security-hardening-your-deployments/using-openid-connect-with-reusable-workflows.md
@@ -24,17 +24,17 @@ ms.locfileid: '146273048'
 
 ## <a name="about-reusable-workflows"></a>关于可重用工作流程
 
-您可以创建一个可重用的工作流程来执行部署步骤，而不是将部署作业从一个工作流程复制并粘贴到另一个工作流程。 如果可重用工作流满足“[重用工作流](/actions/learn-github-actions/reusing-workflows#access-to-reusable-workflows)”中所述的访问要求之一，则可以由另一个工作流使用。
+您可以创建一个可重用的工作流程来执行部署步骤，而不是将部署作业从一个工作流程复制并粘贴到另一个工作流程。如果可重用工作流满足“[重用工作流](/actions/learn-github-actions/reusing-workflows#access-to-reusable-workflows)”中所述的访问要求之一，则可以由另一个工作流使用。
 
-与 OpenID Connect (OIDC) 结合使用时，可重用工作流程可让您在存储库、组织或企业中实施一致的部署。 为此，可以基于可重用工作流程在云角色上定义信任条件。
+与 OpenID Connect (OIDC) 结合使用时，可重用工作流程可让您在存储库、组织或企业中实施一致的部署。为此，可以基于可重用工作流程在云角色上定义信任条件。
 
-为了创建基于可重用工作流的信任条件，云提供商必须支持 `job_workflow_ref` 的自定义声明。 这允许您的云提供商确定作业最初来自哪个存储库。 如果你的云提供商仅支持标准声明（受众和主题），则无法确定作业是否源自可重用工作流存储库 。 支持 `job_workflow_ref` 的云提供商包括 Google Cloud Platform 和 HashiCorp Vault。
+为了创建基于可重用工作流的信任条件，云提供商必须支持 `job_workflow_ref` 的自定义声明。这允许您的云提供商确定作业最初来自哪个存储库。如果你的云提供商仅支持标准声明（受众和主题），则无法确定作业是否源自可重用工作流存储库。支持 `job_workflow_ref` 的云提供商包括 Google Cloud Platform 和 HashiCorp Vault。
 
 在继续操作之前，应熟悉[可重用工作流](/actions/learn-github-actions/reusing-workflows)和 [OpenID Connect](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect) 的概念。
 
 ## <a name="how-the-token-works-with-reusable-workflows"></a>令牌如何与可重用工作流程配合使用
 
-在工作流程运行期间，{% data variables.product.prodname_dotcom %} 的 OIDC 提供商会向云提供商提供一个 OIDC 令牌，其中包含有关作业的信息。 如果该作业是可重用工作流的一部分，则令牌将包括包含有关调用工作流的信息的标准声明，并且还将包括一个名为 `job_workflow_ref` 的自定义声明，其中包含有关被调用工作流的信息。
+在工作流程运行期间，{% data variables.product.prodname_dotcom %} 的 OIDC 提供商会向云提供商提供一个 OIDC 令牌，其中包含有关作业的信息。如果该作业是可重用工作流的一部分，则令牌将包括包含有关调用工作流的信息的标准声明，并且还将包括一个名为 `job_workflow_ref` 的自定义声明，其中包含有关被调用工作流的信息。
 
 例如，以下 OIDC 令牌适用于作为被调用工作流程一部分的作业。 `workflow`、`ref` 及其他属性描述调用方工作流，而 `job_workflow_ref` 指被调用的工作流：
 
@@ -73,13 +73,13 @@ ms.locfileid: '146273048'
 }
 ```
 
-如果可重用工作流程执行部署步骤，则它通常需要访问特定的云角色，并且您可能希望允许组织中的任何存储库调用该可重用工作流程。 若要允许这样做，您将创建允许任何存储库和任何调用方工作流程的信任条件，然后筛选组织和被调用的工作流程。 有关一些示例，请参阅下一节。
+如果可重用工作流程执行部署步骤，则它通常需要访问特定的云角色，并且您可能希望允许组织中的任何存储库调用该可重用工作流程。若要允许这样做，您将创建允许任何存储库和任何调用方工作流程的信任条件，然后筛选组织和被调用的工作流程。有关一些示例，请参阅下一节。
 
 ## <a name="examples"></a>示例
 
 筛选特定存储库中的可重用工作流
 
-您可以配置自定义声明，以筛选特定存储库中的任何可重用工作流程。 在此示例中，工作流运行必须源自在 `octo-org/octo-automation` 存储库的可重用工作流中定义的作业，以及由 `octo-org` 组织拥有的任何存储库中定义的作业。
+您可以配置自定义声明，以筛选特定存储库中的任何可重用工作流程。在此示例中，工作流运行必须源自在 `octo-org/octo-automation` 存储库的可重用工作流中定义的作业，以及由 `octo-org` 组织拥有的任何存储库中定义的作业。
 
 - **主题**：
   - 语法： `repo:ORG_NAME/*`
@@ -91,7 +91,7 @@ ms.locfileid: '146273048'
 
 在特定引用处筛选特定的可重用工作流
 
-您可以配置自定义声明，以筛选特定的可重用工作流程。 在此示例中，工作流运行必须源自在可重用工作流 `octo-org/octo-automation/.github/workflows/deployment.yml` 中定义的作业，以及由 `octo-org` 组织拥有的任何存储库中定义的作业。
+您可以配置自定义声明，以筛选特定的可重用工作流程。在此示例中，工作流运行必须源自在可重用工作流 `octo-org/octo-automation/.github/workflows/deployment.yml` 中定义的作业，以及由 `octo-org` 组织拥有的任何存储库中定义的作业。
 
 - **主题**：
   - 语法： `repo:ORG_NAME/*` 
diff --git a/translations/zh-CN/content/actions/deployment/targeting-different-environments/index.md b/translations/zh-CN/content/actions/deployment/targeting-different-environments/index.md
index 3eb8e9b58758..f093811097bb 100644
--- a/translations/zh-CN/content/actions/deployment/targeting-different-environments/index.md
+++ b/translations/zh-CN/content/actions/deployment/targeting-different-environments/index.md
@@ -1,7 +1,7 @@
 ---
 title: 针对不同的环境
 shortTitle: Targeting different environments
-intro: 您可以使用保护规则和机密配置环境。 引用环境的工作流程作业在运行或访问环境的机密之前，必须遵循环境的任何保护规则。
+intro: 您可以使用保护规则和机密配置环境。引用环境的工作流程作业在运行或访问环境的机密之前，必须遵循环境的任何保护规则。
 versions:
   fpt: '*'
   ghes: '*'
diff --git a/translations/zh-CN/content/actions/deployment/targeting-different-environments/using-environments-for-deployment.md b/translations/zh-CN/content/actions/deployment/targeting-different-environments/using-environments-for-deployment.md
index d57441e133bf..3cc6470fb91b 100644
--- a/translations/zh-CN/content/actions/deployment/targeting-different-environments/using-environments-for-deployment.md
+++ b/translations/zh-CN/content/actions/deployment/targeting-different-environments/using-environments-for-deployment.md
@@ -1,7 +1,7 @@
 ---
 title: 使用环境进行部署
 shortTitle: Use environments for deployment
-intro: 您可以使用保护规则和机密配置环境。 引用环境的工作流程作业在运行或访问环境的机密之前，必须遵循环境的任何保护规则。
+intro: 您可以使用保护规则和机密配置环境。引用环境的工作流程作业在运行或访问环境的机密之前，必须遵循环境的任何保护规则。
 product: '{% data reusables.gated-features.environments %}'
 miniTocMaxHeadingLevel: 3
 redirect_from:
@@ -22,48 +22,48 @@ ms.locfileid: '147572301'
 ---
 ## 关于环境
 
-环境用于描述常规部署目标，例如 `production`、`staging` 或 `development`。 当 {% data variables.product.prodname_actions %} 工作流部署到某个环境时，该环境将显示在存储库的主页上。 有关如何查看环境部署的详细信息，请参阅“[查看部署历史记录](/developers/overview/viewing-deployment-history)”。
+环境用于描述常规部署目标，例如 `production`、`staging` 或 `development`。当 {% data variables.product.prodname_actions %} 工作流部署到某个环境时，该环境将显示在存储库的主页上。有关如何查看环境部署的详细信息，请参阅“[查看部署历史记录](/developers/overview/viewing-deployment-history)”。
 
-您可以使用保护规则和机密配置环境。 当工作流程引用环境时，作业在环境的所有保护规则通过之前不会开始。 在所有环境保护规则通过之前，作业也不能访问在环境中定义的机密。
+您可以使用保护规则和机密配置环境。当工作流程引用环境时，作业在环境的所有保护规则通过之前不会开始。在所有环境保护规则通过之前，作业也不能访问在环境中定义的机密。
 
 {% ifversion fpt %} {% note %}
 
-注意：只能为公共存储库配置环境。 如果您将仓库从公开转换为私密，任何配置的保护规则或环境机密将被忽略， 并且您将无法配置任何环境。 如果将仓库转换回公共，您将有权访问以前配置的任何保护规则和环境机密。
+注意：只能为公共存储库配置环境。如果您将仓库从公开转换为私密，任何配置的保护规则或环境机密将被忽略，并且您将无法配置任何环境。如果将仓库转换回公共，您将有权访问以前配置的任何保护规则和环境机密。
 
-使用 {% data variables.product.prodname_team %} 的组织和使用 {% data variables.product.prodname_pro %} 的用户可以为专用存储库配置环境。 有关详细信息，请参阅“[{% data variables.product.prodname_dotcom %} 的产品](/get-started/learning-about-github/githubs-products)”。
+使用 {% data variables.product.prodname_team %} 的组织和使用 {% data variables.product.prodname_pro %} 的用户可以为专用存储库配置环境。有关详细信息，请参阅“[{% data variables.product.prodname_dotcom %} 的产品](/get-started/learning-about-github/githubs-products)”。
 
 {% endnote %} {% endif %}
 
 ## 环境保护规则
 
-环境保护规则要求通过特定的条件，然后引用环境的作业才能继续。 您可以使用环境保护规则来要求人工审批、延迟工作或将环境限制于某些分支。
+环境保护规则要求通过特定的条件，然后引用环境的作业才能继续。您可以使用环境保护规则来要求人工审批、延迟工作或将环境限制于某些分支。
 
 ### 需要的审查者
 
-使用所需的审查者要求特定人员或团队批准引用环境的工作流程作业。 您最多可以列出六个用户或团队作为审查者。 审查者必须至少具有对仓库的读取访问权限。 只有一个必需的审查者需要批准该作业才能继续。
+使用所需的审查者要求特定人员或团队批准引用环境的工作流程作业。您最多可以列出六个用户或团队作为审查者。审查者必须至少具有对仓库的读取访问权限。只有一个必需的审查者需要批准该作业才能继续。
 
 有关由必需审查者审查引用环境的作业的详细信息，请参阅“[审查部署](/actions/managing-workflow-runs/reviewing-deployments)”。
 
 ### 等待计时器
 
-在最初触发作业后，使用等待计时器将作业延迟特定时间。 时间（分钟）必须是 0 至 43,200（30天）之间的整数。
+在最初触发作业后，使用等待计时器将作业延迟特定时间。时间（分钟）必须是 0 至 43,200（30 天）之间的整数。
 
 ### 部署分支
 
-使用部署分支来限制哪些分支可以部署到环境中。 以下是环境部署分支的选项：
+使用部署分支来限制哪些分支可以部署到环境中。以下是环境部署分支的选项：
 
 * **所有分支**：存储库中的所有分支都可以部署到环境。
-* **受保护的分支**：只有启用了分支保护规则的分支才能部署到环境。 如果没有为仓库中的任何分支定义分支保护规则，那么所有分支都可以部署。 有关分支保护规则的详细信息，请参阅“[关于受保护的分支](/github/administering-a-repository/about-protected-branches)”。
+* **受保护的分支**：只有启用了分支保护规则的分支才能部署到环境。如果没有为仓库中的任何分支定义分支保护规则，那么所有分支都可以部署。有关分支保护规则的详细信息，请参阅“[关于受保护的分支](/github/administering-a-repository/about-protected-branches)”。
 * **所选分支**：只有与指定名称模式匹配的分支才能部署到环境。
 
-  例如，如果指定 `releases/*` 为部署分支规则，则只有名称以 `releases/` 开头的分支才能部署到环境。 （通配符不匹配 `/`。 要匹配以 `release/` 开头且包含其他单斜杠的分支，请使用 `release/*/*`。）如果添加 `main` 作为部署分支规则，则名为 `main` 的分支也可以部署到环境。 有关部署分支的语法选项的详细信息，请参阅 [Ruby File.fnmatch 文档](https://ruby-doc.org/core-2.5.1/File.html#method-c-fnmatch)。
+  例如，如果指定 `releases/*` 为部署分支规则，则只有名称以 `releases/` 开头的分支才能部署到环境。 （通配符不匹配 `/`。要匹配以 `release/` 开头且包含其他单斜杠的分支，请使用 `release/*/*`。）如果添加 `main` 作为部署分支规则，则名为 `main` 的分支也可以部署到环境。有关部署分支的语法选项的详细信息，请参阅 [Ruby File.fnmatch 文档](https://ruby-doc.org/core-2.5.1/File.html#method-c-fnmatch)。
 ## 环境机密
 
-存储在环境中的机密仅可用于引用环境的工作流程作业。 如果环境需要批准，作业在所需的审查者批准之前不能访问环境机密。 有关机密的详细信息，请参阅“[已加密的机密](/actions/reference/encrypted-secrets)”。
+存储在环境中的机密仅可用于引用环境的工作流程作业。如果环境需要批准，作业在所需的审查者批准之前不能访问环境机密。有关机密的详细信息，请参阅“[已加密的机密](/actions/reference/encrypted-secrets)”。
 
 {% note %}
 
-注意：在自托管运行器上运行的工作流不会在一个孤立的容器中运行，即使它们使用环境。 环境机密应与存储库和组织机密的安全级别相同。 有关详细信息，请参阅“[GitHub Actions 的安全强化](/actions/learn-github-actions/security-hardening-for-github-actions#hardening-for-self-hosted-runners)”。
+注意：在自托管运行器上运行的工作流不会在一个孤立的容器中运行，即使它们使用环境。环境机密应与存储库和组织机密的安全级别相同。有关详细信息，请参阅“[GitHub Actions 的安全强化](/actions/learn-github-actions/security-hardening-for-github-actions#hardening-for-self-hosted-runners)”。
 
 {% endnote %}
 
@@ -80,30 +80,30 @@ ms.locfileid: '147572301'
 {% data reusables.repositories.navigate-to-repo %} {% data reusables.repositories.sidebar-settings %} {% data reusables.actions.sidebar-environment %} {% data reusables.actions.new-environment %} {% data reusables.actions.name-environment %}
 1. （可选）指定必须批准使用此环境的工作流程作业的人员或团队。
    1. 选择“必需审阅者”。
-   1. 最多可输入 6 人或团队。 只有一个必需的审查者需要批准该作业才能继续。
+   1. 最多可输入 6 人或团队。只有一个必需的审查者需要批准该作业才能继续。
    1. 单击“保存保护规则”。
 2. （可选）指定在允许使用此环境的工作流程作业继续之前要等待的时长。
    1. 选择“等待计时器”。
    1. 输入要等待的分钟数。
    1. 单击“保存保护规则”。
-3. （可选）指定哪些分支可以部署到此环境。 有关可能值的详细信息，请参阅“[部署分支](#deployment-branches)”。
+3. （可选）指定哪些分支可以部署到此环境。有关可能值的详细信息，请参阅“[部署分支](#deployment-branches)”。
    1. 在“部署分支”下拉列表中选择所需的选项。
    1. 如果选择“所选分支”，请输入要允许的分支名称模式。
-4. （可选）添加环境机密。 这些机密仅可用于使用环境的工作流程作业。 此外，使用此环境的工作流程作业只能在任何配置的规则（例如，必需的审查者）通过后才能访问这些机密。 有关机密的详细信息，请参阅“[已加密的机密](/actions/reference/encrypted-secrets)”。
+4. （可选）添加环境机密。这些机密仅可用于使用环境的工作流程作业。此外，使用此环境的工作流程作业只能在任何配置的规则（例如，必需的审查者）通过后才能访问这些机密。有关机密的详细信息，请参阅“[已加密的机密](/actions/reference/encrypted-secrets)”。
    1. 在“环境机密”下，单击“添加机密” 。
    1. 输入机密名称。
    1. 输入机密值。
    1. 单击“添加机密”。
 
-您还可以通过 REST API 创建和配置环境。 有关详细信息，请参阅“[部署环境](/rest/deployments/environments)”、“[GitHub Actions 机密](/rest/actions/secrets)”和“[部署分支策略](/rest/deployments/branch-policies)”。
+您还可以通过 REST API 创建和配置环境。有关详细信息，请参阅“[部署环境](/rest/deployments/environments)”、“[GitHub Actions 机密](/rest/actions/secrets)”和“[部署分支策略](/rest/deployments/branch-policies)”。
 
-运行引用不存在的环境的工作流程将使用引用的名称创建环境。 新创建的环境将不配置任何保护规则或机密。 可在仓库中编辑工作流程的任何人都可以通过工作流程文件创建环境，但只有仓库管理员才能配置环境。
+运行引用不存在的环境的工作流程将使用引用的名称创建环境。新创建的环境将不配置任何保护规则或机密。可在仓库中编辑工作流程的任何人都可以通过工作流程文件创建环境，但只有仓库管理员才能配置环境。
 
 ## 使用环境
 
-工作流程中的每个作业都可以引用单个环境。 在将引用环境的作业发送到运行器之前，必须通过为环境配置的任何保护规则。 只有在将作业发送给运行器后，作业才能访问环境的机密。
+工作流程中的每个作业都可以引用单个环境。在将引用环境的作业发送到运行器之前，必须通过为环境配置的任何保护规则。只有在将作业发送给运行器后，作业才能访问环境的机密。
 
-当工作流程引用环境时，环境将显示在仓库的部署中。 有关查看当前和以前的部署的详细信息，请参阅“[查看部署历史记录](/developers/overview/viewing-deployment-history)”。
+当工作流程引用环境时，环境将显示在仓库的部署中。有关查看当前和以前的部署的详细信息，请参阅“[查看部署历史记录](/developers/overview/viewing-deployment-history)”。
 
 {% data reusables.actions.environment-example %}
 
@@ -111,20 +111,20 @@ ms.locfileid: '147572301'
 
 {% data reusables.actions.permissions-statement-environment %}
 
-删除环境将删除与环境关联的所有机密和保护规则。 由于已删除环境的保护规则而正在等待的任何作业将自动失败。
+删除环境将删除与环境关联的所有机密和保护规则。由于已删除环境的保护规则而正在等待的任何作业将自动失败。
 
 {% data reusables.repositories.navigate-to-repo %} {% data reusables.repositories.sidebar-settings %} {% data reusables.actions.sidebar-environment %}
 1. 在要删除的环境旁边，单击 {% octicon "trash" aria-label="The trash icon" %}。
 2. 单击“我了解，删除此环境”。
 
-您也可以通过 RESEST API 删除环境。 有关详细信息，请参阅“[环境](/rest/reference/repos#environments)”。
+您也可以通过 RESEST API 删除环境。有关详细信息，请参阅“[环境](/rest/reference/repos#environments)”。
 
 ## 环境与部署的关系
 
 {% data reusables.actions.environment-deployment-event %}
 
-您可以通过 REST API 或 GraphQL API 访问这些对象。 您还可以订阅这些 web 挂钩事件。 有关详细信息，请参阅“[存储库](/rest/reference/repos#deployments)”(REST API)、“[对象](/graphql/reference/objects#deployment)”(GraphQL API) 或“[Webhook 事件和有效负载](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#deployment)”。
+您可以通过 REST API 或 GraphQL API 访问这些对象。您还可以订阅这些 web 挂钩事件。有关详细信息，请参阅“[存储库](/rest/reference/repos#deployments)”(REST API)、“[对象](/graphql/reference/objects#deployment)”(GraphQL API) 或“[Webhook 事件和有效负载](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#deployment)”。
 
 ## 后续步骤
 
-{% data variables.product.prodname_actions %} 具有多个用于管理部署的功能。 有关详细信息，请参阅“[使用 GitHub Actions 进行部署](/actions/deployment/deploying-with-github-actions)”。
+{% data variables.product.prodname_actions %} 具有多个用于管理部署的功能。有关详细信息，请参阅“[使用 GitHub Actions 进行部署](/actions/deployment/deploying-with-github-actions)”。
diff --git a/translations/zh-CN/content/actions/examples/using-concurrency-expressions-and-a-test-matrix.md b/translations/zh-CN/content/actions/examples/using-concurrency-expressions-and-a-test-matrix.md
index 7e236f7aeb8d..725fcb61ff02 100644
--- a/translations/zh-CN/content/actions/examples/using-concurrency-expressions-and-a-test-matrix.md
+++ b/translations/zh-CN/content/actions/examples/using-concurrency-expressions-and-a-test-matrix.md
@@ -238,7 +238,7 @@ on:
 </td>
 <td>
 
-通过 `on` 关键字，可以定义运行工作流时触发的事件。 可在此处定义多个事件。 有关详细信息，请参阅“[触发工作流](/actions/using-workflows/triggering-a-workflow#using-events-to-trigger-workflows)”。
+通过 `on` 关键字，可以定义运行工作流时触发的事件。可在此处定义多个事件。有关详细信息，请参阅“[触发工作流](/actions/using-workflows/triggering-a-workflow#using-events-to-trigger-workflows)”。
 </td>
 </tr>
 <tr>
@@ -250,7 +250,7 @@ on:
 </td>
 <td>
 
-如果要在 UI 中手动运行此工作流，请添加 `workflow_dispatch` 事件。 有关详细信息，请参阅 [`workflow_dispatch`](/actions/reference/events-that-trigger-workflows#workflow_dispatch)。
+如果要在 UI 中手动运行此工作流，请添加 `workflow_dispatch` 事件。有关详细信息，请参阅 [`workflow_dispatch`](/actions/reference/events-that-trigger-workflows#workflow_dispatch)。
 </td>
 </tr>
 <tr>
@@ -262,7 +262,7 @@ on:
 </td>
 <td>
 
-添加 `pull_request` 事件，以便每次创建或更新拉取请求时，工作流都会自动运行。 有关详细信息，请参阅 [`pull_request`](/actions/using-workflows/events-that-trigger-workflows#pull_request)。
+添加 `pull_request` 事件，以便每次创建或更新拉取请求时，工作流都会自动运行。有关详细信息，请参阅 [`pull_request`](/actions/using-workflows/events-that-trigger-workflows#pull_request)。
 </td>
 </tr>
 <tr>
@@ -276,7 +276,7 @@ on:
 </td>
 <td>
 
-添加 `push` 事件，以便每次将提交推送到匹配筛选器 `main` 的分支时，工作流都会自动运行。 有关详细信息，请参阅 [`push`](/actions/using-workflows/events-that-trigger-workflows#push)。
+添加 `push` 事件，以便每次将提交推送到匹配筛选器 `main` 的分支时，工作流都会自动运行。有关详细信息，请参阅 [`push`](/actions/using-workflows/events-that-trigger-workflows#push)。
 </td>
 </tr>
 <tr>
@@ -290,7 +290,7 @@ permissions:
 </td>
 <td>
 
-修改授予 `GITHUB_TOKEN` 的默认权限。 这将因工作流的需求而异。 有关详细信息，请参阅“[为作业分配权限](/actions/using-jobs/assigning-permissions-to-jobs)”。
+修改授予 `GITHUB_TOKEN` 的默认权限。这将因工作流的需求而异。有关详细信息，请参阅“[为作业分配权限](/actions/using-jobs/assigning-permissions-to-jobs)”。
 </td>
 </tr>
 <tr>
@@ -304,7 +304,7 @@ concurrency:
 </td>
 <td>
 
-为特定事件创建并发组，并使用 `||` 运算符定义回退值。 有关详细信息，请参阅“[使用并发](/actions/using-jobs/using-concurrency)”。
+为特定事件创建并发组，并使用 `||` 运算符定义回退值。有关详细信息，请参阅“[使用并发](/actions/using-jobs/using-concurrency)”。
 </td>
 </tr>
 <tr>
@@ -352,7 +352,7 @@ jobs:
 </td>
 <td>
 
-根据运行工作流的存储库，将作业配置为在 {% data variables.product.prodname_dotcom %} 托管的运行器或自托管运行器上运行。 在此示例中，如果存储库名为 `docs-internal` 且位于 `github` 组织内，则作业将在自托管运行器上运行。 如果存储库与此路径不匹配，则其会在由 {% data variables.product.prodname_dotcom %} 托管的 `ubuntu-latest` 运行器上运行。 有关这些选项的详细信息，请参阅“[为作业选择运行器](/actions/using-jobs/choosing-the-runner-for-a-job)”。
+根据运行工作流的存储库，将作业配置为在 {% data variables.product.prodname_dotcom %} 托管的运行器或自托管运行器上运行。在此示例中，如果存储库名为 `docs-internal` 且位于 `github` 组织内，则作业将在自托管运行器上运行。如果存储库与此路径不匹配，则其会在由 {% data variables.product.prodname_dotcom %} 托管的 `ubuntu-latest` 运行器上运行。有关这些选项的详细信息，请参阅“[为作业选择运行器](/actions/using-jobs/choosing-the-runner-for-a-job)”。
 </td>
 </tr>
 <tr>
@@ -364,7 +364,7 @@ jobs:
 </td>
 <td>
 
-设置作业在自动取消之前运行的最大分钟数。 有关详细信息，请参阅 [`timeout-minutes`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idtimeout-minutes)。
+设置作业在自动取消之前运行的最大分钟数。有关详细信息，请参阅 [`timeout-minutes`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idtimeout-minutes)。
 </td>
 </tr>
 <tr>
@@ -410,7 +410,7 @@ jobs:
 </td>
 <td>
 
-创建名为 `test-group` 的矩阵，其中包含测试组数组。 这些值与将由 `npm test` 运行的测试组的名称匹配。
+创建名为 `test-group` 的矩阵，其中包含测试组数组。这些值与将由 `npm test` 运行的测试组的名称匹配。
 </td>
 </tr>
 <tr>
@@ -422,7 +422,7 @@ jobs:
 </td>
 <td>
 
-将作为 `test` 作业一部分运行的所有步骤组合在一起。 工作流中的每个作业都有其自己的 `steps` 部分。
+将作为 `test` 作业一部分运行的所有步骤组合在一起。工作流中的每个作业都有其自己的 `steps` 部分。
 </td>
 </tr>
 <tr>
@@ -438,7 +438,7 @@ jobs:
 </td>
 <td>
 
-`uses` 关键字指示作业检索名为 `actions/checkout` 的操作。 这是检出仓库并将其下载到运行器的操作，允许针对您的代码运行操作（例如测试工具）。 只要工作流程针对仓库的代码运行，或者您使用仓库中定义的操作，您都必须使用检出操作。 使用 `with` 键为操作提供了一些额外的选项。
+`uses` 关键字指示作业检索名为 `actions/checkout` 的操作。这是检出仓库并将其下载到运行器的操作，允许针对您的代码运行操作（例如测试工具）。只要工作流程针对仓库的代码运行，或者您使用仓库中定义的操作，您都必须使用检出操作。使用 `with` 键为操作提供了一些额外的选项。
 </td>
 </tr>
 <tr>
@@ -546,7 +546,7 @@ jobs:
 </td>
 <td>
 
-此步骤使用 `trilom/file-changes-action` 操作收集拉取请求中更改的文件，以便在下一步中分析它们。 此示例使用 `a6ca26c14274c33b15e6499323aac178af06ad4b` SHA 固定到操作的特定版本。
+此步骤使用 `trilom/file-changes-action` 操作收集拉取请求中更改的文件，以便在下一步中分析它们。此示例使用 `a6ca26c14274c33b15e6499323aac178af06ad4b` SHA 固定到操作的特定版本。
 </td>
 </tr>
 <tr>
@@ -605,7 +605,7 @@ jobs:
 </td>
 <td>
 
-此步骤使用 `actions/cache` 操作来缓存 Next.js 生成，以便工作流将尝试检索生成的缓存，而不是每次都从头重新生成它。 有关详细信息，请参阅“[缓存依赖项以加快工作流](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)”。
+此步骤使用 `actions/cache` 操作来缓存 Next.js 生成，以便工作流将尝试检索生成的缓存，而不是每次都从头重新生成它。有关详细信息，请参阅“[缓存依赖项以加快工作流](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)”。
 </td>
 </tr>
 <tr>
@@ -634,7 +634,7 @@ jobs:
 </td>
 <td>
 
-此步骤使用 `npm test` 运行测试，测试矩阵为矩阵中的每个作业提供不同的 {% raw %}`${{ matrix.test-group }}`{% endraw %} 值。 它使用 `DIFF_FILE` 环境变量来识别已更改的文件，并将 `CHANGELOG_CACHE_FILE_PATH` 环境变量用于 changelog 缓存文件。
+此步骤使用 `npm test` 运行测试，测试矩阵为矩阵中的每个作业提供不同的 {% raw %}`${{ matrix.test-group }}`{% endraw %} 值。它使用 `DIFF_FILE` 环境变量来识别已更改的文件，并将 `CHANGELOG_CACHE_FILE_PATH` 环境变量用于 changelog 缓存文件。
 </td>
 </tr>
 </tbody>
diff --git a/translations/zh-CN/content/actions/examples/using-scripts-to-test-your-code-on-a-runner.md b/translations/zh-CN/content/actions/examples/using-scripts-to-test-your-code-on-a-runner.md
index f8d3ea52d22f..5a925c2ece4e 100644
--- a/translations/zh-CN/content/actions/examples/using-scripts-to-test-your-code-on-a-runner.md
+++ b/translations/zh-CN/content/actions/examples/using-scripts-to-test-your-code-on-a-runner.md
@@ -158,7 +158,7 @@ on:
 </td>
 <td>
 
-通过 `on` 关键字，可以定义运行工作流时触发的事件。 可在此处定义多个事件。 有关详细信息，请参阅“[触发工作流](/actions/using-workflows/triggering-a-workflow#using-events-to-trigger-workflows)”。
+通过 `on` 关键字，可以定义运行工作流时触发的事件。可在此处定义多个事件。有关详细信息，请参阅“[触发工作流](/actions/using-workflows/triggering-a-workflow#using-events-to-trigger-workflows)”。
 </td>
 </tr>
 <tr>
@@ -170,7 +170,7 @@ on:
 </td>
 <td>
 
-如果要从 UI 手动运行此工作流，请添加 `workflow_dispatch` 事件。 有关详细信息，请参阅 [`workflow_dispatch`](/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch)。
+如果要从 UI 手动运行此工作流，请添加 `workflow_dispatch` 事件。有关详细信息，请参阅 [`workflow_dispatch`](/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch)。
 </td>
 </tr>
 <tr>
@@ -184,7 +184,7 @@ on:
 </td>
 <td>
 
-添加 `push` 事件，以便每次将提交推送到名为 `main` 的分支时，工作流都会自动运行。 有关详细信息，请参阅 [`push`](/actions/using-workflows/events-that-trigger-workflows#push)。
+添加 `push` 事件，以便每次将提交推送到名为 `main` 的分支时，工作流都会自动运行。有关详细信息，请参阅 [`push`](/actions/using-workflows/events-that-trigger-workflows#push)。
 </td>
 </tr>
 <tr>
@@ -196,7 +196,7 @@ on:
 </td>
 <td>
 
-添加 `pull_request` 事件，以便每次创建或更新拉取请求时，工作流都会自动运行。 有关详细信息，请参阅 [`pull_request`](/actions/using-workflows/events-that-trigger-workflows#pull_request)。
+添加 `pull_request` 事件，以便每次创建或更新拉取请求时，工作流都会自动运行。有关详细信息，请参阅 [`pull_request`](/actions/using-workflows/events-that-trigger-workflows#pull_request)。
 </td>
 </tr>
 <tr>
@@ -210,7 +210,7 @@ permissions:
 </td>
 <td>
 
-修改授予 `GITHUB_TOKEN` 的默认权限。 这将因工作流的需求而异。 有关详细信息，请参阅“[为作业分配权限](/actions/using-jobs/assigning-permissions-to-jobs)”。
+修改授予 `GITHUB_TOKEN` 的默认权限。这将因工作流的需求而异。有关详细信息，请参阅“[为作业分配权限](/actions/using-jobs/assigning-permissions-to-jobs)”。
 </td>
 </tr>
 <tr>
@@ -225,7 +225,7 @@ concurrency:
 </td>
 <td>
 
-为特定事件创建并发组，并使用 `||` 运算符定义回退值。 有关详细信息，请参阅“[使用并发](/actions/using-jobs/using-concurrency)”。
+为特定事件创建并发组，并使用 `||` 运算符定义回退值。有关详细信息，请参阅“[使用并发](/actions/using-jobs/using-concurrency)”。
 </td>
 </tr>
 <tr>
@@ -275,7 +275,7 @@ jobs:
 </td>
 <td>
 
-根据运行工作流的存储库，将作业配置为在 {% data variables.product.prodname_dotcom %} 托管的运行器或自托管运行器上运行。 在此示例中，如果存储库名为 `docs-internal` 且位于 `github` 组织内，则作业将在自托管运行器上运行。 如果存储库与此路径不匹配，则其会在由 {% data variables.product.prodname_dotcom %} 托管的 `ubuntu-latest` 运行器上运行。 有关这些选项的详细信息，请参阅“[为作业选择运行器](/actions/using-jobs/choosing-the-runner-for-a-job)”。
+根据运行工作流的存储库，将作业配置为在 {% data variables.product.prodname_dotcom %} 托管的运行器或自托管运行器上运行。在此示例中，如果存储库名为 `docs-internal` 且位于 `github` 组织内，则作业将在自托管运行器上运行。如果存储库与此路径不匹配，则其会在由 {% data variables.product.prodname_dotcom %} 托管的 `ubuntu-latest` 运行器上运行。有关这些选项的详细信息，请参阅“[为作业选择运行器](/actions/using-jobs/choosing-the-runner-for-a-job)”。
 </td>
 </tr>
 <tr>
@@ -287,7 +287,7 @@ jobs:
 </td>
 <td>
 
-将作为 `check-links` 作业的一部分运行的所有步骤组合在一起。 工作流中的每个作业都有其自己的 `steps` 部分。
+将作为 `check-links` 作业的一部分运行的所有步骤组合在一起。工作流中的每个作业都有其自己的 `steps` 部分。
 </td>
 </tr>
 <tr>
@@ -300,7 +300,7 @@ jobs:
 </td>
 <td>
 
-`uses` 关键字指示作业检索名为 `actions/checkout` 的操作。 这是检出仓库并将其下载到运行器的操作，允许针对您的代码运行操作（例如测试工具）。 只要工作流程针对仓库的代码运行，或者您使用仓库中定义的操作，您都必须使用检出操作。
+`uses` 关键字指示作业检索名为 `actions/checkout` 的操作。这是检出仓库并将其下载到运行器的操作，允许针对您的代码运行操作（例如测试工具）。只要工作流程针对仓库的代码运行，或者您使用仓库中定义的操作，您都必须使用检出操作。
 </td>
 </tr>
 <tr>
@@ -330,7 +330,7 @@ jobs:
 </td>
 <td>
 
-`run` 关键字指示作业在运行器上执行命令。 在这种情况下，`npm ci` 用于为项目安装 npm 软件包。
+`run` 关键字指示作业在运行器上执行命令。在这种情况下，`npm ci` 用于为项目安装 npm 软件包。
 </td>
 </tr>
 
@@ -346,7 +346,7 @@ jobs:
 </td>
 <td>
 
-使用 `trilom/file-changes-action` 操作收集所有已更改的文件。 此示例使用 `a6ca26c14274c33b15e6499323aac178af06ad4b` SHA 固定到操作的特定版本。
+使用 `trilom/file-changes-action` 操作收集所有已更改的文件。此示例使用 `a6ca26c14274c33b15e6499323aac178af06ad4b` SHA 固定到操作的特定版本。
 </td>
 </tr>
 
@@ -360,7 +360,7 @@ jobs:
 </td>
 <td>
 
-列出 `files.json` 的内容。 这将在工作流运行日志中可见，并且对调试非常有用。
+列出 `files.json` 的内容。这将在工作流运行日志中可见，并且对调试非常有用。
 </td>
 </tr>
 <tr>
diff --git a/translations/zh-CN/content/actions/examples/using-the-github-cli-on-a-runner.md b/translations/zh-CN/content/actions/examples/using-the-github-cli-on-a-runner.md
index eaec878f0f10..9d62f2decc07 100644
--- a/translations/zh-CN/content/actions/examples/using-the-github-cli-on-a-runner.md
+++ b/translations/zh-CN/content/actions/examples/using-the-github-cli-on-a-runner.md
@@ -21,7 +21,7 @@ ms.locfileid: '146749535'
 
 ## 示例概述
 
-{% data reusables.actions.example-workflow-intro-ci %} 此工作流触发后，会自动运行一个脚本，用于检查 {% data variables.product.prodname_dotcom %} Docs 站点是否有任何损坏的链接。 如果找到任何损坏的链接，工作流将使用 {% data variables.product.prodname_dotcom %} CLI 创建包含详细信息的 {% data variables.product.prodname_dotcom %} 问题。
+{% data reusables.actions.example-workflow-intro-ci %} 此工作流触发后，会自动运行一个脚本，用于检查 {% data variables.product.prodname_dotcom %} Docs 站点是否有任何损坏的链接。如果找到任何损坏的链接，工作流将使用 {% data variables.product.prodname_dotcom %} CLI 创建包含详细信息的 {% data variables.product.prodname_dotcom %} 问题。
 
 {% data reusables.actions.example-diagram-intro %}
 
@@ -206,8 +206,8 @@ on:
 
 将 `workflow_dispatch` 和 `scheduled` 定义为工作流的触发器：
 
-* 通过 `workflow_dispatch`，可从 UI 手动运行此工作流。 有关详细信息，请参阅 [`workflow_dispatch`](/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch)。
-* 通过 `schedule` 事件，可使用 `cron` 语法来定义自动触发工作流的定期间隔。 有关详细信息，请参阅 [`schedule`](/actions/reference/events-that-trigger-workflows#schedule)。
+* 通过 `workflow_dispatch`，可从 UI 手动运行此工作流。有关详细信息，请参阅 [`workflow_dispatch`](/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch)。
+* 通过 `schedule` 事件，可使用 `cron` 语法来定义自动触发工作流的定期间隔。有关详细信息，请参阅 [`schedule`](/actions/reference/events-that-trigger-workflows#schedule)。
 </td>
 </tr>
 <tr>
@@ -221,7 +221,7 @@ permissions:
 </td>
 <td>
 
-修改授予 `GITHUB_TOKEN` 的默认权限。 这将因工作流的需求而异。 有关详细信息，请参阅“[为作业分配权限](/actions/using-jobs/assigning-permissions-to-jobs)”。
+修改授予 `GITHUB_TOKEN` 的默认权限。这将因工作流的需求而异。有关详细信息，请参阅“[为作业分配权限](/actions/using-jobs/assigning-permissions-to-jobs)”。
 </td>
 </tr>
 <tr>
@@ -258,7 +258,7 @@ if: github.repository == 'github/docs-internal'
 </td>
 <td>
 
-仅当存储库名为 `docs-internal` 且位于 `github` 组织内时，才运行 `check_all_english_links` 作业。 否则，作业会被标记为“跳过”。
+仅当存储库名为 `docs-internal` 且位于 `github` 组织内时，才运行 `check_all_english_links` 作业。否则，作业会被标记为“跳过”。
 </td>
 </tr>
 <tr>
@@ -270,7 +270,7 @@ runs-on: ubuntu-latest
 </td>
 <td>
 
-配置作业在 Ubuntu Linux 运行器上运行。 这意味着作业将在 {% data variables.product.prodname_dotcom %}. 托管的新虚拟机上执行。 有关使用其他运行器的语法示例，请参阅“[{% data variables.product.prodname_actions %} 的工作流语法](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idruns-on)”。
+配置作业在 Ubuntu Linux 运行器上运行。这意味着作业将在 {% data variables.product.prodname_dotcom %}. 托管的新虚拟机上执行。有关使用其他运行器的语法示例，请参阅“[{% data variables.product.prodname_actions %} 的工作流语法](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idruns-on)”。
 </td>
 </tr>
 <tr>
@@ -286,7 +286,7 @@ runs-on: ubuntu-latest
 </td>
 <td>
 
-创建自定义环境变量，并重新定义内置的 `GITHUB_TOKEN` 变量以使用自定义[机密](/actions/security-guides/encrypted-secrets)。 稍后将在工作流中引用这些变量。
+创建自定义环境变量，并重新定义内置的 `GITHUB_TOKEN` 变量以使用自定义[机密](/actions/security-guides/encrypted-secrets)。稍后将在工作流中引用这些变量。
 </td>
 </tr>
 <tr>
@@ -298,7 +298,7 @@ runs-on: ubuntu-latest
 </td>
 <td>
 
-将作为 `check_all_english_links` 作业一部分运行的所有步骤组合在一起。 工作流中的每个作业都有其自己的 `steps` 部分。
+将作为 `check_all_english_links` 作业一部分运行的所有步骤组合在一起。工作流中的每个作业都有其自己的 `steps` 部分。
 </td>
 </tr>
 <tr>
@@ -311,7 +311,7 @@ runs-on: ubuntu-latest
 </td>
 <td>
 
-`uses` 关键字指示作业检索名为 `actions/checkout` 的操作。 这是检出仓库并将其下载到运行器的操作，允许针对您的代码运行操作（例如测试工具）。 只要工作流程针对仓库的代码运行，或者您使用仓库中定义的操作，您都必须使用检出操作。
+`uses` 关键字指示作业检索名为 `actions/checkout` 的操作。这是检出仓库并将其下载到运行器的操作，允许针对您的代码运行操作（例如测试工具）。只要工作流程针对仓库的代码运行，或者您使用仓库中定义的操作，您都必须使用检出操作。
 </td>
 </tr>
 <tr>
@@ -342,7 +342,7 @@ runs-on: ubuntu-latest
 </td>
 <td>
 
-`run` 关键字指示作业在运行器上执行命令。 在这种情况下，`npm ci` 和 `npm run build` 命令作为单独的步骤运行，用于在存储库中安装和生成 Node.js 应用程序。
+`run` 关键字指示作业在运行器上执行命令。在这种情况下，`npm ci` 和 `npm run build` 命令作为单独的步骤运行，用于在存储库中安装和生成 Node.js 应用程序。
 </td>
 </tr>
 <tr>
@@ -393,7 +393,7 @@ runs-on: ubuntu-latest
 </td>
 <td>
 
-使用 `peter-evans/create-issue-from-file` 操作创建新的 {% data variables.product.prodname_dotcom %} 问题。 此示例使用 `b4f9ee0a9d4abbfc6986601d9b1a4f8f8e74c77e` SHA 固定到操作的特定版本。
+使用 `peter-evans/create-issue-from-file` 操作创建新的 {% data variables.product.prodname_dotcom %} 问题。此示例使用 `b4f9ee0a9d4abbfc6986601d9b1a4f8f8e74c77e` SHA 固定到操作的特定版本。
 </td>
 </tr>
 <tr>
@@ -421,7 +421,7 @@ runs-on: ubuntu-latest
 </td>
 <td>
 
-使用 [`gh issue list`](https://cli.github.com/manual/gh_issue_list) 查找之前在早期运行中创建的问题。 在后续步骤中，为了简化处理，这将[别名](https://cli.github.com/manual/gh_alias_set)设置为 `gh list-reports`。 若要获取问题 URL，`jq` 表达式将处理生成的 JSON 输出。
+使用 [`gh issue list`](https://cli.github.com/manual/gh_issue_list) 查找之前在早期运行中创建的问题。在后续步骤中，为了简化处理，这将[别名](https://cli.github.com/manual/gh_alias_set)设置为 `gh list-reports`。若要获取问题 URL，`jq` 表达式将处理生成的 JSON 输出。
 
 然后，使用 [`gh issue comment`](https://cli.github.com/manual/gh_issue_comment) 向链接到上一个问题的新问题添加注释。
 </td>
diff --git a/translations/zh-CN/content/actions/hosting-your-own-runners/customizing-the-containers-used-by-jobs.md b/translations/zh-CN/content/actions/hosting-your-own-runners/customizing-the-containers-used-by-jobs.md
index c84bbc43d81b..eb3c4aaef14d 100644
--- a/translations/zh-CN/content/actions/hosting-your-own-runners/customizing-the-containers-used-by-jobs.md
+++ b/translations/zh-CN/content/actions/hosting-your-own-runners/customizing-the-containers-used-by-jobs.md
@@ -21,9 +21,9 @@ ms.locfileid: '147881161'
 
 ## 关于容器自定义
 
-通过 {% data variables.product.prodname_actions %}，可使用工作流文件中的 `container:` 语句在容器中运行作业。 有关详细信息，请参阅“[在容器中运行作业](/actions/using-jobs/running-jobs-in-a-container)”。 为了处理基于容器的作业，自托管运行器会为每个作业创建一个容器。
+通过 {% data variables.product.prodname_actions %}，可使用工作流文件中的 `container:` 语句在容器中运行作业。有关详细信息，请参阅“[在容器中运行作业](/actions/using-jobs/running-jobs-in-a-container)”。为了处理基于容器的作业，自托管运行器会为每个作业创建一个容器。
 
-{% data variables.product.prodname_actions %} 支持用于自定义自托管运行器创建容器的方式的命令。 例如，你可以使用这些命令通过 Kubernetes 或 Podman 来管理容器，还可以自定义用于调用容器的 `docker run` 或 `docker create` 命令。 自定义命令由脚本运行，当在运行器上设置特定环境变量时，将自动触发脚本。 有关详细信息，请参阅下面的“[触发自定义脚本](#triggering-the-customization-script)”。
+{% data variables.product.prodname_actions %} 支持用于自定义自托管运行器创建容器的方式的命令。例如，你可以使用这些命令通过 Kubernetes 或 Podman 来管理容器，还可以自定义用于调用容器的 `docker run` 或 `docker create` 命令。自定义命令由脚本运行，当在运行器上设置特定环境变量时，将自动触发脚本。有关详细信息，请参阅下面的“[触发自定义脚本](#triggering-the-customization-script)”。
 
 此自定义仅适用于基于 Linux 的自托管运行器，不需要根用户访问权限。
 
@@ -36,13 +36,13 @@ ms.locfileid: '147881161'
 - [`run_container_step`](/actions/hosting-your-own-runners/customizing-the-containers-used-by-jobs#run_container_step)：针对作业中的每个容器操作调用一次。
 - [`run_script_step`](/actions/hosting-your-own-runners/customizing-the-containers-used-by-jobs#run_script_step)：运行任何不属于容器操作的步骤。
 
-每个自定义命令都必须在其自己的 JSON 文件中定义。 文件名必须与命令名称匹配，扩展名为 `.json`。 例如，`prepare_job` 命令在 `prepare_job.json` 中定义。 然后，这些 JSON 文件将在自托管运行器上一起运行，作为主 `index.js` 脚本的一部分。 “[生成自定义脚本](#generating-the-customization-script)”中更详细地介绍了此过程。
+每个自定义命令都必须在其自己的 JSON 文件中定义。文件名必须与命令名称匹配，扩展名为 `.json`。例如，`prepare_job` 命令在 `prepare_job.json` 中定义。然后，这些 JSON 文件将在自托管运行器上一起运行，作为主 `index.js` 脚本的一部分。 “[生成自定义脚本](#generating-the-customization-script)”中更详细地介绍了此过程。
 
 这些命令还包括配置参数，下面详细介绍了这些参数。
 
 ### `prepare_job`
 
-启动作业时调用 `prepare_job` 命令。 {% data variables.product.prodname_actions %} 传入任何作业或作业具有的服务容器。 如果作业中有任何服务或作业容器，则将调用此命令。 
+启动作业时调用 `prepare_job` 命令。 {% data variables.product.prodname_actions %} 传入任何作业或作业具有的服务容器。如果作业中有任何服务或作业容器，则将调用此命令。 
 
 {% data variables.product.prodname_actions %} 假定你将通过 `prepare_job` 命令执行以下任务：
 
@@ -53,43 +53,43 @@ ms.locfileid: '147881161'
 - 启动服务容器。
 - 将 {% data variables.product.prodname_actions %} 所需的任何信息写入响应文件：
   - 必需：说明容器是否为 `alpine` linux 容器（使用 `isAlpine` 布尔值）。 
-  - 可选：要在作业上下文上设置的任何上下文字段，否则用户无法再使用它们。 有关详细信息，请参阅“[`job` 上下文](/actions/learn-github-actions/contexts#job-context)”。
+  - 可选：要在作业上下文上设置的任何上下文字段，否则用户无法再使用它们。有关详细信息，请参阅“[`job` 上下文](/actions/learn-github-actions/contexts#job-context)”。
 - 当运行状况检查成功且作业/服务容器启动时，返回 `0`。
 
 #### 参数
 
-- `jobContainer`：可选。 包含有关指定作业容器的信息的对象。
-  - `image`：必需。 包含 Docker 映像的字符串。
-  - `workingDirectory`：必需。 包含工作目录的绝对路径的字符串。
-  - `createOptions`：可选。 YAML 中指定的可选“创建”选项。 有关详细信息，请参阅“[示例：在容器中运行作业](/actions/using-jobs/running-jobs-in-a-container#example-running-a-job-within-a-container)”。
-  - `environmentVariables`：可选。 设置关键环境变量的映射。
-  - `userMountVolumes`：可选。 由在 YAML 中设置的用户装载卷组成的数组。 有关详细信息，请参阅“[示例：在容器中运行作业](/actions/using-jobs/running-jobs-in-a-container#example-running-a-job-within-a-container)”。
-    - `sourceVolumePath`：必需。 要装载到 Docker 容器中的卷的源路径。
-    - `targetVolumePath`：必需。 要装载到 Docker 容器中的卷的目标路径。
-    - `readOnly`：必需。 确定装载是否应为只读。
-  - `systemMountVolumes`：必需。 由要装载到容器中的装载组成的数组，与上述字段相同。
-    - `sourceVolumePath`：必需。 要装载到 Docker 容器中的卷的源路径。
-    - `targetVolumePath`：必需。 要装载到 Docker 容器中的卷的目标路径。
-    - `readOnly`：必需。 确定装载是否应为只读。
-  - `registry`：可选。 专用容器注册表的 Docker 注册表凭据。
-    - `username`：可选。 注册表帐户的用户名。
-    - `password`：可选。 注册表帐户的密码。
-    - `serverUrl`：可选。 注册表 URL。
-  - `portMappings`：可选。 要映射到容器的 source:target 端口的键值哈希。
-- `services`：可选。 要启动的服务容器数组。
-  - `contextName`：必需。 作业上下文中服务的名称。
-  - `image`：必需。 包含 Docker 映像的字符串。
-  - `createOptions`：可选。 YAML 中指定的可选“创建”选项。 有关详细信息，请参阅“[示例：在容器中运行作业](/actions/using-jobs/running-jobs-in-a-container#example-running-a-job-within-a-container)”。
-  - `environmentVariables`：可选。 设置关键环境变量的映射。
-  - `userMountVolumes`：可选。 由要装载到容器中的装载组成的数组，与上述字段相同。
-    - `sourceVolumePath`：必需。 要装载到 Docker 容器中的卷的源路径。
-    - `targetVolumePath`：必需。 要装载到 Docker 容器中的卷的目标路径。
-    - `readOnly`：必需。 确定装载是否应为只读。
-  - `registry`：可选。 专用容器注册表的 Docker 注册表凭据。
-    - `username`：可选。 注册表帐户的用户名。
-    - `password`：可选。 注册表帐户的密码。
-    - `serverUrl`：可选。 注册表 URL。
-  - `portMappings`：可选。 要映射到容器的 source:target 端口的键值哈希。
+- `jobContainer`：可选。包含有关指定作业容器的信息的对象。
+  - `image`：必需。包含 Docker 映像的字符串。
+  - `workingDirectory`：必需。包含工作目录的绝对路径的字符串。
+  - `createOptions`：可选。YAML 中指定的可选“创建”选项。有关详细信息，请参阅“[示例：在容器中运行作业](/actions/using-jobs/running-jobs-in-a-container#example-running-a-job-within-a-container)”。
+  - `environmentVariables`：可选。设置关键环境变量的映射。
+  - `userMountVolumes`：可选。由在 YAML 中设置的用户装载卷组成的数组。有关详细信息，请参阅“[示例：在容器中运行作业](/actions/using-jobs/running-jobs-in-a-container#example-running-a-job-within-a-container)”。
+    - `sourceVolumePath`：必需。要装载到 Docker 容器中的卷的源路径。
+    - `targetVolumePath`：必需。要装载到 Docker 容器中的卷的目标路径。
+    - `readOnly`：必需。确定装载是否应为只读。
+  - `systemMountVolumes`：必需。由要装载到容器中的装载组成的数组，与上述字段相同。
+    - `sourceVolumePath`：必需。要装载到 Docker 容器中的卷的源路径。
+    - `targetVolumePath`：必需。要装载到 Docker 容器中的卷的目标路径。
+    - `readOnly`：必需。确定装载是否应为只读。
+  - `registry`：可选。专用容器注册表的 Docker 注册表凭据。
+    - `username`：可选。注册表帐户的用户名。
+    - `password`：可选。注册表帐户的密码。
+    - `serverUrl`：可选。注册表 URL。
+  - `portMappings`：可选。要映射到容器的 source:target 端口的键值哈希。
+- `services`：可选。要启动的服务容器数组。
+  - `contextName`：必需。作业上下文中服务的名称。
+  - `image`：必需。包含 Docker 映像的字符串。
+  - `createOptions`：可选。YAML 中指定的可选“创建”选项。有关详细信息，请参阅“[示例：在容器中运行作业](/actions/using-jobs/running-jobs-in-a-container#example-running-a-job-within-a-container)”。
+  - `environmentVariables`：可选。设置关键环境变量的映射。
+  - `userMountVolumes`：可选。由要装载到容器中的装载组成的数组，与上述字段相同。
+    - `sourceVolumePath`：必需。要装载到 Docker 容器中的卷的源路径。
+    - `targetVolumePath`：必需。要装载到 Docker 容器中的卷的目标路径。
+    - `readOnly`：必需。确定装载是否应为只读。
+  - `registry`：可选。专用容器注册表的 Docker 注册表凭据。
+    - `username`：可选。注册表帐户的用户名。
+    - `password`：可选。注册表帐户的密码。
+    - `serverUrl`：可选。注册表 URL。
+  - `portMappings`：可选。要映射到容器的 source:target 端口的键值哈希。
 
 #### 示例输入
 
@@ -254,27 +254,27 @@ ms.locfileid: '147881161'
 
 #### 参数
 
-- `image`：可选。 包含 Docker 映像的字符串。 否则必须提供 dockerfile。
-- `dockerfile`：可选。 包含 dockerfile 的路径的字符串，否则必须提供映像。
-- `entryPointArgs`：可选。 包含入口点参数的列表。
-- `entryPoint`：可选。 如果应覆盖默认映像入口点，则为要使用的容器入口点。
-- `workingDirectory`：必需。 包含工作目录的绝对路径的字符串。
-- `createOptions`：可选。 YAML 中指定的可选“创建”选项。 有关详细信息，请参阅“[示例：在容器中运行作业](/actions/using-jobs/running-jobs-in-a-container#example-running-a-job-within-a-container)”。
-- `environmentVariables`：可选。 设置关键环境变量的映射。
-- `prependPath`：可选。 由要追加到 `$PATH` 变量的其他路径组成的数组。
-- `userMountVolumes`：可选。 由在 YAML 中设置的用户装载卷组成的数组。 有关详细信息，请参阅“[示例：在容器中运行作业](/actions/using-jobs/running-jobs-in-a-container#example-running-a-job-within-a-container)”。
-  - `sourceVolumePath`：必需。 要装载到 Docker 容器中的卷的源路径。
-  - `targetVolumePath`：必需。 要装载到 Docker 容器中的卷的目标路径。
-  - `readOnly`：必需。 确定装载是否应为只读。
-- `systemMountVolumes`：必需。 由要装载到容器中的装载组成的数组，使用与上述字段相同的字段。
-  - `sourceVolumePath`：必需。 要装载到 Docker 容器中的卷的源路径。
-  - `targetVolumePath`：必需。 要装载到 Docker 容器中的卷的目标路径。
-  - `readOnly`：必需。 确定装载是否应为只读。
-- `registry`：可选。 专用容器注册表的 Docker 注册表凭据。
-  - `username`：可选。 注册表帐户的用户名。
-  - `password`：可选。 注册表帐户的密码。
-  - `serverUrl`：可选。 注册表 URL。
-- `portMappings`：可选。 要映射到容器的 source:target 端口的键值哈希。
+- `image`：可选。包含 Docker 映像的字符串。否则必须提供 dockerfile。
+- `dockerfile`：可选。包含 dockerfile 的路径的字符串，否则必须提供映像。
+- `entryPointArgs`：可选。包含入口点参数的列表。
+- `entryPoint`：可选。如果应覆盖默认映像入口点，则为要使用的容器入口点。
+- `workingDirectory`：必需。包含工作目录的绝对路径的字符串。
+- `createOptions`：可选。YAML 中指定的可选“创建”选项。有关详细信息，请参阅“[示例：在容器中运行作业](/actions/using-jobs/running-jobs-in-a-container#example-running-a-job-within-a-container)”。
+- `environmentVariables`：可选。设置关键环境变量的映射。
+- `prependPath`：可选。由要追加到 `$PATH` 变量的其他路径组成的数组。
+- `userMountVolumes`：可选。由在 YAML 中设置的用户装载卷组成的数组。有关详细信息，请参阅“[示例：在容器中运行作业](/actions/using-jobs/running-jobs-in-a-container#example-running-a-job-within-a-container)”。
+  - `sourceVolumePath`：必需。要装载到 Docker 容器中的卷的源路径。
+  - `targetVolumePath`：必需。要装载到 Docker 容器中的卷的目标路径。
+  - `readOnly`：必需。确定装载是否应为只读。
+- `systemMountVolumes`：必需。由要装载到容器中的装载组成的数组，使用与上述字段相同的字段。
+  - `sourceVolumePath`：必需。要装载到 Docker 容器中的卷的源路径。
+  - `targetVolumePath`：必需。要装载到 Docker 容器中的卷的目标路径。
+  - `readOnly`：必需。确定装载是否应为只读。
+- `registry`：可选。专用容器注册表的 Docker 注册表凭据。
+  - `username`：可选。注册表帐户的用户名。
+  - `password`：可选。注册表帐户的密码。
+  - `serverUrl`：可选。注册表 URL。
+- `portMappings`：可选。要映射到容器的 source:target 端口的键值哈希。
 
 #### 映像的示例输入
 
@@ -441,11 +441,11 @@ ms.locfileid: '147881161'
 
 #### 参数
 
-- `entryPointArgs`：可选。 包含入口点参数的列表。
-- `entryPoint`：可选。 如果应覆盖默认映像入口点，则为要使用的容器入口点。
-- `prependPath`：可选。 由要追加到 `$PATH` 变量的其他路径组成的数组。
-- `workingDirectory`：必需。 包含工作目录的绝对路径的字符串。
-- `environmentVariables`：可选。 设置关键环境变量的映射。
+- `entryPointArgs`：可选。包含入口点参数的列表。
+- `entryPoint`：可选。如果应覆盖默认映像入口点，则为要使用的容器入口点。
+- `prependPath`：可选。由要追加到 `$PATH` 变量的其他路径组成的数组。
+- `workingDirectory`：必需。包含工作目录的绝对路径的字符串。
+- `environmentVariables`：可选。设置关键环境变量的映射。
 
 #### 示例输入
 
@@ -488,23 +488,23 @@ ms.locfileid: '147881161'
 
 1. 将 [actions/runner-container-hooks](https://github.com/actions/runner-container-hooks) 存储库克隆到自托管运行器。
 
-1. `examples/` 目录中包含一些现有的自定义命令，每个命令都有其自己的 JSON 文件。 可以查看这些示例，并将其用作你自己的自定义命令的起点。
+1. `examples/` 目录中包含一些现有的自定义命令，每个命令都有其自己的 JSON 文件。可以查看这些示例，并将其用作你自己的自定义命令的起点。
 
    - `prepare_job.json`
    - `run_script_step.json`
    - `run_container_step.json`
 
-1. 生成 npm 包。 这些命令在 `packages/docker/dist` 和 `packages/k8s/dist` 内生成 `index.js` 文件。
+1. 生成 npm 包。这些命令在 `packages/docker/dist` 和 `packages/k8s/dist` 内生成 `index.js` 文件。
 
    ```shell
    npm install && npm run bootstrap && npm run build-all
    ```
 
-当生成的 `index.js` 由 {% data variables.product.prodname_actions %} 触发时，它将运行 JSON 文件中定义的自定义命令。 若要触发 `index.js`，需要将其添加到 `ACTIONS_RUNNER_REQUIRE_JOB_CONTAINER` 环境变量，如下一部分所述。
+当生成的 `index.js` 由 {% data variables.product.prodname_actions %} 触发时，它将运行 JSON 文件中定义的自定义命令。若要触发 `index.js`，需要将其添加到 `ACTIONS_RUNNER_REQUIRE_JOB_CONTAINER` 环境变量，如下一部分所述。
 
 ## 触发自定义脚本
 
-自定义脚本必须位于运行器上，但不应存储在自托管运行器应用程序目录中。 脚本在运行运行器服务的服务帐户的安全性上下文中执行。
+自定义脚本必须位于运行器上，但不应存储在自托管运行器应用程序目录中。脚本在运行运行器服务的服务帐户的安全性上下文中执行。
 
 {% note %}
 
@@ -516,20 +516,20 @@ ms.locfileid: '147881161'
 
 - `ACTIONS_RUNNER_CONTAINER_HOOK`：此环境变量中定义的脚本在作业分配给运行器之后且作业开始运行之前触发。
 
-要设置此环境变量，可将其添加到操作系统中，或将其添加到自托管运行器应用程序目录中名为 `.env` 的文件中。 例如，以下 `.env` 条目将使运行器在每个基于容器的作业运行之前自动在 `/Users/octocat/runner/index.js` 运行脚本：
+要设置此环境变量，可将其添加到操作系统中，或将其添加到自托管运行器应用程序目录中名为 `.env` 的文件中。例如，以下 `.env` 条目将使运行器在每个基于容器的作业运行之前自动在 `/Users/octocat/runner/index.js` 运行脚本：
 
 ```bash
 ACTIONS_RUNNER_CONTAINER_HOOK=/Users/octocat/runner/index.js
 ```
 
-如果要确保作业始终在容器内运行，并且随后始终应用容器自定义项，可以将自托管运行器上的 `ACTIONS_RUNNER_REQUIRE_JOB_CONTAINER` 变量设置为 `true`。 这将使未指定作业容器的作业失败。
+如果要确保作业始终在容器内运行，并且随后始终应用容器自定义项，可以将自托管运行器上的 `ACTIONS_RUNNER_REQUIRE_JOB_CONTAINER` 变量设置为 `true`。这将使未指定作业容器的作业失败。
 
 ## 故障排除
 
 ### 无超时设置
 
-目前没有可供 `ACTIONS_RUNNER_CONTAINER_HOOK` 执行的脚本使用的超时设置。 因此，可以考虑向脚本添加超时处理。
+目前没有可供 `ACTIONS_RUNNER_CONTAINER_HOOK` 执行的脚本使用的超时设置。因此，可以考虑向脚本添加超时处理。
 
 ### 查看工作流运行日志
 
-要确认脚本是否正在执行，可查看该作业的日志。 有关检查日志的详细信息，请参阅“[查看日志以诊断故障](/actions/monitoring-and-troubleshooting-workflows/using-workflow-run-logs#viewing-logs-to-diagnose-failures)”。
+要确认脚本是否正在执行，可查看该作业的日志。有关检查日志的详细信息，请参阅“[查看日志以诊断故障](/actions/monitoring-and-troubleshooting-workflows/using-workflow-run-logs#viewing-logs-to-diagnose-failures)”。
diff --git a/translations/zh-CN/content/actions/hosting-your-own-runners/monitoring-and-troubleshooting-self-hosted-runners.md b/translations/zh-CN/content/actions/hosting-your-own-runners/monitoring-and-troubleshooting-self-hosted-runners.md
index 6ea4e15cbd4c..61c664c68cec 100644
--- a/translations/zh-CN/content/actions/hosting-your-own-runners/monitoring-and-troubleshooting-self-hosted-runners.md
+++ b/translations/zh-CN/content/actions/hosting-your-own-runners/monitoring-and-troubleshooting-self-hosted-runners.md
@@ -33,7 +33,7 @@ ms.locfileid: '147065632'
 
     * 空闲：运行器已连接到 {% data variables.product.product_name %}，并已准备好执行作业。
     * 活动：运行器当前正在执行作业。
-    * 脱机：运行器未连接到 {% data variables.product.product_name %}。 这可能是因为机器处于离线状态，自托管运行器应用程序未在机器上运行，或者自托管运行器应用程序无法与 {% data variables.product.product_name %} 通信。
+    * 脱机：运行器未连接到 {% data variables.product.product_name %}。这可能是因为机器处于离线状态，自托管运行器应用程序未在机器上运行，或者自托管运行器应用程序无法与 {% data variables.product.product_name %} 通信。
 
 ## 网络连接疑难解答
 
@@ -43,8 +43,8 @@ ms.locfileid: '147065632'
 
 除了 `--check` 外，还必须为脚本提供两个参数：
 
-* `--url`，其中包含指向 {% data variables.product.company_short %} 存储库、组织或企业的 URL。 例如，`--url https://github.com/octo-org/octo-repo`。
-* `--pat`，其中包含必须具有 `workflow` 作用域的个人访问令牌的值。 例如，`--pat ghp_abcd1234`。 有关详细信息，请参阅“[创建个人访问令牌](/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token)”。
+* `--url`，其中包含指向 {% data variables.product.company_short %} 存储库、组织或企业的 URL。例如，`--url https://github.com/octo-org/octo-repo`。
+* `--pat`，其中包含必须具有 `workflow` 作用域的个人访问令牌的值。例如，`--pat ghp_abcd1234`。有关详细信息，请参阅“[创建个人访问令牌](/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token)”。
 
 例如：
 
@@ -64,13 +64,13 @@ run.cmd --check --url <em>https://github.com/octo-org/octo-repo</em> --pat <em>g
 
 {% endwindows %}
 
-该脚本测试每项服务，并为每项服务输出 `PASS` 或 `FAIL`。 如有任何失败的检查，您可以在日志文件中看到更多关于问题的详细信息。 日志文件位于安装了运行器应用程序的 `_diag` 目录中，每个检查的日志文件的路径显示在脚本的控制台输出中。
+该脚本测试每项服务，并为每项服务输出 `PASS` 或 `FAIL`。如有任何失败的检查，您可以在日志文件中看到更多关于问题的详细信息。日志文件位于安装了运行器应用程序的 `_diag` 目录中，每个检查的日志文件的路径显示在脚本的控制台输出中。
 
-如有任何失败的检查，您也应该验证您自己托管的运行器是否符合所有通信要求。 有关详细信息，请参阅[关于自承载运行器](/actions/hosting-your-own-runners/about-self-hosted-runners#communication-requirements)。
+如有任何失败的检查，您也应该验证您自己托管的运行器是否符合所有通信要求。有关详细信息，请参阅[关于自承载运行器](/actions/hosting-your-own-runners/about-self-hosted-runners#communication-requirements)。
 
 ### 禁用 TLS 证书验证
-{% ifversion ghes %} 默认情况下，自托管运行器应用程序验证 {% data variables.product.product_name %} 的 TLS 证书。  如果您的 {% data variables.product.product_name %} 具有自签名证书或内部颁发的证书，则出于测试目的，您可能希望禁用 TLS 证书验证。
-{% else %} 默认情况下，自托管运行器应用程序验证 {% data variables.product.product_name %} 的 TLS 证书。  如果遇到网络问题，您可能希望禁用 TLS 证书验证以进行测试。
+{% ifversion ghes %} 默认情况下，自托管运行器应用程序验证 {% data variables.product.product_name %} 的 TLS 证书。如果您的 {% data variables.product.product_name %} 具有自签名证书或内部颁发的证书，则出于测试目的，您可能希望禁用 TLS 证书验证。
+{% else %} 默认情况下，自托管运行器应用程序验证 {% data variables.product.product_name %} 的 TLS 证书。如果遇到网络问题，您可能希望禁用 TLS 证书验证以进行测试。
 {% endif %}
 
 若要在自托管运行器应用程序中禁用 TLS 证书验证，请在配置和运行自托管运行器应用程序之前将 `GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY` 环境变量设置为 `1`。
@@ -83,32 +83,32 @@ export GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY=1
 
 {% warning %}
 
-警告：不建议禁用 TLS 验证，因为 TLS 在自托管运行器应用程序和 {% data variables.product.product_name %} 之间提供了隐私和数据完整性。 我们建议您在自托管运行器的操作系统证书存储中安装 {% data variables.product.product_name %} 证书。 有关如何安装 {% data variables.product.product_name %} 证书的指导，请咨询您的操作系统供应商。
+警告：不建议禁用 TLS 验证，因为 TLS 在自托管运行器应用程序和 {% data variables.product.product_name %} 之间提供了隐私和数据完整性。我们建议您在自托管运行器的操作系统证书存储中安装 {% data variables.product.product_name %} 证书。有关如何安装 {% data variables.product.product_name %} 证书的指导，请咨询您的操作系统供应商。
 
 {% endwarning %}
 
 ## 查阅自托管运行应用程序日志文件
 
-您可以监控自托管运行器应用程序的状态及其活动。 日志文件保存在你安装运行器应用程序的 `_diag` 目录中，每次启动应用程序时都会生成新的日志。 文件名开头为 Runner_，后接应用程序启动时的 UTC 时间戳。
+您可以监控自托管运行器应用程序的状态及其活动。日志文件保存在你安装运行器应用程序的 `_diag` 目录中，每次启动应用程序时都会生成新的日志。文件名开头为 Runner_，后接应用程序启动时的 UTC 时间戳。
 
 有关工作流作业执行的详细日志，请参阅介绍 Worker_ 文件的下一节。
 
 ## 查看作业日志文件
 
-自托管的运行器应用程序为它处理的每个作业创建详细的日志文件。 这些文件存储在安装运行器应用程序的 `_diag` 目录中，文件名以 Worker_ 开头。
+自托管的运行器应用程序为它处理的每个作业创建详细的日志文件。这些文件存储在安装运行器应用程序的 `_diag` 目录中，文件名以 Worker_ 开头。
 
 {% linux %}
 
 ## 使用 journalctl 检查自托管的运行器应用程序服务
 
-对于使用服务运行应用程序的 Linux 自托管运行器，可以使用 `journalctl` 来监视其实时活动。 基于系统的默认服务使用以下命名约定：`actions.runner.<org>-<repo>.<runnerName>.service`。 此名称在超过 80 个字符时将被截断，因此查找服务名称的首选方式是检查 .service 文件。 例如：
+对于使用服务运行应用程序的 Linux 自托管运行器，可以使用 `journalctl` 来监视其实时活动。基于系统的默认服务使用以下命名约定：`actions.runner.<org>-<repo>.<runnerName>.service`。此名称在超过 80 个字符时将被截断，因此查找服务名称的首选方式是检查 .service 文件。例如：
 
 ```shell
 $ cat ~/actions-runner/.service
 actions.runner.octo-org-octo-repo.runner01.service
 ```
 
-如果因为服务安装在其他地方而失败，您可以在运行服务列表中找到服务名称。 例如，在大多数 Linux 系统上，可以使用 `systemctl` 命令：
+如果因为服务安装在其他地方而失败，您可以在运行服务列表中找到服务名称。例如，在大多数 Linux 系统上，可以使用 `systemctl` 命令：
 
 ```shell
 $ systemctl --type=service | grep actions.runner
@@ -134,7 +134,7 @@ Feb 11 16:07:10 runner01 runsvc.sh[962]: 2020-02-11 16:07:10Z: Job testAction co
 ```
 
 若要查看 `systemd` 配置，可在此处找到服务文件：`/etc/systemd/system/actions.runner.<org>-<repo>.<runnerName>.service`。
-如果您想要自定义自托管的运行器应用程序服务，不要直接修改此文件。 按照“[将自托管运行器应用程序配置为服务](/actions/hosting-your-own-runners/configuring-the-self-hosted-runner-application-as-a-service#customizing-the-self-hosted-runner-service)”中所述的说明进行操作。
+如果您想要自定义自托管的运行器应用程序服务，不要直接修改此文件。按照“[将自托管运行器应用程序配置为服务](/actions/hosting-your-own-runners/configuring-the-self-hosted-runner-application-as-a-service#customizing-the-self-hosted-runner-service)”中所述的说明进行操作。
 
 {% endlinux %}
 
@@ -142,14 +142,14 @@ Feb 11 16:07:10 runner01 runsvc.sh[962]: 2020-02-11 16:07:10Z: Job testAction co
 
 ## 使用 `launchd` 检查自托管运行器应用程序服务
 
-对于将应用程序作为服务运行的 macOS 自托管运行器，可以使用 `launchctl` 来监视其实时活动。 基于 launchd 的默认服务使用以下命名约定：`actions.runner.<org>-<repo>.<runnerName>`。 此名称在超过 80 个字符时将被截断，因此查找服务名称的首选方式是检查运行器目录中的 .service 文件：
+对于将应用程序作为服务运行的 macOS 自托管运行器，可以使用 `launchctl` 来监视其实时活动。基于 launchd 的默认服务使用以下命名约定：`actions.runner.<org>-<repo>.<runnerName>`。此名称在超过 80 个字符时将被截断，因此查找服务名称的首选方式是检查运行器目录中的 .service 文件：
 
 ```shell
 % cat ~/actions-runner/.service
 /Users/exampleUsername/Library/LaunchAgents/actions.runner.octo-org-octo-repo.runner01.plist
 ```
 
-`svc.sh` 脚本使用 `launchctl` 来检查应用程序是否正在运行。 例如：
+`svc.sh` 脚本使用 `launchctl` 来检查应用程序是否正在运行。例如：
 
 ```shell
 $ ./svc.sh status
@@ -162,7 +162,7 @@ Started:
 生成的输出包括进程 ID 和应用程序的 `launchd` 服务的名称。
 
 若要查看 `launchd` 配置，可在此处找到服务文件：`/Users/exampleUsername/Library/LaunchAgents/actions.runner.<repoName>.<runnerName>.service`。
-如果您想要自定义自托管的运行器应用程序服务，不要直接修改此文件。 按照“[将自托管运行器应用程序配置为服务](/actions/hosting-your-own-runners/configuring-the-self-hosted-runner-application-as-a-service#customizing-the-self-hosted-runner-service-1)”中所述的说明进行操作。
+如果您想要自定义自托管的运行器应用程序服务，不要直接修改此文件。按照“[将自托管运行器应用程序配置为服务](/actions/hosting-your-own-runners/configuring-the-self-hosted-runner-application-as-a-service#customizing-the-self-hosted-runner-service-1)”中所述的说明进行操作。
 
 {% endmac %}
 
@@ -170,14 +170,14 @@ Started:
 
 ## 使用 PowerShell 检查自托管的运行器应用程序服务
 
-对于将应用程序运行为服务的 Windows 自托管运行器，您可以使用 PowerShell 来监控其实时活动。 服务使用命名约定 `GitHub Actions Runner (<org>-<repo>.<runnerName>)`。 还可以通过检查运行器目录中的 .service 文件来查找服务的名称：
+对于将应用程序运行为服务的 Windows 自托管运行器，您可以使用 PowerShell 来监控其实时活动。服务使用命名约定 `GitHub Actions Runner (<org>-<repo>.<runnerName>)`。还可以通过检查运行器目录中的 .service 文件来查找服务的名称：
 
 ```shell
 PS C:\actions-runner> Get-Content .service
 actions.runner.octo-org-octo-repo.runner01.service
 ```
 
-可以在 Windows 服务应用程序 (`services.msc`) 中查看运行器的状态。 您也可以使用 PowerShell 来检查服务是否在运行：
+可以在 Windows 服务应用程序 (`services.msc`) 中查看运行器的状态。您也可以使用 PowerShell 来检查服务是否在运行：
 
 ```shell
 PS C:\actions-runner> Get-Service "actions.runner.octo-org-octo-repo.runner01.service" | Select-Object Name, Status
@@ -186,7 +186,7 @@ Name                                                  Status
 actions.runner.octo-org-octo-repo.runner01.service    Running
 ```
 
-您可以使用 PowerShell 来检查自托管运行器的近期活动。 在此示例输出中，可以看到应用程序启动，接收名为 `testAction` 的作业，然后显示结果状态：
+您可以使用 PowerShell 来检查自托管运行器的近期活动。在此示例输出中，可以看到应用程序启动，接收名为 `testAction` 的作业，然后显示结果状态：
 
 ```shell
 PS C:\actions-runner> Get-EventLog -LogName Application -Source ActionsRunnerService
@@ -207,9 +207,9 @@ PS C:\actions-runner> Get-EventLog -LogName Application -Source ActionsRunnerSer
 
 ## 监控自动更新过程
 
-建议定期检查自动更新过程，因为如果自托管的运行器低于某个版本阈值，将会无法处理作业。 自托管的运行器应用程序自动更新本身，但请注意，此过程不包括对操作系统或其他软件的任何更新；您需要单独管理这些更新。
+建议定期检查自动更新过程，因为如果自托管的运行器低于某个版本阈值，将会无法处理作业。自托管的运行器应用程序自动更新本身，但请注意，此过程不包括对操作系统或其他软件的任何更新；您需要单独管理这些更新。
 
-可以在 Runner_ 日志文件中查看更新活动。 例如：
+可以在 Runner_ 日志文件中查看更新活动。例如：
 
 ```shell
 [Feb 12 12:37:07 INFO SelfUpdater] An update is available.
@@ -223,7 +223,7 @@ PS C:\actions-runner> Get-EventLog -LogName Application -Source ActionsRunnerSer
 
 ### 检查 Docker 是否安装
 
-如果您的作业需要容器，则自托管的运行器必须基于 Linux，并且需要安装 Docker。 检查自托管运行器是否安装 Docker，以及服务是否正在运行。
+如果您的作业需要容器，则自托管的运行器必须基于 Linux，并且需要安装 Docker。检查自托管运行器是否安装 Docker，以及服务是否正在运行。
 
 可以使用 `systemctl` 检查服务状态：
 
@@ -248,7 +248,7 @@ active
 dial unix /var/run/docker.sock: connect: permission denied
 ```
 
-检查自托管运行器的服务帐户是否有使用 Docker 服务的权限。 可以通过检查 `systemd` 中的自托管运行器的配置来识别此帐户。 例如：
+检查自托管运行器的服务帐户是否有使用 Docker 服务的权限。可以通过检查 `systemd` 中的自托管运行器的配置来识别此帐户。例如：
 
 ```shell
 $ sudo systemctl show -p User actions.runner.octo-org-octo-repo.runner01.service
@@ -262,5 +262,5 @@ User=runner-user
 
 {% data reusables.actions.upgrade-runners-before-upgrade-ghes %} 
 
-如果运行器出于此原因处于脱机状态，请手动更新运行器。 有关详细信息，请参阅操作/运行器存储库中[最新版本](https://github.com/actions/runner/releases/latest)的安装说明。
+如果运行器出于此原因处于脱机状态，请手动更新运行器。有关详细信息，请参阅操作/运行器存储库中[最新版本](https://github.com/actions/runner/releases/latest)的安装说明。
 {% endif %}
diff --git a/translations/zh-CN/content/actions/hosting-your-own-runners/running-scripts-before-or-after-a-job.md b/translations/zh-CN/content/actions/hosting-your-own-runners/running-scripts-before-or-after-a-job.md
index 708b440e80fd..296cef3b67d2 100644
--- a/translations/zh-CN/content/actions/hosting-your-own-runners/running-scripts-before-or-after-a-job.md
+++ b/translations/zh-CN/content/actions/hosting-your-own-runners/running-scripts-before-or-after-a-job.md
@@ -21,21 +21,21 @@ ms.locfileid: '147067648'
 
 ## 关于作业前脚本和作业后脚本
 
-可在作业运行之前或在作业完成运行之后，在自托管运行器上自动执行脚本。 可使用这些脚本来满足作业需求，例如生成或关闭运行器环境，或清理目录。 还可使用这些脚本来跟踪运行器使用情况的遥测数据。
+可在作业运行之前或在作业完成运行之后，在自托管运行器上自动执行脚本。可使用这些脚本来满足作业需求，例如生成或关闭运行器环境，或清理目录。还可使用这些脚本来跟踪运行器使用情况的遥测数据。
 
-当运行器上设置了特定环境变量时，自定义脚本会自动触发；环境变量必须包含该脚本的绝对路径。 有关详细信息，请参阅下面的“[触发脚本](#triggering-the-scripts)”。
+当运行器上设置了特定环境变量时，自定义脚本会自动触发；环境变量必须包含该脚本的绝对路径。有关详细信息，请参阅下面的“[触发脚本](#triggering-the-scripts)”。
 
 支持以下脚本语言：
 
-- **Bash**：使用 `bash` 并可以回退到 `sh`。 通过运行 `-e {pathtofile}` 执行。
-- **PowerShell**：使用 `pwsh` 并可以回退到 `powershell`。 通过运行 `-command \". '{pathtofile}'\"` 执行。
+- **Bash**：使用 `bash` 并可以回退到 `sh`。通过运行 `-e {pathtofile}` 执行。
+- **PowerShell**：使用 `pwsh` 并可以回退到 `powershell`。通过运行 `-command \". '{pathtofile}'\"` 执行。
 
 ## 编写脚本
 
 自定义脚本可以使用以下功能：
 
-- **环境变量**：脚本有权访问默认环境变量。 完整的 Webhook 事件有效负载可在 `GITHUB_EVENT_PATH` 中找到。 有关详细信息，请参阅“[环境变量](/actions/learn-github-actions/environment-variables#default-environment-variables)”。
-- **工作流命令**：脚本可以使用工作流命令。 有关详细信息，请参阅[“{% data variables.product.prodname_actions %} 的工作流命令”](/actions/using-workflows/workflow-commands-for-github-actions)，`save-state` 和 `set-output` 除外（这些脚本不支持）。 脚本还可以使用环境文件。 有关详细信息，请参阅“[环境文件](/actions/using-workflows/workflow-commands-for-github-actions#environment-files)”。
+- **环境变量**：脚本有权访问默认环境变量。完整的 Webhook 事件有效负载可在 `GITHUB_EVENT_PATH` 中找到。有关详细信息，请参阅“[环境变量](/actions/learn-github-actions/environment-variables#default-environment-variables)”。
+- **工作流命令**：脚本可以使用工作流命令。有关详细信息，请参阅[“{% data variables.product.prodname_actions %} 的工作流命令”](/actions/using-workflows/workflow-commands-for-github-actions)，`save-state` 和 `set-output` 除外（这些脚本不支持）。脚本还可以使用环境文件。有关详细信息，请参阅“[环境文件](/actions/using-workflows/workflow-commands-for-github-actions#environment-files)”。
 
 {% note %}
 
@@ -45,13 +45,13 @@ ms.locfileid: '147067648'
 
 ### 处理退出代码
 
-对于作业前脚本，退出代码 `0` 指示脚本成功完成并且作业随后继续运行。 如果存在任何其他退出代码，该作业将不会运行，并标记为失败。 要查看作业前脚本的结果，请检查日志中的 `Set up runner` 条目。 有关检查日志的详细信息，请参阅“[查看日志以诊断故障](/actions/monitoring-and-troubleshooting-workflows/using-workflow-run-logs#viewing-logs-to-diagnose-failures)”。
+对于作业前脚本，退出代码 `0` 指示脚本成功完成并且作业随后继续运行。如果存在任何其他退出代码，该作业将不会运行，并标记为失败。要查看作业前脚本的结果，请检查日志中的 `Set up runner` 条目。有关检查日志的详细信息，请参阅“[查看日志以诊断故障](/actions/monitoring-and-troubleshooting-workflows/using-workflow-run-logs#viewing-logs-to-diagnose-failures)”。
 
 这些脚本不支持使用 [`continue-on-error`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idcontinue-on-error) 设置。
 
 ## 触发脚本
 
-自定义脚本必须位于运行器上，但不应存储在 `actions-runner` 应用程序目录中。 脚本在运行运行器服务的服务帐户的安全性上下文中执行。
+自定义脚本必须位于运行器上，但不应存储在 `actions-runner` 应用程序目录中。脚本在运行运行器服务的服务帐户的安全性上下文中执行。
 
 {% note %}
 
@@ -63,7 +63,7 @@ ms.locfileid: '147067648'
 - `ACTIONS_RUNNER_HOOK_JOB_STARTED`：此环境变量中定义的脚本在作业分配给运行器之后且作业开始运行之前触发。
 - `ACTIONS_RUNNER_HOOK_JOB_COMPLETED`：此环境变量中定义的脚本在作业完成处理后触发。
 
-要设置这些环境变量，可将它们添加到操作系统中，或将它们添加到自托管运行器应用程序目录中名为 `.env` 的文件中。 例如，以下 `.env` 条目将使运行器在每个作业运行之前自动运行一个名为 `cleanup_script.sh` 的脚本：
+要设置这些环境变量，可将它们添加到操作系统中，或将它们添加到自托管运行器应用程序目录中名为 `.env` 的文件中。例如，以下 `.env` 条目将使运行器在每个作业运行之前自动运行一个名为 `cleanup_script.sh` 的脚本：
 
 ```bash
 ACTIONS_RUNNER_HOOK_JOB_STARTED=/cleanup_script.sh
@@ -74,8 +74,8 @@ ACTIONS_RUNNER_HOOK_JOB_STARTED=/cleanup_script.sh
 
 ### 无超时设置
 
-目前没有可供 `ACTIONS_RUNNER_HOOK_JOB_STARTED` 或 `ACTIONS_RUNNER_HOOK_JOB_COMPLETED` 执行的脚本使用的超时设置。 因此，可以考虑向脚本添加超时处理。
+目前没有可供 `ACTIONS_RUNNER_HOOK_JOB_STARTED` 或 `ACTIONS_RUNNER_HOOK_JOB_COMPLETED` 执行的脚本使用的超时设置。因此，可以考虑向脚本添加超时处理。
 
 ### 查看工作流运行日志
 
-要确认脚本是否正在执行，可查看该作业的日志。 脚本将在 `Set up runner` 或 `Complete runner` 的单独步骤中列出，具体取决于触发脚本的环境变量。 有关检查日志的详细信息，请参阅“[查看日志以诊断故障](/actions/monitoring-and-troubleshooting-workflows/using-workflow-run-logs#viewing-logs-to-diagnose-failures)”。
+要确认脚本是否正在执行，可查看该作业的日志。脚本将在 `Set up runner` 或 `Complete runner` 的单独步骤中列出，具体取决于触发脚本的环境变量。有关检查日志的详细信息，请参阅“[查看日志以诊断故障](/actions/monitoring-and-troubleshooting-workflows/using-workflow-run-logs#viewing-logs-to-diagnose-failures)”。
diff --git a/translations/zh-CN/content/actions/hosting-your-own-runners/using-a-proxy-server-with-self-hosted-runners.md b/translations/zh-CN/content/actions/hosting-your-own-runners/using-a-proxy-server-with-self-hosted-runners.md
index cc391ef1f020..6005941a5b23 100644
--- a/translations/zh-CN/content/actions/hosting-your-own-runners/using-a-proxy-server-with-self-hosted-runners.md
+++ b/translations/zh-CN/content/actions/hosting-your-own-runners/using-a-proxy-server-with-self-hosted-runners.md
@@ -23,27 +23,27 @@ ms.locfileid: '145086683'
 
 如果需要一个自托管运行器来通过代理服务器通信，则自托管运行器应用程序使用在以下环境变量中设置的代理配置：
 
-* `https_proxy`：HTTPS 流量的代理 URL。 如果需要，您也可以包括基本验证凭据。 例如：
+* `https_proxy`：HTTPS 流量的代理 URL。如果需要，您也可以包括基本验证凭据。例如：
   * `http://proxy.local`
   * `http://192.168.1.1:8080`
   * `http://username:password@proxy.local`
-* `http_proxy`：HTTP 流量的代理 URL。 如果需要，您也可以包括基本验证凭据。 例如：
+* `http_proxy`：HTTP 流量的代理 URL。如果需要，您也可以包括基本验证凭据。例如：
   * `http://proxy.local`
   * `http://192.168.1.1:8080`
   * `http://username:password@proxy.local`
-* `no_proxy`：不应使用代理的主机的逗号分隔列表。 `no_proxy` 中只允许使用主机名，不能使用 IP 地址。 例如：
+* `no_proxy`：不应使用代理的主机的逗号分隔列表。 `no_proxy` 中只允许使用主机名，不能使用 IP 地址。例如：
   * `example.com`
   * `example.com,myserver.local:443,example.org`
 
-当自托管运行器应用程序启动时，会读取代理环境变量，因此您必须在配置或启动自托管运行器应用程序之前设置环境变量。 如果代理配置发生更改，则必须重启自托管运行程序应用程序。
+当自托管运行器应用程序启动时，会读取代理环境变量，因此您必须在配置或启动自托管运行器应用程序之前设置环境变量。如果代理配置发生更改，则必须重启自托管运行程序应用程序。
 
-在 Windows 机器上，代理环境变量名称不区分大小写。 在 Linux 和 macOS 机器上，建议环境变量全部小写。 如果 Linux 或 macOS 上的环境变量具有小写和大写形式（例如 `https_proxy` 和 `HTTPS_PROXY`），自托管运行程序应用程序会使用小写环境变量。
+在 Windows 机器上，代理环境变量名称不区分大小写。在 Linux 和 macOS 机器上，建议环境变量全部小写。如果 Linux 或 macOS 上的环境变量具有小写和大写形式（例如 `https_proxy` 和 `HTTPS_PROXY`），自托管运行程序应用程序会使用小写环境变量。
 
 {% data reusables.actions.self-hosted-runner-ports-protocols %}
 
 ## 使用 .env 文件设置代理配置
 
-如果设置环境变量不可行，可以在自托管运行器应用程序目录中名为 .env 的文件中设置代理配置变量。 例如，如果您想要将运行器应用程序配置为系统帐户下的服务，这可能是必需的。 当运行器应用程序启动时，它会读取代理 .env 中为代理配置设置的变量。
+如果设置环境变量不可行，可以在自托管运行器应用程序目录中名为 .env 的文件中设置代理配置变量。例如，如果您想要将运行器应用程序配置为系统帐户下的服务，这可能是必需的。当运行器应用程序启动时，它会读取代理 .env 中为代理配置设置的变量。
 
 示例 .env 代理配置如下所示：
 
@@ -54,6 +54,6 @@ no_proxy=example.com,myserver.local:443
 
 ## 设置 Docker 容器的代理配置
 
-如果您在工作流程中使用 Docker 容器操作或服务容器，则除了设置上述环境变量外，可能还需要配置 Docker来使用代理服务器。
+如果您在工作流程中使用 Docker 容器操作或服务容器，则除了设置上述环境变量外，可能还需要配置 Docker 来使用代理服务器。
 
 有关所需 Docker 配置的信息，请参阅 Docker 文档中的“[配置 Docker 以使用代理服务器](https://docs.docker.com/network/proxy/)”。
diff --git a/translations/zh-CN/content/actions/hosting-your-own-runners/using-self-hosted-runners-in-a-workflow.md b/translations/zh-CN/content/actions/hosting-your-own-runners/using-self-hosted-runners-in-a-workflow.md
index 6123bda643f4..207cdc6c6288 100644
--- a/translations/zh-CN/content/actions/hosting-your-own-runners/using-self-hosted-runners-in-a-workflow.md
+++ b/translations/zh-CN/content/actions/hosting-your-own-runners/using-self-hosted-runners-in-a-workflow.md
@@ -24,7 +24,7 @@ ms.locfileid: '147573415'
 
 ## 在工作流中使用自托管运行程序
 
-标签允许您根据其共同特征向特定类型的自托管运行器发送工作流程作业。 例如，如果您的作业需要特定的硬件组件或软件包。 您可以将一个自定义标签分配给运行器，然后将您的作业配置为仅在带该标签的运行器中执行。
+标签允许您根据其共同特征向特定类型的自托管运行器发送工作流程作业。例如，如果您的作业需要特定的硬件组件或软件包。您可以将一个自定义标签分配给运行器，然后将您的作业配置为仅在带该标签的运行器中执行。
 
 {% data reusables.actions.self-hosted-runner-labels-runs-on %}
 
@@ -32,13 +32,13 @@ ms.locfileid: '147573415'
 
 ## 使用默认标签路由作业
 
-在被添加到 {% data variables.product.prodname_actions %} 后，自托管运行器将自动收到某些标签。 这些被用于指出其操作系统和硬件平台：
+在被添加到 {% data variables.product.prodname_actions %} 后，自托管运行器将自动收到某些标签。这些被用于指出其操作系统和硬件平台：
 
 * `self-hosted`：应用于所有自托管运行器的默认标签
 * `linux`、`windows` 或 `macOS`：根据操作系统应用。
 * `x64`、`ARM` 或 `ARM64`：根据硬件体系结构应用。
 
-您可以使用您工作流程的 YAML 将作业发送到这些标签的组合。 在此示例中，与所有三个标签匹配的自托管运行器将有资格运行该作业：
+您可以使用您工作流程的 YAML 将作业发送到这些标签的组合。在此示例中，与所有三个标签匹配的自托管运行器将有资格运行该作业：
 
 ```yaml
 runs-on: [self-hosted, linux, ARM64]
@@ -48,13 +48,13 @@ runs-on: [self-hosted, linux, ARM64]
 - `linux` - 仅使用基于 Linux 的运行器。
 - `ARM64` - 仅使用基于 ARM64 硬件的运行器。
 
-默认标签是固定的，无法更改或删除。 如果您需要对作业路由的更多控制，考虑使用自定义标签。
+默认标签是固定的，无法更改或删除。如果您需要对作业路由的更多控制，考虑使用自定义标签。
 
 ## 使用自定义标签路由作业
 
-您可以随时创建自定义标签并将其分配给您的自托管运行器。 自定义标签允许您根据其标注将作业发送给特定的自托管运行器类型。 
+您可以随时创建自定义标签并将其分配给您的自托管运行器。自定义标签允许您根据其标注将作业发送给特定的自托管运行器类型。 
 
-例如，如果某个作业需要特定类型的图形硬件，则可以创建名为 `gpu` 的自定义标签，并将其分配给安装了该硬件的运行器。 然后，与所有已分配的标签匹配的自托管运行器将有资格运行该作业。 
+例如，如果某个作业需要特定类型的图形硬件，则可以创建名为 `gpu` 的自定义标签，并将其分配给安装了该硬件的运行器。然后，与所有已分配的标签匹配的自托管运行器将有资格运行该作业。 
 
 此示例显示组合默认标签和自定义标签的作业：
 
diff --git a/translations/zh-CN/content/actions/index.md b/translations/zh-CN/content/actions/index.md
index 0f778768ac45..6950f54f268a 100644
--- a/translations/zh-CN/content/actions/index.md
+++ b/translations/zh-CN/content/actions/index.md
@@ -1,7 +1,7 @@
 ---
-title: GitHub Actions文档
+title: GitHub Actions 文档
 shortTitle: GitHub Actions
-intro: '在 {% data variables.product.prodname_actions %} 的仓库中自动化、自定义和执行软件开发工作流程。 您可以发现、创建和共享操作以执行您喜欢的任何作业（包括 CI/CD），并将操作合并到完全自定义的工作流程中。'
+intro: '在 {% data variables.product.prodname_actions %} 的仓库中自动化、自定义和执行软件开发工作流程。您可以发现、创建和共享操作以执行您喜欢的任何作业（包括 CI/CD），并将操作合并到完全自定义的工作流程中。'
 introLinks:
   overview: /actions/learn-github-actions/understanding-github-actions
   quickstart: /actions/quickstart
diff --git a/translations/zh-CN/content/actions/learn-github-actions/essential-features-of-github-actions.md b/translations/zh-CN/content/actions/learn-github-actions/essential-features-of-github-actions.md
index 10577a134b33..db8afdc9c2cf 100644
--- a/translations/zh-CN/content/actions/learn-github-actions/essential-features-of-github-actions.md
+++ b/translations/zh-CN/content/actions/learn-github-actions/essential-features-of-github-actions.md
@@ -1,7 +1,7 @@
 ---
 title: GitHub Actions 的基本功能
 shortTitle: Essential features
-intro: '{% data variables.product.prodname_actions %} 旨在帮助您建立强大而动态的自动化。 本指南说明如何创建包括环境变量、定制化脚本等的 {% data variables.product.prodname_actions %} 工作流程。'
+intro: '{% data variables.product.prodname_actions %} 旨在帮助您建立强大而动态的自动化。本指南说明如何创建包括环境变量、定制化脚本等的 {% data variables.product.prodname_actions %} 工作流程。'
 versions:
   fpt: '*'
   ghes: '*'
@@ -21,11 +21,11 @@ ms.locfileid: '145067023'
 
 ## 概述
 
-{% data variables.product.prodname_actions %} 允许您自定义工作流程，以满足应用程序和团队的独特需求。 在本指南中，我们将讨论一些基本的自定义技术，例如使用变量、运行脚本以及在作业之间共享数据和构件。
+{% data variables.product.prodname_actions %} 允许您自定义工作流程，以满足应用程序和团队的独特需求。在本指南中，我们将讨论一些基本的自定义技术，例如使用变量、运行脚本以及在作业之间共享数据和构件。
 
 ##  在工作流程中使用变量
 
-{% data variables.product.prodname_actions %} 包含每个工作流程运行的默认环境变量。 如果您需要使用自定义环境变量，可以在 YAML 工作流程文件中设置这些变量。 此示例演示如何创建名为 `POSTGRES_HOST` 和 `POSTGRES_PORT` 的自定义变量。 然后，这些变量可供 `node client.js` 脚本使用。
+{% data variables.product.prodname_actions %} 包含每个工作流程运行的默认环境变量。如果您需要使用自定义环境变量，可以在 YAML 工作流程文件中设置这些变量。此示例演示如何创建名为 `POSTGRES_HOST` 和 `POSTGRES_PORT` 的自定义变量。然后，这些变量可供 `node client.js` 脚本使用。
 
 ```yaml
 jobs:
@@ -42,7 +42,7 @@ jobs:
 
 ## 添加脚本到工作流程
 
-您可以使用操作来运行脚本和 shell 命令，然后在指定的运行器上执行。 此示例演示操作如何使用 `run` 关键字在运行器上执行 `npm install -g bats`。
+您可以使用操作来运行脚本和 shell 命令，然后在指定的运行器上执行。此示例演示操作如何使用 `run` 关键字在运行器上执行 `npm install -g bats`。
 
 ```yaml
 jobs:
@@ -66,7 +66,7 @@ jobs:
 
 ## 在作业之间共享数据
 
-如果作业生成你要与同一工作流中的另一个作业共享的文件，或者你要保存这些文件供以后参考，则可以将它们作为工件存储在 {% data variables.product.prodname_dotcom %} 中。 构件是创建并测试代码时所创建的文件。 例如，构件可能包含二进制或包文件、测试结果、屏幕截图或日志文件。 构件与其创建时所在的工作流程运行相关，可被另一个作业使用。 {% data reusables.actions.reusable-workflow-artifacts %}
+如果作业生成你要与同一工作流中的另一个作业共享的文件，或者你要保存这些文件供以后参考，则可以将它们作为工件存储在 {% data variables.product.prodname_dotcom %} 中。构件是创建并测试代码时所创建的文件。例如，构件可能包含二进制或包文件、测试结果、屏幕截图或日志文件。构件与其创建时所在的工作流程运行相关，可被另一个作业使用。 {% data reusables.actions.reusable-workflow-artifacts %}
 
 例如，您可以创建一个文件，然后将其作为构件上传。
 
@@ -85,7 +85,7 @@ jobs:
           path: output.log
 ```
 
-若要从单独的工作流运行中下载工件，可以使用 `actions/download-artifact` 操作。 例如，可以下载名为 `output-log-file` 的工件。
+若要从单独的工作流运行中下载工件，可以使用 `actions/download-artifact` 操作。例如，可以下载名为 `output-log-file` 的工件。
 
 ```yaml
 jobs:
diff --git a/translations/zh-CN/content/actions/learn-github-actions/usage-limits-billing-and-administration.md b/translations/zh-CN/content/actions/learn-github-actions/usage-limits-billing-and-administration.md
index 01da403b1012..4dacec0f15e1 100644
--- a/translations/zh-CN/content/actions/learn-github-actions/usage-limits-billing-and-administration.md
+++ b/translations/zh-CN/content/actions/learn-github-actions/usage-limits-billing-and-administration.md
@@ -1,6 +1,6 @@
 ---
 title: 使用限制、计费和管理
-intro: '{% data variables.product.prodname_actions %} 工作流程有使用限制。 使用费适用于超出仓库免费分钟数和存储空间量的仓库。'
+intro: '{% data variables.product.prodname_actions %} 工作流程有使用限制。使用费适用于超出仓库免费分钟数和存储空间量的仓库。'
 redirect_from:
   - /actions/getting-started-with-github-actions/usage-and-billing-information-for-github-actions
   - /actions/reference/usage-limits-billing-and-administration
@@ -25,7 +25,7 @@ ms.locfileid: '146681003'
 {% data reusables.repositories.about-github-actions %} 有关详细信息，请参阅“[了解 {% data variables.product.prodname_actions %}](/actions/learn-github-actions/understanding-github-actions){% ifversion fpt %}."{% elsif ghes or ghec %}”和“[关于适用于企业的 {% data variables.product.prodname_actions %}](/admin/github-actions/getting-started-with-github-actions-for-your-enterprise/about-github-actions-for-enterprises)”。{% endif %}
 
 {% ifversion fpt or ghec %} {% data reusables.actions.actions-billing %} 有关详细信息，请参阅“[关于 {% data variables.product.prodname_actions %} 的计费](/billing/managing-billing-for-github-actions/about-billing-for-github-actions)”。
-{% else %} 对于使用自托管运行器的 {% data variables.product.prodname_ghe_server %} 实例，GitHub Actions 的使用是免费的。 有关详细信息，请参阅[关于自承载运行器](/actions/hosting-your-own-runners/about-self-hosted-runners)。
+{% else %} 对于使用自托管运行器的 {% data variables.product.prodname_ghe_server %} 实例，GitHub Actions 的使用是免费的。有关详细信息，请参阅[关于自承载运行器](/actions/hosting-your-own-runners/about-self-hosted-runners)。
 {% endif %}
 
 
@@ -39,17 +39,17 @@ ms.locfileid: '146681003'
 
 ## 使用限制
 
-{% ifversion fpt or ghec %} 使用 {% data variables.product.prodname_dotcom %} 托管的运行器时，{% data variables.product.prodname_actions %} 的使用存在一些限制。 这些限制可能会有变动。
+{% ifversion fpt or ghec %} 使用 {% data variables.product.prodname_dotcom %} 托管的运行器时，{% data variables.product.prodname_actions %} 的使用存在一些限制。这些限制可能会有变动。
 
 {% note %}
 
-注意：对于自托管的运行器，会应用不同的使用限制。 有关详细信息，请参阅[关于自承载运行器](/actions/hosting-your-own-runners/about-self-hosted-runners/#usage-limits)。
+注意：对于自托管的运行器，会应用不同的使用限制。有关详细信息，请参阅[关于自承载运行器](/actions/hosting-your-own-runners/about-self-hosted-runners/#usage-limits)。
 
 {% endnote %}
 
-- 作业执行时间 - 工作流中每个作业的最长执行时间为 6 小时。 如果作业达到此限制，该作业将会终止而无法完成。
+- 作业执行时间 - 工作流中每个作业的最长执行时间为 6 小时。如果作业达到此限制，该作业将会终止而无法完成。
 {% data reusables.actions.usage-workflow-run-time %} {% data reusables.actions.usage-api-requests %}
-- 并发作业 - 帐户中可以运行的并发作业数量，具体视 GitHub 计划而定，如下表所示。 如果超出，任何额外的作业都会排队。
+- 并发作业 - 帐户中可以运行的并发作业数量，具体视 GitHub 计划而定，如下表所示。如果超出，任何额外的作业都会排队。
 
   | GitHub 计划 | 同时运行的作业总数 | MacOS 作业同时运行的最大数量 |
   |---|---|---|
@@ -60,18 +60,18 @@ ms.locfileid: '146681003'
 
   {% note %}
 
-  注意：如果需要，使用企业计划的客户可请求更高的并发作业限制。 有关详细信息，请联系 {% data variables.contact.contact_ent_support %} 或销售代表。
+  注意：如果需要，使用企业计划的客户可请求更高的并发作业限制。有关详细信息，请联系 {% data variables.contact.contact_ent_support %} 或销售代表。
 
   {% endnote %}
 - 作业矩阵 - {% data reusables.actions.usage-matrix-limits %} {% data reusables.actions.usage-workflow-queue-limits %}
 
-{% else %} 使用限制适用于自托管运行器。 有关详细信息，请参阅[关于自承载运行器](/actions/hosting-your-own-runners/about-self-hosted-runners/#usage-limits)。
+{% else %} 使用限制适用于自托管运行器。有关详细信息，请参阅[关于自承载运行器](/actions/hosting-your-own-runners/about-self-hosted-runners/#usage-limits)。
 {% endif %}
 
 {% ifversion fpt or ghec %}
 ## 使用策略
 
-除了使用限制外，还必须确保在 [GitHub 服务条款](/free-pro-team@latest/github/site-policy/github-terms-of-service/)规定的范围内使用 {% data variables.product.prodname_actions %}。 有关 {% data variables.product.prodname_actions %} 特定条款的详细信息，请参阅 [GitHub 附加产品条款](/free-pro-team@latest/github/site-policy/github-additional-product-terms#a-actions-usage)。
+除了使用限制外，还必须确保在 [GitHub 服务条款](/free-pro-team@latest/github/site-policy/github-terms-of-service/)规定的范围内使用 {% data variables.product.prodname_actions %}。有关 {% data variables.product.prodname_actions %} 特定条款的详细信息，请参阅 [GitHub 附加产品条款](/free-pro-team@latest/github/site-policy/github-additional-product-terms#a-actions-usage)。
 {% endif %}
 
 {% ifversion fpt or ghes > 3.3 or ghec %}
@@ -79,7 +79,7 @@ ms.locfileid: '146681003'
 
 {% data reusables.actions.reusable-workflows-ghes-beta %}
 
-如果重复使用工作流，则计费始终与调用方工作流程相关联。 始终仅使用调用方的上下文来评估 {% data variables.product.prodname_dotcom %} 托管的运行器的分配。 调用方不能使用被调用存储库中 {% data variables.product.prodname_dotcom %} 托管的运行器。 
+如果重复使用工作流，则计费始终与调用方工作流程相关联。始终仅使用调用方的上下文来评估 {% data variables.product.prodname_dotcom %} 托管的运行器的分配。调用方不能使用被调用存储库中 {% data variables.product.prodname_dotcom %} 托管的运行器。 
 
 有关详细信息，请参阅“[重用工作流](/actions/learn-github-actions/reusing-workflows)”。
 {% endif %}
diff --git a/translations/zh-CN/content/actions/managing-issues-and-pull-requests/adding-labels-to-issues.md b/translations/zh-CN/content/actions/managing-issues-and-pull-requests/adding-labels-to-issues.md
index 7481610968b4..c575a0b3dba6 100644
--- a/translations/zh-CN/content/actions/managing-issues-and-pull-requests/adding-labels-to-issues.md
+++ b/translations/zh-CN/content/actions/managing-issues-and-pull-requests/adding-labels-to-issues.md
@@ -23,9 +23,9 @@ ms.locfileid: '147884307'
 
 ## 简介
 
-本教程演示如何使用工作流中的 [`andymckay/labeler` 操作](https://github.com/marketplace/actions/simple-issue-labeler) 来标记新打开或重新打开的问题。 例如，每次打开或重新打开问题时，都可以添加 `triage` 标签。 然后，可通过筛选具有 `triage` 标签的问题来查看需要会审的问题。
+本教程演示如何使用工作流中的 [`andymckay/labeler` 操作](https://github.com/marketplace/actions/simple-issue-labeler) 来标记新打开或重新打开的问题。例如，每次打开或重新打开问题时，都可以添加 `triage` 标签。然后，可通过筛选具有 `triage` 标签的问题来查看需要会审的问题。
 
-在本教程中，你将首先创建一个使用 [`andymckay/labeler` 操作](https://github.com/marketplace/actions/simple-issue-labeler)的工作流文件。 然后，您将自定义工作流以适应您的需要。
+在本教程中，你将首先创建一个使用 [`andymckay/labeler` 操作](https://github.com/marketplace/actions/simple-issue-labeler)的工作流文件。然后，您将自定义工作流以适应您的需要。
 
 ## 创建工作流程
 
@@ -58,7 +58,7 @@ ms.locfileid: '147884307'
     ```
 
 4. 自定义工工作流程文件中的参数：
-   - 将 `add-labels` 的值更改为你想要添加到此问题的标签列表。 使用逗号分隔多个标签。 例如 `"help wanted, good first issue"`。 有关标签的详细信息，请参阅[管理标签](/github/managing-your-work-on-github/managing-labels#applying-labels-to-issues-and-pull-requests)。
+   - 将 `add-labels` 的值更改为你想要添加到此问题的标签列表。使用逗号分隔多个标签。例如 `"help wanted, good first issue"`。有关标签的详细信息，请参阅[管理标签](/github/managing-your-work-on-github/managing-labels#applying-labels-to-issues-and-pull-requests)。
 5. {% data reusables.actions.commit-workflow %}
 
 ## 测试工作流程
@@ -67,8 +67,8 @@ ms.locfileid: '147884307'
 
 通过在仓库中创建议题来测试工作流程。
 
-1. 在仓库中创建议题。 有关详细信息，请参阅[创建问题](/github/managing-your-work-on-github/creating-an-issue)。
-2. 要查看通过创建议题所触发的工作流程运行，请查看工作流程运行的历史记录。 有关详细信息，请参阅“[查看工作流运行历史记录](/actions/managing-workflow-runs/viewing-workflow-run-history)”。
+1. 在仓库中创建议题。有关详细信息，请参阅[创建问题](/github/managing-your-work-on-github/creating-an-issue)。
+2. 要查看通过创建议题所触发的工作流程运行，请查看工作流程运行的历史记录。有关详细信息，请参阅“[查看工作流运行历史记录](/actions/managing-workflow-runs/viewing-workflow-run-history)”。
 3. 当工作流程完成时，您创建的议题应已添加指定的标签。
 
 ## 后续步骤
diff --git a/translations/zh-CN/content/actions/managing-issues-and-pull-requests/closing-inactive-issues.md b/translations/zh-CN/content/actions/managing-issues-and-pull-requests/closing-inactive-issues.md
index 2511c1aabbb3..ba077b8070da 100644
--- a/translations/zh-CN/content/actions/managing-issues-and-pull-requests/closing-inactive-issues.md
+++ b/translations/zh-CN/content/actions/managing-issues-and-pull-requests/closing-inactive-issues.md
@@ -23,9 +23,9 @@ ms.locfileid: '147063608'
 
 ## 简介
 
-本教程演示如何使用 [`actions/stale` 操作](https://github.com/marketplace/actions/close-stale-issues)来评论和关闭在一段时间内处于非活动状态的问题。 例如，如果某个议题 30 天内未活动，您可以添加评论以促使参与者采取行动。 然后，如果 14 天后没有其他活动发生，您可以关闭此议题。
+本教程演示如何使用 [`actions/stale` 操作](https://github.com/marketplace/actions/close-stale-issues)来评论和关闭在一段时间内处于非活动状态的问题。例如，如果某个议题 30 天内未活动，您可以添加评论以促使参与者采取行动。然后，如果 14 天后没有其他活动发生，您可以关闭此议题。
 
-在本教程中，你将首先创建一个使用 [`actions/stale` 操作](https://github.com/marketplace/actions/close-stale-issues)的工作流文件。 然后，您将自定义工作流以适应您的需要。
+在本教程中，你将首先创建一个使用 [`actions/stale` 操作](https://github.com/marketplace/actions/close-stale-issues)的工作流文件。然后，您将自定义工作流以适应您的需要。
 
 ## 创建工作流程
 
@@ -59,9 +59,9 @@ ms.locfileid: '147063608'
     ```
 
 4. 自定义工工作流程文件中的参数：
-   - 更改 `on.schedule` 的值以指示你希望何时运行此工作流。 在上面的示例中，工作流将于每天 1:30 UTC 运行。 有关计划工作流的详细信息，请参阅“[计划事件](/actions/reference/events-that-trigger-workflows#scheduled-events)”。
-   - 将 `days-before-issue-stale` 的值更改为在 `actions/stale` 操作标记问题之前没有活动的天数。 如果你不希望此操作标记问题，请将此值设置为 `-1`。
-   - 将 `days-before-issue-close` 的值更改为在 `actions/stale` 操作关闭问题之前没有活动的天数。 如果你不希望此操作关闭问题，请将此值设置为 `-1`。
+   - 更改 `on.schedule` 的值以指示你希望何时运行此工作流。在上面的示例中，工作流将于每天 1:30 UTC 运行。有关计划工作流的详细信息，请参阅“[计划事件](/actions/reference/events-that-trigger-workflows#scheduled-events)”。
+   - 将 `days-before-issue-stale` 的值更改为在 `actions/stale` 操作标记问题之前没有活动的天数。如果你不希望此操作标记问题，请将此值设置为 `-1`。
+   - 将 `days-before-issue-close` 的值更改为在 `actions/stale` 操作关闭问题之前没有活动的天数。如果你不希望此操作关闭问题，请将此值设置为 `-1`。
    - 将 `stale-issue-label` 的值更改为要应用于在 `days-before-issue-stale` 指定的时间量内处于非活动状态的问题的标签。
    - 将 `stale-issue-message` 的值更改为要添加到由 `actions/stale` 操作标记的问题的注释。
    - 将 `close-issue-message` 的值更改为要添加到由 `actions/stale` 操作关闭的问题的注释。
@@ -69,13 +69,13 @@ ms.locfileid: '147063608'
 
 ## 预期结果
 
-根据 `schedule` 参数（例如，每天 1:30 UTC），你的工作流将发现在指定时间段内处于非活动状态的问题，并将添加指定的注释和标签。 此外，如果在指定时间段内未发生其他活动，您的工作流程将关闭任何以前标记的议题。
+根据 `schedule` 参数（例如，每天 1:30 UTC），你的工作流将发现在指定时间段内处于非活动状态的问题，并将添加指定的注释和标签。此外，如果在指定时间段内未发生其他活动，您的工作流程将关闭任何以前标记的议题。
 
 {% data reusables.actions.schedule-delay %}
 
-您可以查看工作流程运行的历史记录，以便定期查看此工作流程运行。 有关详细信息，请参阅“[查看工作流运行历史记录](/actions/managing-workflow-runs/viewing-workflow-run-history)”。
+您可以查看工作流程运行的历史记录，以便定期查看此工作流程运行。有关详细信息，请参阅“[查看工作流运行历史记录](/actions/managing-workflow-runs/viewing-workflow-run-history)”。
 
-为了避免超过速率限制，此工作流程将一次只标记和/或关闭 30 个议题。 可以使用 `operations-per-run` 设置进行配置。 有关详细信息，请参阅 [`actions/stale` 操作文档](https://github.com/marketplace/actions/close-stale-issues)。
+为了避免超过速率限制，此工作流程将一次只标记和/或关闭 30 个议题。可以使用 `operations-per-run` 设置进行配置。有关详细信息，请参阅 [`actions/stale` 操作文档](https://github.com/marketplace/actions/close-stale-issues)。
 
 ## 后续步骤
 
diff --git a/translations/zh-CN/content/actions/managing-issues-and-pull-requests/commenting-on-an-issue-when-a-label-is-added.md b/translations/zh-CN/content/actions/managing-issues-and-pull-requests/commenting-on-an-issue-when-a-label-is-added.md
index 0ebd3298984b..7b66bab15b00 100644
--- a/translations/zh-CN/content/actions/managing-issues-and-pull-requests/commenting-on-an-issue-when-a-label-is-added.md
+++ b/translations/zh-CN/content/actions/managing-issues-and-pull-requests/commenting-on-an-issue-when-a-label-is-added.md
@@ -24,9 +24,9 @@ ms.locfileid: '147409035'
 
 ## 简介
 
-本教程演示如何在应用特定标签时使用 [`peter-evans/create-or-update-comment` 操作](https://github.com/marketplace/actions/create-or-update-comment) 对问题添加注释。 例如，当 `help-wanted` 标签添加到问题中后，可以添加注释来建议参与者处理该问题。
+本教程演示如何在应用特定标签时使用 [`peter-evans/create-or-update-comment` 操作](https://github.com/marketplace/actions/create-or-update-comment) 对问题添加注释。例如，当 `help-wanted` 标签添加到问题中后，可以添加注释来建议参与者处理该问题。
 
-在本教程中，你将首先创建一个使用 [`peter-evans/create-or-update-comment` 操作](https://github.com/marketplace/actions/create-or-update-comment)的工作流文件。 然后，您将自定义工作流以适应您的需要。
+在本教程中，你将首先创建一个使用 [`peter-evans/create-or-update-comment` 操作](https://github.com/marketplace/actions/create-or-update-comment)的工作流文件。然后，您将自定义工作流以适应您的需要。
 
 ## 创建工作流程
 
@@ -60,19 +60,19 @@ ms.locfileid: '147409035'
     ```
 
 4. 自定义工工作流程文件中的参数：
-   - 将 `if: github.event.label.name == 'help-wanted'` 中的 `help-wanted` 替换为要处理的标签。 如果想要在多个标签上操作，请使用 `||` 分隔条件。 例如，`if: github.event.label.name == 'bug' || github.event.label.name == 'fix me'` 将在 `bug` 或 `fix me` 标签添加到问题时进行注释。
-   - 将 `body` 的值更改为要添加的注释。 支持 GitHub Flavored Markdown。 有关 Markdown 的详细信息，请参阅“[基本编写和格式设置语法](/github/writing-on-github/basic-writing-and-formatting-syntax)”。
+   - 将 `if: github.event.label.name == 'help-wanted'` 中的 `help-wanted` 替换为要处理的标签。如果想要在多个标签上操作，请使用 `||` 分隔条件。例如，`if: github.event.label.name == 'bug' || github.event.label.name == 'fix me'` 将在 `bug` 或 `fix me` 标签添加到问题时进行注释。
+   - 将 `body` 的值更改为要添加的注释。支持 GitHub Flavored Markdown。有关 Markdown 的详细信息，请参阅“[基本编写和格式设置语法](/github/writing-on-github/basic-writing-and-formatting-syntax)”。
 5. {% data reusables.actions.commit-workflow %}
 
 ## 测试工作流程
 
-每当仓库中的问题被标记时，此工作流就会运行。 如果添加的标签是工作流文件中指定的标签之一，`peter-evans/create-or-update-comment` 操作将添加你针对问题指定的注释。
+每当仓库中的问题被标记时，此工作流就会运行。如果添加的标签是工作流文件中指定的标签之一，`peter-evans/create-or-update-comment` 操作将添加你针对问题指定的注释。
 
 通过将指定的标签应用于议题来测试工作流程。
 
-1. 在仓库中打开一个议题。 有关详细信息，请参阅“[创建问题](/github/managing-your-work-on-github/creating-an-issue)”。
-2. 使用工作流程文件中的指定标签标记议题。 有关详细信息，请参阅“[管理标签](/github/managing-your-work-on-github/managing-labels#applying-labels-to-issues-and-pull-requests)”。
-3. 要查看通过标记议题所触发的工作流程运行，请查看工作流程运行的历史记录。 有关详细信息，请参阅“[查看工作流运行历史记录](/actions/managing-workflow-runs/viewing-workflow-run-history)”。
+1. 在仓库中打开一个议题。有关详细信息，请参阅“[创建问题](/github/managing-your-work-on-github/creating-an-issue)”。
+2. 使用工作流程文件中的指定标签标记议题。有关详细信息，请参阅“[管理标签](/github/managing-your-work-on-github/managing-labels#applying-labels-to-issues-and-pull-requests)”。
+3. 要查看通过标记议题所触发的工作流程运行，请查看工作流程运行的历史记录。有关详细信息，请参阅“[查看工作流运行历史记录](/actions/managing-workflow-runs/viewing-workflow-run-history)”。
 4. 当工作流程完成时，您标记的议题应已添加评论。
 
 ## 后续步骤
diff --git a/translations/zh-CN/content/actions/managing-issues-and-pull-requests/moving-assigned-issues-on-project-boards.md b/translations/zh-CN/content/actions/managing-issues-and-pull-requests/moving-assigned-issues-on-project-boards.md
index e0b77637e3b6..a302df3be676 100644
--- a/translations/zh-CN/content/actions/managing-issues-and-pull-requests/moving-assigned-issues-on-project-boards.md
+++ b/translations/zh-CN/content/actions/managing-issues-and-pull-requests/moving-assigned-issues-on-project-boards.md
@@ -24,14 +24,14 @@ ms.locfileid: '147410457'
 
 ## 简介
 
-本教程演示如何在分配问题时使用 [`alex-page/github-project-automation-plus` 操作](https://github.com/marketplace/actions/github-project-automation)自动将问题移至项目板上的特定列。 例如，分配问题后，可以将其移动到项目板的 `In Progress` 列中。
+本教程演示如何在分配问题时使用 [`alex-page/github-project-automation-plus` 操作](https://github.com/marketplace/actions/github-project-automation)自动将问题移至项目板上的特定列。例如，分配问题后，可以将其移动到项目板的 `In Progress` 列中。
 
-在本教程中，你将首先创建一个使用 [`alex-page/github-project-automation-plus` 操作](https://github.com/marketplace/actions/github-project-automation)的工作流文件。 然后，您将自定义工作流以适应您的需要。
+在本教程中，你将首先创建一个使用 [`alex-page/github-project-automation-plus` 操作](https://github.com/marketplace/actions/github-project-automation)的工作流文件。然后，您将自定义工作流以适应您的需要。
 
 ## 创建工作流程
 
 1. {% data reusables.actions.choose-repo %}
-2. 在仓库中，选择项目板。 您可以使用现有项目，也可以创建新项目。 有关如何创建项目的详细信息，请参阅“[创建项目板](/github/managing-your-work-on-github/creating-a-project-board)”。
+2. 在仓库中，选择项目板。您可以使用现有项目，也可以创建新项目。有关如何创建项目的详细信息，请参阅“[创建项目板](/github/managing-your-work-on-github/creating-a-project-board)”。
 3. {% data reusables.actions.make-workflow-file %}
 4. 将以下 YAML 内容复制到工作流程文件中。
 
@@ -57,25 +57,25 @@ ms.locfileid: '147410457'
     ```
 
 5. 自定义工工作流程文件中的参数：
-   - 将 `project` 的值更改为项目板的名称。 如果有多个同名项目板，则 `alex-page/github-project-automation-plus` 操作将对具有指定名称的所有项目执行操作。
+   - 将 `project` 的值更改为项目板的名称。如果有多个同名项目板，则 `alex-page/github-project-automation-plus` 操作将对具有指定名称的所有项目执行操作。
    - 将 `column` 的值更改为要在分配问题时将其移动到的列的名称。
    - 更改 `repo-token` 的值：
-     1. 创建具有 `repo` 作用域的个人访问令牌。 有关详细信息，请参阅“[创建个人访问令牌](/github/authenticating-to-github/creating-a-personal-access-token)”。
-     1. 将此个人访问令牌作为机密存储在仓库中。 有关如何存储机密的详细信息，请参阅“[已加密的机密](/actions/reference/encrypted-secrets)”。
+     1. 创建具有 `repo` 作用域的个人访问令牌。有关详细信息，请参阅“[创建个人访问令牌](/github/authenticating-to-github/creating-a-personal-access-token)”。
+     1. 将此个人访问令牌作为机密存储在仓库中。有关如何存储机密的详细信息，请参阅“[已加密的机密](/actions/reference/encrypted-secrets)”。
      1. 在工作流文件中，将 `PERSONAL_ACCESS_TOKEN` 替换为机密的名称。
 6. {% data reusables.actions.commit-workflow %}
 
 ## 测试工作流程
 
-每当分配仓库中的议题时，议题将移到指定的项目板列。 如果议题尚未在项目板上，则将添加到项目板中。
+每当分配仓库中的议题时，议题将移到指定的项目板列。如果议题尚未在项目板上，则将添加到项目板中。
 
-如果存储库是用户拥有的存储库，则 `alex-page/github-project-automation-plus` 操作将对存储库或个人帐户中具有指定项目名称和列的所有项目执行操作。 同样，如果您的仓库归组织所有，则该操作将对仓库或组织中具有指定项目名称和列的所有项目执行。
+如果存储库是用户拥有的存储库，则 `alex-page/github-project-automation-plus` 操作将对存储库或个人帐户中具有指定项目名称和列的所有项目执行操作。同样，如果您的仓库归组织所有，则该操作将对仓库或组织中具有指定项目名称和列的所有项目执行。
 
 通过在仓库中分配议题来测试工作流程。
 
-1. 在仓库中打开一个议题。 有关详细信息，请参阅“[创建问题](/github/managing-your-work-on-github/creating-an-issue)”。
-2. 分配议题。 有关详细信息，请参阅“[向其他 GitHub 用户分配问题并拉取请求](/github/managing-your-work-on-github/assigning-issues-and-pull-requests-to-other-github-users)”。
-3. 要查看分配议题所触发的工作流程运行，请查看工作流程运行的历史记录。 有关详细信息，请参阅“[查看工作流运行历史记录](/actions/managing-workflow-runs/viewing-workflow-run-history)”。
+1. 在仓库中打开一个议题。有关详细信息，请参阅“[创建问题](/github/managing-your-work-on-github/creating-an-issue)”。
+2. 分配议题。有关详细信息，请参阅“[向其他 GitHub 用户分配问题并拉取请求](/github/managing-your-work-on-github/assigning-issues-and-pull-requests-to-other-github-users)”。
+3. 要查看分配议题所触发的工作流程运行，请查看工作流程运行的历史记录。有关详细信息，请参阅“[查看工作流运行历史记录](/actions/managing-workflow-runs/viewing-workflow-run-history)”。
 4. 工作流程完成后，分配的议题应会添加到指定的项目板列中。
 
 ## 后续步骤
diff --git a/translations/zh-CN/content/actions/managing-issues-and-pull-requests/removing-a-label-when-a-card-is-added-to-a-project-board-column.md b/translations/zh-CN/content/actions/managing-issues-and-pull-requests/removing-a-label-when-a-card-is-added-to-a-project-board-column.md
index a33d528fadeb..f300a7828494 100644
--- a/translations/zh-CN/content/actions/managing-issues-and-pull-requests/removing-a-label-when-a-card-is-added-to-a-project-board-column.md
+++ b/translations/zh-CN/content/actions/managing-issues-and-pull-requests/removing-a-label-when-a-card-is-added-to-a-project-board-column.md
@@ -24,14 +24,14 @@ ms.locfileid: '147410105'
 
 ## 简介
 
-本教程演示如何使用 [`andymckay/labeler` 操作](https://github.com/marketplace/actions/simple-issue-labeler)和条件，从已添加到项目板上指定列的议题和拉取请求中删除标签。 例如，可以在项目卡移至 `Done` 列后删除 `needs review` 标签。
+本教程演示如何使用 [`andymckay/labeler` 操作](https://github.com/marketplace/actions/simple-issue-labeler)和条件，从已添加到项目板上指定列的议题和拉取请求中删除标签。例如，可以在项目卡移至 `Done` 列后删除 `needs review` 标签。
 
-在本教程中，你将首先创建一个使用 [`andymckay/labeler` 操作](https://github.com/marketplace/actions/simple-issue-labeler)的工作流文件。 然后，您将自定义工作流以适应您的需要。
+在本教程中，你将首先创建一个使用 [`andymckay/labeler` 操作](https://github.com/marketplace/actions/simple-issue-labeler)的工作流文件。然后，您将自定义工作流以适应您的需要。
 
 ## 创建工作流程
 
 1. {% data reusables.actions.choose-repo %}
-2. 选择属于仓库的项目。 此工作流程不能用于属于用户或组织的项目。 您可以使用现有项目，也可以创建新项目。 有关如何创建项目的详细信息，请参阅“[创建项目板](/github/managing-your-work-on-github/creating-a-project-board)”。
+2. 选择属于仓库的项目。此工作流程不能用于属于用户或组织的项目。您可以使用现有项目，也可以创建新项目。有关如何创建项目的详细信息，请参阅“[创建项目板](/github/managing-your-work-on-github/creating-a-project-board)”。
 3. {% data reusables.actions.make-workflow-file %}
 4. 将以下 YAML 内容复制到工作流程文件中。
     ```yaml{:copy}
@@ -62,22 +62,22 @@ ms.locfileid: '147410105'
 5. 自定义工工作流程文件中的参数：
    - 在 `github.event.project_card.column_id == '12345678'` 中，将 `12345678` 替换为要取消标记移至其中的议题和拉取请求的列 ID。
 
-    要查找列 ID，请导航到您的项目板。 在列标题旁边，请单击 {% octicon "kebab-horizontal" aria-label="The horizontal kebab icon" %}，然后单击“复制列链接”。 列 ID 是复制的链接末尾的数字。 例如，`24687531` 是 `https://github.com/octocat/octo-repo/projects/1#column-24687531` 的列 ID。
+    要查找列 ID，请导航到您的项目板。在列标题旁边，请单击 {% octicon "kebab-horizontal" aria-label="The horizontal kebab icon" %}，然后单击“复制列链接”。列 ID 是复制的链接末尾的数字。例如，`24687531` 是 `https://github.com/octocat/octo-repo/projects/1#column-24687531` 的列 ID。
 
-     如果想要在多个列上操作，请使用 `||` 分隔条件。 例如，只要项目卡添加到了列 `12345678` 或列 `87654321`，就会使用 `if github.event.project_card.column_id == '12345678' || github.event.project_card.column_id == '87654321'`。 这些列可能在不同的项目板上。
-   - 将 `remove-labels` 的值更改为要从移至指定列的议题或拉取请求中删除的标签列表。 使用逗号分隔多个标签。 例如 `"help wanted, good first issue"`。 有关标签的详细信息，请参阅“[管理标签](/github/managing-your-work-on-github/managing-labels#applying-labels-to-issues-and-pull-requests)”。
+     如果想要在多个列上操作，请使用 `||` 分隔条件。例如，只要项目卡添加到了列 `12345678` 或列 `87654321`，就会使用 `if github.event.project_card.column_id == '12345678' || github.event.project_card.column_id == '87654321'`。这些列可能在不同的项目板上。
+   - 将 `remove-labels` 的值更改为要从移至指定列的议题或拉取请求中删除的标签列表。使用逗号分隔多个标签。例如 `"help wanted, good first issue"`。有关标签的详细信息，请参阅“[管理标签](/github/managing-your-work-on-github/managing-labels#applying-labels-to-issues-and-pull-requests)”。
 6. {% data reusables.actions.commit-workflow %}
 
 ## 测试工作流程
 
-每次仓库中项目上的项目卡移动时，此工作流程都会运行。 如果卡是议题或拉取请求，并移入您指定的列，则工作流程将从问题或拉取请求中删除指定的标签。 记事卡不会受到影响。
+每次仓库中项目上的项目卡移动时，此工作流程都会运行。如果卡是议题或拉取请求，并移入您指定的列，则工作流程将从问题或拉取请求中删除指定的标签。记事卡不会受到影响。
 
 通过将项目上的议题移到目标列中来测试工作流程。
 
-1. 在仓库中打开一个议题。 有关详细信息，请参阅“[创建议题](/github/managing-your-work-on-github/creating-an-issue)”。
-2. 用标签标记您想要工作流程删除的议题。 有关详细信息，请参阅“[管理标签](/github/managing-your-work-on-github/managing-labels#applying-labels-to-issues-and-pull-requests)”。
-3. 将议题添加到您在工作流程文件中指定的项目列。 有关详细信息，请参阅“[向项目板添加议题和拉取请求](/github/managing-your-work-on-github/adding-issues-and-pull-requests-to-a-project-board)”。
-4. 要查看通过将议题添加到项目所触发的工作流程运行，请查看工作流程运行的历史记录。 有关详细信息，请参阅“[查看工作流运行历史记录](/actions/managing-workflow-runs/viewing-workflow-run-history)”。
+1. 在仓库中打开一个议题。有关详细信息，请参阅“[创建议题](/github/managing-your-work-on-github/creating-an-issue)”。
+2. 用标签标记您想要工作流程删除的议题。有关详细信息，请参阅“[管理标签](/github/managing-your-work-on-github/managing-labels#applying-labels-to-issues-and-pull-requests)”。
+3. 将议题添加到您在工作流程文件中指定的项目列。有关详细信息，请参阅“[向项目板添加议题和拉取请求](/github/managing-your-work-on-github/adding-issues-and-pull-requests-to-a-project-board)”。
+4. 要查看通过将议题添加到项目所触发的工作流程运行，请查看工作流程运行的历史记录。有关详细信息，请参阅“[查看工作流运行历史记录](/actions/managing-workflow-runs/viewing-workflow-run-history)”。
 5. 当工作流程完成时，您添加到项目列的议题应已删除指定的标签。
 
 ## 后续步骤
diff --git a/translations/zh-CN/content/actions/managing-issues-and-pull-requests/scheduling-issue-creation.md b/translations/zh-CN/content/actions/managing-issues-and-pull-requests/scheduling-issue-creation.md
index 13da49ea37cd..8769465b932e 100644
--- a/translations/zh-CN/content/actions/managing-issues-and-pull-requests/scheduling-issue-creation.md
+++ b/translations/zh-CN/content/actions/managing-issues-and-pull-requests/scheduling-issue-creation.md
@@ -23,9 +23,9 @@ ms.locfileid: '147410057'
 
 ## 简介
 
-本教程演示如何使用 [`imjohnbo/issue-bot` 操作](https://github.com/marketplace/actions/issue-bot-action)定期创建议题。 例如，您可以每周创建一个议题，用作团队会议的议程。
+本教程演示如何使用 [`imjohnbo/issue-bot` 操作](https://github.com/marketplace/actions/issue-bot-action)定期创建议题。例如，您可以每周创建一个议题，用作团队会议的议程。
 
-在本教程中，你将首先创建一个使用 [`imjohnbo/issue-bot` 操作](https://github.com/marketplace/actions/issue-bot-action)的工作流文件。 然后，您将自定义工作流以适应您的需要。
+在本教程中，你将首先创建一个使用 [`imjohnbo/issue-bot` 操作](https://github.com/marketplace/actions/issue-bot-action)的工作流文件。然后，您将自定义工作流以适应您的需要。
 
 ## 创建工作流程
 
@@ -75,22 +75,22 @@ ms.locfileid: '147410057'
     ```
 
 4. 自定义工工作流程文件中的参数：
-   - 更改 `on.schedule` 的值以指示你希望何时运行此工作流。 在上面的示例中，工作流将于每周一 7:20 UTC 运行。 有关计划工作流的详细信息，请参阅“[计划事件](/actions/reference/events-that-trigger-workflows#scheduled-events)”。
+   - 更改 `on.schedule` 的值以指示你希望何时运行此工作流。在上面的示例中，工作流将于每周一 7:20 UTC 运行。有关计划工作流的详细信息，请参阅“[计划事件](/actions/reference/events-that-trigger-workflows#scheduled-events)”。
    - 将 `assignees` 的值更改为你想要分配给此议题的 {% data variables.product.prodname_dotcom %} 用户名。
    - 将 `labels` 的值更改为你想要应用于此议题的标签列表。
    - 将 `title` 的值更改为你希望该议题拥有的标题。
-   - 将 `body` 的值更改为你想要用于议题正文的文本。 使用 `|` 字符可以为此参数使用多行值。
-   - 如果想要将这个议题固定在存储库中，请将 `pinned` 设置为 `true`。 有关固定议题的详细信息，请参阅“[将议题固定到存储库](/articles/pinning-an-issue-to-your-repository)”。
-   - 如果你想在每次新建议题时关闭此工作流生成的上一个议题，请将 `close-previous` 设置为 `true`。 工作流将关闭具有 `labels` 字段中定义的标签的最新议题。 为避免关闭错误的议题，请使用独特的标签或标签组合。
+   - 将 `body` 的值更改为你想要用于议题正文的文本。使用 `|` 字符可以为此参数使用多行值。
+   - 如果想要将这个议题固定在存储库中，请将 `pinned` 设置为 `true`。有关固定议题的详细信息，请参阅“[将议题固定到存储库](/articles/pinning-an-issue-to-your-repository)”。
+   - 如果你想在每次新建议题时关闭此工作流生成的上一个议题，请将 `close-previous` 设置为 `true`。工作流将关闭具有 `labels` 字段中定义的标签的最新议题。为避免关闭错误的议题，请使用独特的标签或标签组合。
 5. {% data reusables.actions.commit-workflow %}
 
 ## 预期结果
 
-根据 `schedule` 参数（例如，每周一 7:20 UTC），你的工作流将使用你指定的受理人、标签、标题和正文创建新议题。 如果将 `pinned` 设置为 `true`，工作流会将此议题固定到存储库。 如果将 `close-previous` 设置为 true，工作流将关闭具有匹配标签的最新议题。
+根据 `schedule` 参数（例如，每周一 7:20 UTC），你的工作流将使用你指定的受理人、标签、标题和正文创建新议题。如果将 `pinned` 设置为 `true`，工作流会将此议题固定到存储库。如果将 `close-previous` 设置为 true，工作流将关闭具有匹配标签的最新议题。
 
 {% data reusables.actions.schedule-delay %}
 
-您可以查看工作流程运行的历史记录，以便定期查看此工作流程运行。 有关详细信息，请参阅“[查看工作流运行历史记录](/actions/managing-workflow-runs/viewing-workflow-run-history)”。
+您可以查看工作流程运行的历史记录，以便定期查看此工作流程运行。有关详细信息，请参阅“[查看工作流运行历史记录](/actions/managing-workflow-runs/viewing-workflow-run-history)”。
 
 ## 后续步骤
 
diff --git a/translations/zh-CN/content/actions/managing-issues-and-pull-requests/using-github-actions-for-project-management.md b/translations/zh-CN/content/actions/managing-issues-and-pull-requests/using-github-actions-for-project-management.md
index 0193c75c10ea..8d2173dbb8f5 100644
--- a/translations/zh-CN/content/actions/managing-issues-and-pull-requests/using-github-actions-for-project-management.md
+++ b/translations/zh-CN/content/actions/managing-issues-and-pull-requests/using-github-actions-for-project-management.md
@@ -19,11 +19,11 @@ ms.contentlocale: zh-CN
 ms.lasthandoff: 09/10/2022
 ms.locfileid: '145099104'
 ---
-您可以创建工作流程以使用 {% data variables.product.prodname_actions %} 自动化项目管理任务。 每个工作流程都包含一系列任务，每当工作流程运行时都会自动执行。 例如，您可以创建一个工作流程，在每次创建议题时运行，以添加标签、 留下评论并将议题移动到项目板。
+您可以创建工作流程以使用 {% data variables.product.prodname_actions %} 自动化项目管理任务。每个工作流程都包含一系列任务，每当工作流程运行时都会自动执行。例如，您可以创建一个工作流程，在每次创建议题时运行，以添加标签、留下评论并将议题移动到项目板。
 
 ## 工作流程何时运行？
 
-您可以配置工作流程以按计划运行或在事件发生时触发。 例如，您可以设置工作流程在有人在仓库中创建议题时运行。
+您可以配置工作流程以按计划运行或在事件发生时触发。例如，您可以设置工作流程在有人在仓库中创建议题时运行。
 
 许多工作流程触发器对项目管理自动化很有用。
 
diff --git a/translations/zh-CN/content/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks.md b/translations/zh-CN/content/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks.md
index 723ca8c8a7c0..9b44b4219a60 100644
--- a/translations/zh-CN/content/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks.md
+++ b/translations/zh-CN/content/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks.md
@@ -25,7 +25,7 @@ ms.locfileid: '145084656'
 能够写入仓库的维护者可按照以下步骤来审查和运行来自贡献者、需要审批的拉取请求上的工作流程。
 
 {% data reusables.repositories.sidebar-pr %} {% data reusables.repositories.choose-pr-review %} {% data reusables.repositories.changed-files %}
-1. 检查拉取请求中的拟议更改，确保您在拉取请求分支上自由运行您的工作流程。 应特别注意 `.github/workflows/` 目录中影响工作流文件的任何拟议更改。
+1. 检查拉取请求中的拟议更改，确保您在拉取请求分支上自由运行您的工作流程。应特别注意 `.github/workflows/` 目录中影响工作流文件的任何拟议更改。
 1. 如果能自由在拉取请求分支上运行工作流，请返回到 {% octicon "comment-discussion" aria-label="The discussion icon" %}“转换”选项卡，在“等待审批的工作流”下，单击“批准并运行” 。
 
    ![批准并运行工作流程](/assets/images/help/pull_requests/actions-approve-and-run-workflows-from-fork.png)
diff --git a/translations/zh-CN/content/actions/managing-workflow-runs/canceling-a-workflow.md b/translations/zh-CN/content/actions/managing-workflow-runs/canceling-a-workflow.md
index 47c190ea89d6..d653dc98e717 100644
--- a/translations/zh-CN/content/actions/managing-workflow-runs/canceling-a-workflow.md
+++ b/translations/zh-CN/content/actions/managing-workflow-runs/canceling-a-workflow.md
@@ -1,6 +1,6 @@
 ---
 title: 取消工作流程
-intro: '您可以取消正在运行的工作流程。 当您取消工作流程运行时，{% data variables.product.prodname_dotcom %} 会取消属于该工作流程的所有作业和步骤。'
+intro: '您可以取消正在运行的工作流程。当您取消工作流程运行时，{% data variables.product.prodname_dotcom %} 会取消属于该工作流程的所有作业和步骤。'
 versions:
   fpt: '*'
   ghes: '*'
@@ -27,10 +27,10 @@ ms.locfileid: '145084686'
 
 ## {% data variables.product.prodname_dotcom %} 取消工作流程运行所执行的步骤
 
-取消工作流程运行时，您可能正在运行使用与工作流程运行相关的资源的其他软件。 为了帮助您释放与工作流程运行相关的资源，它可能有助于了解 {% data variables.product.prodname_dotcom %} 为取消工作流程运行而执行的步骤。
+取消工作流程运行时，您可能正在运行使用与工作流程运行相关的资源的其他软件。为了帮助您释放与工作流程运行相关的资源，它可能有助于了解 {% data variables.product.prodname_dotcom %} 为取消工作流程运行而执行的步骤。
 
-1. 要取消工作流运行，服务器将重新评估所有正在运行的作业的 `if` 条件。 如果条件评估为 `true`，作业将不会取消。 例如，条件 `if: always()` 评估为 true，作业继续运行。 没有条件时，则等同于条件 `if: success()`，仅在上一步已成功完成时才会运行。
+1. 要取消工作流运行，服务器将重新评估所有正在运行的作业的 `if` 条件。如果条件评估为 `true`，作业将不会取消。例如，条件 `if: always()` 评估为 true，作业继续运行。没有条件时，则等同于条件 `if: success()`，仅在上一步已成功完成时才会运行。
 2. 对于需要取消的作业，服务器向包含需取消作业的所有运行器机器发送取消消息。
-3. 对于继续运行的作业，服务器将对未完成的步骤重新评估 `if` 条件。 如果条件评估为 `true`，则步骤继续运行。
-4. 对于需要取消的步骤，运行器计算机发送 `SIGINT/Ctrl-C` 到该步骤的入口进程（对于 javascript 操作，为 `node`；对于容器操作，为 `docker`；在步骤中使用 `run` 时，为 `bash/cmd/pwd`）。 如果进程未在 7500 毫秒内退出，运行器将发送 `SIGTERM/Ctrl-Break` 到此进程，然后等待 2500 毫秒让进程退出。 如果该进程仍在运行，运行器会停止进程树。
+3. 对于继续运行的作业，服务器将对未完成的步骤重新评估 `if` 条件。如果条件评估为 `true`，则步骤继续运行。
+4. 对于需要取消的步骤，运行器计算机发送 `SIGINT/Ctrl-C` 到该步骤的入口进程（对于 javascript 操作，为 `node`；对于容器操作，为 `docker`；在步骤中使用 `run` 时，为 `bash/cmd/pwd`）。如果进程未在 7500 毫秒内退出，运行器将发送 `SIGTERM/Ctrl-Break` 到此进程，然后等待 2500 毫秒让进程退出。如果该进程仍在运行，运行器会停止进程树。
 5. 在 5 分钟取消超时期后，服务器将强制终止未完成运行或无法完成取消进程的所有作业和步骤。
diff --git a/translations/zh-CN/content/actions/managing-workflow-runs/disabling-and-enabling-a-workflow.md b/translations/zh-CN/content/actions/managing-workflow-runs/disabling-and-enabling-a-workflow.md
index a7596cbfafbe..7131c8d8398b 100644
--- a/translations/zh-CN/content/actions/managing-workflow-runs/disabling-and-enabling-a-workflow.md
+++ b/translations/zh-CN/content/actions/managing-workflow-runs/disabling-and-enabling-a-workflow.md
@@ -16,9 +16,9 @@ ms.locfileid: '145109568'
 ---
 {% data reusables.actions.enterprise-beta %} {% data reusables.actions.enterprise-github-hosted-runners %}
 
-禁用工作流程允许您停止触发工作流程，而不必从仓库中删除文件。 您可以轻松地在 {% data variables.product.prodname_dotcom %} 上重新启用工作流程。
+禁用工作流程允许您停止触发工作流程，而不必从仓库中删除文件。您可以轻松地在 {% data variables.product.prodname_dotcom %} 上重新启用工作流程。
 
-在许多情况下，暂时禁用工作流程可能很有用。 以下是禁用工作流程可能有帮助的几个例子：
+在许多情况下，暂时禁用工作流程可能很有用。以下是禁用工作流程可能有帮助的几个例子：
 
 - 产生请求过多或错误的工作流程错误，对外部服务产生负面影响。
 - 不重要但会耗费您帐户上太多分钟数的工作流程。
@@ -31,7 +31,7 @@ ms.locfileid: '145109568'
 
 {% endwarning %}
 
-您也可以使用 REST API 禁用和启用工作流程。 有关详细信息，请参阅“[Actions REST API](/rest/reference/actions#workflows)”。
+您也可以使用 REST API 禁用和启用工作流程。有关详细信息，请参阅“[Actions REST API](/rest/reference/actions#workflows)”。
 
 ## 禁用工作流程
 
@@ -52,7 +52,7 @@ ms.locfileid: '145109568'
 
 {% data reusables.cli.cli-learn-more %}
 
-要禁用工作流，请使用 `workflow disable` 子命令。 将 `workflow` 替换为要禁用的工作流的名称、ID 或文件名。 例如，`"Link Checker"`、`1234567` 或 `"link-check-test.yml"`。 如果您没有指定工作流程，{% data variables.product.prodname_cli %} 将返回交互式菜单供您选择工作流程。
+要禁用工作流，请使用 `workflow disable` 子命令。将 `workflow` 替换为要禁用的工作流的名称、ID 或文件名。例如，`"Link Checker"`、`1234567` 或 `"link-check-test.yml"`。如果您没有指定工作流程，{% data variables.product.prodname_cli %} 将返回交互式菜单供您选择工作流程。
 
 ```shell
 gh workflow disable <em>workflow</em>
@@ -76,7 +76,7 @@ gh workflow disable <em>workflow</em>
 
 {% cli %}
 
-要启用工作流，请使用 `workflow enable` 子命令。 将 `workflow` 替换为要启用的工作流的名称、ID 或文件名。 例如，`"Link Checker"`、`1234567` 或 `"link-check-test.yml"`。 如果您没有指定工作流程，{% data variables.product.prodname_cli %} 将返回交互式菜单供您选择工作流程。
+要启用工作流，请使用 `workflow enable` 子命令。将 `workflow` 替换为要启用的工作流的名称、ID 或文件名。例如，`"Link Checker"`、`1234567` 或 `"link-check-test.yml"`。如果您没有指定工作流程，{% data variables.product.prodname_cli %} 将返回交互式菜单供您选择工作流程。
 
 ```shell
 gh workflow enable <em>workflow</em>
diff --git a/translations/zh-CN/content/actions/managing-workflow-runs/downloading-workflow-artifacts.md b/translations/zh-CN/content/actions/managing-workflow-runs/downloading-workflow-artifacts.md
index dfd5609699b8..93e23cdca75f 100644
--- a/translations/zh-CN/content/actions/managing-workflow-runs/downloading-workflow-artifacts.md
+++ b/translations/zh-CN/content/actions/managing-workflow-runs/downloading-workflow-artifacts.md
@@ -16,7 +16,7 @@ ms.locfileid: '145099189'
 ---
 {% data reusables.actions.enterprise-beta %} {% data reusables.actions.enterprise-github-hosted-runners %}
 
-默认情况下，{% data variables.product.product_name %} 存储 90 天内的构建日志和构件，您可以根据仓库类型定制此存储期。 有关详细信息，请参阅“[管理存储库的 {% data variables.product.prodname_actions %} 设置](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#configuring-the-retention-period-for-github-actions-artifacts-and-logs-in-your-repository)”。
+默认情况下，{% data variables.product.product_name %} 存储 90 天内的构建日志和构件，您可以根据仓库类型定制此存储期。有关详细信息，请参阅“[管理存储库的 {% data variables.product.prodname_actions %} 设置](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#configuring-the-retention-period-for-github-actions-artifacts-and-logs-in-your-repository)”。
 
 {% data reusables.repositories.permissions-statement-read %}
 
@@ -34,15 +34,15 @@ ms.locfileid: '145099189'
 
 {% data reusables.cli.cli-learn-more %}
 
-{% data variables.product.prodname_cli %} 将根据构件名称将每个构件下载到单独的目录中。 如果只指定了单个构件, 它将被提取到当前目录。
+{% data variables.product.prodname_cli %} 将根据构件名称将每个构件下载到单独的目录中。如果只指定了单个构件，它将被提取到当前目录。
 
-要下载工作流运行产生的所有项目，请使用 `run download` 子命令。 将 `run-id` 替换为你要从中下载项目的运行的 ID。 如果没有指定 `run-id`，{% data variables.product.prodname_cli %} 将返回交互式菜单供你选择最近的运行。
+要下载工作流运行产生的所有项目，请使用 `run download` 子命令。将 `run-id` 替换为你要从中下载项目的运行的 ID。如果没有指定 `run-id`，{% data variables.product.prodname_cli %} 将返回交互式菜单供你选择最近的运行。
 
 ```shell
 gh run download <em>run-id</em>
 ```
 
-要从运行中下载特定的项目，请使用 `run download` 子命令。 将 `run-id` 替换为你要从中下载项目的运行的 ID。 将 `artifact-name` 替换为你要下载的项目的名称。
+要从运行中下载特定的项目，请使用 `run download` 子命令。将 `run-id` 替换为你要从中下载项目的运行的 ID。将 `artifact-name` 替换为你要下载的项目的名称。
 
 ```shell
 gh run download <em>run-id</em> -n <em>artifact-name</em>
diff --git a/translations/zh-CN/content/actions/managing-workflow-runs/manually-running-a-workflow.md b/translations/zh-CN/content/actions/managing-workflow-runs/manually-running-a-workflow.md
index 6d9622732093..82f5f9483728 100644
--- a/translations/zh-CN/content/actions/managing-workflow-runs/manually-running-a-workflow.md
+++ b/translations/zh-CN/content/actions/managing-workflow-runs/manually-running-a-workflow.md
@@ -18,7 +18,7 @@ ms.locfileid: '145099187'
 
 ## 配置工作流程手动运行
 
-要手动运行工作流，必须将工作流配置为在 `workflow_dispatch` 事件上运行。 要触发 `workflow_dispatch` 事件，工作流必须位于默认分支中。 有关配置 `workflow_dispatch` 事件的详细信息，请参阅“[触发工作流的事件](/actions/reference/events-that-trigger-workflows#workflow_dispatch)”。
+要手动运行工作流，必须将工作流配置为在 `workflow_dispatch` 事件上运行。要触发 `workflow_dispatch` 事件，工作流必须位于默认分支中。有关配置 `workflow_dispatch` 事件的详细信息，请参阅“[触发工作流的事件](/actions/reference/events-that-trigger-workflows#workflow_dispatch)”。
 
 {% data reusables.repositories.permissions-statement-write %}
 
@@ -31,7 +31,7 @@ ms.locfileid: '145099187'
 ![操作选择工作流](/assets/images/actions-select-workflow.png)
 1. 在工作流运行列表上方，选择“运行工作流”。
 ![操作工作流调度](/assets/images/actions-workflow-dispatch.png)
-1. 使用“分支”下拉菜单，选择工作流的分支，并键入输入参数。 单击“运行工作流”。
+1. 使用“分支”下拉菜单，选择工作流的分支，并键入输入参数。单击“运行工作流”。
 ![操作手动运行工作流](/assets/images/actions-manually-run-workflow.png)
 
 {% endwebui %}
@@ -40,13 +40,13 @@ ms.locfileid: '145099187'
 
 {% data reusables.cli.cli-learn-more %}
 
-要运行工作流，请使用 `workflow run` 子命令。 将 `workflow` 参数替换为要运行的工作流的名称、ID 或文件名。 例如，`"Link Checker"`、`1234567` 或 `"link-check-test.yml"`。 如果您没有指定工作流程，{% data variables.product.prodname_cli %} 将返回交互式菜单供您选择工作流程。
+要运行工作流，请使用 `workflow run` 子命令。将 `workflow` 参数替换为要运行的工作流的名称、ID 或文件名。例如，`"Link Checker"`、`1234567` 或 `"link-check-test.yml"`。如果您没有指定工作流程，{% data variables.product.prodname_cli %} 将返回交互式菜单供您选择工作流程。
 
 ```shell
 gh workflow run <em>workflow</em>
 ```
 
-如果您的工作流程接受输入，{% data variables.product.prodname_cli %} 将提示您输入它们。 或者，可以使用 `-f` 或 `-F` 添加 `key=value` 格式的输入。 使用 `-F` 从文件中读取。
+如果您的工作流程接受输入，{% data variables.product.prodname_cli %} 将提示您输入它们。或者，可以使用 `-f` 或 `-F` 添加 `key=value` 格式的输入。使用 `-F` 从文件中读取。
 
 ```shell
 gh workflow run greet.yml -f name=mona -f greeting=hello -F data=@myfile.txt
@@ -74,7 +74,7 @@ gh run watch
 
 ## 使用 REST API 运行工作流程
 
-使用 REST API 时，应将 `inputs` 和 `ref` 配置为请求正文参数。 如果忽略输入，则使用工作流程文件中定义的默认值。
+使用 REST API 时，应将 `inputs` 和 `ref` 配置为请求正文参数。如果忽略输入，则使用工作流程文件中定义的默认值。
 
 {% note %}
 
diff --git a/translations/zh-CN/content/actions/managing-workflow-runs/removing-workflow-artifacts.md b/translations/zh-CN/content/actions/managing-workflow-runs/removing-workflow-artifacts.md
index 4d25f73ce074..77cdc3d06101 100644
--- a/translations/zh-CN/content/actions/managing-workflow-runs/removing-workflow-artifacts.md
+++ b/translations/zh-CN/content/actions/managing-workflow-runs/removing-workflow-artifacts.md
@@ -36,10 +36,10 @@ ms.locfileid: '146199800'
 
 ## 设置构件的保留期
 
-可在仓库、组织和企业级配置构件和日志的保留期。 有关详细信息，请参阅{% ifversion fpt or ghec or ghes %}“[使用情况限制、计费和管理](/actions/reference/usage-limits-billing-and-administration#artifact-and-log-retention-policy)”。{% elsif ghae %}“[为存储库管理 {% data variables.product.prodname_actions %} 设置](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#configuring-the-retention-period-for-github-actions-artifacts-and-logs-in-your-repository)”、“[为组织中的工件和日志配置 {% data variables.product.prodname_actions %} 的保留期](/organizations/managing-organization-settings/configuring-the-retention-period-for-github-actions-artifacts-and-logs-in-your-organization)”或“[为企业中的 {% data variables.product.prodname_actions %} 强制实施政策](/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#enforcing-a-policy-for-artifact-and-log-retention-in-your-enterprise)”。{% endif %}
+可在仓库、组织和企业级配置构件和日志的保留期。有关详细信息，请参阅{% ifversion fpt or ghec or ghes %}“[使用情况限制、计费和管理](/actions/reference/usage-limits-billing-and-administration#artifact-and-log-retention-policy)”。{% elsif ghae %}“[为存储库管理 {% data variables.product.prodname_actions %} 设置](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#configuring-the-retention-period-for-github-actions-artifacts-and-logs-in-your-repository)”、“[为组织中的工件和日志配置 {% data variables.product.prodname_actions %} 的保留期](/organizations/managing-organization-settings/configuring-the-retention-period-for-github-actions-artifacts-and-logs-in-your-organization)”或“[为企业中的 {% data variables.product.prodname_actions %} 强制实施政策](/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#enforcing-a-policy-for-artifact-and-log-retention-in-your-enterprise)”。{% endif %}
 
-也可以在工作流中使用 `actions/upload-artifact` 操作自定义个别工件的保留期。 有关详细信息，请参阅“[将工作流数据存储为工件](/actions/guides/storing-workflow-data-as-artifacts#configuring-a-custom-artifact-retention-period)”。
+也可以在工作流中使用 `actions/upload-artifact` 操作自定义个别工件的保留期。有关详细信息，请参阅“[将工作流数据存储为工件](/actions/guides/storing-workflow-data-as-artifacts#configuring-a-custom-artifact-retention-period)”。
 
 ## 查找构件的到期日期
 
-您可以使用 API 确认构件计划删除的日期。 有关详细信息，请参阅“[列出存储库的工件](/rest/reference/actions#artifacts)返回的 `expires_at` 值”。
+您可以使用 API 确认构件计划删除的日期。有关详细信息，请参阅“[列出存储库的工件](/rest/reference/actions#artifacts)返回的 `expires_at` 值”。
diff --git a/translations/zh-CN/content/actions/managing-workflow-runs/reviewing-deployments.md b/translations/zh-CN/content/actions/managing-workflow-runs/reviewing-deployments.md
index 5ecf54815dca..d12eb9004c91 100644
--- a/translations/zh-CN/content/actions/managing-workflow-runs/reviewing-deployments.md
+++ b/translations/zh-CN/content/actions/managing-workflow-runs/reviewing-deployments.md
@@ -16,17 +16,17 @@ ms.locfileid: '147718099'
 ---
 ## 关于工作流程中所需的审查
 
-引用配置了所需审查者的环境的作业将等待审批后再开始。 当作业正在等待批准时，其状态为“等待”。 如果作业在 30 天内未获得批准，工作流程运行将自动取消。
+引用配置了所需审查者的环境的作业将等待审批后再开始。当作业正在等待批准时，其状态为“等待”。如果作业在 30 天内未获得批准，工作流程运行将自动取消。
 
-有关环境和所需的审批的详细信息，请参阅“[使用环境进行部署](/actions/deployment/using-environments-for-deployment)”。 有关如何使用 REST API 查看部署的信息，请参阅“[工作流运行](/rest/reference/actions#workflow-runs)”。
+有关环境和所需的审批的详细信息，请参阅“[使用环境进行部署](/actions/deployment/using-environments-for-deployment)”。有关如何使用 REST API 查看部署的信息，请参阅“[工作流运行](/rest/reference/actions#workflow-runs)”。
 
 ## 批准或拒绝作业
 
-1. 导航到需要审核的工作流程运行。 有关导航到工作流运行的详细信息，请参阅“[查看工作流运行历史记录](/actions/managing-workflow-runs/viewing-workflow-run-history)”。
+1. 导航到需要审核的工作流程运行。有关导航到工作流运行的详细信息，请参阅“[查看工作流运行历史记录](/actions/managing-workflow-runs/viewing-workflow-run-history)”。
 2. 单击“审查部署”"。 
    ![审查部署](/assets/images/actions-review-deployments.png)
 3. 选择要审批或拒绝的作业环境。 （可选）留下评论。
    ![批准部署](/assets/images/actions-approve-deployments.png)
 4. 批准或拒绝：
-   - 要批准作业，请单击“批准并部署”。 一旦作业获得批准（并且任何其他环境保护规则已通过），作业将继续。 此时，作业可以访问存储在环境中的任何机密。
-   - 要拒绝作业，请单击“拒绝”。 如果作业被拒绝，工作流程将失败。
+   - 要批准作业，请单击“批准并部署”。一旦作业获得批准（并且任何其他环境保护规则已通过），作业将继续。此时，作业可以访问存储在环境中的任何机密。
+   - 要拒绝作业，请单击“拒绝”。如果作业被拒绝，工作流程将失败。
diff --git a/translations/zh-CN/content/actions/managing-workflow-runs/skipping-workflow-runs.md b/translations/zh-CN/content/actions/managing-workflow-runs/skipping-workflow-runs.md
index b668c97b7057..4ea2ee79358a 100644
--- a/translations/zh-CN/content/actions/managing-workflow-runs/skipping-workflow-runs.md
+++ b/translations/zh-CN/content/actions/managing-workflow-runs/skipping-workflow-runs.md
@@ -18,7 +18,7 @@ ms.locfileid: '146199968'
 
 {% note %}
 
-注意：如果因[路径筛选](/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore)、[分支筛选](/actions/using-workflows/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore)或提交消息（见下文）而跳过某工作流，则与该工作流关联的检查将保持为“挂起”状态。 要求这些检查成功的拉取请求将被阻止合并。
+注意：如果因[路径筛选](/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore)、[分支筛选](/actions/using-workflows/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore)或提交消息（见下文）而跳过某工作流，则与该工作流关联的检查将保持为“挂起”状态。要求这些检查成功的拉取请求将被阻止合并。
 
 {% endnote %}
 
@@ -34,12 +34,12 @@ ms.locfileid: '146199968'
 - `skip-checks:true`
 - `skip-checks: true`
 
-如果您的仓库配置为需要先通过特定检查，则无法合并拉取请求。 要允许合并拉取请求，您可以将新提交推送到拉取请求，而无需提交消息中的跳过指令。
+如果您的仓库配置为需要先通过特定检查，则无法合并拉取请求。要允许合并拉取请求，您可以将新提交推送到拉取请求，而无需提交消息中的跳过指令。
 
 {% note %}
 
-**注意**：跳过说明仅适用于 `push` 事件和 `pull_request` 事件。 例如，将 `[skip ci]` 添加到提交消息不会停止触发 `on: pull_request_target` 的工作流运行。
+**注意**：跳过说明仅适用于 `push` 事件和 `pull_request` 事件。例如，将 `[skip ci]` 添加到提交消息不会停止触发 `on: pull_request_target` 的工作流运行。
 
 {% endnote %}
 
-跳过指令仅适用于由包含跳过指令的提交触发的工作流程运行。 您还可以禁用工作流程的运行。 有关详细信息，请参阅“[禁用和启用工作流](/actions/managing-workflow-runs/disabling-and-enabling-a-workflow)”。
+跳过指令仅适用于由包含跳过指令的提交触发的工作流程运行。您还可以禁用工作流程的运行。有关详细信息，请参阅“[禁用和启用工作流](/actions/managing-workflow-runs/disabling-and-enabling-a-workflow)”。
diff --git a/translations/zh-CN/content/actions/migrating-to-github-actions/migrating-from-azure-pipelines-to-github-actions.md b/translations/zh-CN/content/actions/migrating-to-github-actions/migrating-from-azure-pipelines-to-github-actions.md
index 7983eacd08e8..60661abcff91 100644
--- a/translations/zh-CN/content/actions/migrating-to-github-actions/migrating-from-azure-pipelines-to-github-actions.md
+++ b/translations/zh-CN/content/actions/migrating-to-github-actions/migrating-from-azure-pipelines-to-github-actions.md
@@ -26,7 +26,7 @@ ms.locfileid: '145100219'
 
 ## 简介
 
-Azure Pipelines 和 {% data variables.product.prodname_actions %} 都允许您创建能自动构建、测试、发布、发行和部署代码的工作流程。 Azure Pelines 和 {% data variables.product.prodname_actions %} 的工作流程配置有一些相似之处：
+Azure Pipelines 和 {% data variables.product.prodname_actions %} 都允许您创建能自动构建、测试、发布、发行和部署代码的工作流程。Azure Pelines 和 {% data variables.product.prodname_actions %} 的工作流程配置有一些相似之处：
 
 - 工作流程配置文件以 YAML 编写并存储在代码仓库中。
 - 工作流程包括一项或多项作业。
@@ -40,13 +40,13 @@ Azure Pipelines 和 {% data variables.product.prodname_actions %} 都允许您
 从 Azure Pipelines 迁移时，考虑以下差异：
 
 - Azure Pipelines 支持旧版经典编辑器，这样你便可以在 GUI 编辑器中定义 CI 配置，而不是在 YAML 文件中创建管道定义。 {% data variables.product.prodname_actions %} 使用 YAML 文件来定义工作流程，不支持图形编辑器。
-- Azure Pelines 允许您在作业定义中省略一些结构。 例如，如果您只有一个作业，则无需定义作业，只需要定义其步骤。 {% data variables.product.prodname_actions %} 需要明确的配置，且不能省略 YAML 结构。
+- Azure Pelines 允许您在作业定义中省略一些结构。例如，如果您只有一个作业，则无需定义作业，只需要定义其步骤。 {% data variables.product.prodname_actions %} 需要明确的配置，且不能省略 YAML 结构。
 - Azure Pipelines 支持 YAML 文件中定义的阶段，可用于创建部署工作流。 {% data variables.product.prodname_actions %} 要求您将阶段分成单独的 YAML 工作流程文件。
-- 可以使用功能选择本地 Azure Pipelines 构建代理。 通过标签可以选择 {% data variables.product.prodname_actions %} 自托管的运行器。
+- 可以使用功能选择本地 Azure Pipelines 构建代理。通过标签可以选择 {% data variables.product.prodname_actions %} 自托管的运行器。
 
 ## 迁移作业和步骤
 
-Azure Pelines 中的作业和步骤非常类似于 {% data variables.product.prodname_actions %} 中的作业和步骤。 在这两个系统中，作业具有以下特征：
+Azure Pelines 中的作业和步骤非常类似于 {% data variables.product.prodname_actions %} 中的作业和步骤。在这两个系统中，作业具有以下特征：
 
 * 作业包含一系列按顺序运行的步骤。
 * 作业在单独的虚拟机或单独的容器中运行。
@@ -54,9 +54,9 @@ Azure Pelines 中的作业和步骤非常类似于 {% data variables.product.pro
 
 ## 迁移脚本步骤
 
-可以将脚本或 shell 命令作为工作流程中的步骤运行。 在 Azure Pipelines 中，可以使用 `script` 键或 `bash`、`powershell` 或 `pwsh` 键指定脚本步骤。 也可以将脚本指定为 [Bash 任务](https://docs.microsoft.com/azure/devops/pipelines/tasks/utility/bash?view=azure-devops)或 [PowerShell 任务](https://docs.microsoft.com/azure/devops/pipelines/tasks/utility/powershell?view=azure-devops)的输入。
+可以将脚本或 shell 命令作为工作流程中的步骤运行。在 Azure Pipelines 中，可以使用 `script` 键或 `bash`、`powershell` 或 `pwsh` 键指定脚本步骤。也可以将脚本指定为 [Bash 任务](https://docs.microsoft.com/azure/devops/pipelines/tasks/utility/bash?view=azure-devops)或 [PowerShell 任务](https://docs.microsoft.com/azure/devops/pipelines/tasks/utility/powershell?view=azure-devops)的输入。
 
-在 {% data variables.product.prodname_actions %} 中，所有脚本都使用 `run` 键指定。 若要选择特定的 shell，可以在提供脚本时指定 `shell` 键。 有关详细信息，请参阅 [{% data variables.product.prodname_actions %} 的工作流语法](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepsrun)。
+在 {% data variables.product.prodname_actions %} 中，所有脚本都使用 `run` 键指定。若要选择特定的 shell，可以在提供脚本时指定 `shell` 键。有关详细信息，请参阅 [{% data variables.product.prodname_actions %} 的工作流语法](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepsrun)。
 
 下面是每个系统的语法示例：
 
@@ -111,13 +111,13 @@ jobs:
 
 在 Azure Pipelines 中，可将脚本配置为“在有任何输出发送到 `stderr` 时出错”。 {% data variables.product.prodname_actions %} 不支持此配置。
 
-{% data variables.product.prodname_actions %} 尽可能将 shell 配置为“快速失败”，如果脚本中的一个命令退出并有错误代码，则会立即停止脚本。 相反，Azure Pipelines 需要明确配置为在出错时立即退出。 有关详细信息，请参阅“[{% data variables.product.prodname_actions %} 的工作流语法](/actions/reference/workflow-syntax-for-github-actions#exit-codes-and-error-action-preference)”。
+{% data variables.product.prodname_actions %} 尽可能将 shell 配置为“快速失败”，如果脚本中的一个命令退出并有错误代码，则会立即停止脚本。相反，Azure Pipelines 需要明确配置为在出错时立即退出。有关详细信息，请参阅“[{% data variables.product.prodname_actions %} 的工作流语法](/actions/reference/workflow-syntax-for-github-actions#exit-codes-and-error-action-preference)”。
 
 ## Windows 上默认 shell 的差异
 
-在 Azure Pipelines 中，Windows 平台上脚本的默认 shell 是命令 shell (cmd.exe)。 在 {% data variables.product.prodname_actions %} 中，Windows 平台上脚本的默认 shell 是 PowerShell 。 PowerShell 在内置命令、变量扩展和流控制方面存在若干差异。
+在 Azure Pipelines 中，Windows 平台上脚本的默认 shell 是命令 shell (cmd.exe)。在 {% data variables.product.prodname_actions %} 中，Windows 平台上脚本的默认 shell 是 PowerShell。PowerShell 在内置命令、变量扩展和流控制方面存在若干差异。
 
-如果您运行的是简单的命令，则可以在 PowerShell 中运行命令 shell 脚本，而无需进行任何更改。 但在大多数情况下，您需要使用 PowerShell 语法更新脚本，或者指示 {% data variables.product.prodname_actions %} 使用命令 shell 而不是 PowerShell 来运行脚本。 为此，可以将 `shell` 指定为 `cmd`。
+如果您运行的是简单的命令，则可以在 PowerShell 中运行命令 shell 脚本，而无需进行任何更改。但在大多数情况下，您需要使用 PowerShell 语法更新脚本，或者指示 {% data variables.product.prodname_actions %} 使用命令 shell 而不是 PowerShell 来运行脚本。为此，可以将 `shell` 指定为 `cmd`。
 
 下面是每个系统的语法示例：
 
@@ -163,9 +163,9 @@ jobs:
 
 ## 迁移条件和表达式语法
 
-Azure Pipelines 和 {% data variables.product.prodname_actions %} 可以有条件地运行步骤。 在 Azure Pipelines 中，条件表达式使用 `condition` 键来指定。 在 {% data variables.product.prodname_actions %} 中，条件表达式使用 `if` 键来指定。
+Azure Pipelines 和 {% data variables.product.prodname_actions %} 可以有条件地运行步骤。在 Azure Pipelines 中，条件表达式使用 `condition` 键来指定。在 {% data variables.product.prodname_actions %} 中，条件表达式使用 `if` 键来指定。
 
-Azure Pelines 使用表达式中的函数来有条件地执行步骤。 相反，{% data variables.product.prodname_actions %} 使用 infix 表示法。 例如，必须将 Azure Pipelines 中的 `eq` 函数替换为 {% data variables.product.prodname_actions %} 中的 `==` 运算符。
+Azure Pelines 使用表达式中的函数来有条件地执行步骤。相反，{% data variables.product.prodname_actions %} 使用 infix 表示法。例如，必须将 Azure Pipelines 中的 `eq` 函数替换为 {% data variables.product.prodname_actions %} 中的 `==` 运算符。
 
 下面是每个系统的语法示例：
 
@@ -211,9 +211,9 @@ jobs:
 
 ## 作业之间的依赖关系
 
-Azure Pipelines 和 {% data variables.product.prodname_actions %} 允许您为作业设置依赖项。 在这两个系统中，默认情况下作业并行运行，但可以明确指定作业依赖项。 在 Azure Pipelines 中，这通过 `dependsOn` 键来完成。 在 {% data variables.product.prodname_actions %} 中，这通过 `needs` 键来完成。
+Azure Pipelines 和 {% data variables.product.prodname_actions %} 允许您为作业设置依赖项。在这两个系统中，默认情况下作业并行运行，但可以明确指定作业依赖项。在 Azure Pipelines 中，这通过 `dependsOn` 键来完成。在 {% data variables.product.prodname_actions %} 中，这通过 `needs` 键来完成。
 
-下面是每个系统的语法示例： 工作流启动第一个名为 `initial` 的作业，当该作业完成时，两个分别名为 `fanout1` 和 `fanout2` 的作业将会运行。 最后，当这些作业完成后，作业 `fanin` 将会运行。
+下面是每个系统的语法示例：工作流启动第一个名为 `initial` 的作业，当该作业完成时，两个分别名为 `fanout1` 和 `fanout2` 的作业将会运行。最后，当这些作业完成后，作业 `fanin` 将会运行。
 
 <table class="d-block">
 <tr>
@@ -288,7 +288,7 @@ jobs:
 
 ## 将任务迁移到操作
 
-Azure Pipelines 使用“任务”，这是可在多个工作流中重复使用的应用程序组件。 {% data variables.product.prodname_actions %} 使用“操作”，这可用于执行任务和自定义工作流。 在这两个系统中，您可以指定要运行的任务或操作的名称，以及任何必需的输入作为键/值对。
+Azure Pipelines 使用“任务”，这是可在多个工作流中重复使用的应用程序组件。 {% data variables.product.prodname_actions %} 使用“操作”，这可用于执行任务和自定义工作流。在这两个系统中，您可以指定要运行的任务或操作的名称，以及任何必需的输入作为键/值对。
 
 下面是每个系统的语法示例：
 
@@ -336,4 +336,4 @@ jobs:
 </tr>
 </table>
 
-你可以在 [{% data variables.product.prodname_marketplace %}](https://github.com/marketplace?type=actions) 中找到可用于工作流的操作，也可以创建自己的操作。 有关详细信息，请参阅“[创建操作](/actions/creating-actions)”。
+你可以在 [{% data variables.product.prodname_marketplace %}](https://github.com/marketplace?type=actions) 中找到可用于工作流的操作，也可以创建自己的操作。有关详细信息，请参阅“[创建操作](/actions/creating-actions)”。
diff --git a/translations/zh-CN/content/actions/migrating-to-github-actions/migrating-from-circleci-to-github-actions.md b/translations/zh-CN/content/actions/migrating-to-github-actions/migrating-from-circleci-to-github-actions.md
index e6e70e73d2cc..a4a317927d3b 100644
--- a/translations/zh-CN/content/actions/migrating-to-github-actions/migrating-from-circleci-to-github-actions.md
+++ b/translations/zh-CN/content/actions/migrating-to-github-actions/migrating-from-circleci-to-github-actions.md
@@ -26,7 +26,7 @@ ms.locfileid: '147518966'
 
 ## 简介
 
-CircleCI 和 {% data variables.product.prodname_actions %} 都允许您创建能自动构建、测试、发布、发行和部署代码的工作流程。 CircleCI 和 {% data variables.product.prodname_actions %} 的工作流程配置有一些相似之处：
+CircleCI 和 {% data variables.product.prodname_actions %} 都允许您创建能自动构建、测试、发布、发行和部署代码的工作流程。CircleCI 和 {% data variables.product.prodname_actions %} 的工作流程配置有一些相似之处：
 
 - 工作流程配置文件以 YAML 编写并存储在仓库中。
 - 工作流程包括一项或多项作业。
@@ -39,30 +39,30 @@ CircleCI 和 {% data variables.product.prodname_actions %} 都允许您创建能
 
 从 CircleCI 迁移时，考虑以下差异：
 
-- CircleCI 的自动测试并行性根据用户指定的规则或历史计时信息自动对测试进行分组。 此功能未内置于 {% data variables.product.prodname_actions %}。
-- 在 Docker 容器中执行的操作对权限问题很敏感，因为容器具有不同的用户映射。 可以通过不使用 Dockerfile 中的 `USER` 说明来避免其中许多问题。 {% ifversion ghae %}{% data reusables.actions.self-hosted-runners-software %} {% else %}若要详细了解 {% data variables.product.product_name %} 托管的运行器上的 Docker 文件系统，请参阅“[关于 {% data variables.product.prodname_dotcom %} 托管的运行器](/actions/using-github-hosted-runners/about-github-hosted-runners#docker-container-filesystem)”。
+- CircleCI 的自动测试并行性根据用户指定的规则或历史计时信息自动对测试进行分组。此功能未内置于 {% data variables.product.prodname_actions %}。
+- 在 Docker 容器中执行的操作对权限问题很敏感，因为容器具有不同的用户映射。可以通过不使用 Dockerfile 中的 `USER` 说明来避免其中许多问题。 {% ifversion ghae %}{% data reusables.actions.self-hosted-runners-software %} {% else %}若要详细了解 {% data variables.product.product_name %} 托管的运行器上的 Docker 文件系统，请参阅“[关于 {% data variables.product.prodname_dotcom %} 托管的运行器](/actions/using-github-hosted-runners/about-github-hosted-runners#docker-container-filesystem)”。
 {% endif %}
 
 ## 迁移工作流程和作业
 
-CircleCI 在 config.yml 文件中定义 `workflows`，可以通过它配置多个工作流。 {% data variables.product.product_name %} 要求每个工作流有一个工作流文件，因此不要求你声明 `workflows`。 需要为 config.yml 中配置的每个工作流创建一个新的工作流文件。
+CircleCI 在 config.yml 文件中定义 `workflows`，可以通过它配置多个工作流。 {% data variables.product.product_name %} 要求每个工作流有一个工作流文件，因此不要求你声明 `workflows`。需要为 config.yml 中配置的每个工作流创建一个新的工作流文件。
 
-CircleCI 和 {% data variables.product.prodname_actions %} 在配置文件中使用相似的语法配置 `jobs`。 如果在 CircleCI 工作流程中使用 `requires` 配置作业之间的任何依赖项，那么可以使用等效的 {% data variables.product.prodname_actions %} `needs` 语法。 有关详细信息，请参阅“[{% data variables.product.prodname_actions %} 的工作流语法](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idneeds)”。
+CircleCI 和 {% data variables.product.prodname_actions %} 在配置文件中使用相似的语法配置 `jobs`。如果在 CircleCI 工作流程中使用 `requires` 配置作业之间的任何依赖项，那么可以使用等效的 {% data variables.product.prodname_actions %} `needs` 语法。有关详细信息，请参阅“[{% data variables.product.prodname_actions %} 的工作流语法](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idneeds)”。
 
 ## 将 orbs 迁移到操作
 
-CircleCI 和 {% data variables.product.prodname_actions %} 都提供在工作流程中重复使用和共享任务的机制。 CircleCI 使用以 YAML 编写的概念 orbs 来提供人们可以在工作流程中重复使用的任务。 {% data variables.product.prodname_actions %} 具有强大而灵活的可重复使用的组件，称为“操作”，您可以使用 JavaScript 文件或 Docker 映像来构建操作。 您可以编写自定义代码来创建操作，以您喜欢的方式与仓库交互，包括使用 {% data variables.product.product_name %} 的 API 以及任何公开的第三方 API 进行交互。 例如，操作可以发布 npm 模块、在创建紧急问题时发送短信提醒，或者部署可用于生产的代码。 有关详细信息，请参阅“[创建操作](/actions/creating-actions)”。
+CircleCI 和 {% data variables.product.prodname_actions %} 都提供在工作流程中重复使用和共享任务的机制。CircleCI 使用以 YAML 编写的概念 orbs 来提供人们可以在工作流程中重复使用的任务。 {% data variables.product.prodname_actions %} 具有强大而灵活的可重复使用的组件，称为“操作”，您可以使用 JavaScript 文件或 Docker 映像来构建操作。您可以编写自定义代码来创建操作，以您喜欢的方式与仓库交互，包括使用 {% data variables.product.product_name %} 的 API 以及任何公开的第三方 API 进行交互。例如，操作可以发布 npm 模块、在创建紧急问题时发送短信提醒，或者部署可用于生产的代码。有关详细信息，请参阅“[创建操作](/actions/creating-actions)”。
 
-CircleCI 可以使用 YAML 锚点和别名来重复使用工作流程的组件。 {% data variables.product.prodname_actions %} 支持对于重复使用矩阵的最常见需求。 有关矩阵的详细信息，请参阅“[为作业使用矩阵](/actions/using-jobs/using-a-matrix-for-your-jobs)”。
+CircleCI 可以使用 YAML 锚点和别名来重复使用工作流程的组件。 {% data variables.product.prodname_actions %} 支持对于重复使用矩阵的最常见需求。有关矩阵的详细信息，请参阅“[为作业使用矩阵](/actions/using-jobs/using-a-matrix-for-your-jobs)”。
 
 ## 使用 Docker 映像
 
 
 CircleCI 和 {% data variables.product.prodname_actions %} 都支持在 Docker 映像中运行步骤。
 
-CircleCI 提供一套具有共同依赖项的预建映像。 这些映像的 `USER` 设置为 `circleci`，会导致权限与 {% data variables.product.prodname_actions %} 冲突。
+CircleCI 提供一套具有共同依赖项的预建映像。这些映像的 `USER` 设置为 `circleci`，会导致权限与 {% data variables.product.prodname_actions %} 冲突。
 
-建议在迁移到 {% data variables.product.prodname_actions %} 时不使用 CircleCI 的预建映像。 在许多情况下，您可以使用操作来安装需要的附加依赖项。
+建议在迁移到 {% data variables.product.prodname_actions %} 时不使用 CircleCI 的预建映像。在许多情况下，您可以使用操作来安装需要的附加依赖项。
 
 {% ifversion ghae %} 有关 Docker 文件系统的详细信息，请参阅“[Docker 容器文件系统](/actions/using-github-hosted-runners/about-ae-hosted-runners#docker-container-filesystem)”。
 
@@ -290,7 +290,7 @@ jobs:
 
 ## 完整的示例
 
-下面是一个真实的示例。 左边显示用于 [thoughtbot/administrator](https://github.com/thoughtbot/administrate) 存储库的实际 CircleCI config.yml。 右边显示 {% data variables.product.prodname_actions %} 等效项。
+下面是一个真实的示例。左边显示用于 [thoughtbot/administrator](https://github.com/thoughtbot/administrate) 存储库的实际 CircleCI config.yml。右边显示 {% data variables.product.prodname_actions %} 等效项。
 
 <table class="d-block">
 <tr>
diff --git a/translations/zh-CN/content/actions/migrating-to-github-actions/migrating-from-gitlab-cicd-to-github-actions.md b/translations/zh-CN/content/actions/migrating-to-github-actions/migrating-from-gitlab-cicd-to-github-actions.md
index 19177c6c4168..ec4025788a30 100644
--- a/translations/zh-CN/content/actions/migrating-to-github-actions/migrating-from-gitlab-cicd-to-github-actions.md
+++ b/translations/zh-CN/content/actions/migrating-to-github-actions/migrating-from-gitlab-cicd-to-github-actions.md
@@ -26,7 +26,7 @@ ms.locfileid: '146178981'
 
 ## 简介
 
-GitLab CI/CD 和 {% data variables.product.prodname_actions %} 都允许您创建能自动构建、测试、发布、发行和部署代码的工作流程。 GitLab CI/CD 和 {% data variables.product.prodname_actions %} 的工作流程配置有一些相似之处：
+GitLab CI/CD 和 {% data variables.product.prodname_actions %} 都允许您创建能自动构建、测试、发布、发行和部署代码的工作流程。GitLab CI/CD 和 {% data variables.product.prodname_actions %} 的工作流程配置有一些相似之处：
 
 - 工作流程配置文件以 YAML 编写并存储在代码仓库中。
 - 工作流程包括一项或多项作业。
@@ -37,13 +37,13 @@ GitLab CI/CD 和 {% data variables.product.prodname_actions %} 都允许您创
 
 ## 作业
 
-GitLab CI/CD 中的作业非常类似于 {% data variables.product.prodname_actions %} 中的作业。 在这两个系统中，作业具有以下特征：
+GitLab CI/CD 中的作业非常类似于 {% data variables.product.prodname_actions %} 中的作业。在这两个系统中，作业具有以下特征：
 
 * 作业包含一系列按顺序运行的步骤或脚本。
 * 作业可在单独的计算机或单独的容器中运行。
 * 默认情况下作业并行运行，但可以配置为按顺序运行。
 
-可在作业中运行脚本或 shell 命令。 在 GitLab CI/CD 中，使用 `script` 键指定脚本步骤。 在 {% data variables.product.prodname_actions %} 中，所有脚本都使用 `run` 键来指定。
+可在作业中运行脚本或 shell 命令。在 GitLab CI/CD 中，使用 `script` 键指定脚本步骤。在 {% data variables.product.prodname_actions %} 中，所有脚本都使用 `run` 键来指定。
 
 下面是每个系统的语法示例：
 
@@ -84,7 +84,7 @@ jobs:
 
 ## 运行程序
 
-运行器是运行作业的机器。 GitLab CI/CD 和 {% data variables.product.prodname_actions %} 提供托管和自托管的运行器变体。 在 GitLab CI/CD 中，`tags` 用于在不同的平台上运行作业，而在 {% data variables.product.prodname_actions %} 中，它使用 `runs-on` 键运行。
+运行器是运行作业的机器。GitLab CI/CD 和 {% data variables.product.prodname_actions %} 提供托管和自托管的运行器变体。在 GitLab CI/CD 中，`tags` 用于在不同的平台上运行作业，而在 {% data variables.product.prodname_actions %} 中，它使用 `runs-on` 键运行。
 
 下面是每个系统的语法示例：
 
@@ -135,7 +135,7 @@ linux_job:
 
 ## Docker 映像
 
-GitLab CI/CD 和 {% data variables.product.prodname_actions %} 都支持在 Docker 映像中运行作业。 在 GitLab CI/CD 中，Docker 映像使用 `image` 键定义，而在 {% data variables.product.prodname_actions %} 中，它使用 `container` 键定义。
+GitLab CI/CD 和 {% data variables.product.prodname_actions %} 都支持在 Docker 映像中运行作业。在 GitLab CI/CD 中，Docker 映像使用 `image` 键定义，而在 {% data variables.product.prodname_actions %} 中，它使用 `container` 键定义。
 
 下面是每个系统的语法示例：
 
@@ -218,9 +218,9 @@ jobs:
 
 ## 作业之间的依赖关系
 
-GitLab CI/CD 和 {% data variables.product.prodname_actions %} 允许您为作业设置依赖项。 在这两个系统中，默认情况下作业并行运行，但 {% data variables.product.prodname_actions %} 中的作业依赖项可以用 `needs` 键进行显式指定。 GitLab CI/CD 还具有 `stages` 的概念，其中作业分阶段同时运行，但下一阶段将在前一阶段的所有作业完成时开始。 可以使用 `needs` 键在 {% data variables.product.prodname_actions %} 中重新创建此情景。
+GitLab CI/CD 和 {% data variables.product.prodname_actions %} 允许您为作业设置依赖项。在这两个系统中，默认情况下作业并行运行，但 {% data variables.product.prodname_actions %} 中的作业依赖项可以用 `needs` 键进行显式指定。GitLab CI/CD 还具有 `stages` 的概念，其中作业分阶段同时运行，但下一阶段将在前一阶段的所有作业完成时开始。可以使用 `needs` 键在 {% data variables.product.prodname_actions %} 中重新创建此情景。
 
-下面是每个系统的语法示例： 工作流首先同时运行两个名为 `build_a` 和 `build_b` 的作业，当这些作业完成后，另一个名为 `test_ab` 的作业将运行。 最后，`test_ab` 完成后，`deploy_ab` 作业将运行。
+下面是每个系统的语法示例：工作流首先同时运行两个名为 `build_a` 和 `build_b` 的作业，当这些作业完成后，另一个名为 `test_ab` 的作业将运行。最后，`test_ab` 完成后，`deploy_ab` 作业将运行。
 
 <table class="d-block">
 <tr>
@@ -289,7 +289,7 @@ jobs:
 
 ## 预定工作流程
 
-GitLab CI/CD 和 {% data variables.product.prodname_actions %} 允许您以特定的间隔运行工作流程。 在 GitLab CI/CD 中，管道计划使用 UI 配置，而在 {% data variables.product.prodname_actions %} 中，您可以使用 "on" 键在预定的间隔时间触发工作流程。
+GitLab CI/CD 和 {% data variables.product.prodname_actions %} 允许您以特定的间隔运行工作流程。在 GitLab CI/CD 中，管道计划使用 UI 配置，而在 {% data variables.product.prodname_actions %} 中，您可以使用 "on" 键在预定的间隔时间触发工作流程。
 
 有关详细信息，请参阅“[触发工作流的事件](/actions/reference/events-that-trigger-workflows#scheduled-events)”。
 
@@ -360,7 +360,7 @@ jobs:
 
 ## Artifacts
 
-GitLab CI/CD 和 {% data variables.product.prodname_actions %} 都可以上传作业创建的文件和目录作为构件。 在 {% data variables.product.prodname_actions %} 中，构件可用于在多个作业中保留数据。
+GitLab CI/CD 和 {% data variables.product.prodname_actions %} 都可以上传作业创建的文件和目录作为构件。在 {% data variables.product.prodname_actions %} 中，构件可用于在多个作业中保留数据。
 
 下面是每个系统的语法示例：
 
@@ -404,7 +404,7 @@ artifacts:
 
 这两个系统都允许您包括用于数据库、缓存或其他依赖项的其他容器。
 
-在 GitLab CI/CD 中，作业的容器使用 `image` 键指定，而 {% data variables.product.prodname_actions %} 使用 `container` 键指定。 在这两个系统中，使用 `services` 键指定附加服务容器。
+在 GitLab CI/CD 中，作业的容器使用 `image` 键指定，而 {% data variables.product.prodname_actions %} 使用 `container` 键指定。在这两个系统中，使用 `services` 键指定附加服务容器。
 
 下面是每个系统的语法示例：
 
diff --git a/translations/zh-CN/content/actions/migrating-to-github-actions/migrating-from-jenkins-to-github-actions.md b/translations/zh-CN/content/actions/migrating-to-github-actions/migrating-from-jenkins-to-github-actions.md
index eedd3ecc103a..24f5029336ad 100644
--- a/translations/zh-CN/content/actions/migrating-to-github-actions/migrating-from-jenkins-to-github-actions.md
+++ b/translations/zh-CN/content/actions/migrating-to-github-actions/migrating-from-jenkins-to-github-actions.md
@@ -26,31 +26,31 @@ ms.locfileid: '145100215'
 
 ## 简介
 
-Jenkins 和 {% data variables.product.prodname_actions %} 都允许您创建能自动构建、测试、发布、发行和部署代码的工作流程。 Jenkins 和 {% data variables.product.prodname_actions %} 的工作流程配置有一些相似之处：
+Jenkins 和 {% data variables.product.prodname_actions %} 都允许您创建能自动构建、测试、发布、发行和部署代码的工作流程。Jenkins 和 {% data variables.product.prodname_actions %} 的工作流程配置有一些相似之处：
 
 - Jenkins 使用 Declarative Pelines 创建工作流，这些工作流类似于 {% data variables.product.prodname_actions %} 工作流文件。
 - Jenkins 使用阶段运行步骤集合，而 {% data variables.product.prodname_actions %} 则使用作业对一个或多个步骤或单个命令进行分组。
-- Jenkins 和 {% data variables.product.prodname_actions %} 支持基于容器的构建。 有关详细信息，请参阅“[创建 Docker 容器操作](/articles/creating-a-docker-container-action)”。
+- Jenkins 和 {% data variables.product.prodname_actions %} 支持基于容器的构建。有关详细信息，请参阅“[创建 Docker 容器操作](/articles/creating-a-docker-container-action)”。
 - 步骤或任务可以重复使用并与社区共享。
 
 有关详细信息，请参阅“[{% data variables.product.prodname_actions %} 的核心概念](/actions/getting-started-with-github-actions/core-concepts-for-github-actions)”。
 
 ## 主要差异
 
-- Jenkins 有两种类型的语法用来创建管道：Declarative Pipeline 和 Scripted Pipeline。 {% data variables.product.prodname_actions %} 使用 YAML 创建工作流程和配置文件。 有关详细信息，请参阅“[GitHub Actions 的工作流语法](/actions/reference/workflow-syntax-for-github-actions)”。
-- Jenkins 部署通常是自托管的，用户在自己的数据中心维护服务器。 {% data variables.product.prodname_actions %} 通过托管自己可用于运行作业的运行器提供混合云方法，同时也支持自托管运行器。 有关详细信息，请参阅[关于自承载运行器](/actions/hosting-your-own-runners/about-self-hosted-runners)。
+- Jenkins 有两种类型的语法用来创建管道：Declarative Pipeline 和 Scripted Pipeline。 {% data variables.product.prodname_actions %} 使用 YAML 创建工作流程和配置文件。有关详细信息，请参阅“[GitHub Actions 的工作流语法](/actions/reference/workflow-syntax-for-github-actions)”。
+- Jenkins 部署通常是自托管的，用户在自己的数据中心维护服务器。 {% data variables.product.prodname_actions %} 通过托管自己可用于运行作业的运行器提供混合云方法，同时也支持自托管运行器。有关详细信息，请参阅[关于自承载运行器](/actions/hosting-your-own-runners/about-self-hosted-runners)。
 
 ## 比较功能
 
 ### 分发版本
 
-Jenkins 可让您发送版本到单个构建代理，或者您可以在多个代理之间进行分发。 您也可以根据不同的属性（例如操作系统类型）对这些代理进行分类。
+Jenkins 可让您发送版本到单个构建代理，或者您可以在多个代理之间进行分发。您也可以根据不同的属性（例如操作系统类型）对这些代理进行分类。
 
-同样， {% data variables.product.prodname_actions %} 可以向 {% data variables.product.prodname_dotcom %} 托管或自托管的运行器发送作业，您可以根据不同的属性使用标签对运行器分类。 有关详细信息，请参阅“[{% data variables.product.prodname_actions %}](/actions/learn-github-actions/understanding-github-actions#runners)”和“[关于自承载运行器](/actions/hosting-your-own-runners/about-self-hosted-runners)”。
+同样， {% data variables.product.prodname_actions %} 可以向 {% data variables.product.prodname_dotcom %} 托管或自托管的运行器发送作业，您可以根据不同的属性使用标签对运行器分类。有关详细信息，请参阅“[{% data variables.product.prodname_actions %}](/actions/learn-github-actions/understanding-github-actions#runners)”和“[关于自承载运行器](/actions/hosting-your-own-runners/about-self-hosted-runners)”。
 
 ### 使用区段组织管道
 
-Jenkins 将其 Declarative Pipelines 分为多个区段。 同样，{% data variables.product.prodname_actions %} 也将其工作流程分成单独的部分。 下表比较了Jenkins 区段与 {% data variables.product.prodname_actions %} 工作流程。
+Jenkins 将其 Declarative Pipelines 分为多个区段。同样，{% data variables.product.prodname_actions %} 也将其工作流程分成单独的部分。下表比较了 Jenkins 区段与 {% data variables.product.prodname_actions %} 工作流程。
 
 | Jenkins 指令 | {% data variables.product.prodname_actions %} |
 | ------------- | ------------- |
@@ -61,7 +61,7 @@ Jenkins 将其 Declarative Pipelines 分为多个区段。 同样，{% data vari
 
 ## using 指令
 
-Jenkins 使用指令来管理 Declarative Pipelines。 这些指令定义工作流程的特性及其执行方式。 下表演示这些指令如何映射到 {% data variables.product.prodname_actions %} 中的概念。
+Jenkins 使用指令来管理 Declarative Pipelines。这些指令定义工作流程的特性及其执行方式。下表演示这些指令如何映射到 {% data variables.product.prodname_actions %} 中的概念。
 
 | Jenkins 指令 | {% data variables.product.prodname_actions %} |
 | ------------- | ------------- |
@@ -98,7 +98,7 @@ Jenkins 可以并行运行 `stages` 和 `steps`，而 {% data variables.product.
 
 ### 使用步骤执行任务
 
-Jenkins 按 `stages` 将 `steps` 分组在一起。 每个步骤都可以是脚本、函数或命令等。 同样，{% data variables.product.prodname_actions %} 使用 `jobs` 来执行特定的 `steps` 组。
+Jenkins 按 `stages` 将 `steps` 分组在一起。每个步骤都可以是脚本、函数或命令等。同样，{% data variables.product.prodname_actions %} 使用 `jobs` 来执行特定的 `steps` 组。
 
 | Jenkins 步骤 | {% data variables.product.prodname_actions %} |
 | ------------- | ------------- |
diff --git a/translations/zh-CN/content/actions/migrating-to-github-actions/migrating-from-travis-ci-to-github-actions.md b/translations/zh-CN/content/actions/migrating-to-github-actions/migrating-from-travis-ci-to-github-actions.md
index 909c123c1220..8e2140997a4d 100644
--- a/translations/zh-CN/content/actions/migrating-to-github-actions/migrating-from-travis-ci-to-github-actions.md
+++ b/translations/zh-CN/content/actions/migrating-to-github-actions/migrating-from-travis-ci-to-github-actions.md
@@ -26,7 +26,7 @@ ms.locfileid: '146178989'
 
 ## 简介
 
-本指南可帮助您从 Travis CI 迁移到 {% data variables.product.prodname_actions %}。 它会比较它们的概念和语法、描述相似之处，并演示了它们处理常见任务的不同方法。
+本指南可帮助您从 Travis CI 迁移到 {% data variables.product.prodname_actions %}。它会比较它们的概念和语法、描述相似之处，并演示了它们处理常见任务的不同方法。
 
 ## 开始之前
 
@@ -37,7 +37,7 @@ ms.locfileid: '146178989'
 
 ## 比较作业执行
 
-为了让你控制 CI 任务的执行时间，{% data variables.product.prodname_actions %} 工作流使用默认并行运行的作业 。 每个作业都包含按你定义的顺序执行的步骤。 如果需要为作业运行设置和清理操作，可以在每个作业中定义执行这些操作的步骤。
+为了让你控制 CI 任务的执行时间，{% data variables.product.prodname_actions %} 工作流使用默认并行运行的作业。每个作业都包含按你定义的顺序执行的步骤。如果需要为作业运行设置和清理操作，可以在每个作业中定义执行这些操作的步骤。
 
 ## 主要相似之处
 
@@ -45,19 +45,19 @@ ms.locfileid: '146178989'
 
 ### Using YAML syntax
 
-Travis CI 和 {% data variables.product.prodname_actions %} 同时使用 YAML 创建作业和工作流程，并且这些文件存储在代码仓库中。 有关 {% data variables.product.prodname_actions %} 如何使用 YAML 的详细信息，请参阅“[创建工作流文件](/actions/learn-github-actions/introduction-to-github-actions#create-an-example-workflow)”。
+Travis CI 和 {% data variables.product.prodname_actions %} 同时使用 YAML 创建作业和工作流程，并且这些文件存储在代码仓库中。有关 {% data variables.product.prodname_actions %} 如何使用 YAML 的详细信息，请参阅“[创建工作流文件](/actions/learn-github-actions/introduction-to-github-actions#create-an-example-workflow)”。
 
 ### 自定义环境变量
 
-Travis CI 允许您设置环境变量并在各个阶段之间共享它们。 同样，{% data variables.product.prodname_actions %} 允许您为步骤、作业或工作流程定义环境变量。 有关详细信息，请参阅“[环境变量](/actions/reference/environment-variables)”。
+Travis CI 允许您设置环境变量并在各个阶段之间共享它们。同样，{% data variables.product.prodname_actions %} 允许您为步骤、作业或工作流程定义环境变量。有关详细信息，请参阅“[环境变量](/actions/reference/environment-variables)”。
 
 ### 默认环境变量
 
-Travis CI 和 {% data variables.product.prodname_actions %} 都包括可以在 YAML 文件中使用的默认环境变量。 对于 {% data variables.product.prodname_actions %}，可以在“[默认环境变量](/actions/reference/environment-variables#default-environment-variables)”中查看这些内容。
+Travis CI 和 {% data variables.product.prodname_actions %} 都包括可以在 YAML 文件中使用的默认环境变量。对于 {% data variables.product.prodname_actions %}，可以在“[默认环境变量](/actions/reference/environment-variables#default-environment-variables)”中查看这些内容。
 
 ### 并行作业处理
 
-Travis CI 可以使用 `stages` 并行运行作业。 同样，{% data variables.product.prodname_actions %} 并行运行 `jobs`。 有关详细信息，请参阅“[创建依赖作业](/actions/learn-github-actions/managing-complex-workflows#creating-dependent-jobs)”。
+Travis CI 可以使用 `stages` 并行运行作业。同样，{% data variables.product.prodname_actions %} 并行运行 `jobs`。有关详细信息，请参阅“[创建依赖作业](/actions/learn-github-actions/managing-complex-workflows#creating-dependent-jobs)”。
 
 ### 状态徽章
 
@@ -66,7 +66,7 @@ Travis CI 和 {% data variables.product.prodname_actions %} 都支持状态徽
 
 ### 使用矩阵
 
-Travis CI 和 {% data variables.product.prodname_actions %} 都支持矩阵，你可以使用操作系统和软件包的组合执行测试。 有关详细信息，请参阅“[为作业使用矩阵](/actions/using-jobs/using-a-matrix-for-your-jobs)”。
+Travis CI 和 {% data variables.product.prodname_actions %} 都支持矩阵，你可以使用操作系统和软件包的组合执行测试。有关详细信息，请参阅“[为作业使用矩阵](/actions/using-jobs/using-a-matrix-for-your-jobs)”。
 
 下面是比较每个系统的语法示例：
 
@@ -106,7 +106,7 @@ jobs:
 
 ### 定向特定分支
 
-Travis CI 和 {% data variables.product.prodname_actions %} 允许您将 CI 定向到特定分支。 有关详细信息，请参阅“[GitHub Actions 的工作流语法](/actions/reference/workflow-syntax-for-github-actions#onpushbranchestagsbranches-ignoretags-ignore)”。
+Travis CI 和 {% data variables.product.prodname_actions %} 允许您将 CI 定向到特定分支。有关详细信息，请参阅“[GitHub Actions 的工作流语法](/actions/reference/workflow-syntax-for-github-actions#onpushbranchestagsbranches-ignoretags-ignore)”。
 
 下面是每个系统的语法示例：
 
@@ -192,27 +192,27 @@ Travis CI 和 {% data variables.product.prodname_actions %} 可以将自定义
 
 ### 存储机密
 
-{% data variables.product.prodname_actions %} 允许您存储密码并在作业中引用它们。 {% data variables.product.prodname_actions %} 组织可以限制哪些仓库能够访问组织机密。 环境保护规则可能需要手动批准工作流程才能访问环境秘密。 有关详细信息，请参阅“[加密机密](/actions/reference/encrypted-secrets)”。
+{% data variables.product.prodname_actions %} 允许您存储密码并在作业中引用它们。 {% data variables.product.prodname_actions %} 组织可以限制哪些仓库能够访问组织机密。环境保护规则可能需要手动批准工作流程才能访问环境秘密。有关详细信息，请参阅“[加密机密](/actions/reference/encrypted-secrets)”。
 
 ### 在作业和工作流程之间共享文件
 
-{% data variables.product.prodname_actions %} 包括对构件存储的集成支持，允许您在工作流程中的作业之间共享文件。 您还可以保存生成的文件，并与其他工作流程共享它们。 有关详细信息，请参阅“[在作业之间共享数据](/actions/learn-github-actions/essential-features-of-github-actions#sharing-data-between-jobs)”。
+{% data variables.product.prodname_actions %} 包括对构件存储的集成支持，允许您在工作流程中的作业之间共享文件。您还可以保存生成的文件，并与其他工作流程共享它们。有关详细信息，请参阅“[在作业之间共享数据](/actions/learn-github-actions/essential-features-of-github-actions#sharing-data-between-jobs)”。
 
 ### 托管您自己的运行器
 
-如果您的作业需要特定的硬件或软件，{% data variables.product.prodname_actions %} 允许您托管自己的运行器，并将其作业发送给它们进行处理。 {% data variables.product.prodname_actions %} 还允许您使用策略来控制访问这些运行器的方式，在组织或仓库级别授予访问权限。 有关详细信息，请参阅“[托管自己的运行器](/actions/hosting-your-own-runners)”。
+如果您的作业需要特定的硬件或软件，{% data variables.product.prodname_actions %} 允许您托管自己的运行器，并将其作业发送给它们进行处理。 {% data variables.product.prodname_actions %} 还允许您使用策略来控制访问这些运行器的方式，在组织或仓库级别授予访问权限。有关详细信息，请参阅“[托管自己的运行器](/actions/hosting-your-own-runners)”。
 
 {% ifversion fpt or ghec %}
 
 ### 并行作业和执行时间
 
-{% data variables.product.prodname_actions %} 中的并行作业和工作流程执行时间因 {% data variables.product.company_short %} 计划而异。 有关详细信息，请参阅“[使用限制、计费和管理](/actions/reference/usage-limits-billing-and-administration)”。
+{% data variables.product.prodname_actions %} 中的并行作业和工作流程执行时间因 {% data variables.product.company_short %} 计划而异。有关详细信息，请参阅“[使用限制、计费和管理](/actions/reference/usage-limits-billing-and-administration)”。
 
 {% endif %}
 
 ### 在 {% data variables.product.prodname_actions %} 中使用不同的语言
 
-在 {% data variables.product.prodname_actions %} 中使用不同语言时，您可以在作业中创建步骤来设置语言依赖项。 有关使用特定语言的信息，请参阅特定指南：
+在 {% data variables.product.prodname_actions %} 中使用不同语言时，您可以在作业中创建步骤来设置语言依赖项。有关使用特定语言的信息，请参阅特定指南：
   - [生成和测试 Node.js](/actions/guides/building-and-testing-nodejs)
   - [生成和测试 Python](/actions/guides/building-and-testing-python)
   - [生成和测试 PowerShell](/actions/guides/building-and-testing-powershell)
@@ -222,7 +222,7 @@ Travis CI 和 {% data variables.product.prodname_actions %} 可以将自定义
 
 ## 执行脚本
 
-{% data variables.product.prodname_actions %} 可以使用 `run` 步骤运行脚本或 shell 命令。 若要使用特定的 shell，可以在提供脚本路径时指定 `shell` 类型。 有关详细信息，请参阅 [{% data variables.product.prodname_actions %} 的工作流语法](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepsrun)。
+{% data variables.product.prodname_actions %} 可以使用 `run` 步骤运行脚本或 shell 命令。若要使用特定的 shell，可以在提供脚本路径时指定 `shell` 类型。有关详细信息，请参阅 [{% data variables.product.prodname_actions %} 的工作流语法](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepsrun)。
 
 例如：
 
@@ -239,15 +239,15 @@ steps:
 
 ### 脚本错误处理
 
-如果其中一个步骤返回错误代码，{% data variables.product.prodname_actions %} 将立即停止作业。 有关详细信息，请参阅 [{% data variables.product.prodname_actions %} 的工作流语法](/actions/reference/workflow-syntax-for-github-actions#exit-codes-and-error-action-preference)。
+如果其中一个步骤返回错误代码，{% data variables.product.prodname_actions %} 将立即停止作业。有关详细信息，请参阅 [{% data variables.product.prodname_actions %} 的工作流语法](/actions/reference/workflow-syntax-for-github-actions#exit-codes-and-error-action-preference)。
 
 ### 作业错误处理
 
-{% data variables.product.prodname_actions %} 使用 `if` 条件在特定情况下执行作业或步骤。 例如，你可以在某个步骤导致 `failure()` 时运行另一个步骤。 有关详细信息，请参阅 [{% data variables.product.prodname_actions %} 的工作流语法](/actions/reference/workflow-syntax-for-github-actions#example-using-status-check-functions)。  还可以使用 [`continue-on-error`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idcontinue-on-error) 防止工作流在作业失败时停止运行。
+{% data variables.product.prodname_actions %} 使用 `if` 条件在特定情况下执行作业或步骤。例如，你可以在某个步骤导致 `failure()` 时运行另一个步骤。有关详细信息，请参阅 [{% data variables.product.prodname_actions %} 的工作流语法](/actions/reference/workflow-syntax-for-github-actions#example-using-status-check-functions)。还可以使用 [`continue-on-error`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idcontinue-on-error) 防止工作流在作业失败时停止运行。
 
 ## 迁移条件和表达式的语法
 
-若要在条件表达式下运行作业，Travis CI 和 {% data variables.product.prodname_actions %} 将具有类似的 `if` 条件语法。 通过 {% data variables.product.prodname_actions %}，可以使用 `if` 条件来使作业或步骤仅在满足条件时才运行。 有关详细信息，请参阅“[表达式](/actions/learn-github-actions/expressions)”。
+若要在条件表达式下运行作业，Travis CI 和 {% data variables.product.prodname_actions %} 将具有类似的 `if` 条件语法。通过 {% data variables.product.prodname_actions %}，可以使用 `if` 条件来使作业或步骤仅在满足条件时才运行。有关详细信息，请参阅“[表达式](/actions/learn-github-actions/expressions)”。
 
 此示例演示 `if` 条件如何控制是否执行步骤：
 
@@ -262,7 +262,7 @@ jobs:
 
 ## 将阶段迁移到步骤
 
-Travis CI 使用阶段来运行步骤，而 {% data variables.product.prodname_actions %} 具有步骤来执行操作   。 可以在 [{% data variables.product.prodname_marketplace %}](https://github.com/marketplace?type=actions) 中找到预生成的操作，也可以创建自己的操作。 有关详细信息，请参阅“[生成操作](/actions/building-actions)”。
+Travis CI 使用阶段来运行步骤，而 {% data variables.product.prodname_actions %} 具有步骤来执行操作。可以在 [{% data variables.product.prodname_marketplace %}](https://github.com/marketplace?type=actions) 中找到预生成的操作，也可以创建自己的操作。有关详细信息，请参阅“[生成操作](/actions/building-actions)”。
 
 下面是每个系统的语法示例：
 
@@ -359,7 +359,7 @@ cache: npm
 
 ### 配置环境变量
 
-您可以在 {% data variables.product.prodname_actions %} 作业中创建自定义环境变量。 例如：
+您可以在 {% data variables.product.prodname_actions %} 作业中创建自定义环境变量。例如：
 
 <table>
 <tr>
diff --git a/translations/zh-CN/content/actions/monitoring-and-troubleshooting-workflows/about-monitoring-and-troubleshooting.md b/translations/zh-CN/content/actions/monitoring-and-troubleshooting-workflows/about-monitoring-and-troubleshooting.md
index 6f92c5120879..7d456a8af244 100644
--- a/translations/zh-CN/content/actions/monitoring-and-troubleshooting-workflows/about-monitoring-and-troubleshooting.md
+++ b/translations/zh-CN/content/actions/monitoring-and-troubleshooting-workflows/about-monitoring-and-troubleshooting.md
@@ -28,7 +28,7 @@ ms.locfileid: '147062040'
 
 ### 使用可视化图表
 
-每个工作流程运行都会生成一个实时图表，说明运行进度。 您可以使用此图表来监控和调试工作流程。 例如：
+每个工作流程运行都会生成一个实时图表，说明运行进度。您可以使用此图表来监控和调试工作流程。例如：
 
    ![工作流程图表](/assets/images/help/images/workflow-graph.png)
 
@@ -43,7 +43,7 @@ ms.locfileid: '147062040'
 {% ifversion fpt or ghec %}
 ### 查看作业执行时间
 
-要确定作业运行所花费的时间，可以查看其执行时间。 例如：
+要确定作业运行所花费的时间，可以查看其执行时间。例如：
 
    ![运行和可计费时间详细信息链接](/assets/images/help/repository/view-run-billable-time.png)
 
@@ -52,7 +52,7 @@ ms.locfileid: '147062040'
 
 ### 查看工作流程运行历史记录
 
-您可以查看工作流程中每个作业和步骤的状态。 例如：
+您可以查看工作流程中每个作业和步骤的状态。例如：
 
    ![工作流程运行的名称](/assets/images/help/repository/run-name.png)
 
@@ -62,7 +62,7 @@ ms.locfileid: '147062040'
 
 ### 使用工作流运行日志
 
-每个工作流程运行都会生成活动日志，您可以查看、搜索和下载这些日志。 例如：
+每个工作流程运行都会生成活动日志，您可以查看、搜索和下载这些日志。例如：
 
    ![Super linter 工作流程结果](/assets/images/help/repository/super-linter-workflow-results-updated-2.png)
 
@@ -70,7 +70,7 @@ ms.locfileid: '147062040'
 
 ### 启用调试日志记录
 
-如果工作流程日志没有提供足够的详细信息来诊断工作流程、作业或步骤未按预期工作的原因，您可以启用额外的调试日志。 有关详细信息，请参阅“[启用调试日志记录](/actions/monitoring-and-troubleshooting-workflows/enabling-debug-logging)”。
+如果工作流程日志没有提供足够的详细信息来诊断工作流程、作业或步骤未按预期工作的原因，您可以启用额外的调试日志。有关详细信息，请参阅“[启用调试日志记录](/actions/monitoring-and-troubleshooting-workflows/enabling-debug-logging)”。
 
 ## 对自托管运行程序进行监视和故障排除
 
diff --git a/translations/zh-CN/content/actions/monitoring-and-troubleshooting-workflows/adding-a-workflow-status-badge.md b/translations/zh-CN/content/actions/monitoring-and-troubleshooting-workflows/adding-a-workflow-status-badge.md
index 9bf13fcc19fa..7b9323193418 100644
--- a/translations/zh-CN/content/actions/monitoring-and-troubleshooting-workflows/adding-a-workflow-status-badge.md
+++ b/translations/zh-CN/content/actions/monitoring-and-troubleshooting-workflows/adding-a-workflow-status-badge.md
@@ -27,7 +27,7 @@ ms.locfileid: '147880627'
 {% data reusables.repositories.actions-workflow-status-badge-intro %}
 
 
-若要向 `README.md` 文件添加工作流状态徽章，请首先找到要显示的状态徽章的 URL。 然后，可以使用 Markdown 将徽章显示为 `README.md` 文件中的图像。 有关 Markdown 中的图像标记的详细信息，请参阅“[基本编写和格式设置语法](/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#images)”。
+若要向 `README.md` 文件添加工作流状态徽章，请首先找到要显示的状态徽章的 URL。然后，可以使用 Markdown 将徽章显示为 `README.md` 文件中的图像。有关 Markdown 中的图像标记的详细信息，请参阅“[基本编写和格式设置语法](/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#images)”。
 
 ## 使用工作流程文件名称
 
@@ -37,9 +37,9 @@ ms.locfileid: '147880627'
 {% ifversion fpt or ghec %}https://github.com{% else %}<HOSTNAME>{% endif %}/<OWNER>/<REPOSITORY>/actions/workflows/<WORKFLOW_FILE>/badge.svg
 ```
 
-若要在 `README.md` 文件中显示工作流状态徽章，请使用 Markdown 标记来嵌入图像。 有关 Markdown 中的图像标记的详细信息，请参阅“[基本编写和格式设置语法](/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#images)”。
+若要在 `README.md` 文件中显示工作流状态徽章，请使用 Markdown 标记来嵌入图像。有关 Markdown 中的图像标记的详细信息，请参阅“[基本编写和格式设置语法](/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#images)”。
 
-例如，将以下 Markdown 添加到 `README.md` 文件，可为文件路径为 `.github/workflows/main.yml` 的工作流添加状态徽章。 存储库的 `OWNER` 是 `github` 组织，`REPOSITORY` 名称为 `docs`。
+例如，将以下 Markdown 添加到 `README.md` 文件，可为文件路径为 `.github/workflows/main.yml` 的工作流添加状态徽章。存储库的 `OWNER` 是 `github` 组织，`REPOSITORY` 名称为 `docs`。
 
 ```markdown
 ![example workflow](https://github.com/github/docs/actions/workflows/main.yml/badge.svg)
diff --git a/translations/zh-CN/content/actions/monitoring-and-troubleshooting-workflows/enabling-debug-logging.md b/translations/zh-CN/content/actions/monitoring-and-troubleshooting-workflows/enabling-debug-logging.md
index 0099300fc129..3609ccc3c6a6 100644
--- a/translations/zh-CN/content/actions/monitoring-and-troubleshooting-workflows/enabling-debug-logging.md
+++ b/translations/zh-CN/content/actions/monitoring-and-troubleshooting-workflows/enabling-debug-logging.md
@@ -28,7 +28,7 @@ ms.locfileid: '146179381'
 
 {% ifversion debug-reruns %}
 
-此外，有权运行工作流的任何人都可以为工作流重新运行启用运行器诊断日志记录和步骤调试日志记录。 有关详细信息，请参阅“[重新运行工作流和作业](/actions/managing-workflow-runs/re-running-workflows-and-jobs)”。
+此外，有权运行工作流的任何人都可以为工作流重新运行启用运行器诊断日志记录和步骤调试日志记录。有关详细信息，请参阅“[重新运行工作流和作业](/actions/managing-workflow-runs/re-running-workflows-and-jobs)”。
 
  {% endif %}
 
@@ -41,7 +41,7 @@ Runner diagnostic logging provides additional log files that contain information
 
 1. 若要启用运行器诊断日志记录，请在包含工作流的存储库中进行以下设置：将 `ACTIONS_RUNNER_DEBUG` 机密设置为 `true`。
 
-1. 要下载运行程序诊断日志，请下载工作流程运行情况的日志存档。 运行程序诊断日志包含在 `runner-diagnostic-logs` 文件夹中。 关于下载日志的详细信息，请参阅“[下载日志](/actions/managing-workflow-runs/using-workflow-run-logs/#downloading-logs)”。
+1. 要下载运行程序诊断日志，请下载工作流程运行情况的日志存档。运行程序诊断日志包含在 `runner-diagnostic-logs` 文件夹中。关于下载日志的详细信息，请参阅“[下载日志](/actions/managing-workflow-runs/using-workflow-run-logs/#downloading-logs)”。
 
 ## 启用步骤调试日志
 
@@ -49,4 +49,4 @@ Runner diagnostic logging provides additional log files that contain information
 
 1. 要启用步骤调试日志记录，必须在包含工作流的存储库中进行以下设置：将机密 `ACTIONS_STEP_DEBUG` 设置为 `true`。
 
-1. 设置密码后，步骤日志中会显示更多调试事件。 有关详细信息，请参阅[“查看日志以诊断故障”](/actions/managing-workflow-runs/using-workflow-run-logs/#viewing-logs-to-diagnose-failures)。
+1. 设置密码后，步骤日志中会显示更多调试事件。有关详细信息，请参阅[“查看日志以诊断故障”](/actions/managing-workflow-runs/using-workflow-run-logs/#viewing-logs-to-diagnose-failures)。
diff --git a/translations/zh-CN/content/actions/monitoring-and-troubleshooting-workflows/using-the-visualization-graph.md b/translations/zh-CN/content/actions/monitoring-and-troubleshooting-workflows/using-the-visualization-graph.md
index 42a690a759aa..fba75048c26b 100644
--- a/translations/zh-CN/content/actions/monitoring-and-troubleshooting-workflows/using-the-visualization-graph.md
+++ b/translations/zh-CN/content/actions/monitoring-and-troubleshooting-workflows/using-the-visualization-graph.md
@@ -1,6 +1,6 @@
 ---
 title: 使用可视化图表
-intro: 每个工作流程运行都会生成一个实时图表，说明运行进度。 您可以使用此图表来监控和调试工作流程。
+intro: 每个工作流程运行都会生成一个实时图表，说明运行进度。您可以使用此图表来监控和调试工作流程。
 redirect_from:
   - /actions/managing-workflow-runs/using-the-visualization-graph
 versions:
@@ -20,7 +20,7 @@ ms.locfileid: '145100199'
 
 {% data reusables.repositories.navigate-to-repo %} {% data reusables.repositories.actions-tab %} {% data reusables.repositories.navigate-to-workflow %} {% data reusables.repositories.view-run %}
 
-1. 图表显示每个工作流程中的作业。 作业名称左侧的图标指示作业的状态。 作业之间的线表示依赖项。
+1. 图表显示每个工作流程中的作业。作业名称左侧的图标指示作业的状态。作业之间的线表示依赖项。
    ![工作流图表](/assets/images/help/images/workflow-graph.png)
 
 2. 单击作业可查看作业日志。
diff --git a/translations/zh-CN/content/actions/monitoring-and-troubleshooting-workflows/using-workflow-run-logs.md b/translations/zh-CN/content/actions/monitoring-and-troubleshooting-workflows/using-workflow-run-logs.md
index 72c2ddc468d6..9dce4337775f 100644
--- a/translations/zh-CN/content/actions/monitoring-and-troubleshooting-workflows/using-workflow-run-logs.md
+++ b/translations/zh-CN/content/actions/monitoring-and-troubleshooting-workflows/using-workflow-run-logs.md
@@ -17,19 +17,19 @@ ms.locfileid: '147521520'
 ---
 {% data reusables.actions.enterprise-beta %} {% data reusables.actions.enterprise-github-hosted-runners %}
 
-您可以从工作流程运行页面查看工作流程运行是在进行中，还是已完成。 您必须登录到 {% data variables.product.prodname_dotcom %} 帐户才能查看工作流程运行信息，包括公共仓库。 有关详细信息，请参阅“[对 GitHub 的访问权限](/articles/access-permissions-on-github)”。
+您可以从工作流程运行页面查看工作流程运行是在进行中，还是已完成。您必须登录到 {% data variables.product.prodname_dotcom %} 帐户才能查看工作流程运行信息，包括公共仓库。有关详细信息，请参阅“[对 GitHub 的访问权限](/articles/access-permissions-on-github)”。
 
-如果运行已完成，则可查看运行结果是成功、失败、已取消还是中性。 如果运行失败，您可以查看并搜索构建日志，来诊断失败原因并重新运行工作流程。 您也可以查看可计费作业执行分钟数，或下载日志和创建构件。
+如果运行已完成，则可查看运行结果是成功、失败、已取消还是中性。如果运行失败，您可以查看并搜索构建日志，来诊断失败原因并重新运行工作流程。您也可以查看可计费作业执行分钟数，或下载日志和创建构件。
 
-{% data variables.product.prodname_actions %} 使用 Checks API 来输出工作流程的状态、结果和日志。 {% data variables.product.prodname_dotcom %} 对每个工作流程创建新检查套件。 检查套件包含检查工作流程中每项作业的运行，而每项作业包含步骤。 {% data variables.product.prodname_actions %} 作为工作流程中的一个步骤运行。 有关检查 API 的详细信息，请参阅“[检查](/rest/reference/checks)”。
+{% data variables.product.prodname_actions %} 使用 Checks API 来输出工作流程的状态、结果和日志。 {% data variables.product.prodname_dotcom %} 对每个工作流程创建新检查套件。检查套件包含检查工作流程中每项作业的运行，而每项作业包含步骤。 {% data variables.product.prodname_actions %} 作为工作流程中的一个步骤运行。有关检查 API 的详细信息，请参阅“[检查](/rest/reference/checks)”。
 
 {% data reusables.actions.invalid-workflow-files %}
 
 ## 查看日志以诊断故障
 
-如果工作流程运行失败，您可以查看是哪个步骤导致了失败，然后审查失败步骤的创建日志进行故障排除。 您可以查看每个步骤运行的时长。 也可以将永久链接复制到日志文件中的特定行，与您的团队分享。 {% data reusables.repositories.permissions-statement-read %}
+如果工作流程运行失败，您可以查看是哪个步骤导致了失败，然后审查失败步骤的创建日志进行故障排除。您可以查看每个步骤运行的时长。也可以将永久链接复制到日志文件中的特定行，与您的团队分享。 {% data reusables.repositories.permissions-statement-read %}
 
-除了工作流程文件中配置的步骤外，{% data variables.product.prodname_dotcom %} 为每个作业添加了另外两个步骤，以设置和完成作业的执行。 这些步骤以名称"设置作业"和"完成作业"记录在工作流程运行中。
+除了工作流程文件中配置的步骤外，{% data variables.product.prodname_dotcom %} 为每个作业添加了另外两个步骤，以设置和完成作业的执行。这些步骤以名称"设置作业"和"完成作业"记录在工作流程运行中。
 
 对于在 {% data variables.product.prodname_dotcom %} 托管的运行器上运行的作业，“设置作业”会记录运行器映像的详细信息，它还包含一个链接，指向运行器机器上的预安装工具列表。
 
@@ -37,7 +37,7 @@ ms.locfileid: '147521520'
 
 ## 搜索日志
 
-您可以搜索特定步骤的创建日志。 在搜索日志时，只有展开的步骤会包含在结果中。 {% data reusables.repositories.permissions-statement-read %}
+您可以搜索特定步骤的创建日志。在搜索日志时，只有展开的步骤会包含在结果中。 {% data reusables.repositories.permissions-statement-read %}
 
 {% data reusables.repositories.navigate-to-repo %} {% data reusables.repositories.actions-tab %} {% data reusables.repositories.navigate-to-workflow %} {% data reusables.repositories.view-run %} {% data reusables.repositories.navigate-to-job %}
 1. 在日志输出右上角的“搜索日志”搜索框中，输入搜索查询。
@@ -45,7 +45,7 @@ ms.locfileid: '147521520'
 
 ## 下载日志
 
-您可以从工作流程运行中下载日志文件。 您也可以下载工作流程的构件。 有关详细信息，请参阅“[使用工件持久保存工作流数据](/actions/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)”。 {% data reusables.repositories.permissions-statement-read %}
+您可以从工作流程运行中下载日志文件。您也可以下载工作流程的构件。有关详细信息，请参阅“[使用工件持久保存工作流数据](/actions/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)”。 {% data reusables.repositories.permissions-statement-read %}
 
 {% data reusables.repositories.navigate-to-repo %} {% data reusables.repositories.actions-tab %} {% data reusables.repositories.navigate-to-workflow %} {% data reusables.repositories.view-run %} {% data reusables.repositories.navigate-to-job %}
 1. 在右上角，单击 {% octicon "gear" aria-label="The gear icon" %}，然后选择“下载日志存档”。
@@ -57,7 +57,7 @@ ms.locfileid: '147521520'
 
   {% note %}
 
-  **注意**：下载部分重新运行的工作流的日志存档时，存档仅包括已重新运行的作业。 若要获取从工作流程运行的作业的完整日志集，必须下载运行其他作业的上一次运行尝试的日志存档。
+  **注意**：下载部分重新运行的工作流的日志存档时，存档仅包括已重新运行的作业。若要获取从工作流程运行的作业的完整日志集，必须下载运行其他作业的上一次运行尝试的日志存档。
 
   {% endnote %}
 
@@ -82,19 +82,19 @@ ms.locfileid: '147521520'
 
 {% data reusables.cli.cli-learn-more %}
 
-若要查看特定作业的日志，请使用 `run view` 子命令。 将 `run-id` 替换为想要查看其日志的运行的 ID。 {% data variables.product.prodname_cli %} 将返回一个交互式菜单，供您从运行中选择作业。 如果没有指定 `run-id`，{% data variables.product.prodname_cli %} 将返回一个交互式菜单来供你选择最近的运行，然后返回另一个交互式菜单，让你从运行中选择作业。
+若要查看特定作业的日志，请使用 `run view` 子命令。将 `run-id` 替换为想要查看其日志的运行的 ID。 {% data variables.product.prodname_cli %} 将返回一个交互式菜单，供您从运行中选择作业。如果没有指定 `run-id`，{% data variables.product.prodname_cli %} 将返回一个交互式菜单来供你选择最近的运行，然后返回另一个交互式菜单，让你从运行中选择作业。
 
 ```shell
 gh run view <em>run-id</em> --log
 ```
 
-还可以使用 `--job` 标记来指定作业 ID。 将 `job-id` 替换为想要查看其日志的作业的 ID。
+还可以使用 `--job` 标记来指定作业 ID。将 `job-id` 替换为想要查看其日志的作业的 ID。
 
 ```shell
 gh run view --job <em>job-id</em> --log
 ```
 
-可使用 `grep` 搜索日志。 例如，此命令将返回包含 `error` 一词的所有日志条目。
+可使用 `grep` 搜索日志。例如，此命令将返回包含 `error` 一词的所有日志条目。
 
 ```shell
 gh run view --job <em>job-id</em> --log | grep error
diff --git a/translations/zh-CN/content/actions/monitoring-and-troubleshooting-workflows/viewing-job-execution-time.md b/translations/zh-CN/content/actions/monitoring-and-troubleshooting-workflows/viewing-job-execution-time.md
index 2b8277132770..3c25296ded87 100644
--- a/translations/zh-CN/content/actions/monitoring-and-troubleshooting-workflows/viewing-job-execution-time.md
+++ b/translations/zh-CN/content/actions/monitoring-and-troubleshooting-workflows/viewing-job-execution-time.md
@@ -16,14 +16,14 @@ ms.locfileid: '145100197'
 ---
 {% data reusables.actions.enterprise-beta %} {% data reusables.actions.enterprise-github-hosted-runners %}
 
-计费作业执行分钟数仅显示在使用 {% data variables.product.prodname_dotcom %} 托管运行器的私有存储库上运行的作业，并四舍五入到下一分钟。 如果在公共仓库中使用 {% data variables.product.prodname_actions %}，或在自托管的运行器中运行作业时，将没有可计费分钟数。
+计费作业执行分钟数仅显示在使用 {% data variables.product.prodname_dotcom %} 托管运行器的私有存储库上运行的作业，并四舍五入到下一分钟。如果在公共仓库中使用 {% data variables.product.prodname_actions %}，或在自托管的运行器中运行作业时，将没有可计费分钟数。
 
 {% data reusables.repositories.navigate-to-repo %} {% data reusables.repositories.actions-tab %} {% data reusables.repositories.navigate-to-workflow %} {% data reusables.repositories.view-run %}
-1. 在作业摘要下，您可以查看作业的执行时间。 若要查看有关计费作业执行时间的详细信息，请单击“计费时间”下的时间。
+1. 在作业摘要下，您可以查看作业的执行时间。若要查看有关计费作业执行时间的详细信息，请单击“计费时间”下的时间。
    ![运行和计费时间详细信息链接](/assets/images/help/repository/view-run-billable-time.png)
 
    {% note %}
    
-   注意：显示的计费时间不包括任何分钟乘数。 若要查看 {% data variables.product.prodname_actions %} 总的使用情况，包括分钟乘数，请参阅“[查看你的 {% data variables.product.prodname_actions %} 使用情况](/billing/managing-billing-for-github-actions/viewing-your-github-actions-usage)”。
+   注意：显示的计费时间不包括任何分钟乘数。若要查看 {% data variables.product.prodname_actions %} 总的使用情况，包括分钟乘数，请参阅“[查看你的 {% data variables.product.prodname_actions %} 使用情况](/billing/managing-billing-for-github-actions/viewing-your-github-actions-usage)”。
    
    {% endnote %}
diff --git a/translations/zh-CN/content/actions/monitoring-and-troubleshooting-workflows/viewing-workflow-run-history.md b/translations/zh-CN/content/actions/monitoring-and-troubleshooting-workflows/viewing-workflow-run-history.md
index b96ff4b349e7..30d9b791eebc 100644
--- a/translations/zh-CN/content/actions/monitoring-and-troubleshooting-workflows/viewing-workflow-run-history.md
+++ b/translations/zh-CN/content/actions/monitoring-and-troubleshooting-workflows/viewing-workflow-run-history.md
@@ -1,6 +1,6 @@
 ---
 title: 查看工作流程运行历史记录
-intro: 您可以查看工作流程每次运行的日志。 日志包括工作流程中每个作业和步骤的状态。
+intro: 您可以查看工作流程每次运行的日志。日志包括工作流程中每个作业和步骤的状态。
 redirect_from:
   - /actions/managing-workflow-runs/viewing-workflow-run-history
 versions:
@@ -38,13 +38,13 @@ ms.locfileid: '145100196'
 gh run list
 ```
 
-要指定返回的最大运行次数，可使用 `-L` 或 `--limit` 标记。 默认为 `10`。
+要指定返回的最大运行次数，可使用 `-L` 或 `--limit` 标记。默认为 `10`。
 
 ```shell
 gh run list --limit 5
 ```
 
-要仅返回指定工作流的运行，可使用 `-w` 或 `--workflow` 标记。  将 `workflow` 替换为工作流名称、工作流 ID 或工作流文件名。 例如，`"Link Checker"`、`1234567` 或 `"link-check-test.yml"`。
+要仅返回指定工作流的运行，可使用 `-w` 或 `--workflow` 标记。将 `workflow` 替换为工作流名称、工作流 ID 或工作流文件名。例如，`"Link Checker"`、`1234567` 或 `"link-check-test.yml"`。
 
 ```shell
 gh run list --workflow <em>workflow</em>
@@ -52,7 +52,7 @@ gh run list --workflow <em>workflow</em>
 
 ### 查看特定工作流程运行的详细信息
 
-要显示特定工作流运行的详细信息，请使用 `run view` 子命令。 将 `run-id` 替换为要查看的运行的 ID。 如果没有指定 `run-id`，{% data variables.product.prodname_cli %} 将返回交互式菜单供你选择最近的运行。
+要显示特定工作流运行的详细信息，请使用 `run view` 子命令。将 `run-id` 替换为要查看的运行的 ID。如果没有指定 `run-id`，{% data variables.product.prodname_cli %} 将返回交互式菜单供你选择最近的运行。
 
 ```shell
 gh run view <em>run-id</em>
@@ -64,7 +64,7 @@ gh run view <em>run-id</em>
 gh run view <em>run-id</em> --verbose
 ```
 
-要查看运行中特定作业的详细信息，请使用 `-j` 或 `--job` 标记。  将 `job-id` 替换为要查看的作业的 ID。
+要查看运行中特定作业的详细信息，请使用 `-j` 或 `--job` 标记。将 `job-id` 替换为要查看的作业的 ID。
 
 ```shell
 gh run view --job <em>job-id</em>
@@ -76,7 +76,7 @@ gh run view --job <em>job-id</em>
 gh run view --job <em>job-id</em> --log
 ```
 
-如果运行失败，请使用 `--exit-status` 标记以非零状态退出。 例如：
+如果运行失败，请使用 `--exit-status` 标记以非零状态退出。例如：
 
 ```shell
 gh run view 0451 --exit-status && echo "run pending or passed"
diff --git a/translations/zh-CN/content/actions/publishing-packages/publishing-java-packages-with-gradle.md b/translations/zh-CN/content/actions/publishing-packages/publishing-java-packages-with-gradle.md
index 3387378a403b..ee8ed6807a77 100644
--- a/translations/zh-CN/content/actions/publishing-packages/publishing-java-packages-with-gradle.md
+++ b/translations/zh-CN/content/actions/publishing-packages/publishing-java-packages-with-gradle.md
@@ -31,7 +31,7 @@ ms.locfileid: '147410281'
 
 ## 先决条件
 
-建议对工作流程文件和配置选项有一个基本了解。 有关详细信息，请参阅“[了解 {% data variables.product.prodname_actions %}](/actions/learn-github-actions)”。
+建议对工作流程文件和配置选项有一个基本了解。有关详细信息，请参阅“[了解 {% data variables.product.prodname_actions %}](/actions/learn-github-actions)”。
 
 有关使用 Gradle 为 Java 项目创建 CI 工作流的更多信息，请参阅“[使用 Gradle 构建和测试 Java](/actions/language-and-framework-guides/building-and-testing-java-with-gradle)”。
 
@@ -44,15 +44,15 @@ ms.locfileid: '147410281'
 
 ## 关于包配置
 
-build.gradle 文件 `MavenPublication` 部分中的 `groupId` 和 `artifactId` 字段为包创建唯一标识符，注册表使用该标识符将包链接到注册表。  这类似于 Maven pom.xml 文件的 `groupId` 和 `artifactId` 字段。  有关详细信息，请参阅 Gradle 文档中的“[Maven 发布插件](https://docs.gradle.org/current/userguide/publishing_maven.html)”。
+build.gradle 文件 `MavenPublication` 部分中的 `groupId` 和 `artifactId` 字段为包创建唯一标识符，注册表使用该标识符将包链接到注册表。这类似于 Maven pom.xml 文件的 `groupId` 和 `artifactId` 字段。有关详细信息，请参阅 Gradle 文档中的“[Maven 发布插件](https://docs.gradle.org/current/userguide/publishing_maven.html)”。
 
-build.gradle 文件还包含 Gradle 将向其发布包的分发管理存储库的配置。 每个仓库必须有名称、部署 URL 和验证凭据。
+build.gradle 文件还包含 Gradle 将向其发布包的分发管理存储库的配置。每个仓库必须有名称、部署 URL 和验证凭据。
 
 ## 将包发布到 Maven 中心仓库
 
-每次创建新版本时，都可以触发工作流程来发布包。 以下示例中的工作流在类型为 `created` 的 `release` 事件触发时运行。 如果 CI 测试通过，工作流程将包发布到 Maven 中心仓库。 有关 `release` 事件的详细信息，请参阅“[触发工作流的事件](/actions/reference/events-that-trigger-workflows#release)”。
+每次创建新版本时，都可以触发工作流程来发布包。以下示例中的工作流在类型为 `created` 的 `release` 事件触发时运行。如果 CI 测试通过，工作流程将包发布到 Maven 中心仓库。有关 `release` 事件的详细信息，请参阅“[触发工作流的事件](/actions/reference/events-that-trigger-workflows#release)”。
 
-你可以在指向包存储库的 build.gradle 文件的发布块中定义一个新的 Maven 存储库。  例如，如果通过 OSSRH 托管项目部署到 Maven 中央存储库，则 build.gradle 可以指定名称为 `"OSSRH"` 的存储库。
+你可以在指向包存储库的 build.gradle 文件的发布块中定义一个新的 Maven 存储库。例如，如果通过 OSSRH 托管项目部署到 Maven 中央存储库，则 build.gradle 可以指定名称为 `"OSSRH"` 的存储库。
 
 {% raw %}
 ```groovy{:copy}
@@ -78,7 +78,7 @@ publishing {
 ```
 {% endraw %}
 
-使用此配置，可以创建一个工作流，通过运行 `gradle publish` 命令将包发布到 Maven 中央存储库。 在部署步骤中，您需要为用于向 Maven 仓库验证身份的用户名和密码或令牌设置环境变量。 有关详细信息，请参阅“[创建和使用加密机密](/github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)”。
+使用此配置，可以创建一个工作流，通过运行 `gradle publish` 命令将包发布到 Maven 中央存储库。在部署步骤中，您需要为用于向 Maven 仓库验证身份的用户名和密码或令牌设置环境变量。有关详细信息，请参阅“[创建和使用加密机密](/github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)”。
 
 ```yaml{:copy}
 
@@ -118,9 +118,9 @@ jobs:
 
 ## 发布包到 {% data variables.product.prodname_registry %}
 
-每次创建新版本时，都可以触发工作流程来发布包。 以下示例中的工作流在类型为 `created` 的 `release` 事件触发时运行。 如果 CI 测试通过，工作流程会将包发布到 {% data variables.product.prodname_registry %}。 有关 `release` 事件的详细信息，请参阅“[触发工作流的事件](/actions/reference/events-that-trigger-workflows#release)”。
+每次创建新版本时，都可以触发工作流程来发布包。以下示例中的工作流在类型为 `created` 的 `release` 事件触发时运行。如果 CI 测试通过，工作流程会将包发布到 {% data variables.product.prodname_registry %}。有关 `release` 事件的详细信息，请参阅“[触发工作流的事件](/actions/reference/events-that-trigger-workflows#release)”。
 
-可以在指向 {% data variables.product.prodname_registry %} 的 build.gradle 的发布块中定义一个新的 Maven 存储库。  在仓库配置中，您也可以利用在 CI 工作流程运行中设置的环境变量。  可以使用 `GITHUB_ACTOR` 环境变量作为用户名，并且可以使用 `GITHUB_TOKEN` 机密设置 `GITHUB_TOKEN` 环境变量。
+可以在指向 {% data variables.product.prodname_registry %} 的 build.gradle 的发布块中定义一个新的 Maven 存储库。在仓库配置中，您也可以利用在 CI 工作流程运行中设置的环境变量。可以使用 `GITHUB_ACTOR` 环境变量作为用户名，并且可以使用 `GITHUB_TOKEN` 机密设置 `GITHUB_TOKEN` 环境变量。
 
 {% data reusables.actions.github-token-permissions %}
 
@@ -195,7 +195,7 @@ jobs:
 
 确保 build.gradle 文件包含 {% data variables.product.prodname_dotcom %} 存储库和 Maven 中央存储库提供程序的存储库。
 
-例如，如果通过 OSSRH 托管项目部署到中央存储库，可能希望在分发管理存储库中指定它，并将 `name` 设置为 `OSSRH`。 如果部署到 {% data variables.product.prodname_registry %}，可能希望在分发管理存储库中指定它，并将 `name` 设置为 `GitHubPackages`。
+例如，如果通过 OSSRH 托管项目部署到中央存储库，可能希望在分发管理存储库中指定它，并将 `name` 设置为 `OSSRH`。如果部署到 {% data variables.product.prodname_registry %}，可能希望在分发管理存储库中指定它，并将 `name` 设置为 `GitHubPackages`。
 
 如果组织名为“octocat”，存储库名为“hello-world”，则 build.gradle 中的配置类似于以下示例。
 
diff --git a/translations/zh-CN/content/actions/publishing-packages/publishing-java-packages-with-maven.md b/translations/zh-CN/content/actions/publishing-packages/publishing-java-packages-with-maven.md
index 85ab81032053..ea48e4a5d029 100644
--- a/translations/zh-CN/content/actions/publishing-packages/publishing-java-packages-with-maven.md
+++ b/translations/zh-CN/content/actions/publishing-packages/publishing-java-packages-with-maven.md
@@ -31,7 +31,7 @@ ms.locfileid: '147717915'
 
 ## 先决条件
 
-建议对工作流程文件和配置选项有一个基本了解。 有关详细信息，请参阅“[了解 {% data variables.product.prodname_actions %}](/actions/learn-github-actions)”。
+建议对工作流程文件和配置选项有一个基本了解。有关详细信息，请参阅“[了解 {% data variables.product.prodname_actions %}](/actions/learn-github-actions)”。
 
 有关使用 Maven 为 Java 项目创建 CI 工作流的详细信息，请参阅“[使用 Maven 构建和测试用 Java](/actions/language-and-framework-guides/building-and-testing-java-with-maven)”。
 
@@ -44,17 +44,17 @@ ms.locfileid: '147717915'
 
 ## 关于包配置
 
-pom.xml 文件中的 `groupId` 和 `artifactId` 字段为包创建唯一标识符，注册表使用该标识符将包链接到注册表。  有关详细信息，请参阅 Apache Maven 文档中的[将项目上传到中央存储库的指南](http://maven.apache.org/repository/guide-central-repository-upload.html)。
+pom.xml 文件中的 `groupId` 和 `artifactId` 字段为包创建唯一标识符，注册表使用该标识符将包链接到注册表。有关详细信息，请参阅 Apache Maven 文档中的[将项目上传到中央存储库的指南](http://maven.apache.org/repository/guide-central-repository-upload.html)。
 
-pom.xml 文件还包含 Maven 将在其中部署包的分发管理存储库的配置。 每个仓库都必须有名称和部署 URL。 可在运行 Maven 的用户主目录中的 .m2/settings.xml 文件中配置这些存储库的身份验证。
+pom.xml 文件还包含 Maven 将在其中部署包的分发管理存储库的配置。每个仓库都必须有名称和部署 URL。可在运行 Maven 的用户主目录中的 .m2/settings.xml 文件中配置这些存储库的身份验证。
 
-可以使用 `setup-java` 操作配置部署存储库以及该存储库的身份验证。 有关详细信息，请参阅 [`setup-java`](https://github.com/actions/setup-java)。
+可以使用 `setup-java` 操作配置部署存储库以及该存储库的身份验证。有关详细信息，请参阅 [`setup-java`](https://github.com/actions/setup-java)。
 
 ## 将包发布到 Maven 中心仓库
 
-每次创建新版本时，都可以触发工作流程来发布包。 以下示例中的工作流在类型为 `created` 的 `release` 事件触发时运行。 如果 CI 测试通过，工作流程将包发布到 Maven 中心仓库。 有关 `release` 事件的详细信息，请参阅“[触发工作流的事件](/actions/reference/events-that-trigger-workflows#release)”。
+每次创建新版本时，都可以触发工作流程来发布包。以下示例中的工作流在类型为 `created` 的 `release` 事件触发时运行。如果 CI 测试通过，工作流程将包发布到 Maven 中心仓库。有关 `release` 事件的详细信息，请参阅“[触发工作流的事件](/actions/reference/events-that-trigger-workflows#release)”。
 
-在此工作流中，可以使用 `setup-java` 操作。 此操作将给定版本的 JDK 安装到 `PATH` 中，但同时会配置 Maven settings.xml 以发布包。 默认情况下，设置文件将配置用于 {% data variables.product.prodname_registry %}，但可以将其配置为部署到另一个包注册表，如 Maven 中心仓库。 如果已在 pom.xml 中配置了分发管理存储库，则可在 `setup-java` 操作调用期间指定该 `id`。
+在此工作流中，可以使用 `setup-java` 操作。此操作将给定版本的 JDK 安装到 `PATH` 中，但同时会配置 Maven settings.xml 以发布包。默认情况下，设置文件将配置用于 {% data variables.product.prodname_registry %}，但可以将其配置为部署到另一个包注册表，如 Maven 中心仓库。如果已在 pom.xml 中配置了分发管理存储库，则可在 `setup-java` 操作调用期间指定该 `id`。
 
 例如，如果通过 OSSRH 托管项目部署到 Maven 中央存储库，则 pom.xml 可以指定 `id` 为 `ossrh` 的分发管理存储库。
 
@@ -73,9 +73,9 @@ pom.xml 文件还包含 Maven 将在其中部署包的分发管理存储库的
 ```
 {% endraw %}
 
-使用此配置，可通过将存储库管理 `id` 指定到 `setup-java` 操作，创建一个将包发布到 Maven 中央存储库的工作流。 您还需要提供包含用户名和密码的环境变量向仓库验证。
+使用此配置，可通过将存储库管理 `id` 指定到 `setup-java` 操作，创建一个将包发布到 Maven 中央存储库的工作流。您还需要提供包含用户名和密码的环境变量向仓库验证。
 
-在部署步骤中，您需要将环境变量设置为向仓库验证的用户名，以及用密码或令牌配置为进行身份验证的密钥。  有关详细信息，请参阅“[创建和使用加密机密](/github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)”。
+在部署步骤中，您需要将环境变量设置为向仓库验证的用户名，以及用密码或令牌配置为进行身份验证的密钥。有关详细信息，请参阅“[创建和使用加密机密](/github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)”。
 
 ```yaml{:copy}
 name: Publish package to the Maven Central Repository
@@ -112,9 +112,9 @@ jobs:
 
 ## 发布包到 {% data variables.product.prodname_registry %}
 
-每次创建新版本时，都可以触发工作流程来发布包。 以下示例中的工作流在类型为 `created` 的 `release` 事件触发时运行。 如果 CI 测试通过，工作流程会将包发布到 {% data variables.product.prodname_registry %}。 有关 `release` 事件的详细信息，请参阅“[触发工作流的事件](/actions/reference/events-that-trigger-workflows#release)”。
+每次创建新版本时，都可以触发工作流程来发布包。以下示例中的工作流在类型为 `created` 的 `release` 事件触发时运行。如果 CI 测试通过，工作流程会将包发布到 {% data variables.product.prodname_registry %}。有关 `release` 事件的详细信息，请参阅“[触发工作流的事件](/actions/reference/events-that-trigger-workflows#release)”。
 
-在此工作流中，可以使用 `setup-java` 操作。 此操作将给定版本的 JDK 安装到 `PATH` 中，并设置 Maven settings.xml 以将包发布到 {% data variables.product.prodname_registry %}。 生成的 settings.xml 为服务器定义身份验证，该服务器的 `id` 为 `github`，使用 `GITHUB_ACTOR` 环境变量作为用户名，使用 `GITHUB_TOKEN` 环境变量作为密码。 `GITHUB_TOKEN` 环境变量被分配了特殊 `GITHUB_TOKEN` 机密的值。
+在此工作流中，可以使用 `setup-java` 操作。此操作将给定版本的 JDK 安装到 `PATH` 中，并设置 Maven settings.xml 以将包发布到 {% data variables.product.prodname_registry %}。生成的 settings.xml 为服务器定义身份验证，该服务器的 `id` 为 `github`，使用 `GITHUB_ACTOR` 环境变量作为用户名，使用 `GITHUB_TOKEN` 环境变量作为密码。 `GITHUB_TOKEN` 环境变量被分配了特殊 `GITHUB_TOKEN` 机密的值。
 
 {% data reusables.actions.github-token-permissions %}
 
@@ -174,7 +174,7 @@ jobs:
 
 可以通过对每个注册表使用 `setup-java` 操作将包发布到 Maven 中央存储库和 {% data variables.product.prodname_registry %}。
 
-确保 pom.xml 文件包含用于 {% data variables.product.prodname_dotcom %} 存储库和 Maven 中央存储库提供程序的分发管理存储库。 例如，如果通过 OSSRH 托管项目部署到中央存储库，你可以通过将 `id` 设置为 `ossrh` 在分发管理存储库中指定该 OSSRH 托管项目，并且可以通过将 `id` 设置为 `github` 在分发管理存储库中指定 {% data variables.product.prodname_registry %}。
+确保 pom.xml 文件包含用于 {% data variables.product.prodname_dotcom %} 存储库和 Maven 中央存储库提供程序的分发管理存储库。例如，如果通过 OSSRH 托管项目部署到中央存储库，你可以通过将 `id` 设置为 `ossrh` 在分发管理存储库中指定该 OSSRH 托管项目，并且可以通过将 `id` 设置为 `github` 在分发管理存储库中指定 {% data variables.product.prodname_registry %}。
 
 ```yaml{:copy}
 name: Publish package to the Maven Central Repository and GitHub Packages
@@ -213,14 +213,14 @@ jobs:
           GITHUB_TOKEN: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}
 ```
 
-此工作流调用 `setup-java` 操作两次。  每次 `setup-java` 操作运行时，都会覆盖 Maven settings.xml 文件以发布包。  为向存储库进行身份验证，settings.xml 文件引用分发管理存储库 `id` 以及用户名和密码。
+此工作流调用 `setup-java` 操作两次。每次 `setup-java` 操作运行时，都会覆盖 Maven settings.xml 文件以发布包。为向存储库进行身份验证，settings.xml 文件引用分发管理存储库 `id` 以及用户名和密码。
 
 此工作流程执行以下步骤：
 
 1. 检出项目仓库的副本。
-1. 第一次调用 `setup-java`。 这将为 `ossrh` 存储库配置 Maven settings.xml 文件，并将身份验证选项设置为在下一步中定义的环境变量。
+1. 第一次调用 `setup-java`。这将为 `ossrh` 存储库配置 Maven settings.xml 文件，并将身份验证选项设置为在下一步中定义的环境变量。
 1. {% data reusables.actions.publish-to-maven-workflow-step %}
-1. 第二次调用 `setup-java`。 这将自动为 {% data variables.product.prodname_registry %} 配置 Maven settings.xml 文件。
+1. 第二次调用 `setup-java`。这将自动为 {% data variables.product.prodname_registry %} 配置 Maven settings.xml 文件。
 1. {% data reusables.actions.publish-to-packages-workflow-step %}
 
    有关在工作流中使用机密的详细信息，请参阅“[创建和使用加密机密](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)”。
diff --git a/translations/zh-CN/content/actions/using-containerized-services/about-service-containers.md b/translations/zh-CN/content/actions/using-containerized-services/about-service-containers.md
index 4915add09ead..4c9961081e1a 100644
--- a/translations/zh-CN/content/actions/using-containerized-services/about-service-containers.md
+++ b/translations/zh-CN/content/actions/using-containerized-services/about-service-containers.md
@@ -25,35 +25,35 @@ ms.locfileid: '145100173'
 
 ## 关于服务容器
 
-服务容器是 Docker 容器，以简便、可携带的方式托管您可能需要在工作流程中测试或操作应用程序的服务。 例如，您的工作流程可能必须运行需要访问数据库和内存缓存的集成测试。
+服务容器是 Docker 容器，以简便、可携带的方式托管您可能需要在工作流程中测试或操作应用程序的服务。例如，您的工作流程可能必须运行需要访问数据库和内存缓存的集成测试。
 
-您可以为工作流程中的每个作业配置服务容器。 {% data variables.product.prodname_dotcom %} 为工作流中配置的每个服务创建一个新的 Docker 容器，并在作业完成后销毁该服务容器。 作业中的步骤可与属于同一作业的所有服务容器通信。 但是，你不能在组合操作中创建和使用服务容器。 
+您可以为工作流程中的每个作业配置服务容器。 {% data variables.product.prodname_dotcom %} 为工作流中配置的每个服务创建一个新的 Docker 容器，并在作业完成后销毁该服务容器。作业中的步骤可与属于同一作业的所有服务容器通信。但是，你不能在组合操作中创建和使用服务容器。 
 
 {% data reusables.actions.docker-container-os-support %}
 
 ## 与服务容器通信
 
-您可以在工作流程中配置作业直接在运行器机器或 Docker 容器上运行。 作业与其服务容器之间的通信根据作业是直接在运行器上运行还是在容器中运行而有所不同。
+您可以在工作流程中配置作业直接在运行器机器或 Docker 容器上运行。作业与其服务容器之间的通信根据作业是直接在运行器上运行还是在容器中运行而有所不同。
 
 ### 在容器中运行作业
 
-在容器中运行作业时，{% data variables.product.prodname_dotcom %} 使用 Docker 的用户定义桥接网络将服务容器连接到作业。 有关详细信息，请参阅 Docker 文档中的“[使用网桥网络](https://docs.docker.com/network/bridge/)”。
+在容器中运行作业时，{% data variables.product.prodname_dotcom %} 使用 Docker 的用户定义桥接网络将服务容器连接到作业。有关详细信息，请参阅 Docker 文档中的“[使用网桥网络](https://docs.docker.com/network/bridge/)”。
 
-在容器中运行作业和服务可简化网络访问。 您可以使用工作流程中配置的标签访问服务容器。 服务容器的主机名自动映射到标签名称。 例如，如果创建带有标签 `redis` 的服务容器，则该服务容器的主机名为 `redis`。
+在容器中运行作业和服务可简化网络访问。您可以使用工作流程中配置的标签访问服务容器。服务容器的主机名自动映射到标签名称。例如，如果创建带有标签 `redis` 的服务容器，则该服务容器的主机名为 `redis`。
 
-您无需为服务容器配置任何端口。 默认情况下，属于同一 Docker 网络的所有容器会相互显示所有端口，但在 Docker 网络外部不会显示任何端口。
+您无需为服务容器配置任何端口。默认情况下，属于同一 Docker 网络的所有容器会相互显示所有端口，但在 Docker 网络外部不会显示任何端口。
 
 ### 在运行器机器上运行作业
 
 直接在运行程序计算机上运行作业时，你可以使用 `localhost:<port>` 或 `127.0.0.1:<port>` 访问服务容器。 {% data variables.product.prodname_dotcom %} 配置容器网络以启用从服务容器到 Docker 主机的通信。
 
-当作业直接在运行器机器上运行时， Docker 容器中运行的服务默认情况下不会向运行器上的作业显示其端口。 您需要将服务容器上的端口映射到 Docker 主机。 有关详细信息，请参阅“[映射 Docker 主机和服务容器端口](/actions/automating-your-workflow-with-github-actions/about-service-containers#mapping-docker-host-and-service-container-ports)”。
+当作业直接在运行器机器上运行时，Docker 容器中运行的服务默认情况下不会向运行器上的作业显示其端口。您需要将服务容器上的端口映射到 Docker 主机。有关详细信息，请参阅“[映射 Docker 主机和服务容器端口](/actions/automating-your-workflow-with-github-actions/about-service-containers#mapping-docker-host-and-service-container-ports)”。
 
 ## 创建服务容器
 
-可以使用 `services` 关键字创建作为工作流作业的一部分的服务容器。 有关详细信息，请参阅 [`jobs.<job_id>.services`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idservices)。
+可以使用 `services` 关键字创建作为工作流作业的一部分的服务容器。有关详细信息，请参阅 [`jobs.<job_id>.services`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idservices)。
 
-此示例在名为 `container-job` 的作业中创建名为 `redis` 的服务。 此示例中的 Docker 主机是 `node:16-bullseye` 容器。
+此示例在名为 `container-job` 的作业中创建名为 `redis` 的服务。此示例中的 Docker 主机是 `node:16-bullseye` 容器。
 
 {% raw %}
 ```yaml{:copy}
@@ -79,9 +79,9 @@ jobs:
 
 ## 映射 Docker 主机和服务容器端口
 
-如果作业在 Docker 容器中运行，则不需要映射主机或服务容器上的端口。 如果作业直接在运行器机器上运行，则需要将任何必需的服务容器端口映射到主机运行器机器上的端口。
+如果作业在 Docker 容器中运行，则不需要映射主机或服务容器上的端口。如果作业直接在运行器机器上运行，则需要将任何必需的服务容器端口映射到主机运行器机器上的端口。
 
-可以使用 `ports` 关键字将服务容器端口映射到 Docker 主机。 有关详细信息，请参阅 [`jobs.<job_id>.services`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idservices)。
+可以使用 `ports` 关键字将服务容器端口映射到 Docker 主机。有关详细信息，请参阅 [`jobs.<job_id>.services`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idservices)。
 
 | `ports` 的值 |    说明 |
 |------------------|--------------|
@@ -89,9 +89,9 @@ jobs:
 | `8080:80/udp` |   将容器中的 UDP 端口 80 映射到 Docker 主机上的端口 8080。 |
 | `8080/udp`    | 将容器中随机选择的 UDP 端口映射到 Docker 主机上的 UDP 端口 8080。 |
 
-使用 `ports` 关键字映射端口时，{% data variables.product.prodname_dotcom %} 使用 `--publish` 命令将容器的端口发布到 Docker 主机。 有关详细信息，请参阅 Docker 文档中的“[Docker 容器网络](https://docs.docker.com/config/containers/container-networking/)”。
+使用 `ports` 关键字映射端口时，{% data variables.product.prodname_dotcom %} 使用 `--publish` 命令将容器的端口发布到 Docker 主机。有关详细信息，请参阅 Docker 文档中的“[Docker 容器网络](https://docs.docker.com/config/containers/container-networking/)”。
 
-指定 Docker 主机端口但不指定容器端口时，容器端口将随机分配给空闲端口。 {% data variables.product.prodname_dotcom %} 在服务容器上下文中设置分配的容器端口。 例如，对于 `redis` 服务容器，如果配置了 Docker 主机端口 5432，则可以使用 `job.services.redis.ports[5432]` 上下文访问对应的容器端口。 有关详细信息，请参阅“[上下文](/actions/learn-github-actions/contexts#job-context)”。
+指定 Docker 主机端口但不指定容器端口时，容器端口将随机分配给空闲端口。 {% data variables.product.prodname_dotcom %} 在服务容器上下文中设置分配的容器端口。例如，对于 `redis` 服务容器，如果配置了 Docker 主机端口 5432，则可以使用 `job.services.redis.ports[5432]` 上下文访问对应的容器端口。有关详细信息，请参阅“[上下文](/actions/learn-github-actions/contexts#job-context)”。
 
 ### 映射 Redis 端口的示例
 
diff --git a/translations/zh-CN/content/actions/using-containerized-services/creating-postgresql-service-containers.md b/translations/zh-CN/content/actions/using-containerized-services/creating-postgresql-service-containers.md
index 5c2edb48ca42..ee4e26154716 100644
--- a/translations/zh-CN/content/actions/using-containerized-services/creating-postgresql-service-containers.md
+++ b/translations/zh-CN/content/actions/using-containerized-services/creating-postgresql-service-containers.md
@@ -1,7 +1,7 @@
 ---
 title: 创建 PostgreSQL 服务容器
 shortTitle: PostgreSQL service containers
-intro: 您可以创建 PostgreSQL 服务容器用于您的工作流程。 本指南举例说明如何为容器中运行或直接在运行器机器上运行的作业创建 PostgreSQL 服务。
+intro: 您可以创建 PostgreSQL 服务容器用于您的工作流程。本指南举例说明如何为容器中运行或直接在运行器机器上运行的作业创建 PostgreSQL 服务。
 redirect_from:
   - /actions/automating-your-workflow-with-github-actions/creating-postgresql-service-containers
   - /actions/configuring-and-managing-workflows/creating-postgresql-service-containers
@@ -26,7 +26,7 @@ ms.locfileid: '147886636'
 
 ## 简介
 
-本指南演示了使用 Docker Hub `postgres` 映像配置服务容器的工作流示例。 工作流程运行一个脚本，以连接到 PostgreSQL 服务，创建一个表，然后用数据填充该表。 为了测试工作流程是否创建并填充 PostgreSQL 表，脚本会将表中的数据打印到控制台。
+本指南演示了使用 Docker Hub `postgres` 映像配置服务容器的工作流示例。工作流程运行一个脚本，以连接到 PostgreSQL 服务，创建一个表，然后用数据填充该表。为了测试工作流程是否创建并填充 PostgreSQL 表，脚本会将表中的数据打印到控制台。
 
 {% data reusables.actions.docker-container-os-support %}
 
@@ -34,7 +34,7 @@ ms.locfileid: '147886636'
 
 {% data reusables.actions.service-container-prereqs %}
 
-你可能还会发现它也有助于基本了解 YAML、{% data variables.product.prodname_actions %} 的语法和 PostgreSQL。 有关详细信息，请参阅：
+你可能还会发现它也有助于基本了解 YAML、{% data variables.product.prodname_actions %} 的语法和 PostgreSQL。有关详细信息，请参阅：
 
 - [了解 {% data variables.product.prodname_actions %}](/actions/learn-github-actions)
 - PostgreSQL 文档中的“[PostgreSQL 教程](https://www.postgresqltutorial.com/)”
@@ -157,11 +157,11 @@ steps:
 
 {% data reusables.actions.postgres-environment-variables %}
 
-PostgreSQL 服务的主机名是在工作流中配置的标签，在本例中，主机名为 `postgres`。 由于同一用户定义的网桥网络上的 Docker 容器默认打开所有端口，因此您将能够访问默认 PostgreSQL 端口 5432 上的服务容器。
+PostgreSQL 服务的主机名是在工作流中配置的标签，在本例中，主机名为 `postgres`。由于同一用户定义的网桥网络上的 Docker 容器默认打开所有端口，因此您将能够访问默认 PostgreSQL 端口 5432 上的服务容器。
 
 ## 直接在运行器机器上运行作业
 
-直接在运行器机器上运行作业时，需要将服务容器上的端口映射到 Docker 主机上的端口。 可以使用 `localhost` 和 Docker 主机端口号从 Docker 主机访问服务容器。
+直接在运行器机器上运行作业时，需要将服务容器上的端口映射到 Docker 主机上的端口。可以使用 `localhost` 和 Docker 主机端口号从 Docker 主机访问服务容器。
 
 {% data reusables.actions.copy-workflow-file %}
 
@@ -223,7 +223,7 @@ jobs:
 
 {% data reusables.actions.postgres-label-description %}
 
-工作流程将 PostgreSQL 服务容器上的端口 5432 映射到 Docker 主机。 有关 `ports` 关键字的详细信息，请参阅“[关于服务容器](/actions/automating-your-workflow-with-github-actions/about-service-containers#mapping-docker-host-and-service-container-ports)”。
+工作流程将 PostgreSQL 服务容器上的端口 5432 映射到 Docker 主机。有关 `ports` 关键字的详细信息，请参阅“[关于服务容器](/actions/automating-your-workflow-with-github-actions/about-service-containers#mapping-docker-host-and-service-container-ports)”。
 
 ```yaml{:copy}
 jobs:
@@ -286,9 +286,9 @@ steps:
 
 ## 测试 PostgreSQL 服务容器
 
-您可以使用以下脚本测试工作流程，该脚本将连接到 PostgreSQL 服务，并添加包含某些占位符数据的新表。 然后，脚本将存储在 PostgreSQL 表中的值打印到终端。 你的脚本可以使用任何你喜欢的语言，但此示例使用 Node.js 和 `pg` npm 模块。 有关详细信息，请参阅 [npm pg 模块](https://www.npmjs.com/package/pg)。
+您可以使用以下脚本测试工作流程，该脚本将连接到 PostgreSQL 服务，并添加包含某些占位符数据的新表。然后，脚本将存储在 PostgreSQL 表中的值打印到终端。你的脚本可以使用任何你喜欢的语言，但此示例使用 Node.js 和 `pg` npm 模块。有关详细信息，请参阅 [npm pg 模块](https://www.npmjs.com/package/pg)。
 
-可以修改 client.js 以包含工作流所需的任何 PostgreSQL 操作。 在本例中，脚本连接到 PostgreSQL 服务，向 `postgres` 数据库添加一个表，插入一些占位符数据，然后检索数据。
+可以修改 client.js 以包含工作流所需的任何 PostgreSQL 操作。在本例中，脚本连接到 PostgreSQL 服务，向 `postgres` 数据库添加一个表，插入一些占位符数据，然后检索数据。
 
 {% data reusables.actions.service-container-add-script %}
 
@@ -324,9 +324,9 @@ pgclient.query('SELECT * FROM student', (err, res) => {
 });
 ```
 
-该脚本会创建与 PostgreSQL 服务的新连接，并使用 `POSTGRES_HOST` 和 `POSTGRES_PORT` 环境变量来指定 PostgreSQL 服务 IP 地址和端口。 如果未定义 `host` 和 `port`，则默认主机为 `localhost`，默认端口为 5432。
+该脚本会创建与 PostgreSQL 服务的新连接，并使用 `POSTGRES_HOST` 和 `POSTGRES_PORT` 环境变量来指定 PostgreSQL 服务 IP 地址和端口。如果未定义 `host` 和 `port`，则默认主机为 `localhost`，默认端口为 5432。
 
-脚本创建一个表并将用占位符数据添加。 要测试 `postgres` 数据库是否包含数据，脚本会将表的内容打印到控制台日志。
+脚本创建一个表并将用占位符数据添加。要测试 `postgres` 数据库是否包含数据，脚本会将表的内容打印到控制台日志。
 
 运行此工作流程时，应会在“连接到 PostgreSQL”步骤中看到以下输出，确认您成功创建了 PostgreSQL 表并添加了数据：
 
diff --git a/translations/zh-CN/content/actions/using-containerized-services/creating-redis-service-containers.md b/translations/zh-CN/content/actions/using-containerized-services/creating-redis-service-containers.md
index 7dd55c0ade95..ac88c09bd81d 100644
--- a/translations/zh-CN/content/actions/using-containerized-services/creating-redis-service-containers.md
+++ b/translations/zh-CN/content/actions/using-containerized-services/creating-redis-service-containers.md
@@ -1,7 +1,7 @@
 ---
 title: 创建 Redis 服务容器
 shortTitle: Redis service containers
-intro: 您可以使用服务容器在工作流程中创建 Redis 客户端。 本指南举例说明如何为容器中运行或直接在运行器机器上运行的作业创建 Redis 服务。
+intro: 您可以使用服务容器在工作流程中创建 Redis 客户端。本指南举例说明如何为容器中运行或直接在运行器机器上运行的作业创建 Redis 服务。
 redirect_from:
   - /actions/automating-your-workflow-with-github-actions/creating-redis-service-containers
   - /actions/configuring-and-managing-workflows/creating-redis-service-containers
@@ -26,7 +26,7 @@ ms.locfileid: '145100172'
 
 ## 简介
 
-本指南演示了使用 Docker Hub `redis` 映像配置服务容器的工作流示例。 工作流程运行脚本来创建 Redis 客户端并使用数据填充客户端。 要测试工作流程是否创建并填充 Redis 客户端，脚本会将客户端数据打印到控制台。
+本指南演示了使用 Docker Hub `redis` 映像配置服务容器的工作流示例。工作流程运行脚本来创建 Redis 客户端并使用数据填充客户端。要测试工作流程是否创建并填充 Redis 客户端，脚本会将客户端数据打印到控制台。
 
 {% data reusables.actions.docker-container-os-support %}
 
@@ -34,7 +34,7 @@ ms.locfileid: '145100172'
 
 {% data reusables.actions.service-container-prereqs %}
 
-你可能还会发现它也有助于基本了解 YAML、{% data variables.product.prodname_actions %} 的语法和 Redis。 有关详细信息，请参阅：
+你可能还会发现它也有助于基本了解 YAML、{% data variables.product.prodname_actions %} 的语法和 Redis。有关详细信息，请参阅：
 
 - [了解 {% data variables.product.prodname_actions %}](/actions/learn-github-actions)
 - Redis 文档中的“[Redis 入门](https://redislabs.com/get-started-with-redis/)”
@@ -150,11 +150,11 @@ steps:
 
 {% data reusables.actions.redis-environment-variables %}
 
-Redis 服务的主机名是在工作流中配置的标签，在本例中，主机名为 `redis`。 由于同一用户定义的网桥网络上的 Docker 容器默认打开所有端口，因此您将能够访问默认 Redis 端口 6379 上的服务容器。
+Redis 服务的主机名是在工作流中配置的标签，在本例中，主机名为 `redis`。由于同一用户定义的网桥网络上的 Docker 容器默认打开所有端口，因此您将能够访问默认 Redis 端口 6379 上的服务容器。
 
 ## 直接在运行器机器上运行作业
 
-直接在运行器机器上运行作业时，需要将服务容器上的端口映射到 Docker 主机上的端口。 可以使用 `localhost` 和 Docker 主机端口号从 Docker 主机访问服务容器。
+直接在运行器机器上运行作业时，需要将服务容器上的端口映射到 Docker 主机上的端口。可以使用 `localhost` 和 Docker 主机端口号从 Docker 主机访问服务容器。
 
 {% data reusables.actions.copy-workflow-file %}
 
@@ -213,7 +213,7 @@ jobs:
 
 {% data reusables.actions.redis-label-description %}
 
-工作流程将 Redis 服务容器上的端口 6379 映射到 Docker 主机。 有关 `ports` 关键字的详细信息，请参阅“[关于服务容器](/actions/automating-your-workflow-with-github-actions/about-service-containers#mapping-docker-host-and-service-container-ports)。”
+工作流程将 Redis 服务容器上的端口 6379 映射到 Docker 主机。有关 `ports` 关键字的详细信息，请参阅“[关于服务容器](/actions/automating-your-workflow-with-github-actions/about-service-containers#mapping-docker-host-and-service-container-ports)。”
 
 ```yaml{:copy}
 jobs:
@@ -273,9 +273,9 @@ steps:
 
 ## 测试 Redis 服务容器
 
-您可以使用以下脚本测试工作流程，该脚本将创建 Redis 客户端，并使用某些占位符数据填充客户端。 然后，脚本将存储在 Redis 客户端中的值打印到终端。 你的脚本可以使用任何你喜欢的语言，但此示例使用 Node.js 和 `redis` npm 模块。 有关详细信息，请参阅 [npm redis 模块](https://www.npmjs.com/package/redis)。
+您可以使用以下脚本测试工作流程，该脚本将创建 Redis 客户端，并使用某些占位符数据填充客户端。然后，脚本将存储在 Redis 客户端中的值打印到终端。你的脚本可以使用任何你喜欢的语言，但此示例使用 Node.js 和 `redis` npm 模块。有关详细信息，请参阅 [npm redis 模块](https://www.npmjs.com/package/redis)。
 
-可以修改 client.js 以包含工作流所需的任何 Redis 操作。 在此示例中，脚本创建 Redis 客户端实例、添加占位符数据，然后检索数据。
+可以修改 client.js 以包含工作流所需的任何 Redis 操作。在此示例中，脚本创建 Redis 客户端实例、添加占位符数据，然后检索数据。
 
 {% data reusables.actions.service-container-add-script %}
 
@@ -313,9 +313,9 @@ redisClient.hkeys("species", function (err, replies) {
 });
 ```
 
-该脚本使用 `createClient` 方法创建新的 Redis 客户端，该方法接受 `host` 和 `port` 参数。 该脚本使用 `REDIS_HOST` 和 `REDIS_PORT` 环境变量来设置客户端的 IP 地址和端口。 如果未定义 `host` 和 `port`，则默认主机为 `localhost`，默认端口为 6379。
+该脚本使用 `createClient` 方法创建新的 Redis 客户端，该方法接受 `host` 和 `port` 参数。该脚本使用 `REDIS_HOST` 和 `REDIS_PORT` 环境变量来设置客户端的 IP 地址和端口。如果未定义 `host` 和 `port`，则默认主机为 `localhost`，默认端口为 6379。
 
-该脚本使用 `set` 和 `hset` 方法，使用某些键、字段和值填充数据库。 要确认 Redis 客户端是否包含数据，脚本会将数据库的内容打印到控制台日志。
+该脚本使用 `set` 和 `hset` 方法，使用某些键、字段和值填充数据库。要确认 Redis 客户端是否包含数据，脚本会将数据库的内容打印到控制台日志。
 
 运行此工作流程时，应会在“连接到 Redis”步骤中看到以下输出，确认您创建了 Redis 客户端并添加了数据：
 
diff --git a/translations/zh-CN/content/actions/using-github-hosted-runners/connecting-to-a-private-network.md b/translations/zh-CN/content/actions/using-github-hosted-runners/connecting-to-a-private-network.md
index c2b0247ebf29..f415bdeda240 100644
--- a/translations/zh-CN/content/actions/using-github-hosted-runners/connecting-to-a-private-network.md
+++ b/translations/zh-CN/content/actions/using-github-hosted-runners/connecting-to-a-private-network.md
@@ -20,20 +20,20 @@ ms.locfileid: '147884267'
 
 ## 关于 {% data variables.product.prodname_dotcom %} 托管的运行器网络
 
-默认情况下，{% data variables.product.prodname_dotcom %} 托管的运行器有权访问公共 Internet。 但是，你可能还希望这些运行器访问专用网络上的资源，例如包注册表、机密管理器或其他本地服务。 
+默认情况下，{% data variables.product.prodname_dotcom %} 托管的运行器有权访问公共 Internet。但是，你可能还希望这些运行器访问专用网络上的资源，例如包注册表、机密管理器或其他本地服务。 
 
-{% data variables.product.prodname_dotcom %} 托管的运行器在所有 {% data variables.product.prodname_dotcom %} 客户之间共享，因此，你需要一种方法，在运行器运行你的工作流时，将你的专用网络仅连接到它们。 可以采用几种不同的方法来配置此访问，每个方法都有不同的优缺点。
+{% data variables.product.prodname_dotcom %} 托管的运行器在所有 {% data variables.product.prodname_dotcom %} 客户之间共享，因此，你需要一种方法，在运行器运行你的工作流时，将你的专用网络仅连接到它们。可以采用几种不同的方法来配置此访问，每个方法都有不同的优缺点。
 
 {% ifversion fpt or ghec or ghes > 3.4 %}
 ### 将 API 网关与 OIDC 配合使用
 
-借助 {% data variables.product.prodname_actions %}，可以使用 OpenID Connect (OIDC) 令牌对 {% data variables.product.prodname_actions %} 之外的工作流进行身份验证。 例如，可以在专用网络的边缘运行 API 网关，该网关使用 OIDC 令牌对传入请求进行身份验证，然后代表专用网络中的工作流发出 API 请求。
+借助 {% data variables.product.prodname_actions %}，可以使用 OpenID Connect (OIDC) 令牌对 {% data variables.product.prodname_actions %} 之外的工作流进行身份验证。例如，可以在专用网络的边缘运行 API 网关，该网关使用 OIDC 令牌对传入请求进行身份验证，然后代表专用网络中的工作流发出 API 请求。
 
 下图概述了此解决方案的体系结构：
 
 ![OIDC 网关示意图](/assets/images/help/images/actions-oidc-gateway.png)
 
-重要的是，不仅要验证 OIDC 令牌来自 {% data variables.product.prodname_actions %}，而且还要验证它专门来自你预期的工作流，以便其他 {% data variables.product.prodname_actions %} 用户无法访问专用网络中的服务。 可以使用 OIDC 声明创建这些条件。 有关详细信息，请参阅“[使用 OIDC 声明定义云角色的信任条件](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#defining-trust-conditions-on-cloud-roles-using-oidc-claims)”。
+重要的是，不仅要验证 OIDC 令牌来自 {% data variables.product.prodname_actions %}，而且还要验证它专门来自你预期的工作流，以便其他 {% data variables.product.prodname_actions %} 用户无法访问专用网络中的服务。可以使用 OIDC 声明创建这些条件。有关详细信息，请参阅“[使用 OIDC 声明定义云角色的信任条件](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#defining-trust-conditions-on-cloud-roles-using-oidc-claims)”。
 
 这种方法的主要缺点是，必须实现 API 网关来代表你发出请求，并在网络边缘运行它。
 
@@ -53,7 +53,7 @@ ms.locfileid: '147884267'
 - 若要访问在专用服务上运行的 WireGuard，需要工作流可以引用的已知 IP 地址和端口：可以是公共 IP 地址和端口、网络网关上的端口映射，或者动态更新 DNS 的服务。 
 - WireGuard 无法即时处理 NAT 遍历，因此需要确定一种提供此服务的方法。
 - 此连接是一对一的，因此如果需要高可用性或高吞吐量，则需要在 WireGuard 之上构建它。 
-- 需要为运行器和专用服务生成并安全地存储密钥。 WireGuard 使用 UDP，因此网络必须支持 UDP 流量。
+- 需要为运行器和专用服务生成并安全地存储密钥。WireGuard 使用 UDP，因此网络必须支持 UDP 流量。
 
 也有一些优点，由于可以在现有服务器上运行 WireGuard，因此不必维护单独的基础结构，并且它在 {% data variables.product.prodname_dotcom %} 托管的运行器上得到了很好的支持。
 
@@ -99,10 +99,10 @@ jobs:
 
 ### 使用 Tailscale 创建网络覆盖
 
-Tailscale 是基于 WireGuard 构建的商业产品。 此选项与 WireGuard 非常相似，不同之处在于 Tailscale 更多的是完整的产品体验，而不是开源组件。
+Tailscale 是基于 WireGuard 构建的商业产品。此选项与 WireGuard 非常相似，不同之处在于 Tailscale 更多的是完整的产品体验，而不是开源组件。
 
-它的缺点与 WireGuard 类似：连接是一对一的，因此可能需要执行额外的操作以实现高可用性或高吞吐量。 你仍然需要生成并安全地存储密钥。 协议仍然是 UDP，因此网络必须支持 UDP 流量。
+它的缺点与 WireGuard 类似：连接是一对一的，因此可能需要执行额外的操作以实现高可用性或高吞吐量。你仍然需要生成并安全地存储密钥。协议仍然是 UDP，因此网络必须支持 UDP 流量。
 
-但是，与 WireGuard 相比，它也有一些优势：NAT 遍历是内置的，因此无需向公共 Internet 公开端口。 这是迄今为止启动和运行最快的选项，因为 Tailscale 提供了一个 {% data variables.product.prodname_actions %} 工作流，只需一步即可连接到覆盖网络。
+但是，与 WireGuard 相比，它也有一些优势：NAT 遍历是内置的，因此无需向公共 Internet 公开端口。这是迄今为止启动和运行最快的选项，因为 Tailscale 提供了一个 {% data variables.product.prodname_actions %} 工作流，只需一步即可连接到覆盖网络。
 
 有关详细信息，请参阅 [Tailscale GitHub 操作](https://github.com/tailscale/github-action)以及“[加密机密](/actions/security-guides/encrypted-secrets)”以了解如何安全地存储密钥。
diff --git a/translations/zh-CN/content/actions/using-github-hosted-runners/customizing-github-hosted-runners.md b/translations/zh-CN/content/actions/using-github-hosted-runners/customizing-github-hosted-runners.md
index 5a6eec95e181..c2e5aff3a279 100644
--- a/translations/zh-CN/content/actions/using-github-hosted-runners/customizing-github-hosted-runners.md
+++ b/translations/zh-CN/content/actions/using-github-hosted-runners/customizing-github-hosted-runners.md
@@ -45,7 +45,7 @@ jobs:
 
 {% note %}
 
-注意：安装包之前始终运行 `sudo apt-get update`。 如果 `apt` 索引已经过时，此命令将获取并重新索引任何可用的包，这有助于防止包安装失败。 
+注意：安装包之前始终运行 `sudo apt-get update`。如果 `apt` 索引已经过时，此命令将获取并重新索引任何可用的包，这有助于防止包安装失败。 
 
 {% endnote %}
 
diff --git a/translations/zh-CN/content/actions/using-github-hosted-runners/monitoring-your-current-jobs.md b/translations/zh-CN/content/actions/using-github-hosted-runners/monitoring-your-current-jobs.md
index 02a6ecb92552..104f3ff402c2 100644
--- a/translations/zh-CN/content/actions/using-github-hosted-runners/monitoring-your-current-jobs.md
+++ b/translations/zh-CN/content/actions/using-github-hosted-runners/monitoring-your-current-jobs.md
@@ -24,10 +24,10 @@ ms.locfileid: '145100158'
 
 ## 查看组织或企业中的排队作业
 
-{% data variables.product.prodname_dotcom %}-hosted runners 允许你同时运行作业，最大并发作业数将根据你的计划而有所不同。 如果达到最大并发作业数，任何新作业都将开始进入队列。 若要详细了解计划可用的并发作业数量，请参阅“[使用限制、计费和管理](/actions/learn-github-actions/usage-limits-billing-and-administration)”。
+{% data variables.product.prodname_dotcom %}-hosted runners 允许你同时运行作业，最大并发作业数将根据你的计划而有所不同。如果达到最大并发作业数，任何新作业都将开始进入队列。若要详细了解计划可用的并发作业数量，请参阅“[使用限制、计费和管理](/actions/learn-github-actions/usage-limits-billing-and-administration)”。
 
 以下过程演示了如何检查可以运行的最大并发作业数。
 
 {% data reusables.actions.github-hosted-runners-navigate-to-repo-org-enterprise %} {% data reusables.actions.github-hosted-runners-table-entry %}
-1. 查看“所有作业使用情况”部分，其中列出了活动作业的数量和你可以运行的最大作业数量。 在此示例中，`9` 个作业当前已超过最大值 `180`。
+1. 查看“所有作业使用情况”部分，其中列出了活动作业的数量和你可以运行的最大作业数量。在此示例中，`9` 个作业当前已超过最大值 `180`。
   ![一个帐户的最大作业的屏幕截图](/assets/images/help/settings/github-hosted-runners-max-jobs.png)
diff --git a/translations/zh-CN/content/actions/using-jobs/using-conditions-to-control-job-execution.md b/translations/zh-CN/content/actions/using-jobs/using-conditions-to-control-job-execution.md
index f9b6e37669fe..ba24764ae588 100644
--- a/translations/zh-CN/content/actions/using-jobs/using-conditions-to-control-job-execution.md
+++ b/translations/zh-CN/content/actions/using-jobs/using-conditions-to-control-job-execution.md
@@ -21,7 +21,7 @@ ms.locfileid: '145100139'
 
 {% note %}
 
-注意：跳过的作业将报告其状态为“成功”。 即使是必需检查，也不会阻止拉取请求合并。
+注意：跳过的作业将报告其状态为“成功”。即使是必需检查，也不会阻止拉取请求合并。
 
 {% endnote %}
 
diff --git a/translations/zh-CN/content/actions/using-workflows/caching-dependencies-to-speed-up-workflows.md b/translations/zh-CN/content/actions/using-workflows/caching-dependencies-to-speed-up-workflows.md
index 147ddb094843..8f8a357a445a 100644
--- a/translations/zh-CN/content/actions/using-workflows/caching-dependencies-to-speed-up-workflows.md
+++ b/translations/zh-CN/content/actions/using-workflows/caching-dependencies-to-speed-up-workflows.md
@@ -23,11 +23,11 @@ ms.locfileid: '147580669'
 ---
 ## <a name="about-caching-workflow-dependencies"></a>关于缓存工作流程依赖项
 
-工作流程运行通常在不同运行之间重新使用相同的输出或下载的依赖项。 例如，Maven、Gradle、npm 和 Yarn 等软件包和依赖项管理工具都会对下载的依赖项保留本地缓存。
+工作流程运行通常在不同运行之间重新使用相同的输出或下载的依赖项。例如，Maven、Gradle、npm 和 Yarn 等软件包和依赖项管理工具都会对下载的依赖项保留本地缓存。
 
 {% data variables.product.prodname_dotcom %} 托管的运行器上的 {% ifversion fpt or ghec %} 作业在干净的运行器映像中启动，每次都必须下载依赖项，导致网络利用率提高、运行时间延长和成本增加。 {% endif %}为帮助加快重新创建依赖项等文件，{% data variables.product.prodname_dotcom %} 可以缓存你在工作流中经常使用的文件。
 
-要缓存作业的依赖项，可以使用 {% data variables.product.prodname_dotcom %} 的 [`cache` 操作](https://github.com/actions/cache)。 该操作创建和还原由唯一键标识的缓存。 或者，如果要缓存下列包管理器，则使用其各自的 setup-* 操作需要最小配置并将为你创建和还原依赖项缓存。
+要缓存作业的依赖项，可以使用 {% data variables.product.prodname_dotcom %} 的 [`cache` 操作](https://github.com/actions/cache)。该操作创建和还原由唯一键标识的缓存。或者，如果要缓存下列包管理器，则使用其各自的 setup-* 操作需要最小配置并将为你创建和还原依赖项缓存。
 
 | 包管理器 | 用于缓存的 setup-* 操作 |
 |---|---|
@@ -41,9 +41,9 @@ ms.locfileid: '147580669'
 
 警告：{% ifversion fpt or ghec %}将缓存与 {% data variables.product.prodname_actions %} 结合使用时，请注意以下几点：
 
-* {% endif %}建议不要在缓存中存储任何敏感信息。 例如，敏感信息可以包括存储在缓存路径的文件中的访问令牌或登录凭据。 此外，命令行接口 (CLI) 程序（例如 `docker login`）可以将访问凭据保存在配置文件中。 具有读取访问权限的任何人都可以在存储库上创建拉取请求并访问缓存的内容。 仓库的复刻也可在基本分支上创建拉取请求，并在基本分支上访问缓存。
+* {% endif %}建议不要在缓存中存储任何敏感信息。例如，敏感信息可以包括存储在缓存路径的文件中的访问令牌或登录凭据。此外，命令行接口 (CLI) 程序（例如 `docker login`）可以将访问凭据保存在配置文件中。具有读取访问权限的任何人都可以在存储库上创建拉取请求并访问缓存的内容。仓库的复刻也可在基本分支上创建拉取请求，并在基本分支上访问缓存。
 {%- ifversion fpt or ghec %}
-* 使用自托管运行器时，工作流运行中的缓存存储在 {% data variables.product.company_short %} 拥有的云存储上。 客户拥有的存储解决方案仅适用于 {% data variables.product.prodname_ghe_server %}。
+* 使用自托管运行器时，工作流运行中的缓存存储在 {% data variables.product.company_short %} 拥有的云存储上。客户拥有的存储解决方案仅适用于 {% data variables.product.prodname_ghe_server %}。
 {%- endif %}
 
 {% endwarning %}
@@ -54,25 +54,25 @@ ms.locfileid: '147580669'
 
 ## <a name="restrictions-for-accessing-a-cache"></a>访问缓存的限制
 
-工作流可以访问和还原当前分支、基础分支（包括复刻的存储库的基本分支）或默认分支（通常是 `main`）中创建的缓存。 例如，在默认分支上创建的缓存可从任何拉取请求访问。 此外，如果分支 `feature-b` 具有基础分支 `feature-a`，则在 `feature-b` 上触发的工作流将有权访问在默认分支 (`main`)、`feature-a` 和 `feature-b` 中创建的缓存。
+工作流可以访问和还原当前分支、基础分支（包括复刻的存储库的基本分支）或默认分支（通常是 `main`）中创建的缓存。例如，在默认分支上创建的缓存可从任何拉取请求访问。此外，如果分支 `feature-b` 具有基础分支 `feature-a`，则在 `feature-b` 上触发的工作流将有权访问在默认分支 (`main`)、`feature-a` 和 `feature-b` 中创建的缓存。
 
-访问限制通过在不同分支之间创建逻辑边界来提供缓存隔离和安全。 例如，针对分支 `feature-c`（具有基础 `main`）的拉取请求无法访问为分支 `feature-a`（具有基础 `main`）创建的缓存。
+访问限制通过在不同分支之间创建逻辑边界来提供缓存隔离和安全。例如，针对分支 `feature-c`（具有基础 `main`）的拉取请求无法访问为分支 `feature-a`（具有基础 `main`）创建的缓存。
 
-仓库中的多个工作流程共享缓存条目。 可以从同一仓库和分支的另一个工作流程访问和恢复为工作流程中的分支创建的缓存。
+仓库中的多个工作流程共享缓存条目。可以从同一仓库和分支的另一个工作流程访问和恢复为工作流程中的分支创建的缓存。
 
 ## <a name="using-the-cache-action"></a>使用 `cache` 操作
 
-此 [`cache` 操作](https://github.com/actions/cache)将尝试根据你提供 `key` 的还原缓存。 当操作找到缓存时，该操作会将缓存的文件还原到你配置的 `path`。
+此 [`cache` 操作](https://github.com/actions/cache)将尝试根据你提供 `key` 的还原缓存。当操作找到缓存时，该操作会将缓存的文件还原到你配置的 `path`。
 
-如果没有精确匹配，该操作在作业成功完成时会自动创建一个新缓存。 新缓存将使用你提供的 `key`，并包含你在 `path` 中指定的文件。
+如果没有精确匹配，该操作在作业成功完成时会自动创建一个新缓存。新缓存将使用你提供的 `key`，并包含你在 `path` 中指定的文件。
 
-可以选择提供在 `key` 与现有缓存不匹配时要使用的 `restore-keys` 列表。 从另一个分支还原缓存时，`restore-keys` 列表非常有用，因为 `restore-keys` 可以部分匹配缓存密钥。 有关匹配 `restore-keys` 的详细信息，请参阅“[匹配缓存密钥](#matching-a-cache-key)”。
+可以选择提供在 `key` 与现有缓存不匹配时要使用的 `restore-keys` 列表。从另一个分支还原缓存时，`restore-keys` 列表非常有用，因为 `restore-keys` 可以部分匹配缓存密钥。有关匹配 `restore-keys` 的详细信息，请参阅“[匹配缓存密钥](#matching-a-cache-key)”。
 
 ### <a name="input-parameters-for-the-cache-action"></a>`cache` 操作的输入参数
 
-- `key`：必要。保存缓存时创建的密钥和用于搜索缓存的密钥。 它可以是变量、上下文值、静态字符串和函数的任何组合。 密钥最大长度为 512 个字符，密钥长度超过最大长度将导致操作失败。
+- `key`：必要。保存缓存时创建的密钥和用于搜索缓存的密钥。它可以是变量、上下文值、静态字符串和函数的任何组合。密钥最大长度为 512 个字符，密钥长度超过最大长度将导致操作失败。
 - `path`：必要。运行器上用于缓存或还原的路径。
-  - 可以指定单个路径，也可以在单独的行上添加多个路径。 例如：
+  - 可以指定单个路径，也可以在单独的行上添加多个路径。例如：
 
     ```
     - name: Cache Gradle packages
@@ -84,7 +84,7 @@ ms.locfileid: '147580669'
     ```
   - 可以指定目录或单个文件，并且支持 glob 模式。
   - 可以指定绝对路径或相对于工作区目录的路径。
-- `restore-keys`：可选。包含备用还原键的字符串，每个还原键均放置在一个新行上。 如果 `key` 没有发生缓存命中，则按照提供的顺序依次使用这些还原键来查找和还原缓存。 例如：
+- `restore-keys`：可选。包含备用还原键的字符串，每个还原键均放置在一个新行上。如果 `key` 没有发生缓存命中，则按照提供的顺序依次使用这些还原键来查找和还原缓存。例如：
 
   {% raw %}
   ```yaml
@@ -101,7 +101,7 @@ ms.locfileid: '147580669'
 
 ### <a name="example-using-the-cache-action"></a>使用 `cache` 操作的示例
 
-此示例在 `package-lock.json` 文件中的包更改时，或运行器的操作系统更改时，创建一个新的缓存。 缓存键使用上下文和表达式生成一个键值，其中包括运行器的操作系统和 `package-lock.json` 文件的 SHA-256 哈希。
+此示例在 `package-lock.json` 文件中的包更改时，或运行器的操作系统更改时，创建一个新的缓存。缓存键使用上下文和表达式生成一个键值，其中包括运行器的操作系统和 `package-lock.json` 文件的 SHA-256 哈希。
 
 ```yaml{:copy}
 name: Caching with npm
@@ -149,19 +149,19 @@ jobs:
 
 1. 如果提供 `restore-keys`，`cache` 操作将按顺序搜索与 `restore-keys` 列表匹配的任何缓存。
    - 当存在精确匹配时，该操作会将缓存中的文件还原到 `path` 目录。
-   - 如果没有精确匹配，操作将会搜索恢复键值的部分匹配。 当操作找到部分匹配时，最近的缓存将还原到 `path` 目录。
+   - 如果没有精确匹配，操作将会搜索恢复键值的部分匹配。当操作找到部分匹配时，最近的缓存将还原到 `path` 目录。
 1. `cache` 操作完成，作业中的下一个步骤运行。
 1. 如果作业成功完成，则操作将自动创建一个包含 `path` 目录内容的新缓存。
 
-有关缓存匹配过程的更详细说明，请参阅“[匹配缓存键](#matching-a-cache-key)”。 创建缓存后，无法更改现有缓存的内容，但可以使用新键创建新缓存。
+有关缓存匹配过程的更详细说明，请参阅“[匹配缓存键](#matching-a-cache-key)”。创建缓存后，无法更改现有缓存的内容，但可以使用新键创建新缓存。
 
 ### <a name="using-contexts-to-create-cache-keys"></a>使用上下文创建缓存键
 
-缓存键可以包括 {% data variables.product.prodname_actions %} 支持的任何上下文、函数、文本和运算符。 有关详细信息，请参阅“[上下文](/actions/learn-github-actions/contexts)”和“[表达式](/actions/learn-github-actions/expressions)”。
+缓存键可以包括 {% data variables.product.prodname_actions %} 支持的任何上下文、函数、文本和运算符。有关详细信息，请参阅“[上下文](/actions/learn-github-actions/contexts)”和“[表达式](/actions/learn-github-actions/expressions)”。
 
 使用表达式创建 `key` 使你能够在依赖项更改时自动创建新缓存。
 
-例如，可以使用可计算 npm `package-lock.json` 文件的哈希的表达式创建 `key`。 因此，当构成 `package-lock.json` 文件的依赖项更改时，缓存键会更改，并自动创建新缓存。
+例如，可以使用可计算 npm `package-lock.json` 文件的哈希的表达式创建 `key`。因此，当构成 `package-lock.json` 文件的依赖项更改时，缓存键会更改，并自动创建新缓存。
 
 {% raw %}
 ```yaml
@@ -177,7 +177,7 @@ npm-d5ea0750
 
 ### <a name="using-the-output-of-the-cache-action"></a>使用 `cache` 操作的输出
 
-可以使用 `cache` 操作的输出，以根据发生的是缓存命中还是缓存失误来执行某些操作。 找到指定 `key` 的缓存的精确匹配时，`cache-hit` 输出设置为 `true`。
+可以使用 `cache` 操作的输出，以根据发生的是缓存命中还是缓存失误来执行某些操作。找到指定 `key` 的缓存的精确匹配时，`cache-hit` 输出设置为 `true`。
 
 在上面的示例工作流中，有一个步骤会列出发生缓存失误时节点模块的状态：
 
@@ -190,9 +190,9 @@ npm-d5ea0750
 
 ## <a name="matching-a-cache-key"></a>匹配缓存键
 
-`cache` 操作首先在包含工作流运行的分支中搜索 `key` 和 `restore-keys` 的缓存命中。 如果当前分支中没有命中，`cache` 操作将在父分支和上游分支中搜索 `key` 和 `restore-keys`。
+`cache` 操作首先在包含工作流运行的分支中搜索 `key` 和 `restore-keys` 的缓存命中。如果当前分支中没有命中，`cache` 操作将在父分支和上游分支中搜索 `key` 和 `restore-keys`。
 
-通过 `restore-keys`，你可以指定当 `key` 中发生缓存失误时要使用的备用还原键列表。 您可以创建从最具体到最不具体的多个恢复键。 `cache` 操作按顺序搜索 `restore-keys`。 当键不直接匹配时，操作将搜索以恢复键为前缀的键。 如果恢复键值有多个部分匹配项，操作将返回最近创建的缓存。
+通过 `restore-keys`，你可以指定当 `key` 中发生缓存失误时要使用的备用还原键列表。您可以创建从最具体到最不具体的多个恢复键。 `cache` 操作按顺序搜索 `restore-keys`。当键不直接匹配时，操作将搜索以恢复键为前缀的键。如果恢复键值有多个部分匹配项，操作将返回最近创建的缓存。
 
 ### <a name="example-using-multiple-restore-keys"></a>使用多个恢复键值的示例
 
@@ -216,7 +216,7 @@ restore-keys: |
 ```
 {% endraw %}
 
-还原键 `npm-feature-` 与以字符串 `npm-feature-` 开头的任何键匹配。 例如，`npm-feature-fd3052de` 和 `npm-feature-a9b253ff` 这两个键都与还原键匹配。 将使用创建日期最新的缓存。 此示例中的键值按以下顺序搜索：
+还原键 `npm-feature-` 与以字符串 `npm-feature-` 开头的任何键匹配。例如，`npm-feature-fd3052de` 和 `npm-feature-a9b253ff` 这两个键都与还原键匹配。将使用创建日期最新的缓存。此示例中的键值按以下顺序搜索：
 
 1. `npm-feature-d5ea0750` 匹配特定哈希。
 1. `npm-feature-` 匹配前缀为 `npm-feature-` 的缓存键。
@@ -243,7 +243,7 @@ restore-keys: |
 
 ## <a name="usage-limits-and-eviction-policy"></a>使用限制和收回政策
 
-{% data variables.product.prodname_dotcom %} 将删除 7 天内未被访问的任何缓存条目。 可以存储的缓存数没有限制，但存储库中所有缓存的总大小限制{% ifversion actions-cache-policy-apis %}。 默认情况下，每个存储库的限制为 10 GB，但根据企业所有者或存储库管理员设置的策略，此限制可能有所不同。{% else %}为 10 GB。{% endif %} 
+{% data variables.product.prodname_dotcom %} 将删除 7 天内未被访问的任何缓存条目。可以存储的缓存数没有限制，但存储库中所有缓存的总大小限制{% ifversion actions-cache-policy-apis %}。默认情况下，每个存储库的限制为 10 GB，但根据企业所有者或存储库管理员设置的策略，此限制可能有所不同。{% else %}为 10 GB。{% endif %} 
 
 {% data reusables.actions.cache-eviction-process %}
 
@@ -256,6 +256,6 @@ restore-keys: |
 
 可以使用 {% data variables.product.product_name %} REST API 来管理缓存。 {% ifversion actions-cache-list-delete-apis %}可以使用 API 列出和删除缓存条目，并查看缓存使用情况。{% elsif actions-cache-management %}目前，可以使用 API 查看缓存使用情况，将来的更新中预期会有更多功能。{% endif %}有关详细信息，请参阅“[{% data variables.product.prodname_actions %} 缓存](/rest/actions/cache)”REST API 文档。
 
-你还可以安装 {% data variables.product.prodname_cli %} 扩展来从命令行管理缓存。 有关扩展的详细信息，请参阅[扩展文档](https://github.com/actions/gh-actions-cache#readme)。 有关 {% data variables.product.prodname_cli %} 扩展的详细信息，请参阅“[使用 GitHub CLI 扩展](/github-cli/github-cli/using-github-cli-extensions)”。
+你还可以安装 {% data variables.product.prodname_cli %} 扩展来从命令行管理缓存。有关扩展的详细信息，请参阅[扩展文档](https://github.com/actions/gh-actions-cache#readme)。有关 {% data variables.product.prodname_cli %} 扩展的详细信息，请参阅“[使用 GitHub CLI 扩展](/github-cli/github-cli/using-github-cli-extensions)”。
 
 {% endif %}
diff --git a/translations/zh-CN/content/actions/using-workflows/storing-workflow-data-as-artifacts.md b/translations/zh-CN/content/actions/using-workflows/storing-workflow-data-as-artifacts.md
index feb37bfee4d9..7a4fd1086a03 100644
--- a/translations/zh-CN/content/actions/using-workflows/storing-workflow-data-as-artifacts.md
+++ b/translations/zh-CN/content/actions/using-workflows/storing-workflow-data-as-artifacts.md
@@ -28,7 +28,7 @@ ms.locfileid: '146179733'
 
 ## 关于工作流程构件
 
-构件允许您在作业完成后保留数据，并与同一工作流程中的另一个作业共享该数据。 构件是指在工作流程运行过程中产生的文件或文件集。 例如，在工作流程运行结束后，您可以使用构件保存您的构建和测试输出。 {% data reusables.actions.reusable-workflow-artifacts %}
+构件允许您在作业完成后保留数据，并与同一工作流程中的另一个作业共享该数据。构件是指在工作流程运行过程中产生的文件或文件集。例如，在工作流程运行结束后，您可以使用构件保存您的构建和测试输出。 {% data reusables.actions.reusable-workflow-artifacts %}
 
 {% data reusables.actions.artifact-log-retention-statement %} 每当有人向拉取请求推送新提交时，拉取请求的保留期都会重新开始计算。
 
@@ -49,16 +49,16 @@ ms.locfileid: '146179733'
 
 {% endif %}
 
-构件会在工作流程运行过程中上传，您可以在 UI 中查看构件的名称和大小。 当构件使用 {% data variables.product.product_name %} UI 下载时， 作为构件一部分单独上传的所有文件都会压缩到一个 zip 文件中。 这意味着计费是根据上传的构件大小而不是 zip 文件的大小计算的。
+构件会在工作流程运行过程中上传，您可以在 UI 中查看构件的名称和大小。当构件使用 {% data variables.product.product_name %} UI 下载时，作为构件一部分单独上传的所有文件都会压缩到一个 zip 文件中。这意味着计费是根据上传的构件大小而不是 zip 文件的大小计算的。
 
-{% data variables.product.product_name %} 提供两项可用于上传和下载构建构件的操作。 有关详细信息，请参阅 {% ifversion fpt or ghec %}[actions/upload-artifact](https://github.com/actions/upload-artifact) 和 [download-artifact](https://github.com/actions/download-artifact) 操作{% else %} {% data variables.product.product_location %} 上的 `actions/upload-artifact` 和 `download-artifact` 操作{% endif %}。
+{% data variables.product.product_name %} 提供两项可用于上传和下载构建构件的操作。有关详细信息，请参阅 {% ifversion fpt or ghec %}[actions/upload-artifact](https://github.com/actions/upload-artifact) 和 [download-artifact](https://github.com/actions/download-artifact) 操作{% else %} {% data variables.product.product_location %} 上的 `actions/upload-artifact` 和 `download-artifact` 操作{% endif %}。
 
 要在作业之间共享数据：
 
 * **上传文件**：为上传的文件指定一个名称，并在作业结束前上传数据。
-* **下载文件**：只能下载在同一工作流运行期间上传的工件。 下载文件时，您可以通过名称引用该文件。
+* **下载文件**：只能下载在同一工作流运行期间上传的工件。下载文件时，您可以通过名称引用该文件。
 
-作业步骤共享运行器机器的相同环境，但在其各自的进程中运行。 要在作业的步骤之间传递数据，您可以使用输入和输出。 有关输入和输出的详细信息，请参阅“[{% data variables.product.prodname_actions %} 的元数据语法](/articles/metadata-syntax-for-github-actions)”。
+作业步骤共享运行器机器的相同环境，但在其各自的进程中运行。要在作业的步骤之间传递数据，您可以使用输入和输出。有关输入和输出的详细信息，请参阅“[{% data variables.product.prodname_actions %} 的元数据语法](/articles/metadata-syntax-for-github-actions)”。
 
 {% ifversion actions-caching %}
 
@@ -70,15 +70,15 @@ ms.locfileid: '146179733'
 
 ## 上传构建和测试构件
 
-您可以创建持续集成 (CI) 工作流程来构建和测试您的代码。 有关使用 {% data variables.product.prodname_actions %} 执行 CI 的详细信息，请参阅“[关于持续集成](/articles/about-continuous-integration)”。
+您可以创建持续集成 (CI) 工作流程来构建和测试您的代码。有关使用 {% data variables.product.prodname_actions %} 执行 CI 的详细信息，请参阅“[关于持续集成](/articles/about-continuous-integration)”。
 
-构建和测试代码的输出通常会生成可用于调试测试失败的文件和可部署的生产代码。 您可以配置一个工作流程来构建和测试推送到仓库中的代码，并报告成功或失败状态。 您可以上传构建和测试输出，以用于部署、调试失败的测试或崩溃以及查看测试套件范围。
+构建和测试代码的输出通常会生成可用于调试测试失败的文件和可部署的生产代码。您可以配置一个工作流程来构建和测试推送到仓库中的代码，并报告成功或失败状态。您可以上传构建和测试输出，以用于部署、调试失败的测试或崩溃以及查看测试套件范围。
 
-可以使用 `upload-artifact` 操作上传工件。 上传构件时，您可以指定单个文件或目录，或多个文件或目录。 您还可以排除某些文件或目录，以及使用通配符模式。 建议为工件命名，如果没有命名，则会使用 `artifact` 作为默认名称。 有关语法的详细信息，请参阅 {% ifversion fpt or ghec %}[actions/upload-artifact](https://github.com/actions/upload-artifact) 操作{% else %} {% data variables.product.product_location %} 上的 `actions/upload-artifact` 操作{% endif %}。
+可以使用 `upload-artifact` 操作上传工件。上传构件时，您可以指定单个文件或目录，或多个文件或目录。您还可以排除某些文件或目录，以及使用通配符模式。建议为工件命名，如果没有命名，则会使用 `artifact` 作为默认名称。有关语法的详细信息，请参阅 {% ifversion fpt or ghec %}[actions/upload-artifact](https://github.com/actions/upload-artifact) 操作{% else %} {% data variables.product.product_location %} 上的 `actions/upload-artifact` 操作{% endif %}。
 
 ### 示例
 
-例如，您的仓库或 Web 应用程序可能包含必须转换为 CSS 和 JavaScript 的 SASS 和 TypeScript 文件。 假设生成配置输出 `dist` 目录中已编译的文件，如果所有测试均已成功完成，则可将 `dist` 目录中的文件部署到 Web 应用服务器。
+例如，您的仓库或 Web 应用程序可能包含必须转换为 CSS 和 JavaScript 的 SASS 和 TypeScript 文件。假设生成配置输出 `dist` 目录中已编译的文件，如果所有测试均已成功完成，则可将 `dist` 目录中的文件部署到 Web 应用服务器。
 
 ```
 |-- hello-world (repository)
@@ -92,9 +92,9 @@ ms.locfileid: '146179733'
 |   
 ```
 
-此示例演示了如何创建 Node.js 项目的工作流，该项目在 `src` 目录中生成代码，在 `tests` 目录中运行测试。 可以假定运行 `npm test` 会生成一个名为 `code-coverage.html`、存储在 `output/test/` 目录中的代码覆盖率报告。
+此示例演示了如何创建 Node.js 项目的工作流，该项目在 `src` 目录中生成代码，在 `tests` 目录中运行测试。可以假定运行 `npm test` 会生成一个名为 `code-coverage.html`、存储在 `output/test/` 目录中的代码覆盖率报告。
 
-工作流上传 `dist` 目录中的生产工件，但不包括任何 Markdown 文件。 它还将 `code-coverage.html` 报表作为另一个工件上传。
+工作流上传 `dist` 目录中的生产工件，但不包括任何 Markdown 文件。它还将 `code-coverage.html` 报表作为另一个工件上传。
 
 ```yaml{:copy}
 name: Node CI
@@ -128,7 +128,7 @@ jobs:
 
 ## 配置自定义构件保留期
 
-您可以为工作流程创建的单个构件自定义保留期。 使用工作流创建新工件时，可以同时使用 `retention-days` 和 `upload-artifact` 操作。 此示例演示如何为名为 `my-artifact` 的工件设置 5 天的自定义保留期：
+您可以为工作流程创建的单个构件自定义保留期。使用工作流创建新工件时，可以同时使用 `retention-days` 和 `upload-artifact` 操作。此示例演示如何为名为 `my-artifact` 的工件设置 5 天的自定义保留期：
 
 ```yaml{:copy}
   - name: 'Upload Artifact'
@@ -145,7 +145,7 @@ jobs:
 
 在工作流运行期间，可以使用 [`download-artifact`](https://github.com/actions/download-artifact) 操作下载以前在同一工作流运行中上传的工件。
 
-工作流程运行完成后，您可以在 {% data variables.product.prodname_dotcom %} 上或使用 REST API 下载或删除构件。 有关详细信息，请参阅“[下载工作流工件](/actions/managing-workflow-runs/downloading-workflow-artifacts)”、“[删除工作流工件](/actions/managing-workflow-runs/removing-workflow-artifacts)”和“[工件 REST API](/rest/reference/actions#artifacts)”。
+工作流程运行完成后，您可以在 {% data variables.product.prodname_dotcom %} 上或使用 REST API 下载或删除构件。有关详细信息，请参阅“[下载工作流工件](/actions/managing-workflow-runs/downloading-workflow-artifacts)”、“[删除工作流工件](/actions/managing-workflow-runs/removing-workflow-artifacts)”和“[工件 REST API](/rest/reference/actions#artifacts)”。
 
 ### 在工作流程运行期间下载构件
 
@@ -157,7 +157,7 @@ jobs:
 
 {% endnote %}
 
-指定构件的名称以下载单个构件。 如果在未指定名称的情况下上传了工件，则默认名称为 `artifact`。
+指定构件的名称以下载单个构件。如果在未指定名称的情况下上传了工件，则默认名称为 `artifact`。
 
 ```yaml
 - name: Download a single artifact
@@ -166,7 +166,7 @@ jobs:
     name: my-artifact
 ```
 
-您还可以不指定名称而下载工作流程运行中的所有构件。 如果您在处理大量构件，此功能非常有用。
+您还可以不指定名称而下载工作流程运行中的所有构件。如果您在处理大量构件，此功能非常有用。
 
 ```yaml
 - name: Download all workflow run artifacts
@@ -179,18 +179,18 @@ jobs:
 
 ## 在工作流中的作业间传递数据
 
-可以使用 `upload-artifact` 和 `download-artifact` 操作在工作流中的作业间共享数据。 此示例工作流程说明如何在相同工作流程中的任务之间传递数据。 有关详细信息，请参阅 {% ifversion fpt or ghec %}[actions/upload-artifact](https://github.com/actions/upload-artifact) 和 [download-artifact](https://github.com/actions/download-artifact) 操作{% else %} {% data variables.product.product_location %} 上的 `actions/upload-artifact` 和 `download-artifact` 操作{% endif %}。
+可以使用 `upload-artifact` 和 `download-artifact` 操作在工作流中的作业间共享数据。此示例工作流程说明如何在相同工作流程中的任务之间传递数据。有关详细信息，请参阅 {% ifversion fpt or ghec %}[actions/upload-artifact](https://github.com/actions/upload-artifact) 和 [download-artifact](https://github.com/actions/download-artifact) 操作{% else %} {% data variables.product.product_location %} 上的 `actions/upload-artifact` 和 `download-artifact` 操作{% endif %}。
 
-依赖于以前作业构件的作业必须等待依赖项成功完成。 此工作流使用 `needs` 密钥来确保 `job_1`、`job_2` 和 `job_3` 按顺序运行。 例如，`job_2` 需要 `job_1`，方法是使用 `needs: job_1` 语法。
+依赖于以前作业构件的作业必须等待依赖项成功完成。此工作流使用 `needs` 密钥来确保 `job_1`、`job_2` 和 `job_3` 按顺序运行。例如，`job_2` 需要 `job_1`，方法是使用 `needs: job_1` 语法。
 
-作业1执行以下步骤：
+作业 1 执行以下步骤：
 - 执行数学计算并将结果保存到名为 `math-homework.txt` 的文本文件。
 - 使用 `upload-artifact` 操作上传工件名称为 `homework` 的 `math-homework.txt` 文件。
 
 作业 2 使用上一个作业的结果：
-- 下载在上一作业中上传的 `homework` 工件。 默认情况下，`download-artifact` 操作会将工件下载到该步骤执行的工作区目录中。 可以使用 `path` 输入参数指定不同的下载目录。
+- 下载在上一作业中上传的 `homework` 工件。默认情况下，`download-artifact` 操作会将工件下载到该步骤执行的工作区目录中。可以使用 `path` 输入参数指定不同的下载目录。
 - 读取 `math-homework.txt` 文件中的值，执行数学计算，并再次将结果保存到 `math-homework.txt`，覆盖其内容。
-- 上传 `math-homework.txt` 文件。 此上传会覆盖之前上传的构件，因为它们共用同一名称。
+- 上传 `math-homework.txt` 文件。此上传会覆盖之前上传的构件，因为它们共用同一名称。
 
 作业 3 显示上一个作业中上传的结果：
 - 下载 `homework` 工件。
@@ -252,7 +252,7 @@ jobs:
           echo The result is $value
 ```
 
-工作流程运行运行将会存档它生成的任何构件。 有关下载已存档工件的详细信息，请参阅“[下载工作流工件](/actions/managing-workflow-runs/downloading-workflow-artifacts)”。
+工作流程运行运行将会存档它生成的任何构件。有关下载已存档工件的详细信息，请参阅“[下载工作流工件](/actions/managing-workflow-runs/downloading-workflow-artifacts)”。
 ![在作业间传递数据以执行数学运算的工作流](/assets/images/help/repository/passing-data-between-jobs-in-a-workflow-updated.png)
 
 {% ifversion fpt or ghec %}
diff --git a/translations/zh-CN/content/actions/using-workflows/using-github-cli-in-workflows.md b/translations/zh-CN/content/actions/using-workflows/using-github-cli-in-workflows.md
index 387d834be470..c3f720bd1026 100644
--- a/translations/zh-CN/content/actions/using-workflows/using-github-cli-in-workflows.md
+++ b/translations/zh-CN/content/actions/using-workflows/using-github-cli-in-workflows.md
@@ -23,9 +23,9 @@ ms.locfileid: '145100117'
 ---
 {% data reusables.cli.cli-learn-more %}
 
-{% data variables.product.prodname_cli %} 预安装在所有 {% data variables.product.prodname_dotcom %} 托管的运行程序上。 对于使用 {% data variables.product.prodname_cli %} 的每个步骤，必须将调用 `GITHUB_TOKEN` 的环境变量设置为具有所需范围的令牌。
+{% data variables.product.prodname_cli %} 预安装在所有 {% data variables.product.prodname_dotcom %} 托管的运行程序上。对于使用 {% data variables.product.prodname_cli %} 的每个步骤，必须将调用 `GITHUB_TOKEN` 的环境变量设置为具有所需范围的令牌。
 
-可以执行任何 {% data variables.product.prodname_cli %} 命令。 例如，此工作流使用 `gh issue comment` 子命令在打开问题时添加注释。
+可以执行任何 {% data variables.product.prodname_cli %} 命令。例如，此工作流使用 `gh issue comment` 子命令在打开问题时添加注释。
 
 ```yaml{:copy}
 name: Comment when opened
@@ -43,7 +43,7 @@ jobs:
           ISSUE: {% raw %}${{ github.event.issue.html_url }}{% endraw %}
 ```
 
-还可以通过 {% data variables.product.prodname_cli %} 执行 API 调用。 例如，此工作流首先使用 `gh api` 子命令查询 GraphQL API 并分析结果。 然后，它将结果存储在可在后续步骤中访问的环境变量中。 在第二步中，它使用 `gh issue create` 子命令创建包含第一步中信息的问题。
+还可以通过 {% data variables.product.prodname_cli %} 执行 API 调用。例如，此工作流首先使用 `gh api` 子命令查询 GraphQL API 并分析结果。然后，它将结果存储在可在后续步骤中访问的环境变量中。在第二步中，它使用 `gh issue create` 子命令创建包含第一步中信息的问题。
 
 ```yaml{:copy}
 name: Report remaining open issues
diff --git a/translations/zh-CN/content/actions/using-workflows/using-starter-workflows.md b/translations/zh-CN/content/actions/using-workflows/using-starter-workflows.md
index 006e24ee4ce3..d579f1efb348 100644
--- a/translations/zh-CN/content/actions/using-workflows/using-starter-workflows.md
+++ b/translations/zh-CN/content/actions/using-workflows/using-starter-workflows.md
@@ -30,11 +30,11 @@ ms.locfileid: '146179837'
 
 ## 关于入门工作流程
 
-{% data variables.product.product_name %} 为各种语言和工具提供入门工作流程。 在存储库中设置工作流程时，{% data variables.product.product_name %} 会分析存储库中的代码，并根据存储库中的语言和框架推荐工作流程。 例如，如果你使用 [Node.js](https://nodejs.org/en/)，{% data variables.product.product_name %} 将提议使用入门工作流文件来安装 Node.js 包和运行测试。{% ifversion actions-starter-template-ui %} 你可以搜索并筛选来查找相关的入门工作流。{% endif %}
+{% data variables.product.product_name %} 为各种语言和工具提供入门工作流程。在存储库中设置工作流程时，{% data variables.product.product_name %} 会分析存储库中的代码，并根据存储库中的语言和框架推荐工作流程。例如，如果你使用 [Node.js](https://nodejs.org/en/)，{% data variables.product.product_name %} 将提议使用入门工作流文件来安装 Node.js 包和运行测试。{% ifversion actions-starter-template-ui %} 你可以搜索并筛选来查找相关的入门工作流。{% endif %}
 
 {% data reusables.actions.starter-workflow-categories %}
 
-您还可以创建自己的入门工作流程以与您的组织共享。 这些入门工作流程将显示在 {% data variables.product.product_name %} 提供的入门工作流程旁边。 有关详细信息，请参阅“[为组织创建入门工作流](/actions/learn-github-actions/creating-starter-workflows-for-your-organization)”。
+您还可以创建自己的入门工作流程以与您的组织共享。这些入门工作流程将显示在 {% data variables.product.product_name %} 提供的入门工作流程旁边。有关详细信息，请参阅“[为组织创建入门工作流](/actions/learn-github-actions/creating-starter-workflows-for-your-organization)”。
 
 ## 使用入门工作流程
 
@@ -42,12 +42,12 @@ ms.locfileid: '146179837'
 
 {% data reusables.repositories.navigate-to-repo %} {% data reusables.repositories.actions-tab %}
 1. 如果存储库中已有工作流，请单击“新建工作流”。
-1. “{% ifversion actions-starter-template-ui %}选择工作流{% else %}选择工作流模板{% endif %}”页面显示了一系列推荐的入门工作流。 找到要使用的入门工作流，然后单击{% ifversion actions-starter-template-ui %}“配置”{% else %}“设置此工作流”{% endif %}。{% ifversion actions-starter-template-ui %}为帮助你找到所需的入门工作流，可以搜索关键字或按类别进行筛选。{% endif %} 
+1. “{% ifversion actions-starter-template-ui %}选择工作流{% else %}选择工作流模板{% endif %}”页面显示了一系列推荐的入门工作流。找到要使用的入门工作流，然后单击{% ifversion actions-starter-template-ui %}“配置”{% else %}“设置此工作流”{% endif %}。{% ifversion actions-starter-template-ui %}为帮助你找到所需的入门工作流，可以搜索关键字或按类别进行筛选。{% endif %} 
 
    {% ifversion actions-starter-template-ui %}![配置此工作流](/assets/images/help/settings/actions-create-starter-workflow-updated-ui.png){% else %}![设置此工作流程](/assets/images/help/settings/actions-create-starter-workflow.png){% endif %}
-1. 如果入门工作流程包含详细说明其他设置步骤的注释，请按照下列步骤操作。 许多入门工作流程都有相应的指南。 有关详细信息，请参阅 [{% data variables.product.prodname_actions %} 指南](/actions/guides)。
-1. 某些入门工作流程使用机密。 例如，{% raw %}`${{ secrets.npm_token }}`{% endraw %}。 如果入门工作流使用机密，请将机密名称中描述的值作为机密存储在存储库中。 有关详细信息，请参阅“[加密机密](/actions/reference/encrypted-secrets)”。
-1. （可选）进行其他更改。 例如，你可能希望更改 `on` 的值，以便在工作流运行时进行更改。
+1. 如果入门工作流程包含详细说明其他设置步骤的注释，请按照下列步骤操作。许多入门工作流程都有相应的指南。有关详细信息，请参阅 [{% data variables.product.prodname_actions %} 指南](/actions/guides)。
+1. 某些入门工作流程使用机密。例如，{% raw %}`${{ secrets.npm_token }}`{% endraw %}。如果入门工作流使用机密，请将机密名称中描述的值作为机密存储在存储库中。有关详细信息，请参阅“[加密机密](/actions/reference/encrypted-secrets)”。
+1. （可选）进行其他更改。例如，你可能希望更改 `on` 的值，以便在工作流运行时进行更改。
 1. 单击“开始提交”。
 1. 编写提交消息并决定是直接提交到默认分支还是打开拉取请求。