---
title: サイトのローカリゼーション
description: 非英語ローカリゼーションのサイトページの作成と管理
linkTitle: ローカリゼーション
weight: 25
default_lang_commit: 92dd44d5998fe30453368880929dc86dd9ba84da
drifted_from_default: true
cSpell:ignore: Dowair shortcodes
---

OTel のウェブサイトは、ページのローカリゼーションをサポートするために、Hugo の [multilingual framework][] をサポートしています。
デフォルトの言語は英語であり、米国英語がデフォルト（暗黙の）ローカリゼーションとして設定されています。
対応する言語の数は増えており、トップナビゲーションの言語ドロップダウンメニューから確認できます。

## 翻訳のガイド {#translation-guidance}

ウェブサイトのページを英語から翻訳する場合は、この節のガイダンスにしたがうことをおすすめします。

### 要約

#### ✅ すべきこと {#do}

<div class="border-start border-success bg-success-subtle">

- **翻訳**
  - 以下を含むページの内容
    - Mermaid [diagram](#images)のテキストフィールド
    - コードスニペット内のコメント（オプション）
  - [フロントマター][front matter] 内の `title`、 `linkTitle`、 `description` のフィールド値
  - 特別な指示がない場合、ページ内の **すべての** コンテンツとフロントマターの内容
- 原文の _内容_、 _意味_、 _スタイル_ を **変更しないこと**
- [小さなプルリクエスト](#small-prs) で **段階的に作業を提出すること**
- もしなにか疑問等があれば、以下の方法で [メンテナー][maintainers] に **質問すること**
  - [Slack][] の `#otel-docs-localization` か `#otel-comms` の各チャンネル
  - [Discussion][] やイシュー、あるいは PR コメント

[Discussion]: https://github.com/open-telemetry/opentelemetry.io/discussions?discussions_q=is%3Aopen+label%3Ai18n

</div>

#### ❌ すべきでないこと {#do-not}

<div class="border-start border-warning bg-warning-subtle">

- **翻訳**
  - `TIP`、`WARNING` などの [アラートタイプ](../style-guide/#alerts)。
    これは [`MARKDOWN` linter][] ルールによって強制されます。
  - コードブロックとインラインコード（この `inline code example` のようなもの）を含むコード
  - このレポジトリ内のリソースの **ファイルやディレクトリ** の名前
  - [すべきこと](#do) で指示されていない [フロントマター][front matter] のフィールド。特に、`aliases` は翻訳しないこと。よくわからない場合はメンテナーに質問すること。
  - [リンク](#links)。これには [見出し ID](#headings) [^*] が含まれます
  - `notranslate`（通常は CSS クラスとして）でマークされた Markdown の要素、特に[見出し](#headings)に対して
- [アセット内のテキストをローカライズする](#images) 場合以外で **画像やその他のアセットのコピー** をすること。
- 新規に追加したり変更すること
  - 原文で意図した意味と異なる **内容**
  - 表示の **スタイル**。たとえば _フォーマット_、_レイアウト_、_デザイン_ スタイル（タイポグラフィ、文字の大文字小文字、空白など）。

[^*]: ありえる例外に関しては [リンク](#links) を参照のこと。

[`MARKDOWN` linter]: ../pr-checks/#markdown-linter

</div>

#### AI ツールの使用 {#ai-tools}

翻訳を支援するために生成 AI ツール（ChatGPT、Gemini など）を使用する場合は、OpenTelemetry [Generative AI Contribution Policy][genai-policy] と Linux Foundation [Generative AI Policy][lf-ai-policy] にしたがう必要があります。
特に、次の点に注意してください。

- [プルリクエストテンプレート][pull request template]の該当するチェックボックスをオンにして、AI を使用したことを**開示する**。
- すべての AI 生成翻訳の正確性を**レビューして検証する**。
  提出するコンテンツにはあなたが責任を負います。
- 自分でレビューおよび検証できない AI 生成翻訳（たとえば、自分が十分に習熟していない言語での提出）は**提出しない**。
  これは大きなレビューボトルネックを生み出すため、メンテナーの負担を抑えるために PR がクローズされる可能性があります。

[genai-policy]: https://github.com/open-telemetry/community/blob/main/policies/genai.md
[lf-ai-policy]: https://www.linuxfoundation.org/legal/generative-ai
[pull request template]: https://github.com/open-telemetry/opentelemetry.io/blob/main/.github/PULL_REQUEST_TEMPLATE.md

### 見出しID {#headings}

見出しを翻訳する際に、見出しアンカーのターゲットをローカリゼーション全体で統一するために、以下に従ってください。

- 見出しに明示的な ID がある場合は、それを保持する。[見出し ID の記法][Heading ID syntax] は `{ #some-id }` のように、見出しテキストの後に記述されます。
- そうでない場合は、元の英語の見出しに対して自動生成された ID に対応する明示的な ID を宣言する。

[Heading ID syntax]: https://github.com/yuin/goldmark/blob/master/README.md#headings

### リンク {#links}

リンク参照を **翻訳しないで** ください。
これは外部リンク、ウェブサイトのページへのパス、[画像やその他のアセット](#images)のようなセクションローカルのリソースにも当てはまります。

唯一の例外は、外部ページ（<https://en.wikipedia.org>など）へのリンクで、あなたのロケール固有のバージョンがある場合です。
多くの場合、これはURLの`en`をあなたのロケールの言語コードに置き換えることを意味します。

> [!NOTE]
>
> OTel ウェブサイトのリポジトリには、Hugo がドキュメントページを参照する絶対リンクパスを変換するために使用するカスタムの render-link フックがあります。
> **`/docs/some-page` 形式のリンク** は、リンクをレンダリングするときに、パスの先頭にページの言語コードを付けることで、**ロケール固有になります**。
> たとえば、先ほどのサンプルのパスは、日本語のページからレンダリングされた場合には `/ja/docs/some-page` となります。

### リンク定義ラベル {#link-labels}

ロケールの著者は、Markdownの[リンク定義][link definitions]の[ラベル][labels]を翻訳するかしないかを選択できます。
英語のラベルを保持することを選択した場合は、このセクションのガイダンスに従ってください。

たとえば、次の Markdown を考えてみます。

```markdown
[Hello], world! Welcome to the [OTel website][].

[hello]: https://code.org/helloworld
[OTel website]: https://opentelemetry.io
```

これをフランス語に翻訳すると次のようになります。

```markdown
[Bonjour][hello], le monde! Bienvenue sur le [site OTel][OTel website].

[hello]: https://code.org/helloworld
[OTel website]: https://opentelemetry.io
```

[labels]: https://spec.commonmark.org/0.31.2/#link-label
[link definitions]: https://spec.commonmark.org/0.31.2/#link-reference-definitions

### 画像とその他のアセット {#images}

- ファイル自体のテキストをローカライズする場合を除き、画像、動画、その他のコンテンツ以外のアセットファイルのコピーを **作成しない** でください。
  - Hugo は、サイトのローカリゼーション間で共有される画像ファイルをレンダリングする方法についてスマートです。
    つまり、Hugo は _単一の_ 画像ファイルを出力し、それをロケール間で共有します。
    詳細は [Page bundles][] を参照してください。
  - これは [`LOCALIZATION` guidelines][l10n-check] チェックによって強制されます。

- [Mermaid][] ダイアグラム内のテキストは **翻訳して** ください。

[l10n-check]: ../pr-checks/#localization
[Mermaid]: https://mermaid.js.org
[Page bundles]: https://gohugo.io/content-management/multilingual/#page-bundles

### インクルードファイル {#includes}

`_includes` ディレクトリの下にあるページフラグメントは、他のページコンテンツと同じように **翻訳して** ください。

### ショートコード {#shortcodes}

> [!NOTE]
>
> 2025 年 2 月現在、私たちは共有ページのコンテンツをサポートする手段として、ショートコードから[インクルードファイル](#includes)への移行を進めています。

一部の基本ショートコードには英語のテキストが含まれており、ローカリゼーションが必要になる場合があります。
特に、[layouts/_shortcodes/docs][] に含まれるものについては、その傾向が強いです。

ローカリゼーションしたショートコードを作成する必要がある場合は、`layouts/_shortcodes/xx` に配置してください。
ここで `xx` はローカリゼーション対象の言語コードを指します。
その際、元の基本ショートコードと同じ相対パスを使用してください。

[layouts/_shortcodes/docs]: https://github.com/open-telemetry/opentelemetry.io/tree/main/layouts/_shortcodes/docs

## ローカリゼーションページの乖離を追跡する {#track-changes}

ローカリゼーションページを維持する上で主な課題の 1 つは、対応する英語のページが更新されたタイミングを特定することです。
本セクションでは、どのように対処するのかを説明します。

### `default_lang_commit` フロントマターフィールド {#the-default_lang_commit-front-matter-field}

`content/zh/<some-path>/page.md` のようなローカリゼーションページが書かれた際に、この翻訳は `content/en/<some-path>/page.md` にある対応する英語版のページの特定の [`main` ブランチのコミット][main] に基づいています。
このリポジトリでは、それぞれのローカリゼーションページが対応する英語ページのコミットを以下のようにローカリゼーションページのフロントマターで識別します。

```markdown
---
title: Your localized page title
...

default_lang_commit: <デフォルト言語の最新コミットハッシュ値>
```

上述のフロントマターは `content/zh/<some-path>/page.md` です。
このコミットは、`main` における `content/en/<some-path>/page.md` の最新コミットに対応します。

### 英語ページの変更を追跡する {#tracking-changes-to-english-pages}

英語ページの更新が作成されると、以下のコマンドを実行することで、対応するローカリゼーションページの更新が必要か追跡ができます。

```console
$ npm run check:i18n
1       1       content/en/docs/platforms/kubernetes/_index.md - content/zh/docs/platforms/kubernetes/_index.md
...
```

以下のようにパスを追加することで、1 つまたはそれ以上のローカライゼーションするページに対象を絞れます。

```sh
npm run check:i18n -- content/zh
```

### 変更の詳細をみる {#viewing-change-details}

更新が必要なローカリゼーションページについて、`-d` フラグとローカリゼーションページへのパスを追加して差分を見るか、パスを省略して対応するページのすべての差分を見ることができます。
たとえば、以下のようになります。

```console
$ npm run check:i18n -- -d content/zh/docs/platforms/kubernetes
diff --git a/content/en/docs/platforms/kubernetes/_index.md b/content/en/docs/platforms/kubernetes/_index.md
index 3592df5d..c7980653 100644
--- a/content/en/docs/platforms/kubernetes/_index.md
+++ b/content/en/docs/platforms/kubernetes/_index.md
@@ -1,7 +1,7 @@
 ---
 title: OpenTelemetry with Kubernetes
 linkTitle: Kubernetes
-weight: 11
+weight: 350
 description: Using OpenTelemetry with Kubernetes
 ---
```

### `default_lang_commit` を新しいページに追加する {#adding-default_lang_commit-to-new-pages}

ローカリゼーションのページを作成する際は、`default_lang_commit` をページのフロントマターに追加し、`main` ブランチの適切なコミットハッシュを指定することを忘れないでください。

翻訳ページが`main` における `<hash>` 時点の英語ページに基づいている場合、以下のコマンドを実行すると、`default_lang_commit` をコミット `<hash>` の値で自動的にページのフロントマターに追加できます。
ページが `main` の `HEAD` に同期している場合、引数として `HEAD` を指定できます。
たとえば、以下のように実行します。

```sh
npm run check:i18n -- -n -c 1ca30b4d content/ja
npm run check:i18n -- -n -c HEAD content/zh/docs/concepts
```

ハッシュキーを欠落しているローカリゼーションしたページのファイル一覧にするには、次を実行してください。

```sh
npm run check:i18n -- -n
```

### 既存のページの `default_lang_commit` を更新する {#updating-default_lang_commit-for-existing-pages}

対応する英語のページに変更に合わせてローカリゼーションページを更新する際、`default_lang_commit` のコミットハッシュも忘れずに更新してください。

> [!TIP]
>
> ローカリゼーションページが `main` の `HEAD` にある英語版と対応するようになった場合、フロントマター内のコミットハッシュの値を消去し、前のセクションであった **add** コマンドを実行して、`default_lang_commit` フィールドの値を自動的に更新してください。

乖離したローカリゼーションページをまとめて更新した場合、`-c` フラグに続いてコミットハッシュまたは 'HEAD' を指定することで、それらのファイルのコミットハッシュを `main@HEAD` に更新できます。

```sh
npm run check:i18n -- -c <hash> <PATH-TO-YOUR-NEW-FILES>
npm run check:i18n -- -c HEAD <PATH-TO-YOUR-NEW-FILES>
```

> [!IMPORTANT]
>
> `HEAD` をハッシュ指定子として使用すると、スクリプトは**ローカル環境**における `main` の HEAD のハッシュを使用します。
> `main` を GitHub 上の HEAD に対応したい場合、必ず `main` のフェッチとプルをしてください。

### ローカリゼーションページへのパッチ適用 {#patched}

[ビルドとチェックの修正](#keep-checks-green)では、ローカリゼーションページを英語の対応ページと同期せずに編集する必要がある場合があります。
たとえば、英語のページが移動された後にリンクの変更先を変更する場合です。
修正がロケールをまたぐかどうかにかかわらず、この方法で修正されたローカリゼーションページは**パッチ済み**としてマークしてください。

- 修正に必要な編集のみを行い、ページに他の変更を加えないでください。
- ページの `default_lang_commit` 行の末尾に `# patched` YAML コメントを追加してください。

  ```yaml
  default_lang_commit: abc4567... # patched
  ```

このマーカーはこのような機械的な修正に限定されており、[意味的な変更](#semantic-changes)では使用しません。
このマーカーは、ページが同期されずに修正されたことをそのページのロケールチームに伝えます。
ハッシュ値は最後の同期ポイントを記録したままです。
マーカーは、ページのハッシュが次に[更新](#updating-default_lang_commit-for-existing-pages)された際に削除されます。

### 乖離の状況 {#drift-status}

`npm run fix:i18n:status` を実行して、乖離したローカリゼーション対象ページのフロントマターフィールド `drifted_from_default` を設定します。
このフィールドはページの上部に「outdated」バナーを表示し、リンクチェッカーがそのページをスキップするようにします。
これにより、乖離したページの古いリンクが CI を失敗させることがなくなります。
リンクチェッカーが乖離したページをどのように処理するかの詳細は、[リンクチェック](/site/build/link-checking/)を参照してください。

### スクリプトのヘルプ {#script-help}

スクリプトの詳細は、`npm run check:i18n -- -h` を実行してください。

## 新しいローカリゼーション {#new-localizations}

OTel ウェブサイトの新しいローカリゼーションを始めることに興味がありますか？
メンテナーにあなたの興味を伝えましょう。
たとえば、GitHub ディスカッションや Slack の `#otel-docs-localization` チャンネルを経由することが挙げられます。
このセクションでは、新しいローカリゼーションを開始する際の手順について説明します。

> [!NOTE]
>
> 新しいローカリゼーションを開始するために、OpenTelemetry プロジェクトの既存のコントリビューターである必要はありません。
> しかし、[OpenTelemetry GitHub organization](https://github.com/open-telemetry/) のメンバーまたはローカリゼーションの承認者グループのメンバーとして追加されるには、[メンバーシップガイドライン][membership guidelines]に概説されている確立されたメンバーおよび承認者になるための要件を満たす必要があります。
>
> 承認者ステータスを獲得する前は、ローカリゼーション PR への承認を「LGTM」（Looks Good To Me）コメントを追加することで示すことができます。
> この立ち上げ段階では、メンテナーはあなたがすでに承認者であるかのようにあなたのレビューを扱います。

[membership guidelines]: https://github.com/open-telemetry/community/blob/main/guides/contributor/membership.md

### 1. ローカリゼーションチームを結成する {#team}

ローカリゼーションの作成は、活発で支援的なコミュニティを育てることです。
OpenTelemetryウェブサイトの新しいローカリゼーションを始めるには、以下が必要です。

1. あなたの言語に精通した**ローカリゼーションメンター**。たとえば、[CNCF Glossary][]や[Kubernetes ウェブサイト][Kubernetes website]の[アクティブな承認者][active approver]など。
2. 少なくとも2名の潜在的なコントリビューター。

[active approver]: https://github.com/cncf/glossary/blob/main/CODEOWNERS
[CNCF Glossary]: https://glossary.cncf.io/
[Kubernetes website]: https://github.com/kubernetes/website

### 2. ローカリゼーションのキックオフ：イシューを作成する {#kickoff}

[ローカリゼーションチーム](#team)が配置されているか結成されている場合は、以下のタスクリストを使用してイシューを作成します。

1. 追加したい言語の公式[ISO 639-1 コード][ISO 639-1 code]を調べてください。このセクションの残りの部分では、この言語コードを`LANG_ID`と呼びます。特にサブリージョンの選択に関して、使用するタグについて疑問がある場合は、メンテナーに尋ねてください。

   [ISO 639-1 code]: https://en.wikipedia.org/wiki/ISO_639-1

2. [メンターと潜在的なコントリビューター](#team)のGitHubのハンドルネームを特定してください。

3. 冒頭コメントに以下のタスクリストを含む[新しいイシュー][new issue]を作成してください。

   ```markdown
   - [ ] Language info:
     - ISO 639-1 language code: `LANG_ID`
     - Language name: ADD_NAME_HERE
   - [ ] Locale team info:
     - [ ] Locale mentor: @GITHUB_HANDLE1, @GITHUB_HANDLE2, ...
     - [ ] Contributors: @GITHUB_HANDLE1, @GITHUB_HANDLE2, ...
   - [ ] Read through
         [Localization](https://opentelemetry.io/docs/contributing/localization/)
         and all other pages in the Contributing section
   - [ ] Localize site homepage (only) to YOUR_LANGUAGE_NAME and submit a PR.
         For details, see
         [Localize the homepage](https://opentelemetry.io/docs/contributing/localization/#homepage).
   - [ ] OTel maintainers:
     - [ ] Update Hugo config for `LANG_ID`
     - [ ] Configure cSpell and other tooling support
     - [ ] Create an issue label for `lang:LANG_ID`
     - [ ] Create org-level group for `LANG_ID` approvers
     - [ ] Update components owners for `content/LANG_ID`
   - [ ] Create an issue to track the localization of the **glossary**. Add the
         issue number here. For details, see
         [Localize the glossary](https://opentelemetry.io/docs/contributing/localization/#glossary).
   ```

### 3. ホームページをローカライズする {#homepage}

ファイル `content/LANG_ID/_index.md` に、ウェブサイトの[ホームページ][homepage]の翻訳 _のみ_ を含む[プルリクエストを送信](../pull-requests/)してください。
メンテナーはローカリゼーションプロジェクトを開始するために必要な追加の変更をPRに加えるため、メンテナーがPRを編集するために必要な権限があることを確認してください。

[homepage]: https://github.com/open-telemetry/opentelemetry.io/blob/main/content/en/_index.md

最初のPRがマージされた後、メンテナーはイシューラベル、組織レベルのグループ、およびコンポーネント所有者を設定します。

### 4. 用語集をローカライズする {#glossary}

ローカライズする2番目のページは[用語集](/docs/concepts/glossary/)です。
これは、特にオブザーバビリティとOpenTelemetryで使用される主要な用語を定義するため、ローカライズされた読者にとって**重要な**ページです。
これは、あなたの言語にそのような用語が存在しない場合は特に重要です。

ガイダンスについては、Write the Docs 2024でのAli Dowairのトーク[The art of translation: How to localize technical content][ali-dowair-2024]の[動画][ali-d-youtube]を参照してください。

[ali-dowair-2024]: https://www.writethedocs.org/conf/atlantic/2024/speakers/#speaker-ali-dowair-what-s-in-a-word-lessons-from-localizing-kubernetes-documentation-to-arabic-ali-dowair
[ali-d-youtube]: https://youtu.be/HY3LZOQqdig

### 5. 残りのサイトページを小さな増分でローカライズする {#rest}

用語が確立されたら、残りのサイトページをローカライズできます。

> [!IMPORTANT] 小さな PR を提出する <a id="small-prs"></a>
>
> ローカリゼーションチームは、**小さな増分**で作業を提出する必要があります。
> つまり、[PR][PRs] は小さく保ち、できれば 1 つまたは少数の小さなファイルに限定してください。
> 小さな PR はレビューが簡単で、通常はより早くマージされます。

### OTelメンテナーチェックリスト {#otel-maintainer-checklist}

#### Hugo {#hugo}

`LANG_ID` の Hugo config を更新します。
`LANG_ID` の適切なエントリを以下に追加します。

- `config/_default/hugo.yaml` の `languages`
- `config/_default/module-template.yaml` 経由の `module.mounts`。
  最低限、`content` 用の単一の `source`-`target` エントリを追加します。
  ロケールに十分なコンテンツがある場合にのみ、`en` フォールバックページのエントリの追加を検討してください。

#### スペルチェック {#spelling}

NPM パッケージ [@cspell/dict-LANG_ID][] として利用可能な [cSpell 辞書][cSpell dictionaries] を探します。
方言や地域に辞書がない場合は、最も近い地域のものを選んでください。

- **辞書が利用できる場合**:
  - 開発依存関係として NPM パッケージを追加します。
    例: `npm install --save-dev @cspell/dict-bn`
  - [`.cspell.yml`][] で、パッケージの `cspell-ext.json` を `import:` の下に追加し、辞書の ID（たとえば `bn`、`es-es`、`pl_pl`）を `dictionaries:` の下に追加します。
- **その言語の辞書が利用できない場合**は、その言語の `import` を追加しないでください。
  cSpell がそのロケールの Markdown を英語としてスペルチェックしようとしないように、[`.cspell.yml`][] の `ignorePaths` リストに `content/LANG_ID` を追加します。

[cSpell dictionaries]: https://github.com/streetsidesoftware/cspell-dicts
[@cspell/dict-LANG_ID]: https://www.npmjs.com/search?q=%40cspell%2Fdict
[`.cspell.yml`]: https://github.com/open-telemetry/opentelemetry.io/blob/main/.cspell.yml

#### 単語リスト {#word-list}

**スペルチェック**で追加する自然言語辞書がない場合でも、新しいロケールごとに `.cspell/LANG_ID-words.txt` を作成します（最初は空で構いません）。

- [`.cspell.yml`][] で、このファイルを登録して有効化します。
  - `dictionaryDefinitions` の下に、`name`（たとえば `LANG_ID-words`）と `path`（たとえば `.cspell/LANG_ID-words.txt`）を持つエントリを追加します。
  - `dictionaries` の下に、上記のステップと同じ `name` の値を追加します（ファイルパスではありません）。

#### その他のツールサポート {#other-tooling-support}

- Prettierサポート：`LANG_ID`がPrettierで十分にサポートされていない場合は、`.prettierignore`に無視ルールを追加します

## 承認者およびメンテナー向けガイダンス {#approver-and-maintainer-guidance}

### ロケール限定の PR で自動マージを有効にする {#auto-merge}

ロケールのメンテナーチームのメンバーは、ロケール限定の PR に対して `/auto-merge`（または `/auto-merge:enable`、無効にするには `/auto-merge:disable`）とコメントすることで [GitHub の自動マージ][GitHub auto-merge] を有効にできます。
このディレクティブは、先頭にテキストや空白がない独立した行に記述し、コメントの最初または最後の非空白行として配置する必要があります。
指定は最大 1 回までです。
たとえば、次のように記述できます。

```text
LGTM
/auto-merge
```

これにより、確立されたローカリゼーションチームがドキュメントメンテナーを待つことなく自分たちの PR をマージできるようになります。
GitHub、ブランチ保護、CODEOWNERS ルールは引き続きマージを制御しており、PR はすべての必要なレビューが完了しチェックが通った場合にのみマージされます。

自動マージコメントは、変更されたすべてのファイルがあなたがメンテナンスしているロケールに属している場合にのみ受け入れられます。
そのため、共有コンテンツや英語コンテンツの変更には使用できません。
適用条件とコマンドの詳細は、[ヘルパー README][helper README] を参照してください。

[GitHub auto-merge]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/automatically-merging-a-pull-request
[helper README]: https://github.com/open-telemetry/opentelemetry.io/tree/main/scripts/gh/locale-auto-merge

### PR は複数のロケールにまたがるべきではない {#prs-should-not-span-locales}

一般的な原則として、PR は複数のロケールにまたがるべきではありません。
つまり、変更するページは最大で 1 つのロケールに限定すべきです。
唯一の例外はこのセクションで説明します。

#### 意味的な変更 {#semantic-changes}

承認者は、ドキュメントページに**意味的な**変更を加える[PR][PRs]が複数のロケールにまたがらないようにする必要があります。
意味的な変更とは、ページコンテンツの _意味_、つまり読者が理解し行動する内容に影響を与える変更です。
コードブロック、コマンド、設定サンプルもそのコンテンツの一部です。
これらは[翻訳しません](#do-not)が、それらへの編集は同様に意味的な変更です。
私たちのドキュメントの[ローカリゼーションプロセス](.)により、ロケールの承認者は、時期を見て、英語の編集内容を確認し、その変更がそのロケールに適切かどうか、およびそのロケールにどのように組み込むのが最善かを判断します。
変更が必要な場合、ロケールの承認者は独自のロケール固有のPRを通じて変更を行います。

> [!NOTE] コンテンツに影響しないメンテナンス
>
> ロケールをまたぐルールはページの**コンテンツ**を対象としています。
> メンテナーは、サイト全体のツール、設定、フロントマター、マークアップの更新を含む、ロケールをまたがざるを得ない、コンテンツに影響しない変更を提出することがあります。
> これには自動化された[乖離状況](#track-changes)の記録管理 PR も含まれます。
> このような変更はローカリゼーションページの意味を変更しません。

#### ビルドとチェックをグリーンに保つ {#keep-checks-green}

ローカリゼーションページの**コンテンツ**を変更する PR が複数のロケールにまたがることが許されるのは、サイトのビルドとチェックをグリーンに保つために厳密に必要な場合のみです。

- **リンクの修正**：英語のページが移動または削除された後、あるいは外部リソースが移動した後に、ローカリゼーションページのリンクチェックの失敗を修復します。
  [リンクの修正とリソースの更新](#link-fixes-and-resource-updates)を参照してください。
- **ビルドの修正**：共有のショートコード、インクルードファイル、データソースの変更後などに、ローカリゼーションページのサイトビルドの破損を修復します。
  ページの[乖離状況](#track-changes)はリンクチェックからのみ保護し、Hugo のビルドからは保護しません。

いずれの場合も、修正したすべてのローカリゼーションページを[パッチ済み](#patched)としてマークしてください。

ローカリゼーションページのコンテンツへのその他の変更は、そのロケールにとっての**意味的な**変更として扱ってください。
これには、乖離したページへの対象を絞ったコンテンツの追加（新しい用語集の用語の追加など）も含まれます。

#### リンクの修正とリソースの更新 {#link-fixes-and-resource-updates}

英語のドキュメントへの変更により、非英語のロケールでリンクチェックの失敗が発生することがあります。
これはドキュメントページやそのセクションが移動または削除された場合に発生します。
移動した外部リソースへのリンクも同様に失敗する可能性があります。
移動または削除されたページのローカリゼーションされたコピー自体は変更する必要はありません。
[乖離の追跡](#track-changes)がそれらのロケールチームに対してフラグを立てます。
修正が必要になるのは、そのようなターゲットに**リンクしている**ローカリゼーションページです。
リンクターゲットの状況に応じて対処してください。

- **ページが移動された場合**：
  1. 移動された英語ページが古いパスの [alias][aliases] を宣言していることを確認してください。
     alias は以前公開されたリンクを機能させ続けますが、サイト訪問者に対してのみです。
     alias はサーバーサイドリダイレクトとして公開され、リンクチェッカーはビルドされたサイトの正規ページパスに対してリンクを解決します。
     そのため、古いパスへのリンクは修正が必要です。
  2. リンクチェックに失敗する各非英語ページのリンクを新しいパスに更新し、編集した各ページを[パッチ済み](#patched)としてマークしてください。
     （[乖離した](#track-changes)ページはリンクチェッカーによってスキップされるため、これは通常、同期済みのページに適用されます。）

- **セクションが移動された場合**：alias はページパスをリダイレクトするため、フラグメントには対応できません。
  セクションがページ内で移動した場合は、セクションへのリンクが機能し続けるよう[見出し ID](#headings) を保持してください。
  それ以外の場合は、リンクチェックに失敗する各ページのセクションへのリンクを更新し、編集した各ローカリゼーションページを[パッチ済み](#patched)としてマークしてください。

- **ページまたはセクションが削除された場合**：代替を選択するかリファレンスを削除することは、影響を受ける各ロケールにとって[意味的な変更](#semantic-changes)であるため、そのようなリンクにパッチを適用しないでください。
  削除されたターゲットにリンクしていた英語ページを修正すると、そのローカリゼーションされたコピーが乖離します。
  英語の編集がコミットされたら、`npm run fix:i18n:status -- <PATHS-TO-LOCALIZED-COPIES>` を実行して、それらのコピーの[乖離状況](#drift-status)を更新してください。
  リンクチェッカーはそれらのページをスキップし、調整は各ページのロケールチームに委ねられます。
  まれに、ローカリゼーションページにのみ存在する失敗リンクがある場合は、そのロケールチームと連携して修正してください。

- **外部リソースが移動された**が、それ以外は意味的に変更されていない場合（GitHub ファイルの移動など）：リンクチェックに失敗する各ページのリンクを更新し、編集した各ローカリゼーションページを[パッチ済み](#patched)としてマークしてください。

すべてのケースで、`npm run check:links` を再実行して、リンクの失敗が残っていないことを確認してください。

[aliases]: https://gohugo.io/content-management/urls/#aliases
[front matter]: https://gohugo.io/content-management/front-matter/
[main]: https://github.com/open-telemetry/opentelemetry.io/commits/main/
[maintainers]: https://github.com/orgs/open-telemetry/teams/docs-maintainers
[multilingual framework]: https://gohugo.io/content-management/multilingual/
[new issue]: https://github.com/open-telemetry/opentelemetry.io/issues/new
[PRs]: ../pull-requests/
[slack]: https://slack.cncf.io/
