jprdonnelly/docs
1
0
Fork 0
mirror of synced 2026-01-06 06:02:35 -05:00
Code Issues Projects Releases Wiki Activity

New translation batch for ja (#29971)

Browse Source 
* Add crowdin translations

* Run script/i18n/homogenize-frontmatter.js

* Run script/i18n/lint-translation-files.js --check rendering

* run script/i18n/reset-files-with-broken-liquid-tags.js --language=ja

* run script/i18n/reset-known-broken-translation-files.js

* Check in ja CSV report

Co-authored-by: Peter Bengtsson <peterbe@github.com>
This commit is contained in:
docubot
2022-08-16 07:34:44 -04:00
committed by GitHub
parent 59d1f3ea9a
commit 62d1df16fd
143 changed files with 694 additions and 504 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
translations/ja-JP/content/actions/deployment/targeting-different-environments/using-environments-for-deployment.md
View File

@@ -27,7 +27,7 @@ versions:
**Note:** You can only configure environments for public repositories. リポジトリをパブリックからプライベートに変換すると、設定された保護ルールや環境のシークレットは無視されるようになり、環境は設定できなくなります。 リポジトリをパブリックに変換して戻せば、以前に設定されていた保護ルールや環境のシークレットにアクセスできるようになります。
Organizations that use {% data variables.product.prodname_ghe_cloud %} can configure environments for private repositories. 詳しい情報については[{% data variables.product.prodname_ghe_cloud %}のドキュメンテーション](/enterprise-cloud@latest/actions/deployment/targeting-different-environments/using-environments-for-deployment)を参照してください。 {% data reusables.enterprise.link-to-ghec-trial %}
Organizations with {% data variables.product.prodname_team %} and users with {% data variables.product.prodname_pro %} can configure environments for private repositories. 詳細は「[{% data variables.product.prodname_dotcom %} の製品](/get-started/learning-about-github/githubs-products)」を参照してください。
{% endnote %}
{% endif %}
@@ -72,7 +72,7 @@ Organizations that use {% data variables.product.prodname_ghe_cloud %} can confi
{% ifversion fpt or ghec %}
{% note %}
**Note:** To create an environment in a private repository, your organization must use {% data variables.product.prodname_ghe_cloud %}. {% data reusables.enterprise.link-to-ghec-trial %}
**Note:** Creation of an environment in a private repository is available to organizations with {% data variables.product.prodname_team %} and users with {% data variables.product.prodname_pro %}.
{% endnote %}
{% endif %}
@@ -99,7 +99,7 @@ Organizations that use {% data variables.product.prodname_ghe_cloud %} can confi
1. Enter the secret value.
1. [**Add secret（シークレットの追加）**] をクリックします。
REST API を介して環境を作成および設定することもできます。 詳細については、「[環境](/rest/reference/repos#environments)」および「[シークレット](/rest/reference/actions#secrets)」を参照してください。
REST API を介して環境を作成および設定することもできます。 For more information, see "[Deployment environments](/rest/deployments/environments)," "[GitHub Actions Secrets](/rest/actions/secrets)," and "[Deployment branch policies](/rest/deployments/branch-policies)."
存在しない環境を参照するワークフローを実行すると、参照された名前を持つ環境が作成されます。 新しく作成される環境には、保護ルールやシークレットは設定されていません。 リポジトリのワークフローを編集できる人は、ワークフローファイルを通じて環境を作成できますが、その環境を設定できるのはリポジトリ管理者だけです。

2
translations/ja-JP/content/actions/hosting-your-own-runners/using-self-hosted-runners-in-a-workflow.md
View File

@@ -63,7 +63,7 @@ runs-on: [self-hosted, linux, x64, gpu]
- `x64` - Only use a runner based on x64 hardware.
- `gpu` - This custom label has been manually assigned to self-hosted runners with the GPU hardware installed.
These labels operate cumulatively, so a self-hosted runner’s labels must match all four to be eligible to process the job.
These labels operate cumulatively, so a self-hosted runner must have all four labels to be eligible to process the job.
## Routing precedence for self-hosted runners

2
translations/ja-JP/content/actions/using-github-hosted-runners/about-github-hosted-runners.md
View File

@@ -111,7 +111,7 @@ For the overall list of included tools for each runner operating system, see the
* [Ubuntu 22.04 LTS](https://github.com/actions/runner-images/blob/main/images/linux/Ubuntu2204-Readme.md)
* [Ubuntu 20.04 LTS](https://github.com/actions/runner-images/blob/main/images/linux/Ubuntu2004-Readme.md)
* [Ubuntu 18.04 LTS](https://github.com/actions/runner-images/blob/main/images/linux/Ubuntu1804-Readme.md)
* [Ubuntu 18.04 LTS](https://github.com/actions/runner-images/blob/main/images/linux/Ubuntu1804-Readme.md) (deprecated)
* [Windows Server 2022](https://github.com/actions/runner-images/blob/main/images/win/Windows2022-Readme.md)
* [Windows Server 2019](https://github.com/actions/runner-images/blob/main/images/win/Windows2019-Readme.md)
* [macOS 12](https://github.com/actions/runner-images/blob/main/images/macos/macos-12-Readme.md)

8
translations/ja-JP/content/actions/using-workflows/workflow-commands-for-github-actions.md
View File

@@ -25,7 +25,7 @@ versions:
アクションは、 環境変数を設定する、他のアクションに利用される値を出力する、デバッグメッセージを出力ログに追加するなどのタスクを行うため、ランナーマシンとやりとりできます。
ほとんどのワークフローコマンドは特定の形式で `echo` コマンドを使用しますが、他のワークフローコマンドはファイルへの書き込みによって呼び出されます。 詳しい情報については、「[環境ファイル](#environment-files)」を参照してください。
ほとんどのワークフローコマンドは特定の形式で `echo` コマンドを使用しますが、他のワークフローコマンドはファイルへの書き込みによって呼び出されます。 For more information, see "[Environment files](#environment-files)."
### サンプル
@@ -623,6 +623,12 @@ steps:
{delimiter}
```
{% warning %}
**Warning:** Make sure the delimiter you're using is randomly generated and unique for each run. For more information, see "[Understanding the risk of script injections](/actions/security-guides/security-hardening-for-github-actions#understanding-the-risk-of-script-injections)".
{% endwarning %}
#### サンプル
This example uses `EOF` as a delimiter, and sets the `JSON_RESPONSE` environment variable to the value of the `curl` response.

5
translations/ja-JP/content/actions/using-workflows/workflow-syntax-for-github-actions.md
View File

@@ -538,6 +538,7 @@ jobs:
| サポートされているプラットフォーム | `shell` パラメータ | 説明 | 内部で実行されるコマンド |
| ----------------- | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- |
| Linux / macOS | unspecified | The default shell on non-Windows platforms. Note that this runs a different command to when `bash` is specified explicitly. If `bash` is not found in the path, this is treated as `sh`. | `bash -e {0}` |
| すべて | `bash` | 非Windowsプラットフォームのデフォルトシェルで、`sh`へのフォールバックがあります。 Windowsでbashシェルを指定すると、Windows用Gitに含まれるbashシェルが使用されます。 | `bash --noprofile --norc -eo pipefail {0}` |
| すべて | `pwsh` | PowerShell Coreです。 {% data variables.product.prodname_dotcom %}はスクリプト名に拡張子`.ps1`を追加します。 | `pwsh -command ". '{0}'"` |
| すべて | `python` | Pythonのコマンドを実行します。 | `python {0}` |
@@ -793,11 +794,11 @@ strategy:
fail-fast: false
matrix:
node: [13, 14]
os: [macos-latest, ubuntu-18.04]
os: [macos-latest, ubuntu-latest]
experimental: [false]
include:
- node: 15
os: ubuntu-18.04
os: ubuntu-latest
experimental: true
```
{% endraw %}

6
translations/ja-JP/content/admin/github-actions/managing-access-to-actions-from-githubcom/setting-up-the-tool-cache-on-self-hosted-runners-without-internet-access.md
View File

@@ -30,7 +30,7 @@ You can populate the runner tool cache by running a {% data variables.product.pr
{% note %}
**Note:** You can only use a {% data variables.product.prodname_dotcom %}-hosted runner's tool cache for a self-hosted runner that has an identical operating system and architecture. For example, if you are using a `ubuntu-18.04` {% data variables.product.prodname_dotcom %}-hosted runner to generate a tool cache, your self-hosted runner must be a 64-bit Ubuntu 18.04 machine. For more information on {% data variables.product.prodname_dotcom %}-hosted runners, see "[About {% data variables.product.prodname_dotcom %}-hosted runners](/free-pro-team@latest/actions/using-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources)."
**Note:** You can only use a {% data variables.product.prodname_dotcom %}-hosted runner's tool cache for a self-hosted runner that has an identical operating system and architecture. For example, if you are using a `ubuntu-22.04` {% data variables.product.prodname_dotcom %}-hosted runner to generate a tool cache, your self-hosted runner must be a 64-bit Ubuntu 22.04 machine. For more information on {% data variables.product.prodname_dotcom %}-hosted runners, see "[About {% data variables.product.prodname_dotcom %}-hosted runners](/free-pro-team@latest/actions/using-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources)."
{% endnote %}
@@ -45,14 +45,14 @@ You can populate the runner tool cache by running a {% data variables.product.pr
1. On {% data variables.product.prodname_dotcom_the_website %}, navigate to a repository that you can use to run a {% data variables.product.prodname_actions %} workflow.
1. Create a new workflow file in the repository's `.github/workflows` folder that uploads an artifact containing the {% data variables.product.prodname_dotcom %}-hosted runner's tool cache.
The following example demonstrates a workflow that uploads the tool cache for an Ubuntu 18.04 environment, using the `setup-node` action with Node.js versions 10 and 12.
The following example demonstrates a workflow that uploads the tool cache for an Ubuntu 22.04 environment, using the `setup-node` action with Node.js versions 10 and 12.
```yaml
name: Upload Node.js 10 and 12 tool cache
on: push
jobs:
upload_tool_cache:
runs-on: ubuntu-18.04
runs-on: ubuntu-22.04
steps:
- name: Clear any existing tool cache
run: |

11
translations/ja-JP/content/admin/overview/creating-an-enterprise-account.md
View File

@@ -18,14 +18,15 @@ shortTitle: Create enterprise account
{% data reusables.enterprise.create-an-enterprise-account %} If you pay by invoice, you can create an enterprise account yourself on {% data variables.product.prodname_dotcom %}. If not, you can [contact our sales team](https://github.com/enterprise/contact?ref_page=/pricing&ref_cta=Contact%20Sales&ref_loc=cards) to create an enterprise account for you.
An enterprise account is included in {% data variables.product.prodname_ghe_cloud %}, so creating one will not affect your bill.
An enterprise account is included with {% data variables.product.prodname_ghe_cloud %}. Creation of an enterprise account does not result in additional charges on your bill.
When you create an enterprise account, your existing organization will automatically be owned by the enterprise account. All current owners of your organization will become owners of the enterprise account. All current billing managers of the organization will become billing managers of the new enterprise account. The current billing details of the organization, including the organization's billing email address, will become billing details of the new enterprise account.
When you create an enterprise account that owns your existing organization on {% data variables.product.product_name %}, the organization's resources remain accessible to members at the same URLs. After you add your organization to the enterprise account, the following changes will apply to the organization.
If the organization is connected to {% data variables.product.prodname_ghe_server %} or {% data variables.product.prodname_ghe_managed %} via {% data variables.product.prodname_github_connect %}, upgrading the organization to an enterprise account **will not** update the connection. If you want to connect to the new enterprise account, you must disable and re-enable {% data variables.product.prodname_github_connect %}.
- Your existing organization will automatically be owned by the enterprise account.
- {% data variables.product.company_short %} bills the enterprise account for usage within all organizations owned by the enterprise. The current billing details for the organization, including the organization's billing email address, will become billing details for the new enterprise account. 詳しい情報については「[Enterpriseの支払いについて](/billing/managing-billing-for-your-github-account/about-billing-for-your-enterprise)」を参照してください。
- All current owners of your organization will become owners of the enterprise account, and all current billing managers of the organization will become billing managers of the new enterprise account. 詳しい情報については、「[Enterprise アカウントのロール](/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise)」を参照してください。
- "[Managing {% data variables.product.prodname_github_connect %}](/enterprise-server@latest/admin/configuration/configuring-github-connect/managing-github-connect)" in the {% data variables.product.prodname_ghe_server %} documentation
- "[Managing {% data variables.product.prodname_github_connect %}](/github-ae@latest/admin/configuration/configuring-github-connect/managing-github-connect)" in the {% data variables.product.prodname_ghe_managed %} documentation
For more information about the changes that apply to an organization after you add the organization to an enterprise, see "[Adding organizations to your enterprise](/admin/user-management/managing-organizations-in-your-enterprise/adding-organizations-to-your-enterprise#about-addition-of-organizations-to-your-enterprise-account)."
## Creating an enterprise account on {% data variables.product.prodname_dotcom %}

2
translations/ja-JP/content/admin/policies/enforcing-policies-for-your-enterprise/enforcing-repository-management-policies-in-your-enterprise.md
View File

@@ -96,7 +96,7 @@ Across all organizations owned by your enterprise, you can allow members to crea
{% data reusables.enterprise-accounts.policies-tab %}
{% data reusables.enterprise-accounts.repositories-tab %}
5. [Repository creation] で、設定変更に関する情報を読みます。 {% data reusables.enterprise-accounts.view-current-policy-config-orgs %}
{% ifversion ghes or ghae %}
{% ifversion ghes or ghae or ghec %}
{% data reusables.enterprise-accounts.repo-creation-policy %}
{% data reusables.enterprise-accounts.repo-creation-types %}
{% else %}

19
translations/ja-JP/content/admin/user-management/managing-organizations-in-your-enterprise/adding-organizations-to-your-enterprise.md
View File

@@ -17,13 +17,26 @@ shortTitle: Add organizations
permissions: Enterprise owners can add organizations to an enterprise.
---
## Organizationについて
## About addition of organizations to your enterprise account
Your enterprise account can own organizations. Members of your enterprise can collaborate across related projects within an organization. 詳細は「[Organization について](/organizations/collaborating-with-groups-in-organizations/about-organizations)」を参照してください。
You can add a new or existing organization to your enterprise in your enterprise account's settings.
You can add new organizations to your enterprise account. If you do not use {% data variables.product.prodname_emus %}, you can add existing organizations on {% data variables.product.product_location %} to your enterprise. You cannot add an existing organization from an {% data variables.product.prodname_emu_enterprise %} to a different enterprise.
You can only add organizations this way to an existing enterprise account. {% data reusables.enterprise.create-an-enterprise-account %} 詳しい情報については「[Enterpriseアカウントの作成](/admin/overview/creating-an-enterprise-account)」を参照してください。
{% data reusables.enterprise.create-an-enterprise-account %} 詳しい情報については「[Enterpriseアカウントの作成](/admin/overview/creating-an-enterprise-account)」を参照してください。
After you add an existing organization to your enterprise, the organization's resources remain accessible to members at the same URLs, and the following changes will apply.
- The organization's members will become members of the enterprise, and {% data variables.product.company_short %} will bill the enterprise account for the organization's usage. You must ensure that the enterprise account has enough licenses to accommodate any new members. 詳しい情報については「[Enterpriseの支払いについて](/billing/managing-billing-for-your-github-account/about-billing-for-your-enterprise)」を参照してください。
- Enterprise owners can manage their role within the organization. 詳しい情報については「[自身のEnterpriseが所有しているOrganization内での自分のロールの管理](/admin/user-management/managing-organizations-in-your-enterprise/managing-your-role-in-an-organization-owned-by-your-enterprise)」を参照してください。
- Any policies applied to the enterprise will apply to the organization. For more information, see "[About enterprise policies](/admin/policies/enforcing-policies-for-your-enterprise/about-enterprise-policies)."
- If SAML SSO is configured for the enterprise account, the enterprise's SAML configuration will apply to the organization. If the organization used SAML SSO, the enterprise account's configuration will replace the organization's configuration. SCIM is not available for enterprise accounts, so SCIM will be disabled for the organization. For more information, see "[Configuring SAML single sign-on for your enterprise](/admin/identity-and-access-management/using-saml-for-enterprise-iam/configuring-saml-single-sign-on-for-your-enterprise)" and "[Switching your SAML configuration from an organization to an enterprise account](/admin/identity-and-access-management/using-saml-for-enterprise-iam/switching-your-saml-configuration-from-an-organization-to-an-enterprise-account)."
- If SAML SSO was configured for the organization, members' existing personal access tokens (PATs) or SSH keys that were authorized to access the organization's resources will be authorized to access the same resources. To access additional organizations owned by the enterprise, members must authorize the PAT or key. 詳しい情報については、「[SAMLシングルサインオンで利用するために個人アクセストークンを認可する](/authentication/authenticating-with-saml-single-sign-on/authorizing-a-personal-access-token-for-use-with-saml-single-sign-on)」と、「[SAML シングルサインオンで使用するために SSH キーを認可する](/authentication/authenticating-with-saml-single-sign-on/authorizing-an-ssh-key-for-use-with-saml-single-sign-on)」を参照してください。
- If the organization was connected to {% data variables.product.prodname_ghe_server %} or {% data variables.product.prodname_ghe_managed %} using {% data variables.product.prodname_github_connect %}, adding the organization to an enterprise will not update the connection. {% data variables.product.prodname_github_connect %} features will no longer function for the organization. To continue using {% data variables.product.prodname_github_connect %}, you must disable and re-enable the feature. 詳しい情報については、次の記事を参照してください。
- "[Managing {% data variables.product.prodname_github_connect %}](/enterprise-server@latest/admin/configuration/configuring-github-connect/managing-github-connect)" in the {% data variables.product.prodname_ghe_server %} documentation
- "[Managing {% data variables.product.prodname_github_connect %}](/github-ae@latest/admin/configuration/configuring-github-connect/managing-github-connect)" in the {% data variables.product.prodname_ghe_managed %} documentation
- If the organization used billed {% data variables.product.prodname_marketplace %} apps, the organization can continue to use the apps, but must pay the vendor directly. For more information, contact the app's vendor.
## Enterprise アカウント内で Organization を作成する

42
translations/ja-JP/content/admin/user-management/migrating-data-to-and-from-your-enterprise/about-migrations.md
View File

@@ -29,24 +29,24 @@ topics:
{% data reusables.enterprise_migrations.fork-persistence %}
| 移行されたリポジトリに関連するデータ | 注釈 |
| ----------------------------- | ------------------------------------------------------------------------------------------------------------- |
| ユーザ | ユーザの**@メンション**は、ターゲットにマッチするよう書き換えられます。 |
| Organization | Organizationの名前と詳細は移行されます。 |
| リポジトリ | Git ツリー、blob、コミット、および行へのリンクは、ターゲットにマッチするよう書き換えられます。 移行者がリダイレクトできるリポジトリの上限は 3 つです。 |
| Wiki | すべてのWikiのデータは移行されます。 |
| Team | チームの**@メンション**はターゲットにマッチするよう書き換えられます。 |
| マイルストーン | タイムスタンプは保持されます。 |
| プロジェクトボード | リポジトリやリポジトリを所有するOrganizationに関連するプロジェクトボードは移行されます。 |
| Issue | Issueへの参照とタイムスタンプは保持されます。 |
| Issueのコメント | コメントへの相互参照は、ターゲットインスタンスに合わせて書き換えられます。 |
| プルリクエスト | プルリクエストへの相互参照はターゲットにマッチするよう書き換えられます。 タイムスタンプは保持されます。 |
| プルリクエストのレビュー | プルリクエストのレビューと関連データは移行されます。 |
| プルリクエストのレビューのコメント | コメントへの相互参照は、ターゲットインスタンスに合わせて書き換えられます。 タイムスタンプは保持されます。 |
| コミットのコメント | コメントへの相互参照は、ターゲットインスタンスに合わせて書き換えられます。 タイムスタンプは保持されます。 |
| リリース | すべてのリリースデータは移行されます。 |
| プルリクエストあるいはIssueに対して行われたアクション | ユーザの割り当て、タイトルの変更、ラベルの変更など、プルリクエストあるいはIssueに対するすべての変更は、それぞれのアクションのタイムスタンプと共に保持されます。 |
| 添付ファイル | [Issue およびプルリクエストの添付ファイル](/articles/file-attachments-on-issues-and-pull-requests)は移行されます。 移行に関するこの機能は無効化できます。 |
| webhook | アクティブなwebhookのみが移行されます。 |
| リポジトリのデプロイキー | リポジトリのデプロイキーは移行されます。 |
| 保護されたブランチ | 保護されたブランチの設定と関連データは移行されます。 |
| 移行されたリポジトリに関連するデータ | 注釈 |
| ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| ユーザ | ユーザの**@メンション**は、ターゲットにマッチするよう書き換えられます。 |
| Organization | Organizationの名前と詳細は移行されます。 |
| リポジトリ | Git ツリー、blob、コミット、および行へのリンクは、ターゲットにマッチするよう書き換えられます。 移行者がリダイレクトできるリポジトリの上限は 3 つです。 Internal repositories are migrated as private repositories. Archive status is unset. |
| Wiki | すべてのWikiのデータは移行されます。 |
| Team | チームの**@メンション**はターゲットにマッチするよう書き換えられます。 |
| マイルストーン | タイムスタンプは保持されます。 |
| プロジェクトボード | リポジトリやリポジトリを所有するOrganizationに関連するプロジェクトボードは移行されます。 |
| Issue | Issueへの参照とタイムスタンプは保持されます。 |
| Issueのコメント | コメントへの相互参照は、ターゲットインスタンスに合わせて書き換えられます。 |
| プルリクエスト | プルリクエストへの相互参照はターゲットにマッチするよう書き換えられます。 タイムスタンプは保持されます。 |
| プルリクエストのレビュー | プルリクエストのレビューと関連データは移行されます。 |
| プルリクエストのレビューのコメント | コメントへの相互参照は、ターゲットインスタンスに合わせて書き換えられます。 タイムスタンプは保持されます。 |
| コミットのコメント | コメントへの相互参照は、ターゲットインスタンスに合わせて書き換えられます。 タイムスタンプは保持されます。 |
| リリース | すべてのリリースデータは移行されます。 |
| プルリクエストあるいはIssueに対して行われたアクション | ユーザの割り当て、タイトルの変更、ラベルの変更など、プルリクエストあるいはIssueに対するすべての変更は、それぞれのアクションのタイムスタンプと共に保持されます。 |
| 添付ファイル | [Issue およびプルリクエストの添付ファイル](/articles/file-attachments-on-issues-and-pull-requests)は移行されます。 移行に関するこの機能は無効化できます。 |
| webhook | アクティブなwebhookのみが移行されます。 |
| リポジトリのデプロイキー | リポジトリのデプロイキーは移行されます。 |
| 保護されたブランチ | 保護されたブランチの設定と関連データは移行されます。 |

9
translations/ja-JP/content/authentication/keeping-your-account-and-data-secure/sudo-mode.md
View File

@@ -41,13 +41,16 @@ After you authenticate to perform a sensitive action, your session is temporaril
To confirm access for sudo mode, you {% ifversion totp-and-mobile-sudo-challenge %}can{% else %}must{% endif %} authenticate with your password.{% ifversion totp-and-mobile-sudo-challenge %} Optionally, you can use a different authentication method, like {% ifversion fpt or ghec %}a security key, {% data variables.product.prodname_mobile %}, or a 2FA code{% elsif ghes %}a security key or a 2FA code{% endif %}.{% endif %}
{% ifversion totp-and-mobile-sudo-challenge %}
{%- ifversion totp-and-mobile-sudo-challenge %}
- [Confirming access using a security key](#confirming-access-using-a-security-key)
{%- ifversion fpt or ghec %}
- [Confirming access using GitHub Mobile](#confirming-access-using-github-mobile)
{%- endif %}
- [Confirming access using a 2FA code](#confirming-access-using-a-2fa-code)
- [Confirming access using your password](#confirming-access-using-your-password)
{%- endif %}
{% ifversion totp-and-mobile-sudo-challenge %}
### Confirming access using a security key
@@ -57,8 +60,6 @@ When prompted to authenticate for sudo mode, click **Use security key**, then fo
![Screenshot of security key option for sudo mode](/assets/images/help/settings/sudo_mode_prompt_security_key.png)
{% endif %}
{% ifversion fpt or ghec %}
### Confirming access using {% data variables.product.prodname_mobile %}
@@ -75,8 +76,6 @@ You must install and sign into {% data variables.product.prodname_mobile %} to c
{% endif %}
{% ifversion totp-and-mobile-sudo-challenge %}
### Confirming access using a 2FA code
You must configure 2FA using a TOTP mobile app{% ifversion fpt or ghec %} or text messages{% endif %} to confirm access to your account for sudo mode using a 2FA code. 詳しい情報については、「[2 要素認証を設定する](/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication)」を参照してください。

6
translations/ja-JP/content/billing/managing-billing-for-your-github-account/about-billing-for-your-enterprise.md
View File

@@ -45,7 +45,11 @@ You can see your current usage in your [Azure account portal](https://portal.azu
{% ifversion ghec %}
{% data variables.product.company_short %} bills monthly for the total number of licensed seats for your organization or enterprise account, as well as any additional services you use with {% data variables.product.prodname_ghe_cloud %}, such as {% data variables.product.prodname_actions %} minutes. For more information about the licensed seats portion of your bill, see "[About per-user pricing](/billing/managing-billing-for-your-github-account/about-per-user-pricing)."
When you use an enterprise account on {% data variables.product.product_location %}, the enterprise account is the central point for all billing within your enterprise, including the organizations that your enterprise owns.
If you use {% data variables.product.product_name %} with an individual organization and do not yet have an enterprise account, you create an enterprise account and add your organization. For more information, see "[Creating an enterprise account](/admin/overview/creating-an-enterprise-account)."
{% data variables.product.company_short %} bills monthly for the total number of licensed seats for your enterprise account, as well as any additional services you use with {% data variables.product.prodname_ghe_cloud %}, such as {% data variables.product.prodname_actions %} minutes. If you use a standalone organization on {% data variables.product.product_name %}, you'll be billed at the organization level for all usage. For more information your bill's license seats, see "[About per-user pricing](/billing/managing-billing-for-your-github-account/about-per-user-pricing)."
{% elsif ghes %}

2
translations/ja-JP/content/billing/managing-your-license-for-github-enterprise/syncing-license-usage-between-github-enterprise-server-and-github-enterprise-cloud.md
View File

@@ -22,6 +22,8 @@ To ensure that you see up-to-date license details on {% data variables.product.p
If you don't want to enable {% data variables.product.prodname_github_connect %}, you can manually sync license usage by uploading a file from {% data variables.product.prodname_ghe_server %} to {% data variables.product.prodname_dotcom_the_website %}.
When you synchronize license usage, only the user ID and email addresses for each user account on {% data variables.product.prodname_ghe_server %} are transmitted to {% data variables.product.prodname_ghe_cloud %}.
{% data reusables.enterprise-licensing.view-consumed-licenses %}
{% data reusables.enterprise-licensing.verified-domains-license-sync %}

77
translations/ja-JP/content/billing/managing-your-license-for-github-enterprise/troubleshooting-license-usage-for-github-enterprise.md
View File

@@ -14,32 +14,57 @@ shortTitle: Troubleshoot license usage
## About unexpected license usage
If the number of consumed licenses for your enterprise is unexpected, you can review your consumed license report to audit your license usage across all your enterprise deployments and subscriptions. If you find errors, you can try troubleshooting steps. For more information about viewing your license usage, see "[Viewing license usage for GitHub Enterprise](/billing/managing-your-license-for-github-enterprise/viewing-license-usage-for-github-enterprise)" and "[Viewing the subscription and usage for your enterprise account](/billing/managing-billing-for-your-github-account/viewing-the-subscription-and-usage-for-your-enterprise-account)."
If the number of consumed licenses for your enterprise is unexpected, you can review your consumed license report to audit your license usage across all your enterprise deployments and subscriptions. For more information, see "[Viewing license usage for GitHub Enterprise](/billing/managing-your-license-for-github-enterprise/viewing-license-usage-for-github-enterprise)" and "[Viewing the subscription and usage for your enterprise account](/billing/managing-billing-for-your-github-account/viewing-the-subscription-and-usage-for-your-enterprise-account)."
For privacy reasons, enterprise owners cannot directly access the details of user accounts.
If you find errors, you can try troubleshooting steps.
For privacy reasons, enterprise owners cannot directly access the details of user accounts unless you use {% data variables.product.prodname_emus %}.
## About the calculation of consumed licenses
{% data variables.product.company_short %} bills for each person who uses deployments of {% data variables.product.prodname_ghe_server %}, is a member of an organization on {% data variables.product.prodname_ghe_cloud %}, or is a {% data variables.product.prodname_vs_subscriber %}. For more information about the people in your enterprise who are counted as consuming a license, see "[About per-user pricing](/billing/managing-billing-for-your-github-account/about-per-user-pricing)."
{% data variables.product.company_short %} bills for each person who uses deployments of {% data variables.product.prodname_ghe_server %}, is a member of one of your organizations on {% data variables.product.prodname_ghe_cloud %}, or is a {% data variables.product.prodname_vs_subscriber %}. For more information about the people in your enterprise who consume a license, see "[About per-user pricing](/billing/managing-billing-for-your-github-account/about-per-user-pricing)."
{% data reusables.enterprise-licensing.about-license-sync %}
For each user to consume a single seat regardless of how many deployments they use, you must synchronize license usage between {% data variables.product.prodname_ghe_server %} and {% data variables.product.prodname_ghe_cloud %}. For more information, see "[Syncing license usage between {% data variables.product.prodname_ghe_server %} and {% data variables.product.prodname_ghe_cloud %}](/billing/managing-your-license-for-github-enterprise/syncing-license-usage-between-github-enterprise-server-and-github-enterprise-cloud)."
After you synchronize license usage, {% data variables.product.prodname_dotcom %} matches user accounts on {% data variables.product.prodname_ghe_server %} with user accounts on {% data variables.product.prodname_ghe_cloud %} by email address.
First, we first check the primary email address of each user on {% data variables.product.prodname_ghe_server %}. Then, we attempt to match that address with the email address for a user account on {% data variables.product.prodname_ghe_cloud %}. If your enterprise uses SAML SSO, we first check the following SAML attributes for email addresses.
- `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name`
- `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress`
- `username`
- `NameID`
- `emails`
If no email addresses found in these attributes match the primary email address on {% data variables.product.prodname_ghe_server %}, or if your enterprise doesn't use SAML SSO, we then check each of the user's verified email addresses on {% data variables.product.prodname_ghe_cloud %}. For more information about verification of email addresses on {% data variables.product.prodname_dotcom_the_website %}, see "[Verifying your email address](/enterprise-cloud@latest/get-started/signing-up-for-github/verifying-your-email-address){% ifversion not ghec %}" in the {% data variables.product.prodname_ghe_cloud %} documentation.{% else %}."{% endif %}
## Fields in the consumed license files
The {% data variables.product.prodname_dotcom_the_website %} license usage report and {% data variables.product.prodname_ghe_server %} exported license usage file include a variety of fields to help you troubleshoot license usage for your enterprise.
### {% data variables.product.prodname_dotcom_the_website %} license usage report (CSV file)
The license usage report for your enterprise is a CSV file that contains the following information about members of your enterprise. Some fields are specific to your {% data variables.product.prodname_ghe_cloud %} (GHEC) deployment, {% data variables.product.prodname_ghe_server %} (GHES) connected environments, or your {% data variables.product.prodname_vs %} subscriptions (VSS) with GitHub Enterprise.
| Field | Description
| ----- | -----------
| Name | First and last name for the user's account on GHEC.
| Handle or email | GHEC username, or the email address associated with the user's account on GHES.
| Profile link | Link to the {% data variables.product.prodname_dotcom_the_website %} profile page for the user's account on GHEC.
| License type | Can be one of: `Visual Studio subscription` or `Enterprise`.
| License status | Identifies if a user account on {% data variables.product.prodname_dotcom_the_website %} successfully matched either a {% data variables.product.prodname_vs_subscriber %} or GHES user.<br><br>Can be one of: `Matched`, `Pending Invitation`, `Server Only`, blank.
| Member roles | For each of the organizations the user belongs to on GHEC, the organization name and the person's role in that organization (`Owner` or `Member`) separated by a colon<br><br>Each organization is delimited by a comma.
| Enterprise role | Can be one of: `Owner` or `Member`.
| github_com_login | The username for the user's GHEC account
| github_com_name | The display name for the user's GHEC account
| github_com_profile | The URL for the user's profile page on GHEC
| github_com_user | Whether or not the user has an account on GHEC |
| github_com_member_roles | For each of the organizations the user belongs to on GHEC, the organization name and the user's role in that organization (`Owner` or `Member`) separated by a colon<br><br>Organizations delimited by commas |
| github_com_enterprise_role | Can be one of: `Owner`, `Member`, or `Outside collaborator`
| github_com_verified_domain_emails | All email addresses associated with the user's GHEC account that match your enterprise's verified domains |
| github_com_saml_name_id | The SAML username |
| github_com_orgs_with_pending_invites | All pending invitations for the user's GHEC account to join organizations within your enterprise |
| license_type | Can be one of: `Visual Studio subscription` or `Enterprise`
| enterprise_server_user| Whether or not the user has at least one account on GHES |
| enterprise_server_primary_emails | The primary email addresses associated with each of the user's GHES accounts |
| enterprise_server_user_ids | For each of the user's GHES accounts, the account's user ID
| total_user_accounts | The total number of accounts the person has across both GHEC and GHES
| visual_studio_subscription_user | Whether or not the user is a {% data variables.product.prodname_vs_subscriber %} |
| visual_studio_subscription_email | The email address associated with the user's VSS |
| visual_studio_license_status | Whether the Visual Studio license has been matched to a {% data variables.product.company_short %} user |
{% data variables.product.prodname_vs_subscriber %}s who are not yet members of at least one organization in your enterprise will be included in the report with a pending invitation status, and will be missing values for the "Name" or "Profile link" field.
@@ -59,32 +84,16 @@ Your {% data variables.product.prodname_ghe_server %} license usage is a JSON fi
## Troubleshooting consumed licenses
If the number of consumed seats is unexpected, or if you've recently removed members from your enterprise, we recommend that you audit your license usage.
To ensure that the each user is only consuming a single seat for different deployments and subscriptions, try the following troubleshooting steps.
To determine which users are currently consuming seat licenses, first try reviewing the consumed licenses report for your enterprise{% ifversion ghes %} and/or an export of your {% data variables.product.prodname_ghe_server %} license usage{% endif %} for unexpected entries.
1. To help identify users that are consuming multiple seats, if your enterprise uses verified domains for {% data variables.product.prodname_ghe_cloud %}, review the list of enterprise members who do not have an email address from a verified domain associated with their account on {% data variables.product.prodname_dotcom_the_website %}. Often, these are the users who erroneously consume more than one licensed seat. For more information, see "[Viewing members without an email address from a verified domain](/admin/user-management/managing-users-in-your-enterprise/viewing-people-in-your-enterprise#viewing-members-without-an-email-address-from-a-verified-domain)."
There are two especially common reasons for inaccurate or incorrect license seat counts.
- The email addresses associated with a user do not match across your enterprise deployments and subscriptions.
- An email address for a user was recently updated or verified to correct a mismatch, but a license sync job hasn't run since the update was made.
{% note %}
When attempting to match users across enterprises, {% data variables.product.company_short %} identifies individuals by the verified email addresses associated with their {% data variables.product.prodname_dotcom_the_website %} account, and the primary email address associated with their {% data variables.product.prodname_ghe_server %} account and/or the email address assigned to the {% data variables.product.prodname_vs_subscriber %}.
**Note:** To make troubleshooting easier, we recommend using verified domains with your enterprise account on {% data variables.product.prodname_dotcom_the_website %}. For more information, see "[Verifying or approving a domain for your enterprise](/enterprise-cloud@latest/admin/configuration/configuring-your-enterprise/verifying-or-approving-a-domain-for-your-enterprise)."
Your license usage is recalculated shortly after each license sync is performed. You can view the timestamp of the last license sync job, and, if a job hasn't run since an email address was updated or verified, to resolve an issue with your consumed license report you can manually trigger one. For more information, see "[Syncing license usage between GitHub Enterprise Server and GitHub Enterprise Cloud](/billing/managing-your-license-for-github-enterprise/syncing-license-usage-between-github-enterprise-server-and-github-enterprise-cloud)."
{% ifversion ghec or ghes %}
If your enterprise uses verified domains, review the list of enterprise members who do not have an email address from a verified domain associated with their {% data variables.product.prodname_dotcom_the_website %} account. Often, these are the users who erroneously consume more than one licensed seat. For more information, see "[Viewing members without an email address from a verified domain](/admin/user-management/managing-users-in-your-enterprise/viewing-people-in-your-enterprise#viewing-members-without-an-email-address-from-a-verified-domain)."
{% endif %}
{% note %}
**Note:** For privacy reasons, your consumed license report only includes the email address associated with a user account on {% data variables.product.prodname_dotcom_the_website %} if the address is hosted by a verified domain. For this reason, we recommend using verified domains with your enterprise account on {% data variables.product.prodname_dotcom_the_website %}. Then, if one person is erroneously consuming multiple licenses, you can more easily troubleshoot, as you will have access to the email address that is being used for license deduplication.
{% endnote %}
{% ifversion ghec %}
If your license includes {% data variables.product.prodname_vss_ghe %} and your enterprise also includes at least one {% data variables.product.prodname_ghe_server %} connected environment, we strongly recommend using {% data variables.product.prodname_github_connect %} to automatically synchronize your license usage. For more information, see "[About Visual Studio subscriptions with GitHub Enterprise](/enterprise-cloud@latest/billing/managing-licenses-for-visual-studio-subscriptions-with-github-enterprise/about-visual-studio-subscriptions-with-github-enterprise)."
{% endif %}
{% endnote %}
1. After you identify users who are consuming multiple seats, make sure that the same email address is associated with all of the user's accounts. For more information about which email addresses must match, see "[About the calculation of consumed licenses](#about-the-calculation-of-consumed-licenses)."
1. If an email address was recently updated or verified to correct a mismatch, view the timestamp of the last license sync job. If a job hasn't run since the correction was made, manually trigger a new job. For more information, see "[Syncing license usage between GitHub Enterprise Server and GitHub Enterprise Cloud](/billing/managing-your-license-for-github-enterprise/syncing-license-usage-between-github-enterprise-server-and-github-enterprise-cloud)."
If you still have questions about your consumed licenses after reviewing the troubleshooting information above, you can contact {% data variables.contact.github_support %} through the {% data variables.contact.contact_enterprise_portal %}.

13
translations/ja-JP/content/billing/managing-your-license-for-github-enterprise/viewing-license-usage-for-github-enterprise.md
View File

@@ -14,21 +14,20 @@ shortTitle: View license usage
## About license usage for {% data variables.product.prodname_enterprise %}
{% ifversion ghec %}
You can view license usage for {% data variables.product.product_name %} on {% data variables.product.product_location %}.
You can view license usage for your enterprise account on {% data variables.product.prodname_ghe_cloud %} on {% data variables.product.prodname_dotcom_the_website %}.
If you use both {% data variables.product.prodname_ghe_cloud %} and {% data variables.product.prodname_ghe_server %} and sync license usage between the products, you can view license usage for both on {% data variables.product.prodname_dotcom_the_website %}. For more information about license sync, see "[Syncing license usage between {% data variables.product.prodname_ghe_server %} and {% data variables.product.prodname_ghe_cloud %}](/billing/managing-your-license-for-github-enterprise/syncing-license-usage-between-github-enterprise-server-and-github-enterprise-cloud)."
{% data reusables.enterprise-licensing.you-can-sync-for-a-combined-view %}
{% ifversion ghes %}
{% elsif ghes %}
For more information about viewing license usage on {% data variables.product.prodname_dotcom_the_website %} and identifying when the last license sync occurred, see "[Viewing license usage for {% data variables.product.prodname_enterprise %}](/enterprise-cloud@latest/billing/managing-your-license-for-github-enterprise/viewing-license-usage-for-github-enterprise)" in the {% data variables.product.prodname_ghe_cloud %} documentation.
You can view license usage for {% data variables.product.prodname_ghe_server %} on {% data variables.product.product_location %}.
{% endif %}
{% data reusables.enterprise-licensing.you-can-sync-for-a-combined-view %} For more information about the display of license usage on {% data variables.product.prodname_dotcom_the_website %} and identifying when the last license sync occurred, see "[Viewing license usage for {% data variables.product.prodname_enterprise %}](/enterprise-cloud@latest/billing/managing-your-license-for-github-enterprise/viewing-license-usage-for-github-enterprise)" in the {% data variables.product.prodname_ghe_cloud %} documentation.
You can also use the REST API to return consumed licenses data and the status of the license sync job. For more information, see "[GitHub Enterprise administration](/enterprise-cloud@latest/rest/enterprise-admin/license)" in the REST API documentation.
To learn more about the license data associated with your enterprise account and how the number of consumed user seats are calculated, see "[Troubleshooting license usage for GitHub Enterprise](/billing/managing-your-license-for-github-enterprise/troubleshooting-license-usage-for-github-enterprise)."
{% endif %}
## Viewing license usage on {% ifversion ghec %}{% data variables.product.prodname_dotcom_the_website %}{% elsif ghes %}{% data variables.product.product_location %}{% endif %}

8
translations/ja-JP/content/code-security/code-scanning/integrating-with-code-scanning/uploading-a-sarif-file-to-github.md
View File

@@ -51,10 +51,10 @@ To use {% data variables.product.prodname_actions %} to upload a third-party SAR
Your workflow will need to use the `upload-sarif` action, which is part of the `github/codeql-action` repository. It has input parameters that you can use to configure the upload. The main input parameters you'll use are:
- `sarif-file`, which configures the file or directory of SARIF files to be uploaded. The directory or file path is relative to the root of the repository.
- `sarif-file`, which configures the file or directory of SARIF files to be uploaded. The directory or file path is relative to the root of the repository.
- `category` (optional), which assigns a category for results in the SARIF file. This enables you to analyze the same commit in multiple ways and review the results using the {% data variables.product.prodname_code_scanning %} views in {% data variables.product.prodname_dotcom %}. For example, you can analyze using multiple tools, and in mono-repos, you can analyze different slices of the repository based on the subset of changed files.
For more information see the [`upload-sarif` action](https://github.com/github/codeql-action/tree/v1/upload-sarif).
For more information see the [`upload-sarif` action](https://github.com/github/codeql-action/tree/{% ifversion actions-node16-action %}v2{% else %}v1{% endif %}/upload-sarif).
The `upload-sarif` action can be configured to run when the `push` and `scheduled` event occur. For more information about {% data variables.product.prodname_actions %} events, see "[Events that trigger workflows](/actions/reference/events-that-trigger-workflows)."
@@ -66,7 +66,7 @@ If your SARIF file doesn't include `partialFingerprints`, the `upload-sarif` act
You can create a new workflow that uploads SARIF files after you commit them to your repository. This is useful when the SARIF file is generated as an artifact outside of your repository.
This example workflow runs anytime commits are pushed to the repository. The action uses the `partialFingerprints` property to determine if changes have occurred. In addition to running when commits are pushed, the workflow is scheduled to run once per week. For more information, see "[Events that trigger workflows](/actions/reference/events-that-trigger-workflows)."
This example workflow runs anytime commits are pushed to the repository. The action uses the `partialFingerprints` property to determine if changes have occurred. In addition to running when commits are pushed, the workflow is scheduled to run once per week. For more information, see "[Events that trigger workflows](/actions/reference/events-that-trigger-workflows)."
This workflow uploads the `results.sarif` file located in the root of the repository. For more information about creating a workflow file, see "[Learn {% data variables.product.prodname_actions %}](/actions/learn-github-actions)."
@@ -109,7 +109,7 @@ jobs:
If you generate your third-party SARIF file as part of a continuous integration (CI) workflow, you can add the `upload-sarif` action as a step after running your CI tests. If you don't already have a CI workflow, you can create one using a {% data variables.product.prodname_actions %} template. For more information, see the "[{% data variables.product.prodname_actions %} quickstart](/actions/quickstart)."
This example workflow runs anytime commits are pushed to the repository. The action uses the `partialFingerprints` property to determine if changes have occurred. In addition to running when commits are pushed, the workflow is scheduled to run once per week. For more information, see "[Events that trigger workflows](/actions/reference/events-that-trigger-workflows)."
This example workflow runs anytime commits are pushed to the repository. The action uses the `partialFingerprints` property to determine if changes have occurred. In addition to running when commits are pushed, the workflow is scheduled to run once per week. For more information, see "[Events that trigger workflows](/actions/reference/events-that-trigger-workflows)."
The workflow shows an example of running the ESLint static analysis tool as a step in a workflow. The `Run ESLint` step runs the ESLint tool and outputs the `results.sarif` file. The workflow then uploads the `results.sarif` file to {% data variables.product.prodname_dotcom %} using the `upload-sarif` action. For more information about creating a workflow file, see "[Introduction to GitHub Actions](/actions/learn-github-actions/introduction-to-github-actions)."

15
translations/ja-JP/content/code-security/secret-scanning/defining-custom-patterns-for-secret-scanning.md
View File

@@ -67,9 +67,10 @@ topics:
{% data reusables.repositories.navigate-to-code-security-and-analysis %}
{% data reusables.repositories.navigate-to-ghas-settings %}
{% data reusables.advanced-security.secret-scanning-new-custom-pattern %}
{% data reusables.advanced-security.secret-scanning-add-custom-pattern-details %}{% ifversion secret-scanning-custom-enterprise-35 %}
{% data reusables.advanced-security.secret-scanning-add-custom-pattern-details %}{% ifversion secret-scanning-custom-enterprise-35 or custom-pattern-dry-run-ga %}
1. 新しいカスタムパターンをテストする準備ができたら、アラートを作成することなくリポジトリ内のマッチを特定するために、**Save and dry run（保存してdry run）**をクリックしてください。
{% data reusables.advanced-security.secret-scanning-dry-run-results %}
{%- ifversion secret-scanning-custom-enterprise-35 %}{% indented_data_reference reusables.secret-scanning.beta-dry-runs spaces=3 %}{% endif %}
{% endif %}
{% data reusables.advanced-security.secret-scanning-create-custom-pattern %}
@@ -122,10 +123,11 @@ aAAAe9
{% data reusables.repositories.navigate-to-ghas-settings %}
{% data reusables.advanced-security.secret-scanning-new-custom-pattern %}
{% data reusables.advanced-security.secret-scanning-add-custom-pattern-details %}
{%- ifversion secret-scanning-custom-enterprise-35 %}
{%- ifversion secret-scanning-custom-enterprise-35 or custom-pattern-dry-run-ga %}
1. 新しいカスタムパターンをテストする準備ができたら、アラートを作成することなく選択したリポジトリ内のマッチを特定するために、**Save and dry run（保存してdry run）**をクリックしてください。
{% data reusables.advanced-security.secret-scanning-dry-run-select-repos %}
{% data reusables.advanced-security.secret-scanning-dry-run-results %}
{%- ifversion secret-scanning-custom-enterprise-35 %}{% indented_data_reference reusables.secret-scanning.beta-dry-runs spaces=3 %}{% endif %}
{%- endif %}
{% data reusables.advanced-security.secret-scanning-create-custom-pattern %}
@@ -141,7 +143,7 @@ aAAAe9
{% note %}
{% ifversion secret-scanning-custom-enterprise-36 %}
{% ifversion secret-scanning-custom-enterprise-36 or custom-pattern-dry-run-ga %}
**ノート:**
- Enterpriseレベルでは、カスタムパターンを編集でき、dry runで使えるのはカスタムパターンの作者だけです。
- Enterpriseオーナーは、アクセスできるリポジトリ上でのみdry runを利用できますが、必ずしもEnterprise内のすべてのOrganizationやリポジトリにアクセスできるわけではありません。
@@ -158,10 +160,11 @@ aAAAe9
{% data reusables.enterprise-accounts.advanced-security-security-features %}
1. "Secret scanning custom patterns（シークレットスキャンニングのカスタムパターン）"の下で、{% ifversion ghes = 3.2 %}**New custom pattern（新規カスタムパターン）**{% else %}**New pattern（新規パターン）**{% endif %}をクリックしてください。
{% data reusables.advanced-security.secret-scanning-add-custom-pattern-details %}
{%- ifversion secret-scanning-custom-enterprise-36 %}
{%- ifversion secret-scanning-custom-enterprise-36 or custom-pattern-dry-run-ga %}
1. 新しいカスタムパターンをテストする準備ができたら、アラートを作成することなくEnterprise内のマッチを特定するために、**Save and dry run（保存してdry run）**をクリックしてください。
{% data reusables.advanced-security.secret-scanning-dry-run-select-repos %}
{% data reusables.advanced-security.secret-scanning-dry-run-select-enterprise-repos %}
{% data reusables.advanced-security.secret-scanning-dry-run-results %}
{%- ifversion secret-scanning-custom-enterprise-36 %}{% indented_data_reference reusables.secret-scanning.beta-dry-runs spaces=3 %}{% endif %}
{%- endif %}
{% data reusables.advanced-security.secret-scanning-create-custom-pattern %}
@@ -175,7 +178,7 @@ aAAAe9
* リポジトリあるいはOrganizationの場合は、カスタムパターンが作成されたリポジトリもしくはOrganizationの"Security & analysis（セキュリティと分析）" 設定を表示させてください。 詳しい情報については上の「[リポジトリのカスタムパターンの定義](#defining-a-custom-pattern-for-a-repository)」あるいは「[Organizationのカスタムパターンの定義](#defining-a-custom-pattern-for-an-organization)」を参照してください。
* Enterpriseの場合は、"Policies（ポリシー）"の下で"Advanced Security（高度なセキュリティ）"を表示させ、**Security features（セキュリティの機能）**をクリックしてください。 詳しい情報については、上記の「[Enterpriseアカウントでのカスタムパターンの定義](#defining-a-custom-pattern-for-an-enterprise-account)」を参照してください。
2. "{% data variables.product.prodname_secret_scanning_caps %}"の下で、編集したいカスタムパターンの右の{% octicon "pencil" aria-label="The edit icon" %}をクリックしてください。
{%- ifversion secret-scanning-custom-enterprise-36 %}
{%- ifversion secret-scanning-custom-enterprise-36 or custom-pattern-dry-run-ga %}
3. 編集された新しいカスタムパターンをテストする準備ができたら、アラートを作成することなくマッチを特定するために、**Save and dry run（保存してdry run）**をクリックしてください。
{%- endif %}
4. 変更をレビューしてテストしたら、**Save changes（変更を保存）**をクリックしてください。

2
translations/ja-JP/content/code-security/supply-chain-security/understanding-your-software-supply-chain/exploring-the-dependencies-of-a-repository.md
View File

@@ -110,7 +110,7 @@ Dependency submission API（ベータ）を使ってプロジェクトにサブ
## 参考リンク
- [依存関係グラフについて](/github/visualizing-repository-data-with-graphs/about-the-dependency-graph)
- "[Viewing and updating {% data variables.product.prodname_dependabot_alerts %}](/code-security/dependabot/dependabot-alerts/viewing-and-updating-dependabot-alerts)"{% ifversion ghec %}
- 「[{% data variables.product.prodname_dependabot_alerts %}の表示と更新](/code-security/dependabot/dependabot-alerts/viewing-and-updating-dependabot-alerts)」{% ifversion ghec %}
- 「[Organizationのインサイトの表示](/organizations/collaborating-with-groups-in-organizations/viewing-insights-for-your-organization)」{% endif %}{% ifversion fpt or ghec %}
- [{% data variables.product.prodname_dotcom %}によるデータの利用と保護の方法の理解](/get-started/privacy-on-github)
{% endif %}

2
translations/ja-JP/content/codespaces/codespaces-reference/security-in-github-codespaces.md
View File

@@ -107,7 +107,7 @@ There are some additional good practices and risks that you should be aware of w
When you create a codespace, if a `devcontainer.json` file is found for your repository, it is parsed and used to configure your codespace. The `devcontainer.json` file can contain powerful features, such as installing third-party extensions and running arbitrary code supplied in a `postCreateCommand`.
For more information, see "[Introduction to dev containers](/codespaces/setting-up-your-project-for-codespaces/introduction-to-dev-containers)."
詳しい情報については「[開発コンテナの紹介](/codespaces/setting-up-your-project-for-codespaces/introduction-to-dev-containers)」を参照してください。
#### Granting access through features

19
translations/ja-JP/content/codespaces/developing-in-codespaces/connecting-to-a-private-network.md
View File

@@ -18,11 +18,26 @@ By default, your codespaces have access to all resources on the public internet,
## Connecting to resources on a private network
The currently supported method of accessing resources on a private network is to use a VPN. It is currently not recommended to allowlist codespaces IPs as this would allow all codespaces (both yours and those of other customers) access to the network protected resources.
There are currently two methods of accessing resources on a private network within Codespaces.
- Using a {% data variables.product.prodname_cli %} extension to configure your local machine as a gateway to remote resources.
- Using a VPN.
### Using the GitHub CLI extension to access remote resources
{% note %}
**Note**: The {% data variables.product.prodname_cli %} extension is currently in beta and subject to change.
{% endnote %}
The {% data variables.product.prodname_cli %} extension allows you to create a bridge between a codespace and your local machine, so that the codespace can access any remote resource that is accessible from your machine. The codespace uses your local machine as a network gateway to reach those resources. For more information, see "[Using {% data variables.product.prodname_cli %} to access remote resources](https://github.com/github/gh-net#codespaces-network-bridge)."
### Using a VPN to access resources behind a private network
The easiest way to access resources behind a private network is to VPN into that network from within your codespace.
As an alternative to the {% data variables.product.prodname_cli %} extension, you can use a VPN to access resources behind a private network from within your codespace.
We recommend VPN tools like [OpenVPN](https://openvpn.net/) to access resources on a private network. For more information, see "[Using the OpenVPN client from GitHub Codespaces](https://github.com/codespaces-contrib/codespaces-openvpn)."

10
translations/ja-JP/content/codespaces/developing-in-codespaces/using-github-codespaces-with-github-cli.md
View File

@@ -30,6 +30,7 @@ You can work with {% data variables.product.prodname_codespaces %} in the {% da
- [Copy a file to/from a codespace](#copy-a-file-tofrom-a-codespace)
- [Modify ports in a codespace](#modify-ports-in-a-codespace)
- [Access codespace logs](#access-codespace-logs)
- [Access remote resources](#access-remote-resources)
## {% data variables.product.prodname_cli %}のインストール
@@ -193,3 +194,12 @@ gh codespace logs -c <em>codespace-name</em>
```
For more information about the creation log, see "[{% data variables.product.prodname_github_codespaces %} logs](/codespaces/troubleshooting/github-codespaces-logs#creation-logs)."
### Access remote resources
You can use the {% data variables.product.prodname_cli %} extension to create a bridge between a codespace and your local machine, so that the codespace can access any remote resource that is accessible from your machine. For more information on using the extension, see "[Using {% data variables.product.prodname_cli %} to access remote resources](https://github.com/github/gh-net#codespaces-network-bridge)."
{% note %}
**Note**: The {% data variables.product.prodname_cli %} extension is currently in beta and subject to change.
{% endnote %}

16
translations/ja-JP/content/codespaces/prebuilding-your-codespaces/about-github-codespaces-prebuilds.md
View File

@@ -22,6 +22,14 @@ When prebuilds are available for a particular branch of a repository, a particul
![The dialog box for choosing a machine type](/assets/images/help/codespaces/choose-custom-machine-type.png)
## The prebuild process
To create a prebuild you set up a prebuild configuration. When you save the configuration, a {% data variables.product.prodname_actions %} workflow runs to create each of the required prebuilds; one workflow per prebuild. Workflows also run whenever the prebuilds for your configuration need to be updated. This can happen at scheduled intervals, on pushes to a prebuild-enabled repository, or when you change the dev container configuration. 詳しい情報については「[事前ビルドの設定](/codespaces/prebuilding-your-codespaces/configuring-prebuilds#configuring-a-prebuild)」を参照してください。
When a prebuild configuration workflow runs, {% data variables.product.prodname_dotcom %} creates a temporary codespace, performing setup operations up to and including any `onCreateCommand` and `updateContentCommand` commands in the `devcontainer.json` file. No `postCreateCommand` commands are run during the creation of a prebuild. For more information about these commands, see the [`devcontainer.json` reference](https://code.visualstudio.com/docs/remote/devcontainerjson-reference#_devcontainerjson-properties) in the {% data variables.product.prodname_vscode_shortname %} documentation. A snapshot of the generated container is then taken and stored.
When you create a codespace from a prebuild, {% data variables.product.prodname_dotcom %} downloads the existing container snapshot from storage and deploys it on a fresh virtual machine, completing the remaining commands specified in the dev container configuration. Since many operations have already been performed, such as cloning the repository, creating a codespace from a prebuild can be substantially quicker than creating one without a prebuild. This is true where the repository is large and/or `onCreateCommand` commands take a long time to run.
## About billing for {% data variables.product.prodname_codespaces %} prebuilds
{% data reusables.codespaces.billing-for-prebuilds-default %} For details of {% data variables.product.prodname_codespaces %} storage pricing, see "[About billing for {% data variables.product.prodname_github_codespaces %}](/billing/managing-billing-for-github-codespaces/about-billing-for-github-codespaces)."
@@ -32,15 +40,15 @@ Use of codespaces created using prebuilds is charged at the same rate as regular
## About pushing changes to prebuild-enabled branches
By default, each push to a branch that has a prebuild configuration results in a {% data variables.product.prodname_dotcom %}-managed Actions workflow run to update the prebuild template. The prebuild workflow has a concurrency limit of one workflow run at a time for a given prebuild configuration, unless changes were made that affect the dev container configuration for the associated repository. For more information, see "[Introduction to dev containers](/codespaces/setting-up-your-project-for-codespaces/introduction-to-dev-containers)." If a run is already in progress, the workflow run that was queued most recently queued will run next, after the current run completes.
By default, each push to a branch that has a prebuild configuration results in a {% data variables.product.prodname_dotcom %}-managed Actions workflow run to update the prebuild. The prebuild workflow has a concurrency limit of one workflow run at a time for a given prebuild configuration, unless changes were made that affect the dev container configuration for the associated repository. 詳しい情報については「[開発コンテナの紹介](/codespaces/setting-up-your-project-for-codespaces/introduction-to-dev-containers)」を参照してください。 If a run is already in progress, the workflow run that was queued most recently queued will run next, after the current run completes.
With the prebuild template set to be updated on each push, it means that if there are very frequent pushes to your repository, prebuild template updates will occur at least as often as it takes to run the prebuild workflow. That is, if your workflow run typically takes one hour to complete, prebuilds will be created for your repository roughly hourly, if the run succeeds, or more often if there were pushes that change the dev container configuration on the branch.
With the prebuild set to be updated on each push, it means that if there are very frequent pushes to your repository, prebuild updates will occur at least as often as it takes to run the prebuild workflow. That is, if your workflow run typically takes one hour to complete, prebuilds will be created for your repository roughly hourly, if the run succeeds, or more often if there were pushes that change the dev container configuration on the branch.
For example, let's imagine 5 pushes are made, in quick succession, against a branch that has a prebuild configuration. In this situation:
* A workflow run is started for the first push, to update the prebuild template.
* A workflow run is started for the first push, to update the prebuild.
* If the 4 remaining pushes do not affect the dev container configuration, the workflow runs for these are queued in a "pending" state.
If any of the remaining 4 pushes change the dev container configuration, then the service will not skip that one and will immediately run the prebuild creation workflow, updating the prebuild accordingly if it succeeds.
* Once the first run completes, workflow runs for pushes 2, 3, and 4 will be canceled, and the last queued workflow (for push 5) will run and update the prebuild template.
* Once the first run completes, workflow runs for pushes 2, 3, and 4 will be canceled, and the last queued workflow (for push 5) will run and update the prebuild.

4
translations/ja-JP/content/codespaces/prebuilding-your-codespaces/allowing-a-prebuild-to-access-other-repositories.md
View File

@@ -1,7 +1,7 @@
---
title: Allowing a prebuild to access other repositories
shortTitle: Allow external repo access
intro: 'You can permit your prebuild template access to other {% data variables.product.prodname_dotcom %} repositories so that it can be built successfully.'
intro: 'You can permit your prebuild to access other {% data variables.product.prodname_dotcom %} repositories so that it can be built successfully.'
versions:
fpt: '*'
ghec: '*'
@@ -55,7 +55,7 @@ You will need to create a new personal account and then use this account to crea
1. Sign back into the account that has admin access to the repository.
1. In the repository for which you want to create {% data variables.product.prodname_codespaces %} prebuilds, create a new {% data variables.product.prodname_codespaces %} repository secret called `CODESPACES_PREBUILD_TOKEN`, giving it the value of the token you created and copied. For more information, see "[Managing encrypted secrets for your repository and organization for {% data variables.product.prodname_github_codespaces %}](/codespaces/managing-codespaces-for-your-organization/managing-encrypted-secrets-for-your-repository-and-organization-for-github-codespaces#adding-secrets-for-a-repository)."
The PAT will be used for all subsequent prebuild templates created for your repository. Unlike other {% data variables.product.prodname_codespaces %} repository secrets, the `CODESPACES_PREBUILD_TOKEN` secret is only used for prebuilding and will not be available to use in codespaces created from your repository.
The PAT will be used for all subsequent prebuilds created for your repository. Unlike other {% data variables.product.prodname_codespaces %} repository secrets, the `CODESPACES_PREBUILD_TOKEN` secret is only used for prebuilding and will not be available to use in codespaces created from your repository.
## 参考リンク

28
translations/ja-JP/content/codespaces/prebuilding-your-codespaces/configuring-prebuilds.md
View File

@@ -15,7 +15,7 @@ permissions: People with admin access to a repository can configure prebuilds fo
You can set up a prebuild configuration for the combination of a specific branch of your repository with a specific dev container configuration file.
Any branches created from a prebuild-enabled parent branch will typically also get prebuilds for the same dev container configuration. This is because the prebuild template for child branches that use the same dev container configuration as the parent branch are, for the most part, identical, so developers can benefit from faster codespace creation times on those branches also. For more information, see "[Introduction to dev containers](/codespaces/setting-up-your-project-for-codespaces/introduction-to-dev-containers)."
Any branches created from a prebuild-enabled parent branch will typically also get prebuilds for the same dev container configuration. This is because the prebuild for child branches that use the same dev container configuration as the parent branch are, for the most part, identical, so developers can benefit from faster codespace creation times on those branches also. For more information, see "[Introduction to dev containers](/codespaces/setting-up-your-project-for-codespaces/introduction-to-dev-containers)."
Typically, when you configure prebuilds for a branch, prebuilds will be available for multiple machine types. However, if your repository is greater than 32 GB, prebuilds won't be available for 2-core and 4-core machine types, since the storage these provide is limited to 32 GB.
@@ -44,37 +44,37 @@ Before you can configure prebuilds for your project the following must be true:
{% endnote %}
1. Optionally, in the **Configuration file** drop-down menu that's displayed, choose the `devcontainer.json` configuration file that you want to use for this prebuild template. For more information, see "[Introduction to dev containers](/codespaces/setting-up-your-project-for-codespaces/introduction-to-dev-containers#devcontainerjson)."
1. Optionally, in the **Configuration file** drop-down menu that's displayed, choose the `devcontainer.json` configuration file that you want to use for this prebuild. For more information, see "[Introduction to dev containers](/codespaces/setting-up-your-project-for-codespaces/introduction-to-dev-containers#devcontainerjson)."
![The configuration file drop-down menu](/assets/images/help/codespaces/prebuilds-choose-configfile.png)
1. Choose how you want to automatically trigger updates of the prebuild template.
1. Choose how you want to automatically trigger updates of the prebuild.
* **Every push** (the default setting) - With this setting, prebuild configurations will be updated on every push made to the given branch. This will ensure that codespaces generated from a prebuild template always contain the latest codespace configuration, including any recently added or updated dependencies.
* **On configuration change** - With this setting, prebuild configurations will be updated every time associated configuration files for a given repo and branch are updated. This ensures that changes to the dev container configuration files for the repository are used when a codespace is generated from a prebuild template. The Actions workflow that updates the prebuild template will run less often, so this option will use fewer Actions minutes. However, this option will not guarantee that codespaces always include recently added or updated dependencies, so these may have to be added or updated manually after a codespace has been created.
* **Every push** (the default setting) - With this setting, prebuild configurations will be updated on every push made to the given branch. This will ensure that codespaces generated from a prebuild always contain the latest codespace configuration, including any recently added or updated dependencies.
* **On configuration change** - With this setting, prebuild configurations will be updated every time associated configuration files for a given repo and branch are updated. This ensures that changes to the dev container configuration files for the repository are used when a codespace is generated from a prebuild. The Actions workflow that updates the prebuild will run less often, so this option will use fewer Actions minutes. However, this option will not guarantee that codespaces always include recently added or updated dependencies, so these may have to be added or updated manually after a codespace has been created.
* **Scheduled** - With this setting, you can have your prebuild configurations update on a custom schedule that's defined by you. This can reduce consumption of Actions minutes, however, with this option, codespaces may be created that do not use the latest dev container configuration changes.
![The prebuild trigger options](/assets/images/help/codespaces/prebuilds-triggers.png)
1. Optionally, select **Reduce prebuild available to only specific regions** to limit access to your prebuild template, then select which regions you want it to be available in. Developers can only create codespaces from a prebuild if they are located in a region you select. By default, your prebuild template is available to all regions where codespaces is available and storage costs apply for each region.
1. Optionally, select **Reduce prebuild available to only specific regions** to limit access to your prebuild, then select which regions you want it to be available in. Developers can only create codespaces from a prebuild if they are located in a region you select. By default, your prebuild is available to all regions where codespaces is available and storage costs apply for each region.
![The region selection options](/assets/images/help/codespaces/prebuilds-regions.png)
{% note %}
**Notes**:
* The prebuild template for each region will incur individual charges. You should, therefore, only enable prebuilds for regions in which you know they'll be used. For more information, see "[About {% data variables.product.prodname_github_codespaces %} prebuilds](/codespaces/prebuilding-your-codespaces/about-github-codespaces-prebuilds#about-billing-for-codespaces-prebuilds)."
* The prebuild for each region will incur individual charges. You should, therefore, only enable prebuilds for regions in which you know they'll be used. For more information, see "[About {% data variables.product.prodname_github_codespaces %} prebuilds](/codespaces/prebuilding-your-codespaces/about-github-codespaces-prebuilds#about-billing-for-codespaces-prebuilds)."
* Developers can set their default region for {% data variables.product.prodname_codespaces %}, which can allow you to enable prebuilds for fewer regions. For more information, see "[Setting your default region for {% data variables.product.prodname_github_codespaces %}](/codespaces/customizing-your-codespace/setting-your-default-region-for-github-codespaces)."
{% endnote %}
1. Optionally, set the number of prebuild template versions to be retained. You can input any number between 1 and 5. The default number of saved versions is 2, which means that only the latest template version and the previous version are saved.
1. Optionally, set the number of prebuild versions to be retained. You can input any number between 1 and 5. The default number of saved versions is 2, which means that only the latest template version and the previous version are saved.
Depending on your prebuild trigger settings, your prebuild template could change with each push or on each dev container configuration change. Retaining older versions of prebuild templates enables you to create a prebuild from an older commit with a different dev container configuration than the current prebuild template. Since there is a storage cost associated with retaining prebuild template versions, you can choose the number of versions to be retained based on the needs of your team. For more information on billing, see "[About billing for {% data variables.product.prodname_github_codespaces %}](/billing/managing-billing-for-github-codespaces/about-billing-for-github-codespaces#codespaces-pricing)."
Depending on your prebuild trigger settings, your prebuild could change with each push or on each dev container configuration change. Retaining older versions of prebuilds enables you to create a prebuild from an older commit with a different dev container configuration than the current prebuild. Since there is a storage cost associated with retaining prebuild versions, you can choose the number of versions to be retained based on the needs of your team. For more information on billing, see "[About billing for {% data variables.product.prodname_github_codespaces %}](/billing/managing-billing-for-github-codespaces/about-billing-for-github-codespaces#codespaces-pricing)."
If you set the number of prebuild template versions to save to 1, {% data variables.product.prodname_codespaces %} will only save the latest version of the prebuild template and will delete the older version each time the template is updated. This means you will not get a prebuilt codespace if you go back to an older dev container configuration.
If you set the number of prebuild versions to save to 1, {% data variables.product.prodname_codespaces %} will only save the latest version of the prebuild and will delete the older version each time the template is updated. This means you will not get a prebuilt codespace if you go back to an older dev container configuration.
![The prebuild template history setting](/assets/images/help/codespaces/prebuilds-template-history-setting.png)
![The prebuild history setting](/assets/images/help/codespaces/prebuilds-template-history-setting.png)
1. Optionally, add users or teams to notify when the prebuild workflow run fails for this configuration. You can begin typing a username, team name, or full name, then click the name once it appears to add them to the list. The users or teams you add will receive an email when prebuild failures occur, containing a link to the workflow run logs to help with further investigation.
@@ -84,7 +84,7 @@ Before you can configure prebuilds for your project the following must be true:
{% data reusables.codespaces.prebuilds-permission-authorization %}
After you create a prebuild configuration it is listed on the {% data variables.product.prodname_codespaces %} page of your repository settings. A {% data variables.product.prodname_actions %} workflow is queued and then run to create prebuild templates in the regions you specified, based on the branch and dev container configuration file you selected.
After you create a prebuild configuration it is listed on the {% data variables.product.prodname_codespaces %} page of your repository settings. A {% data variables.product.prodname_actions %} workflow is queued and then run to create prebuilds in the regions you specified, based on the branch and dev container configuration file you selected.
![Screenshot of the list of prebuild configurations](/assets/images/help/codespaces/prebuild-configs-list.png)
@@ -100,9 +100,9 @@ Prebuilds cannot use any user-level secrets while building your environment, bec
## Configuring time-consuming tasks to be included in the prebuild
You can use the `onCreateCommand` and `updateContentCommand` commands in your `devcontainer.json` to include time-consuming processes as part of the prebuild template creation. For more information, see the {% data variables.product.prodname_vscode %} documentation, "[devcontainer.json reference](https://code.visualstudio.com/docs/remote/devcontainerjson-reference#_lifecycle-scripts)."
You can use the `onCreateCommand` and `updateContentCommand` commands in your `devcontainer.json` to include time-consuming processes as part of the prebuild creation. For more information, see the {% data variables.product.prodname_vscode %} documentation, "[devcontainer.json reference](https://code.visualstudio.com/docs/remote/devcontainerjson-reference#_lifecycle-scripts)."
`onCreateCommand` is run only once, when the prebuild template is created, whereas `updateContentCommand` is run at template creation and at subsequent template updates. Incremental builds should be included in `updateContentCommand` since they represent the source of your project and need to be included for every prebuild template update.
`onCreateCommand` is run only once, when the prebuild is created, whereas `updateContentCommand` is run at template creation and at subsequent template updates. Incremental builds should be included in `updateContentCommand` since they represent the source of your project and need to be included for every prebuild update.
## Further reading

8
translations/ja-JP/content/codespaces/prebuilding-your-codespaces/managing-prebuilds.md
View File

@@ -16,7 +16,7 @@ miniTocMaxHeadingLevel: 3
The prebuilds that you configure for a repository are created and updated using a {% data variables.product.prodname_actions %} workflow, managed by the {% data variables.product.prodname_github_codespaces %} service.
Depending on the settings in a prebuild configuration, the workflow to update the prebuild template may be triggered by these events:
Depending on the settings in a prebuild configuration, the workflow to update the prebuild may be triggered by these events:
* Creating or updating the prebuild configuration
* Pushing a commit or a pull request to a branch that's configured to have prebuilds
@@ -24,7 +24,7 @@ Depending on the settings in a prebuild configuration, the workflow to update th
* A schedule that you've defined in the prebuild configuration
* Manually triggering the workflow
The settings in the prebuild configuration determine which events automatically trigger an update of the prebuild template. 詳しい情報については「[事前ビルドの設定](/codespaces/prebuilding-your-codespaces/configuring-prebuilds#configuring-a-prebuild)」を参照してください。
The settings in the prebuild configuration determine which events automatically trigger an update of the prebuild. 詳しい情報については「[事前ビルドの設定](/codespaces/prebuilding-your-codespaces/configuring-prebuilds#configuring-a-prebuild)」を参照してください。
People with admin access to a repository can check the progress of prebuilds, edit, and delete prebuild configurations.
@@ -61,7 +61,7 @@ This displays the workflow run history for prebuilds for the associated branch.
### Disabling a prebuild configuration
To pause the update of prebuild templates for a configuration, you can disable workflow runs for the configuration. Disabling the workflow runs for a prebuild configuration does not delete any previously created prebuild templates for that configuration and, as a result, codespaces will continue to be generated from an existing prebuild template.
To pause the update of prebuilds for a configuration, you can disable workflow runs for the configuration. Disabling the workflow runs for a prebuild configuration does not delete any previously created prebuilds for that configuration and, as a result, codespaces will continue to be generated from an existing prebuild.
Disabling the workflow runs for a prebuild configuration is useful if you need to investigate template creation failures.
@@ -74,7 +74,7 @@ Disabling the workflow runs for a prebuild configuration is useful if you need t
### Deleting a prebuild configuration
Deleting a prebuild configuration also deletes all previously created prebuild templates for that configuration. As a result, shortly after you delete a configuration, prebuilds generated by that configuration will no longer be available when you create a new codespace.
Deleting a prebuild configuration also deletes all previously created prebuilds for that configuration. As a result, shortly after you delete a configuration, prebuilds generated by that configuration will no longer be available when you create a new codespace.
After you delete a prebuild configuration, workflow runs for that configuration that have been queued or started will still run. They will be listed in the workflow run history, along with previously completed workflow runs.

8
translations/ja-JP/content/codespaces/prebuilding-your-codespaces/testing-dev-container-changes.md
View File

@@ -14,17 +14,17 @@ product: '{% data reusables.gated-features.codespaces %}'
permissions: People with write permissions to a repository can create or edit the dev container configuration for a branch.
---
Any changes you make to the dev container configuration for a prebuild-enabled branch will result in an update to the codespace configuration and the associated prebuild template. It’s therefore important to test such changes in a codespace from a test branch before committing your changes to a branch of your repository that's actively used. This will ensure you’re not introducing breaking changes for your team.
Any changes you make to the dev container configuration for a prebuild-enabled branch will result in an update to the codespace configuration and the associated prebuild. It’s therefore important to test such changes in a codespace from a test branch before committing your changes to a branch of your repository that's actively used. This will ensure you’re not introducing breaking changes for your team.
For more information, see "[Introduction to dev containers](/codespaces/setting-up-your-project-for-codespaces/introduction-to-dev-containers)."
詳しい情報については「[開発コンテナの紹介](/codespaces/setting-up-your-project-for-codespaces/introduction-to-dev-containers)」を参照してください。
## Testing changes to the dev container configuration
1. Create a codespace from the prebuild-enabled branch whose dev container you want to change. For more information, see "[Creating a codespace ](/codespaces/developing-in-codespaces/creating-a-codespace#creating-a-codespace)."
1. In the codespace, check out a test branch. For more information, see "[Using source control in your codespace](/codespaces/developing-in-codespaces/using-source-control-in-your-codespace#creating-or-switching-branches)."
1. Make the required changes to the dev container configuration.
1. Apply the changes by rebuilding the container. For more information, see "[Introduction to dev containers](/codespaces/setting-up-your-project-for-codespaces/introduction-to-dev-containers#applying-configuration-changes-to-a-codespace)."
1. After everything looks good, we also recommend creating a new codespace from your test branch to ensure everything is working. You can then commit your changes to your repository's default branch, or an active feature branch, triggering an update of the prebuild template for that branch.
1. Apply the changes by rebuilding the container. 詳しい情報については「[開発コンテナの紹介](/codespaces/setting-up-your-project-for-codespaces/introduction-to-dev-containers#applying-configuration-changes-to-a-codespace)」を参照してください。
1. After everything looks good, we also recommend creating a new codespace from your test branch to ensure everything is working. You can then commit your changes to your repository's default branch, or an active feature branch, triggering an update of the prebuild for that branch.
{% note %}

2
translations/ja-JP/content/codespaces/troubleshooting/troubleshooting-prebuilds.md
View File

@@ -44,7 +44,7 @@ cat /workspaces/.codespaces/shared/environment-variables.json | jq '.ACTION_NAME
You may notice that sometimes, when you create a new codespace from a prebuild-enabled branch, the "{% octicon "zap" aria-label="The zap icon" %} Prebuild Ready" label is not displayed in the dialog box for choosing a machine type. This means that prebuilds are not currently available.
By default, each time you push to a prebuild-enabled branch, the prebuild template is updated. If the push involves a change to the dev container configuration then, while the update is in progress, the "{% octicon "zap" aria-label="The zap icon" %} Prebuild Ready" label is removed from the list of machine types. During this time you can still create codespaces without a prebuild template. If required, you can reduce the occasions on which prebuilds are unavailable for a repository by setting the prebuild template to be updated only when you make a change to your dev container configuration files, or only on a custom schedule. 詳しい情報については「[事前ビルドの設定](/codespaces/prebuilding-your-codespaces/configuring-prebuilds#configuring-a-prebuild)」を参照してください。
By default, each time you push to a prebuild-enabled branch, the prebuild is updated. If the push involves a change to the dev container configuration then, while the update is in progress, the "{% octicon "zap" aria-label="The zap icon" %} Prebuild Ready" label is removed from the list of machine types. During this time you can still create codespaces without a prebuild. If required, you can reduce the occasions on which prebuilds are unavailable for a repository by setting the prebuild to be updated only when you make a change to your dev container configuration files, or only on a custom schedule. 詳しい情報については「[事前ビルドの設定](/codespaces/prebuilding-your-codespaces/configuring-prebuilds#configuring-a-prebuild)」を参照してください。
If your branch is not specifically enabled for prebuilds it may still benefit from prebuilds if it was branched from a prebuild-enabled branch. However, if the dev container configuration is changed on your branch, so that it's not the same as the configuration on the base branch, prebuilds will no longer be available on your branch.

2
translations/ja-JP/content/communities/documenting-your-project-with-wikis/about-wikis.md
View File

@@ -19,6 +19,8 @@ Every repository on {% ifversion ghae %}{% data variables.product.product_name %
ウィキでは、{% data variables.product.product_name %} のあらゆる他の場所と同じようにコンテンツを書くことができます。 詳細は「[{% data variables.product.prodname_dotcom %} で書き、フォーマットしてみる](/articles/getting-started-with-writing-and-formatting-on-github)」を参照してください。 私たちは、さまざまなフォーマットを HTML に変更するのに[私たちのオープンソースマークアップライブラリ](https://github.com/github/markup)を使っているので、Markdown あるいはその他任意のサポートされているフォーマットで書くことができます。
{% data reusables.getting-started.math-and-diagrams %}
{% ifversion fpt or ghes or ghec %}パブリックリポジトリに Wiki を作成すると、{% ifversion ghes %}{% data variables.product.product_location %}{% else %}パブリック{% endif %}にアクセスできるすべてのユーザがその Wiki を利用できます。 {% endif %}If you create a wiki in a private{% ifversion ghec or ghes %} or internal{% endif %} repository, only {% ifversion fpt or ghes or ghec %}people{% elsif ghae %}enterprise members{% endif %} with access to the repository can access the wiki. 詳細は「[リポジトリの可視性を設定する](/articles/setting-repository-visibility)」を参照してください。
ウィキは、{% data variables.product.product_name %} 上で直接編集することも、ウィキのファイルをローカルで編集することもできます。 デフォルトでは、リポジトリへの書き込みアクセス権を持つユーザのみが Wiki に変更を加えることができますが、{% data variables.product.product_location %} のすべてのユーザが{% ifversion ghae %}内部{% else %}パブリック{% endif %}リポジトリの Wiki に貢献できるようにすることも可能ですす。 For more information, see "[Changing access permissions for wikis](/communities/documenting-your-project-with-wikis/changing-access-permissions-for-wikis)."

5
translations/ja-JP/content/communities/documenting-your-project-with-wikis/editing-wiki-content.md
View File

@@ -45,6 +45,11 @@ topics:
[[https://github.com/USERNAME/REPOSITORY/blob/main/img/octocat.png|alt=octocat]]
{% ifversion fpt or ghec or ghes > 3.6 or ghae-issue-7647 %}
## Adding mathematical expressions and diagrams{% endif %}
{% data reusables.getting-started.math-and-diagrams %}
## サポートされる MediaWiki 形式
ウィキがどのマークアップ言語で書かれたかにかかわらず、特定の MediaWiki 構文を常に使用できます。

46
translations/ja-JP/content/developers/webhooks-and-events/webhooks/webhook-events-and-payloads.md
View File

@@ -1172,29 +1172,29 @@ Activity related to items in a {% data variables.projects.project_v2 %}. {% data
### webhook ペイロードオブジェクト
| キー | 種類 | 説明 |
| -------------------------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| `ref` | `string` | プッシュされた完全な[`git ref`](/rest/reference/git#refs)。 例: `refs/heads/main`または`refs/tags/v3.14.1`。 |
| `before` | `string` | プッシュ前の`ref` 上の最新のコミットのSHA。 |
| `after` | `string` | プッシュ後の`ref`上の最新のコミットのSHA。 |
| `created` | `boolean` | プッシュが`ref`を作成したかどうか。 |
| `deleted` | `boolean` | プッシュが`ref`を削除したかどうか。 |
| `forced` | `boolean` | プッシュが `ref`のフォースプッシュであったかどうか。 |
| `head_commit` | `オブジェクト` | `after`がコミットオブジェクトであるか、コミットオブジェクトを指している場合、そのコミットの拡張表現。 `after`がアノテーションされたタグオブジェクトを指すプッシュの場合、そのアノテーションされたタグが指すコミットの拡張表現。 |
| `compare` | `string` | `before`コミットから`after`コミットまで、この`ref`更新にある変更を示すURL。 デフォルトブランチに直接基づいて新規作成された`ref`の場合、デフォルトブランチのheadと`after`コミットとの比較。 それ以外の場合は、`after`コミットまでのすべてのコミットを示す。 |
| `commits` | `array` | プッシュされたコミットを示すコミットオブジェクトの配列。 (プッシュされたコミットは、`before`コミットと`after`コミットの間で`compare`されたものに含まれる全てのコミット。) |
| `commits[][id]` | `string` | コミットのSHA。 |
| `commits[][timestamp]` | `string` | コミットの ISO 8601 タイムスタンプ。 |
| `commits[][message]` | `string` | コミットメッセージ。 |
| `commits[][author]` | `オブジェクト` | コミットのGit作者。 |
| `commits[][author][name]` | `string` | Git作者の名前。 |
| `commits[][author][email]` | `string` | Git作者のメールアドレス。 |
| `commits[][url]` | `url` | コミットAPIのリソースを指すURL。 |
| `commits[][distinct]` | `boolean` | このコミットが以前にプッシュされたいずれとも異なっているか。 |
| `commits[][added]` | `array` | コミットに追加されたファイルの配列。 |
| `commits[][modified]` | `array` | コミットによって変更されたファイルの配列。 |
| `commits[][removed]` | `array` | コミットから削除されたファイルの配列。 |
| `pusher` | `オブジェクト` | コミットをプッシュしたユーザ。 |
| キー | 種類 | 説明 |
| -------------------------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `ref` | `string` | プッシュされた完全な[`git ref`](/rest/reference/git#refs)。 例: `refs/heads/main`または`refs/tags/v3.14.1`。 |
| `before` | `string` | プッシュ前の`ref` 上の最新のコミットのSHA。 |
| `after` | `string` | プッシュ後の`ref`上の最新のコミットのSHA。 |
| `created` | `boolean` | プッシュが`ref`を作成したかどうか。 |
| `deleted` | `boolean` | プッシュが`ref`を削除したかどうか。 |
| `forced` | `boolean` | プッシュが `ref`のフォースプッシュであったかどうか。 |
| `head_commit` | `オブジェクト` | `after`がコミットオブジェクトであるか、コミットオブジェクトを指している場合、そのコミットの拡張表現。 `after`がアノテーションされたタグオブジェクトを指すプッシュの場合、そのアノテーションされたタグが指すコミットの拡張表現。 |
| `compare` | `string` | `before`コミットから`after`コミットまで、この`ref`更新にある変更を示すURL。 デフォルトブランチに直接基づいて新規作成された`ref`の場合、デフォルトブランチのheadと`after`コミットとの比較。 それ以外の場合は、`after`コミットまでのすべてのコミットを示す。 |
| `commits` | `array` | プッシュされたコミットを示すコミットオブジェクトの配列。 (プッシュされたコミットは、`before`コミットと`after`コミットの間で`compare`されたものに含まれる全てのコミット。) |
| `commits[][id]` | `string` | コミットのSHA。 |
| `commits[][timestamp]` | `string` | コミットの ISO 8601 タイムスタンプ。 |
| `commits[][message]` | `string` | コミットメッセージ。 |
| `commits[][author]` | `オブジェクト` | コミットのGit作者。 |
| `commits[][author][name]` | `string` | Git作者の名前。 |
| `commits[][author][email]` | `string` | Git作者のメールアドレス。 |
| `commits[][url]` | `url` | コミットAPIのリソースを指すURL。 |
| `commits[][distinct]` | `boolean` | このコミットが以前にプッシュされたいずれとも異なっているか。 |
| `commits[][added]` | `array` | コミットに追加されたファイルの配列。 For extremely large commits where {% data variables.product.product_name %} is unable to calculate this list in a timely manner, this may be empty even if files were added. |
| `commits[][modified]` | `array` | コミットによって変更されたファイルの配列。 For extremely large commits where {% data variables.product.product_name %} is unable to calculate this list in a timely manner, this may be empty even if files were modified. |
| `commits[][removed]` | `array` | コミットから削除されたファイルの配列。 For extremely large commits where {% data variables.product.product_name %} is unable to calculate this list in a timely manner, this may be empty even if files were removed. |
| `pusher` | `オブジェクト` | コミットをプッシュしたユーザ。 |
{% data reusables.webhooks.repo_desc %}
{% data reusables.webhooks.org_desc %}
{% data reusables.webhooks.app_desc %}

2
translations/ja-JP/content/get-started/writing-on-github/working-with-advanced-formatting/creating-diagrams.md
View File

@@ -8,7 +8,7 @@ shortTitle: Create diagrams
## About creating diagrams
You can create diagrams in Markdown using three different syntaxes: mermaid, geoJSON and topoJSON, and ASCII STL.
You can create diagrams in Markdown using three different syntaxes: mermaid, geoJSON and topoJSON, and ASCII STL. Diagram rendering is available in {% data variables.product.prodname_github_issues %}, {% data variables.product.prodname_discussions %}, pull requests, wikis, and Markdown files.
## Creating Mermaid diagrams

4
translations/ja-JP/content/get-started/writing-on-github/working-with-advanced-formatting/writing-mathematical-expressions.md
View File

@@ -6,10 +6,14 @@ versions:
shortTitle: Mathematical expressions
---
## About writing mathematical expressions
To enable clear communication of mathematical expressions, {% data variables.product.product_name %} supports LaTeX formatted math within Markdown. For more information, see [LaTeX/Mathematics](http://en.wikibooks.org/wiki/LaTeX/Mathematics) in Wikibooks.
{% data variables.product.company_short %}'s math rendering capability uses MathJax; an open source, JavaScript-based display engine. MathJax supports a wide range of LaTeX macros, and several useful accessibility extensions. For more information, see [the MathJax documentation](http://docs.mathjax.org/en/latest/input/tex/index.html#tex-and-latex-support) and [the MathJax Accessibility Extensions Documentation](https://mathjax.github.io/MathJax-a11y/docs/#reader-guide).
Mathematical expressions rendering is available in {% data variables.product.prodname_github_issues %}, {% data variables.product.prodname_discussions %}, pull requests, {% ifversion fpt or ghec or ghes > 3.6 or ghae-issue-7647 %}wikis, {% endif %}and Markdown files.
## Writing inline expressions
To include a math expression inline with your text, delimit the expression with a dollar symbol `$`.

1
translations/ja-JP/content/index.md
View File

@@ -63,6 +63,7 @@ childGroups:
- repositories
- pull-requests
- discussions
- copilot
- name: CI/CD and DevOps
octicon: GearIcon
children:

30
translations/ja-JP/content/organizations/managing-access-to-your-organizations-project-boards/project-board-permissions-for-an-organization.md
View File

@@ -1,6 +1,6 @@
---
title: '{% data variables.product.prodname_project_v1_caps %} permissions for an organization'
intro: 'Organization owners and people with {% data variables.projects.projects_v1_board %} admin permissions can customize who has read, write, and admin permissions to your organization’s {% data variables.projects.projects_v1_boards %}.'
title: 'Organizationの{% data variables.product.prodname_project_v1_caps %}の権限'
intro: 'Organizationのオーナーと{% data variables.projects.projects_v1_board %}の管理権限を持つユーザは、Organizationの{% data variables.projects.projects_v1_boards %}への読み取り、書き込み、管理権限を持つ人ををカスタマイズできます。'
redirect_from:
- /articles/project-board-permissions-for-an-organization
- /github/setting-up-and-managing-organizations-and-teams/project-board-permissions-for-an-organization
@@ -20,30 +20,30 @@ allowTitleToDifferFromFilename: true
## 権限の概要
There are three levels of permissions to a {% data variables.projects.projects_v1_board %} for people and teams:
人とTeamに対しては、{% data variables.projects.projects_v1_board %}に3つのレベルの権限があります。
{% data reusables.project-management.project-board-permissions %}
Organization owners and people with admin permissions can give a person access to an organization {% data variables.projects.projects_v1_board %} individually, as an outside collaborator or organization member, or through their membership in a team or organization. 外部コラボレーターとは、Organization のメンバーではないが、Organization でコラボレーションの権限を付与されたユーザーのことです。
Organization のオーナーと、管理者権限を持つユーザーは、外部コラボレーターまたは Organization メンバーとして、またはTeamやOrganizationのメンバーシップを通じて、Organizationの{% data variables.projects.projects_v1_board %}に対するユーザーのアクセス権を個々に付与することができます。 外部コラボレーターとは、Organization のメンバーではないが、Organization でコラボレーションの権限を付与されたユーザーのことです。
Organization owners and people with admin permissions to a {% data variables.projects.projects_v1_board %} can also:
Organizationのオーナーと{% data variables.projects.projects_v1_board %}の管理権限を持つユーザは、以下のこともできます。
- すべての Organization メンバーに対して、デフォルトのプロジェクトボード権限を設定する。
- Organization メンバー、Team、外部コラボレーターについてプロジェクトボードへのアクセスを管理する。 For more information, see "[Managing team access to an organization {% data variables.product.prodname_project_v1 %}](/articles/managing-team-access-to-an-organization-project-board)", "[Managing an individual’s access to an organization {% data variables.product.prodname_project_v1 %}](/articles/managing-an-individual-s-access-to-an-organization-project-board)", or "[Managing access to a {% data variables.product.prodname_project_v1 %} for organization members](/articles/managing-access-to-a-project-board-for-organization-members)."
- プロジェクトボードの可視性を管理する。 For more information, see "[Managing access to a {% data variables.product.prodname_project_v1 %} for organization members](/articles/managing-access-to-a-project-board-for-organization-members)."
- Organization メンバー、Team、外部コラボレーターについてプロジェクトボードへのアクセスを管理する。 詳しい情報については「[Organizationの{% data variables.product.prodname_project_v1 %}へのTeamアクセスの管理](/articles/managing-team-access-to-an-organization-project-board)」、「[Organizationの{% data variables.product.prodname_project_v1 %}への個人のアクセス管理](/articles/managing-an-individual-s-access-to-an-organization-project-board)」、「[Organizationのメンバーの{% data variables.product.prodname_project_v1 %}へのアクセス管理](/articles/managing-access-to-a-project-board-for-organization-members)」を参照してください。
- プロジェクトボードの可視性を管理する。 詳しい情報については「[Organizationのメンバーの{% data variables.product.prodname_project_v1 %}へのアクセス管理](/articles/managing-access-to-a-project-board-for-organization-members)」を参照してください。
## Cascading permissions for {% data variables.projects.projects_v1_boards %}
## {% data variables.projects.projects_v1_boards %}のカスケード権限
{% data reusables.project-management.cascading-permissions %}
For example, if an organization owner has given all organization members read permissions to a {% data variables.projects.projects_v1_board %}, and a {% data variables.projects.projects_v1_board %} admin gives an organization member write permissions to that board as an individual collaborator, that person would have write permissions to the {% data variables.projects.projects_v1_board %}.
たとえば、Organization のオーナーが、ある{% data variables.projects.projects_v1_board %}に対する読み取り権限をOrganizationのすべてのメンバーに付与しており、{% data variables.projects.projects_v1_board %}の管理者が同じボードに対する書き込み権限をOrganization のメンバーに個別のコラボレーターとして付与している場合、そのユーザーはその{% data variables.projects.projects_v1_board %}に対する書き込み権限を持つことになります。
## {% data variables.projects.projects_v1_board_caps %} visibility
## {% data variables.projects.projects_v1_board_caps %}の可視性
{% data reusables.project-management.project-board-visibility %} You can change the {% data variables.projects.projects_v1_board %}'s visibility from private to {% ifversion ghae %}internal{% else %}public{% endif %} and back again. For more information, see "[Changing {% data variables.product.prodname_project_v1 %} visibility](/articles/changing-project-board-visibility)."
{% data reusables.project-management.project-board-visibility %}{% data variables.projects.projects_v1_board %}の可視性をプライベートから{% ifversion ghae %}インターナル{% else %}パブリック{% endif %}に変更したり、元に戻したりすることができます。 詳しい情報については「[{% data variables.product.prodname_project_v1 %}の可視性の変更](/articles/changing-project-board-visibility)」を参照してください。
## 参考リンク
- "[Changing {% data variables.product.prodname_project_v1 %} visibility](/articles/changing-project-board-visibility)"
- "[Managing an individual’s access to an organization {% data variables.product.prodname_project_v1 %}](/articles/managing-an-individual-s-access-to-an-organization-project-board)"
- "[Managing team access to an organization {% data variables.product.prodname_project_v1 %}](/articles/managing-team-access-to-an-organization-project-board)"
- "[Managing access to a {% data variables.product.prodname_project_v1 %} for organization members](/articles/managing-access-to-a-project-board-for-organization-members)"
- 「[{% data variables.product.prodname_project_v1 %}の可視性の変更](/articles/changing-project-board-visibility)」
- 「[Organizationの{% data variables.product.prodname_project_v1 %}への個人のアクセスの管理](/articles/managing-an-individual-s-access-to-an-organization-project-board)」
- 「[Organizationの{% data variables.product.prodname_project_v1 %}へのTeamのアクセスの管理](/articles/managing-team-access-to-an-organization-project-board)」
- 「[Organizationのメンバーに対する{% data variables.product.prodname_project_v1 %}へのアクセス管理](/articles/managing-access-to-a-project-board-for-organization-members)」

4
translations/ja-JP/content/organizations/managing-access-to-your-organizations-project-boards/removing-an-outside-collaborator-from-an-organization-project-board.md
View File

@@ -1,6 +1,6 @@
---
title: 'Removing an outside collaborator from an organization {% data variables.product.prodname_project_v1 %}'
intro: 'As an organization owner or {% data variables.projects.projects_v1_board %} admin, you can remove an outside collaborator''s access to a {% data variables.projects.projects_v1_board %}.'
title: 'Organizationの{% data variables.product.prodname_project_v1 %}からの外部のコラボレータの削除'
intro: 'Organizationのオーナーもしくは{% data variables.projects.projects_v1_board %}の管理者は、{% data variables.projects.projects_v1_board %}への外部のコラボレータのアクセスを削除できます。'
redirect_from:
- /articles/removing-an-outside-collaborator-from-an-organization-project-board
- /github/setting-up-and-managing-organizations-and-teams/removing-an-outside-collaborator-from-an-organization-project-board

14
translations/ja-JP/content/organizations/managing-organization-settings/allowing-project-visibility-changes-in-your-organization.md
View File

@@ -1,26 +1,26 @@
---
title: Organizationでのプロジェクトの可視性の変更の許可
intro: Organization owners can allow members with admin permissions to adjust the visibility of projects in their organization.
intro: Organizationのオーナーは、管理権限を持つメンバーに、Organization内のプロジェクトの可視性の調整を許可できます。
versions:
feature: projects-v2
topics:
- Organizations
- Projects
shortTitle: Project visibility permissions
shortTitle: プロジェクトの可視性の権限
allowTitleToDifferFromFilename: true
permissions: Organization owners can allow project visibility changes for an organization.
---
You can restrict who has the ability to change the visibility of projects in your organization, such as restricting members from changing a project from private to public.
メンバーがプロジェクトをプライベートからパブリックに変更するのを制限するように、Organizationでのプロジェクトの可視性を変更できる人を制限できます。
You can limit the ability to change project visibility to just organization owners, or you can allow anyone with admin permissions on a project to change the visibility.
プロジェクトの可視性を変更できるのをOrganizationのオーナーだけに制限したり、プロジェクトの管理権限を持つ人なら誰でも可視性を変更できるようにしたりできます。
{% data reusables.profile.access_org %}
{% data reusables.profile.org_settings %}
1. In the "Code, planning, and automation" section of the sidebar, click **{% octicon "table" aria-label="The table icon" %} Projects**.
1. To allow members to adjust project visibility, select **Allow members to change project visibilities for this organization**. ![Screenshot showing checkbox to set visibility changes](/assets/images/help/projects-v2/visibility-change-checkbox.png)
1. サイドバーの「Code planning, and automation（コードの計画と自動化）」セクションで、**{% octicon "table" aria-label="The table icon" %} Projects（プロジェクト）**をクリックしてください。
1. プロジェクトの可視性の調整をメンバーに許可するには、**Allow members to change project visibilities for this organization（このOrganizationのプロジェクトの可視性の変更をメンバーに許可）**を選択してください。 ![可視性の変更を設定するチェックボックスを表示しているスクリーンショット](/assets/images/help/projects-v2/visibility-change-checkbox.png)
1. [**Save**] をクリックします。
## 参考リンク
- "[Managing visibility of your projects](/issues/planning-and-tracking-with-projects/managing-your-project/managing-visibility-of-your-projects)"
- 「[プロジェクトの可視性の管理](/issues/planning-and-tracking-with-projects/managing-your-project/managing-visibility-of-your-projects)」

14
translations/ja-JP/content/organizations/managing-organization-settings/disabling-insights-for-projects-in-your-organization.md
View File

@@ -1,25 +1,25 @@
---
title: 'Disabling insights for {% data variables.projects.projects_v2 %} in your organization'
intro: 'Organization owners can turn off insights for {% data variables.product.prodname_projects_v2 %} in their organization.'
title: 'Organizationでの{% data variables.projects.projects_v2 %}のインサイトの無効化'
intro: 'Organizationのオーナーは、自分のOrganizationで{% data variables.product.prodname_projects_v2 %}をオフにできます。'
versions:
feature: projects-v2
product: '{% data reusables.gated-features.historical-insights-for-projects %}'
topics:
- Projects
shortTitle: 'Disable {% data variables.product.prodname_projects_v2 %} insights'
shortTitle: '{% data variables.product.prodname_projects_v2 %}インサイトの無効化'
allowTitleToDifferFromFilename: true
---
After you disable insights for projects in your organization, it won't be possible to access insights for any projects owned by the organization.
Organizationのプロジェクトのインサイトを無効化したあとは、Organizationが所有するいずれのプロジェクトでもインサイトにアクセスすることはできなくなります。
{% data reusables.profile.access_org %}
{% data reusables.profile.org_settings %}
1. In the sidebar, click **{% octicon "sliders" aria-label="The sliders icon" %} Features**. ![Screenshot showing features menu item](/assets/images/help/projects-v2/features-org-menu.png)
1. Under "Insights", deselect **Enable Insights for the organization**. ![Screenshot showing Enable Insights for the organization checkbox](/assets/images/help/projects-v2/disable-insights-checkbox.png)
1. サイドバーで**{% octicon "sliders" aria-label="The sliders icon" %} Features（機能）**をクリックしてください。 ![機能メニューアイコンを表示しているスクリーンショット](/assets/images/help/projects-v2/features-org-menu.png)
1. "Insights（インサイト）"の下で、**Enable Insights for the organization（Organizationでインサイトを有効化）**の選択を解除してください。 ![Organizationのインサイトの有効化チェックボックスを表示しているスクリーンショット](/assets/images/help/projects-v2/disable-insights-checkbox.png)
1. [**Save**] をクリックします。 ![保存ボタンを表示しているスクリーンショット](/assets/images/help/projects-v2/disable-insights-save.png)
## 参考リンク
- [{% data variables.product.prodname_projects_v2 %}について](/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects)
- "[About insights for {% data variables.projects.projects_v2 %}](/issues/planning-and-tracking-with-projects/viewing-insights-from-your-project/about-insights-for-projects)"
- 「[{% data variables.projects.projects_v2 %}のインサイトについて](/issues/planning-and-tracking-with-projects/viewing-insights-from-your-project/about-insights-for-projects)」

16
translations/ja-JP/content/organizations/managing-organization-settings/disabling-project-boards-in-your-organization.md
View File

@@ -1,6 +1,6 @@
---
title: 'Disabling {% ifversion projects-v2 %}projects{% else %}project boards{% endif %} in your organization'
intro: 'Organization owners can turn off {% ifversion projects-v2 %}organization-wide {% data variables.projects.projects_v2 %}, organization-wide {% data variables.projects.projects_v1_boards %}, and repository-level {% data variables.projects.projects_v1_boards %}{% else %}organization-wide project boards and repository project boards{% endif %} in an organization.'
title: 'Organizationの{% ifversion projects-v2 %}プロジェクト{% else %}プロジェクトボード{% endif %}の無効化'
intro: 'Organizationのオーナーは、Organizationにおいて{% ifversion projects-v2 %}Organization全体の{% data variables.projects.projects_v2 %}、Organization全体の{% data variables.projects.projects_v1_boards %}、リポジトリレベルの{% data variables.projects.projects_v1_boards %}{% else %}Organization全体のプロジェクトボードとリポジトリのプロジェクトボード{% endif %}をオフにできます。'
redirect_from:
- /github/managing-your-work-on-github/managing-project-boards/disabling-project-boards-in-your-organization
- /articles/disabling-project-boards-in-your-organization
@@ -12,11 +12,11 @@ versions:
ghec: '*'
topics:
- Pull requests
shortTitle: Disable projects
shortTitle: プロジェクトの無効化
allowTitleToDifferFromFilename: true
---
Organization 全体でプロジェクトボードを無効化すると、Organization レベルでプロジェクトボードを新たに作成することができなくなり、既存の Organization レベルのプロジェクトボードはそれまでの URL ではアクセスできなくなります。 Organization 内にあるリポジトリのプロジェクトボードは影響を受けません。 {% ifversion projects-v2 %}These settings apply to {% data variables.projects.projects_v2 %} and {% data variables.projects.projects_v1_boards %}.{% endif %}
Organization 全体でプロジェクトボードを無効化すると、Organization レベルでプロジェクトボードを新たに作成することができなくなり、既存の Organization レベルのプロジェクトボードはそれまでの URL ではアクセスできなくなります。 Organization 内にあるリポジトリのプロジェクトボードは影響を受けません。 {% ifversion projects-v2 %}これらの設定は、{% data variables.projects.projects_v2 %}及び{% data variables.projects.projects_v1_boards %}に適用されます。{% endif %}
Organization 内にあるリポジトリのプロジェクトボードを無効化すると、Organization 内のどのリポジトリでもプロジェクトボードを新たに作成できなくなり、既存の Organization 内にあるリポジトリのプロジェクトボードはそれまでの URL でアクセスできなくなります。 Organization レベルのプロジェクトボードは影響を受けません。
@@ -38,8 +38,8 @@ Organization 内にあるリポジトリのプロジェクトボードを無効
## 参考リンク
{% ifversion projects-v2 %}- "[About {% data variables.product.prodname_projects_v2 %}](/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects)"{% endif %}
{% ifversion projects-v2 %}- 「[{% data variables.product.prodname_projects_v2 %}について](/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects)」{% endif %}
- [{% data variables.product.prodname_projects_v1 %}について](/articles/about-project-boards)
- "[Closing a {% data variables.projects.projects_v1_board %}](/articles/closing-a-project-board)"
- "[Deleting a {% data variables.projects.projects_v1_board %}](/articles/deleting-a-project-board)"
- "[Disabling {% data variables.projects.projects_v1_boards %} in a repository](/articles/disabling-project-boards-in-a-repository)"
- 「[{% data variables.projects.projects_v1_board %}のクローズ](/articles/closing-a-project-board)」
- 「[{% data variables.projects.projects_v1_board %}の削除](/articles/deleting-a-project-board)」
- 「[リポジトリでの{% data variables.projects.projects_v1_boards %}の無効化](/articles/disabling-project-boards-in-a-repository)」

8
translations/ja-JP/content/pages/configuring-a-custom-domain-for-your-github-pages-site/managing-a-custom-domain-for-your-github-pages-site.md
View File

@@ -40,12 +40,12 @@ DNS レコードの設定が正しいかどうかを検証するために利用
## サブドメインを設定する
To set up a `www` or custom subdomain, such as `www.example.com` or `blog.example.com`, you must add your domain in the repository settings. その後、DNS プロバイダで CNAME レコードを設定します。
`www` または `www.example.com` や `blog.example.com` などのカスタムサブドメインを設定するには、リポジトリ設定にドメインを追加する必要があります。 その後、DNS プロバイダで CNAME レコードを設定します。
{% data reusables.pages.navigate-site-repo %}
{% 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)
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 %}
{% indented_data_reference reusables.pages.wildcard-dns-warning spaces=3 %}
@@ -63,14 +63,14 @@ To set up a `www` or custom subdomain, such as `www.example.com` or `blog.exampl
## Apexドメインを設定する
To set up an apex domain, such as `example.com`, you must configure a custom domain in your repository settings and at least one `ALIAS`, `ANAME`, or `A` record with your DNS provider.
`example.com` などの Apex ドメインを設定するには、カスタムドメインをリポジトリ設定で構成し、DNS プロバイダで少なくとも 1 つの `ALIAS`、`ANAME`、または `A` レコードを設定する必要があります。
{% data reusables.pages.www-and-apex-domain-recommendation %} 詳しい情報については、「[サブドメインを設定する](#configuring-a-subdomain)」を参照してください。
{% data reusables.pages.navigate-site-repo %}
{% 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-apex-domain.png)
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-apex-domain.png)
5. DNS プロバイダに移動し、`ALIAS`、`ANAME`、または `A` レコードを作成します。 IPv6サポートのために`AAAA`レコードを作成することもできます。 {% data reusables.pages.contact-dns-provider %}
- `ALIAS`または`ANAME`レコードを作成するには、Apexドメインをサイトのデフォルトドメインにポイントします。 {% data reusables.pages.default-domain-information %}
- `A` レコードを作成するには、Apex ドメインが {% data variables.product.prodname_pages %} の IP アドレスを指すようにします。

4
translations/ja-JP/content/pages/configuring-a-custom-domain-for-your-github-pages-site/troubleshooting-custom-domains-and-github-pages.md
View File

@@ -18,9 +18,9 @@ shortTitle: カスタムドメインのトラブルシューティング
## _CNAME_ エラー
{% ifversion pages-custom-workflow %}If you are publishing from a custom {% data variables.product.prodname_actions %} workflow, any _CNAME_ file is ignored and is not required.{% endif %}
{% ifversion pages-custom-workflow %}カスタムの{% data variables.product.prodname_actions %}ワークフローから公開しているなら、いかなる_CNAME_ファイルも無視され、必要ではありません。{% endif %}
If you are publishing from a branch, custom domains are stored in a _CNAME_ file in the root of your publishing source. このファイルは、リポジトリ設定を通じて、あるいは手動で追加または更新することができます。 詳しい情報については、「[{% data variables.product.prodname_pages %} サイト用のカスタムドメインを管理する](/articles/managing-a-custom-domain-for-your-github-pages-site)」を参照してください。
ブランチから公開しているなら、カスタムドメインは公開ソースのルートにある_CNAME_ファイルに保存されます。 このファイルは、リポジトリ設定を通じて、あるいは手動で追加または更新することができます。 詳しい情報については、「[{% data variables.product.prodname_pages %} サイト用のカスタムドメインを管理する](/articles/managing-a-custom-domain-for-your-github-pages-site)」を参照してください。
サイトが正しいドメインをレンダリングするには、_CNAME_ ファイルがまだリポジトリに存在していることを確認します。 たとえば、静的サイトジェネレータの多くはリポジトリへのプッシュを強制するので、カスタムドメインの設定時にリポジトリに追加された _CNAME_ ファイルを上書きすることができます。 ローカルでサイトをビルドし、生成されたファイルを {% data variables.product.product_name %} にプッシュする場合は、_CNAME_ ファイルをローカルリポジトリに追加したコミットを先にプルして、そのファイルがビルドに含まれるようにする必要があります。

2
translations/ja-JP/content/pages/configuring-a-custom-domain-for-your-github-pages-site/verifying-your-custom-domain-for-github-pages.md
View File

@@ -18,6 +18,8 @@ shortTitle: カスタムドメインの検証
ドメインを検証すると、直接のサブドメインもその検証に含まれます。 たとえば、`github.com`というカスタムドメインが検証されると、`docs.github.com`、`support.github.com`あるいはその他の直接のサブドメインも、乗っ取りから保護されることになります。
{% data reusables.pages.wildcard-dns-warning %}
Organization{% ifversion ghec %}あるいはEnterprise{% endif %}のドメインを検証することもできます。そうすると、「検証済み」バッジがOrganization{% ifversion ghec %}もしくはEnterprise{% endif %}のプロフィールに表示され{% ifversion ghec %}、{% data variables.product.prodname_ghe_cloud %}では検証済みドメインを使ってメールアドレスへの通知を制限できるようになり{% endif %}ます。 詳しい情報については「[Organizationのドメインの検証あるいは承認](/organizations/managing-organization-settings/verifying-or-approving-a-domain-for-your-organization)」{% ifversion ghec %}及び「[Enterpriseのドメインの検証あるいは承認](/enterprise-cloud@latest/admin/configuration/configuring-your-enterprise/verifying-or-approving-a-domain-for-your-enterprise)」{% endif %}を参照してください。
## ユーザサイトのドメインの検証

45
translations/ja-JP/content/pages/getting-started-with-github-pages/adding-a-theme-to-your-github-pages-site-with-the-theme-chooser.md
View File

@@ -1,6 +1,6 @@
---
title: テーマ選択画面で GitHub Pages サイトにテーマを追加する
intro: 'サイトの見た目をカスタマイズするため、{% data variables.product.prodname_pages %} サイトにテーマを追加できます。'
title: Adding a theme to your GitHub Pages site with the theme chooser
intro: 'You can add a theme to your {% data variables.product.prodname_pages %} site to customize your site’s look and feel.'
redirect_from:
- /articles/creating-a-github-pages-site-with-the-jekyll-theme-chooser
- /articles/adding-a-jekyll-theme-to-your-github-pages-site-with-the-jekyll-theme-chooser
@@ -12,11 +12,11 @@ versions:
ghec: '*'
topics:
- Pages
shortTitle: Pagesサイトへのテーマの追加
permissions: 'People with admin permissions for a repository can use the theme chooser to add a theme to a {% data variables.product.prodname_pages %} site.'
shortTitle: Add theme to a Pages site
permissions: People with admin permissions for a repository can use the theme chooser to add a theme to a {% data variables.product.prodname_pages %} site.
---
## テーマ選択画面について
## About the theme chooser
{% ifversion pages-custom-workflow %}
@@ -28,30 +28,33 @@ permissions: 'People with admin permissions for a repository can use the theme c
{% endif %}
テーマ選択画面は、リポジトリに Jekyll テーマを追加するためのものです。 Jekyll に関する詳しい情報については、「[{% data variables.product.prodname_pages %} と Jekyll](/articles/about-github-pages-and-jekyll)」を参照してください。
The theme chooser adds a Jekyll theme to your repository. For more information about Jekyll, see "[About {% data variables.product.prodname_pages %} and Jekyll](/articles/about-github-pages-and-jekyll)."
テーマ選択画面の動作は、リポジトリがパブリックかプライベートかにより異なります。
- {% data variables.product.prodname_pages %} がリポジトリに対して既に有効である場合、テーマ選択画面は、現在の公開元にテーマを追加します。
- リポジトリがパブリックで、{% data variables.product.prodname_pages %} がリポジトリに対して無効である場合、テーマ選択画面を使用することで {% data variables.product.prodname_pages %} が有効となり、デフォルトブランチを公開元として設定します。
- リポジトリがプライベートで、{% data variables.product.prodname_pages %}がリポジトリに対して無効である場合、テーマ選択画面を使用する前に、公開元を設定して {% data variables.product.prodname_pages %} を有効にする必要があります。
How the theme chooser works depends on whether your repository is public or private.
- If {% data variables.product.prodname_pages %} is already enabled for your repository, the theme chooser will add your theme to the current publishing source.
- If your repository is public and {% data variables.product.prodname_pages %} is disabled for your repository, using the theme chooser will enable {% data variables.product.prodname_pages %} and configure the default branch as your publishing source.
- If your repository is private and {% data variables.product.prodname_pages %} is disabled for your repository, you must enable {% data variables.product.prodname_pages %} by configuring a publishing source before you can use the theme chooser.
公開元に関する詳しい情報については、「[{% data variables.product.prodname_pages %} について](/articles/about-github-pages#publishing-sources-for-github-pages-sites)」を参照してください。
For more information about publishing sources, see "[About {% data variables.product.prodname_pages %}](/articles/about-github-pages#publishing-sources-for-github-pages-sites)."
Jekyll テーマをリポジトリに手動で追加したことがある場合には、それらのファイルが、テーマ選択画面を使用した後も適用されることがあります。 競合を避けるため、テーマ選択画面を使用する前に、手動で追加したテーマフォルダおよびファイルをすべて削除してください。 詳しい情報については、「[Jekyll を使用して {% data variables.product.prodname_pages %} サイトにテーマを追加する](/articles/adding-a-theme-to-your-github-pages-site-using-jekyll)」を参照してください。
If you manually added a Jekyll theme to your repository in the past, those files may be applied even after you use the theme chooser. To avoid conflicts, remove all manually added theme folders and files before using the theme chooser. For more information, see "[Adding a theme to your {% data variables.product.prodname_pages %} site using Jekyll](/articles/adding-a-theme-to-your-github-pages-site-using-jekyll)."
## テーマ選択画面でテーマを追加する
## Adding a theme with the theme chooser
{% data reusables.pages.navigate-site-repo %}
{% data reusables.repositories.sidebar-settings %}
{% data reusables.pages.sidebar-pages %}
3. [{% data variables.product.prodname_pages %}] で、[**Choose a theme**] または [**Change theme**] をクリックします。 ![[Choose a theme] ボタン](/assets/images/help/pages/choose-a-theme.png)
4. ページ上部の、選択したいテーマをクリックし、[**Select theme**] をクリックします。 ![テーマのオプションおよび [Select theme] ボタン](/assets/images/help/pages/select-theme.png)
5. サイトの *README.md* ファイルを編集するようプロンプトが表示される場合があります。
- ファイルを後で編集する場合、[**Cancel**] をクリックします。 ![ファイルを編集する際の [Cancel] リンク](/assets/images/help/pages/cancel-edit.png)
- すぐにファイルを編集するには、「[Editing files（ファイルの編集）](/repositories/working-with-files/managing-files/editing-files)」を参照してください。
3. Under "{% data variables.product.prodname_pages %}," click **Choose a theme** or **Change theme**.
![Choose a theme button](/assets/images/help/pages/choose-a-theme.png)
4. On the top of the page, click the theme you want, then click **Select theme**.
![Theme options and Select theme button](/assets/images/help/pages/select-theme.png)
5. You may be prompted to edit your site's *README.md* file.
- To edit the file later, click **Cancel**.
![Cancel link when editing a file](/assets/images/help/pages/cancel-edit.png)
- To edit the file now, see "[Editing files](/repositories/working-with-files/managing-files/editing-files)."
選択したテーマは、リポジトリの Markdown ファイルに自動的に適用されます。 テーマをリポジトリの HTML ファイルに適用するには、各ファイルのレイアウトを指定する YAML front matter を追加する必要があります。 詳しい情報については、Jekyll サイトの「[Front Matter](https://jekyllrb.com/docs/front-matter/)」を参照してください。
Your chosen theme will automatically apply to markdown files in your repository. To apply your theme to HTML files in your repository, you need to add YAML front matter that specifies a layout to each file. For more information, see "[Front Matter](https://jekyllrb.com/docs/front-matter/)" on the Jekyll site.
## 参考リンク
## Further reading
- Jekyll サイトの「[Themes](https://jekyllrb.com/docs/themes/)」
- [Themes](https://jekyllrb.com/docs/themes/) on the Jekyll site

10
translations/ja-JP/content/pages/getting-started-with-github-pages/configuring-a-publishing-source-for-your-github-pages-site.md
View File

@@ -49,17 +49,11 @@ shortTitle: Configure publishing source
If you choose the `docs` folder on any branch as your publishing source, then later remove the `/docs` folder from that branch in your repository, your site won't build and you'll get a page build error message for a missing `/docs` folder. For more information, see "[Troubleshooting Jekyll build errors for {% data variables.product.prodname_pages %} sites](/articles/troubleshooting-jekyll-build-errors-for-github-pages-sites#missing-docs-folder)."
{% ifversion fpt %}
{% ifversion build-pages-with-actions %}
Your {% data variables.product.prodname_pages %} site will always be deployed with a {% data variables.product.prodname_actions %} workflow run, even if you've configured your {% data variables.product.prodname_pages %} site to be built using a different CI tool. Most external CI workflows "deploy" to GitHub Pages by committing the build output to the `gh-pages` branch of the repository, and typically include a `.nojekyll` file. When this happens, the {% data variables.product.prodname_actions %} workflow will detect the state that the branch does not need a build step, and will execute only the steps necessary to deploy the site to {% data variables.product.prodname_pages %} servers.
To find potential errors with either the build or deployment, you can check the workflow run for your {% data variables.product.prodname_pages %} site by reviewing your repository's workflow runs. For more information, see "[Viewing workflow run history](/actions/monitoring-and-troubleshooting-workflows/viewing-workflow-run-history)." For more information about how to re-run the workflow in case of an error, see "[Re-running workflows and jobs](/actions/managing-workflow-runs/re-running-workflows-and-jobs)."
{% note %}
{% data reusables.pages.pages-builds-with-github-actions-public-beta %}
{% endnote %}
To find potential errors with either the build or deployment, you can check the workflow run for your {% data variables.product.prodname_pages %} site by reviewing your repository's workflow runs. For more information, see "[Viewing workflow run history](/actions/monitoring-and-troubleshooting-workflows/viewing-workflow-run-history)." For more information about how to re-run the workflow in case of an error, see "[Re-running workflows and jobs](/actions/managing-workflow-runs/re-running-workflows-and-jobs)."
{% endif %}

6
translations/ja-JP/content/pages/getting-started-with-github-pages/creating-a-github-pages-site.md
View File

@@ -41,11 +41,11 @@ shortTitle: GitHub Pagesのサイトの作成
{% data reusables.pages.navigate-site-repo %}
{% data reusables.pages.decide-publishing-source %}
1. Create the entry file for your site. {% data variables.product.prodname_pages %} will look for an `index.html`, `index.md`, or `README.md` file as the entry file for your site.
1. サイトのエントリファイルを作成してください。 {% data variables.product.prodname_pages %}は、サイトのエントリファイルとして`index.html`、`index.md`、`README.md`のいずれかのファイルを探します。
{% ifversion pages-custom-workflow %}If your publishing source is a branch and folder, the entry file must be at the top level of the source folder on the source branch. For example, if your publishing source is the `/docs` folder on the `main` branch, your entry file must be located in the `/docs` folder on a branch called `main`.
{% ifversion pages-custom-workflow %}公開ソースがブランチとフォルダなら、エントリファイルはソースブランチのソースフォルダのトップレベルになければなりません。 たとえば、公開ソースが`main`ブランチの`/docs`フォルダにあるなら、エントリファイルは`main`というブランチの`/docs`フォルダに置かれていなければなりません。
If your publishing source is a {% data variables.product.prodname_actions %} workflow, the artifact that you deploy must include the entry file at the top level of the artifact. Instead of adding the entry file to your repository, you may choose to have your {% data variables.product.prodname_actions %} workflow generate your entry file when the workflow runs.{% else %} The entry file must be at the top level of your chosen publishing source. For example, if your publishing source is the `/docs` folder on the `main` branch, your entry file must be located in the `/docs` folder on a branch called `main`.{% endif %}
公開ソースが{% data variables.product.prodname_actions %}ワークフローなら、デプロイする成果物のトップレベルにはエントリファイルがなければなりません。 エントリファイルをリポジトリに追加する代わりに、{% data variables.product.prodname_actions %}ワークフローに実行時にエントリファイルを生成させるよう選択することもできます。{% else %}エントリファイルは、選択した公開ソースのトップレベルになければなりません。 たとえば、公開ソースが`main`ブランチの`/docs`フォルダにあるなら、エントリファイルは`main`というブランチの`/docs`フォルダ内に置かれていなければなりません。{% endif %}
{% data reusables.pages.configure-publishing-source %}
{% data reusables.repositories.sidebar-settings %}
{% data reusables.pages.sidebar-pages %}

8
translations/ja-JP/content/pages/getting-started-with-github-pages/unpublishing-a-github-pages-site.md
View File

@@ -22,13 +22,13 @@ shortTitle: Pagesサイトの公開取り下げ
{% ifversion pages-custom-workflow %}
When you unpublish your site, the site will no longer be available. Any existing repository settings or content will not be affected.
サイトを取り下げると、サイトは利用できなくなります。 既存のリポジトリの設定や内容は影響されません。
{% data reusables.repositories.navigate-to-repo %}
1. Under **{% data variables.product.prodname_pages %}**, next to the **Your site is live at** message, click {% octicon "kebab-horizontal" aria-label="the horizontal kebab icon" %}.
1. In the menu that appears, select **Unpublish site**.
1. **{% data variables.product.prodname_pages %}**の下で、**Your site is live at**メッセージの隣の{% octicon "kebab-horizontal" aria-label="the horizontal kebab icon" %}をクリックしてください。
1. 表示されたメニューで**Unpublish site（サイトの取り下げ）**を選択してください。
![Drop down menu to unpublish site](/assets/images/help/pages/unpublish-site.png)
![サイトの取り下げのドロップダウンメニュー](/assets/images/help/pages/unpublish-site.png)
{% else %}

15
translations/ja-JP/content/pages/setting-up-a-github-pages-site-with-jekyll/about-jekyll-build-errors-for-github-pages-sites.md
View File

@@ -30,26 +30,27 @@ shortTitle: Jekyll build errors for Pages
{% endnote %}
{% ifversion build-pages-with-actions %}
If Jekyll does attempt to build your site and encounters an error, you will receive a build error message.
{% else %}
If Jekyll does attempt to build your site and encounters an error, you will receive a build error message. There are two main types of Jekyll build error messages.
- A "Page build warning" message means your build completed successfully, but you may need to make changes to prevent future problems.
- A "Page build failed" message means your build failed to complete. If Jekyll is able to detect a reason for the failure, you'll see a descriptive error message.
{% endif %}
For more information about troubleshooting build errors, see "[Troubleshooting Jekyll build errors for {% data variables.product.prodname_pages %} sites](/articles/troubleshooting-jekyll-build-errors-for-github-pages-sites)."
{% ifversion fpt %}
{% ifversion build-pages-with-actions %}
## Viewing Jekyll build error messages with {% data variables.product.prodname_actions %}
By default, your {% data variables.product.prodname_pages %} site is built and deployed with a {% data variables.product.prodname_actions %} workflow run unless you've configured your {% data variables.product.prodname_pages %} site to use a different CI tool. To find potential build errors, you can check the workflow run for your {% data variables.product.prodname_pages %} site by reviewing your repository's workflow runs. For more information, see "[Viewing workflow run history](/actions/monitoring-and-troubleshooting-workflows/viewing-workflow-run-history)." For more information about how to re-run the workflow in case of an error, see "[Re-running workflows and jobs](/actions/managing-workflow-runs/re-running-workflows-and-jobs)."
{% note %}
{% data reusables.pages.pages-builds-with-github-actions-public-beta %}
{% endnote %}
{% endif %}
{% ifversion build-pages-with-actions %}{% else %}
## Viewing your repository's build failures on {% data variables.product.product_name %}
You can see build failures (but not build warnings) for your site on {% data variables.product.product_name %} in the **Settings** tab of your site's repository.
{% endif %}
## Viewing Jekyll build error messages locally
@@ -63,7 +64,7 @@ We recommend testing your site locally, which allows you to see build error mess
## Viewing Jekyll build errors by email
{% ifversion pages-custom-workflow %}If you are publishing from a branch, when{% else %}When{% endif %} you push changes to your publishing source on {% data variables.product.product_name %}, {% data variables.product.prodname_pages %} will attempt to build your site. If the build fails, you'll receive an email at your primary email address. You'll also receive emails for build warnings. {% data reusables.pages.build-failure-email-server %}
{% ifversion pages-custom-workflow %}If you are publishing from a branch, when{% else %}When{% endif %} you push changes to your publishing source on {% data variables.product.product_name %}, {% data variables.product.prodname_pages %} will attempt to build your site. If the build fails, you'll receive an email at your primary email address. {% data reusables.pages.build-failure-email-server %}
{% ifversion pages-custom-workflow %}If you are publishing with a custom {% data variables.product.prodname_actions %} workflow, in order to receive emails about build errors in your pull request, you must configure your workflow to run on the `pull_request` trigger. When you do this, we recommend that you skip any deploy steps if the workflow was triggered by the `pull_request` event. This will allow you to see any build errors without deploying the changes from your pull request to your site. For more information, see "[Events that trigger workflows](/actions/using-workflows/events-that-trigger-workflows#pull_request)" and "[Expressions](/actions/learn-github-actions/expressions)."{% endif %}

9
translations/ja-JP/content/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork.md
View File

@@ -23,9 +23,14 @@ permissions: People with write access for a forked repository can sync the fork
## Syncing a fork branch from the web UI
{% ifversion syncing-fork-web-ui %}
1. On {% data variables.product.product_name %}, navigate to the main page of the forked repository that you want to sync with the upstream repository.
2. Select the **Fetch upstream** drop-down. !["Fetch upstream" drop-down](/assets/images/help/repository/fetch-upstream-drop-down.png)
3. Review the details about the commits from the upstream repository, then click **Fetch and merge**. !["Fetch and merge" button](/assets/images/help/repository/fetch-and-merge-button.png)
2. Select the **Sync fork** dropdown. !["Sync fork" dropdown emphasized](/assets/images/help/repository/sync-fork-dropdown.png)
3. Review the details about the commits from the upstream repository, then click **Update branch**. ![Sync fork modal with "Update branch" button emphasized](/assets/images/help/repository/update-branch-button.png)
{% else %}
1. On {% data variables.product.product_name %}, navigate to the main page of the forked repository that you want to sync with the upstream repository.
2. Select the **Fetch upstream** dropdown. !["Fetch upstream" drop-down](/assets/images/help/repository/fetch-upstream-drop-down.png)
3. Review the details about the commits from the upstream repository, then click **Fetch and merge**. !["Fetch and merge" button](/assets/images/help/repository/fetch-and-merge-button.png){% endif %}
If the changes from the upstream repository cause conflicts, {% data variables.product.company_short %} will prompt you to create a pull request to resolve the conflicts.

2
translations/ja-JP/content/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/displaying-a-sponsor-button-in-your-repository.md
View File

@@ -17,7 +17,7 @@ shortTitle: Display a sponsor button
You can configure your sponsor button by editing a _FUNDING.yml_ file in your repository's `.github` folder, on the default branch. You can configure the button to include sponsored developers in {% data variables.product.prodname_sponsors %}, external funding platforms, or a custom funding URL. For more information about {% data variables.product.prodname_sponsors %}, see "[About GitHub Sponsors](/sponsors/getting-started-with-github-sponsors/about-github-sponsors)."
You can add one username, package name, or project name per external funding platform and up to four custom URLs. You can add up to four sponsored developers or organizations in {% data variables.product.prodname_sponsors %}. Add each platform on a new line, using the following syntax:
You can add one username, package name, or project name per external funding platform and up to four custom URLs. You can add one organization and up to four sponsored developers in {% data variables.product.prodname_sponsors %}. Add each platform on a new line, using the following syntax:
Platform | Syntax
-------- | -----

2
translations/ja-JP/content/rest/actions/cache.md
View File

@@ -13,4 +13,4 @@ versions:
## Cache APIについて
{% data variables.product.prodname_actions %} Cache APIを使うと、リポジトリの{% data variables.product.prodname_actions %}キャッシュに対するクエリと管理ができます。 {% ifversion actions-cache-management %}You can also install a {% data variables.product.prodname_cli %} extension to manage your caches from the command line. {% endif %}For more information, see "[Caching dependencies to speed up workflows](/actions/advanced-guides/caching-dependencies-to-speed-up-workflows#managing-caches)."
{% data variables.product.prodname_actions %} Cache APIを使うと、リポジトリの{% data variables.product.prodname_actions %}キャッシュに対するクエリと管理ができます。 {% ifversion actions-cache-management %}{% data variables.product.prodname_cli %}機能拡張をインストールして、コマンドラインからキャッシュを管理することもできます。 {% endif %}詳しい情報については「[ワークフローを高速化するための依存関係のキャッシング](/actions/advanced-guides/caching-dependencies-to-speed-up-workflows#managing-caches)」を参照してください。

20
translations/ja-JP/content/rest/deployments/branch-policies.md Normal file
View File

@@ -0,0 +1,20 @@
---
title: デプロイメントブランチポリシー
allowTitleToDifferFromFilename: true
shortTitle: デプロイメントブランチポリシー
intro: Deployment branch policies APIを使うと、カスタムのデプロイメントブランチポリシーを管理できます。
versions:
fpt: '*'
ghes: '*'
ghae: '*'
ghec: '*'
topics:
- API
miniTocMaxHeadingLevel: 3
---
## Deployment branch policies APIについて
Deployment branch policies APIを使うと、環境へデプロイするためにブランチがマッチしなければならないカスタムの名前パターンを指定できます。 これらのエンドポイントを使うためには、環境の`deployment_branch_policy.custom_branch_policies`は`true`に設定しなければなりません。 環境の`deployment_branch_policy`を更新するには、「[環境の作成もしくは更新](/rest/deployments/environments#create-or-update-an-environment)」を参照してください。
特定のブランチに環境のデプロイメントを制限することに関する詳しい情報については「[デプロイメントのための環境の利用](/actions/deployment/targeting-different-environments/using-environments-for-deployment#deployment-branches)」を参照してください。

1
translations/ja-JP/content/rest/deployments/index.md
View File

@@ -14,6 +14,7 @@ children:
- /deployments
- /environments
- /statuses
- /branch-policies
redirect_from:
- /rest/reference/deployments
---

2
translations/ja-JP/content/rest/enterprise-admin/license.md
View File

@@ -4,6 +4,8 @@ intro: ライセンス API は、Enterprise ライセンスに関する情報を
versions:
ghes: '*'
ghae: '*'
ghec: '*'
fpt: '*'
topics:
- API
miniTocMaxHeadingLevel: 3

203
translations/ja-JP/content/rest/guides/getting-started-with-the-rest-api.md
View File

@@ -1,6 +1,6 @@
---
title: REST APIを使ってみる
intro: 認証とエンドポイントの例から始めて、REST APIを使用するための基礎を学びます。
title: Getting started with the REST API
intro: 'Learn the foundations for using the REST API, starting with authentication and some endpoint examples.'
redirect_from:
- /guides/getting-started
- /v3/guides/getting-started
@@ -11,23 +11,28 @@ versions:
ghec: '*'
topics:
- API
shortTitle: 始めましょう - REST API
shortTitle: Get started - REST API
---
日常的なユースケースに取り組みながら、APIの中心的な概念を見ていきましょう。
Let's walk through core API concepts as we tackle some everyday use cases.
{% data reusables.rest-api.dotcom-only-guide-note %}
## 概要
## Overview
ほとんどのアプリケーションは、任意の言語において既存の[ラッパーライブラリ][wrappers]を使用しています。ただ、まずは基底となっているAPI HTTPメソッドについて知ることが大切です。
Most applications will use an existing [wrapper library][wrappers] in the language
of your choice, but it's important to familiarize yourself with the underlying API
HTTP methods first.
ちょっと試しにやってみるだけなら、[cURL][curl]を使うのが一番簡単です。{% ifversion fpt or ghec %}別のクライアントを使用している場合、リクエストで有効な [ユーザエージェントのヘッダ](/rest/overview/resources-in-the-rest-api#user-agent-required)を送信する必要があることに注意してください。{% endif %}
There's no easier way to kick the tires than through [cURL][curl].{% ifversion fpt or ghec %} If you are using
an alternative client, note that you are required to send a valid
[User Agent header](/rest/overview/resources-in-the-rest-api#user-agent-required) in your request.{% endif %}
### Hello World
まずはセットアップをテストすることから始めましょう。 コマンドプロンプトを開き、次のコマンドを入力します。
Let's start by testing our setup. Open up a command prompt and enter the
following command:
```shell
$ curl https://api.github.com/zen
@@ -35,7 +40,7 @@ $ curl https://api.github.com/zen
> Keep it logically awesome.
```
レスポンスは、私たちの設計思想からランダムに選択されます。
The response will be a random selection from our design philosophies.
Next, let's `GET` [Chris Wanstrath's][defunkt github] [GitHub profile][users api]:
@@ -55,7 +60,7 @@ $ curl https://api.github.com/users/defunkt
> }
```
Mmmmm, tastes like [JSON][json]. `-i`フラグを追加して、ヘッダを入れてみましょう。
Mmmmm, tastes like [JSON][json]. Let's add the `-i` flag to include headers:
```shell
$ curl -i https://api.github.com/users/defunkt
@@ -99,57 +104,66 @@ $ curl -i https://api.github.com/users/defunkt
> }
```
レスポンスヘッダの中に、ちょっと面白いものがありますね。 思っていたとおり、`Content-Type`は`application/json`です。
There are a few interesting bits in the response headers. As expected, the
`Content-Type` is `application/json`.
`X-`で始まるヘッダはすべてカスタムヘッダで、HTTPの仕様にはありません。 たとえば、`X-RateLimit-Limit`と`X-RateLimit-Remaining`のヘッダに注目してください。 This pair of headers indicate [how many requests a client can make][rate-limiting] in a rolling time period (typically an hour) and how many of those requests the client has already spent.
Any headers beginning with `X-` are custom headers, and are not included in the
HTTP spec. For example, take note of the `X-RateLimit-Limit` and `X-RateLimit-Remaining` headers. This
pair of headers indicate [how many requests a client can make][rate-limiting] in
a rolling time period (typically an hour) and how many of those requests the
client has already spent.
## 認証
## Authentication
認証されていないクライアントは、1時間に60件のリクエストを行うことができます。 1時間あたりのリクエストを増やすには、_認証_が必要です。 In fact, doing anything interesting with the {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} API requires [authentication][authentication].
Unauthenticated clients can make 60 requests per hour. To get more requests per hour, we'll need to
_authenticate_. In fact, doing anything interesting with the {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} API requires
[authentication][authentication].
### 個人アクセストークンの使用
### Using personal access tokens
{% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} APIで認証を受けるもっと簡単で最善の方法は、[OAuthトークン経由](/rest/overview/other-authentication-methods#via-oauth-and-personal-access-tokens)でBasic認証を使うことです。 OAuth tokens include [personal access tokens][personal token].
The easiest and best way to authenticate with the {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} API is by using Basic Authentication [via OAuth tokens](/rest/overview/other-authentication-methods#via-oauth-and-personal-access-tokens). OAuth tokens include [personal access tokens][personal token].
`-u`フラグを使って、ユーザ名を設定します。
Use a `-u` flag to set your username:
```shell
$ curl -i -u <em>your_username</em> {% data variables.product.api_url_pre %}/users/octocat
```
プロンプトが表示されたらOAuthトークンを入力できますが、そのための変数を設定することをお勧めします。
When prompted, you can enter your OAuth token, but we recommend you set up a variable for it:
`-u "your_username:$token"`を使い、`トークン`の変数をセットアップして、シェルの履歴にトークンが残らないようにできます。トークンは残さないようにするべきです。
You can use `-u "your_username:$token"` and set up a variable for `token` to avoid leaving your token in shell history, which should be avoided.
```shell
$ curl -i -u <em>your_username:$token</em> {% data variables.product.api_url_pre %}/users/octocat
```
認証の際、`X-RateLimit-Limit`ヘッダが示す通り、レート制限が1時間に5,000リクエストに上がったことがわかるはずです。 1時間あたりの呼び出し数が増えるだけでなく、認証するとAPIを使用してプライベート情報を読み書きできます。
When authenticating, you should see your rate limit bumped to 5,000 requests an hour, as indicated in the `X-RateLimit-Limit` header. In addition to providing more calls per hour, authentication enables you to read and write private information using the API.
You can easily [create a **personal access token**][personal token] using your [Personal access tokens settings page][tokens settings]:
{% warning %}
自分の情報をセキュアに保てるようにするために、個人アクセストークンに有効期限を設定することを強くおすすめします。
To help keep your information secure, we highly recommend setting an expiration for your personal access tokens.
{% endwarning %}
{% ifversion fpt or ghes or ghec %}
![個人トークンの選択](/assets/images/personal_token.png)
![Personal Token selection](/assets/images/personal_token.png)
{% endif %}
{% ifversion ghae %}
![個人トークンの選択](/assets/images/help/personal_token_ghae.png)
![Personal Token selection](/assets/images/help/personal_token_ghae.png)
{% endif %}
期限切れの個人アクセストークンを使用したAPIリクエストには、`GitHub-Authentication-Token-Expiration`を通じてそのトークンの有効期限が返されます。 このヘッダをスクリプト中で使って、トークンが有効期限に近づいてきたら警告メッセージを出すことができます。
API requests using an expiring personal access token will return that token's expiration date via the `GitHub-Authentication-Token-Expiration` header. You can use the header in your scripts to provide a warning message when the token is close to its expiration date.
### ユーザプロフィールの取得
### Get your own user profile
適切に認証されると、{% ifversion ghae %}{% data variables.product.product_name %}{% else %}{% data variables.product.product_location %}{% endif %}上のアカウントに関連づけられた権限を活用できます。 たとえば、あなたのプロフィールを取得してみましょう。
When properly authenticated, you can take advantage of the permissions
associated with your account on {% ifversion ghae %}{% data variables.product.product_name %}{% else %}{% data variables.product.product_location %}{% endif %}. For example, try getting
[your own user profile][auth user api]:
```shell
$ curl -i -u <em>your_username</em>:<em>your_token</em> {% data variables.product.api_url_pre %}/user
@@ -166,28 +180,39 @@ $ curl -i -u <em>your_username</em>:<em>your_token</em> {% data variables.produc
> }
```
This time, in addition to the same set of public information we retrieved for [@defunkt][defunkt github] earlier, you should also see the non-public information for your user profile. たとえば、アカウントの{% data variables.product.product_name %}プランに関する詳細を持つ`plan`オブジェクトがレスポンス中にあります。
This time, in addition to the same set of public information we
retrieved for [@defunkt][defunkt github] earlier, you should also see the non-public information for your user profile. For example, you'll see a `plan` object in the response which gives details about the {% data variables.product.product_name %} plan for the account.
### OAuthトークンのアプリケーションへの使用
### Using OAuth tokens for apps
他のユーザに代わりAPIを使用してプライベートな情報を読み書きする必要があるアプリは、 [OAuth][oauth]を使用すべきです。
Apps that need to read or write private information using the API on behalf of another user should use [OAuth][oauth].
OAuthは_トークン_を使用します。 トークンには、次の2つの重要な機能があります。
OAuth uses _tokens_. Tokens provide two big features:
* **アクセスを取り消せる**: ユーザはサードパーティアプリケーションへの認可をいつでも取り消すことができます
* **制限付きアクセス**: ユーザはサードパーティーアプリケーションを認可する前に、トークンが提供する特定のアクセスを確認できます
* **Revokable access**: users can revoke authorization to third party apps at any time
* **Limited access**: users can review the specific access that a token
will provide before authorizing a third party app
トークンは[web フロー][webflow]から作成してください。 アプリケーションはユーザを{% data variables.product.product_name %}に送信してログインします。 それから{% data variables.product.product_name %}はアプリケーションの名前と、ユーザが認可した場合のアクセス権レベルを示すダイアログを表示します。 ユーザがアクセスを認可すると、{% data variables.product.product_name %}はユーザをアプリケーションにリダイレクトします。
Tokens should be created via a [web flow][webflow]. An application
sends users to {% data variables.product.product_name %} to log in. {% data variables.product.product_name %} then presents a dialog
indicating the name of the app, as well as the level of access the app
has once it's authorized by the user. After a user authorizes access, {% data variables.product.product_name %}
redirects the user back to the application:
![GitHubのOAuthプロンプト](/assets/images/oauth_prompt.png)
![GitHub's OAuth Prompt](/assets/images/oauth_prompt.png)
**OAuthトークンはパスワードと同様に扱ってください。**他のユーザと共有したり、安全でない場所に保存したりしてはいけません。 ここにあるトークンのサンプルは架空のものであり、不要な被害を防ぐため名前を変更しています。
**Treat OAuth tokens like passwords!** Don't share them with other users or store
them in insecure places. The tokens in these examples are fake and the names have
been changed to protect the innocent.
Now that we've got the hang of making authenticated calls, let's move along to the [Repositories API][repos-api].
Now that we've got the hang of making authenticated calls, let's move along to
the [Repositories API][repos-api].
## リポジトリ
## Repositories
ほとんどあらゆる意味のある{% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} APIの利用には、なんらかのレベルのリポジトリ情報が関わります。 We can [`GET` repository details][get repo] in the same way we fetched user details earlier:
Almost any meaningful use of the {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} API will involve some level of Repository
information. We can [`GET` repository details][get repo] in the same way we fetched user
details earlier:
```shell
$ curl -i {% data variables.product.api_url_pre %}/repos/twbs/bootstrap
@@ -212,26 +237,32 @@ Or, we can [list repositories for an organization][org repos api]:
$ curl -i {% data variables.product.api_url_pre %}/orgs/octo-org/repos
```
これらの呼び出しから返される情報は、認証時にトークンが持っているスコープにより異なります。
The information returned from these calls will depend on which scopes our token has when we authenticate:
{%- ifversion fpt or ghec or ghes %}
* A token with `public_repo` [scope][scopes] returns a response that includes all public repositories we have access to see on {% data variables.product.product_location %}.
{%- endif %}
* A token with `repo` [scope][scopes] returns a response that includes all {% ifversion fpt %}public or private{% elsif ghec or ghes %}public, private, or internal{% elsif ghae %}private or internal{% endif %} repositories we have access to see on {% data variables.product.product_location %}.
As the [docs][repos-api] indicate, these methods take a `type` parameter that can filter the repositories returned based on what type of access the user has for the repository. こうすることで、直接所有するリポジトリ、Organizationのリポジトリ、またはチームによりユーザがコラボレーションするリポジトリに限定してフェッチすることができます。
As the [docs][repos-api] indicate, these methods take a `type` parameter that
can filter the repositories returned based on what type of access the user has
for the repository. In this way, we can fetch only directly-owned repositories,
organization repositories, or repositories the user collaborates on via a team.
```shell
$ curl -i "{% data variables.product.api_url_pre %}/users/octocat/repos?type=owner"
```
この例では、octocatが所有するリポジトリのみを取得し、コラボレーションするリポジトリは取得しません。 URLが引用符で囲まれていることに注目してください。 シェルの設定によっては、cURLはURLを引用符で囲まないとクエリ文字列型を無視することがあります。
In this example, we grab only those repositories that octocat owns, not the
ones on which she collaborates. Note the quoted URL above. Depending on your
shell setup, cURL sometimes requires a quoted URL or else it ignores the
query string.
### リポジトリの作成
### Create a repository
既存のリポジトリ情報をフェッチすることは一般的なユースケースですが、
{% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} APIは、新しいリポジトリの作成もサポートします。 To [create a repository][create repo],
詳細情報や設定オプションを含んだいくつかのJSONを`POST`する必要があります。
Fetching information for existing repositories is a common use case, but the
{% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} API supports creating new repositories as well. To [create a repository][create repo],
we need to `POST` some JSON containing the details and configuration options.
```shell
$ curl -i -H "Authorization: token ghp_16C7e42F292c6912E7710c838347Ae178B4a" \
@@ -244,11 +275,14 @@ $ curl -i -H "Authorization: token ghp_16C7e42F292c6912E7710c838347Ae178B4a" \
{% data variables.product.api_url_pre %}/user/repos
```
In this minimal example, we create a new private repository for our blog (to be served on [GitHub Pages][pages], perhaps). このブログは{% ifversion not ghae %}パブリックになり{% else %}すべてのEnterpriseメンバーからアクセスできるようになり{% endif %}ますが、このリポジトリはプライベートにしました。 In this single step, we'll also initialize it with a README and a [nanoc][nanoc]-flavored [.gitignore template][gitignore templates].
In this minimal example, we create a new private repository for our blog (to be served
on [GitHub Pages][pages], perhaps). Though the blog {% ifversion not ghae %}will be public{% else %}is accessible to all enterprise members{% endif %}, we've made the repository private. In this single step, we'll also initialize it with a README and a [nanoc][nanoc]-flavored [.gitignore template][gitignore templates].
生成されたリポジトリは、`https://github.com/<your_username>/blog`にあります。 オーナーであるOrganization以下にリポジトリを作成するには、APIメソッドを `/user/repos`から`/orgs/<org_name>/repos`に変更するだけです。
The resulting repository will be found at `https://github.com/<your_username>/blog`.
To create a repository under an organization for which you're
an owner, just change the API method from `/user/repos` to `/orgs/<org_name>/repos`.
次に、新しく作成したリポジトリをフェッチしましょう。
Next, let's fetch our newly created repository:
```shell
$ curl -i {% data variables.product.api_url_pre %}/repos/pengwynn/blog
@@ -260,13 +294,21 @@ $ curl -i {% data variables.product.api_url_pre %}/repos/pengwynn/blog
> }
```
あれれ？ どこにいったのでしょう。 リポジトリを_プライベート_にして作成したので、表示するには認証する必要があります。 古参のHTTPユーザの方なら、`403`が出ると思っていたかもしれません。 プライベートリポジトリに関する情報を漏洩させたくはないので、{% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} APIはこの場合「このリポジトリの存在を確認も否認もできません」というように`404`を返します。
Oh noes! Where did it go? Since we created the repository as _private_, we need
to authenticate in order to see it. If you're a grizzled HTTP user, you might
expect a `403` instead. Since we don't want to leak information about private
repositories, the {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} API returns a `404` in this case, as if to say "we can
neither confirm nor deny the existence of this repository."
## Issue
## Issues
{% data variables.product.product_name %}のIssue用UIは、「必要十分」なワークフローを提供しつつ、邪魔にならないということを目指しています。 With the {% data variables.product.product_name %} [Issues API][issues-api], you can pull data out or create issues from other tools to create a workflow that works for your team.
The UI for Issues on {% data variables.product.product_name %} aims to provide 'just enough' workflow while
staying out of your way. With the {% data variables.product.product_name %} [Issues API][issues-api], you can pull
data out or create issues from other tools to create a workflow that works for
your team.
GitHub.comと同じように、Issues APIは認証されたユーザがIssueを表示するためのメソッドをいくつか提供します。 To [see all your issues][get issues api], call `GET /issues`:
Just like github.com, the API provides a few methods to view issues for the
authenticated user. To [see all your issues][get issues api], call `GET /issues`:
```shell
$ curl -i -H "Authorization: token ghp_16C7e42F292c6912E7710c838347Ae178B4a" \
@@ -287,9 +329,11 @@ We can also get [all the issues under a single repository][repo issues api]:
$ curl -i {% data variables.product.api_url_pre %}/repos/rails/rails/issues
```
### ページネーション
### Pagination
Railsのような規模のプロジェクトになれば、万単位のIssueがあります。 We'll need to [paginate][pagination], making multiple API calls to get the data. 直近で行った呼び出しを繰り返してみましょう。今回はレスポンスヘッダに注目してください。
A project the size of Rails has thousands of issues. We'll need to [paginate][pagination],
making multiple API calls to get the data. Let's repeat that last call, this
time taking note of the response headers:
```shell
$ curl -i {% data variables.product.api_url_pre %}/repos/rails/rails/issues
@@ -301,13 +345,20 @@ $ curl -i {% data variables.product.api_url_pre %}/repos/rails/rails/issues
> ...
```
The [`Link` header][link-header] provides a way for a response to link to external resources, in this case additional pages of data. 呼び出しで30 (デフォルトのページサイズ) を超えるIssueを検出したので、APIは次のページと最後のページの場所を伝えます。
The [`Link` header][link-header] provides a way for a response to link to
external resources, in this case additional pages of data. Since our call found
more than thirty issues (the default page size), the API tells us where we can
find the next page and the last page of results.
### Issue の作成
### Creating an issue
Now that we've seen how to paginate lists of issues, let's [create an issue][create issue] from the API.
Now that we've seen how to paginate lists of issues, let's [create an issue][create issue] from
the API.
Issueを作成するには認証される必要があるので、ヘッダにOAuthトークンを渡します。 また、タイトル、本文、およびJSONの本文にあるラベルを、Issueを作成したい、リポジトリ以下の`/issues`パスに渡します。
To create an issue, we need to be authenticated, so we'll pass an
OAuth token in the header. Also, we'll pass the title, body, and labels in the JSON
body to the `/issues` path underneath the repository in which we want to create
the issue:
```shell
$ curl -i -H 'Authorization: token ghp_16C7e42F292c6912E7710c838347Ae178B4a' \
@@ -359,11 +410,14 @@ $ {% data variables.product.api_url_pre %}/repos/pengwynn/api-sandbox/issues
> }
```
レスポンスでは、新しく作成されたIssueに2つのポインタを提供し、それは両方とも`Location`レスポンスヘッダとJSONレスポンスの `url`フィールドにあります。
The response gives us a couple of pointers to the newly created issue, both in
the `Location` response header and the `url` field of the JSON response.
## 条件付きリクエスト
## Conditional requests
良きAPI利用者であるために非常に大切なのは、変更されていない情報をキャッシュして、レート制限を尊重するということです。 The API supports [conditional requests][conditional-requests] and helps you do the right thing. 最初に呼び出した、Chris Wanstrathのプロフィールを取り上げてみましょう。
A big part of being a good API citizen is respecting rate limits by caching information that hasn't changed. The API supports [conditional
requests][conditional-requests] and helps you do the right thing. Consider the
first call we made to get defunkt's profile:
```shell
$ curl -i {% data variables.product.api_url_pre %}/users/defunkt
@@ -372,7 +426,10 @@ $ curl -i {% data variables.product.api_url_pre %}/users/defunkt
> etag: W/"61e964bf6efa3bc3f9e8549e56d4db6e0911d8fa20fcd8ab9d88f13d513f26f0"
```
JSONの本文に加え、HTTPステータスコード `200`と`ETag`ヘッダに注目してください。 The [ETag][etag] is a fingerprint of the response. 後続の呼び出しにこれを渡すと、変更されたリソースだけを渡すようAPIに伝えることができます。
In addition to the JSON body, take note of the HTTP status code of `200` and
the `ETag` header.
The [ETag][etag] is a fingerprint of the response. If we pass that on subsequent calls,
we can tell the API to give us the resource again, only if it has changed:
```shell
$ curl -i -H 'If-None-Match: "61e964bf6efa3bc3f9e8549e56d4db6e0911d8fa20fcd8ab9d88f13d513f26f0"' \
@@ -381,23 +438,24 @@ $ {% data variables.product.api_url_pre %}/users/defunkt
> HTTP/2 304
```
`304`ステータスは、直近のリクエストからリソースが変更されておらず、レスポンスには本文が含まれないことを示しています。 As a bonus, `304` responses don't count against your [rate limit][rate-limiting].
The `304` status indicates that the resource hasn't changed since the last time
we asked for it and the response will contain no body. As a bonus, `304` responses don't count against your [rate limit][rate-limiting].
以上で{% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} APIの基本を学んだことになります！
Now you know the basics of the {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} API!
* Basic & OAuth認証
* リポジトリおよびIssueのフェッチと作成
* 条件付きリクエスト
* Basic & OAuth authentication
* Fetching and creating repositories and issues
* Conditional requests
Keep learning with the next API guide [Basics of Authentication][auth guide]!
[wrappers]: /libraries/
[curl]: http://curl.haxx.se/
[media types]: /rest/overview/media-types
[oauth]: /apps/building-integrations/setting-up-and-registering-oauth-apps/
[webflow]: /apps/building-oauth-apps/authorizing-oauth-apps/
[scopes]: /apps/building-oauth-apps/understanding-scopes-for-oauth-apps/
[repos-api]: /rest/reference/repos
[repos-api]: /rest/reference/repos
[pages]: http://pages.github.com
[nanoc]: http://nanoc.ws/
[gitignore templates]: https://github.com/github/gitignore
@@ -405,13 +463,14 @@ Keep learning with the next API guide [Basics of Authentication][auth guide]!
[link-header]: https://www.w3.org/wiki/LinkHeader
[conditional-requests]: /rest#conditional-requests
[rate-limiting]: /rest/overview/resources-in-the-rest-api#rate-limit-http-headers
[rate-limiting]: /rest/overview/resources-in-the-rest-api#rate-limit-http-headers
[users api]: /rest/reference/users#get-a-user
[defunkt github]: https://github.com/defunkt
[auth user api]: /rest/reference/users#get-the-authenticated-user
[defunkt github]: https://github.com/defunkt
[json]: http://en.wikipedia.org/wiki/JSON
[authentication]: /rest#authentication
[personal token]: /articles/creating-an-access-token-for-command-line-use
[2fa]: /articles/about-two-factor-authentication
[2fa header]: /rest/overview/other-authentication-methods#working-with-two-factor-authentication
[oauth section]: /rest/guides/getting-started-with-the-rest-api#oauth
[personal token]: /articles/creating-an-access-token-for-command-line-use
[tokens settings]: https://github.com/settings/tokens
[pagination]: /rest#pagination
@@ -423,6 +482,6 @@ Keep learning with the next API guide [Basics of Authentication][auth guide]!
[other user repos api]: /rest/reference/repos#list-repositories-for-a-user
[org repos api]: /rest/reference/repos#list-organization-repositories
[get issues api]: /rest/reference/issues#list-issues-assigned-to-the-authenticated-user
[get issues api]: /rest/reference/issues#list-issues-assigned-to-the-authenticated-user
[repo issues api]: /rest/reference/issues#list-repository-issues
[etag]: http://en.wikipedia.org/wiki/HTTP_ETag
[2fa section]: /rest/guides/getting-started-with-the-rest-api#two-factor-authentication

4
translations/ja-JP/content/rest/orgs/security-managers.md
View File

@@ -1,10 +1,10 @@
---
title: Security Managers
title: セキュリティマネージャー
intro: ''
versions:
fpt: '*'
ghes: '>=3.7'
ghae: 'issue-7691'
ghae: issue-7691
ghec: '*'
topics:
- API

4
translations/ja-JP/content/rest/overview/permissions-required-for-github-apps.md
View File

@@ -570,13 +570,13 @@ _キー_
{% endif -%}
- [`GET /orgs/:org/team/:team_id`](/rest/teams/teams#get-a-team-by-name) (:read)
{% ifversion fpt or ghec -%}
- [`GET /scim/v2/orgs/:org/Users`](/rest/reference/scim#list-scim-provisioned-identities) (:read)
- [`GET /scim/v2/orgs/:org/Users`](/rest/reference/scim#list-scim-provisioned-identities) (:write)
{% endif -%}
{% ifversion fpt or ghec -%}
- [`POST /scim/v2/orgs/:org/Users`](/rest/reference/scim#provision-and-invite-a-scim-user) (:write)
{% endif -%}
{% ifversion fpt or ghec -%}
- [`GET /scim/v2/orgs/:org/Users/:external_identity_guid`](/rest/reference/scim#get-scim-provisioning-information-for-a-user) (:read)
- [`GET /scim/v2/orgs/:org/Users/:external_identity_guid`](/rest/reference/scim#get-scim-provisioning-information-for-a-user) (:write)
{% endif -%}
{% ifversion fpt or ghec -%}
- [`PUT /scim/v2/orgs/:org/Users/:external_identity_guid`](/rest/reference/scim#set-scim-information-for-a-provisioned-user) (:write)

6
translations/ja-JP/content/rest/overview/resources-in-the-rest-api.md
View File

@@ -226,7 +226,7 @@ REST API を介して `node_id` を検索し、それらを GraphQL 操作で使
## HTTP メソッド
可能な場合、{% data variables.product.product_name %} REST APIはそれぞれのアクションに対して適切なHTTPメソッドを使うように努めます。 Note that HTTP verbs are case-sensitive.
可能な場合、{% data variables.product.product_name %} REST APIはそれぞれのアクションに対して適切なHTTPメソッドを使うように努めます。 HTTPメソッドは大文字と小文字を区別することに注意してください。
| メソッド | 説明 |
| -------- | ----------------------------------------------------------------------------------------------------------------------------- |
@@ -299,7 +299,7 @@ _この例は、読みやすいように改行されています。_
## タイムアウト
If {% data variables.product.prodname_dotcom %} takes more than 10 seconds to process an API request, {% data variables.product.prodname_dotcom %} will terminate the request and you will receive a timeout response like this:
{% data variables.product.prodname_dotcom %}がAPIリクエストを処理するのに10秒以上かかると、{% data variables.product.prodname_dotcom %}はリクエストを終了させ、以下のようなタイムアウトのレスポンスが返されます。
```json
{
@@ -307,7 +307,7 @@ If {% data variables.product.prodname_dotcom %} takes more than 10 seconds to pr
}
```
{% data variables.product.product_name %} reserves the right to change the timeout window to protect the speed and reliability of the API.
{% data variables.product.product_name %}は、APIの速度と信頼性を保護するためにタイムアウトのウィンドウを変更する権限を留保します。
## レート制限

4
translations/ja-JP/content/rest/projects/cards.md
View File

@@ -1,8 +1,8 @@
---
title: '{% data variables.product.prodname_project_v1_caps %} cards'
title: '{% data variables.product.prodname_project_v1_caps %}カード'
shortTitle: カード
allowTitleToDifferFromFilename: true
intro: 'The {% data variables.product.prodname_project_v1 %} cards API lets you create and manage cards on a {% data variables.projects.projects_v1_board %}.'
intro: '{% data variables.product.prodname_project_v1 %} cards APIを使うと、{% data variables.projects.projects_v1_board %}上でカードを作成及び管理できます。'
versions:
fpt: '*'
ghes: '*'

4
translations/ja-JP/content/rest/projects/collaborators.md
View File

@@ -1,8 +1,8 @@
---
title: '{% data variables.product.prodname_project_v1_caps %} collaborators'
title: '{% data variables.product.prodname_project_v1_caps %}のコラボレータ'
shortTitle: コラボレータ
allowTitleToDifferFromFilename: true
intro: 'The {% data variables.product.prodname_project_v1 %} collaborators API lets you manage collaborators on a {% data variables.projects.projects_v1_board %}.'
intro: '{% data variables.product.prodname_project_v1 %} collaborators APIを使うと、{% data variables.projects.projects_v1_board %}上のコラボレータを管理できます。'
versions:
fpt: '*'
ghes: '*'

6
translations/ja-JP/content/rest/projects/columns.md
View File

@@ -1,8 +1,8 @@
---
title: '{% data variables.product.prodname_project_v1_caps %} columns'
shortTitle: カラム
title: '{% data variables.product.prodname_project_v1_caps %}の列'
shortTitle: 列
allowTitleToDifferFromFilename: true
intro: 'The {% data variables.product.prodname_project_v1 %} columns API lets you create and manage columns on a {% data variables.projects.projects_v1_board %}.'
intro: '{% data variables.product.prodname_project_v1 %} columns APIを使うと、{% data variables.projects.projects_v1_board %}上の列の作成及び管理ができます。'
versions:
fpt: '*'
ghes: '*'

2
translations/ja-JP/content/rest/projects/index.md
View File

@@ -1,6 +1,6 @@
---
title: '{% data variables.product.prodname_projects_v1_caps %}'
intro: 'The {% data variables.product.prodname_projects_v1 %} API lets you create, list, update, delete and customize {% data variables.projects.projects_v1_boards %}.'
intro: '{% data variables.product.prodname_projects_v1 %} APIを使うと、{% data variables.projects.projects_v1_boards %}の作成、リスト、更新、削除、カスタマイズができます。'
redirect_from:
- /v3/projects
- /rest/reference/projects

2
translations/ja-JP/content/rest/projects/projects.md
View File

@@ -2,7 +2,7 @@
title: '{% data variables.product.prodname_projects_v1_caps %}'
shortTitle: ボード
allowTitleToDifferFromFilename: true
intro: 'The {% data variables.product.prodname_projects_v1 %} API lets you create and manage {% data variables.projects.projects_v1_boards %} in a repository.'
intro: '{% data variables.product.prodname_projects_v1 %} APIを使うと、リポジトリの{% data variables.projects.projects_v1_boards %}の作成や管理ができます。'
versions:
fpt: '*'
ghes: '*'

2
translations/ja-JP/content/site-policy/privacy-policies/github-privacy-statement.md
View File

@@ -314,7 +314,7 @@ You have a right to opt-out from future “sales” of personal information. Not
#### Right to Non-Discrimination.
You have a right to not be discriminated against for exercising your CCPA rights. We will not discriminate against you for exercising your CCPA rights.
You may designate, in writing or through a power of attorney, an authorized agent to make requests on your behalf to exercise your rights under the CCPA. Before accepting such a request from an agent, we will require the agent to provide proof you have authorized it to act on your behalf, and we may need you to verify your identity directly with us. Further, to provide or delete specific pieces of personal information we will need to verify your identity to the degree of certainty required by law. We will verify your request by asking you to submit the request from the email address associated with your account or requiring you to provide information necessary to verify your account. [Please note that you may use two-factor authentication with your GitHub account.](/authentication/securing-your-account-with-two-factor-authentication-2fa/accessing-github-using-two-factor-authentication)
You may designate, in writing or through a power of attorney, an authorized agent to make requests on your behalf to exercise your rights under the CCPA. Before accepting such a request from an agent, we will require the agent to provide proof you have authorized it to act on your behalf, and we may need you to verify your identity directly with us. Further, to provide or delete specific pieces of personal information we will need to verify your identity to the degree of certainty required by law. We will verify your request by asking you to submit the request from the email address associated with your account or requiring you to provide information necessary to verify your account. [Please note that you may use two-factor authentication with your GitHub account](/authentication/securing-your-account-with-two-factor-authentication-2fa/accessing-github-using-two-factor-authentication).
Finally, you have a right to receive notice of our practices at or before collection of personal information.
Additionally, under California Civil Code section 1798.83, also known as the “Shine the Light” law, California residents who have provided personal information to a business with which the individual has established a business relationship for personal, family, or household purposes (“California Customers”) may request information about whether the business has disclosed personal information to any third parties for the third parties’ direct marketing purposes. Please be aware that we do not disclose personal information to any third parties for their direct marketing purposes as defined by this law. California Customers may request further information about our compliance with this law by emailing **(privacy [at] github [dot] com)**. Please note that businesses are required to respond to one request per California Customer each year and may not be required to respond to requests made by means other than through the designated email address.

5
translations/ja-JP/data/features/build-pages-with-actions.yml Normal file
View File

@@ -0,0 +1,5 @@
#Issue 7584
#Building Pages sites with Actions [GA]
versions:
fpt: '*'
ghec: '*'

5
translations/ja-JP/data/features/custom-pattern-dry-run-ga.yml Normal file
View File

@@ -0,0 +1,5 @@
#Secret scanning: custom pattern dry run GA #7527
versions:
ghec: '*'
ghes: '>3.6'
ghae: 'issue-7527'

3
translations/ja-JP/data/features/secret-scanning-custom-enterprise-35.yml
View File

@@ -3,6 +3,5 @@
##6367: updates for the "organization level dry runs (Public Beta)"
##5499: updates for the "repository level dry runs (Public Beta)"
versions:
ghec: '*'
ghes: '>3.4'
ghes: '>3.4 <3.7'
ghae: 'issue-6367'

3
translations/ja-JP/data/features/secret-scanning-custom-enterprise-36.yml
View File

@@ -3,6 +3,5 @@
##6904: updates for "enterprise account level dry runs (Public Beta)"
##7297: updates for dry runs on editing patterns (Public Beta)
versions:
ghec: '*'
ghes: '>3.5'
ghes: '>3.5 <3.7'
ghae: 'issue-6904'

7
translations/ja-JP/data/features/syncing-fork-web-ui.yml Normal file
View File

@@ -0,0 +1,7 @@
#Issue 7629
#Improved UI for manually syncing a fork
versions:
fpt: '*'
ghec: '*'
ghes: '>=3.7'
ghae: 'issue-7629'

2
translations/ja-JP/data/graphql/ghae/graphql_upcoming_changes.public-ghae.yml
View File

@@ -156,7 +156,7 @@ upcoming_changes:
owner: lukewar
-
location: ProjectNextFieldType.TASKS
description: '`TASKS` will be removed. Follow the ProjectV2 guide at https://github.blog/changelog/2022-06-23-the-new-github-issues-june-23rd-update/, to find a suitable replacement.'
description: '`TASKS`は削除されます。適切な置き換えを見つけるには、https://github.blog/changelog/2022-06-23-the-new-github-issues-june-23rd-update/ にあるProjectV2ガイドに従ってください。'
reason: '`ProjectNext`は、より多機能な`ProjectV2`に置き換えられて非推奨になりました。'
date: '2022-10-01T00:00:00+00:00'
criticality: 破壊的

2
translations/ja-JP/data/graphql/ghec/graphql_upcoming_changes.public.yml
View File

@@ -576,7 +576,7 @@ upcoming_changes:
owner: lukewar
-
location: ProjectNextFieldType.TASKS
description: '`TASKS` will be removed. Follow the ProjectV2 guide at https://github.blog/changelog/2022-06-23-the-new-github-issues-june-23rd-update/, to find a suitable replacement.'
description: '`TASKS`は削除されます。適切な置き換えを見つけるには、https://github.blog/changelog/2022-06-23-the-new-github-issues-june-23rd-update/ にあるProjectV2ガイドに従ってください。'
reason: '`ProjectNext`は、より多機能な`ProjectV2`に置き換えられて非推奨になりました。'
date: '2022-10-01T00:00:00+00:00'
criticality: 破壊的

2
translations/ja-JP/data/graphql/graphql_upcoming_changes.public.yml
View File

@@ -576,7 +576,7 @@ upcoming_changes:
owner: lukewar
-
location: ProjectNextFieldType.TASKS
description: '`TASKS` will be removed. Follow the ProjectV2 guide at https://github.blog/changelog/2022-06-23-the-new-github-issues-june-23rd-update/, to find a suitable replacement.'
description: '`TASKS`は削除されます。適切な置き換えを見つけるには、https://github.blog/changelog/2022-06-23-the-new-github-issues-june-23rd-update/ にあるProjectV2ガイドに従ってください。'
reason: '`ProjectNext`は、より多機能な`ProjectV2`に置き換えられて非推奨になりました。'
date: '2022-10-01T00:00:00+00:00'
criticality: 破壊的

2
translations/ja-JP/data/release-notes/enterprise-server/3-3/11.yml
View File

@@ -5,7 +5,7 @@ sections:
- "**中**: 攻撃者が、GitHub Enterprise ServerのWebインターフェース内のドロップダウンUI要素のクロスサイトスクリプティング（XSS）脆弱性を悪用することによってJavascriptのコードを実行することを防ぎます。"
- Grafanaをバージョン7.5.17にアップデートします。このバージョンは [CVE-2020-13379](https://github.com/advisories/GHSA-wc9w-wvq2-ffm9)及び[CVE-2022-21702](https://github.com/grafana/grafana/security/advisories/GHSA-xc3p-28hw-q24g)を含む様々なセキュリティ脆弱性に対処しています。
- パッケージは最新のセキュリティバージョンにアップデートされました。
- "**MEDIUM**: A stored XSS vulnerability was identified in GitHub Enterprise Server that allowed the injection of arbitrary attributes. This injection was blocked by Github's Content Security Policy (CSP). This vulnerability was reported via the GitHub Bug Bounty program and has been assigned [CVE-2022-23733](https://www.cve.org/CVERecord?id=CVE-2022-23733). [Updated: 2022-07-31]"
- "**中**: 任意の属性をインジェクションできるストアドXSS脆弱性がGitHub Enterprise Serverで特定されました。このインジェクションは、GitHubのContent Security Policy (CSP)によってブロックされました。この脆弱性はGitHub Bug Bountyプログラムを通じて報告され、[CVE-2022-23733] (https://www.cve.org/CVERecord?id=CVE-2022-23733)が割り当てられました。[更新:2022年7月31日]"
bugs:
- 成果物のzipアーカイブ中のファイルが、unzipツールを使って展開されたときに000の権限を持つ問題を修正しました。GitHub.comでの動作と同じように、それらのファイルの権限には644が設定されるようになりました。
- collectdデーモンが過剰にメモリを消費することがありました。

2
translations/ja-JP/data/release-notes/enterprise-server/3-4/6.yml
View File

@@ -5,7 +5,7 @@ sections:
- "**中**: 攻撃者が、GitHub Enterprise ServerのWebインターフェース内のドロップダウンUI要素のクロスサイトスクリプティング（XSS）脆弱性を悪用することによってJavascriptのコードを実行することを防ぎます。"
- Grafanaをバージョン7.5.17にアップデートします。このバージョンは [CVE-2020-13379](https://github.com/advisories/GHSA-wc9w-wvq2-ffm9)及び[CVE-2022-21702](https://github.com/grafana/grafana/security/advisories/GHSA-xc3p-28hw-q24g)を含む様々なセキュリティ脆弱性に対処しています。
- パッケージは最新のセキュリティバージョンにアップデートされました。
- "**MEDIUM**: A stored XSS vulnerability was identified in GitHub Enterprise Server that allowed the injection of arbitrary attributes. This injection was blocked by Github's Content Security Policy (CSP). This vulnerability was reported via the GitHub Bug Bounty program and has been assigned [CVE-2022-23733](https://www.cve.org/CVERecord?id=CVE-2022-23733). [Updated: 2022-07-31]"
- "**中**: 任意の属性をインジェクションできるストアドXSS脆弱性がGitHub Enterprise Serverで特定されました。このインジェクションは、GitHubのContent Security Policy (CSP)によってブロックされました。この脆弱性はGitHub Bug Bountyプログラムを通じて報告され、[CVE-2022-23733] (https://www.cve.org/CVERecord?id=CVE-2022-23733)が割り当てられました。[更新:2022年7月31日]"
bugs:
- collectdデーモンが過剰にメモリを消費することがありました。
- ローテーとされたログファイルのバックアップが蓄積され、過剰にストレージを消費することがありました。

4
translations/ja-JP/data/release-notes/enterprise-server/3-5/0-rc1.yml
View File

@@ -245,13 +245,13 @@ sections:
heading: EnterpriseのAudit log内のGitイベント
notes:
- |
The following Git-related events can now appear in the enterprise audit log. If you enable the feature and set an audit log retention period, the new events will be available for search via the UI and API, or export via JSON or CSV.
以下のGit関連のイベントが、EnterpriseのAudit logに現れるようになりました。この機能を有効化し、Audit logの保存期間を設定すると、新しいイベントはUIやAPI経由で検索したり、JSONあるいはCSVにエクスポートしたりできるようになります。
- `git.clone`
- `git.fetch`
- `git.push`
Due to the large number of Git events logged, we recommend you monitor your instance's file storage and review your related alert configurations. For more information, see "[Configuring the audit log for your enterprise](/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/configuring-the-audit-log-for-your-enterprise#managing-git-events-in-the-audit-log)."
記録されるGitイベント数は大量なので、インスタンスのファイルストレージをモニタリングし、関連するアラート設定をレビューすることをおすすめします。詳しい情報については「[EnterpriseのAudit logの設定(/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/configuring-the-audit-log-for-your-enterprise#managing-git-events-in-the-audit-log)」を参照してください。
-
heading: CODEOWNERSの改善
notes:

13
translations/ja-JP/data/release-notes/enterprise-server/3-5/0.yml
View File

@@ -238,13 +238,13 @@ sections:
heading: EnterpriseのAudit log内のGitイベント
notes:
- |
The following Git-related events can now appear in the enterprise audit log. If you enable the feature and set an audit log retention period, the new events will be available for search via the UI and API, or export via JSON or CSV.
以下のGit関連のイベントが、EnterpriseのAudit logに現れるようになりました。この機能を有効化し、Audit logの保存期間を設定すると、新しいイベントはUIやAPI経由で検索したり、JSONあるいはCSVにエクスポートしたりできるようになります。
- `git.clone`
- `git.fetch`
- `git.push`
Due to the large number of Git events logged, we recommend you monitor your instance's file storage and review your related alert configurations. For more information, see "[Configuring the audit log for your enterprise](/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/configuring-the-audit-log-for-your-enterprise#managing-git-events-in-the-audit-log)."
記録されるGitイベント数は大量なので、インスタンスのファイルストレージをモニタリングし、関連するアラート設定をレビューすることをおすすめします。詳しい情報については「[EnterpriseのAudit logの設定(/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/configuring-the-audit-log-for-your-enterprise#managing-git-events-in-the-audit-log)」を参照してください。
-
heading: CODEOWNERSの改善
notes:
@@ -290,12 +290,13 @@ sections:
GitHub Appがリリースアセットをアップロードできるようになりました。
changes:
- |
Minimum requirements for root storage and memory increased for GitHub Enterprise Server 2.10 and 3.0, and are now enforced as of 3.5.0.
ルートストレージとメモリの最小要件はGitHub Enterprise Server 2.10と3.0で増加され、3.5.0で強制されました。
- In version 2.10, the minimum requirement for root storage increased from 80 GB to 200 GB. As of 3.5.0, system preflight checks will fail if the root storage is smaller than 80 GB.
- In version 3.0, the minimum requirement for memory increased from 16 GB to 32 GB. As of 3.5.0, system preflight checks will fail if the system has less than 28 GB of memory.
- バージョン2.10では、ルートストレージの最小要件は80GBから200GBに増やされました。3.5.0では、システムのプリフライトチェックはルートストレージが80GB未満の場合失敗します。
For more information, see the minimum requirements for each supported deployment platform in "[Setting up a GitHub Enterprise Server instance](/admin/installation/setting-up-a-github-enterprise-server-instance)." [Updated: 2022-06-20]
- バージョン3.0では、メモリの最小要件が16GBから32GBに増やされました。3.5.0では、システムのプリフライトチェックはシステムが28GB未満のメモリしか持っていない場合失敗します。
詳しい情報については、「[GitHub Enterprise Serverインスタンスのセットアップ](/admin/installation/setting-up-a-github-enterprise-server-instance)」中のサポートされている各デプロイメントプラットフォームに対する最小要件を参照してください。[更新: 2022年6月20日]
- |
OAuth及びGitHub Appsでデバイス認可フローを使うためには、この機能を手動で有効化しなければなりません。この変更は、アプリケーションがGitHub Enterprise Serverのユーザに対するフィッシング攻撃に使われる可能性を、インテグレーターがそのリスクを認識し、この形態の認証をサポートする意識的な選択を確実に行うことによって下げるものです。OAuth AppもしくはGitHub Appを所有もしくは管理していて、デバイスフローを使いたいのであれば、アプリケーションの設定ページからアプリケーションに対して有効化できます。デバイスフローAPIのエンドポイントは、この機能が有効化されていないアプリケーションに対してはステータスコード`400`を返します。詳しい情報については「[OAuth Appsの認可](/developers/apps/building-oauth-apps/authorizing-oauth-apps#device-flow)」を参照してください。
- |

2
translations/ja-JP/data/release-notes/enterprise-server/3-5/3.yml
View File

@@ -5,7 +5,7 @@ sections:
- "**中**: 攻撃者が、GitHub Enterprise ServerのWebインターフェース内のドロップダウンUI要素のクロスサイトスクリプティング（XSS）脆弱性を悪用することによってJavascriptのコードを実行することを防ぎます。"
- Grafanaをバージョン7.5.17にアップデートします。このバージョンは [CVE-2020-13379](https://github.com/advisories/GHSA-wc9w-wvq2-ffm9)及び[CVE-2022-21702](https://github.com/grafana/grafana/security/advisories/GHSA-xc3p-28hw-q24g)を含む様々なセキュリティ脆弱性に対処しています。
- パッケージは最新のセキュリティバージョンにアップデートされました。
- "**MEDIUM**: A stored XSS vulnerability was identified in GitHub Enterprise Server that allowed the injection of arbitrary attributes. This injection was blocked by Github's Content Security Policy (CSP). This vulnerability was reported via the GitHub Bug Bounty program and has been assigned [CVE-2022-23733](https://www.cve.org/CVERecord?id=CVE-2022-23733). [Updated: 2022-07-31]"
- "**中**: 任意の属性をインジェクションできるストアドXSS脆弱性がGitHub Enterprise Serverで特定されました。このインジェクションは、GitHubのContent Security Policy (CSP)によってブロックされました。この脆弱性はGitHub Bug Bountyプログラムを通じて報告され、[CVE-2022-23733] (https://www.cve.org/CVERecord?id=CVE-2022-23733)が割り当てられました。[更新:2022年7月31日]"
bugs:
- collectdデーモンが過剰にメモリを消費することがありました。
- ローテーとされたログファイルのバックアップが蓄積され、過剰にストレージを消費することがありました。

6
translations/ja-JP/data/reusables/actions/actions-use-sha-pinning-comment.md
View File

@@ -1,3 +1,3 @@
# GitHub recommends pinning actions to a commit SHA.
# To get a newer version, you will need to update the SHA.
# You can also reference a tag or branch, but the action may change without warning.
# GitHubでは、コミットSHAにアクションを固定することをおすすめします。
# 新しいバージョンを入手するには、SHAをアップデートする必要があります。
# タグやブランチを参照することもできますが、アクションは警告なしに変更されることがあります。

2
translations/ja-JP/data/reusables/actions/contacting-support.md
View File

@@ -1,4 +1,4 @@
If you need help with anything related to workflow configuration, such as syntax, {% data variables.product.prodname_dotcom %}-hosted runners, or building actions, look for an existing topic or start a new one in the [{% data variables.product.prodname_github_community %}'s {% data variables.product.prodname_actions %} and {% data variables.product.prodname_registry %} category](https://github.com/orgs/github-community/discussions/categories/actions-and-packages).
たとえば構文、{% data variables.product.prodname_dotcom %}ホストランナー、アクションの構築など、ワークフローの設定に関して何か支援が必要な場合は、[{% data variables.product.prodname_github_community %}の{% data variables.product.prodname_actions %}や{% data variables.product.prodname_registry %}カテゴリ](https://github.com/orgs/github-community/discussions/categories/actions-and-packages)で既存のトピックを探してみるか、新しいトピックを開始してください。
{% data variables.product.prodname_actions %}についてのフィードバックもしくは機能リクエストがあるなら、それらを{% data variables.contact.contact_feedback_actions %}で共有してください。

2
translations/ja-JP/data/reusables/actions/jobs/multi-dimension-matrix.md
View File

@@ -12,7 +12,7 @@ jobs:
example_matrix:
strategy:
matrix:
os: [ubuntu-18.04, ubuntu-20.04]
os: [ubuntu-22.04, ubuntu-20.04]
version: [10, 12, 14]
runs-on: {% raw %}${{ matrix.os }}{% endraw %}
steps:

2
translations/ja-JP/data/reusables/actions/jobs/section-choosing-the-runner-for-a-job.md
View File

@@ -6,7 +6,7 @@
### {% data variables.product.prodname_dotcom %}ホストランナーの選択
If you use a {% data variables.product.prodname_dotcom %}-hosted runner, each job runs in a fresh instance of a runner image specified by `runs-on`.
{% data variables.product.prodname_dotcom %}ホストランナーを使う場合、それぞれのジョブは`runs-on`で指定されたランナーイメージの新しいインスタンスで実行されます。
利用可能な{% data variables.product.prodname_dotcom %}ホストランナーの種類は以下のとおりです。

2
translations/ja-JP/data/reusables/actions/macos-runner-preview.md
View File

@@ -1 +1 @@
The <code>macos-latest</code> YAML workflow label currently uses the macOS 10.15 runner image.
<code>macos-latest</code> YAMLワークフローラベルは、現在macOS 10.15のランナーイメージを使用します。

2
translations/ja-JP/data/reusables/actions/pure-javascript.md
View File

@@ -1 +1 @@
JavaScriptのアクションがGitHubがホストするすべてのランナー（Ubuntu、Windows、macOS）と互換性があることを保証するためには、作成するパッケージ化されたJacScriptのコードは純粋なJavaScriptであり、他のバイナリに依存していてはなりません。 JavaScript actions run directly on the runner and use binaries that already exist in the runner image.
JavaScriptのアクションがGitHubがホストするすべてのランナー（Ubuntu、Windows、macOS）と互換性があることを保証するためには、作成するパッケージ化されたJacScriptのコードは純粋なJavaScriptであり、他のバイナリに依存していてはなりません。 JavaScriptアクションは直接ランナー上で実行され、ランナーイメージ上にすでに存在するバイナリを使用します。

7
translations/ja-JP/data/reusables/actions/self-hosted-runner-auto-removal.md
View File

@@ -1 +1,6 @@
A self-hosted runner is automatically removed from {% data variables.product.product_name %} if it has not connected to {% data variables.product.prodname_actions %} for more than 30 days.
{%- ifversion fpt or ghec or ghes > 3.6 %}
A self-hosted runner is automatically removed from {% data variables.product.product_name %} if it has not connected to {% data variables.product.prodname_actions %} for more than 14 days.
An ephemeral self-hosted runner is automatically removed from {% data variables.product.product_name %} if it has not connected to {% data variables.product.prodname_actions %} for more than 1 day.
{%- elsif ghae or ghes < 3.7 %}
A self-hosted runner is automatically removed from {% data variables.product.product_name %} if it has not connected to {% data variables.product.prodname_actions %} for more than 30 days.
{%- endif %}

8
translations/ja-JP/data/reusables/actions/supported-github-runners.md
View File

@@ -1,7 +1,7 @@
<table style="width:100%">
<thead>
<tr>
<th style="width:35%"><b>Runner image</b></th>
<th style="width:35%"><b>ランナーイメージ</b></th>
<th style="width:25%"><b>YAMLのワークフローラベル</b></th>
<th style="width:40%"><b>注釈</b></th>
</tr>
@@ -36,7 +36,6 @@ Ubuntu 22.04
<code>ubuntu-22.04</code>
</td>
<td>
Ubuntu 22.04は現在パブリックベータです。
</td>
</tr>
<tr>
@@ -49,12 +48,13 @@ Ubuntu 20.04
</tr>
<tr>
<td>
Ubuntu 18.04
Ubuntu 18.04 <sup>[非推奨]</sup>
</td>
<td>
<code>ubuntu-18.04</code>
</td>
<td>
<code>ubuntu-20.04</code>もしくは<code>ubuntu-22.04</code>に移行。 詳しい情報については<A href="https://github.blog/changelog/2022-08-09-github-actions-the-ubuntu-18-04-actions-runner-image-is-being-deprecated-and-will-be-removed-by-12-1-22/">GitHubブログのポスト</A>を参照してください。
</td>
</tr>
<tr>
@@ -92,7 +92,7 @@ macOS Catalina 10.15 <sup>[deprecated]</sup>
{% note %}
**Note:** The `-latest` runner images are the latest stable images that {% data variables.product.prodname_dotcom %} provides, and might not be the most recent version of the operating system available from the operating system vendor.
**ノート:** `-latest`ランナーイメージは、{% data variables.product.prodname_dotcom %}が提供する最新の安定版イメージであり、オペレーティングシステムのベンダーが提供する最新バージョンのオペレーティングシステムではないことがあります。
{% endnote %}

2
translations/ja-JP/data/reusables/advanced-security/secret-scanning-dry-run-results.md
View File

@@ -1,3 +1,3 @@
1. dry runが終了すると、結果のサンプル（最大1000）が表示されます。 結果をレビューし、誤検知の結果を確認してください。 ![dry runの結果を表示しているスクリーンショット](/assets/images/help/repository/secret-scanning-publish-pattern.png)
1. 結果に問題があれば修正するために新しいカスタムパターンを編集し、その変更をテストするために**Save and dry run（保存してdry run）**をクリックしてください。
{% indented_data_reference reusables.secret-scanning.beta-dry-runs spaces=3 %}

7
translations/ja-JP/data/reusables/advanced-security/secret-scanning-dry-run-select-enterprise-repos.md Normal file
View File

@@ -0,0 +1,7 @@
{%- ifversion custom-pattern-dry-run-ga %}
1. dry runを実行したいリポジトリを最大10個まで検索して選択してください。 ![dry runのために選択したリポジトリを表示しているスクリーンショット](/assets/images/help/repository/secret-scanning-dry-run-custom-pattern-select-repo-only.png)
1. 新しいカスタムパターンをテストする準備ができたら**Run（実行）**をクリックしてください。
{%- else %}
1. dry runを実行したいリポジトリを最大10個まで検索して選択してください。 ![dry runのために選択したリポジトリを表示しているスクリーンショット](/assets/images/help/repository/secret-scanning-dry-run-custom-pattern-select-repo.png)
1. カスタムパターンをテストする準備ができたら、**Dry run**をクリックしてください。
{%- endif %}

7
translations/ja-JP/data/reusables/advanced-security/secret-scanning-dry-run-select-repos.md
View File

@@ -1,2 +1,9 @@
{%- ifversion custom-pattern-dry-run-ga %}
1. dry runを実行したいリポジトリを選択してください。
* Organization全体でdry runを実行したい場合は、**All repositories in the organization（Organizationのすべてのリポジトリ）**を選択してください。 ![dry runのために選択したリポジトリを表示しているスクリーンショット](/assets/images/help/repository/secret-scanning-dry-run-custom-pattern-all-repos.png)
* dry runを実行したいリポジトリを指定するには、**Selected repositories（選択したリポジトリ）**を選択し、続いて最大で10個のリポジトリを検索して選択してください。 ![dry runのために選択したリポジトリを表示しているスクリーンショット](/assets/images/help/repository/secret-scanning-dry-run-custom-pattern-select-repos-option.png)
1. 新しいカスタムパターンをテストする準備ができたら**Run（実行）**をクリックしてください。
{%- else %}
1. dry runを実行したいリポジトリを最大10個まで検索して選択してください。 ![dry runのために選択したリポジトリを表示しているスクリーンショット](/assets/images/help/repository/secret-scanning-dry-run-custom-pattern-select-repo.png)
1. カスタムパターンをテストする準備ができたら、**Dry run**をクリックしてください。
{%- endif %}

4
translations/ja-JP/data/reusables/audit_log/audit-data-retention-tab.md
View File

@@ -1,3 +1,3 @@
1. Under "Audit log", click **Audit Data Retention**.
1. "Audit log"の下で、**Audit Data Retention（監査データの保持）**をクリックしてください。
![Screenshot of the "Audit Data Retention" tab](/assets/images/help/enterprises/audit-data-retention-tab.png)
!["Audit Data Retention"タブのスクリーンショット](/assets/images/help/enterprises/audit-data-retention-tab.png)

2
translations/ja-JP/data/reusables/audit_log/git-events-not-in-search-results.md
View File

@@ -1,7 +1,7 @@
{% ifversion git-events-audit-log %}
{% note %}
**Note:** Git events are not included in search results.
**ノート:** Gitイベントは検索結果に含まれません。
{% endnote %}
{% endif %}

2
translations/ja-JP/data/reusables/audit_log/retention-periods.md
View File

@@ -1,3 +1,3 @@
Audit logにはEnterpriseに影響するアクティビティによってトリガーされたイベントがリストされ{% ifversion not ghec %}ます。 Audit logs for {% data variables.product.product_name %} are retained indefinitely{% ifversion audit-data-retention-tab %}, unless an enterprise owner configured a different retention period. For more information, see "[Configuring the audit log for your enterprise](/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/configuring-the-audit-log-for-your-enterprise)."{% else %}.{% endif %}{% else %} within the current month and up to the previous six months. Audit logは、7日分のGitイベントを保持します。{% endif %}
Audit logにはEnterpriseに影響するアクティビティによってトリガーされたイベントがリストされ{% ifversion not ghec %}ます。 {% data variables.product.product_name %}のAudit logは{% ifversion audit-data-retention-tab %}Enterpriseのオーナーが異なる保持期間を設定しないかぎり 無期限に保持されます。詳しい情報については「[EntepriseでのAudit logの設定](/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/configuring-the-audit-log-for-your-enterprise)」を参照してください。{% else %}無期限に保持されます。{% endif %}{% else %}、その期間は当月と最大過去6ヶ月です。 Audit logは、7日分のGitイベントを保持します。{% endif %}
{% data reusables.audit_log.only-three-months-displayed %}

4
translations/ja-JP/data/reusables/codespaces/billing-for-prebuilds-default.md
View File

@@ -1,3 +1,3 @@
デフォルトでは、{% data variables.product.prodname_actions %}ワークフローは事前ビルドされたテンプレートを作成あるいは更新するたび、あるいは事前ビルドが有効化されたブランチにプッシュするたびにトリガーされます。 他のワークフローと同じように、事前ビルドされたワークフローはアカウントに含まれるActionsの分があればその一部を消費し、そうでない場合はActionsの分に対する課金を生じさせます。 Actionsの分の価格に関する詳しい情報については「[{% data variables.product.prodname_actions %}の支払いについて](/billing/managing-billing-for-github-actions/about-billing-for-github-actions)」を参照してください。
デフォルトでは、{% data variables.product.prodname_actions %}ワークフローは事前ビルドを作成あるいは更新するたび、あるいは事前ビルドが有効化されたブランチにプッシュするたびにトリガーされます。 他のワークフローと同じように、事前ビルドされたワークフローはアカウントに含まれるActionsの分があればその一部を消費し、そうでない場合はActionsの分に対する課金を生じさせます。 Actionsの分の価格に関する詳しい情報については「[{% data variables.product.prodname_actions %}の支払いについて](/billing/managing-billing-for-github-actions/about-billing-for-github-actions)」を参照してください。
{% data variables.product.prodname_actions %}の分と合わせて、指定されたリポジトリとリージョンについて、それぞれの事前ビルドされた設定と関連づけられた事前ビルドテンプレートのストレージに対しても課金されます。 事前ビルドされたテンプレートのストレージは、Codespacesのストレージと同じレートで課金されます。
{% data variables.product.prodname_actions %}の分と合わせて、指定されたリポジトリとリージョンについて、それぞれの事前ビルドの設定と関連づけられた事前ビルドのストレージに対しても課金されます。 事前ビルドのストレージは、Codespacesのストレージと同じレートで課金されます。

4
translations/ja-JP/data/reusables/codespaces/billing-for-prebuilds-reducing.md
View File

@@ -1,3 +1,3 @@
Actionsの分の消費を削減するために、開発コンテナ設定ファイルを変更したときにのみ、あるいはカスタムのスケジュールだけに従って事前ビルドされたテンプレートが更新されるように設定できます。 また、事前ビルドされた設定に対して保持されるテンプレートのバージョン数を調整することによって、ストレージの使用量を管理することもできます。 詳しい情報については「[事前ビルドの設定](/codespaces/prebuilding-your-codespaces/configuring-prebuilds#configuring-a-prebuild)」を参照してください。
Actionsの分の消費を削減するために、開発コンテナ設定ファイルを変更したときにのみ、あるいはカスタムのスケジュールだけに従って事前ビルドが更新されるように設定できます。 また、事前ビルドされた設定に対して保持されるテンプレートのバージョン数を調整することによって、ストレージの使用量を管理することもできます。 詳しい情報については「[事前ビルドの設定](/codespaces/prebuilding-your-codespaces/configuring-prebuilds#configuring-a-prebuild)」を参照してください。
Organizationのオーナーは、事前ビルドされたワークフローとストレージの使用状況を、Organizationの{% data variables.product.prodname_actions %}使用状況レポートをダウンロードして追跡できます。 You can identify workflow runs for prebuilds by filtering the CSV output to only include the workflow called "Create {% data variables.product.prodname_codespaces %} Prebuilds." 詳しい情報については「[{% data variables.product.prodname_actions %}の利用状況の表示](/billing/managing-billing-for-github-actions/viewing-your-github-actions-usage#viewing-github-actions-usage-for-your-organization)」を参照してください。
Organizationのオーナーは、事前ビルドされたワークフローとストレージの使用状況を、Organizationの{% data variables.product.prodname_actions %}使用状況レポートをダウンロードして追跡できます。 事前ビルドに対するワークフローの実行は、CSVの出力を"Create {% data variables.product.prodname_codespaces %} Prebuilds"というワークフローだけが含まれるようにフィルタリングすれば、特定できます。 詳しい情報については「[{% data variables.product.prodname_actions %}の利用状況の表示](/billing/managing-billing-for-github-actions/viewing-your-github-actions-usage#viewing-github-actions-usage-for-your-organization)」を参照してください。

4
translations/ja-JP/data/reusables/codespaces/creating-a-codespace-in-vscode.md
View File

@@ -19,9 +19,9 @@
![新しい {% data variables.product.prodname_codespaces %} を作成するためのブランチを検索する](/assets/images/help/codespaces/choose-branch-vscode.png)
5. If prompted to choose a dev container configuration file, choose a file from the list.
5. 開発コンテナの設定ファイルを選択するよう求められたら、リストからファイルを選択してください。
![Choosing a dev container configuration file for {% data variables.product.prodname_codespaces %}](/assets/images/help/codespaces/choose-dev-container-vscode.png)
![{% data variables.product.prodname_codespaces %}の開発コンテナの設定ファイルの選択](/assets/images/help/codespaces/choose-dev-container-vscode.png)
6. 使用したいマシンタイプをクリックしてください。

10
translations/ja-JP/data/reusables/codespaces/prebuilds-permission-authorization.md
View File

@@ -1,13 +1,13 @@
If the dev container configuration for the repository specifies permissions for accessing other repositories, you will be shown an authorization page. For more information on how this is specified in the `devcontainer.json` file, see "[Managing access to other repositories within your codespace](/codespaces/managing-your-codespaces/managing-repository-access-for-your-codespaces)."
リポジトリの開発コンテナの設定が他のリポジトリへのアクセスの権限を指定しているなら、認可ページが表示されます。 `devcontainer.json`でのこの指定に関する詳しい情報については「[codespace内での他のリポジトリへのアクセス管理](/codespaces/managing-your-codespaces/managing-repository-access-for-your-codespaces)」を参照してください。
Click {% octicon "chevron-down" aria-label="The expand down icon" %} to view the details of the requested permissions.
要求された権限の詳細を表示するには{% octicon "chevron-down" aria-label="The expand down icon" %}をクリックしてください。
![Screenshot of the authorization page for prebuilds](/assets/images/help/codespaces/prebuild-authorization-page.png)
![事前ビルドのための認可ページのスクリーンショット](/assets/images/help/codespaces/prebuild-authorization-page.png)
Click **Authorize and continue** to grant these permissions for creation of the prebuild. Alternatively, you can click **Continue without authorizing** but, if you do so, codespaces created from the resulting prebuild may not work properly.
**Authorize and continue（認証して続ける）**をクリックして、事前ビルドの作成のためのこれらの権限を付与します。 あるいは**Continue without authorizing（認可せずに続ける）**をクリックすることもできますが、そうした場合にはその結果の事前ビルドから生成されるCodespacesは正しく動作しないかもしれません。
{% note %}
**Note**: Users who create codespaces using this prebuild will also be asked to grant these permisssions.
**ノート**: この事前ビルドを使ってCodespacesを作成したユーザは、これらの権限の付与も求められます。
{% endnote %}

2
translations/ja-JP/data/reusables/dependabot/dependabot-secrets-button.md
View File

@@ -1,5 +1,5 @@
{% ifversion fpt or ghec or ghes > 3.4 or ghae-issue-5658 %}
1. In the "Security" section of the sidebar, select **{% octicon "key-asterisk" aria-label="The key-asterisk icon" %} Secrets**, then click **{% data variables.product.prodname_dependabot %}**.
1. サイドバーの"Security（セキュリティ）"セクションで、**{% octicon "key-asterisk" aria-label="The key-asterisk icon" %} Secrets（シークレット）**を選択し、続いて**{% data variables.product.prodname_dependabot %}**をクリックしてください。
{% else %}
1. サイドバーで**{% data variables.product.prodname_dependabot %}**をクリックしてください。 ![{% data variables.product.prodname_dependabot %}シークレットサイドバーオプション](/assets/images/enterprise/3.3/dependabot/dependabot-secrets.png)
{% endif %}

2
translations/ja-JP/data/reusables/dependabot/dependabot-tos.md
View File

@@ -1,5 +1,5 @@
{% ifversion fpt %}
{% data variables.product.prodname_dependabot %}及びすべての関連する機能は、[{% data variables.product.prodname_dotcom %}の利用規約](/free-pro-team@latest/github/site-policy/github-terms-of-service)でカバーされています。
{% elsif ghec %}
{% data variables.product.prodname_dependabot %} and all related features are covered by your license agreement. For more information, see "[{% data variables.product.company_short %} Enterprise Customer Terms](https://github.com/enterprise-legal)."
{% data variables.product.prodname_dependabot %}とすべての関連機能は、ライセンス契約の対象となっています。 詳しい情報については「[{% data variables.product.company_short %}Enterpriseカスタマー規約](https://github.com/enterprise-legal)」を参照してください。
{% endif %}

4
translations/ja-JP/data/reusables/dependabot/enabling-disabling-dependency-graph-private-repo.md
View File

@@ -1,8 +1,8 @@
リポジトリ管理者は、プライベートリポジトリに対して依存関係グラフを有効または無効にすることができます。
ユーザアカウントまたは Organization が所有するすべてのリポジトリの依存関係グラフを有効または無効にすることもできます。 For more information, see "[Configuring the dependency graph](/code-security/supply-chain-security/understanding-your-software-supply-chain/configuring-the-dependency-graph)."
ユーザアカウントまたは Organization が所有するすべてのリポジトリの依存関係グラフを有効または無効にすることもできます。 詳しい情報については「[依存関係グラフの設定](/code-security/supply-chain-security/understanding-your-software-supply-chain/configuring-the-dependency-graph)」を参照してください。
{% data reusables.repositories.navigate-to-repo %}
{% data reusables.repositories.sidebar-settings %}
{% data reusables.repositories.navigate-to-code-security-and-analysis %}
4. リポジトリ データへの読み取りアクセスを {% data variables.product.product_name %} に許可して依存関係グラフを有効にすることに関するメッセージを読んだうえで、[Dependency Graph] の隣にある [**Enable**] をクリックします。 !["Enable" button for the dependency graph](/assets/images/help/repository/dependency-graph-enable-button.png) You can disable the dependency graph at any time by clicking **Disable** next to "Dependency Graph" on the settings page for {% ifversion fpt or ghec or ghes > 3.4 or ghae-issue-5658 %}"Code security and analysis."{% else %}"Security & analysis."{% endif %}
4. リポジトリ データへの読み取りアクセスを {% data variables.product.product_name %} に許可して依存関係グラフを有効にすることに関するメッセージを読んだうえで、[Dependency Graph] の隣にある [**Enable**] をクリックします。 !["Enable" button for the dependency graph](/assets/images/help/repository/dependency-graph-enable-button.png) 依存関係グラフは、{% ifversion fpt or ghec or ghes > 3.4 or ghae-issue-5658 %}"Code security and analysis（コードのセキュリティと分析）"{% else %}""Security & analysis（セキュリティと分析）"{% endif %}の設定ページの"Dependency Graph（依存関係グラフ）"の隣の**Disable（無効化）**をクリックすれば、いつでも無効化できます。

2
translations/ja-JP/data/reusables/dependabot/enterprise-enable-dependabot.md
View File

@@ -2,7 +2,7 @@
{% note %}
**Note:** Your site administrator must set up {% data variables.product.prodname_dependabot_updates %} for {% data variables.product.product_location %} before you can use this feature. 詳しい情報については「[Enterpriseでの{% data variables.product.prodname_dependabot %}の有効化](/admin/configuration/configuring-github-connect/enabling-dependabot-for-your-enterprise)」を参照してください。
**Note:** Your site administrator must set up {% data variables.product.prodname_dependabot_updates %} for {% data variables.product.product_location %} before you can use this feature. For more information, see "[Enabling {% data variables.product.prodname_dependabot %} for your enterprise](/admin/configuration/configuring-github-connect/enabling-dependabot-for-your-enterprise)."
{% endnote %}

2
translations/ja-JP/data/reusables/dependabot/ghes-ghae-enabling-dependency-graph.md
View File

@@ -1 +1 @@
If the dependency graph is not available in your system, your enterprise owner can enable the dependency graph. 詳しい情報については「[Enterpriseでの依存関係グラフの有効化](/admin/code-security/managing-supply-chain-security-for-your-enterprise/enabling-the-dependency-graph-for-your-enterprise)」を参照してください。
システムで依存関係グラフが利用できないのであれば、Enterpriseオーナーは依存関係グラフを有効化できます。 詳しい情報については「[Enterpriseでの依存関係グラフの有効化](/admin/code-security/managing-supply-chain-security-for-your-enterprise/enabling-the-dependency-graph-for-your-enterprise)」を参照してください。

2
translations/ja-JP/data/reusables/dependabot/pull-request-introduction.md
View File

@@ -1 +1 @@
{% data variables.product.prodname_dependabot %} は、依存関係を更新するPull Requestを生成します。 リポジトリの設定によっては、{% data variables.product.prodname_dependabot %} がバージョン更新やセキュリティアップデートのPull Requestを発行する場合があります。 これらのPull Requestは、他のPull Requestと同じ方法で管理しますが、追加のコマンドもいくつか用意されています。 For information about enabling {% data variables.product.prodname_dependabot %} dependency updates, see "[Configuring {% data variables.product.prodname_dependabot_security_updates %}](/github/managing-security-vulnerabilities/configuring-dependabot-security-updates)" and "[Enabling and disabling {% data variables.product.prodname_dependabot %} version updates](/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/enabling-and-disabling-version-updates)."
{% data variables.product.prodname_dependabot %} は、依存関係を更新するPull Requestを生成します。 リポジトリの設定によっては、{% data variables.product.prodname_dependabot %} がバージョン更新やセキュリティアップデートのPull Requestを発行する場合があります。 これらのPull Requestは、他のPull Requestと同じ方法で管理しますが、追加のコマンドもいくつか用意されています。 {% data variables.product.prodname_dependabot %}依存関係アップデートの有効化に関する情報については「[{% data variables.product.prodname_dependabot_security_updates %}の設定](/github/managing-security-vulnerabilities/configuring-dependabot-security-updates)」及び「[{% data variables.product.prodname_dependabot %}バージョンアップデートの有効化と無効化](/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/enabling-and-disabling-version-updates)」を参照してください。

4
translations/ja-JP/data/reusables/dependabot/pull-request-security-vs-version-updates.md
View File

@@ -1,4 +1,4 @@
{% data variables.product.prodname_dependabot %}がPull Requestを起こす場合、それらのPull Requestは_セキュリティ_もしくは_バージョン_アップデートです。
- _{% data variables.product.prodname_dependabot_security_updates %}_ are automated pull requests that help you update dependencies with known vulnerabilities.
- _{% data variables.product.prodname_dependabot_version_updates %}_ are automated pull requests that keep your dependencies updated, even when they don’t have any vulnerabilities. バージョンアップデートの状態をチェックするには、リポジトリのInsights（インサイト）タブ、続いてDependency Graph（依存関係グラフ）、そして{% data variables.product.prodname_dependabot %}にアクセスしてください。
- _{% data variables.product.prodname_dependabot_security_updates %}_は、既知の脆弱性を持つ依存関係のアップデートを支援する自動化されたPull Requestです。
- _{% data variables.product.prodname_dependabot_version_updates %}_は、脆弱性がない場合であっても依存関係を更新された状態に保つ、自動化されたPull Requestです。 バージョンアップデートの状態をチェックするには、リポジトリのInsights（インサイト）タブ、続いてDependency Graph（依存関係グラフ）、そして{% data variables.product.prodname_dependabot %}にアクセスしてください。

Some files were not shown because too many files have changed in this diff Show More