@intlayer/docs 8.9.4-canary.0 → 8.9.5

package/docs/ja/benchmark/nextjs.md

@@ -61,6 +61,13 @@ history:
 
 Intlayerは、これらの各側面において最適化を試みています。
 
+## TL;DR
+
+- **Intlayer** & **next-translate**: Next.jsのパフォーマンスにおいて最適な選択肢。最小のフットプリントと最高の静的レンダリングサポートを提供。
+- **next-intl**: 最もトレンドのオプションだが、大規模なアプリケーション向けに最適化するには重く、複雑。
+- **next-i18next**: 人気がありプラグインも豊富だが、バンドル重量が非常に大きい（Intlayer의約3倍）。
+- **避けるべき**: **gt-next** と **lingo.dev**。深刻なパフォーマンスの問題、ベンダーロックイン、ビルドを破壊するバグのため。
+
 ## アプリをテストする
 
 これらの問題を顕在化させるために、無料のスキャナーを作成しました。[こちら](https://intlayer.org/i18n-seo-scanner)で試すことができます。
@@ -99,14 +106,14 @@ WebpackやTurbopackを使用し、`[locale]/page.tsx`のようなルートを宣
 このベンチマークでは、以下のライブラリを比較しました。
 
 - `Base App`（i18nライブラリなし）
-- `next-intlayer` (v8.7.5)
+- `next-intlayer` (v8.7.12)
 - `next-i18next` (v16.0.5)
 - `next-intl` (v4.9.1)
 - `@lingui/core` (v5.3.0)
 - `next-translate` (v3.1.2)
 - `next-international` (v1.3.1)
 - `@inlang/paraglide-js` (v2.15.1)
-- `tolgee` (v7.0.0)
+- `@tolgee/react` (v7.0.0)
 - `@lingo.dev/compiler` (v0.4.0)
 - `wuchale` (v0.22.11)
 - `gt-next` (v6.16.5)
@@ -161,10 +168,10 @@ Next.jsのバージョンは`16.2.4`（App Router）を使用しました。
 
 **(General Translation)** (`gt-next@6.16.5`):
 
-- 110kbのアプリに対して、`gt-react`は440kb以上の余分なデータを追加します。
+- 110kbのアプリに対して、`gt-next`は440kb以上の余分なデータを追加します。
 - General Translationを使用した最初のビルドで「Quota Exceeded, please upgrade your plan（クォータ超過、プランをアップグレードしてください）」と表示されました。
 - 翻訳がレンダリングされません。`Error: <T> used on the client-side outside of <GTProvider>`というエラーが発生しましたが、これはライブラリのバグのようです。
-- **gt-tanstack-start-react**を実装中、ライブラリの[問題](https://github.com/generaltranslation/gt/issues/1210#event-24510646961)にも遭遇しました。`does not provide an export named 'printAST' - @formatjs/icu-messageformat-parser`というエラーでアプリケーションが壊れました。この問題を報告した後、メンテナは24時間以内に修正しました。
+- **gt-next**を実装中、ライブラリの[問題](https://github.com/generaltranslation/gt/issues/1210#event-24510646961)にも遭遇しました。`does not provide an export named 'printAST' - @formatjs/icu-messageformat-parser`というエラーでアプリケーションが壊れました。この問題を報告した後、メンテナは24時間以内に修正しました。
 - このライブラリはNext.jsページの静的レンダリングをブロックします。
 
 **(Lingo.dev)** (`@lingo.dev/compiler@0.4.0`):
@@ -186,9 +193,11 @@ Next.jsのバージョンは`16.2.4`（App Router）を使用しました。
 個人的には、プッシュのたびにJSファイルを再生成しなければならないのが嫌いです。これはPRを通じて常にマージ競合のリスクを生み出します。また、このツールはNext.jsよりもViteにフォーカスしているように見えます。
 最後に、他のソリューションと比較して、Paraglideはコンテンツをレンダリングするために現在のロケールを取得するためのストア（例：Reactコンテキスト）を使用しません。パースされる各ノードについて、localStorageやクッキーなどからロケールをリクエストします。これにより、コンポーネントの反応性に影響を与える不要なロジックが実行されます。
 
+> paraglideについての注意：このソリューションは、インポートのためにコードベースにコードを注入します。その結果、ベンチマークレポートの「ライブラリサイズ」指標はほぼ0になります。コード生成は良いことです。なぜなら、使用される関数には必要なロジック（すべてのプレフィックス対プレフィックスなし、クッキー対ストレージなど）のみが含まれるからです。対照的に、Intlayerはビルド時に環境変数を注入して、ロジックに応じてコンテンツをツリーシェイキングするようバンドラーに強制します。このおかげで、paraglideとintlayerは、i18nextやnext-intlよりも6〜10倍軽量なソリューションとなっています。
+
 ### 3 — 許容できるソリューション
 
-**(Tolgee)** (`tolgee@7.0.0`):
+**(Tolgee)** (`@tolgee/react@7.0.0`):
 
 `Tolgee`は前述の問題の多くに対処しています。しかし、同様のツールよりも導入が難しいと感じました。型安全性が提供されていないため、コンパイル時に紛失したキーを見つけることも困難です。キーの不備を検出するために、Tolgeeの関数を自前の関数でラップする必要がありました。
 
@@ -216,7 +225,7 @@ Next.jsのバージョンは`16.2.4`（App Router）を使用しました。
 
 `t()`スタイルのAPIがお好みなら、`next-translate`が私の主な推奨事項です。`next-translate-plugin`を介して優雅に動作し、Webpack / Turbopackローダーを使用して`getStaticProps`経由でネームスペースをロードします。また、今回の中で最も軽量な選択肢です（約2.5kb）。ネームスぺーシングについては、設定ファイルでページやルートごとにネームスペースを定義する方法がよく考えられており、**next-intl**や**next-i18next**のような主要な選択肢よりもメンテナンスが容易です。バージョン`3.1.2`では、静的レンダリングが機能せず、Next.jsが動的レンダリングにフォールバックすることに気づきました。
 
-**(Intlayer)** (`next-intlayer@8.7.5`):
+**(Intlayer)** (`next-intlayer@8.7.12`):
 
 客観性を保つため、自分自身のソリューションである`next-intlayer`については個人的な判断を控えさせていただきます。
 

package/docs/ja/benchmark/solid.md

@@ -0,0 +1,155 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+title: 2026年 Solid向けの最高のi18nソリューション - ベンチマークレポート
+description: solid-primitives、solid-i18next、IntlayerなどのSolid国際化（i18n）ライブラリを比較します。バンドルサイズ、リーク、反応性に関する詳細なパフォーマンスレポート。
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - solid
+  - パフォーマンス
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+  - solid
+author: Aymeric PINEAU
+applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-solid-template
+history:
+  - version: 8.7.12
+    date: 2026-01-06
+    changes: "ベンチマークの初期化"
+---
+
+# Solid i18nライブラリ - 2026年ベンチマークレポート
+
+このページは、Solidにおけるi18nソリューションのベンチマークレポートです。
+
+## 目次
+
+<Toc/>
+
+## インタラクティブベンチマーク
+
+<I18nBenchmark framework="vite-solid" vertical/>
+
+## 結果のリファレンス:
+
+<iframe 
+  src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_solid.md" 
+  width="100%" 
+  height="600px"
+  style="border:none;">
+</iframe>
+
+> https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_solid.md
+
+完全なベンチマークリポジトリは[こちら](https://github.com/intlayer-org/benchmark-i18n/tree/main)でご覧いただけます。
+
+## はじめに
+
+国際化ソリューションは、Solidアプリにおいて最も重い依存関係の一つです。主なリスクは、不必要なコンテンツ（単一のルートのバンドルに含まれる他のページや他のロケールの翻訳）を送信してしまうことです。
+
+アプリが成長するにつれて、この問題はクライアントに送信されるJavaScriptを急速に増大させ、ナビゲーションを遅くする可能性があります。
+
+実際、最適化が不十分な実装では、国際化されたページがi18nなしのバージョンよりも数倍重くなることがあります。
+
+もう一つの影響は、開発者エクスペリエンス（DX）です。コンテンツの宣言方法、型、名前空間の構成、動的ロード、ロケール変更時の反応性などが含まれます。
+
+## TL;DR
+
+- **Intlayer**: 高度な機能と最適化を必要とするプロフェッショナルなSolidアプリケーションに推奨される選択肢（v8.7.12）。
+- **@solid-primitives/i18n**: シンプルなプロジェクトには優れた軽量な代替案ですが、遅延ロードなどの高度な機能に欠けます。
+- **solid-i18next**: 標準的ですが重い選択肢（Intlayerの約4.7倍）で、React i18nextと同じ欠点があります。
+- **Paraglide**: 革新的なアプローチですが、一部のセットアップではDXが複雑で、ツリーシェイキングの問題があります。
+
+## アプリをテストする
+
+i18nリークの問題を素早く特定するために、無料のスキャナーを用意しました。[こちら](https://intlayer.org/i18n-seo-scanner)でお試しいただけます。
+
+<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## 問題点
+
+多言語アプリのコストを抑えるためには、2つのレバーが不可欠です。
+
+- ページ/名前空間ごとにコンテンツを分割し、不要な時に辞書全体をロードしないようにする。
+- 必要な時にだけ、適切なロケールを動的にロードする。
+
+これらのアプローチの技術的限界を理解する：
+
+**動的ロード**
+
+動的ロードがない場合、ほとんどのソリューションは最初のレンダリングからメッセージをメモリに保持するため、ルートやロケールが多いアプリでは大きなオーバーヘッドとなります。
+
+動的ロードを使用する場合、トレードオフを受け入れることになります。初期JSは減りますが、言語切り替え時などに追加のリクエストが発生することがあります。
+
+**コンテンツの分割**
+
+`t('a.b.c')` を中心に構築された構文は非常に便利ですが、実行時に大きなJSONオブジェクトを保持することを助長しがちです。このモデルでは、ライブラリがページごとの分割戦略を提供していない限り、ツリーシェイキングが難しくなります。
+
+## 研究方法
+
+このベンチマークでは、以下のライブラリを比較しました。
+
+- `Base App` (i18nライブラリなし)
+- `solid-intlayer` (v8.7.12)
+- `@solid-primitives/i18n` (v2.2.1)
+- `solid-i18next` (v17.0.2)
+- `@inlang/paraglide-js` (v2.17.0)
+
+フレームワークは `Solid` で、**10ページ**と**10言語**を持つ多言語アプリを使用しました。
+
+**4つのロード戦略**を比較しました。
+
+| 戦略           | 名前空間なし（グローバル）                      | 名前空間あり（スコープ）                                   |
+| :------------- | :---------------------------------------------- | :--------------------------------------------------------- |
+| **静的ロード** | **Static**: 起動時にすべてをメモリに保持。      | **Scoped static**: 名前空間で分割。起動時にすべてロード。  |
+| **動的ロード** | **Dynamic**: ロケールごとのオンデマンドロード。 | **Scoped dynamic**: 名前空間とロケールごとの詳細なロード。 |
+
+## 戦略のまとめ
+
+- **静的（Static）**: シンプル。初期ロード後のネットワーク遅延なし。欠点：バンドルサイズが大きい。
+- **動的（Dynamic）**: 初期重量を削減（遅延ロード）。ロケールが多い場合に理想的。
+- **名前空間付き静的（Scoped static）**: 複雑な追加リクエストなしで、コードを整理（論理的分離）した状態に保つ。
+- **名前空間付き動的（Scoped dynamic）**: コード分割とパフォーマンスのための最善のアプローチ。現在のビューとアクティブなロケールに必要なものだけをロードし、メモリ使用量を最小限に抑える。
+
+## 結果の詳細
+
+### 1 - 避けるべきソリューション
+
+> Solidエコシステムにおいて、明確に避けるべきソリューションはありません。
+
+### 2 - 許容できるソリューション
+
+**(solid-i18next)** (`solid-i18next@17.0.2`):
+
+`solid-i18next` は、JavaScriptアプリのi18nニーズに応えた最初のソリューションの一つであったため、おそらく最も人気のあるオプションです。また、特定の問題を解決するためのコミュニティプラグインも幅広く揃っています。
+
+パッケージは重いです（~14.6kb。これは `solid-intlayer` の約4.7倍です）。
+
+それでも、`t('a.b.c')` 上に構築されたスタックと同じ主要な欠点を共有しています。最適化は可能ですが非常に時間がかかり、大規模なプロジェクトでは悪い習慣（名前空間 + 動的ロード + 型）に陥るリスクがあります。
+
+**(@solid-primitives/i18n)** (`@solid-primitives/i18n@2.2.1`):
+
+Solid primitive は非常に軽量で効率的です。小規模なプロジェクトにはこのソリューションを推奨しますが、クッキー管理、プロキシリダイレクト、フォーマッタなどを含むプロフェッショナルなソリューションには機能が不足しがちです。
+また、ページサイズの最適化のための遅延ロードや名前空間のスコーピングも欠けています。
+
+**(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
+
+`Paraglide` は革新的でよく考えられたアプローチを提供しています。それでも、このベンチマークでは、彼らが宣伝しているツリーシェイキングは私の実装では機能しませんでした。ワークフローとDXも他のオプションより複雑です。
+個人的には、プッシュする前に毎回JSファイルを再生成しなければならないのが好きではありません。
+最後に、他のソリューションと比較して、Paraglide はコンテンツをレンダリングするための現在のロケールを取得するためにストア（例：Solid signal）を使用しません。パースされる各ノードに対して、localStorage / cookie などからロケールを要求します。これにより、コンポーネントの反応性に影響を与える不要なロジックの実行が発生します。
+
+### 3 - 推奨事項
+
+**(Intlayer)** (`solid-intlayer@8.7.12`):
+
+客観性を保つため、`solid-intlayer` については私自身のソリューションであるため、個人的な評価は控えます。
+
+### 個人メモ
+
+このメモは個人的なものであり、ベンチマーク結果には影響しません。それでも、i18nの世界では翻訳されたコンテンツに対して `const t = useTranslation('xx')` + `<>{t('xx.xx')}</>` のようなパターンが一般的です。
+
+Solidアプリにおいて、関数を `JSX.Element` として注入することは、私の考えではアンチパターンです。また、回避可能な複雑さとJavaScriptの実行オーバーヘッド（たとえほとんど目立たなくても）を追加することになります。

package/docs/ja/benchmark/svelte.md

@@ -0,0 +1,148 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+title: 2026年 Svelte向けの最高のi18nソリューション - ベンチマークレポート
+description: svelte-i18n、Paraglide、IntlayerなどのSvelte国際化（i18n）ライブラリを比較します。バンドルサイズ、リーク、反応性に関する詳細なパフォーマンスレポート。
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - svelte
+  - パフォーマンス
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+  - svelte
+author: Aymeric PINEAU
+applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-svelte-template
+history:
+  - version: 8.7.12
+    date: 2026-01-06
+    changes: "ベンチマークの初期化"
+---
+
+# Svelte i18nライブラリ - 2026年ベンチマークレポート
+
+このページは、Svelteにおけるi18nソリューションのベンチマークレポートです。
+
+## 目次
+
+<Toc/>
+
+## インタラクティブベンチマーク
+
+<I18nBenchmark framework="vite-svelte" vertical/>
+
+## 結果のリファレンス:
+
+<iframe 
+  src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_svelte.md" 
+  width="100%" 
+  height="600px"
+  style="border:none;">
+</iframe>
+
+> https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_svelte.md
+
+完全なベンチマークリポジトリは[こちら](https://github.com/intlayer-org/benchmark-i18n/tree/main)でご覧いただけます。
+
+## はじめに
+
+国際化ソリューションは、Svelteアプリにおいて最も重い依存関係の一つです。主なリスクは、不必要なコンテンツ（単一のルートのバンドルに含まれる他のページや他のロケールの翻訳）を送信してしまうことです。
+
+アプリが成長するにつれて、この問題はクライアントに送信されるJavaScriptを急速に増大させ、ナビゲーションを遅くする可能性があります。
+
+実際、最適化が不十分な実装では、国際化されたページがi18nなしのバージョンよりも数倍重くなることがあります。
+
+もう一つの影響は、開発者エクスペリエンス（DX）です。コンテンツの宣言方法、型、名前空間の構成、動的ロード、ロケール変更時の反応性などが含まれます。
+
+## TL;DR
+
+- **Intlayer**: 最もパフォーマンス効率が高く、フットプリントが最も小さい選択肢（v8.7.12）。
+- **Paraglide**: ツリーシェイキング（tree-shaking）の強力な候補ですが、開発者エクスペリエンスがより複雑で、反応性のオーバーヘッドがあります。
+- **svelte-i18n**: Svelte向けの標準的で機能が充実したソリューションですが、バンドル重量が非常に大きくなります（Intlayerの約7倍）。
+
+## アプリをテストする
+
+i18nリークの問題を素早く特定するために、無料のスキャナーを用意しました。[こちら](https://intlayer.org/i18n-seo-scanner)でお試しいただけます。
+
+<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## 問題点
+
+多言語アプリのコストを抑えるためには、2つのレバーが不可欠です。
+
+- ページ/名前空間ごとにコンテンツを分割し、不要な時に辞書全体をロードしないようにする。
+- 必要な時にだけ、適切なロケールを動的にロードする。
+
+これらのアプローチの技術的限界を理解する：
+
+**動的ロード**
+
+動的ロードがない場合、ほとんどのソリューションは最初のレンダリングからメッセージをメモリに保持するため、ルートやロケールが多いアプリでは大きなオーバーヘッドとなります。
+
+動的ロードを使用する場合、トレードオフを受け入れることになります。初期JSは減りますが、言語切り替え時などに追加のリクエストが発生することがあります。
+
+**コンテンツの分割**
+
+`t('a.b.c')` を中心に構築された構文は非常に便利ですが、実行時に大きなJSONオブジェクトを保持することを助長しがちです。このモデルでは、ライブラリがページごとの分割戦略を提供していない限り、ツリーシェイキングが難しくなります。
+
+## 研究方法
+
+このベンチマークでは、以下のライブラリを比較しました。
+
+- `Base App` (i18nライブラリなし)
+- `svelte-intlayer` (v8.7.12)
+- `svelte-i18n` (v4.0.1)
+- `@inlang/paraglide-js` (v2.17.0)
+
+フレームワークは `Svelte` で、**10ページ**と**10言語**を持つ多言語アプリを使用しました。
+
+**4つのロード戦略**を比較しました。
+
+| 戦略           | 名前空間なし（グローバル）                      | 名前空間あり（スコープ）                                   |
+| :------------- | :---------------------------------------------- | :--------------------------------------------------------- |
+| **静的ロード** | **Static**: 起動時にすべてをメモリに保持。      | **Scoped static**: 名前空間で分割。起動時にすべてロード。  |
+| **動的ロード** | **Dynamic**: ロケールごとのオンデマンドロード。 | **Scoped dynamic**: 名前空間とロケールごとの詳細なロード。 |
+
+## 戦略のまとめ
+
+- **静的（Static）**: シンプル。初期ロード後のネットワーク遅延なし。欠点：バンドルサイズが大きい。
+- **動的（Dynamic）**: 初期重量を削減（遅延ロード）。ロケールが多い場合に理想的。
+- **名前空間付き静的（Scoped static）**: 複雑な追加リクエストなしで、コードを整理（論理的分離）した状態に保つ。
+- **名前空間付き動的（Scoped dynamic）**: コード分割とパフォーマンスのための最善のアプローチ。現在のビューとアクティブなロケールに必要なものだけをロードし、メモリ使用量を最小限に抑える。
+
+## 結果の詳細
+
+### 1 - 避けるべきソリューション
+
+> Svelteエコシステムにおいて、明確に避けるべきソリューションはありません。
+
+### 2 - 許容できるソリューション
+
+**(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
+
+`Paraglide` は革新的でよく考えられたアプローチを提供しています。Vite + Svelte アプリの文脈では、彼らが宣伝しているツリーシェイキングは期待通りに機能しており、素晴らしいことです。
+しかし、React + TanStack Start の場合、ツリーシェイキングは期待通りに機能せず、Next.jsでも同様でした。とはいえ、Svelte および TanStack Start プロジェクトにおける Paraglide の使用は再確認する価値があるでしょう。
+ワークフローとDXも他のオプションより複雑です。
+個人的には、プッシュする前に毎回JSファイルを再生成しなければならないのが好きではありません。これはPRを通じた開発者間の絶え間ないマージコンフリクトのリスクを生みます。また、このツールはNext.jsよりもViteに重点を置いているようです。
+最後に、他のソリューションと比較して、Paraglide はコンテンツをレンダリングするための現在のロケールを取得するためにストア（例：Svelte store）を使用しません。パースされる各ノードに対して、localStorage / cookie などからロケールを要求します。これにより、コンポーネントの反応性に影響を与える不要なロジックの実行が発生します。
+
+> paraglideに関する注意：このソリューションはインポートのためにコードベースにコードを注入するため、ベンチマークレポートの「ライブラリサイズ（lib size）」メトリックはほぼ0になります。コード生成は、使用される関数に必要なロジック（接頭辞あり vs 接頭辞なし、クッキー vs ストレージなど）のみが含まれるため、良いことです。比較すると、Intlayer はビルド時に環境変数を注入することでこのフィルタリングを行い、ロジックに応じてコンテンツをツリーシェイクするようにバンドラーに強制します。このおかげで、paraglide と intlayer は i18next や next-intl よりも 6〜10倍軽量なソリューションとなります。
+
+**(svelte-i18n)** (`svelte-i18n@3.4.0`):
+
+このソリューションは、Svelteプロジェクトにおけるi18nのすべてのニーズに応えます。しかし、i18nextや他の主要なi18nソリューションと同様に、少し重いです（~15.9kb。これは `svelte-intlayer` の約7倍です）。
+
+### 3 - 推奨事項
+
+**(Intlayer)** (`svelte-intlayer@8.7.12`):
+
+客観性を保つため、`svelte-intlayer` については私自身のソリューションであるため、個人的な評価は控えます。
+
+### 個人メモ
+
+このメモは個人的なものであり、ベンチマーク結果には影響しません。それでも、i18nの世界では翻訳されたコンテンツに対して `const t = useTranslation('xx')` + `<>{t('xx.xx')}</>` のようなパターンが一般的です。
+
+Svelteアプリにおいて、関数を `Slot` として注入することは、私の考えではアンチパターンです。また、回避可能な複雑さとJavaScriptの実行オーバーヘッド（たとえほとんど目立たなくても）を追加することになります。

package/docs/ja/benchmark/tanstack.md

@@ -57,6 +57,13 @@ history:
 
 もう一つの影響は開発体験（DX）への影響です。コンテンツの宣言方法、型、ネームスペースの構成、動的ロード、およびロケール変更時の反応性などが挙げられます。
 
+## TL;DR
+
+- **Intlayer**: TanStack Startにおいて最高のパフォーマンスと最小のバンドルサイズ（v8.7.12）を提供します。
+- **react-i18next** & **use-intl**: 大規模なエコシステムを持つ成熟した代替案ですが、大幅に重く、最適化がより複雑です。
+- **Paraglide**: 革新的なツリーシェイキングのアイデアですが、実際には機能しません。TanStack StartにおいてはDXが複雑で、反応性のオーバーヘッドがあります。
+- **避けるべき**: **General Translation (GT)** と **Lingo.dev**。深刻なパフォーマンスの問題、AIクォータの制限、およびベンダーロックインのためです。
+
 ## アプリをテストする
 
 i18nのリーク問題を素早く特定するために、無料のスキャナーを用意しました。[こちら](https://intlayer.org/i18n-seo-scanner)で利用可能です。
@@ -87,12 +94,12 @@ i18nのリーク問題を素早く特定するために、無料のスキャナ
 このベンチマークでは、以下のライブラリを比較しました。
 
 - `Base App`（i18nライブラリなし）
-- `react-intlayer` (v8.7.5-canary.0)
+- `react-intlayer` (v8.7.12)
 - `react-i18next` (v17.0.2)
 - `use-intl` (v4.9.1)
 - `@lingui/core` (v5.3.0)
 - `@inlang/paraglide-js` (v2.15.1)
-- `tolgee` (v7.0.0)
+- `@tolgee/react` (v7.0.0)
 - `react-intl` (v10.1.1)
 - `wuchale` (v0.22.11)
 - `gt-react` (vlatest)
@@ -150,7 +157,9 @@ i18nのリーク問題を素早く特定するために、無料のスキャナ
 
 `Paraglide`は革新的でよく考えられたアプローチを提供しています。それにもかかわらず、このベンチマークでは、Next.jsの実装やTanStack Startにおいて、彼らが宣伝していたツリーシェイキングは機能しませんでした。ワークフローとDXも他の選択肢より複雑です。個人的には、プッシュのたびにJSファイルを再生成しなければならないのが好きではありません。これはPRを通じて常にマージ競合のリスクを生み出します。
 
-**(Tolgee)** (`tolgee@7.0.0`):
+> paraglideに関する注意：このソリューションはインポートのためにコードベースにコードを注入するため、ベンチマークレポートの「lib size」メトリクスはほぼ0になります。コード生成は、使用される関数に必要なロジック（すべてのプレフィックス対プレフィックスなし、クッキー対ストレージなど）のみが含まれるため、良いことです。対照的に、Intlayerはビルド時に環境変数を注入してこのフィルタリングを行い、ロケールに応じたコンテンツをバンドラーにツリーシェイクさせます。このおかげで、paraglideとintlayerは、i18nextやnext-intlよりも6〜10倍軽量なソリューションとなります。
+
+**(Tolgee)** (`@tolgee/react@7.0.0`):
 
 `Tolgee`は前述の問題の多くに対処しています。しかし、同様のアプローチを持つ他のツールよりも導入が難しいと感じました。型安全性が提供されていないため、コンパイル時に紛失したキーを見つけることが非常に困難です。キーの不備を検出するために、TolgeeのAPIを自前のAPIでラップする必要がありました。
 

package/docs/ja/benchmark/vue.md

@@ -0,0 +1,160 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+title: 2026年 Vue向けの最高のi18nソリューション - ベンチマークレポート
+description: vue-i18n、fluent-vue、IntlayerなどのVue国際化（i18n）ライブラリを比較します。バンドルサイズ、リーク、反応性に関する詳細なパフォーマンスレポート。
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - vue
+  - パフォーマンス
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+  - vue
+author: Aymeric PINEAU
+applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-vue-template
+history:
+  - version: 8.7.12
+    date: 2026-01-06
+    changes: "ベンチマークの初期化"
+---
+
+# Vue i18nライブラリ - 2026年ベンチマークレポート
+
+このページは、Vueにおけるi18nソリューションのベンチマークレポートです。
+
+## 目次
+
+<Toc/>
+
+## インタラクティブベンチマーク
+
+<I18nBenchmark framework="vite-vue" vertical/>
+
+## 結果のリファレンス:
+
+<iframe 
+  src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_vue.md" 
+  width="100%" 
+  height="600px"
+  style="border:none;">
+</iframe>
+
+> https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_vue.md
+
+完全なベンチマークリポジトリは[こちら](https://github.com/intlayer-org/benchmark-i18n/tree/main)でご覧いただけます。
+
+## はじめに
+
+国際化ソリューションは、Vueアプリにおいて最も重い依存関係の一つです。主なリスクは、不必要なコンテンツ（単一のルートのバンドルに含まれる他のページや他のロケールの翻訳）を送信してしまうことです。
+
+アプリが成長するにつれて、この問題はクライアントに送信されるJavaScriptを急速に増大させ、ナビゲーションを遅くする可能性があります。
+
+実際、最適化が不十分な実装では、国際化されたページがi18nなしのバージョンよりも数倍重くなることがあります。
+
+もう一つの影響は、開発者エクスペリエンス（DX）です。コンテンツの宣言方法、型、名前空間の構成、動的ロード、ロケール変更時の反応性などが含まれます。
+
+## TL;DR
+
+- **Intlayer**: スコーピング（scoping）と動的ロードを内蔵した、最も軽量なソリューション（v8.7.12）。
+- **vue-i18n**: 豊かなエコシステムを持つ業界標準ですが、非常に重くなる可能性があり、大規模アプリケーションでのコード分割の最適化が難しい場合があります。
+- **fluent-vue**: 革新的なメッセージ構成ですが、型安全性が欠けており、非常に重いソリューションです。
+
+## アプリをテストする
+
+i18nリークの問題を素早く特定するために、無料のスキャナーを用意しました。[こちら](https://intlayer.org/i18n-seo-scanner)でお試しいただけます。
+
+<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## 問題点
+
+多言語アプリのコストを抑えるためには、2つのレバーが不可欠です。
+
+- ページ/名前空間ごとにコンテンツを分割し、不要な時に辞書全体をロードしないようにする。
+- 必要な時にだけ、適切なロケールを動的にロードする。
+
+これらのアプローチの技術的限界を理解する：
+
+**動的ロード**
+
+動的ロードがない場合、ほとんどのソリューションは最初のレンダリングからメッセージをメモリに保持するため、ルートやロケールが多いアプリでは大きなオーバーヘッドとなります。
+
+動的ロードを使用する場合、トレードオフを受け入れることになります。初期JSは減りますが、言語切り替え時などに追加のリクエストが発生することがあります。
+
+**コンテンツの分割**
+
+`const { t } = useI18n()` + `t('a.b.c')` を中心に構築された構文は非常に便利ですが、実行時に大きなJSONオブジェクトを保持することを助長しがちです。このモデルでは、ライブラリがページごとの分割戦略を提供していない限り、ツリーシェイキング（tree-shaking）が難しくなります。
+
+## 研究方法
+
+このベンチマークでは、以下のライブラリを比較しました。
+
+- `Base App` (i18nライブラリなし)
+- `vue-intlayer` (v8.7.12)
+- `vue-i18n` (v11.4.0)
+- `fluent-vue` (v3.8.2)
+
+フレームワークは `Vue` で、**10ページ**と**10言語**を持つ多言語アプリを使用しました。
+
+**4つのロード戦略**を比較しました。
+
+| 戦略           | 名前空間なし（グローバル）                      | 名前空間あり（スコープ）                                   |
+| :------------- | :---------------------------------------------- | :--------------------------------------------------------- |
+| **静的ロード** | **Static**: 起動時にすべてをメモリに保持。      | **Scoped static**: 名前空間で分割。起動時にすべてロード。  |
+| **動的ロード** | **Dynamic**: ロケールごとのオンデマンドロード。 | **Scoped dynamic**: 名前空間とロケールごとの詳細なロード。 |
+
+## 戦略のまとめ
+
+- **静的（Static）**: シンプル。初期ロード後のネットワーク遅延なし。欠点：バンドルサイズが大きい。
+- **動的（Dynamic）**: 初期重量を削減（遅延ロード）。ロケールが多い場合に理想的。
+- **名前空間付き静的（Scoped static）**: 複雑な追加リクエストなしで、コードを整理（論理的分離）した状態に保つ。
+- **名前空間付き動的（Scoped dynamic）**: コード分割とパフォーマンスのための最善のアプローチ。現在のビューとアクティブなロケールに必要なものだけをロードし、メモリ使用量を最小限に抑える。
+
+### 測定項目：
+
+各スタックについて実際のブラウザで同じ多言語アプリを実行し、実際にネットワーク上を流れたデータ量と時間を記録しました。サイズは**通常のWeb圧縮後**の数値です。これは、生のソースコード量よりもユーザーが実際にダウンロードする量に近いからです。
+
+- **i18nライブラリのサイズ**: バンドル、ツリーシェイキング、ミニファイ後のi18nライブラリのサイズです。空のコンポーネントにおけるプロバイダーやコンポーザブル（composables）のコードサイズを指し、翻訳ファイルのロードは含みません。コンテンツが入る前に、ライブラリ自体がどれほど「高価」であるかを示します。
+
+- **1ページあたりのJavaScript**: 各ベンチマークルートにおいて、ブラウザが読み込むスクリプトの量です。テストスイート内のページの平均値（およびロケールごとの平均値）です。重いページは遅いページです。
+
+- **他のロケールからのリーク（Leakage）**: 同じページの内容ですが、別の言語のコンテンツが誤って監査対象のページにロードされてしまうことです。このコンテンツは不要であり、避けるべきです（例：`/en/about` ページのバンドルに含まれる `/fr/about` ページの内容）。
+
+- **他のルートからのリーク**: アプリ内の**他の画面**についても同様です。1つのページしか開いていないのに、他の画面のテキストが一緒に運ばれていないかを示します（例：`/en/contact` ページのバンドルに含まれる `/en/about` ページの内容）。数値が高い場合は、分割が不十分であるか、バンドルが広範すぎることを示唆しています。
+
+- **コンポーネントの平均バンドルサイズ**: 一般的なUI要素を**一つずつ**測定します。これにより、国際化が日常的なコンポーネントをひっそりと肥大化させていないかを確認できます。例えば、コンポーネントが再レンダリングされる際、それらすべてのデータをメモリからロードすることになります。巨大なJSONをコンポーネントに紐付けることは、未使用のデータの大きなストアを接続するようなもので、コンポーネントのパフォーマンスを低下させます。
+
+- **言語切り替えの反応性**: アプリ自身のコントロールを使用して言語を切り替え、ページが明確に切り替わるまでの時間を測定します。これはユーザーが気づく時間です。
+
+- **言語変更後のレンダリング作業**: 言語が切り替わり始めた後に、インターフェースが新しい言語で再描画するために費やした労力です。「体感」時間とフレームワークのコストが異なる場合に役立ちます。
+
+- **初期ページロード時間**: ナビゲーションから、ブラウザがページを完全にロードしたと判断するまでの時間です。コールドスタートの比較に役立ちます。
+
+- **ハイドレーション時間（Hydration）**: クライアントがサーバーからのHTMLをインタラクティブなものに変えるのに費やす時間です。表内のダッシュ（-）は、その実装がこのベンチマークで信頼できるハイドレーションの数値を提供しなかったことを意味します。
+
+## 結果の詳細
+
+### 1 - 避けるべきソリューション
+
+> Vueエコシステムにおいて、明確に避けるべきソリューションはありません。
+
+### 2 - 許容できるソリューション
+
+**(vue-i18n)** (`vue-i18n@11.4.0`):
+
+- **vue-i18n** は間違いなくVueで最も使用されているi18nライブラリであり、多くの機能と巨大なエコシステムを持っています。しかし、内部的にはかなり重いソリューションです。メッセージの遅延ロードを統合していても、スコーピング（scoping）機能が欠けています。標準的なVue SPAアプリの場合は問題ありませんが、@nuxt/i18nを使用するNuxtアプリの場合、すべてのページのメッセージが単一のページに含まれてしまうことになります。10ページを超える大規模なNuxtアプリでは、これが深刻な問題になる可能性があります。
+
+パッケージは非常に重いです（~24.3kb。これは `vue-intlayer` の約9倍です）。
+
+**(fluent-vue)** (`fluent-vue@0.5.0`):
+
+- **fluent-vue** は .ftl 形式を通じて革新を試みています。メッセージの構成は素晴らしく、始めやすいです。しかし実際には、型安全性の欠如によりエラーのリスクが高まり、デバッグに時間がかかる可能性があります。さらに、このソリューションはViteプラグインを使用してメッセージをロードしますが、これによりすべての言語の全コンテンツが各ページに強制的にロードされます。加えて、これは極めて重いソリューションです（~92.7kb。これは `vue-intlayer` の約34倍です）。
+
+### 3 - 推奨事項
+
+**(Intlayer)** (`vue-intlayer@8.7.12`):
+
+客観性を保つため、`vue-intlayer` については私自身のソリューションであるため、個人的な評価は控えます。