New translation batch for ja (#30394)

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

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

@@ -147,11 +147,11 @@ With OIDC, a {% data variables.product.prodname_actions %} workflow requires a t
 
 Audience and Subject claims are typically used in combination while setting conditions on the cloud role/resources to scope its access to the GitHub workflows.
 - **Audience**: By default, this value uses the URL of the organization or repository owner. This can be used to set a condition that only the workflows in the specific organization can access the cloud role.
-- **Subject**: 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. See "[Example subject claims](#example-subject-claims)" to see how the subject claim is assembled from concatenated metadata.
+- **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. See "[Example subject claims](#example-subject-claims)" to see how the subject claim is assembled from concatenated metadata.
 
-There are also many additional claims supported in the OIDC token that can also be used for setting these conditions.
+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)".
 
-In addition, your cloud provider could allow you to assign a role to the access tokens, letting you specify even more granular permissions.
+There are also many additional claims supported in the OIDC token that can be used for setting these conditions. In addition, your cloud provider could allow you to assign a role to the access tokens, letting you specify even more granular permissions.
 
 {% 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/ja-JP/content/actions/deployment/security-hardening-your-deployments/using-openid-connect-with-reusable-workflows.md

@@ -23,11 +23,18 @@ topics:
 
 Rather than copying and pasting deployment jobs from one workflow to another, you can create a reusable workflow that performs the deployment steps. A reusable workflow can be used by another workflow if it meets one of the access requirements described in "[Reusing workflows](/actions/learn-github-actions/reusing-workflows#access-to-reusable-workflows)."
 
-When combined with OpenID Connect (OIDC), reusable workflows let you enforce consistent deployments across your repository, organization, or enterprise. You can do this by defining trust conditions on cloud roles based on reusable workflows.
+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)."
 
-In order to create trust conditions based on reusable workflows, your cloud provider must support custom claims for `job_workflow_ref`. This allows your cloud provider to identify which repository the job originally came from. If your cloud provider only supports the standard claims (_audience_ and _subject_), it will not be able to determine that the job originated from the reusable workflow repository. Cloud providers that support `job_workflow_ref` include Google Cloud Platform and HashiCorp Vault.
+## Defining the trust conditions
 
-Before proceeding, you should be familiar with the concepts of [reusable workflows](/actions/learn-github-actions/reusing-workflows) and [OpenID Connect](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect).
+When combined with OpenID Connect (OIDC), reusable workflows let you enforce consistent deployments across your repository, organization, or enterprise. You can do this by defining trust conditions on cloud roles based on reusable workflows. 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`. This allows your cloud provider to identify which repository the job originally came from.
+  - 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)".
 
 ## How the token works with reusable workflows
 

translations/ja-JP/content/actions/using-workflows/caching-dependencies-to-speed-up-workflows.md

@@ -51,7 +51,7 @@ For more information on workflow run artifacts, see "[Persisting workflow data u
 
 ワークフローは、現在のブランチ、ベースブランチ（フォークされたリポジトリのベースブランチを含む）、またはデフォルトブランチ（通常は `main`）で作成されたキャッシュにアクセスして復元できます。 たとえば、デフォルトブランチで作成されたキャッシュは、どのPull Requestからもアクセスできます。 また、`feature-b` ブランチに `feature-a` ベースブランチがある場合、`feature-b` でトリガーされたワークフローは、デフォルトのブランチ（`main`）、`feature-a`、および `feature-b` で作成されたキャッシュにアクセスできます。
 
-Access restrictions provide cache isolation and security by creating a logical boundary between different branches. For example, a cache created for the branch `feature-a` (with the base `main`) would not be accessible to a pull request for the branch `feature-c` (with the base `main`).
+Access restrictions provide cache isolation and security by creating a logical boundary between different branches or tags. For example, a cache created for the branch `feature-a` (with the base `main`) would not be accessible to a pull request for the branch `feature-c` (with the base `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`).
 
 Multiple workflows within a repository share cache entries. A cache created for a branch within a workflow can be accessed and restored from another workflow for the same repository and branch.
 

translations/ja-JP/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 @@ You set up the audit log stream on {% data variables.product.product_name %} by
 
 - [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)
 
@@ -60,7 +61,7 @@ You can set up streaming to S3 with access keys or, to avoid storing long-lived
 #### Setting up streaming to S3 with access keys
 {% endif %}
 
-To stream audit logs to Amazon's S3 endpoint, you must have a bucket and access keys. For more information, see [Creating, configuring, and working with Amazon S3 buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/creating-buckets-s3.html) in the the AWS documentation. Make sure to block public access to the bucket to protect your audit log information.
+To stream audit logs to Amazon's S3 endpoint, you must have a bucket and access keys. For more information, see [Creating, configuring, and working with Amazon S3 buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/creating-buckets-s3.html) in the AWS documentation. Make sure to block public access to the bucket to protect your audit log information.
 
 To set up audit log streaming from {% data variables.product.prodname_dotcom %} you will need:
 * The name of your Amazon S3 bucket
@@ -231,6 +232,32 @@ You need two pieces of information about your event hub: its instance name and t
 
 {% 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 %}
+
 ### Setting up streaming to Google Cloud Storage
 
 To set up streaming to Google Cloud Storage, you must create a service account in Google Cloud with the appropriate credentials and permissions, then configure audit log streaming in {% data variables.product.product_name %} using the service account's credentials for authentication.
@@ -291,6 +318,10 @@ To stream audit logs to Splunk's HTTP Event Collector (HEC) endpoint you must ma
 
 Pausing the stream allows you to perform maintenance on the receiving application without losing audit data. Audit logs are stored for up to seven days on {% data variables.product.product_location %} and are then exported when you unpause the stream.
 
+{% 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. Click **Pause stream**.
 

translations/ja-JP/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. `-----BEGIN PGP PUBLIC KEY BLOCK-----` で始まり、`-----END PGP PUBLIC KEY BLOCK-----` で終わる GPG キーをコピーします。

translations/ja-JP/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/ja-JP/content/developers/apps/building-github-apps/rate-limits-for-github-apps.md

@@ -47,7 +47,7 @@ Rate limits for {% data variables.product.prodname_github_apps %} and {% data va
 
 {% 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 %}
 

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

@@ -23,7 +23,7 @@ To transfer an open issue to another repository, you must have write access to t
 
 {% endnote %}
 
-When you transfer an issue, comments, labels and assignees are retained. The issue's milestones are not retained. This issue will stay on any user-owned or organization-wide project boards and be removed from any repository project boards. For more information, see "[About project boards](/articles/about-project-boards)."
+When you transfer an issue, comments and assignees are retained. 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. This issue will stay on any user-owned or organization-wide project boards and be removed from any repository project boards. For more information, see "[About project boards](/articles/about-project-boards)."
 
 People or teams who are mentioned in the issue will receive a notification letting them know that the issue has been transferred to a new repository. The original URL redirects to the new issue's URL. People who don't have read permissions in the new repository will see a banner letting them know that the issue has been transferred to a new repository that they can't access.
 

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

@@ -1,6 +1,6 @@
 ---
 title: OrganizationでのGitHub Discussionsの有効化もしくは無効化
-intro: 'Organization内の1つのリポジトリに限定されない会話をするための場所として、{% data variables.product.prodname_discussions %}をOrganizationで利用できます。'
+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/ja-JP/content/packages/learn-github-packages/about-permissions-for-github-packages.md

@@ -18,7 +18,7 @@ shortTitle: 権限について
 
 リポジトリスコープのパッケージは、パッケージを所有するリポジトリの権限と可視性を継承します。 リポジトリをスコープとするパッケージは、リポジトリのメインページにアクセスし、ページ右にある**パッケージ**リンクをクリックすれば見つかります。 {% ifversion fpt or ghec %}詳しい情報については「[リポジトリのパッケージへの接続](/packages/learn-github-packages/connecting-a-repository-to-a-package)」を参照してください。{% endif %}
 
-The {% data variables.product.prodname_registry %} registries below **only** use repository-scoped permissions:
+以下の{% data variables.product.prodname_registry %}レジストリは、リポジトリスコープの権限**のみ**を使います。
 
   {% ifversion not fpt or ghec %}-Dockerレジストリ（`docker.pkg.github.com`）{% endif %}
   {% ifversion packages-npm-v2 %}{% else %}- npm registry{% endif %}
@@ -26,14 +26,14 @@ The {% data variables.product.prodname_registry %} registries below **only** use
   - Apache Mavenレジストリ
   - NuGetレジストリ
 
-{% ifversion packages-npm-v2 %}For {% data variables.product.prodname_ghcr_and_npm_registry %}, you can choose to allow packages to be scoped to a user, an organization, or linked to a repository.{% endif %}
+{% ifversion packages-npm-v2 %}{% data variables.product.prodname_ghcr_and_npm_registry %}については、パッケージがユーザ、Organizationをスコープとするか、あるいはリポジトリにリンクするかを選択できます。{% endif %}
 
 {% ifversion fpt or ghec %}
 ## ユーザ/Organizationスコープのパッケージの詳細な権限
 
 詳細な権限を持つパッケージは、個人ユーザもしくはOrganizationアカウントをスコープとします。 パッケージのアクセス制御と可視性は、パッケージに接続された（あるいはリンクされた）リポジトリは別個に変更できます。
 
-Currently, the {% data variables.product.prodname_ghcr_and_npm_registry %} offer granular permissions for your container image packages.
+現在のところ、{% data variables.product.prodname_ghcr_and_npm_registry %}だけがコンテナイメージパッケージに関する詳細な権限を提供しています。
 
 ## コンテナイメージの可視性とアクセス権限
 

translations/ja-JP/content/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility.md

@@ -16,7 +16,7 @@ shortTitle: アクセスコントロールと可視性
 
 詳細な権限を持つパッケージは、個人ユーザもしくはOrganizationアカウントをスコープとします。 パッケージのアクセス制御と可視性は、パッケージに接続された（あるいはリンクされた）リポジトリは別個に変更できます。
 
-現在は、{% data variables.product.prodname_ghcr_and_npm_registry %}でのみ詳細な権限を使うことができます。 Granular permissions are not supported in our other package registries, such as the RubyGems registry.{% ifversion docker-ghcr-enterprise-migration %} For more information about migration to the {% data variables.product.prodname_container_registry %}, see "[Migrating to the {% data variables.product.prodname_container_registry %} from the Docker registry](/packages/working-with-a-github-packages-registry/migrating-to-the-container-registry-from-the-docker-registry)."{% endif %}
+現在は、{% data variables.product.prodname_ghcr_and_npm_registry %}でのみ詳細な権限を使うことができます。 詳細な権限は、RubyGemsレジストリのような他のパッケージレジストリではサポートされていません。{% ifversion docker-ghcr-enterprise-migration %}{% data variables.product.prodname_container_registry %}への移行に関する詳しい情報については「[Dockerレジストリから{% data variables.product.prodname_container_registry %}への移行](/packages/working-with-a-github-packages-registry/migrating-to-the-container-registry-from-the-docker-registry)」を参照してください。{% endif %}
 
 リポジトリをスコープとするパッケージの権限や、PATに関するパッケージ関連のスコープ、Actionsのワークフローの権限の管理についての詳しい情報は、「[GitHub Packagesの権限について](/packages/learn-github-packages/about-permissions-for-github-packages)」を参照してください。
 
@@ -95,7 +95,7 @@ Organization が所有するコンテナイメージに対する管理者権限
 {% ifversion fpt or ghec %}
 ## パッケージへの{% data variables.product.prodname_codespaces %}アクセスの確保
 
-By default, a codespace can seamlessly access certain packages in the {% data variables.product.prodname_ghcr_and_npm_registry %}, such as those published in the same repository with the **Inherit access** option selected. For more information on which access is automatically configured, see "[Allowing your codespace to access a private image registry](/codespaces/codespaces-reference/allowing-your-codespace-to-access-a-private-image-registry#accessing-images-stored-in-container-registry-and-npm-registry)."
+デフォルトでは、codespaceは**Inherit access（アクセスの継承）**オプションが選択された同じリポジトリ内で公開されたパッケージなど、{% data variables.product.prodname_ghcr_and_npm_registry %} 内の特定パッケージにシームレスにアクセスできます。 自動的に設定されるアクセスに関する詳しい情報については「[codespaceへのプライベートイメージレジストリへのアクセスの許可](/codespaces/codespaces-reference/allowing-your-codespace-to-access-a-private-image-registry#accessing-images-stored-in-container-registry-and-npm-registry) 」を参照してください。
 
 あるいは、codespaceがパッケージに確実にアクセスできるようにするには、codespaceが起動されたリポジトリへのアクセスを許可しなければなりません。
 

translations/ja-JP/content/packages/learn-github-packages/deleting-and-restoring-a-package.md

@@ -46,7 +46,7 @@ REST APIを使用してパッケージを管理できます。 詳しい情報
 
 {% endif %}
 
-For packages that inherit their permissions and access from repositories, you can use GraphQL to delete a specific package version.{% data reusables.package_registry.no-graphql-to-delete-packages %} For more information about GraphQL support, see "[Deleting a version of a repository-scoped package with GraphQL](#deleting-a-version-of-a-repository-scoped-package-with-graphql)."
+権限とアクセスをリポジトリから継承するパッケージでは、GraphQLを使って特定のパッケージバージョンを削除できます。{% data reusables.package_registry.no-graphql-to-delete-packages %}GraphQLサポートに関する詳しい情報については「[GraphQLでリポジトリをスコープとするパッケージのバージョンを削除する](#deleting-a-version-of-a-repository-scoped-package-with-graphql)」を参照してください。
 
 {% endif %}
 
@@ -54,7 +54,7 @@ For packages that inherit their permissions and access from repositories, you ca
 
 リポジトリからアクセス権限を継承しているパッケージの場合、そのリポジトリに対する管理者権限がある場合はパッケージを削除できます。
 
-The {% data variables.product.prodname_registry %} registries below **only** use repository-scoped permissions:
+以下の{% data variables.product.prodname_registry %}レジストリは、リポジトリスコープの権限**のみ**を使います。
 
   {% ifversion not fpt or ghec %}-`docker.pkg.github.com/OWNER/REPOSITORY/IMAGE-NAME`にあるDockerイメージ{% endif %}
   {% ifversion packages-npm-v2 %}{% else %}- npm{% endif %}
@@ -62,11 +62,11 @@ The {% data variables.product.prodname_registry %} registries below **only** use
   - Apache Mavenレジストリ
   - NuGetレジストリ
 
-{% ifversion packages-npm-v2 %}For {% data variables.product.prodname_ghcr_and_npm_registry %}, you can choose to allow packages to be scoped to a user, an organization, or linked to a repository.{% endif %}
+{% ifversion packages-npm-v2 %}{% data variables.product.prodname_ghcr_and_npm_registry %}については、パッケージがユーザ、Organizationをスコープとするか、あるいはリポジトリにリンクするかを選択できます。{% endif %}
 
 {% ifversion fpt or ghec %}
 
-To delete a package that has granular permissions separate from a repository, such as container images stored at `https://ghcr.io/OWNER/PACKAGE-NAME` or `https://npm.pkg.github.com/OWNER/PACKAGE-NAME`, you must have admin access to the package. 詳しい情報については「[{% data variables.product.prodname_registry %}の権限について](/packages/learn-github-packages/about-permissions-for-github-packages)」を参照してください。
+`https://ghcr.io/OWNER/PACKAGE-NAME`あるいは`https://npm.pkg.github.com/OWNER/PACKAGE-NAME`に保存されたコンテナイメージなど、リポジトリとは別に詳細な権限を持つパッケージを削除する場合は、そのパッケージに対するアクセス権限が必要です。 詳しい情報については「[{% data variables.product.prodname_registry %}の権限について](/packages/learn-github-packages/about-permissions-for-github-packages)」を参照してください。
 
 {% endif %}
 
@@ -88,7 +88,7 @@ To delete a package that has granular permissions separate from a repository, su
 
 リポジトリから権限とアクセスを継承しているパッケージの場合、GraphQLを使用して特定のパッケージバージョンを削除できます。
 
-{% data reusables.package_registry.no-graphql-to-delete-packages %}{% ifversion fpt or ghec %} You can however use the REST API. For more information, see the "[{% data variables.product.prodname_registry %} API](/rest/reference/packages)."{% endif %}
+{% data reusables.package_registry.no-graphql-to-delete-packages %}{% ifversion fpt or ghec %}ただし、REST APIを使うことはできます。 詳しい情報については「[{% data variables.product.prodname_registry %} API](/rest/reference/packages)」を参照してください。{% endif %}
 
 GraphQL APIの`deletePackageVersion`ミューテーションを使ってください。 `read:packages`、`delete:packages`、`repo`スコープを持つトークンを使わなければなりません。 トークンに関する詳しい情報については「[{% data variables.product.prodname_registry %}について](/packages/publishing-and-managing-packages/about-github-packages#authenticating-to-github-packages)」を参照してください。
 

translations/ja-JP/content/packages/learn-github-packages/viewing-packages.md

@@ -23,7 +23,7 @@ versions:
 
 パッケージを見ることができるかどうかは、いくつかの要素に依存します。 デフォルトでは、公開したパッケージはすべて見ることができます。
 
-リポジトリをスコープとするパッケージは、そのパッケージを所有するリポジトリから権限と可視性を継承します。 The registries below **only** use this type of permissions:{% ifversion not fpt or ghec %}
+リポジトリをスコープとするパッケージは、そのパッケージを所有するリポジトリから権限と可視性を継承します。 以下のレジストリは、この種類の権限**のみ**を利用します:{% ifversion not fpt or ghec %}
 - Dockerレジストリ (`docker.pkg.github.com`){% endif %}
 {% ifversion packages-npm-v2 %}{% else %}- npm registry{% endif %}
 - RubyGemsレジストリ
@@ -31,7 +31,7 @@ versions:
 - NuGetレジストリ
 
 {% ifversion fpt or ghec %}
-The {% data variables.product.prodname_ghcr_and_npm_registry %} offer you the option of granular permissions and visibility settings that can be customized for each package owned by a personal user or organization account. 詳細な権限を利用することも、パッケージをレジストリに接続してその権限を継承することもできます。 詳しい情報については「[リポジトリのパッケージへの接続](/packages/learn-github-packages/connecting-a-repository-to-a-package)」を参照してください。
+{% data variables.product.prodname_ghcr_and_npm_registry %}は、個人ユーザもしくはOrganizationアカウントが所有する各パッケージごとにカスタマイズできる、詳細な権限及び可視性の設定のオプションを提供します。 詳細な権限を利用することも、パッケージをレジストリに接続してその権限を継承することもできます。 詳しい情報については「[リポジトリのパッケージへの接続](/packages/learn-github-packages/connecting-a-repository-to-a-package)」を参照してください。
 {% endif %}
 
 詳しい情報については「[GitHub Packagesの権限について](/packages/learn-github-packages/about-permissions-for-github-packages)」{% ifversion fpt or ghec %}及び「[パッケージのアクセス制御と可視性の設定](/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility)」{% endif %}を参照してください。

translations/ja-JP/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 @@ DNS レコードの設定が正しいかどうかを検証するために利用
 {% data reusables.repositories.sidebar-settings %}
 {% data reusables.pages.sidebar-pages %}
 4. "Custom domain（カスタムドメイン）" の下で、カスタムドメインを入力して**Save（保存）**をクリックします。 サイトをブランチから公開しているなら、これで`CNAME`ファイルをソースブランチのルートに追加するコミットが作成されます。 サイトをカスタムの{% data variables.product.prodname_actions %}ワークフローで公開しているなら、`CNAME`ファイルは作成されません。 公開ソースに関する詳しい情報については「[GitHub Pagesサイトの公開ソースの設定](/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` というサブドメインを使いたい場合、`www.example.com` が `<user>.github.io` を指す`CNAME` レコードを作成します。 Organization サイトで `www.anotherexample.com` というサブドメインを使用する場合、`www.anotherexample.com` が `<organization>.github.io` を指す`CNAME` レコードを作成します。 `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` というサブドメインを使いたい場合、`www.example.com` が `<user>.github.io` を指す`CNAME` レコードを作成します。 Organization サイトで `another.example.com` というサブドメインを使用する場合、`another.example.com` が `<organization>.github.io` を指す`CNAME` レコードを作成します。 `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/ja-JP/content/rest/guides/getting-started-with-the-checks-api.md

@@ -41,7 +41,7 @@ GitHub Appは、単に合格/不合格の二択ではない、情報量の多い
 
 ![チェック実行のワークフロー](/assets/images/check_runs.png)
 
-チェック実行が15日以上にわたり不完全な状態である場合は、チェック実行の`conclusion`が`stale`になり、{% data variables.product.prodname_dotcom %}に状態が{% octicon "issue-reopened" aria-label="The issue-reopened icon" %}と表示されます。 {% data variables.product.prodname_dotcom %}のみが、チェック実行を`stale`としてマークできます。 チェック実行で出る可能性がある結果についての詳細は、 [`conclusion`パラメータ](/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)を参照してください。
 
 [`check_suite`](/webhooks/event-payloads/#check_suite) webhookを受け取ったら、チェックが完了していなくてもすぐにチェック実行を作成できます。 チェック実行の`status`は、`queued`、`in_progress`、または`completed`の値で更新でき、より詳細を明らかにして`output`を更新できます。 チェック実行にはタイムスタンプ、詳細情報が記載された外部サイトへのリンク、コードの特定の行に対するアノテーション、および実行した分析についての情報を含めることができます。
 

translations/ja-JP/content/rest/teams/external-groups.md

@@ -19,7 +19,7 @@ miniTocMaxHeadingLevel: 3
 
 **ノート:**
 
-- 外部グループAPIは、{% data variables.product.prodname_emus %}を使用しているEnterpriseの一部であるOrganizationでのみ利用できます。 詳しい情報については「[Enterpriseが管理しているユーザ](/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 %}. 詳しい情報については「[Enterpriseが管理しているユーザ](/admin/authentication/managing-your-enterprise-users-with-your-identity-provider/about-enterprise-managed-users)」を参照してください。
 - OrganizationがTeam同期を使用している場合、Team Synchronization APIが利用できます。 詳しい情報については「[Team synchronization API](#team-synchronization)」を参照してください。
 
 {% endnote %}

translations/ja-JP/content/sponsors/sponsoring-open-source-contributors/sponsoring-an-open-source-contributor.md

@@ -25,7 +25,7 @@ shortTitle: Sponsor a contributor
 
 You can sponsor an account on behalf of your personal account to invest in projects that you personally benefit from. Organization に代わってアカウントをスポンサーできますが、それには多くの理由があります。
 - Organization の作業が依存する特定のライブラリを維持する
-- Organization として依存しているエコシステム (たとえばブロックチェーン) に投資する
+- Investing in the ecosystem you rely on as an organization (such as blockchain)
 - オープンソースを大切にする Organization としてブランド認知度を確立する
 - Organization が提供する製品を補完するライブラリを構築しているオープンソース開発者に感謝する
 

translations/ja-JP/data/features/streaming-datadog.yml

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

translations/ja-JP/data/reusables/codespaces/codespaces-disabling-org-billing.md

@@ -1,5 +1,5 @@
 {% note %}
 
-**Note**:  If you disable billable codespaces use for your organization, anyone who can create codespaces as an individual user, and can clone a repository in your organization, will still be able to create a codespace for that repository. However, this will not incur any charge for your organization. For information about restricting access to a repository, see "[Managing teams and people with access to your repository](/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/managing-teams-and-people-with-access-to-your-repository)."
+**ノート**: Organizationで課金されるcodespacesの利用を無効化した場合でも、個人ユーザとしてcodespacesを作成でき、Organization内のリポジトリをクローンできるユーザは、引き続きそのリポジトリに対してcodespaceを作成できます。 しかし、これによってOrganizationに対する課金が生じることはありません。 リポジトリへのアクセスの制限に関する情報については「[リポジトリへのアクセスを持つTeamや人の管理](/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/managing-teams-and-people-with-access-to-your-repository)」を参照してください。
 
 {% endnote %}

translations/ja-JP/data/reusables/codespaces/codespaces-org-policies-note.md

@@ -1,5 +1,5 @@
 {% note %}
 
-**Note**: Organization policies you define for {% data variables.product.prodname_codespaces %} only apply to codespaces for which your organization will be billed. If an individual user creates a codespace for a repository in your organization, and the organization is not billed, then the codespace will not be bound by these policies. For information on how to choose who can create codespaces that are billed to your organization, see "[Enabling {% data variables.product.prodname_github_codespaces %} for your organization](https://docs-internal-29134-ad7bd8.preview.ghdocs.com/en/codespaces/managing-codespaces-for-your-organization/enabling-github-codespaces-for-your-organization#choose-who-can-create-codespaces-that-are-billed-to-your-organization)."
+**ノート**: {% data variables.product.prodname_codespaces %}に対して定義するOrganizationのポリシーは、そのOrganizationに対して課金されるcodespacesにのみ適用されます。 個人ユーザがOrganization内のリポジトリに対してcodespaceを作成し、Organizationが課金されない場合は、そのcodespaceはそれらのポリシーによる制約を受けません。 Organizationに課金されるcodespaceを作成できるユーザの選択方法に関する情報については「[Organizationでの{% data variables.product.prodname_github_codespaces %}の有効化](https://docs-internal-29134-ad7bd8.preview.ghdocs.com/en/codespaces/managing-codespaces-for-your-organization/enabling-github-codespaces-for-your-organization#choose-who-can-create-codespaces-that-are-billed-to-your-organization)」を参照してください。
 
 {% endnote %}

translations/ja-JP/data/reusables/codespaces/codespaces-spending-limit-requirement.md

@@ -1,9 +1,9 @@
 {% note %}
 
-**Note:** You must set a non-zero spending limit before you can use {% data variables.product.prodname_codespaces %}.
+**ノート:** {% data variables.product.prodname_codespaces %}を利用するには、0ではない利用上限を設定しなければなりません。
 
 {% endnote %}
 
-By default, your organization or enterprise will have a {% data variables.product.prodname_github_codespaces %} spending limit of $0. This prevents new codespaces from being created, or existing codespaces from being opened, if this would incur a billable cost to your organization or enterprise. Organiationでユーザがcodespaceを作成できるようにするには、この上限を$0よりも大きな値に設定してください。
+デフォルトでは、OrganizationもしくはEnterpriseは、$0の{% data variables.product.prodname_github_codespaces %}利用上限を持ちます。 これによって、OrganizationやEntepriseへの課金が発生する場合に、新しいcodespaceが作成されたり、既存のcodespacesがオープンされることを防げます。 Organiationでユーザがcodespaceを作成できるようにするには、この上限を$0よりも大きな値に設定してください。
 
 {% data reusables.billing.overages-billed-monthly %}

translations/ja-JP/data/reusables/codespaces/remote-explorer.md

@@ -1,9 +1,9 @@
 {% note %}
 
-**Note**: If the Remote Explorer is not displayed in the Activity Bar:
+**ノート**: Remote Explorerがアクティビティバーに表示されない場合:
 
-1. Access the command palette. For example, by pressing <kbd>Shift</kbd>+<kbd>Command</kbd>+<kbd>P</kbd> (Mac) / <kbd>Ctrl</kbd>+<kbd>Shift</kbd>+<kbd>P</kbd> (Windows/Linux).
+1. コマンドパレットにアクセスしてください。 たとえば<kbd>Shift</kbd>+<kbd>Command</kbd>+<kbd>P</kbd> (Mac) / <kbd>Ctrl</kbd>+<kbd>Shift</kbd>+<kbd>P</kbd> (Windows/Linuxを押します。
-1. Type: `codespaces`.
+1. `codespaces`と入力してください。
-1. Click **Codespaces: Details**.
+1. **Codespaces: Details（Codespacesの詳細）**をクリックしてください。
 
 {% endnote %}

translations/ja-JP/data/reusables/enterprise_site_admin_settings/pgp-key-env-variable.md

@@ -1,4 +1,4 @@
-1. `<YOUR-KEY-ID>`をGPGキーIDで置き換えて、キーを{% data variables.product.product_name %}の環境変数として定義してください。
+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}')"

translations/ja-JP/data/reusables/git/cache-on-repository-path.md

@@ -1,4 +1,4 @@
-1. To configure Git to cache credentials for each local directory where you clone a repository, enter the following command.
+1. リポジトリをクローンしたそれぞれのローカルディレクトリに認証情報をキャッシュするようGitを設定するには、以下のコマンドを入力してください。
 
    ```shell{:copy}
    git config --global credential.useHttpPath true