New translation batch for cn (#30391)

Co-authored-by: Grace Park <gracepark@github.com>

translations/log/cn-resets.csv

@@ -203,7 +203,6 @@ translations/zh-CN/content/desktop/installing-and-configuring-github-desktop/ins
 translations/zh-CN/content/desktop/installing-and-configuring-github-desktop/installing-and-authenticating-to-github-desktop/setting-up-github-desktop.md,broken liquid tags
 translations/zh-CN/content/desktop/installing-and-configuring-github-desktop/overview/creating-your-first-repository-using-github-desktop.md,broken liquid tags
 translations/zh-CN/content/developers/apps/building-github-apps/managing-allowed-ip-addresses-for-a-github-app.md,broken liquid tags
-translations/zh-CN/content/developers/apps/building-github-apps/rate-limits-for-github-apps.md,broken liquid tags
 translations/zh-CN/content/developers/apps/getting-started-with-apps/about-apps.md,broken liquid tags
 translations/zh-CN/content/developers/apps/getting-started-with-apps/migrating-oauth-apps-to-github-apps.md,broken liquid tags
 translations/zh-CN/content/developers/github-marketplace/github-marketplace-overview/about-github-marketplace.md,broken liquid tags
@@ -289,7 +288,6 @@ translations/zh-CN/content/rest/activity/events.md,broken liquid tags
 translations/zh-CN/content/rest/apps/marketplace.md,broken liquid tags
 translations/zh-CN/content/rest/enterprise-admin/index.md,broken liquid tags
 translations/zh-CN/content/rest/guides/basics-of-authentication.md,Listed in localization-support#489
-translations/zh-CN/content/rest/guides/getting-started-with-the-checks-api.md,broken liquid tags
 translations/zh-CN/content/rest/overview/other-authentication-methods.md,Listed in localization-support#489
 translations/zh-CN/content/rest/overview/other-authentication-methods.md,broken liquid tags
 translations/zh-CN/content/rest/overview/resources-in-the-rest-api.md,Listed in localization-support#489
@@ -401,9 +399,9 @@ translations/zh-CN/data/reusables/package_registry/packages-cluster-support.md,b
 translations/zh-CN/data/reusables/repositories/deleted_forks_from_private_repositories_warning.md,broken liquid tags
 translations/zh-CN/data/reusables/repositories/enable-security-alerts.md,broken liquid tags
 translations/zh-CN/data/reusables/repositories/select-marketplace-apps.md,broken liquid tags
-translations/zh-CN/data/reusables/saml/saml-session-oauth.md,broken liquid tags
+translations/zh-CN/data/reusables/saml/saml-session-oauth.md,rendering error
 translations/zh-CN/data/reusables/saml/you-must-periodically-authenticate.md,Listed in localization-support#489
-translations/zh-CN/data/reusables/saml/you-must-periodically-authenticate.md,broken liquid tags
+translations/zh-CN/data/reusables/saml/you-must-periodically-authenticate.md,rendering error
 translations/zh-CN/data/reusables/scim/after-you-configure-saml.md,broken liquid tags
 translations/zh-CN/data/reusables/secret-scanning/enterprise-enable-secret-scanning.md,broken liquid tags
 translations/zh-CN/data/reusables/secret-scanning/partner-program-link.md,broken liquid tags

translations/zh-CN/content/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect.md

@@ -147,11 +147,11 @@ OIDC 令牌还包括其他标准声明：
 
 在云角色/资源上设置条件以限定其对 GitHub 工作流程的访问范围时，受众和主题声明通常结合使用。
 - **受众**：默认情况下，此值使用组织或存储库所有者的 URL。 这可用于设置只有特定组织中的工作流程才能访问云角色的条件。
-- **主题**：具有预定义的格式，并且是有关工作流程的某些关键元数据的串联，如 {% data variables.product.prodname_dotcom %} 组织、存储库、分支或关联的[`作业`](/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idenvironment)环境。 请参阅“[示例主题声明](#example-subject-claims)”，了解如何从串联的元数据汇编主题声明。
+- **Subject**: By default, has a predefined format and is a concatenation of some of the key metadata about the workflow, such as the {% data variables.product.prodname_dotcom %} organization, repository, branch, or associated [`job`](/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idenvironment) environment. 请参阅“[示例主题声明](#example-subject-claims)”，了解如何从串联的元数据汇编主题声明。
 
-OIDC 令牌中还支持许多其他声明，这些声明也可用于设置这些条件。
+If you need more granular trust conditions, you can customize the issuer (`iss`) and subject (`sub`) claims that are included with the JWT. For more information, see "[Customizing the token claims](#customizing-the-token-claims)".
 
-此外，云提供商可以允许你为访问令牌分配角色，从而允许你指定更精细的权限。
+There are also many additional claims supported in the OIDC token that can be used for setting these conditions. 此外，云提供商可以允许你为访问令牌分配角色，从而允许你指定更精细的权限。
 
 {% note %}
 
@@ -245,9 +245,13 @@ curl -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" "$ACTIONS_ID_TOK
 {% ifversion actions-oidc-hardening-config %}
 ## Customizing the token claims
 
-You can security harden your OIDC configuration by customizing the claims that are included with the JWT. This allows your cloud provider to apply more granular trust conditions when determining whether to grant access to its resources. For example, {% ifversion ghec %}you can customize the issuer (`iss`) claim to only allow access from a specific enterprise URL, and {% endif %}you can customize the subject (`sub`) value to require that requests originate from a specific repository, reusable workflow, or other source.
+You can security harden your OIDC configuration by customizing the claims that are included with the JWT. These customisations allow you to define more granular trust conditions on your cloud roles when allowing your workflows to access resources hosted in the cloud:
 
-To configure the claim conditions on {% data variables.product.prodname_dotcom %}, you can use the REST API endpoints described in the following sections.
+{% ifversion ghec %} - For an additional layer of security, you can append the `issuer` url with your enterprise slug. This lets you set conditions on the issuer (`iss`) claim, configuring it to only accept JWT tokens from a unique `issuer` URL that must include your enterprise slug.{% endif %}
+- You can standardize your OIDC configuration by setting conditions on the subject (`sub`) claim that require JWT tokens to originate from a specific repository, reusable workflow, or other source.
+- You can define granular OIDC policies by using additional OIDC token claims, such as `repository_id` and `repo_visibility`. For more information, see "[Understanding the OIDC token](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#understanding-the-oidc-token)".
+
+To customize these claim formats, organization and repository admins can use the REST API endpoints described in the following sections.
 
 {% ifversion ghec %}
 
@@ -282,19 +286,21 @@ After this setting is applied, the JWT will contain the updated `iss` value. In
 
 To configure organization-wide security, compliance, and standardization, you can customize the standard claims to suit your required access conditions. If your cloud provider supports conditions on subject claims, you can create a condition that checks whether the `sub` value matches the path of the reusable workflow, such as `"job_workflow_ref: "octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main""`. The exact format will vary depending on your cloud provider's OIDC configuration. To configure the matching condition on {% data variables.product.prodname_dotcom %}, you can can use the REST API to require that the `sub` claim must always include a specific custom claim, such as `job_workflow_ref`. For more information, see "[Set the customization template for an OIDC subject claim for an organization](/rest/actions/oidc#set-the-customization-template-for-an-oidc-subject-claim-for-an-organization)."
 
+Customizing the claims results in a new format for the entire `sub` claim, which replaces the default predefined `sub` format in the token described in "[Example subject claims](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#example-subject-claims)."
+
 The following example templates demonstrate various ways to customize the subject claim. To configure these settings on {% data variables.product.prodname_dotcom %}, organization admins use the REST API to specify a list of claims that must be included in the subject (`sub`) claim. {% data reusables.actions.use-request-body-api %}
 
-To customize your subject claims, you should first create a matching condition in your cloud provider's OIDC configuration, before adding the configuration using the REST API. Once the configuration is completed, each time a new job runs, the OIDC token generated during that job will follow the new customization template. If the matching condition doesn't exist in the cloud provider's OIDC configuration before the job runs, the generated token might not be accepted by the cloud provider, since the cloud conditions may not be synchronized.
+To customize your subject claims, you should first create a matching condition in your cloud provider's OIDC configuration, before customizing the configuration using the REST API. Once the configuration is completed, each time a new job runs, the OIDC token generated during that job will follow the new customization template. If the matching condition doesn't exist in the cloud provider's OIDC configuration before the job runs, the generated token might not be accepted by the cloud provider, since the cloud conditions may not be synchronized.
 
 {% note %}
 
-**Note**: When the organization template is applied, it will not affect any existing repositories that already use OIDC. For new repositories that are created after the template has been applied, the repository owner will need to opt-in to receive this configuration. For more information, see "[Set the opt-in flag of an OIDC subject claim customization for a repository](/rest/actions/oidc#set-the-opt-in-flag-of-an-oidc-subject-claim-customization-for-a-repository)."
+**Note**: When the organization template is applied, it will not affect any existing repositories that already use OIDC. For existing repositories, as well as any new repositories that are created after the template has been applied, the repository owner will need to opt-in to receive this configuration. For more information, see "[Set the opt-in flag of an OIDC subject claim customization for a repository](/rest/actions/oidc#set-the-opt-in-flag-of-an-oidc-subject-claim-customization-for-a-repository)."
 
 {% endnote %}
 
 #### Example: Allowing repository based on visibility and owner
 
-This example template enables cloud access based on repository visibility and owner, letting you restrict cloud role access to only private repositories within an organization or enterprise. {% data reusables.actions.use-request-body-api %}
+This example template allows the `sub` claim to have a new format, using `repository_owner` and `repository_visibility`:
 
 ```json
 {
@@ -305,11 +311,11 @@ This example template enables cloud access based on repository visibility and ow
 }
 ```
 
-In your cloud provider's OIDC configuration, configure the `sub` condition to require that claims must include specific values for `repository_owner` and `repository_visibility`. For example: `"repository_owner: "monalisa":repository_visibility:private"`.
+In your cloud provider's OIDC configuration, configure the `sub` condition to require that claims must include specific values for `repository_owner` and `repository_visibility`. For example: `"repository_owner: "monalisa":repository_visibility:private"`. The approach lets you restrict cloud role access to only private repositories within an organization or enterprise.
 
 #### Example: Allowing access to all repositories with a specific owner
 
-This example template grants access to all repositories with a specified `repository_owner`. {% data reusables.actions.use-request-body-api %}
+This example template enables the `sub` claim to have a new format with only the value of `repository_owner`. {% data reusables.actions.use-request-body-api %}
 
 ```json
 {
@@ -324,7 +330,9 @@ In your cloud provider's OIDC configuration, configure the `sub` condition to re
 
 #### Example: Requiring a reusable workflow
 
-This example template requires a specific reusable workflow in a claim, letting an enterprise enforce consistent deployments across its enterprise, organizations, and repositories. {% data reusables.actions.use-request-body-api %}
+This example template allows the `sub` claim to have a new format that contains the value of the `job_workflow_ref` claim. This enables an enterprise to use [reusable workflows](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#example-subject-claims) to enforce consistent deployments across its organizations and repositories.
+
+{% data reusables.actions.use-request-body-api %}
 
 ```json
   {
@@ -338,7 +346,9 @@ In your cloud provider's OIDC configuration, configure the `sub` condition to re
 
 #### Example: Requiring a reusable workflow and other claims
 
-This example template combines the requirement of a specific reusable workflow with additional claims. {% data reusables.actions.use-request-body-api %}
+The following example template combines the requirement of a specific reusable workflow with additional claims. {% data reusables.actions.use-request-body-api %}
+
+This example also demonstrates how to use `"context"` to define your conditions. This is the part that follows the repository in the [default `sub` format](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#example-subject-claims). For example, when the job references an environment, the context contains: `environment:<environmentName>`.
 
 ```json
 {
@@ -352,6 +362,8 @@ This example template combines the requirement of a specific reusable workflow w
 
 In your cloud provider's OIDC configuration, configure the `sub` condition to require that claims must include specific values for `repo`, `context`, and `job_workflow_ref`.
 
+This customization template requires that the `sub` uses the following format: `repo:<orgName/repoName>:environment:<environmentName>:job_workflow_ref:<reusableWorkflowPath>`. For example: `"sub": "repo:octo-org/octo-repo:environment:prod:job_workflow_ref:octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main"`
+
 #### Example: Granting access to a specific repository
 
 This example template lets you grant cloud access to all the workflows in a specific repository, across all branches/tags and environments. To help improve security, combine this template with the custom issuer URL described in "[Customizing the token URL for an enterprise](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#customizing-the-token-url-for-an-enterprise)."

translations/zh-CN/content/actions/deployment/security-hardening-your-deployments/using-openid-connect-with-reusable-workflows.md

@@ -23,11 +23,18 @@ topics:
 
 您可以创建一个可重用的工作流程来执行部署步骤，而不是将部署作业从一个工作流程复制并粘贴到另一个工作流程。 如果可重用工作流程满足“[重用工作流](/actions/learn-github-actions/reusing-workflows#access-to-reusable-workflows)”中所述的访问要求之一，则可以由另一个工作流程使用。
 
-与 OpenID Connect (OIDC) 结合使用时，可重用工作流程可让您在存储库、组织或企业中实施一致的部署。 为此，可以基于可重用工作流程在云角色上定义信任条件。
+You should be familiar with the concepts described in "\[Reusing workflows\](/actions/learn-github-actions/reusing-workflows" and "[About security hardening with OpenID Connect](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect)."
 
-为了创建基于可重用工作流程的信任条件，云提供商必须支持 `job_workflow_ref` 的自定义声明。 这允许您的云提供商确定作业最初来自哪个存储库。 如果您的云提供商仅支持标准声明（_受众_和_主题_），则无法确定作业是否源自可重用工作流程存储库。 支持 `job_workflow_ref` 的云提供商包括 Google Cloud Platform 和 HashiCorp Vault。
+## Defining the trust conditions
 
-在继续之前，您应该熟悉[可重用工作流程](/actions/learn-github-actions/reusing-workflows) 和 [OpenID Connect](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect) 的概念。
+与 OpenID Connect (OIDC) 结合使用时，可重用工作流程可让您在存储库、组织或企业中实施一致的部署。 为此，可以基于可重用工作流程在云角色上定义信任条件。 The available options will vary depending on your cloud provider:
+
+- **Using `job_workflow_ref`**:
+  - To create trust conditions based on reusable workflows, your cloud provider must support custom claims for `job_workflow_ref`. 这允许您的云提供商确定作业最初来自哪个存储库。
+  - For clouds that only support the standard claims (audience (`aud`) and subject (`sub`)), you can use the API to customize the `sub` claim to include `job_workflow_ref`. For more information, see "[Customizing the token claims](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#customizing-the-token-claims)". Support for custom claims is currently available for Google Cloud Platform and HashiCorp Vault.
+
+- **Customizing the token claims**:
+  - You can configure more granular trust conditions by customizing the issuer (`iss`) and subject (`sub`) claims included with the JWT. For more information, see "[Customizing the token claims](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#customizing-the-token-claims)".
 
 ## 令牌如何与可重用工作流程配合使用
 

translations/zh-CN/content/actions/using-workflows/caching-dependencies-to-speed-up-workflows.md

@@ -51,7 +51,7 @@ miniTocMaxHeadingLevel: 3
 
 工作流程可以访问和还原当前分支、基础分支（包括复刻的仓库的基本分支）或默认分支（通常是 `main`）中创建的缓存 例如，在默认分支上创建的缓存可从任何拉取请求访问。 另外，如果分支 `feature-b` 具有基础分支 `feature-a`，则触发于 `feature-b` 的工作流程可以访问默认分支 (`main`)、`feature-a` 和 `feature-b` 中创建的缓存。
 
-访问限制通过在不同分支之间创建逻辑边界来提供缓存隔离和安全。 例如， 为分支 `feature-a`（具有基础分支 `main`）创建的缓存将无法访问分支 `feature-c`（具有基础分支 `main`）的拉取请求。
+Access restrictions provide cache isolation and security by creating a logical boundary between different branches or tags. 例如， 为分支 `feature-a`（具有基础分支 `main`）创建的缓存将无法访问分支 `feature-c`（具有基础分支 `main`）的拉取请求。 On similar lines, a cache created for the tag `release-a` (from the base `main`) would not be accessible to a workflow triggered for the tag `release-b` (with the base `main`).
 
 仓库中的多个工作流程共享缓存条目。 可以从同一仓库和分支的另一个工作流程访问和恢复为工作流程中的分支创建的缓存。
 

translations/zh-CN/content/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/streaming-the-audit-log-for-your-enterprise.md

@@ -44,7 +44,8 @@ Enterprise owners can set up{% ifversion pause-audit-log-stream %}, pause,{% end
 
 - [Amazon S3](#setting-up-streaming-to-amazon-s3)
 - [Azure Blob Storage](#setting-up-streaming-to-azure-blob-storage)
-- [Azure Event Hubs](#setting-up-streaming-to-azure-event-hubs)
+- [Azure Event Hubs](#setting-up-streaming-to-azure-event-hubs){% ifversion streaming-datadog %}
+- [Datadog](#setting-up-streaming-to-datadog){% endif %}
 - [Google Cloud Storage](#setting-up-streaming-to-google-cloud-storage)
 - [Splunk](#setting-up-streaming-to-splunk)
 
@@ -231,6 +232,32 @@ Then, set up streaming with access keys until the vulnerability is resolved. For
 
 {% data reusables.enterprise.verify-audit-log-streaming-endpoint %}
 
+{% ifversion streaming-datadog %}
+### Setting up streaming to Datadog
+
+To set up streaming to Datadog, you must create a client token or an  API key in Datadog, then configure audit log streaming in {% data variables.product.product_name %} using the token for authentication. You do not need to create a bucket or other storage container in Datadog.
+
+After you set up streaming to Datadog, you can see your audit log data by filtering by "github.audit.streaming." For more information, see [Log Management](https://docs.datadoghq.com/logs/).
+
+1. If you don't already have a Datadog account, create one.
+1. In Datadog, generate a client token or an API key, then click **Copy key**. For more information, see [API and Application Keys](https://docs.datadoghq.com/account_management/api-app-keys/) in Datadog Docs.
+{% data reusables.enterprise.navigate-to-log-streaming-tab %}
+1. Select the **Configure stream** dropdown menu and click **Datadog**.
+
+   ![Screenshot of the "Configure stream" dropdown menu with "Datadog" highlighted](/assets/images/help/enterprises/audit-stream-choice-datadog.png)
+1. Under "Token", paste the token  you copied earlier.
+
+   ![Screenshot of the "Token" field](/assets/images/help/enterprises/audit-stream-datadog-token.png)
+1. Select the "Site" dropdown menu and click your Datadog site. To determine your Datadog site, compare your Datadog URL to the table in [Datadog sites](https://docs.datadoghq.com/getting_started/site/) in Datadog Docs.
+
+   ![Screenshot of the "Site" dropdown menu](/assets/images/help/enterprises/audit-stream-datadog-site.png)
+1. To verify that {% data variables.product.prodname_dotcom %} can connect and write to the Datadog endpoint, click **Check endpoint**.
+
+   ![检查端点](/assets/images/help/enterprises/audit-stream-check.png)
+{% data reusables.enterprise.verify-audit-log-streaming-endpoint %}
+1. After a few minutes, confirm that audit log data is appearing on the **Logs** tab in Datadog. If audit log data is not appearing, confirm that your token and site are correct in {% data variables.product.prodname_dotcom %}.
+{% endif %}
+
 ### 设置流式传输到 Google Cloud Storage
 
 要设置流式传输到 Google Cloud Storage，您必须在 Google Cloud 中使用适当的凭据和权限创建一个服务帐户，然后使用服务帐户的凭据在 {% data variables.product.product_name %} 中配置审核日志流以进行身份验证。
@@ -291,6 +318,10 @@ Then, set up streaming with access keys until the vulnerability is resolved. For
 
 暂停流允许您对接收应用程序执行维护，而不会丢失审核数据。 审核日志在 {% data variables.product.product_location %} 上最多存储七天，然后在取消暂停流时导出。
 
+{% ifversion streaming-datadog %}
+Datadog only accepts logs from up to 18 hours in the past. If you pause a stream to a Datadog endpoint for more than 18 hours, you risk losing logs that Datadog won't accept after you resume streaming.
+{% endif %}
+
 {% data reusables.enterprise.navigate-to-log-streaming-tab %}
 1. 单击 **Pause stream（暂停流）**。
 

translations/zh-CN/content/authentication/managing-commit-signature-verification/generating-a-new-gpg-key.md

@@ -53,7 +53,7 @@ topics:
 {% data reusables.gpg.copy-gpg-key-id %}
 10. 粘贴下面的文本（替换为您要使用的 GPG 密钥 ID）。 在此例中，GPG 密钥 ID 是 `3AA5C34371567BD2`：
  ```shell{:copy}
- $ gpg --armor --export <em>3AA5C34371567BD2</em>
+ $ gpg --armor --export 3AA5C34371567BD2
  # Prints the GPG key ID, in ASCII armor format
  ```
 11. 复制 GPG 密钥，从 `-----BEGIN PGP PUBLIC KEY BLOCK-----` 开始，到 `-----END PGP PUBLIC KEY BLOCK-----` 结束。

translations/zh-CN/content/code-security/code-scanning/integrating-with-code-scanning/sarif-support-for-code-scanning.md

@@ -83,6 +83,12 @@ You can check a SARIF file is compatible with {% data variables.product.prodname
 
 If you use a code analysis engine other than {% data variables.product.prodname_codeql %}, you can review the supported SARIF properties to optimize how your analysis results will appear on {% data variables.product.prodname_dotcom %}.
 
+{% note %}
+
+**Note:** You must supply an explicit value for any property marked as "required". The empty string is not supported for required properties.
+
+{% endnote %}
+
 Any valid SARIF 2.1.0 output file can be uploaded, however, {% data variables.product.prodname_code_scanning %} will only use the following supported properties.
 
 ### `sarifLog` object
@@ -210,7 +216,7 @@ These example SARIF output files show supported properties and example values.
 
 ### Example with minimum required properties
 
-This SARIF output file has example values to show the minimum required properties for {% data variables.product.prodname_code_scanning %} results to work as expected. If you remove any properties or don't include values, this data will not be displayed correctly or sync on {% data variables.product.prodname_dotcom %}.
+This SARIF output file has example values to show the minimum required properties for {% data variables.product.prodname_code_scanning %} results to work as expected. If you remove any properties, omit values, or use an empty string, this data will not be displayed correctly or sync on {% data variables.product.prodname_dotcom %}. 
 
 ```json
 {

translations/zh-CN/content/developers/apps/building-github-apps/rate-limits-for-github-apps.md

@@ -1,5 +1,5 @@
 ---
-title: Rate limits for GitHub Apps
+title: GitHub 应用程序的速率限制
 intro: '{% data reusables.shortdesc.rate_limits_github_apps %}'
 redirect_from:
   - /early-access/integrations/rate-limits
@@ -14,7 +14,7 @@ versions:
   ghec: '*'
 topics:
   - GitHub Apps
-shortTitle: Rate limits
+shortTitle: 速率限制
 ---
 
 {% data reusables.enterprise.rate_limit %}
@@ -23,49 +23,49 @@ shortTitle: Rate limits
 
 {% ifversion ghec or fpt %}
 
-## About rate limits for apps
+## 关于应用程序的速率限制
 
-Rate limits for {% data variables.product.prodname_github_apps %} and {% data variables.product.prodname_oauth_apps %} depend on the plan for the organization where you install the application. For more information, see "[{% data variables.product.company_short %}'s products](/get-started/learning-about-github/githubs-products)" and "[Types of {% data variables.product.company_short %} accounts](/get-started/learning-about-github/types-of-github-accounts#organization-accounts)."
+{% data variables.product.prodname_github_apps %} 和 {% data variables.product.prodname_oauth_apps %} 的速率限制取决于安装应用程序的组织的计划。 更多信息请参阅“[{% data variables.product.company_short %} 的产品](/get-started/learning-about-github/githubs-products)”和“[{% data variables.product.company_short %} 帐户类型](/get-started/learning-about-github/types-of-github-accounts#organization-accounts)”。
 
 {% endif %}
 
-## Server-to-server requests
+## 服务器到服务器请求
 
 {% ifversion ghec or fpt %}
 
-### Default server-to-server rate limits for {% data variables.product.prodname_dotcom_the_website %}
+### {% data variables.product.prodname_dotcom_the_website %} 的默认服务器到服务器速率限制
 
 {% endif %}
 
-{% data variables.product.prodname_github_apps %} making server-to-server requests use the installation's minimum rate limit of 5,000 requests per hour. If an application is installed on an organization with more than 20 users, the application receives another 50 requests per hour for each user. Installations that have more than 20 repositories receive another 50 requests per hour for each repository. The maximum rate limit for an installation is 12,500 requests per hour.
+发出服务器-服务器请求的 {% data variables.product.prodname_github_apps %} 使用安装的最低速率限制为每小时 5,000 个请求。 如果应用程序安装在具有 20 个以上用户的组织中，则该应用程序每小时为每个用户再接收 50 个请求。 具有 20 个以上仓库的安装每小时会为每个仓库再接收 50 个请求。 安装的最大速率限制为每小时 12,500 个请求。
 
 {% ifversion fpt or ghec %}
 
-### Server-to-server rate limits for {% data variables.product.prodname_ghe_cloud %}
+### {% data variables.product.prodname_ghe_cloud %} 的服务器到服务器速率限制
 
 {% endif %}
 
 {% ifversion fpt or ghec %}
 
-{% data variables.product.prodname_github_apps %} that are installed on an organization or a repository within an enterprise on {% data variables.product.product_location %} are subject to a limit of 15,000 requests per hour.
+{% data variables.product.prodname_github_apps %} that are installed on an organization within an enterprise on {% data variables.product.product_location %} are subject to a limit of 15,000 requests per hour per organization that has installed the app.
 
 {% endif %}
 
-## User-to-server requests
+## 用户到服务器请求
 
-{% data variables.product.prodname_github_apps %} and {% data variables.product.prodname_oauth_apps %} can also act on behalf of a user, making user-to-server requests after the user authorizes the app. For more information, see "[Authorizing {% data variables.product.prodname_github_apps %}](/authentication/keeping-your-account-and-data-secure/authorizing-github-apps)" and "[Authorizing {% data variables.product.prodname_oauth_apps %}](/authentication/keeping-your-account-and-data-secure/authorizing-oauth-apps)."
+{% data variables.product.prodname_github_apps %} 和 {% data variables.product.prodname_oauth_apps %} 还可以代表用户执行操作，在用户授权应用后发出用户到服务器的请求。 更多信息请参阅“[授权 {% data variables.product.prodname_github_apps %}](/authentication/keeping-your-account-and-data-secure/authorizing-github-apps)”和“[授权 {% data variables.product.prodname_oauth_apps %}](/authentication/keeping-your-account-and-data-secure/authorizing-oauth-apps)”。
 
-User-to-server requests from {% data variables.product.prodname_oauth_apps %} are authenticated with an OAuth token. User-to-server requests from {% data variables.product.prodname_github_apps %} are authenticated with either an OAuth token or an expiring user access token. For more information, see "[Identifying and authorizing users for {% data variables.product.prodname_github_apps %}](/developers/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#identifying-and-authorizing-users-for-github-apps)" and "[Authorizing {% data variables.product.prodname_oauth_apps %}](/developers/apps/building-oauth-apps/authorizing-oauth-apps)."
+来自 {% data variables.product.prodname_oauth_apps %} 的用户到服务器请求使用 OAuth 令牌进行身份验证。 来自 {% data variables.product.prodname_github_apps %} 的用户到服务器请求使用 OAuth 令牌或即将过期的用户访问令牌进行身份验证。 更多信息请参阅“[识别和授权 {% data variables.product.prodname_github_apps %} 的用户](/developers/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#identifying-and-authorizing-users-for-github-apps)”和“[授权 {% data variables.product.prodname_oauth_apps %}](/developers/apps/building-oauth-apps/authorizing-oauth-apps)”。
 
 {% ifversion fpt or ghec %}
 
-### Default user-to-server rate limits for {% data variables.product.prodname_dotcom_the_website %}
+### {% data variables.product.prodname_dotcom_the_website %} 的默认用户到服务器速率限制
 
 {% endif %}
 
 {% ifversion ghec %}
 
-The rate limits for user-to-server requests made by {% data variables.product.prodname_github_apps %} depend on where the app is installed. If the app is installed on organizations or repositories owned by an enterprise on {% data variables.product.product_location %}, then the rate is higher than for installations outside an enterprise.
+{% data variables.product.prodname_github_apps %} 发出的用户到服务器请求的速率限制取决于应用程序的安装位置。 如果应用程序安装在 {% data variables.product.product_location %} 上由企业拥有的组织或存储库上，则速率高于企业外部的安装。
 
 {% endif %}
 
@@ -73,13 +73,13 @@ The rate limits for user-to-server requests made by {% data variables.product.pr
 
 {% ifversion fpt or ghec %}
 
-### User-to-server rate limits for {% data variables.product.prodname_ghe_cloud %}
+### {% data variables.product.prodname_ghe_cloud %} 的用户到服务器速率限制
 
 {% data reusables.apps.user-to-server-rate-limits-ghec %}
 
 {% endif %}
 
-## Further reading
+## 延伸阅读
 
-- "[Rate limiting](/rest/overview/resources-in-the-rest-api#rate-limiting)" in the REST API documentation
-- "[Resource limitations](/graphql/overview/resource-limitations)" in the GraphQL API documentation
+- REST API 文档中的“[速率限制](/rest/overview/resources-in-the-rest-api#rate-limiting)”
+- GraphQL API 文档中的“[资源限制](/graphql/overview/resource-limitations)”

translations/zh-CN/content/issues/tracking-your-work-with-issues/transferring-an-issue-to-another-repository.md

@@ -24,7 +24,7 @@ shortTitle: 转移议题
 
 {% endnote %}
 
-转让议题时，评论、标签和受理人将保留。 不会保留议题的里程碑。 此议题将留在任何用户拥有或组织范围的项目板上，并从任何仓库项目板中删除。 更多信息请参阅“[关于项目板](/articles/about-project-boards)”。
+转让议题时，评论和受理人将保留。 Labels and milestones are also retained if they're present in the target repository, with labels matching by name and milestones matching by both name and due date. 此议题将留在任何用户拥有或组织范围的项目板上，并从任何仓库项目板中删除。 更多信息请参阅“[关于项目板](/articles/about-project-boards)”。
 
 议题中提及的人员或团队将收到通知，告知他们该议题已转让给新仓库。 原来的 URL 会重定向到新议题的 URL。 在新仓库中没有读取权限的人员将看到一个横幅，告知他们该议题已转让给他们无法访问的新仓库。
 

translations/zh-CN/content/organizations/managing-organization-settings/enabling-or-disabling-github-discussions-for-an-organization.md

@@ -1,6 +1,6 @@
 ---
 title: 为组织启用或禁用 GitHub 讨论
-intro: '您可以使用组织中的 {% data variables.product.prodname_discussions %} 作为组织进行对话的位置，这些对话不特定于组织中的单个存储库。'
+intro: 'You can use {% data variables.product.prodname_discussions %} in an organization as a place for your organization to have conversations that aren''t specific to a single repository within your organization.'
 permissions: 'Organization owners can enable {% data variables.product.prodname_discussions %} for their organization.'
 versions:
   feature: discussions

translations/zh-CN/content/pages/configuring-a-custom-domain-for-your-github-pages-site/managing-a-custom-domain-for-your-github-pages-site.md

@@ -46,7 +46,7 @@ To set up a `www` or custom subdomain, such as `www.example.com` or `blog.exampl
 {% data reusables.repositories.sidebar-settings %}
 {% data reusables.pages.sidebar-pages %}
 4. 在 "Custom domain（自定义域）"下，输入自定义域，然后单击 **Save（保存）**。 If you are publishing your site from a branch, this will create a commit that adds a `CNAME` file to the root of your source branch. If you are publishing your site with a custom {% data variables.product.prodname_actions %} workflow , no `CNAME` file is created. For more information about your publishing source, see "[Configuring a publishing source for your GitHub Pages site](/pages/getting-started-with-github-pages/configuring-a-publishing-source-for-your-github-pages-site)." ![保存自定义域按钮](/assets/images/help/pages/save-custom-subdomain.png)
-5. 导航到您的 DNS 提供程序并创建 `CNAME` 记录，使子域指向您站点的默认域。 例如，如果要对您的用户站点使用子域 `www.example.com`，您可以创建 `CNAME` 记录，使 `www.example.com` 指向 `<user>.github.io`。 如果要对您的组织站点使用子域 `www.anotherexample.com`，您可以创建 `CNAME` 记录，使 `www.anotherexample.com` 指向 `<organization>.github.io`。 `CNAME` 记录应该始终指向 `<user>.github.io` 或 `<organization>.github.io`，不包括仓库名称。 {% data reusables.pages.contact-dns-provider %} {% data reusables.pages.default-domain-information %}
+5. 导航到您的 DNS 提供程序并创建 `CNAME` 记录，使子域指向您站点的默认域。 例如，如果要对您的用户站点使用子域 `www.example.com`，您可以创建 `CNAME` 记录，使 `www.example.com` 指向 `<user>.github.io`。 如果要对您的组织站点使用子域 `another.example.com`，您可以创建 `CNAME` 记录，使 `another.example.com` 指向 `<organization>.github.io`。 `CNAME` 记录应该始终指向 `<user>.github.io` 或 `<organization>.github.io`，不包括仓库名称。 {% data reusables.pages.contact-dns-provider %} {% data reusables.pages.default-domain-information %}
 
 {% indented_data_reference reusables.pages.wildcard-dns-warning spaces=3 %}
 {% data reusables.command_line.open_the_multi_os_terminal %}

translations/zh-CN/content/rest/guides/getting-started-with-the-checks-api.md

@@ -1,6 +1,6 @@
 ---
-title: Getting started with the Checks API
-intro: 'The Check Runs API enables you to build GitHub Apps that run powerful checks against code changes in a repository. You can create apps that perform continuous integration, code linting, or code scanning services and provide detailed feedback on commits.'
+title: 检查 API 入门指南
+intro: 检查运行 API 使您能够构建 GitHub 应用程序，以针对仓库中的代码更改运行强大的检查。 您可以创建应用程序以执行持续集成 、代码分析或代码扫描服务，并提供有关提交的详细反馈。
 versions:
   fpt: '*'
   ghes: '*'
@@ -8,58 +8,58 @@ versions:
   ghec: '*'
 topics:
   - API
-shortTitle: Get started - Checks API
+shortTitle: 开始 - 检查 API
 ---
 
-## Overview
+## 概览
 
-Rather than binary pass/fail build statuses, GitHub Apps can report rich statuses, annotate lines of code with detailed information, and re-run tests. The Checks API functionality is available exclusively to your GitHub Apps.
+GitHub 应用程序可以报告丰富的状态信息、提供详细的代码行注释以及重新运行测试，而不是提供二进制的通过/失败构建状态。 Checks API 功能专用于您的 GitHub 应用程序。
 
-For an example of how to use the Checks API with a {% data variables.product.prodname_github_app %}, see "[Creating CI tests with the Checks API](/apps/quickstart-guides/creating-ci-tests-with-the-checks-api/)."
+关于如何将检查 API 用于 {% data variables.product.prodname_github_app %} 的示例，请参阅“[使用检查 API 创建 CI 测试](/apps/quickstart-guides/creating-ci-tests-with-the-checks-api/)”。
 
-## About check suites
+## 关于检查套件
 
-When someone pushes code to a repository, GitHub creates a check suite for the last commit. A check suite is a collection of the [check runs](/rest/reference/checks#check-runs) created by a single GitHub App for a specific commit. Check suites summarize the status and conclusion of the check runs that a suite includes.
+当有人向仓库推送代码时，GitHub 会为最新的提交创建一个检查套件。 检查套件是单个 GitHub 应用程序为特定提交而创建的[检查运行](/rest/reference/checks#check-runs)的集合。 检查套件汇总了套件所含检查运行的状态和结论。
 
-![Check suites workflow](/assets/images/check_suites.png)
+![检查套件工作流程](/assets/images/check_suites.png)
 
-The check suite reports the highest priority check run `conclusion` in the check suite's `conclusion`. For example, if three check runs have conclusions of `timed_out`, `success`, and `neutral` the check suite conclusion will be `timed_out`.
+检查套件在其 `conclusion` 中报告优先级最高的检查运行 `conclusion` 。 例如，如果三个检查运行的结论分别为 `timed_out`、`success` 和 `neutral`，则检查套件的结论将为 `timed_out`。
 
-By default, GitHub creates a check suite automatically when code is pushed to the repository. This default flow sends the `check_suite` event (with `requested` action) to all GitHub App's that have the `checks:write` permission. When your GitHub App receives the `check_suite` event, it can create new check runs for the latest commit. GitHub automatically adds new check runs to the correct [check suite](/rest/reference/checks#check-suites) based on the check run's repository and SHA.
+默认情况下，当代码被推送到仓库时，GitHub 会自动创建一个检查套件。 此默认流程会将 `check_suite` 事件（使用 `requested` 操作）发送到具有 `checks:write` 权限的所有 GitHub 应用程序。 当您的 GitHub 应用程序收到 `check_suite` 事件时，它可以为最新的提交创建新的检查运行。 GitHub 根据检查运行的仓库和 SHA，自动将新的检查运行添加到适当的[检查套件](/rest/reference/checks#check-suites)中。
 
-If you don't want to use the default automatic flow, you can control when you create check suites. To change the default settings for the creation of check suites, use the [Update repository preferences for check suites](/rest/reference/checks#update-repository-preferences-for-check-suites) endpoint. All changes to the automatic flow settings are recorded in the audit log for the repository. If you have disabled the automatic flow, you can create a check suite using the [Create a check suite](/rest/reference/checks#create-a-check-suite) endpoint. You should continue to use the [Create a check run](/rest/reference/checks#create-a-check-run) endpoint to provide feedback on a commit.
+如果您不想使用默认的自动流程，您可以控制何时创建检查套件。 要更改用于创建检查套件的默认设置，请使用[更新检查套件的仓库首选项](/rest/reference/checks#update-repository-preferences-for-check-suites)端点。 对自动流程设置的所有更改都被记录在仓库的审核日志中。 如果您禁用了自动流程，您可以使用[创建检查套件](/rest/reference/checks#create-a-check-suite)端点来创建一个检查套件。 您应该继续使用[创建检查运行](/rest/reference/checks#create-a-check-run)端点来提供对提交的反馈。
 
 {% data reusables.apps.checks-availability %}
 
-To use the check suites API, the GitHub App must have the `checks:write` permission and can also subscribe to the [check_suite](/webhooks/event-payloads/#check_suite) webhook.
+要使用检查套件 API，GitHub 应用程序必须具有 `checks:write` 权限并且可以订阅 [check_suite](/webhooks/event-payloads/#check_suite) web 挂钩。
 
 {% data reusables.shortdesc.authenticating_github_app %}
 
-## About check runs
+## 关于检查运行
 
-A check run is an individual test that is part of a check suite. Each run includes a status and conclusion.
+检查运行是检查套件中的单个测试。 每个运行都包含状态和结论。
 
-![Check runs workflow](/assets/images/check_runs.png)
+![检查运行工作流程](/assets/images/check_runs.png)
 
-If a check run is in a incomplete state for more than 14 days, then the check run's `conclusion` becomes `stale` and appears on {% data variables.product.prodname_dotcom %} as stale with {% octicon "issue-reopened" aria-label="The issue-reopened icon" %}. Only {% data variables.product.prodname_dotcom %} can mark check runs as `stale`. For more information about possible conclusions of a check run, see the [`conclusion` parameter](/rest/reference/checks#create-a-check-run--parameters).
+If a check run is in an incomplete state for more than 14 days, then the check run's `conclusion` becomes `stale` and appears on {% data variables.product.prodname_dotcom %} as stale with {% octicon "issue-reopened" aria-label="The issue-reopened icon" %}. 只有 {% data variables.product.prodname_dotcom %} 可以将检查运行标记为 `stale`。 有关检查运行之可能结论的更多信息，请参阅 [`conclusion` 参数](/rest/reference/checks#create-a-check-run--parameters)。
 
-As soon as you receive the [`check_suite`](/webhooks/event-payloads/#check_suite) webhook, you can create the check run, even if the check is not complete. You can update the `status` of the check run as it completes with the values `queued`, `in_progress`, or `completed`, and you can update the `output` as more details become available. A check run can contain timestamps, a link to more details on your external site, detailed annotations for specific lines of code, and information about the analysis performed.
+一旦收到 [`check_suite`](/webhooks/event-payloads/#check_suite) web 挂钩，您即可创建检查运行，即使检查尚未完成。 您可以在检查运行完成时使用值 `queued`、`in_progress` 或 `completed` 来更新其 `status`， 并且可以在更多详细信息可用时更新 `output`。 检查运行可以包含时间戳、指向外部站点上更多详细信息的链接、特定代码行的详细注释以及有关所执行分析的信息。
 
-![Check run annotation](/assets/images/check_run_annotations.png)
+![检查运行注释](/assets/images/check_run_annotations.png)
 
-A check can also be manually re-run in the GitHub UI. See "[About status checks](/articles/about-status-checks#checks)" for more details. When this occurs, the GitHub App that created the check run will receive the [`check_run`](/webhooks/event-payloads/#check_run) webhook requesting a new check run. If you create a check run without creating a check suite, GitHub creates the check suite for you automatically.
+还可以在 GitHub UI 中手动重新运行检查。 更多信息请参阅“[关于状态检查](/articles/about-status-checks#checks)”。 发生这种情况时，创建检查运行的 GitHub 应用程序将收到请求新检查运行的 [`check_run`](/webhooks/event-payloads/#check_run) web 挂钩。 如果您创建检查运行时没有创建检查套件，GitHub 将自动为您创建检查套件。
 
 {% data reusables.apps.checks-availability %}
 
-To use the Check Runs API, the GitHub App must have the `checks:write` permission and can also subscribe to the [check_run](/webhooks/event-payloads#check_run) webhook.
+要使用检查运行 API，GitHub 应用程序必须具有 `checks:write` 权限并且可以订阅 [ccheck_run](/webhooks/event-payloads#check_run) web 挂钩。
 
-## Check runs and requested actions
+## 检查运行和请求的操作
 
-When you set up a check run with requested actions (not to be confused with {% data variables.product.prodname_actions %}), you can display a button in the pull request view on {% data variables.product.prodname_dotcom %} that allows people to request your {% data variables.product.prodname_github_app %} to perform additional tasks.
+在设置带有请求操作（不要与 {% data variables.product.prodname_actions %} 混淆）的检查运行时，您可以在 {% data variables.product.prodname_dotcom %} 上的拉取请求视图中显示一个按钮，以允许用户请求您的 {% data variables.product.prodname_github_app %} 执行额外任务。
 
-For example, a code linting app could use requested actions to display a button in a pull request to automatically fix detected syntax errors.
+例如，代码分析应用程序可以使用请求的操作在拉取请求中显示一个按钮，以自动修复检测到的语法错误。
 
-To create a button that can request additional actions from your app, use the [`actions` object](/rest/reference/checks#create-a-check-run--parameters) when you [Create a check run](/rest/reference/checks/#create-a-check-run). For example, the `actions` object below displays a button in a pull request with the label "Fix this." The button appears after the check run completes.
+要创建可从您的程序请求额外操作的按钮，请在[创建检查运行](/rest/reference/checks/#create-a-check-run)时使用 [`actions` 对象](/rest/reference/checks#create-a-check-run--parameters)。 例如，下面的 `actions` 对象在拉取请求中显示一个按钮，标签为“Fix this（修复此问题）”。 该按钮在检查运行完成后显示。
 
    ```json
   "actions": [{
@@ -69,14 +69,14 @@ To create a button that can request additional actions from your app, use the [`
     }]
   ```
 
-  ![Check run requested action button](/assets/images/github-apps/github_apps_checks_fix_this_button.png)
+  ![检查运行请求操作按钮](/assets/images/github-apps/github_apps_checks_fix_this_button.png)
 
-When a user clicks the button, {% data variables.product.prodname_dotcom %} sends the [`check_run.requested_action` webhook](/webhooks/event-payloads/#check_run) to your app. When your app receives a `check_run.requested_action` webhook event, it can look for the `requested_action.identifier` key in the webhook payload to determine which button was clicked and perform the requested task.
+当用户单击该按钮时，{% data variables.product.prodname_dotcom %} 会将 [`check_run.requested_action` web 挂钩](/webhooks/event-payloads/#check_run)发送到您的应用程序。 当您的应用程序收到 `check_run.requested_action` web 挂钩事件时，它可以在 web 挂钩有效负载中查找 `requested_action.identifier` 键，以确定单击了哪个按钮，并执行请求的任务。
 
-For a detailed example of how to set up requested actions with the Checks API, see "[Creating CI tests with the Checks API](/apps/quickstart-guides/creating-ci-tests-with-the-checks-api/#part-2-creating-the-octo-rubocop-ci-test)."
+关于如何使用检查 API 设置请求操作的详细示例，请参阅“[使用检查 API 创建 CI 测试](/apps/quickstart-guides/creating-ci-tests-with-the-checks-api/#part-2-creating-the-octo-rubocop-ci-test)”。
 
 {% ifversion fpt or ghec %}
-## Retention of checks data
+## 检查数据的保留
 
 {% data reusables.pull_requests.retention-checks-data %}
 {% endif %}

translations/zh-CN/content/rest/teams/external-groups.md

@@ -19,7 +19,7 @@ miniTocMaxHeadingLevel: 3
 
 **注意：**
 
-- 外部组 API 仅适用于属于使用 {% data variables.product.prodname_emus %} 的企业中的组织。 更多信息请参阅“[关于企业管理用户](/admin/authentication/managing-your-enterprise-users-with-your-identity-provider/about-enterprise-managed-users)”。
+- The external groups API is only available for organizations that are part of an enterprise using {% data variables.product.prodname_emus %}. 更多信息请参阅“[关于企业管理用户](/admin/authentication/managing-your-enterprise-users-with-your-identity-provider/about-enterprise-managed-users)”。
 - 如果您的组织使用团队同步，则可以使用团队同步 API。 更多信息请参阅“[团队同步 API](#team-synchronization)”。
 
 {% endnote %}

translations/zh-CN/content/sponsors/sponsoring-open-source-contributors/sponsoring-an-open-source-contributor.md

@@ -25,7 +25,7 @@ shortTitle: 赞助贡献者
 
 您可以代表您的个人帐户赞助一个帐户，以投资您个人受益的项目。 您可以代表您的组织赞助帐户，原因有很多。
 - 维护组织工作所依赖的特定库
-- 投资于作为一个组织所依赖的生态系统（如区块链）
+- Investing in the ecosystem you rely on as an organization (such as blockchain)
 - 作为重视开源的组织，培养品牌知名度
 - 感谢开源开发者构建库来补充您的组织提供的产品
 

translations/zh-CN/data/features/streaming-datadog.yml

@@ -0,0 +1,4 @@
+#Reference #7495
+#Documentation for audit log streaming to a Datadog endpoint
+versions:
+  ghec: '*'

translations/zh-CN/data/reusables/enterprise_site_admin_settings/pgp-key-env-variable.md

@@ -1,4 +1,4 @@
-1. Define the key as a environment variable for {% data variables.product.product_name %}, replacing `<YOUR-KEY-ID>` with the GPG key ID.
+1. Define the key as an environment variable for {% data variables.product.product_name %}, replacing `<YOUR-KEY-ID>` with the GPG key ID.
 
     ```bash{:copy}
     ghe-config "secrets.gpgverify.web-signing-key" "$(gpg --export-secret-keys -a <YOUR-KEY-ID> | awk '{printf "%s\\n", $0}')"