@intlayer/docs 8.12.5-canary.0 → 9.0.0-canary.10

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/doc-review.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-06-17
 title: ドキュメントのレビュー
 description: 異なるロケール間での品質、一貫性、完全性を確認するためのドキュメントファイルのレビュー方法を学びます。
 keywords:
@@ -15,6 +15,10 @@ slugs:
   - concept
   - cli
   - doc-review
+history:
+  - version: 9.0.0
+    date: 2026-06-17
+    changes: "--log オプションを追加"
 author: aymericzip
 ---
 
@@ -55,8 +59,110 @@ bun x intlayer doc review
 
 ## 引数:
 
-`doc review` コマンドは `doc translate` と同じ引数を受け付け、特定のドキュメントファイルをレビューし品質チェックを適用できます。
+**ファイルリストオプション:**
 
-もし git オプションのいずれかを有効にしている場合、コマンドは変更されているファイルの部分のみをレビューします。スクリプトはファイルをチャンクに分割して処理し、各チャンクをレビューします。チャンクに変更がなければ、レビュー処理を高速化し AI プロバイダーの API コストを抑えるためにそのチャンクはスキップされます。
+- **`--doc-pattern [docPattern...]`**: レビューするドキュメントファイルにマッチするグロブパターン。
 
-完全な引数の一覧については、[Translate Document](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/cli/doc-translate.md) コマンドのドキュメントを参照してください。
+  > 例: `npx intlayer doc review --doc-pattern "docs/**/*.md" "src/**/*.mdx"`
+
+- **`--excluded-glob-pattern [excludedGlobPattern...]`**: レビューから除外するグロブパターン。
+
+  > 例: `npx intlayer doc review --excluded-glob-pattern "docs/internal/**"`
+
+- **`--skip-if-modified-before [skipIfModifiedBefore]`**: 指定した日時より前に変更されたファイルをスキップします。
+  - 絶対日時として "2025-12-05"（文字列またはDate型）を指定可能
+  - ミリ秒単位の相対時間として `1 * 60 * 60 * 1000`（1時間）を指定可能
+  - このオプションは `fs.stat` メソッドを使ってファイルの更新日時をチェックします。そのため、Gitやその他のツールによるファイル変更の影響を受ける可能性があります。
+
+  > 例: `npx intlayer doc review --skip-if-modified-before "2025-12-05"`
+
+- **`--skip-if-modified-after [skipIfModifiedAfter]`**: 指定した日時以内に変更されたファイルをスキップします。
+  - 絶対日時として "2025-12-05"（文字列またはDate型）を指定可能
+  - ミリ秒単位の相対時間として `1 * 60 * 60 * 1000`（1時間）を指定可能
+  - このオプションは `fs.stat` メソッドを使ってファイルの更新日時をチェックします。そのため、Gitやその他のツールによるファイル変更の影響を受ける可能性があります。
+
+  > 例: `npx intlayer doc review --skip-if-modified-after "2025-12-05"`
+
+- **`--skip-if-exists`**: 既にファイルが存在する場合、そのファイルをスキップします。
+
+  > 例: `npx intlayer doc review --skip-if-exists`
+
+**レビューモードオプション:**
+
+- **`--log`**: ログ出力のみモード。AIによる翻訳は行わず、代わりに別のエージェントが翻訳を生成できるように、ベースロケールとターゲットロケールで注意が必要なブロック（行番号と内容を含む）をログ出力します。
+
+  > 例: `npx intlayer doc review --log`
+
+**エントリー出力オプション:**
+
+- **`--locales [locales...]`**: ドキュメントをレビューする対象のロケール。
+
+  > 例: `npx intlayer doc review --locales fr es de`
+
+- **`--base-locale [baseLocale]`**: 比較元のソースロケール（ベースドキュメント）。
+
+  > 例: `npx intlayer doc review --base-locale en`
+
+**ファイル処理オプション:**
+
+- **`--nb-simultaneous-file-processed [nbSimultaneousFileProcessed]`**: レビューのために同時に処理するファイル数。
+
+  > 例: `npx intlayer doc review --nb-simultaneous-file-processed 5`
+
+**AIオプション:**
+
+- **`--model [model]`**: レビューに使用するAIモデル（例: `gpt-3.5-turbo`）。
+- **`--provider [provider]`**: レビューに使用するAIプロバイダー。
+- **`--temperature [temperature]`**: AIモデルの温度設定。
+- **`--api-key [apiKey]`**: AIサービス用のAPIキーを提供。
+- **`--application-context [applicationContext]`**: AIレビューに追加のコンテキストを提供。
+- **`--data-serialization [dataSerialization]`**: IntlayerのAI機能に使用するデータシリアライズ形式。オプション: `json` (標準的で信頼性が高い), `toon` (トークン消費が少ないが、一貫性が低い)。
+- **`--custom-prompt [prompt]`**: レビューに使用する基本プロンプトをカスタマイズします。（注：ほとんどのユースケースでは、挙動をより良く制御できるため `--custom-instructions` オプションの使用が推奨されます。）
+
+  > 例: `npx intlayer doc review --model deepseek-chat --provider deepseek --temperature 0.5 --api-key sk-1234567890 --application-context "My application is a cat store"`
+
+**環境変数オプション:**
+
+- **`--env`**: 環境を指定します（例：`development`、`production`）。
+- **`--env-file [envFile]`**: 変数を読み込むためのカスタム環境ファイルを指定します。
+- **`--base-dir`**: プロジェクトのベースディレクトリを指定します。
+- **`--no-cache`**: キャッシュを無効にします。
+
+  > 例: `npx intlayer doc review --base-dir ./docs --env-file .env.production.local`
+
+**ログオプション:**
+
+- **`--verbose`**: デバッグのために詳細なログを有効にします。（CLIではデフォルトでtrue）
+
+  > 例: `npx intlayer doc review --verbose`
+
+**カスタム指示オプション:**
+
+- **`--custom-instructions [customInstructions]`**: プロンプトに追加するカスタム指示。フォーマットやURLの翻訳など特定のルールを適用するのに便利です。
+
+  > 例: `npx intlayer doc review --custom-instructions "URLの翻訳を避け、マークダウン形式を維持する"`
+
+  > 例: `npx intlayer doc review --custom-instructions "$(cat ./instructions.md)"`
+
+**Gitオプション:**
+
+- **`--git-diff`**: 変更を含むファイル（デフォルトは `origin/main` から現在のブランチ `HEAD` への変更）のみで実行します。
+- **`--git-diff-base`**: git diffのベース参照を指定します（デフォルトは `origin/main`）。
+- **`--git-diff-current`**: git diffの現在の参照を指定します（デフォルトは `HEAD`）。
+- **`--uncommitted`**: ココミットされていない変更を含めます。
+- **`--unpushed`**: プッシュされていない変更を含めます。
+- **`--untracked`**: トラッキングされていないファイルを含めます。
+
+  > 例: `npx intlayer doc review --git-diff --git-diff-base origin/main --git-diff-current HEAD`
+
+  > 例: `npx intlayer doc review --uncommitted --unpushed --untracked`
+
+> 出力ファイルのパスは、以下のパターンを置換することで決定されることに注意してください:
+>
+> - `/{{baseLocale}}/` を `/{{locale}}/` に置換（Unix）
+> - `\{{baseLocale}}\` を `\{{locale}}\` に置換（Windows）
+> - `_{{baseLocale}}.` を `_{{locale}}.` に置換
+> - `{{baseLocale}}_` を `{{locale}}_` に置換
+> - `.{{baseLocaleName}}.` を `.{{localeName}}.` に置換
+>
+> もしパターンが見つからない場合、出力ファイルはファイル拡張子の前に `.{{locale}}` を追加します。例えば `./my/file.md` はレビューされ、フランス語ロケールの場合 `./my/file.fr.md` に更新されます。

package/docs/ja/cli/fill.md

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

package/docs/ja/cli/index.md

@@ -17,7 +17,7 @@ slugs:
   - concept
   - cli
 history:
-  - version: 8.13.0
+  - version: 9.0.0
     date: 2026-06-11
     changes: "scanコマンドの追加"
   - version: 8.6.4

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/cli/scan.md

@@ -18,7 +18,7 @@ slugs:
   - cli
   - scan
 history:
-  - version: 8.13.0
+  - version: 9.0.0
     date: 2026-06-11
     changes: "scanコマンドの追加"
 author: aymericzip

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`フォーマッターにブリッジされます。