@intlayer/docs 9.4.2 → 9.4.4

package/blog/ja/is_vue-i18n_outdated.md

@@ -0,0 +1,338 @@
+---
+createdAt: 2026-09-02
+updatedAt: 2026-09-02
+title: 2026年においてvue-i18nは時代遅れなのか？
+description: vue-i18nは10年以上にわたりVueとNuxtの標準として親しまれてきました。しかしベンチマークではWebで最も重いi18nランタイムという結果に。その理由を紐解きます。
+keywords:
+  - vue-i18n
+  - Intlayer
+  - 国際化
+  - i18n
+  - Vue
+  - Nuxt
+  - バンドルサイズ
+  - ブログ
+slugs:
+  - blog
+  - is-vue-i18n-outdated
+author: aymericzip
+---
+
+# 2026年においてvue-i18nは時代遅れなのか？
+
+Vueエコシステムにおいて、`vue-i18n`ほど広く定着したライブラリは他にありません。Vue 2時代からKazupon氏を中心に開発が続けられ、`@nuxtjs/i18n`の基盤としても採用されており、多言語対応Vueプロジェクトの第一候補となってきました。
+
+しかし2026年のベンチマーク検証により、意外な事実が判明しました。**`vue-i18n`は、検証したすべての主要フロントエンドフレームワークの中で最も重いローカライズランタイムだったのです。**
+
+Vite + Vueで構築した素の初期状態（31.5 KB）に`vue-i18n`を導入したところ、ページあたりの平均JavaScriptサイズは**136.4 KB**に達し、元の4倍以上に膨らみました。
+
+軽量さを売りにするフレームワークで、なぜ国際化ツールがこれほど巨大になってしまうのでしょうか？そして従来のランタイム指向モデルは今も通用するのでしょうか？
+
+<TOC/>
+
+## 主なポイント
+
+**検証中もっとも重いランタイム:**
+
+テキストを追加する前の状態で**24.3 KB（gzip圧縮後、Minifiedで83.2 KB）**あり、`intlayer`のコアランタイム（2.7 KB）と比較して**約9倍のサイズ**です。
+
+**ページ容量が330%増加:**
+
+`vue-i18n`によって初期31.5 KBだったVueページが136.4 KBまで膨張しました。対照的にIntlayerは59.3 KBにとどまり、**56%軽量なペイロード**を実現します。
+
+**ブラウザ内に含まれるコンパイラ:**
+
+バンドラーで適切なエイリアス設定を行わない限り、`vue-i18n`はブラウザ上で文字列を解析するためにフルスペックのメッセージコンパイラをクライアントへ送り込みます。
+
+**更新ペースの現状:**
+
+過去1年間で`vue-i18n`のコミットは約259回行われましたが、主にバグ修正とVueのマイナー追従が中心です。
+
+**次世代開発ツールの不在:**
+
+Language Server（LSP）、AI向けMCPサーバー、CLIを通じた自動翻訳パイプラインなど、公式の現代的ツールが揃っていません。
+
+## 保守状況と現代ツールの比較
+
+| リポジトリ            | スター数                                                                                                                                               | 総コミット数                                                                                                                                                        | 年間コミット数                                                                                                                                                     | 最終コミット                                                                                                                                 |
+| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------- |
+| `intlify/vue-i18n`    | [![stars](https://img.shields.io/github/stars/intlify/vue-i18n?style=for-the-badge&label=stars)](https://github.com/intlify/vue-i18n/stargazers)       | [![commits](https://img.shields.io/github/commit-activity/t/intlify/vue-i18n?style=for-the-badge&label=commits)](https://github.com/intlify/vue-i18n/commits)       | [![yearly](https://img.shields.io/github/commit-activity/y/intlify/vue-i18n?style=for-the-badge&label=%2Fyear)](https://github.com/intlify/vue-i18n/commits)       | [![last](https://img.shields.io/github/last-commit/intlify/vue-i18n?style=for-the-badge)](https://github.com/intlify/vue-i18n/commits)       |
+| `aymericzip/intlayer` | [![stars](https://img.shields.io/github/stars/aymericzip/intlayer?style=for-the-badge&label=stars)](https://github.com/aymericzip/intlayer/stargazers) | [![commits](https://img.shields.io/github/commit-activity/t/aymericzip/intlayer?style=for-the-badge&label=commits)](https://github.com/aymericzip/intlayer/commits) | [![yearly](https://img.shields.io/github/commit-activity/y/aymericzip/intlayer?style=for-the-badge&label=%2Fyear)](https://github.com/aymericzip/intlayer/commits) | [![last](https://img.shields.io/github/last-commit/aymericzip/intlayer?style=for-the-badge)](https://github.com/aymericzip/intlayer/commits) |
+
+過去12か月間の実績:
+
+- `intlify/vue-i18n`: **259コミット**（Vue 3およびNuxt向けの定期保守）。
+- `aymericzip/intlayer`: **4,343コミット**（コンパイラ最適化、LSP機能、AI連携ツールの継続開発）。
+
+[![Star History Chart](https://api.star-history.com/chart?repos=intlify%2Fvue-i18n%2Caymericzip%2Fintlayer&type=date&legend=top-left)](https://www.star-history.com/#intlify/vue-i18n&aymericzip/intlayer)
+
+歴史あるライブラリには安定性の利点があります。しかし近年の開発手法は、ビルド時のAST解析、デッドコード除去、AIによる自動化を前提としています。クライアント上での実行に依存するアーキテクチャでは、こうした進化を取り入れるのが難しくなります。
+
+## Vite + Vueでの性能測定
+
+ViteとVue 3による10ページ、10言語構成のアプリケーションで測定:
+
+<I18nBenchmark framework="vite-vue" vertical/>
+
+<ClickToOpenIframe
+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;"
+/>
+
+> 実ブラウザ環境で本番用gzip圧縮を適用して計測。詳細は[Vueベンチマークドキュメント](https://intlayer.org/ja/doc/benchmark/vue)をご覧ください。
+
+### 初期ライブラリのサイズ
+
+翻訳テキストを読み込む前のフットプリント:
+
+| ライブラリ        | Gzip圧縮後 | Minified   |
+| ----------------- | ---------- | ---------- |
+| `vue-i18n@11.4.0` | 24.3 KB    | 83.2 KB    |
+| `intlayer@8.7.12` | **2.7 KB** | **7.6 KB** |
+
+`vue-i18n`のランタイムだけで**24.3 KB（gzip圧縮後）**を占め、Vueのコア全体に近い容量です。これに対してIntlayerはわずか**2.7 KB**にとどまります。
+
+### ページサイズと不要データの混入率
+
+| 構成               | 平均ページJS (gz) | 他言語混入率 | 他ページ混入率 | 平均コンポーネント (gz) |
+| ------------------ | ----------------- | ------------ | -------------- | ----------------------- |
+| ベース（i18nなし） | 31.5 KB           | 0.0%         | 90.0%          | 0.9 KB                  |
+| `vue-i18n`         | **136.4 KB**      | 50.2%        | 90.0%          | 196.0 KB                |
+| Intlayer           | **59.3 KB**       | 51.1%        | **0.0%**       | **6.5 KB**              |
+
+### 主な分析結果
+
+**相対的な増大率の高さ:**
+
+Vue自体のフットプリントが非常に小さいため（約31 KB）、`vue-i18n`を追加することでページ全体の容量が4倍以上に跳ね上がります。
+
+**他ページ翻訳の混入:**
+
+デフォルト設定では、特定のルートに届く**テキストデータの90%**が他のページ用です。Intlayerはこれをビルド時に完全に排除し、**0.0%**に抑えます。
+
+**スコープ付きコンポーネントの肥大化:**
+
+辞書が重複してバンドルされるため、`vue-i18n`を使ったスコープ付きコンポーネントの平均サイズは196 KBに達しました。一方、Intlayerでは**6.5 KB**です。
+
+## なぜvue-i18nは重いのか？
+
+### ブラウザへ同梱されるASTコンパイラ
+
+`vue-i18n`はメッセージフォーマット用の独自コンパイラを内蔵しています。複数形判定や変数置換を、ブラウザの実行時に構文木（AST）へ変換して解釈します。
+
+これを回避するには、バンドラー設定で`vue-i18n/dist/vue-i18n.runtime.esm-bundler.js`へのエイリアスを指定し、`@intlify/unplugin-vue-i18n`を用いて事前コンパイルを行う必要がありますが、多くのプロジェクトで見落とされています。
+
+### モノリシックな多機能設計
+
+日付・数値フォーマッター、リンクメッセージ、旧来のOptions API向けブリッジ（`$t`, `v-t`）、リアクティブプロキシなどが一体となっています。`<script setup>`内でごく単純なテキストを表示したいだけであっても、すべての機能群が読み込まれます。
+
+### 動的キーによるTree-shakingの阻害
+
+`"home.hero.title"`が実行時に解釈されるため、バンドラーはどのキーが実際に使用されているかを追跡できません。不要なテキストもそのままバンドル内に残存します。
+
+<Tabs defaultTab="intlayer" group="techno">
+  <Tab label="vue-i18n" value="vue-i18n">
+
+```vue fileName="Hero.vue"
+<script setup>
+import { useI18n } from "vue-i18n";
+
+const { t } = useI18n();
+</script>
+
+<template>
+  <h1>{{ t("home.hero.title") }}</h1>
+</template>
+```
+
+  </Tab>
+  <Tab label="Intlayer" value="intlayer">
+
+```vue fileName="Hero.vue"
+<script setup>
+import { useIntlayer } from "vue-intlayer";
+
+const { title } = useIntlayer("hero");
+</script>
+
+<template>
+  <h1>{{ title }}</h1>
+</template>
+```
+
+  </Tab>
+</Tabs>
+
+[Intlayerコンパイラ](https://intlayer.org/ja/doc/compiler)はアクセスされたプロパティを正確に追跡し、クライアント用チャンクをビルドする前に未使用データをカットします。詳細は[バンドル最適化](https://intlayer.org/ja/doc/concept/bundle-optimization)をご覧ください。
+
+## 開発体験（DX）の比較
+
+### 分離されたJSONとコンポーネント共配置
+
+`vue-i18n`では翻訳文が遠く離れた`locales/`フォルダに保存されます。Intlayerならコンポーネントのすぐ隣にコンテンツファイルを配置できます。
+
+<Tabs defaultTab="intlayer" group="techno">
+  <Tab label="vue-i18n" value="vue-i18n">
+
+```json fileName="locales/en.json"
+{
+  "hero": {
+    "title": "Ship in every language"
+  }
+}
+```
+
+```json fileName="locales/ja.json"
+{
+  "hero": {
+    "title": "あらゆる言語でリリースしよう"
+  }
+}
+```
+
+```vue fileName="Hero.vue"
+<script setup>
+import { useI18n } from "vue-i18n";
+
+const { t } = useI18n();
+</script>
+
+<template>
+  <h1>{{ t("hero.title") }}</h1>
+</template>
+```
+
+  </Tab>
+  <Tab label="Intlayer" value="intlayer">
+
+```ts fileName="Hero.content.ts"
+import { t, type Dictionary } from "intlayer";
+
+export default {
+  key: "hero",
+  content: {
+    title: t({
+      en: "Ship in every language",
+      ja: "あらゆる言語でリリースしよう",
+    }),
+  },
+} satisfies Dictionary;
+```
+
+```vue fileName="Hero.vue"
+<script setup>
+import { useIntlayer } from "vue-intlayer";
+
+const { title } = useIntlayer("hero");
+</script>
+
+<template>
+  <h1>{{ title }}</h1>
+</template>
+```
+
+  </Tab>
+</Tabs>
+
+`Hero.vue`をリネームまたは削除すれば、対応するコンテンツ定義も連動して処理されます。
+
+### エディタ補完と厳密な完全性の違い
+
+`DefineLocaleMessage`を使用すればエディタ上でキーの候補が表示されます。しかし全言語の網羅性まではチェックされません。`ja.json`からキーが欠落していてもTypeScriptはビルドを止めません。
+
+Intlayerでは辞書の内容が厳密に検証されます。[`strictMode`](https://intlayer.org/ja/doc/concept/configuration)を有効にすれば、いずれかの言語で翻訳が不足している場合にビルドエラーが発生します。
+
+### エディタおよびAIツールのサポート
+
+| ツール                            | `vue-i18n`          | Intlayer                                                              |
+| --------------------------------- | ------------------- | --------------------------------------------------------------------- |
+| **VS Code拡張機能**               | 有志製（i18n Ally） | ✅ [公式拡張機能](https://intlayer.org/ja/doc/vs-code-extension)      |
+| **Language Server (LSP)**         | ❌ なし             | ✅ [専用LSP](https://intlayer.org/ja/doc/lsp)                         |
+| **AI用MCPサーバー**               | ❌ なし             | ✅ [内蔵MCPサーバー](https://intlayer.org/ja/doc/mcp-server)          |
+| **エージェントスキル**            | ❌ なし             | ✅ [自律型スキル](https://intlayer.org/ja/doc/agent_skills)           |
+| **インコンテキストビジュアルCMS** | ❌ なし             | ✅ [無料・オープンソース](https://intlayer.org/ja/doc/concept/editor) |
+
+## 翻訳ワークフロー
+
+`vue-i18n`には翻訳を自動生成するコマンドがありません。外部のCrowdinやPhrase等へファイルを送るのが通例です。
+
+Intlayerは自前のツールチェーンを提供しています。
+
+**ローカルAI翻訳機能（`intlayer fill`）:**
+
+自身のOpenAI、Anthropic、Mistral、GeminiのAPIキーを使って、不足しているキーを自動翻訳します。
+
+**セルフホスト対応ビジュアルCMS:**
+
+[Intlayer CMS](https://intlayer.org/ja/doc/concept/cms)を起動し、非エンジニアのメンバーがWeb上で修正した内容を直接Gitに保存できます。
+
+**オープンソースライセンス:**
+
+すべてのツールがApache 2.0ライセンスで利用可能です。
+
+## 今もvue-i18nが選択肢となるケース
+
+<AccordionGroup>
+<Accordion header="稼働中のNuxt 2/3大規模プロダクト">
+
+ルーティングが`@nuxtjs/i18n`と緊密に結合している場合、システム刷新のコストが見合わないことがあります。
+
+</Accordion>
+<Accordion header="複雑なICUフォーマットを駆使している場合">
+
+多重ネストされたメッセージリンクや高度な数値・日付フォーマットを多用している環境。
+
+</Accordion>
+<Accordion header="個人開発や小規模な検証プロジェクト">
+
+バンドルサイズがUXやビジネス成果に大きく影響しないケース。
+
+</Accordion>
+</AccordionGroup>
+
+## 既存のvue-i18n環境を向上させるには？
+
+Intlayerは、`vue-i18n`および`@nuxtjs/i18n`の関数シグネチャ（`useI18n`、`$t`、`<i18n-t>`）をそのまま再現するドロップイン互換パッケージを提供しています。テンプレートやComposableを書き換えることなく、コンパイラ主導の軽量アーキテクチャの恩恵を受けることができます。
+
+導入はコマンド1行で完了します:
+
+```bash packageManager="npm"
+npx intlayer init --interactive
+```
+
+```bash packageManager="pnpm"
+pnpm dlx intlayer init --interactive
+```
+
+```bash packageManager="yarn"
+yarn dlx intlayer init --interactive
+```
+
+```bash packageManager="bun"
+bunx intlayer init --interactive
+```
+
+この対話型CLIは以下の作業を自動で行います:
+
+1. `@intlayer/vue-i18n`または`@intlayer/nuxt-i18n`互換パッケージをインストール。
+2. ViteまたはNuxtバンドラーのエイリアスを設定し、既存のインポートやテンプレート記述をシームレスにIntlayerへルーティング。これにより`vue-i18n`を`package.json`から安全に削除できます。
+3. Language Server（LSP）診断の即時有効化、クライアントバンドルからの24KB ASTパーサーの完全排除、ローカルAI翻訳ワークフローを大規模なリファクタリングなしで利用可能にします。
+
+詳しい手順については、以下のガイドをご覧ください:
+
+- **互換レイヤーの活用:** [`vue-i18n`互換レイヤー](https://intlayer.org/ja/doc/compatibility/vue-i18n)または[`@nuxtjs/i18n`互換レイヤー](https://intlayer.org/ja/doc/compatibility/nuxtjs-i18n)を使うことで、既存のテンプレートを維持したまま導入できます。
+- **移行ガイドライン:** 既存のJSONファイルを型付き辞書へ移行するためのドキュメントを用意しています。[vue-i18nからの移行](https://intlayer.org/ja/doc/migration/vue-i18n)、[@nuxtjs/i18nからの移行](https://intlayer.org/ja/doc/migration/nuxtjs-i18n)。
+- **ハイブリッド構成:** ランタイムとして`vue-i18n`を使い続けながら、[Intlayerとvue-i18nを連携](https://intlayer.org/ja/blog/intlayer-with-vue-i18n)させて厳格な型安全性とローカルAI翻訳を活用することも可能です。
+
+自社サイトのサイズと翻訳漏れは無料の[i18n SEOスキャナー](https://intlayer.org/i18n-seo-scanner)で診断できます。
+
+<ClickToOpenIframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## おすすめの記事
+
+- [Vue & Vite i18nベンチマーク: パフォーマンス詳細比較](https://intlayer.org/ja/doc/benchmark/vue)
+- [vue-i18n vs Intlayer: 項目別比較](https://intlayer.org/ja/blog/vue-i18n-vs-intlayer)
+- [2026年においてnext-intlは時代遅れなのか？](https://intlayer.org/ja/blog/is-next-intl-outdated)
+- [コンパイラ主導型国際化と宣言的i18nの比較](https://intlayer.org/ja/blog/compiler-vs-declarative-i18n)

package/blog/ja/list_i18n_technologies/build-tools/vite.md

@@ -0,0 +1,179 @@
+---
+createdAt: 2026-09-02
+updatedAt: 2026-09-02
+title: "Vite i18n: globインポート、チャンク分割、ビルド時メッセージ処理"
+description: i18n において真に Vite 固有となる要素とは何か。import.meta.glob による遅延カタログ読み込み、ルート別分割が機能しにくい理由、HMR の落とし穴、ビルド時プラグインの仕組みを解説。
+keywords:
+  - vite i18n
+  - import.meta.glob
+  - vite コード分割
+  - 翻訳の遅延読み込み
+  - vite プラグイン i18n
+  - rollup チャンク
+slugs:
+  - blog
+  - i18n-technologies
+  - build-tools
+  - vite
+author: aymericzip
+---
+
+# Vite i18n: フレームワークではなく Vite 固有の設計論
+
+世の中に溢れる「Vite i18n」チュートリアルの大半は、たまたま Vite を使っているだけの React や Vue の解説です。本記事ではその下のレイヤー、つまりカタログがどのようにインポートされ、Rollup がそれをどうチャンク化し、なぜ自作した遅延読み込み（Lazy loading）が実際には遅延されていないのかに焦点を当てます。
+
+## 目次
+
+<TOC/>
+
+## 静的インポートはデフォルトかつ同期的である
+
+最も単純なセットアップは、モジュールの先頭ですべてのカタログを直接インポートすることです。
+
+```ts fileName="src/i18n.ts"
+import en from "./locales/en.json";
+import fr from "./locales/fr.json";
+import ja from "./locales/ja.json";
+```
+
+これにより、すべてのページのすべてのユーザー向けに、3言語分のカタログがエントリーチャンクに含まれてしまいます。2言語で合計100文字列程度なら問題ありませんが、10言語に達した時点でバンドルサイズにおける最大の無駄になります。
+
+## `import.meta.glob` と設定ミスしやすいフラグ
+
+Vite の glob インポート機能は、この問題の標準的な解決策です。
+
+```ts
+const catalogs = import.meta.glob("./locales/*.json");
+
+export const loadCatalog = async (locale: string) => {
+  const load = catalogs[`./locales/${locale}.json`];
+  return (await load()) as Record<string, string>;
+};
+```
+
+デフォルトで遅延読み込み（Lazy）になります。各エントリは動的インポートを返す関数となり、Rollup はファイルごとに個別のチャンクを出力します。ここで `{ eager: true }` を追加してしまうと、すべてのファイルが親モジュール内にインライン展開され、回避しようとしていた問題そのものを引き起こします。
+
+```ts
+// すべての言語がエントリーチャンクに入ってしまうため非推奨
+const catalogs = import.meta.glob("./locales/*.json", { eager: true });
+```
+
+注意すべきは、開発環境では Vite が各モジュールを個別配信するため、どちらの書き方でも軽快に動いてしまう点です。違いは `dist` フォルダにのみ現れます。`npx vite build && npx vite preview` でビルドし、エントリーチャンクに実際に何が含まれているかを確認してください。
+
+## ルートごとの分割が期待通りに分割されない理由
+
+多くの開発者が直面する落とし穴です。ページごとにカタログファイルを分割したとします。
+
+```
+locales/en/home.json
+locales/en/checkout.json
+```
+
+しかし、2つのルートが両方とも `checkout.json` をインポートすると、Rollup はそれを共通チャンクに引き上げ、両方のページでダウンロードされるようにまとめます。Rollup のチャンク分割アルゴリズムはフォルダ名ではなくモジュールグラフに基づいて動作するため、複数のエントリポイントから参照されるモジュールは自動的に共有チャンクになります。3つ目のルートを追加しても変わらず、4つ目を追加すると予期せぬ別の分割が行われることもあります。
+
+ルートごとのカタログ分割が成立するのは、インポートグラフが完全に独立している場合のみです。バンドルサイズが重要な場合は、推測ではなく可視化ツールで検証してください。
+
+```bash
+npx vite build && npx vite-bundle-visualizer
+```
+
+どうしても境界を強制したい場合は `build.rollupOptions.output.manualChunks` を使用して手動で制御できますが、保守コストがかかります。
+
+## カタログは自動でホットリロード（HMR）されない
+
+コンポーネントを編集すると Vite は瞬時に画面を書き換えます。しかし `locales/fr.json` を編集した場合、インポートの仕方によっては何も起こりません。動的インポートされた JSON にはネイティブな HMR 境界が存在しないため、モジュールグラフが依存関係を正しく無効化できないためです。
+
+文言を編集するたびに開発サーバーを再起動しているエンジニアを見かけますが、これは回避可能です。解決策は i18n プラグイン側にあります。HMR の更新通知を受け取り、実行中のアプリに新しいメッセージを注入するハンドラーを備えている必要があります。ライブラリを選定する際は、その Vite プラグインが辞書ファイルの HMR を処理できるか確認してください。
+
+## `define` はロケールをビルド時に焼き固めてしまう
+
+ビルド時にデフォルトロケールを解決したくなる誘惑に駆られることがあります。
+
+```ts fileName="vite.config.ts"
+export default defineConfig({
+  define: {
+    __DEFAULT_LOCALE__: JSON.stringify(process.env.LOCALE ?? "en"),
+  },
+});
+```
+
+`define` はビルド時に単純なテキスト置換を行います。ビルド時点で指定された値がそのままコードに埋め込まれるため、言語ごとに別々のビルドを実行することが前提となります。これは Angular の公式 i18n などで採用されている正当なアーキテクチャですが、1つのデプロイメントですべての言語を配信したい場合には適しません。
+
+リクエストごとに変化する動的な値は `define` に含めず、実行時に解決してください。
+
+## メッセージのパースをビルド時に移管する
+
+このエコシステムで成熟したツールは、例外なく「ブラウザ内でメッセージをパースしない」というアプローチに移行しています。
+
+| プラグイン                   | ビルド時に前処理される内容                                              |
+| :--------------------------- | :---------------------------------------------------------------------- |
+| `@intlify/unplugin-vue-i18n` | vue-i18n メッセージを描画関数にコンパイル（ランタイム専用バンドル配信） |
+| Lingui (マクロ + プラグイン) | カタログを抽出・コンパイルし、マクロをメッセージIDに置換                |
+| Paraglide (inlang)           | 各メッセージを Tree-shaking 可能な独立した関数にコンパイル              |
+| `vite-intlayer`              | コンポーネント単位の辞書を構築し、未使用フィールドのパージと短縮化      |
+
+得られる利点は2つあります。クライアント側のランタイムから重いメッセージコンパイラを排除できる点と、未使用の翻訳キーを静的に削除できる点です。一方のコストとして、開発サーバーと CI の両方にプラグインの導入が必要になり、Vite を介さない素の `tsc` やテストランナーを実行する際に追加の設定が必要になります。
+
+vue-i18n は前者の好例です。`@intlify/unplugin-vue-i18n` がないと、ブラウザ側で `new Function` を呼び出すコンパイラを配信することになり、バンドル増だけでなく CSP（コンテンツセキュリティポリシー）の制限にも抵触します。
+
+## SSR: モジュール変数でロケールを保持しない
+
+SSR（フレームワークまたは `vite-plugin-ssr` 経由）を導入する場合の鉄則は、「現在のロケールを保持するモジュールレベルの変数は、そのサーバープロセス上の全リクエスト間で共有されてしまう」ということです。
+
+```ts
+// ブラウザ内なら安全。サーバー上ではリクエスト間での重大なデータ漏洩につながる
+export let currentLocale = "en";
+```
+
+2人のユーザーが同時にアクセスするとレースコンディションが発生し、一方が他方の言語でレンダリングされてしまいます。ローカル開発時は同時に1リクエストしか発生しないため発覚しません。ロケールは必ずリクエストごとに解決し、コンテキストやフレームワークのリクエストローカルストレージを介して明示的に渡してください。
+
+## Intlayer の Vite プラグイン
+
+Intlayer は辞書のビルド、開発時のファイル監視、最適化パイプラインを統合した単一のプラグインを提供します。
+
+```ts fileName="vite.config.ts"
+import react from "@vitejs/plugin-react";
+import { defineConfig } from "vite";
+import { intlayer } from "vite-intlayer";
+
+export default defineConfig({
+  plugins: [react(), intlayer()],
+});
+```
+
+インポートの自動書き換え、未使用文言のパージ、キーの最小化（minify）が最初から有効になっています。主要なオプションは `intlayer.config.ts` で管理します。
+
+```ts fileName="intlayer.config.ts"
+import type { IntlayerConfig } from "intlayer";
+
+const config: IntlayerConfig = {
+  build: {
+    purge: true, // どのコンポーネントからも読まれていない文言フィールドを削除
+    minify: true, // コンテンツキーを短いエイリアスに短縮
+  },
+};
+
+export default config;
+```
+
+翻訳コンテンツが巨大な単一言語ファイルではなく各コンポーネント単位で宣言されているため、パージ処理は正確なモジュールグラフを参照して安全にコードを刈り取ることができます。トレードオフは前述の通り、コードをコンパイルするあらゆる環境（CI やテスト実行環境を含む）でプラグインが必要になる点です。詳細は [バンドル最適化ドキュメント](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/bundle_optimization.md) を確認してください。
+
+## よくある失敗
+
+- **遅延読み込みを意図した glob に `{ eager: true }` を付ける。** ローカルでは動きますが、本番で全言語が一括配信されます。
+- **フォルダ構造がそのままチャンクになると誤認する。** Rollup はディレクトリではなくインポート関係を追跡します。ビルド結果を検証してください。
+- **文言の修正を確認するために毎回開発サーバーを再起動する。** プラグイン側の HMR ハンドラーの欠落が原因です。
+- **`define` に言語情報を設定する。** 言語ごとに独立したビルドを行う構成を自ら強いることになります。
+- **SSR 環境でモジュールスコープにロケールを保持する。** 同時リクエスト時に言語が入れ替わる事故につながります。
+- **開発サーバー上でパフォーマンスを計測する。** バンドルされていないモジュールの挙動は本番バンドルの参考になりません。
+
+## さらに学ぶ
+
+- [バンドル最適化: パージ、縮小化、そしてブラウザに届く成果物の内訳](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/bundle_optimization.md)
+- [主要フレームワーク間のベンチマークレポート](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/benchmark/index.md)
+- [設定リファレンス](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/configuration.md)
+- [Vite + React 環境への Intlayer の導入手順](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/intlayer_with_vite+react.md)
+- [i18next互換アダプター](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/compat/i18next.md)
+- [React i18n: Provider パターンの仕組み](https://github.com/aymericzip/intlayer/blob/main/docs/blog/ja/list_i18n_technologies/frameworks/react.md)
+- [Vue i18n: 仕組みと運用上の注意点](https://github.com/aymericzip/intlayer/blob/main/docs/blog/ja/list_i18n_technologies/frameworks/vue.md)
+- [コンポーネント指向 vs 集中管理型i18n](https://github.com/aymericzip/intlayer/blob/main/docs/blog/ja/per-component_vs_centralized_i18n.md)

package/blog/ja/list_i18n_technologies/frameworks/angular.md

@@ -23,8 +23,6 @@ author: aymericzip
 
 今日の相互接続された世界では、ウェブサイトを複数の言語で提供することで、リーチを大幅に拡大し、ユーザーエクスペリエンスを向上させることができます。Angularを使用している開発者にとって、国際化（i18n）の実装は、アプリケーションの構造、SEO、およびパフォーマンスを維持しながら翻訳を効率的に管理するために重要です。この記事では、Angularの組み込みソリューションから人気のサードパーティライブラリに至るまで、さまざまなi18nアプローチを探り、プロジェクトに最適な選択肢を判断できるようにします。
 
-![i18n illustration](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18n.webp)
-
 ## 国際化（i18n）とは何ですか？
 
 国際化、通常はi18nと呼ばれるプロセスは、アプリケーションが複数の言語と文化的文脈をサポートできるように設計し、準備することです。Angularでは、テキスト、日付、数字、さらにはUIレイアウトが異なるロケールにシームレスに適応できるようにアプリを構成することを含みます。この基盤を適切に築くことで、将来の翻訳の統合が整理され、効率的に行えることを保証します。

package/blog/ja/list_i18n_technologies/frameworks/react-native.md

@@ -25,8 +25,6 @@ author: aymericzip
 
 ---
 
-![i18nのイラスト](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18n.webp)
-
 ## 国際化（i18n）とは？
 
 国際化、またはi18nは、アプリケーションを構造化して、さまざまな言語、地域の形式、文化的規範に簡単に適応できるようにすることを含みます。React Nativeにおけるi18nは、ボタンやラベルの文字列を扱うだけでなく、ユーザーのロケールに応じて日付、時間、通貨などをフォーマットすることも含まれます。適切に準備されたReact Nativeアプリは、後から追加の言語やロケール特有の動作をシームレスに統合できるため、大規模なリファクタリングなしに行うことができます。

package/blog/ja/list_i18n_technologies/frameworks/react.md

@@ -25,8 +25,6 @@ author: aymericzip
 
 ---
 
-![i18nのイラスト](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18n.webp)
-
 ## 国際化（i18n）とは？
 
 国際化、略してi18nは、ウェブサイトが複数の言語や文化的文脈をサポートするように設計し準備するプロセスです。Reactにおいては、アプリがさまざまな地域のユーザーに適応できるように、文字列、日付形式、数字形式、さらにはレイアウトを簡単に調整できるように設定することを意味します。Reactアプリをi18n用に準備することは、翻訳やその他のローカリゼーション機能をクリーンに統合するための基盤を築きます。

package/blog/ja/list_i18n_technologies/frameworks/svelte.md

@@ -23,8 +23,6 @@ author: aymericzip
 
 ウェブが世界中の人々をつなげ続ける中で、複数言語でコンテンツを提供することはますます重要になっています。**Svelte**で作業している開発者にとって、i18nの実装は翻訳を効率的に管理し、クリーンなコードを維持し、良好なSEOプラクティスを保つために不可欠です。本記事では、Svelte向けのさまざまなi18nソリューションとワークフローを掘り下げ、プロジェクトのニーズに最適なものを選ぶ手助けをします。
 
-![i18n illustration](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18n.webp)
-
 ## 国際化 (i18n) とは？
 
 国際化、一般にi18nと略されるものは、アプリケーションを設計・構築し、さまざまな言語、地域、文化的慣習に簡単に適応できるようにするプロセスです。Svelteでは、通常、翻訳文字列の設定、日付、時間、数字のローカライズ、およびユーザーインターフェースがさまざまなロケール間で動的に切り替えられることを保証することを意味します。

package/blog/ja/list_i18n_technologies/frameworks/vue.md

@@ -25,8 +25,6 @@ author: aymericzip
 
 ---
 
-![i18n illustration](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18n.webp)
-
 ## 国際化（i18n）とは？
 
 国際化（i18n）とは、ソフトウェアアプリケーション（またはウェブサイト）を複数の言語および文化的慣習のために準備する実践です。Vue.jsエコシステム内では、テキスト、日付、数値、通貨、およびその他のローカライズ可能な要素がどのようにさまざまなロケールに適応できるかを確立することが含まれます。最初からi18nを設定することで、新しい言語を追加し、将来のローカリゼーションニーズに対応するための組織的でスケーラブルな構造を確保します。

package/blog/ja/what_is_internationalization.md

@@ -20,8 +20,6 @@ author: aymericzip
 
 # 国際化（i18n）とは？ 定義と課題
 
-![i18n illustration](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18n.webp)
-
 ## 国際化（i18n）の理解
 
 **国際化**（Internationalization）、略して**i18n**は、アプリケーションを設計し、コードベースに大きな変更を加えることなく、複数の言語、文化、地域的慣習をサポートするためのプロセスです。i18nという名前は、「internationalization」という言葉の中で**i**と**n**の間に18文字があることに由来しています。