@intlayer/docs 9.0.0-canary.3 → 9.0.0-canary.5

package/docs/ja/autoFill.md

@@ -28,6 +28,53 @@ history:
 author: aymericzip
 ---
 
+# コンテンツ宣言ファイルの翻訳を自動入力
+
+**CI でのコンテンツ宣言ファイルの自動入力**は、開発ワークフローを高速化する方法です。
+
+## 動作の理解
+
+`fill` コマンドには2つのモードがあります：
+
+- **Complete**: 各ロケールのすべての欠落コンテンツを自動的に入力し、現在のファイルまたは指定された別のファイルを編集します。つまり、完全モードは既に翻訳されている既存コンテンツのスキップします。
+- **Review**: 各ロケールのすべてのコンテンツを自動的に入力し、特定のファイルまたは指定された別のファイルを生成します。
+
+`fill` コマンドはすべてのロケールコンテンツ宣言ファイルを処理します。つまり、CMSからのリモートコンテンツは処理しません。CMSは独自の翻訳管理を含んでいます。
+`@intlayer/sync-json-plugin` などのプラグインを使用する場合、Intlayerはこれらのファイルをロケールコンテンツ宣言ファイルに変換します。つまり、これらのファイルは `fill` コマンドによって処理されます。
+
+新しく生成されたファイルには、辞書メタデータとして `filled` 命令が含まれています。この命令は、Intlayerがファイルが自動入力されたかどうかを判定し、存在する場合はこのファイルを再度翻訳の対象からスキップするために使用されます。
+
+Intlayerは自動入力に関して以下の命令を考慮します：
+
+- `.content.{ts|js|json}` ファイルから → `fill` 命令
+- 設定ファイル `.intlayer.config.ts` から → `dictionary.fill` 命令
+- それ以外の場合はデフォルトで `true` に設定されます
+
+ロケール固有のコンテンツ宣言ファイルの場合、`true` 命令は `./{{fileName}}.fill.content.json` に置き換えられます。これは、ロケール固有のコンテンツ宣言ファイルが追加のローカライズされたコンテンツを受け取ることができないためです。そのため、既存のファイルを上書きしないために新しいファイルを生成します。
+
+## デフォルト動作
+
+デフォルトでは、`fill`はグローバルに`true`に設定されています。これは、Intlayerがすべてのコンテンツファイルを自動的に入力し、ファイル自体を編集することを意味します。この動作は、いくつかの方法でカスタマイズできます。
+
+### グローバル設定オプション
+
+1. **`fill: true` (デフォルト)** - すべてのロケールを自動的に埋め、現在のファイルを編集します
+2. **`fill: false`** - このコンテンツファイルの自動埋めを無効にします
+3. **`fill: "./relative/path/to/file"`** - 現在のファイルを編集せずに指定されたファイルを作成/更新します。相対パスは現在のファイルの場所に基づいて解決されます
+4. **`fill: "/absolute/path/to/file"`** - 現在のファイルを編集せずに指定されたファイルを作成/更新します。相対パスは基本ディレクトリの場所に基づいて解決されます（設定ファイル `.intlayer.config.ts` の `baseDir` フィールド）
+5. **`fill: "C:\\absolute\path\to\file"`** - 現在のファイルを編集せずに指定されたファイルを作成/更新します。絶対パスはお使いのオペレーティングシステムに基づいて解決されます
+6. **`fill: { [key in Locales]?: string }`** - 各ロケールについて指定されたファイルを作成/更新します
+
+### v7 の動作変更
+
+v7 では、`fill` コマンドの動作が更新されました：
+
+- **`fill: true`** - 現在のファイルを全ロケールの埋め込みコンテンツで上書きします
+- **`fill: "path/to/file"`** - 指定されたファイルを埋め込みますが、現在のファイルは変更しません
+- **`fill: false`** - 自動埋め込みを完全に無効にします
+
+別のファイルに書き込むためのパスオプションを使用する場合、埋め込みメカニズムはコンテンツ宣言ファイル間の _マスター・スレーブ_ 関係を通じて機能します。メインファイル（マスター）が情報源として機能し、更新されると、Intlayer はパスで指定されたスレーブの宣言ファイルに変更を自動的に適用します。
+
 # 自動入力コンテンツ宣言ファイルの翻訳
 
 **自動入力コンテンツ宣言ファイル**は、開発ワークフローを高速化する方法です。
@@ -88,6 +135,40 @@ Intlayer は、メインファイルにまだ宣言されていないすべて
 
 その後、両方の宣言ファイルは単一の辞書にマージされ、標準の `useIntlayer("example")` フック（React）/ コンポーザブル（Vue）を使ってアクセス可能になります。
 
+## グローバル設定
+
+`intlayer.config.ts` ファイルでグローバル自動入力設定を構成できます。
+
+```ts fileName="intlayer.config.ts"
+import { type IntlayerConfig, Locales } from "intlayer";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    defaultLocale: Locales.ENGLISH,
+    requiredLocales: [Locales.ENGLISH, Locales.FRENCH],
+  },
+  dictionary: {
+    // すべての辞書に対して欠落している翻訳を自動生成します
+    fill: "./{{fileName}}Filled.content.ts",
+    //
+    // fill: "/messages/{{locale}}/{{key}}/{{fileName}}.content.json",
+    //
+    // fill: true, // "./{{fileName}}.content.json" を使用しているようなすべての辞書に対して欠落している翻訳を自動生成します
+    //
+    // fill: {
+    //   en: "./{{fileName}}.en.content.json",
+    //   fr: "./{{fileName}}.fr.content.json",
+    //   es: "./{{fileName}}.es.content.json",
+    // },
+  },
+};
+
+export default config;
+```
+
+コンテンツファイルの `fill` フィールドを使用して、辞書ごとに細かく調整することもできます。Intlayer は最初に辞書ごとの設定を検討し、その後グローバル設定にフォールバックします。
+
 ## 自動補完されたファイル形式
 
 自動補完された宣言ファイルに推奨される形式は **JSON** であり、これによりフォーマットの制約を回避できます。ただし、Intlayer は `.ts`、`.js`、`.mjs`、`.cjs` などの他の形式もサポートしています。

package/docs/ja/benchmark/solid.md

@@ -118,6 +118,28 @@ i18nリークの問題を素早く特定するために、無料のスキャナ
 - **名前空間付き静的（Scoped static）**: 複雑な追加リクエストなしで、コードを整理（論理的分離）した状態に保つ。
 - **名前空間付き動的（Scoped dynamic）**: コード分割とパフォーマンスのための最善のアプローチ。現在のビューとアクティブなロケールに必要なものだけをロードし、メモリ使用量を最小限に抑える。
 
+### 測定内容:
+
+実際のブラウザで各スタック向けに同じ多言語アプリを実行し、実際にどのようなデータが送信されたか、処理にどのくらい時間がかかったかを記録しました。サイズは**通常のウェブ圧縮後**に報告されています。これは生のソースコードのサイズよりも、実際にユーザーがダウンロードするものに近いためです。
+
+- **国際化ライブラリサイズ**: バンドリング、ツリーシェイキング、およびミニフィケーション後、i18nライブラリのサイズは、空のコンポーネント内のプロバイダー + フック/プリミティブコードのサイズです。翻訳ファイルの読み込みは含まれていません。コンテンツが入る前に、ライブラリがどのくらい高コストかを示します。
+
+- **ページごとのJavaScript**: 各ベンチマークルートについて、そのアクセス時にブラウザが引き込むスクリプトの量。スイート内のページ間で平均化されます（レポートがロールアップする場合はロケール間でも）。ヘビーページは遅いページです。
+
+- **他のロケールからのリーク**: 監査対象ページで誤って読み込まれるはずの、別の言語の同じページのコンテンツです。このコンテンツは不要であり、回避すべきです。（例: `/en/about`ページバンドル内の`/fr/about`ページコンテンツ）
+
+- **他のルートからのリーク**: **他の画面**についても同じ考え方です。1つのページを開いたときに、その他のページのコピーが一緒に読み込まれるかどうかです。（例: `/en/contact`ページバンドル内の`/en/about`ページコンテンツ）。スコアが高いことは、弱い分割またはバンドルが過度に広いことを示唆しています。
+
+- **平均コンポーネントバンドルサイズ**: 一般的なUIピースは、1つの巨大なアプリ番号の内部に隠れるのではなく、**1つずつ**測定されます。国際化が日常的なコンポーネントを静かに膨張させているかどうかを示します。例えば、コンポーネントが再レンダリングされる場合、メモリからすべてのデータを読み込みます。巨大なJSONを任意のコンポーネントに添付することは、コンポーネントのパフォーマンスを低下させる大量の未使用データを接続するようなものです。
+
+- **言語切り替えの応答性**: アプリ自身のコントロールを使って言語を切り替え、ページが明確に切り替わるまでにかかる時間を測定します。これは実験室のマイクロステップではなく、訪問者が気付くものです。
+
+- **言語変更後のレンダリング作業**: より狭いフォローアップです。切り替えが実行されている間に、新しい言語のために、インターフェイスの再描画にどのくらいの労力がかかったかです。「感じられた」時間とフレームワークのコストが異なる場合に役立ちます。
+
+- **初期ページ読み込み時間**: ナビゲーションからブラウザがテストしたシナリオのページが完全に読み込まれたと判断するまで。コールドスタートの比較に適しています。
+
+- **ハイドレーション時間**: アプリがそれを公開する場合、クライアントがサーバーHTMLを実際にクリック可能な状態に変えるのにかかる時間です。表の中のダッシュは、その実装がこのベンチマークで信頼できるハイドレーション数値を提供しなかったことを意味します。
+
 ## GitHubのスター
 
 GitHubのスターは、プロジェクトの普及度、コミュニティの信頼、および長期的な関連性を示す強力な指標です。技術的な品質を直接測定するものではありませんが、どれだけの開発者がプロジェクトを有用だと感じ、その進捗をフォローし、採用する可能性があるかを反映しています。プロジェクトの価値を見積もる際、スターは代替案との勢いの比較を助け、エコシステムの成長に関する洞察を提供します。

package/docs/ja/benchmark/svelte.md

@@ -116,6 +116,28 @@ i18nリークの問題を素早く特定するために、無料のスキャナ
 - **名前空間付き静的（Scoped static）**: 複雑な追加リクエストなしで、コードを整理（論理的分離）した状態に保つ。
 - **名前空間付き動的（Scoped dynamic）**: コード分割とパフォーマンスのための最善のアプローチ。現在のビューとアクティブなロケールに必要なものだけをロードし、メモリ使用量を最小限に抑える。
 
+### 測定内容：
+
+実際のブラウザで各スタックの同じ多言語アプリを実行し、実際にネットワークに送信されたものと処理時間を記録しました。サイズは**通常のウェブ圧縮後**に報告されています。これはユーザーがダウンロードする実際のサイズに近いため、生のソースコード数よりも適切です。
+
+- **国際化ライブラリのサイズ**: バンドリング、ツリーシェイキング、ミニフィケーション後の i18n ライブラリのサイズは、空のコンポーネント内のプロバイダー + ストアコードのサイズです。翻訳ファイルの読み込みは含まれていません。これはコンテンツが含まれる前にライブラリにかかるコストを示します。
+
+- **ページごとの JavaScript**: 各ベンチマークルートについて、そのアクセス時にブラウザが取得するスクリプトの量。スイート内のページとロケール全体で平均化されています（レポートにまとめられている場合）。重いページは遅いページです。
+
+- **他のロケールからのリーク**: 監査対象ページに誤って読み込まれる、別の言語での同じページのコンテンツです。このコンテンツは不要であり、避けるべきです。（例：`/en/about` ページバンドル内の `/fr/about` ページコンテンツ）
+
+- **他のルートからのリーク**: **他の画面**についても同じ考え方です。1 つのページを開いただけなのに、そのコピーが一緒に読み込まれるかどうかです。（例：`/en/contact` ページバンドル内の `/en/about` ページコンテンツ）。高いスコアは分割が弱いか、バンドルが広すぎることを示唆しています。
+
+- **コンポーネントバンドルサイズの平均**: 一般的な UI パーツは 1 つずつ測定され、1 つの巨大なアプリ数に隠れていません。これは国際化がいかに日常的なコンポーネントを静かに膨張させるかを示しています。例えば、コンポーネントが再レンダリングされる場合、メモリからそのすべてのデータを読み込みます。巨大な JSON をコンポーネントに接続することは、コンポーネントのパフォーマンスを低下させる大量の未使用データストアに接続するようなものです。
+
+- **言語切り替えの応答性**: アプリの独自のコントロールを使用して言語を切り替え、ページが明らかに切り替わるまでにかかる時間を計測します。これは訪問者が気付く、ラボのマイクロステップではありません。
+
+- **言語変更後のレンダリング作業**: より狭い範囲のフォローアップです。スイッチが実行中になった後、新しい言語に対して再描画するためにインターフェースがどれだけの労力を費やしたかです。「体感」時間とフレームワークのコストが異なる場合に役立ちます。
+
+- **初期ページ読み込み時間**: ナビゲーションからブラウザがテストシナリオのページが完全に読み込まれたと判断するまで。コールドスタートを比較するのに最適です。
+
+- **ハイドレーション時間**: アプリが公開している場合、クライアントがサーバー HTML を実際にクリックできるものに変える際にかかる時間です。テーブル内のダッシュは、その実装がこのベンチマークで信頼できるハイドレーション数値を提供しなかったことを意味します。
+
 ## GitHubのスター
 
 GitHubのスターは、プロジェクトの普及度、コミュニティの信頼、および長期的な関連性を示す強力な指標です。技術的な品質を直接測定するものではありませんが、どれだけの開発者がプロジェクトを有用だと感じ、その進捗をフォローし、採用する可能性があるかを反映しています。プロジェクトの価値を見積もる際、スターは代替案との勢いの比較を助け、エコシステムの成長に関する洞察を提供します。

package/docs/ja/benchmark/tanstack.md

@@ -124,6 +124,28 @@ i18nのリーク問題を素早く特定するために、無料のスキャナ
 - **Scoped static**: 複雑な追加ネットワークリクエストなしで、コードを整理（論理的な分離）できる。
 - **Scoped dynamic**: コード分割とパフォーマンスにおいて最良のアプローチ。現在のビューとアクティブなロケールが必要なものだけをロードすることで、メモリ使用量を最小限に抑える。
 
+### 測定内容:
+
+私は、すべてのスタックに対して同じ多言語アプリを実際のブラウザで実行し、実際にネットワークを通じて何が表示されたか、どのくらい時間がかかったかを記録しました。サイズは**通常のウェブ圧縮後**に報告されています。これは生ソースコード数よりも、人々が実際にダウンロードするものに近いためです。
+
+- **国際化ライブラリサイズ**: バンドリング、ツリーシェイキング、ミニファイ後の i18n ライブラリのサイズは、空のコンポーネント内のプロバイダー（例：`NextIntlClientProvider`）+ フック（例：`useTranslations`）コードのサイズです。翻訳ファイルの読み込みは含まれません。これにより、コンテンツが入る前にライブラリがどの程度コストがかかるかが分かります。
+
+- **ページごとの JavaScript**: 各ベンチマークルートについて、その訪問時にブラウザが取得するスクリプトの量を、スイート内のページ全体にわたり、またレポートがロールアップする場所のロケール全体にわたって平均化したものです。重いページは遅いページです。
+
+- **他のロケールからのリーク**: 同じページであっても、別の言語であり、監査されたページに誤って読み込まれるコンテンツです。このコンテンツは不要であり、回避する必要があります。（例：`/en/about` ページバンドルの `/fr/about` ページコンテンツ）
+
+- **他のルートからのリーク**: アプリ内の**他の画面**についても同じ考え方です。1 つのページのみを開いたときに、そのコピーが一緒に読み込まれるかどうかです。（例：`/en/contact` ページバンドルの `/en/about` ページコンテンツ）。スコアが高い場合は、分割が弱いか、バンドルが過度に広いことを示唆しています。
+
+- **平均コンポーネントバンドルサイズ**: 一般的な UI コンポーネントは、1 つの巨大なアプリ番号内に隠れるのではなく、**1 つずつ**測定されます。国際化が日常的なコンポーネントを静かに膨張させているかどうかを示します。例えば、コンポーネントが再レンダリングされる場合、メモリからすべてのデータを読み込みます。巨大な JSON をコンポーネントに添付することは、コンポーネントのパフォーマンスを低下させる、使用されていない大量のデータストアに接続するようなものです。
+
+- **言語切り替えレスポンシビティ**: アプリ独自の制御を使用して言語を切り替え、ページが明確に切り替わるまでにかかる時間を計測します。訪問者が気付くこと、ラボの微視的なステップではありません。
+
+- **言語変更後のレンダリング作業**: より狭い追跡です。スイッチが実行中になった後、新しい言語のために、インターフェイスが再描画するのに要した努力がどの程度であるかです。「感じられた」時間とフレームワークコストが異なる場合に役立ちます。
+
+- **初期ページロード時間**: ナビゲーションから、テストしたシナリオについてページが完全に読み込まれたと見なすブラウザまで。コールドスタートを比較するのに適しています。
+
+- **ハイドレーション時間**: アプリが公開している場合、クライアントがサーバー HTML を実際にクリックできるものに変換するのにかかる時間です。テーブルのダッシュ記号は、その実装がこのベンチマークで信頼性の高いハイドレーション数値を提供しなかったことを意味します。
+
 ## GitHubのスター
 
 GitHubのスターは、プロジェクトの普及度、コミュニティの信頼、および長期的な関連性を示す強力な指標です。技術的な品質を直接測定するものではありませんが、どれだけの開発者がプロジェクトを有用だと感じ、その進捗をフォローし、採用する可能性があるかを反映しています。プロジェクトの価値を見積もる際、スターは代替案との勢いの比較を助け、エコシステムの成長に関する洞察を提供します。

package/docs/ja/cli/ci.md

@@ -140,6 +140,28 @@ steps:
     run: npx intlayer ci fill
 ```
 
+## スキャフォルドされた GitHub Actions
+
+`intlayer init` を実行すると、Intlayer はパッケージマネージャー (npm、yarn、pnpm、または bun) を検出し、`.github/workflows/` の下に 2 つの GitHub Actions ワークフローをスキャフォルドします。コマンドはそのパッケージマネージャーに対応します:
+
+- **`intlayer-fill.yml`** — すべてのプルリクエストで、辞書をビルドし `intlayer fill --git-diff --mode complete` を実行して、変更された辞書の欠落している翻訳を生成し、結果を PR ブランチにコミットします。
+- **`intlayer-test.yml`** — すべてのプルリクエストで、辞書をビルドし `intlayer test` を実行し、必要なロケールの翻訳が不足している場合はチェックを失敗させます。
+
+既存のワークフローファイルが上書きされることはありません。スキャフォルディングをスキップするには、以下を実行します:
+
+```bash
+npx intlayer init --no-github-actions
+```
+
+### fill workflowへのAIアクセスの提供
+
+スキャフォルドされた `intlayer-fill.yml` はAIアクセスが必要です。2つのオプションが利用可能です（workflowの `env` ブロックで設定）:
+
+1. **独自のAIプロバイダーキー** — リポジトリ設定（Settings → Secrets and variables → Actions）に `AI_API_KEY` シークレットを追加します。workflowは `--provider`、`--model`、`--api-key` 経由でそれを転送します。
+2. **Intlayer CMSアクセスキー** — `INTLAYER_CLIENT_ID` と `INTLAYER_CLIENT_SECRET` シークレットを追加し、`intlayer.config` の `editor` セクションに接続します。CMSアクセスキーはIntlayer backendを通じてAIアクセスを許可します。
+
+`intlayer-test.yml` workflowはAIアクセスを必要としません。
+
 ## エラーハンドリング
 
 - `INTLAYER_PROJECT_CREDENTIALS`が設定されていない場合、コマンドはエラーで終了します。

package/docs/ja/cli/fill.md

@@ -47,6 +47,14 @@ bun x intlayer fill
 - 既存の翻訳を上書きしないことで、既存の翻訳を保持します。
 - キューシステムを使用してファイル、チャンク、ロケールを並列処理し、速度を向上させます。
 
+## 主なポイント:
+
+- 大規模なJSONファイルをチャンクに分割して、AIモデルのコンテキストウィンドウ制限内に収まるようにします。
+- 出力形式が正しくない場合は翻訳を再試行します。
+- アプリケーション固有とファイル固有のコンテキストを組み込んで、翻訳精度を向上させます。
+- 既存の翻訳を保持し、上書きしません。
+- キューシステムを使用してファイル、チャンク、ロケールを並列処理して、速度を向上させます。
+
 ## エイリアス:
 
 - `npx intlayer dictionaries fill`

package/docs/ja/cli/list_projects.md

@@ -99,24 +99,6 @@ pnpm intlayer projects list
 bun x intlayer projects list
 ```
 
-### 現在のディレクトリ内のプロジェクトを一覧表示:
-
-```bash packageManager="npm"
-npx intlayer projects list --base-dir ./packages
-```
-
-```bash packageManager="yarn"
-yarn intlayer projects list --base-dir ./packages
-```
-
-```bash packageManager="pnpm"
-pnpm intlayer projects list --base-dir ./packages
-```
-
-```bash packageManager="bun"
-bun x intlayer projects list --base-dir ./packages
-```
-
 ### 特定ディレクトリ内のプロジェクトを一覧表示:
 
 ```bash packageManager="npm"

package/docs/ja/compat/i18n-js.md

@@ -0,0 +1,44 @@
+---
+createdAt: 2026-06-13
+updatedAt: 2026-06-13
+title: "i18n-jsからIntlayerへの移行"
+description: "compatアダプタを使用してアプリケーションをi18n-jsからIntlayerに移行する方法を学びます。"
+keywords:
+  - i18n-js
+  - intlayer
+  - migration
+  - compat
+slugs:
+  - doc
+  - compatibility
+  - i18n-js
+history:
+  - version: 9.0.0
+    date: 2026-06-13
+    changes: "Init history"
+author: aymericzip
+---
+
+# i18n-js から Intlayer への移行
+
+`i18n-js` ライブラリから Intlayer への移行は、大規模な翻訳設定を Intlayer の構造化されたファイル解決システムにオフロードするために設計された、高度に最適化された移行です。
+
+## やることリスト
+
+リポジトリで次のセットアップコマンドを実行してください：
+
+```bash
+npx intlayer init
+```
+
+`intlayer.config.ts`を準備したら、バンドラー設定にIntlayerのエイリアスを追加して、`i18n-js`のインポートが互換性パッケージ`@intlayer/i18n-js`を対象とするようにすることができます。
+
+## 内部的な動作
+
+`i18n-js` は `i18n.t('scope.key', {name})` のような式を通じてネームスペースにアクセスし、ロケールフォールバックと特定の複数形マッピングに対応しています。
+
+内部的には：
+
+- **補間:** compat アダプターは `%{name}` マッピングをターゲットとするランタイム辞書値に簡単に解析します。
+- **複数形:** `one/other` サブキーを置き換え、Intlayer の強力な基礎となる複数形メカニズム (`Intl.PluralRules`) に対してマップし、手動マッピングを抽象化します。
+- **ロケール:** ブートストラップ時にモノリシック言語ペイロードを読み込む代わりに、ネイティブ Intlayer 設定を通じて現在のコンテキスト設定に基づいて辞書が最適に提供されます。

package/docs/ja/compat/i18next.md

@@ -0,0 +1,59 @@
+---
+createdAt: 2026-06-13
+updatedAt: 2026-06-13
+title: "i18nextからIntlayerへの移行"
+description: "compat adapterを使用して、Vanilla JS/TSアプリケーションをi18nextからIntlayerに移行する方法を学びます。"
+keywords:
+  - i18next
+  - vanilla
+  - javascript
+  - typescript
+  - intlayer
+  - migration
+  - compat
+slugs:
+  - doc
+  - compatibility
+  - i18next
+history:
+  - version: 9.0.0
+    date: 2026-06-13
+    changes: "Init history"
+author: aymericzip
+---
+
+# i18nextからIntlayerへの移行
+
+詳細なステップバイステップのチュートリアルについては、[i18next Migration Guide](../migration_from_i18next_to_intlayer.md)をご覧ください。
+
+Intlayerは`i18next`のコア実行時特性を完全に複製します。compatパッケージを利用することで、Vanillaアプリケーションまたは内部モジュールは引き続き馴染みのある構文を活用できます。
+
+## やることリスト
+
+まず、プロジェクトで Intlayer を初期化します：
+
+```bash
+npx intlayer init
+```
+
+Vite を使用している場合、Intlayer プラグインを含めて `@intlayer/i18next` へのインポートをルーティングしてください：
+
+```typescript fileName="vite.config.ts"
+import { defineConfig } from "vite";
+import { i18nextVitePlugin } from "@intlayer/i18next/plugin";
+
+export default defineConfig({
+  plugins: [i18nextVitePlugin()],
+});
+```
+
+## 内部動作
+
+`i18nextVitePlugin` は `i18next` インポートを `@intlayer/i18next` にエイリアスし、JSON ファイル含有によるバンドル肥大化を回避します。
+
+内部動作:
+
+- **インスタンス設定:** `createInstance` は名前空間フォールバックを正しく解析・適用し、Intlayer のコンパイルパイプラインを活用して辞書取得を行います。
+- **補間:** `{{name}}` 置換と `$t(key)` ネストの再帰的なネイティブサポート。
+- **コンテキスト & 複数形:** `key_male` や `key_one`/`key_other` のようなサフィックス形式を識別・解決し、標準 `Intl.PluralRules` に対して評価します。
+- **オブジェクト返却:** `returnObjects: true` モードは Intlayer 辞書からツリーを安全に抽出します。

package/docs/ja/compat/index.md

@@ -0,0 +1,51 @@
+---
+createdAt: 2026-06-13
+updatedAt: 2026-06-13
+title: "Intlayer Compat アダプター"
+description: "既存の i18n ソリューションを、compat アダプターを使用して、ゼロの摩擦で Intlayer に移行してください。"
+keywords:
+  - compat
+  - migration
+  - internationalization
+  - i18n
+  - Intlayer
+slugs:
+  - doc
+  - compatibility
+history:
+  - version: 9.0.0
+    date: 2026-06-13
+    changes: "Init history"
+author: aymericzip
+---
+
+# Intlayer Compat Adapters
+
+大規模なアプリケーションを新しい国際化ライブラリに移行することは困難な場合があります。この移行を容易にするため、Intlayer はエコシステムで最も人気のある i18n ライブラリ用の **compat adapters** を提供しています。
+
+これらのアダプターパッケージは、既存の i18n ライブラリと **まったく同じパブリック API** を公開していますが、すべての翻訳作業を実行時に Intlayer に委譲しています。
+
+## 仕組み
+
+compat アダプターを使用する場合、アプリケーションのインポートを書き直したり、翻訳フックとコンポーネントの使用方法を変更したりする必要はありません。代わりに、Intlayer のバンドラープラグインが既存のインポートを自動的に Intlayer compat パッケージにエイリアスします。
+
+例えば、開発者は `import { useTranslation } from 'react-i18next'` を `import { useTranslation } from '@intlayer/react-i18next'` に置き換えます (バンドラープラグインが自動的に行います)。すると、アプリケーションは Intlayer 辞書から提供される翻訳で動作し続けます。キーは Intlayer 辞書に対しても型付けされています！
+
+## 利用可能な互換性アダプター
+
+以下から既存のライブラリを選択して、シームレスに移行する方法を確認してください：
+
+- [Vue I18n](./vue-i18n.md)
+- [Transloco](./transloco.md)
+- [React Intl](./react-intl.md)
+- [Svelte I18n](./svelte-i18n.md)
+- [React i18next](./react-i18next.md)
+- [Polyglot.js](./polyglot.md)
+- [NuxtJS I18n](./nuxtjs-i18n.md)
+- [NGX Translate](./ngx-translate.md)
+- [Next Translate](./next-translate.md)
+- [Next Intl](./next-intl.md)
+- [Next i18next](./next-i18next.md)
+- [i18next](./i18next.md)
+- [Lingui](./lingui.md)
+- [I18n-js](./i18n-js.md)

package/docs/ja/compat/lingui.md

@@ -0,0 +1,44 @@
+---
+createdAt: 2026-06-13
+updatedAt: 2026-06-13
+title: "Linguiからintlayerへの移行"
+description: "compat adapterを使用してLinguiアプリケーションからIntlayerへ移行する方法を学びます。"
+keywords:
+  - lingui
+  - intlayer
+  - migration
+  - compat
+slugs:
+  - doc
+  - compatibility
+  - lingui
+history:
+  - version: 9.0.0
+    date: 2026-06-13
+    changes: "Init history"
+author: aymericzip
+---
+
+# Linguiからの移行 Intlayer
+
+現在、プロジェクトがLinguiのマクロベースのコンパイルに依存している場合、Intlayerへの移行により、強力なマクロワークフローを維持しながら、Intlayerの JSON コンパイル戦略でネイティブにサポートすることができます。
+
+## 実施方法
+
+まず、プロジェクトで Intlayer を初期化します:
+
+```bash
+npx intlayer init
+```
+
+これにより `intlayer.config.ts` が作成されます。ビルドステップで `@lingui/babel-plugin-lingui-macro` / `@lingui/swc-plugin` を保持し、Intlayer compiler の _前に_ 実行されることを確認してください。その後、bundler plugin alias を使用して `@lingui/core` と `@lingui/react` を `@intlayer/lingui` にルーティングします。
+
+## 内部動作
+
+Linguiは、マクロ（`` t`Hello ${name}` ``および`<Trans>`など）を使用しており、これらは`i18n._(id, values)`のようなランタイム呼び出しにコンパイルされます。
+
+内部動作:
+
+- **マクロ:** これらは以前と同じようにコンパイルされ、ソース構文の中断がないことを保証します。
+- **ランタイム翻訳:** エイリアス化された`i18n._()`はIntlayerの辞書を使用します。明示的に名付けられたIDとハッシュ化されたIDの両方が、Intlayerの`.po`同期プラグインを使用して完全にマップされ、キーを安全に集約およびプルーニングします。
+- **ICU機能:** 複数形化、選択、およびICUバリアントのサポートは、Intlayerの統一されたICUパーサーにより堅牢であり、同じレンダリング出力を保証します。

package/docs/ja/compat/next-i18next.md

@@ -0,0 +1,57 @@
+---
+createdAt: 2026-06-13
+updatedAt: 2026-06-13
+title: "next-i18nextからIntlayerへの移行"
+description: "compat アダプターを使用して、Next.js アプリケーションを next-i18next から Intlayer に移行する方法を学びます。"
+keywords:
+  - next-i18next
+  - nextjs
+  - intlayer
+  - migration
+  - compat
+slugs:
+  - doc
+  - compatibility
+  - next-i18next
+history:
+  - version: 9.0.0
+    date: 2026-06-13
+    changes: "Init history"
+author: aymericzip
+---
+
+# next-i18nextからIntlayerへの移行
+
+完全で詳細なステップバイステップのチュートリアルについては、[next-i18next移行ガイド](../migration_from_next-i18next_to_intlayer.md)をご参照ください。
+
+Intlayerは、Next.js Pages RouterとApp Routerのすべての実装を透過的に処理します。アダプターを使用することで、`next-i18next`の実装をコードの書き換えなしで移行できます。
+
+## 実行する内容
+
+開始するには、以下を実行してください:
+
+```bash
+npx intlayer init
+```
+
+これにより、必要な Intlayer セットアップファイルが作成されます。バックグラウンドで Intlayer を使用するように切り替えるには、`next.config.ts` を更新してください:
+
+```typescript fileName="next.config.ts"
+import type { NextConfig } from "next";
+import { createNextI18nPlugin } from "@intlayer/next-i18next/plugin";
+
+const withIntlayer = createNextI18nPlugin();
+
+const nextConfig: NextConfig = {};
+
+export default withIntlayer(nextConfig);
+```
+
+## 仕組みの詳細
+
+`createNextI18nPlugin` は Next.js のネイティブな動作と core `next-intlayer` プラグインを合成し、`next-i18next`、`react-i18next`、`i18next` に必要なすべての Webpack/Turbopack エイリアスをインジェクトします。
+
+仕組みの詳細：
+
+- **`serverSideTranslations` & `appWithTranslation`:** これらは Intlayer の内部ローダーのラッパーとして機能し、大規模な静的 JSON インジェクションを回避します。
+- **Client hooks:** `@intlayer/react-i18next` に直接委譲され、すべてのフォーマット、複数形、およびネストされた namespace 機能を保持します。

package/docs/ja/compat/next-intl.md

@@ -0,0 +1,59 @@
+---
+createdAt: 2026-06-13
+updatedAt: 2026-06-13
+title: "next-intl から Intlayer への移行"
+description: "compat アダプタを使用して、Next.js アプリケーションを next-intl から Intlayer に移行する方法を学びます。"
+keywords:
+  - next-intl
+  - nextjs
+  - intlayer
+  - migration
+  - compat
+slugs:
+  - doc
+  - compatibility
+  - next-intl
+history:
+  - version: 9.0.0
+    date: 2026-06-13
+    changes: "Init history"
+author: aymericzip
+---
+
+# next-intl から Intlayer への移行
+
+完全で詳細なステップバイステップチュートリアルについては、[next-intl 移行ガイド](../migration_from_next-intl_to_intlayer.md)を参照してください。
+
+`next-intl` から Intlayer への移行により、アプリケーションのルーティングとシンタックスを完全に変更せずに維持できます。
+
+## やること
+
+リポジトリで次のコマンドを実行します:
+
+```bash
+npx intlayer init
+```
+
+これにより `intlayer.config.ts` が作成されます。`next.config.ts` で、プラグインラッパーを使用して `next-intl` のエイリアスを `@intlayer/next-intl` にシームレスに注入します。
+
+```typescript fileName="next.config.ts"
+import type { NextConfig } from "next";
+import { createNextIntlPlugin } from "@intlayer/next-intl/plugin";
+
+const withIntlayer = createNextIntlPlugin();
+
+const nextConfig: NextConfig = {};
+
+export default withIntlayer(nextConfig);
+```
+
+## 内部的な動作
+
+bundlerラッパーは翻訳を置き換えますが、**`next-intl/navigation`の機能は損なわれません**（例：`Link`、`redirect`、`usePathname`）。
+
+内部的には：
+
+- **ICU runtime:** 複数形（`=0`、`one`、`other`）、select/selectordinal、`#`引数、フォーマット済み引数（`{ts, date, long}`）は、共有の`resolveMessage(..., 'icu')`リゾルバーを使用して正しく実行されます。
+- **`useTranslations()` & `getTranslations()`:** ベアスコープの呼び出しは、最初のキーセグメントを正しい辞書識別子として抽出します。ネストされた名前空間は、辞書パスとプレフィックスに適切に分割されます。
+- **Rich formatting:** `t.rich()`と`t.markup()`の両方が完全にネイティブに実装され、HTML風のノードをレンダリングされたReactチャンクに変換します。
+- **`useFormatter`:** `relativeTime`、`list`、`dateTimeRange`、および設定からの名前付きフォーマットが、コアのネイティブな`Intl`フォーマッターにブリッジされます。

package/docs/ja/compat/next-translate.md

@@ -0,0 +1,45 @@
+---
+createdAt: 2026-06-13
+updatedAt: 2026-06-13
+title: "Next Translateから Intlayerへの移行"
+description: "compat adapterを使用して、Next.jsアプリケーションをnext-translateからIntlayerに移行する方法を学びます。"
+keywords:
+  - next-translate
+  - nextjs
+  - intlayer
+  - migration
+  - compat
+slugs:
+  - doc
+  - compatibility
+  - next-translate
+history:
+  - version: 9.0.0
+    date: 2026-06-13
+    changes: "Init history"
+author: aymericzip
+---
+
+# Next Translateから Intlayerへの移行
+
+`next-translate` から Intlayer への移行は、既存の構文とタグを保持するほぼドロップイン置換です。
+
+## やること
+
+プロジェクトで Intlayer を初期化します:
+
+```bash
+npx intlayer init
+```
+
+CLI があなたの設定をスキャフォルドします。その後、`next.config.ts` で Intlayer プラグインを適用でき、ビルド時に `next-translate/useTranslation` を `@intlayer/next-translate` にマッピングするサブパスエイリアスを注入します。
+
+## 内部的な動作
+
+`next-translate` は `useTranslation('ns')`、`t('ns:key.path')`、および `<Trans>` コンポーネントなどのフックを提供します。
+
+内部的には：
+
+- **補間とプルーラル:** `react-i18next` アダプターの動作に密接に依存しています。`{{var}}` プレースホルダーと `key_0`、`key_one`、`key_other` などのサフィックスからマップされたプルーラル化が動的に処理されます。
+- **`<Trans>` コンポーネント:** HTML風のタグ解析が、配列ベースの `components` プロップと共に直接サポートされています。
+- **Namespaces:** サブパスエイリアシングにより、`useTranslation` が手動修正なしに正しい内部辞書 namespace を参照することを保証します。