diff --git a/docs/ja/concepts-basics/lagoon-yml.md b/docs/ja/concepts-basics/lagoon-yml.md
index 90af266433..db13b2487c 100644
--- a/docs/ja/concepts-basics/lagoon-yml.md
+++ b/docs/ja/concepts-basics/lagoon-yml.md
@@ -2,7 +2,7 @@
`.lagoon.yml` ファイルは、プロジェクトを設定するための中心となるファイルです。以下の操作を行うための設定が含まれています:
-* [サイトへのアクセスルートを定義する](#routes)
+* [サイトへのアクセスルートを定義する](lagoon-yml.md#routes)
* [プリロールアウトタスクを定義する](#pre-rollout-tasks-pre_rolloutirun)
* [ポストロールアウトタスクを定義する](#post-rollout-tasks-post_rolloutirun)
* [SSL証明書を設定する](#ssl-configuration-tls-acme)
@@ -20,7 +20,7 @@
この設定は、デプロイされたGit SHAを環境変数としてプロジェクトに設定することを有効にします。デフォルトではこれは無効です。値を `true` に設定すると、SHAが環境変数 `LAGOON_GIT_SHA` として設定されます。
-## ルート
+## ルート { #routes }
ルートはトラフィックをサービスへ転送するために使用されます 。環境内の各サービスにはルートがあり、ドメイン名は手動または自動で定義されます。トップレベルの `routes` セクションの設定は、すべての環境のすべてのルートに対して適用されます。
@@ -58,7 +58,7 @@
定義可能なタスクには複数の種類があり、それらはビルドフローの中のどのタイミングで実行されるかが異なります。
-### プリロールアウトタスク - `pre_rollout.[i].run`
+### プリロールアウトタスク - `pre_rollout.[i].run` { #pre-rollout-tasks-pre_rolloutirun}
すべてのイメージが正常にビルドされた後、かつ、以下のタイミングの前に、プロジェクトに対して実行するタスクを指定することができます。
@@ -73,7 +73,7 @@
* 最後のデプロイ以降にDockerfileに加えられた変更は、プリロールアウトタスクが実行されるときには反映されません。
* 既存のコンテナがない場合(例えば、新しい環境の初期デプロイメント時など)、プリロールアウトタスクはスキップされます。
-### ポストロールアウトタスク - `post_rollout.[i].run`
+### ポストロールアウトタスク - `post_rollout.[i].run` { #post-rollout-tasks-post_rolloutirun }
以下のタイミングの後にプロジェクトに対して実行する必要があるタスクを指定することができます。
@@ -225,7 +225,7 @@ Drupal & Drush 9: マスター環境からデータベースとファイルを
hstsEnabled: true
```
-### SSL設定 `tls-acme`
+### SSL設定 `tls-acme` { #ssl-configuration-tls-acme }
!!! Warning "警告"
`tls-acme: true`から`tls-acme: false`に切り替えると、このルートに対して以前に生成された証明書がすべて削除されます。これは、外部のCDNを使用していて証明書のピン留めを行っている場合、予期しない挙動を引き起こす可能性があります。
@@ -387,7 +387,7 @@ environments:
autogenerateRoutes: true
```
-### `environments.[name].cronjobs`
+### `environments.[name].cronjobs` { #environmentsnamecronjobs }
diff --git a/docs/ja/interacting/graphql-queries.md b/docs/ja/interacting/graphql-queries.md
index 1a418b56b7..23b9bb99c4 100644
--- a/docs/ja/interacting/graphql-queries.md
+++ b/docs/ja/interacting/graphql-queries.md
@@ -1,6 +1,6 @@
# GraphQL API
-## GraphQLクエリの実行
+## GraphQLクエリの実行 { #running-graphql-queries }
Lagoonでの直接的なAPIの相互作用は、[GraphQL](graphql-queries.md)を経由して行われます。
@@ -41,7 +41,7 @@ query allProjects{
すべてがうまくいけば、最初のGraphQLレスポンスがすぐに右のペインに表示されるはずです。
-## 最初のプロジェクトの作成
+## 最初のプロジェクトの作成 { #creating-the-first-project }
Lagoonにデプロイするための最初のプロジェクトを作成しましょう！これには、[`create-project.gql`](../interacting/create-project.gql)のGraphQLクエリテンプレートからクエリを使用します。
@@ -50,7 +50,7 @@ Lagoonにデプロイするための最初のプロジェクトを作成しま
1. `kubernetes` : LagoonがデプロイするべきKubernetes(またはOpenshift)クラスタ。Lagoonは自身のKubernetesクラスタにだけでなく、任意のKubernetesにもデプロイすることが可能です。 世界中のどこでもクラスタリングします。
2. `project` : デプロイされるLagoonプロジェクトで、ルートにコミットされた `.lagoon.yml` 設定ファイルを持つGitリポジトリです。
-## プロジェクトへのアクセス許可
+## プロジェクトへのアクセス許可 { #allowing-access-to-the-project }
Lagoonでは、各開発者は自分のSSHキーで認証します。これにより、以下へのアクセスが決まります:
@@ -147,7 +147,7 @@ mutation {
これらのクエリの一部または全部を実行した後、ユーザーはSSH経由でトークンを作成したり、コンテナにアクセスしたりする権限が付与されます。
-## プロジェクトに通知を追加する
+## プロジェクトに通知を追加する { #adding-notifications-to-the-project }
デプロイメント中に何が起こっているのかを知りたい場合、プロジェクトに通知を設定することをお勧めします。以下の情報を提供します:
@@ -208,9 +208,9 @@ mutation {
これで、デプロイメントごとに、定義したチャンネルでメッセージを受け取ることができます。
-## GraphQLクエリの例
+## GraphQLクエリの例 { #example-graphql-queries }
-### 新しいKubernetesターゲットの追加
+### 新しいKubernetesターゲットの追加 { #adding-a-new-kubernetes-target }
!!! Note "注意:"
Lagoonでは、`addKubernetes`と`addOpenshift`のどちらもKubernetesとOpenShiftのターゲットの両方に使用することができ、どちらも互換性があります。
@@ -238,7 +238,7 @@ mutation {
}
```
-### プロジェクトにグループを追加する
+### プロジェクトにグループを追加する { #adding-a-group-to-a-project }
このクエリはプロジェクトにグループを追加します。そのグループのユーザーはプロジェクトにアクセスできます。彼らはそのグループでの役割に基づいて変更を加えることができます。
@@ -261,7 +261,7 @@ mutation {
}
```
-### 新しいプロジェクトを追加する
+### 新しいプロジェクトを追加する { #adding-a-new-project }
このクエリは、新しいLagoonプロジェクトをデプロイするために追加します。これは、ルートにコミットされた`.lagoon.yml`設定ファイルを持つGitリポジトリです。
@@ -303,7 +303,7 @@ mutation {
}
```
-### プロジェクトとグループのリスト
+### プロジェクトとグループのリスト { #list-projects-and-groups }
これは、私たちのLagoon内に存在するすべてのプロジェクト、クラスター、グループの概要を見るための良いクエリです。
@@ -337,7 +337,7 @@ query {
}
```
-### 単一のプロジェクト
+### 単一のプロジェクト { #single-project }
単一のプロジェクトを詳しく見る場合、このクエリが非常に有用であることが証明されています。
@@ -372,7 +372,7 @@ query {
}
```
-### Git URLによるプロジェクトのクエリ
+### Git URLによるプロジェクトのクエリ { #querying-a-project-by-its-git-url }
プロジェクトの名前を覚えていないが、Git URLは知っている場合？もう探す必要はありません、そのためのGraphQLクエリがあります:
@@ -385,7 +385,7 @@ query {
}
```
-### オブジェクトの更新
+### オブジェクトの更新 { #updating-objects }
Lagoon GraphQL APIは、オブジェクトを表示し、オブジェクトを作成するだけでなく、[パッチオブジェクト](https://www.apollographql.com/blog/designing-graphql-mutations) を使用して既存のオブジェクトを更新する能力もあります。
@@ -434,7 +434,7 @@ mutation {
}
```
-### 環境の削除
+### 環境の削除 { #deleting-environments }
Lagoon GraphQL APIを使用して、環境を削除することもできます。 環境。コマンドを実行するためには、プロジェクト名と環境名を知っている必要があります。
@@ -454,7 +454,7 @@ mutation {
}
```
-### プロジェクトに割り当てられたグループとユーザーを確認する
+### プロジェクトに割り当てられたグループとユーザーを確認する { #querying-a-project-to-see-what-groups-and-users-are-assigned }
プロジェクトにどのグループとユーザーがアクセスできるか見たいですか？彼らの役割は何か知りたいですか？そのためのクエリがあります！下記のクエリを使用して、プロジェクトを検索し、そのプロジェクトに割り当てられたグループ、ユーザー、役割を表示できます。
@@ -491,11 +491,11 @@ query search{
}
```
-## 維持 プロジェクトメタデータ
+## 維持 プロジェクトメタデータ { #maintaining-project-metadata }
プロジェクトメタデータは、任意のキー/値の組み合わせで割り当てることができます。プロジェクトは関連付けられたメタデータによって問い合わせることができます。例えば、ソフトウェアの種類、バージョン番号、または後で問い合わせるための任意のカテゴリーによってプロジェクトを分類することができます。
-### プロジェクトのメタデータを追加/更新する
+### プロジェクトのメタデータを追加/更新する { #addupdate-metadata-on-a-project }
メタデータの更新はキー/値の組み合わせを期待しています。これは`UPSERT`として動作します。つまり、既にキーが存在する場合は値が更新され、存在しない場合は挿入されます。
@@ -512,7 +512,7 @@ mutation {
}
```
-### メタデータによるプロジェクトのクエリ
+### メタデータによるプロジェクトのクエリ { #query-for-projects-by-metadata }
クエリは`key`のみ(例:特定のキーが存在するすべてのプロジェクトを返す)または`key`と`value`の両方(キーと値の両方が一致する必要があります)によって行うことができます。
@@ -538,7 +538,7 @@ query projectsByMetadata {
}
```
-### プロジェクトのメタデータを削除する
+### プロジェクトのメタデータを削除する { #removing-metadata-on-a-project }
メタデータはキーごとに削除できます。他のメタデータキー/値のペアは残ります。
diff --git a/docs/ja/interacting/organizations.md b/docs/ja/interacting/organizations.md
index 856086f751..c0eb4e14a6 100644
--- a/docs/ja/interacting/organizations.md
+++ b/docs/ja/interacting/organizations.md
@@ -2,38 +2,38 @@
以下に、Lagoon UIでグループ、プロジェクト、ユーザー、および役割に関連する有用なタスクを実行するためのステップバイステップガイドを示します。
-## ログインして組織を探す
+## ログインして組織を探す { #log-in-and-find-organizations }
-## プロジェクトへのアクセス権を持つ人を確認する
+## プロジェクトへのアクセス権を持つ人を確認する { #view-who-has-access-to-a-project }
-## ユーザーをロール付きのグループに追加する
+## ユーザーをロール付きのグループに追加する { #add-user-to-group-with-role }
-## ユーザーをグループから削除する
+## ユーザーをグループから削除する { #remove-a-user-from-a-group }
-## ユーザーのロールを変更する
+## ユーザーのロールを変更する { #change-a-user-role }
-## プロジェクトにメール通知を追加する
+## プロジェクトにメール通知を追加する { #add-an-email-notification-to-a-project }
-## プロジェクトにグループを追加する
+## プロジェクトにグループを追加する { #add-a-group-to-a-project }
-## 組織のオーナー権限を持つユーザーを追加する
+## 組織のオーナー権限を持つユーザーを追加する { #add-a-user-with-organization-owner-privileges }
-## 新しいプロジェクトを作成し、グループを追加し、プロダクション環境を作成する
+## 新しいプロジェクトを作成し、グループを追加し、プロダクション環境を作成する { #create-a-new-project-add-a-group-and-create-a-production-environment }
diff --git a/docs/ja/interacting/rbac.md b/docs/ja/interacting/rbac.md
index 19076c3b68..2253472b85 100644
--- a/docs/ja/interacting/rbac.md
+++ b/docs/ja/interacting/rbac.md
@@ -2,21 +2,21 @@
Lagoon バージョン 1.0 では、プロジェクトへのアクセス方法が変更されました。プロジェクトへのアクセスはグループ経由で処理され、プロジェクトは 1 つまたは複数のグループに割り当てられます。ユーザーはロールを持つグループに追加されます。グループはサブグループ内にネストすることもできます。この変更により、柔軟性が大幅に向上し、Lagoon 内で実際のチームを再現できるようになります。
-## ロール
+## ロール { #roles }
ユーザーをグループに割り当てるときは、このグループ内でそのユーザーにグループ ロールを提供する必要があります。現在存在する 5 つのグループ ロールのそれぞれが、グループとグループに割り当てられたプロジェクトに対する異なる権限をユーザーに付与します。現在 Lagoon にあるプラットフォーム全体のロールとグループ ロールは次のとおりです。
-### プラットフォーム全体のロール
+### プラットフォーム全体のロール { #platform-wide-roles }
-#### プラットフォーム全体の管理者
+#### プラットフォーム全体の管理者 { #platform-wide-admin }
プラットフォーム全体の管理者は、Lagoon 全体のすべてにアクセスできます。これには、すべてのプロジェクトを削除するなどの危険な変更も含まれます。**非常に**慎重に使用してください。
-#### プラットフォーム全体の所有者
+#### プラットフォーム全体の所有者 { #platform-wide-owner }
プラットフォーム全体のオーナーは、グループオーナーの役割と同様にすべてのLagoonグループにアクセスできます。すべてにアクセスする必要があるが、各グループにユーザーを割り当てたくない場合に使用できます。
-#### 組織の所有者
+#### 組織の所有者 { #organization-owner}
組織の所有者のロールにより、組織内でプロジェクト、グループ、通知を作成および削除できます。
@@ -27,38 +27,38 @@ Lagoon バージョン 1.0 では、プロジェクトへのアクセス方法
!!! Warning "注意"
デフォルトでは、このロールは組織のオーナーがプロジェクト内で環境を作成したり、デプロイをトリガーしたりすることを許可していません。彼らは自分自身を、その権限を付与するロールを持つグループに追加することができます。プロジェクトを作成するとき、組織のオーナーはプロジェクトのデフォルトグループのオーナーとして追加されることを選択できます。
-#### 組織のビューア
+#### 組織のビューア { #organization-viewer }
組織のビューワーは、自組織内のプロジェクト、グループとユーザーのアクセス、通知を表示するアクセス権を持っています。
-### グループのロール
+### グループのロール { #group-roles }
-#### オーナー
+#### オーナー { #owner }
オーナーのロールは、グループとその関連プロジェクト内で全てを行うことができます。彼らはグループのユーザーを追加し、管理することができます。 このロールには注意が必要です、なぜならプロジェクトや本番環境を削除することができるからです。
-#### メンテナ
+#### メンテナ { #maintainer }
メンテナのロールは、プロジェクト自体や本番環境を削除することを除いて、グループとその関連プロジェクト内で何でもできます。彼らはグループのユーザーを追加し、管理することができます。
-#### 開発者
+#### 開発者 { #developer }
開発者ロールは開発環境へのSSHアクセスのみが許可されています。このロールは、本番環境へのアクセス、更新、削除を行うことはできません。本番環境をソースとして同期タスクを実行することはできますが、宛先として使用することはできません。また、グループのユーザー管理も行えません。
!!! Warning "重要"
このロールは、Gitプッシュによってデプロイメントがトリガーされるため、本番環境のデプロイメントを防ぐことはありません。Gitサーバーがこれらのユーザーが本番環境として定義されたブランチにプッシュするのを防ぐように設定する必要があります。
-#### レポーター
+#### レポーター { #reporter }
レポーターのロールは、閲覧アクセスのみを持っています。彼らはSSH経由で環境にアクセスしたり、それらを変更したりすることはできません。彼らはキャッシュクリアタスクを実行することができます。このロールは主に、ステークホルダーがLagoon UIとログにアクセスできるようにするために使用されます。
-#### ゲスト
+#### ゲスト { #guest }
ゲストのロールは、上記のレポーターのロールと同等の権限を持っています。
以下はその表です。 彼らが持つロールとアクセスをリストします:
-### Lagoon 1.0.0 RBAC 権限マトリックス
+### Lagoon 1.0.0 RBAC 権限マトリックス { #lagoon-100-rbac-permission-matrix }
=== "自分自身"