@intlayer/docs 9.4.2 → 9.4.3

package/blog/ja/i18n_in_ci_cd_pipelines.md

@@ -0,0 +1,247 @@
+---
+createdAt: 2026-09-02
+updatedAt: 2026-09-02
+title: "粗悪な翻訳をリリースしないためのCI/CD自動化戦略"
+description: i18nを自動化する3つのフェーズ（Pre-push、Pull Request、ランタイム）。カバレッジによるビルドのゲート制御、安全な自動補完、コミットの無限ループ回避法。
+keywords:
+  - 翻訳自動化 ci
+  - i18n ci cd
+  - github actions 翻訳
+  - husky pre-push
+  - 継続的ローカライゼーション
+  - 翻訳パイプライン
+slugs:
+  - blog
+  - i18n-in-ci-cd-pipelines
+author: aymericzip
+---
+
+# 粗悪な翻訳をリリースしないためのCI/CD自動化戦略
+
+手動による翻訳作業は、頻繁なリリースサイクルに耐えられません。金曜日に誰かが文字列を追加し、次のスプリントまでエクスポートが後回しにされ、その間にさらに3言語の翻訳が遅れていきます。自動化すること自体は簡単です。しかし、機械翻訳の出力を無検証のままユーザーに公開することなく安全に自動化することこそが、真に考えるべきテーマです。
+
+## 目次
+
+<TOC/>
+
+## 自動化のために大規模な移行をする必要はありません
+
+以下で紹介するパイプライン構成はライブラリに依存せず、ツールも同様です。翻訳メッセージが i18next、next-intl、react-intl、vue-i18n、next-translate などのJSONカタログで管理されている場合、[Sync JSON プラグイン](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/plugins/sync-json.md) はそれらのファイルをその場で読み書きします。
+
+```ts fileName="intlayer.config.ts"
+import { syncJSON } from "@intlayer/sync-json-plugin";
+
+const config = {
+  plugins: [
+    syncJSON({
+      source: ({ key, locale }) => `./locales/${locale}/${key}.json`,
+      format: "i18next", // または next-intl / react-intl 向けに "icu"
+    }),
+  ],
+};
+
+export default config;
+```
+
+アプリケーション側のインポートは既存のままで構いません。後述のCIジョブが既存のカタログを補完および検証するため、レビュー担当者が見る差分は `locales/fr/checkout.json` の変更だけであり、コードベース全体の移行作業ではありません。gettextワークフロー用の [Sync PO プラグイン](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/plugins/sync-po.md) や、ランタイムAPIをそのまま維持するための [互換アダプター](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/compat/index.md) も用意されています。
+
+## ゲート（Gate）とフィル（Fill）を分離する
+
+役割の異なる2つのタスクが混同されがちです。
+
+**ゲート（Gate）** は、失敗を検知するチェックです。必須ロケールの翻訳が不足している場合にビルドを停止させます。ファイルへの書き込みは一切行いません。
+
+**フィル（Fill）** は、データの更新です。不足している翻訳を生成してコミットします。ビルドを失敗させることはありません。
+
+フィルだけを実行するとビルドは一切停止せず、レビューされていない機械翻訳が本番環境へそのまま流出してしまいます。ゲートだけを実行するとビルドが頻繁に失敗し、都度人間が手作業で対応しなければならなくなります。ほとんどのチームでは、異なるトリガーで両方を連携させることが最適解となります。つまり、Pull Request作成時にフィルを実行し、リリースブランチへのマージ時にゲートで検証します。
+
+## 自動化を組み込むフェーズの比較
+
+| フェーズ         | トリガー    | 適した用途                                 | コスト                                       |
+| :--------------- | :---------- | :----------------------------------------- | :------------------------------------------- |
+| Pre-push フック  | ローカルGit | 高速フィードバック、CI時間の消費なし       | 開発者のPCおよび個人APIキーで実行            |
+| Pull request     | CIジョブ    | マージ前のレビュー、シークレットの一元管理 | CI実行時間およびPRごとのモデル呼び出しコスト |
+| リリースブランチ | CIジョブ    | カバレッジに対する厳格なゲート             | 安価、AIモデルの呼び出しなし                 |
+| ランタイム       | CMS         | ビルド不要でのコンテンツ更新               | ホスティング環境への依存                     |
+
+## Pre-push: 最も速いフィードバックループ
+
+Huskyを使えば、コードが手元のマシンを離れる前にフィルを実行できるため、新しい文字列を追加したコミットと同じプッシュに翻訳を含めることができます。
+
+```bash fileName=".husky/pre-push"
+npx intlayer build
+npx intlayer fill --unpushed --mode complete
+```
+
+`--unpushed` は未プッシュのコンテンツに処理を限定するため、毎回のプッシュで待たされるのを防ぎます。`--mode complete` は値が存在しない項目のみを補完し、既にレビュー済みの翻訳を上書きしないため安心です。
+
+モノレポの場合はアプリケーションごとに対象を絞り込みます。
+
+```bash fileName=".husky/pre-push"
+npx intlayer build --base-dir ./app1
+npx intlayer fill --base-dir ./app1 --unpushed --mode complete
+npx intlayer build --base-dir ./app2
+npx intlayer fill --base-dir ./app2 --unpushed --mode complete
+```
+
+ただし、開発者全員にAPIキーが必要になり、プッシュする人にコストが偏るという明確なデメリットがあります。そのため、チーム規模が大きくなるとCIへ移行するのが一般的です。
+
+## Pull request: レビューが行われる場所で自動補完する
+
+同じ処理をGitHub Actionsで実行し、差分のみを対象にします。
+
+```yaml fileName=".github/workflows/intlayer-translate.yml"
+name: Intlayer Auto-Fill
+on:
+  pull_request:
+    branches: ["main"]
+
+permissions:
+  contents: write
+  pull-requests: write
+
+concurrency:
+  group: "autofill-${{ github.ref }}"
+  cancel-in-progress: true
+
+jobs:
+  autofill:
+    runs-on: ubuntu-latest
+    env:
+      AI_PROVIDER: openai
+      AI_MODEL: gpt-5-mini
+      AI_API_KEY: ${{ secrets.AI_API_KEY }}
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          persist-credentials: true
+          fetch-depth: 0
+      - uses: actions/setup-node@v4
+        with:
+          node-version: 20
+      - run: npm install
+      - run: npx intlayer build
+      - run: npx intlayer fill --git-diff --mode complete --provider $AI_PROVIDER --model $AI_MODEL --api-key $AI_API_KEY
+      - name: Commit
+        run: |
+          if [ -n "$(git status --porcelain)" ]; then
+            git config --local user.email "action@github.com"
+            git config --local user.name "GitHub Action"
+            git add .
+            git commit -m "chore: auto-fill missing translations [skip ci]"
+            git push origin HEAD:${{ github.head_ref }}
+          fi
+```
+
+重要なポイントが4つあります。
+
+- **`fetch-depth: 0`**: `--git-diff` を機能させるために必須です。Shallow cloneでは差分比較の基準が存在しないため、何も補完されなくなります。
+- **コミットメッセージの `[skip ci]`**: ワークフローの無限ループを防ぎます。これがないとコミットが新たなジョブを起動し、そのジョブがまたコミットするという悪循環に陥り、CI枠を瞬時に消費してしまいます。
+- **`concurrency` と `cancel-in-progress`**: 複数のプッシュが同時に同じファイルを書き換える競合を防ぎます。
+- **`--git-diff`**: PRで変更された部分だけをフィル対象にします。これを省くと、実行のたびに全カタログを再翻訳してしまいます。
+
+生成された翻訳はPRブランチへのコミットとして反映されるため、レビュー担当者は差分として確認できます。マージ後ではなくPR上で行う理由はここにあります。
+
+## リリースブランチ: ゲートによる安全担保
+
+ゲート処理はモデル呼び出しが不要で、高速に完了するべきです。
+
+```yaml fileName=".github/workflows/ci.yml"
+- run: npm run test:i18n
+```
+
+CLIのテキストレポートに頼るのではなく、アサーションを含むテストでカバーします。
+
+```ts fileName="i18n.test.ts"
+import { listMissingTranslations } from "intlayer/cli";
+
+test("必須ロケールに翻訳漏れがないこと", async () => {
+  const result = await listMissingTranslations();
+  if (result.missingRequiredLocales.length > 0) {
+    console.log(result.missingTranslations);
+  }
+  expect(result.missingRequiredLocales).toHaveLength(0);
+});
+```
+
+`npx intlayer content test` はレポートを出力しますが終了コード0を返すため、情報提供にとどまりビルドを停止させません。ローカルではCLIを使い、CIではテストによるアサーションを活用してください。詳細は [翻訳漏れを検出する方法](https://github.com/aymericzip/intlayer/blob/main/docs/blog/ja/detecting_missing_translations.md) を参照してください。
+
+## `requiredLocales` で実用的なゲートを維持する
+
+全18言語の完全性を一律に求めるゲートを作ると、翻訳が遅れている1言語のために全リリースが滞り、最終的にチェック自体が無効化されてしまいます。
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    requiredLocales: [Locales.ENGLISH],
+    defaultLocale: Locales.ENGLISH,
+  },
+};
+
+export default config;
+```
+
+サポートする言語を `locales` に宣言し、リリースをブロックすべき言語のみを `requiredLocales` に指定します。それ以外の言語は非同期に翻訳を進めることができ、デプロイの妨げになりません。
+
+## 翻訳をリポジトリから完全に分離する手法
+
+もう1つのアプローチは、ソースコード上では1言語のみを宣言し、残りをLive Sync対応のCMSでリモート管理することです。コンテンツの変更にアプリの再ビルドが不要になるため、テキスト編集サイクルとリリースサイクルを完全に切り離せます。
+
+```ts fileName="intlayer.config.ts"
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.SPANISH, Locales.FRENCH],
+    requiredLocales: [Locales.ENGLISH],
+    defaultLocale: Locales.ENGLISH,
+  },
+  editor: {
+    clientId: process.env.INTLAYER_CLIENT_ID,
+    clientSecret: process.env.INTLAYER_CLIENT_SECRET,
+    liveSync: true,
+  },
+};
+
+export default config;
+```
+
+これは非エンジニアが文言を管理するチームに適しています。編集の自由度が高まる一方で、Gitリポジトリの状態だけでは画面表示を完全に再現できなくなるというトレードオフがあります。詳細は [CMSドキュメント](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/intlayer_CMS.md) をご覧ください。
+
+なお、`clientSecret` はサーバーサイドの認証情報です。CIのシークレット設定やサーバーの環境変数で管理し、クライアント向けバンドルに含めないでください。
+
+## 自動化が抱える本質的な限界
+
+ここまでに紹介した方法は、あくまで「翻訳の存在（カバレッジ）」を担保するものであり、「品質」を保証するものではありません。自動補完によってキーに値が入るため監査は通過しますが、その文言はまだ誰も読んでいません。
+
+社内向けツールや変更履歴、ベータ版の言語であれば問題ないかもしれませんが、料金表、利用規約、決済エラーメッセージなど、ユーザーの意思決定に直結する重要箇所の機械翻訳をそのまま公開するのは危険です。重要な文言は人間のレビューを通し、`--mode complete` を使用して確認済みテキストが上書きされないようにしてください。
+
+また、出力の整合性を保つためにAIへコンテキストを与えましょう。
+
+```ts
+ai: {
+  applicationContext: "B2B請求管理アプリ。丁寧な表現を使用。製品名は翻訳しないこと。",
+}
+```
+
+## よくある失敗
+
+- **自動コミットに `[skip ci]` を付け忘れる。** ワークフローが無限ループに陥ります。
+- **`--git-diff` 使用時に Shallow clone を行う。** 比較基準がなく、何も処理されずに終わります。
+- **実行のたびに全カタログを再翻訳する。** コスト削減のために `--git-diff` や `--unpushed` を指定してください。
+- **CLIレポートをゲートとして使う。** 正常終了（コード0）するためビルドが止まりません。
+- **全言語を必須（required）にしてしまう。** リリースが止まり、最初の障害でチェックが撤廃されます。
+- **ゲートのないフィルジョブを組む。** エラーが発生せず、未確認のAI生成テキストが本番へ流出します。
+- **モデルのAPIキーをリポジトリに含めてしまう。** `clientSecret` 同様、必ずCIシークレットで保護してください。
+
+## さらに学ぶ
+
+- [CI/CD: Husky、GitHub Actions、CMSによる翻訳の自動生成](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/CI_CD.md)
+- [コンテンツのテストとカバレッジによるビルドのゲート制御](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/testing.md)
+- [autoFill: ロケールごとの宣言ファイルの自動生成](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/autoFill.md)
+- [設定リファレンス: `locales`、`requiredLocales`、`editor`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/configuration.md)
+- [主要フレームワーク間のベンチマークレポート](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/benchmark/index.md)
+- [i18next互換アダプター](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/compat/i18next.md)
+- [翻訳漏れを検出する方法](https://github.com/aymericzip/intlayer/blob/main/docs/blog/ja/detecting_missing_translations.md)
+- [壊れにくい翻訳テスト戦略](https://github.com/aymericzip/intlayer/blob/main/docs/blog/ja/i18n_testing_strategies.md)

package/blog/ja/i18n_meaning.md

@@ -19,8 +19,6 @@ author: aymericzip
 
 # i18nの意味：国際化とは何か、なぜ重要なのか？
 
-![i18nのイラスト](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18n.webp)
-
 ## 「i18nの意味」を理解する
 
 ソフトウェア開発、ウェブデザイン、またはデジタルマーケティングに携わっているなら、**i18n**という用語を目にしたことがあるでしょう。真の**i18nの意味**は、単純に**国際化**（internationalization）の数略語です。

package/blog/ja/i18n_testing_strategies.md

@@ -0,0 +1,179 @@
+---
+createdAt: 2026-09-02
+updatedAt: 2026-09-02
+title: "壊れやすいテストを作らずに翻訳をテストする方法"
+description: i18n対応アプリにおいてテストする価値があるものとないもの。Providerベースのレンダリングテスト、疑似多言語化、RTLと複数形のカバレッジ、そしてスナップショットの罠。
+keywords:
+  - 翻訳テスト
+  - i18n テスト
+  - testing library i18n
+  - 疑似ローカライゼーション
+  - locale provider test
+  - snapshot test i18n
+slugs:
+  - blog
+  - i18n-testing-strategies
+author: aymericzip
+---
+
+# 壊れやすいテストを作らずに翻訳をテストする方法
+
+多くのi18nテストスイートは、2つのパターンのいずれかで破綻します。1つは文言そのものをアサートしてしまうパターンで、文言を少し修正するたびに50個のテストが壊れ、チームは最終的にテストを削除してしまいます。もう1つはすべてをデフォルトロケールでのみ描画するパターンで、残りの17言語については何も検証できません。どちらも行き着く先は同じで、誰も信頼しないテストスイートになります。
+
+## 目次
+
+<TOC/>
+
+## パターンはライブラリに依存しません
+
+以下で紹介するパターンは、あらゆるi18nスタックで動作します。プロバイダーを `I18nextProvider`、`NextIntlClientProvider`、または `IntlProvider` に置き換えても、ライブラリの内部APIではなくレンダリングされた結果をアサートするため、テストコードは同一のままです。
+
+カバレッジ検証ツールも同様に移行可能です。[Sync JSONプラグイン](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/plugins/sync-json.md) を既存カタログに向けたり、[互換アダプター](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/compat/index.md) を使って現在のインポートにエイリアスを張ることで、既存のJSONに対してそのままカバレッジ検証を実行できます。
+
+## 実際に何をテストしているのかを整理する
+
+翻訳品質はコードテストで検証するものではありません。ドイツ語が自然であるかどうかを判定できるアサーションは存在せず、それを試みるとテスト内にハードコードされた文字列が散乱するだけです。
+
+機械的にテストする価値があるのは以下の項目です。
+
+| テストする価値があるもの                        | テストする価値がないもの   |
+| :---------------------------------------------- | :------------------------- |
+| 必須ロケールすべてに値が存在する                | 言い回しが洗練されているか |
+| 適切なロケールがコンポーネントに届いている      | 各ラベルの厳密なテキスト   |
+| 各カテゴリの複数形が解決される                  | 翻訳者が正しく作業したか   |
+| RTLロケールで文字方向やミラーリングが適用される | 全ロケールの全文字列       |
+| フォーマットされた日付や数値がロケールに従う    | `Intl` 内部実装の正確性    |
+
+カバレッジの担保はコンポーネントテストではなく、単一のデータ駆動型テストで行うべきです。これについては [翻訳漏れを検出する方法](https://github.com/aymericzip/intlayer/blob/main/docs/blog/ja/detecting_missing_translations.md) で詳しく解説しています。本記事ではそれ以外の部分を扱います。
+
+## Provider下で描画し、ロールでアサートする
+
+中核となるパターンは、コンポーネントをロケールプロバイダーでラップしてマウントし、テキストではなくロール（role）やテストIDでクエリすることです。
+
+```tsx fileName="CartSummary.test.tsx"
+import { render, screen } from "@testing-library/react";
+import { IntlayerProvider } from "react-intlayer/client";
+import { CartSummary } from "./CartSummary";
+
+test("renders the summary heading in French", () => {
+  render(
+    <IntlayerProvider locale="fr-FR">
+      <CartSummary />
+    </IntlayerProvider>
+  );
+
+  expect(screen.getByRole("heading")).toBeInTheDocument();
+});
+```
+
+`getByRole("heading")` によるクエリは文言の変更に耐えられますが、`getByText("Récapitulatif")` は文言変更で壊れます。文字列自体がテスト対象である稀なケースを除き、リテラル文字列によるクエリは避けましょう。
+
+`aria-label` のような属性にはレンダリングノードではなく未加工の文字列が必要です。Reactの場合、`useIntlayer` のエントリは `.value` フィールドを提供しています。
+
+## ロケールをまたいでテストをパラメータ化する
+
+言語ごとにテストを個別に書くよりも、1つのテストロジックをすべてのロケールに対して回すほうが価値があります。
+
+```tsx fileName="direction.test.tsx"
+import { getHTMLTextDir } from "intlayer";
+import { render } from "@testing-library/react";
+import { IntlayerProvider } from "react-intlayer/client";
+
+describe.each(["en", "fr", "ja", "ar"])("locale %s", (locale) => {
+  it("キー名へフォールバックせずに描画される", () => {
+    const { container } = render(
+      <IntlayerProvider locale={locale}>
+        <CartSummary />
+      </IntlayerProvider>
+    );
+
+    // キー名が表示されている場合はルックアップに失敗している
+    expect(container.textContent).not.toMatch(/^[a-z]+(\.[a-z]+)+$/);
+  });
+
+  it("正しいテキスト方向が設定されている", () => {
+    expect(getHTMLTextDir(locale)).toBe(locale === "ar" ? "rtl" : "ltr");
+  });
+});
+```
+
+1つ目のアサーションは手軽で効果的です。キーの取得に失敗してライブラリがキー名をそのまま描画すると、DOM内に `cart.summary.title` のような文字列が現れます。これにより、個別の文字列を検証することなく多くのバグを検知できます。
+
+## 疑似ローカライゼーションでカタログの盲点を突く
+
+すべての文字列を変換するテスト用ロケールを追加します（例: `Checkout` を `[!!! Çĥéçķöũţ !!!]` に変換）。そしてそのロケールでページを描画します。
+
+英語のまま残っている部分はソースコードに直書きされています。ツール側から見ればその文字列は存在しないため、カタログベースの監査では検出できません。また、前後のブラケットはテキストを約30%長くするため、ドイツ語を導入する前にレイアウト崩れを発見できる利点もあります。
+
+これは視覚的な破綻を見つける作業なので、ユニットテストではなくビジュアルリグレッションテストやE2Eテストとして実施するのが適しています。
+
+## 複数形テストは言語ごとではなくカテゴリごとに実施する
+
+複数形のバグは見落とされがちです。英語には2つの形式しかなく、多くの開発者はそれらしか検証しないためです。しかしポーランド語には4つ、アラビア語には6つの形式が存在します。
+
+```ts fileName="plural.test.ts"
+// アラビア語は zero, one, two, few, many, other を網羅します。
+describe.each([0, 1, 2, 3, 11, 100])("count %i", (count) => {
+  it("アラビア語で空文字にならない文字列を生成する", () => {
+    expect(formatItems(count, "ar")).not.toBe("");
+  });
+});
+```
+
+すべての言語で単に1と2をテストするのではなく、最も複雑な言語のCLDRカテゴリを網羅する数値を選びます。`Intl.PluralRules` を使えば数値がどのカテゴリに分類されるかが分かるため、推測に頼らずサンプルを決定できます。詳細は [ICUメッセージフォーマットの記事](https://github.com/aymericzip/intlayer/blob/main/docs/blog/ja/icu_message_format.md) を参照してください。
+
+## スナップショットテストの罠
+
+スナップショットとi18nの相性は最悪です。ローカライズされたコンポーネントのスナップショットにはすべての文字列が含まれます。そのため、翻訳者がポルトガル語のタイポを修正しただけでテストが失敗し、レビュー担当者には判断できないdiffが生まれます。何度か繰り返すうちに、開発者はdiffを読まずに `-u` を実行するようになり、スナップショットは形骸化します。
+
+スナップショットを利用する場合は単一のロケールでのみ取得し、内容ではなく構造チェックとして扱いましょう。ロケール固有の検証はすべて明示的なアサーションで行うべきです。
+
+## 表示だけでなくロケール解決ロジックをテストする
+
+本番環境で最も頻発するi18nバグは、文字列の欠落ではありません。間違ったロケールが選択されることです。URLが `/fr/` であるにもかかわらず、クライアントが `navigator.language` を読み取って不整合が起きるケースです。
+
+コンポーネントから切り離し、解決順序を純粋関数としてテストします。
+
+```ts fileName="locale-resolution.test.ts"
+it("保存された設定よりもURLを優先する", () => {
+  expect(resolveLocale({ url: "/fr/about", stored: "de", header: "ja" })).toBe(
+    "fr"
+  );
+});
+
+it("URLにプレフィックスがない場合はヘッダーにフォールバックする", () => {
+  expect(resolveLocale({ url: "/about", stored: null, header: "ja" })).toBe(
+    "ja"
+  );
+});
+```
+
+これは多くのプロジェクトで見過ごされている最も価値の高いi18nテストであり、DOMも不要です。
+
+## テストの配置基準
+
+- **Unit**: ロケールネゴシエーション、フォーマッター、複数形カテゴリ。DOM不要で高速。
+- **Component**: ロケールごとにProvider経由で描画し、ロールと未解決キーの有無を検証。
+- **Coverage**: 必須ロケールに未翻訳がないことを確認するデータ駆動テスト。
+- **Visual / E2E**: 疑似ローカライゼーションとRTLページの描画テスト（表示崩れを検出）。
+
+最初の3つはコミットごとにCIで実行します。最後の項目は夜間ビルドで定期実行するのが効率的です。
+
+## よくある失敗
+
+- **すべての箇所でリテラルテキストをアサートする。** 数ヶ月以内にテストスイートが破棄される原因になります。
+- **ローカライズされたコンポーネントをスナップショット化する。** 翻訳更新でビルドが止まり、レビューが形骸化します。
+- **デフォルトロケールしかテストしない。** 欠落するはずのない言語だけを検証しても意味がありません。
+- **複数形を1と2だけでテストする。** 英語に存在しないカテゴリを見落とします。
+- **i18nライブラリをモックで消してしまう。** 単にモックが文字列を返すことしかテストできません。
+- **ロケール解決ロジックをテストしない。** 本番環境で最も起きやすく、最も簡単に防げる問題です。
+
+## さらに学ぶ
+
+- [コンテンツのテスト: CLI監査、プログラムAPI、UIアサーション](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/testing.md)
+- [ESLintプラグイン: ハードコードされた文字列と未使用コンテンツの検出](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/eslint.md)
+- [フォーマッターとロケールユーティリティ（`getHTMLTextDir` を含む）](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/formatters.md)
+- [主要フレームワーク間のベンチマークレポート](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/benchmark/index.md)
+- [react-i18next互換アダプター](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/compat/react-i18next.md)
+- [翻訳漏れを検出する方法](https://github.com/aymericzip/intlayer/blob/main/docs/blog/ja/detecting_missing_translations.md)
+- [ICUメッセージフォーマット: 複数形、select、スケルトン](https://github.com/aymericzip/intlayer/blob/main/docs/blog/ja/icu_message_format.md)

package/blog/ja/intlayer_with_i18next.md

@@ -74,15 +74,15 @@ npx intlayer init --interactive
 ```
 
 ```bash packageManager="pnpm"
-pnpm dlx intlayer@canary init --interactive
+pnpm dlx intlayer init --interactive
 ```
 
 ```bash packageManager="yarn"
-yarn dlx intlayer@canary init --interactive
+yarn dlx intlayer init --interactive
 ```
 
 ```bash packageManager="bun"
-bunx intlayer@canary init --interactive
+bunx intlayer init --interactive
 ```
 
 > `--interactive` フラグはオプションです。AI エージェントの場合は `intlayer-cli init` を使用してください。

package/blog/ja/intlayer_with_next-i18next.md

@@ -67,15 +67,15 @@ npx intlayer init --interactive
 ```
 
 ```bash packageManager="pnpm"
-pnpm dlx intlayer@canary init --interactive
+pnpm dlx intlayer init --interactive
 ```
 
 ```bash packageManager="yarn"
-yarn dlx intlayer@canary init --interactive
+yarn dlx intlayer init --interactive
 ```
 
 ```bash packageManager="bun"
-bunx intlayer@canary init --interactive
+bunx intlayer init --interactive
 ```
 
 > `--interactive` フラグはオプションです。AI エージェントの場合は `intlayer-cli init` を使用してください。

package/blog/ja/intlayer_with_next-intl.md

@@ -68,15 +68,15 @@ npx intlayer init --interactive
 ```
 
 ```bash packageManager="pnpm"
-pnpm dlx intlayer@canary init --interactive
+pnpm dlx intlayer init --interactive
 ```
 
 ```bash packageManager="yarn"
-yarn dlx intlayer@canary init --interactive
+yarn dlx intlayer init --interactive
 ```
 
 ```bash packageManager="bun"
-bunx intlayer@canary init --interactive
+bunx intlayer init --interactive
 ```
 
 > `--interactive` フラグはオプションです。AI エージェントの場合は `intlayer-cli init` を使用してください。

package/blog/ja/intlayer_with_react-i18next.md

@@ -68,15 +68,15 @@ npx intlayer init --interactive
 ```
 
 ```bash packageManager="pnpm"
-pnpm dlx intlayer@canary init --interactive
+pnpm dlx intlayer init --interactive
 ```
 
 ```bash packageManager="yarn"
-yarn dlx intlayer@canary init --interactive
+yarn dlx intlayer init --interactive
 ```
 
 ```bash packageManager="bun"
-bunx intlayer@canary init --interactive
+bunx intlayer init --interactive
 ```
 
 > `--interactive` フラグはオプションです。AI エージェントの場合は `intlayer-cli init` を使用してください。

package/blog/ja/intlayer_with_react-intl.md

@@ -66,15 +66,15 @@ npx intlayer init --interactive
 ```
 
 ```bash packageManager="pnpm"
-pnpm dlx intlayer@canary init --interactive
+pnpm dlx intlayer init --interactive
 ```
 
 ```bash packageManager="yarn"
-yarn dlx intlayer@canary init --interactive
+yarn dlx intlayer init --interactive
 ```
 
 ```bash packageManager="bun"
-bunx intlayer@canary init --interactive
+bunx intlayer init --interactive
 ```
 
 > `--interactive` フラグはオプションです。AI エージェントの場合は `intlayer-cli init` を使用してください。

package/blog/ja/intlayer_with_vue-i18n.md

@@ -68,15 +68,15 @@ npx intlayer init --interactive
 ```
 
 ```bash packageManager="pnpm"
-pnpm dlx intlayer@canary init --interactive
+pnpm dlx intlayer init --interactive
 ```
 
 ```bash packageManager="yarn"
-yarn dlx intlayer@canary init --interactive
+yarn dlx intlayer init --interactive
 ```
 
 ```bash packageManager="bun"
-bunx intlayer@canary init --interactive
+bunx intlayer init --interactive
 ```
 
 > `--interactive` フラグはオプションです。AI エージェントの場合は `intlayer-cli init` を使用してください。