@intlayer/docs 9.5.2 → 9.5.4-canary.0

package/blog/ja/vue-i18n_vs_intlayer-vue-i18n.md

@@ -0,0 +1,288 @@
+---
+createdAt: 2026-09-13
+updatedAt: 2026-09-13
+title: "vue-i18n vs @intlayer/vue-i18n: 同じAPI、異なるBundle"
+description: Vue 3アプリが vue-i18n の呼び出しを保持しながら、@intlayer/vue-i18n compat adapterを通じてそれらをサーブする場合の変更点。同じ Vite + Vue コード上での、ページごとのJavaScript、ランタイムサイズ、コンポーネントサイズとリークの測定、およびアダプターが保持、無視、および置き換えることができないものの説明。
+keywords:
+  - vue-i18n
+  - "@intlayer/vue-i18n"
+  - Intlayer
+  - Compat adapter
+  - Migration
+  - Internationalization
+  - i18n
+  - Benchmark
+  - Bundle size
+  - Blog
+  - Vue
+  - Nuxt
+  - Vite
+slugs:
+  - blog
+  - vue-i18n-vs-intlayer-vue-i18n
+author: aymericzip
+---
+
+# vue-i18n VS @intlayer/vue-i18n | 同じAPI、異なるBundle
+
+`@intlayer/vue-i18n` は互換性アダプター：vue-i18n API (`createI18n`、`useI18n`、`t()`、`d()`、`n()`、`$t`、`v-t`、`i18n.global.locale`...) を公開し、Intlayer によってコンパイルされたディクショナリから提供します。`.vue` ファイルは変わりません。`t("footer.github")` がバインドされるものが変わるだけです。
+
+この記事では、同じVite + Vue 3アプリケーションでこのスワップを測定します。このアプリケーションは`vue-i18n`で1回、アダプターで1回ビルドされました。数値は[Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom)から取得されています。ライブラリとして比較される`vue-i18n`とIntlayerについては、[vue-i18n vs Intlayer](https://intlayer.org/blog/vue-i18n-vs-intlayer)と[vue-i18n vs Intlayer benchmark](https://intlayer.org/blog/vue-i18n-vs-intlayer-benchmark)を参照してください。この記事は、コンポーネントをそのまま保つ場合にアダプターが何を変更するかについてです。
+
+<TOC/>
+
+> **tl;dr**: 同じ Vite + Vue 3 アプリで、`vue-i18n` を `@intlayer/vue-i18n` に置き換えると、ページごとの JavaScript が **134.9 KB から 47.0 KB** gzip に削減されました（i18n なしのアプリは 41.3 KB）、ランタイムが **24.3 KB から 7.9 KB**、平均コンポーネントが **196 KB から 8.4 KB**、他言語ページの文字列漏洩が **90% から 0%** に改善され、`.vue` ファイルは一切編集していません。`createI18n({ messages })` はフォールバックとして動作し続けます。JSON のインポートを削除すると上記の数値が得られます。SFC `<i18n>` ブロックとランタイム `setLocaleMessage()` は、引き継がれない 2 つの機能です。
+
+## `@intlayer/vue-i18n` とは
+
+`vue-i18n` はランタイムです。`createI18n({ messages: { en, fr, ... } })` はすべてのロケールのすべてのメッセージを保持するグローバルインスタンスを構築します。`useI18n()` は各コンポーネントをそれにバインドします。`t("footer.github")` はレンダリング時にツリーをウォークします。この設計により、SFC `<i18n>` ブロックと `setLocaleMessage()` が可能になり、各コンポーネントの依存グラフがツリー全体を含む理由でもあります。
+
+`@intlayer/vue-i18n` はAPIを保持し、ツリーを置き換えます：
+
+1. **インポートエイリアシング。** `@intlayer/vue-i18n/plugin` の `vueI18nVitePlugin()` は `vite-intlayer` をラップし、`vue-i18n` が `@intlayer/vue-i18n` に解決されるように `resolve.alias` を追加します。インポートは名前変更されません。
+2. **JSONを真実のソースとする。** `syncJSON` プラグインは、既存の `locales/{locale}.json` を `format: "vue-i18n"` で読み込み（`{name}`、`{0}` リスト補間、`"car | cars"` パイプ複数形が正しく解析されます）、CLI または CMS が更新したときに翻訳を書き戻します。
+3. **コール・サイト・バインディング。** Intlayer の最適化パスは `useI18n()` コール・サイトを書き直すため、コンポーネントはキー名の辞書を受け取り、アクティブなロケールでインポートとして存在し、bundler がトレースして分割できます。
+
+```vue fileName="src/components/Footer.vue"
+<!-- コードは変更されていません -->
+<script setup lang="ts">
+import { useI18n } from "vue-i18n";
+
+const { t } = useI18n();
+</script>
+
+<template>
+  <a href="https://github.com/intlayer-org/benchmark-bloom">{{
+    t("footer.github")
+  }}</a>
+</template>
+```
+
+```ts fileName="What the compiler emits (simplified)"
+import _dicHash_footer from "../.intlayer/dictionaries/footer.mjs";
+import { useDictionary as useI18n } from "@intlayer/vue-i18n";
+
+const { t } = useI18n(_dicHash_footer);
+```
+
+コンポーネントはもはやグローバルなメッセージツリーに到達しません。`footer` に到達します。これが、以下のコンポーネントサイズの列が 196 KB から 8 KB に低下する理由です。
+
+## アダプターが保持、無視、および置換しないもの
+
+| `vue-i18n` API                                                      | `@intlayer/vue-i18n` を使用する場合                                                                                                    |
+| ------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
+| `useI18n()` → `{ t, d, n, te, tm, rt, locale, availableLocales }`   | ✅ 保持。`t` キーは辞書に対して型チェックされます                                                                                      |
+| `t("key", { name })`, `t("key", [a, b])`, `t("key", count)`         | ✅ 保持。`{name}`、`{0}` およびパイプ区切りの複数形は以前のように解決されます                                                          |
+| `d(date, "long")`, `n(value, "currency")`                           | ✅ 保持。`createI18n()` の `datetimeFormats` / `numberFormats` は尊重され、ネイティブ `Intl` によってサポートされます                  |
+| `i18n.global.locale.value = "fr"`                                   | ✅ 保持。Intlayerのクライアントに支えられた`WritableComputedRef`。リアクティビティは以前と同じように動作します                         |
+| `$t`, `$tc`, `$te`, `$tm`, `$rt`, `$d`, `$n`, `$i18n` (Options API) | ✅ 保持。`app.use(i18n)`によって`app.config.globalProperties`に登録されます                                                            |
+| `v-t` ディレクティブ                                                | ✅ 保持                                                                                                                                |
+| `legacy: true`                                                      | ✅ 受け入れられます                                                                                                                    |
+| `createI18n({ messages })`                                          | ⚠️ `messages` は **ランタイムフォールバック** として使用されます（開発警告付き）。バンドル削減のため JSON インポートを削除してください |
+| `setLocaleMessage()`, `mergeLocaleMessage()`                        | ❌ 警告を表示して何もしません。ランタイムメッセージ読み込みはビルド時辞書に置き換わります                                              |
+| SFC `<i18n>` カスタムブロック                                       | ❌ 読み込まれません。これらのメッセージをロケール JSON（またはコンポーネント隣の `.content.ts`）に移動してください                     |
+| `@nuxtjs/i18n`                                                      | ⚠️ 別のアダプター、[Nuxt compat ドキュメント](https://intlayer.org/doc/compatibility/nuxtjs-i18n)を参照してください                    |
+
+## ベンチマーク
+
+### 測定内容
+
+[Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom) スイートは、**同じ Vite + Vue 3 アプリケーション**を各セットアップでビルドします: **10 ページ**(home、about、blog、careers、contact、FAQ、pricing、products、settings、team)、**10 言語**(`en`、`fr`、`es`、`de`、`it`、`pt`、`zh`、`ja`、`ko`、`ru`)、同一のコンポーネントと同一のコンテンツ。ページは `en` と `fr` で測定されます。
+
+どちらも **static** 設定でビルドされています。これは Vue プロジェクトが最も一般的に使用する設定です: `vue-i18n` では、すべてのロケールの JSON をインポートして `createI18n({ messages })` に渡されます。アダプターでは、同じコンポーネントで `vite.config.ts` と `intlayer.config.ts` を変更し、`messages` インポートを削除しています。参照用に、ネイティブな `vue-intlayer` が含まれています。
+
+各ビルドについて、スイートは以下を記録します:
+
+- **Lib size**: i18nライブラリのみをインポートする空のコンポーネントのgzip（および縮小）サイズ。
+- **Page JS**: ページあたりにダウンロードされるgzip JavaScript、すべてのページとlocaleの平均。
+- **Locale leak %**: ユーザーが**表示していない** localeに属する、ダウンロードされたJS内の翻訳文字列のシェア。
+- **Page leak %**: ユーザーが**いないページ**に属する、ダウンロードされたJS内の翻訳文字列のシェア。
+- **Component avg**: 個別にコンパイルされた各コンポーネントの平均gzipサイズ。
+- **E2E reactivity**: 新しいlocaleを選択してからDOM内の`html[lang]`が更新されるまでの実経過時間（Playwright、5回の反復）。
+- **Page load**: `PerformanceNavigationTiming.duration`。
+
+> 以下の数値は **2026-09-12** の実行から取得したもので、`vue-i18n` 11.4.0 と `@intlayer/vue-i18n` 9.5.1 を使用しています。テストアプリケーションは意図的に小さく設計されており（ロケールあたり数十の文字列）、リーク率は**パターン**を示します：コンテンツが増えるにつれてリーク率は増加しますが、ランタイムコストは固定されたままです。
+
+### Vite + Vue 3 での結果
+
+| Setup                    | Strategy | Lib size (gz) | Lib size (min) | Page JS avg (gz) | Locale leak | Page leak | Component avg (gz) | E2E reactivity |  Page load |
+| ------------------------ | -------- | ------------: | -------------: | ---------------: | ----------: | --------: | -----------------: | -------------: | ---------: |
+| **base** (no i18n)       | -        |        0.0 KB |         0.0 KB |          41.3 KB |        0.0% |         - |             1.1 KB |         1.8 ms |    10.8 ms |
+| `vue-i18n`               | static   |       24.3 KB |        83.2 KB |         134.9 KB |       50.0% |     90.0% |           196.0 KB |         2.8 ms |    13.6 ms |
+| **`@intlayer/vue-i18n`** | static   |    **7.9 KB** |    **23.2 KB** |      **47.0 KB** |   **15.0%** |  **0.0%** |         **8.4 KB** |     **1.5 ms** | **9.3 ms** |
+| `vue-intlayer` (native)  | static   |        3.9 KB |        11.1 KB |          57.1 KB |       56.8% |      0.0% |             7.7 KB |         4.5 ms |    13.8 ms |
+| `vue-intlayer` (native)  | dynamic  |        3.9 KB |        11.1 KB |          59.8 KB |       50.0% |      0.0% |             6.5 KB |         4.0 ms |    15.8 ms |
+
+> ベースアプリのpage-leakカラムは空白のままです。i18nライブラリがない場合、フィンガープリンティングは共有チャンク内のハードコードされた文字列を拾い上げ、その数は意味がありません。
+
+**読み方**
+
+- **ページあたり88 KB少なく、同じコンポーネント。** `vue-i18n`はベースアプリの41.3 KBを**134.9 KB**に増やします。同じコンポーネントのアダプタビルドは**47.0 KB**に落ち着き、ベースアプリより5.7 KB多くなります。差異のほとんどは、`createI18n({ messages })`が毎ページに引き込む74.9 KBの`src/locales`とアダプタがブロックとしてバンドルしない部分です。
+- **ランタイムが3倍縮小します。** `vue-i18n` のみをインポートするコンポーネントは **24.3 KB gzip / 83.2 KB minified** かかります: `@intlify/core-base`、メッセージコンパイラーと実行時です。アダプターは **7.9 KB / 23.2 KB** かかります。ほとんどが Intlayer のコアと `vue-i18n` API サーフェスです。
+- **コンポーネント: 23倍小さくなります。** 単独でコンパイルされた `useI18n()` コンポーネントは平均 **196 KB** です。これは `t` が全ロケールの全メッセージを保持するインスタンスにバインドされているためです。アダプターの場合、同じコンポーネントは平均 **8.4 KB** です: 独自の辞書に到達します。
+- **リーク.** `vue-i18n`はすべてのロケールとすべてのページの文字列をすべてのページに含めます：50%のロケールリーク（2つのフィンガープリント付きロケール上；10個のロケールがバンドルされている場合、実際の無駄はさらに高い）、90%のページリーク。アダプターは、各コンポーネントがその辞書のみをインポートするため、ページリークを**0%**に削減します。このロケールリークはこの`static`実行で15%です；`importMode: 'dynamic'`はそれを削除する設定であり、その設定はこのVue実行の一部ではありませんでした。
+- **リアクティビティとページ読み込み.** ロケール切り替えは両者にとって安価です（1.5～2.8 ms）；Vueのリアクティビティシステムは、メッセージがメモリ内にあれば可能にします。ページ読み込みは13.6 msから**9.3 ms**に短縮され、88 KBのJavaScriptのパースが減少することと一致しています。
+- **ネイティブ行について。** このrun で、`vue-intlayer` は `static` モードですべてのロケールをバンドルし、57.1 KB に到達し、3.9 KB のランタイムを実装しました。アダプタの同期辞書は外国語ロケール文字列が少なかったため、ページごとの数値が低くなりました。ネイティブランタイムは 3 つの中で最も軽量のままであり、その `.content.ts` モデルは SFC `<i18n>` ブロックが同等のものを見つける場所です。
+
+## 数値が移動する理由
+
+`src/components/` の何も変わっていないため、ゲインは `useI18n` がバインドされているものから来ています。
+
+**`vue-i18n`を使用する場合**、バインディングはグローバルインスタンスです。`createI18n({ messages: { en, fr, ... } })`は everything を保持する1つのインポートであり、`useI18n()`を呼び出すすべてのコンポーネントはそのすべてにアクセスできるため、bundler はインスタンス以下で分割できません。最適化とは、_あなたが_`en.json`をルートごとに分割し、router guard で`setLocaleMessage()`を呼び出し、コンポーネントが移動するときにルートからファイルへのマップを正確に保つことを意味します。
+
+```bash
+.
+├── locales
+│   ├── en.json                    # すべてのページの文字列
+│   └── fr.json
+└── src
+    ├── i18n.ts                    # createI18n({ messages: { en, fr, ... } })
+    ├── main.ts                    # app.use(i18n)
+    └── components
+        └── Footer.vue             # useI18n(); t("footer.github")
+```
+
+**`@intlayer/vue-i18n`を使用する場合**、バインディングは辞書です。`syncJSON`は`en.json`の各トップレベルキーを辞書に変換します。最適化パスはコンポーネントにそのキー名のものをハンドし、bundlerが追跡して分割するインポートとしています。
+
+```bash
+.
+├── intlayer.config.ts             # syncJSON({ format: "vue-i18n", source: ... })
+├── locales
+│   ├── en.json                    # 変わらず、相変わらず信頼できるソース
+│   └── fr.json
+├── .intlayer/                     # 生成: トップレベルキーごと、ロケールごとの辞書
+└── src
+    ├── i18n.ts                    # createI18n({})   ← messages インポート削除
+    ├── main.ts                    # app.use(i18n)    ← 変わらず
+    └── components
+        └── Footer.vue             # useI18n(); t("footer.github")  ← 変わらず
+```
+
+`i18n.ts`の`messages`インポートは削除する1行です。それが88 KBです。
+
+## 3つのステップでの移行
+
+<Steps>
+<Step number={1} title="インストール">
+
+```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
+```
+
+このコマンドは`vue-i18n`を検出し、`intlayer`、`vue-intlayer`、`@intlayer/vue-i18n`、`@intlayer/sync-json-plugin`をインストールし、`intlayer.config.ts`を事前入力します。`vue-i18n`をインストールしたままにしておいてください。これはピア依存関係であり、型を提供します。
+
+</Step>
+<Step number={2} title="ロケールファイルをIntlayerにポイントする">
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+import { syncJSON } from "@intlayer/sync-json-plugin";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    defaultLocale: Locales.ENGLISH,
+  },
+  dictionary: {
+    // "static"はすべてのロケールをバンドルします。"dynamic"はアクティブなロケールをオンデマンドでロードします
+    importMode: "dynamic",
+    format: "vue-i18n",
+  },
+  plugins: [
+    syncJSON({
+      // vue-i18n方言: {name}, {0}, "car | cars"
+      format: "vue-i18n",
+      source: ({ locale }) => `./locales/${locale}.json`,
+      location: "locales",
+    }),
+  ],
+};
+
+export default config;
+```
+
+`locales/{locale}.json`はそのままの場所に保持されます。各トップレベルキー（`footer`、`hero`など）はdictionaryになります。
+
+</Step>
+<Step number={3} title="プラグインを追加してメッセージインポートを削除する">
+
+```ts fileName="vite.config.ts"
+import { defineConfig } from "vite";
+import vue from "@vitejs/plugin-vue";
+import { vueI18nVitePlugin } from "@intlayer/vue-i18n/plugin";
+
+export default defineConfig({
+  plugins: [vue(), vueI18nVitePlugin()],
+});
+```
+
+```ts fileName="src/i18n.ts"
+import { createI18n } from "vue-i18n";
+
+// 前: createI18n({ locale: "en", messages: { en, fr, es } })
+export const i18n = createI18n({ locale: "en" });
+```
+
+`vueI18nVitePlugin()` は `vite-intlayer`（コンテンツ監視、辞書コンパイル、最適化パス）をラップし、`vue-i18n` をアダプターにエイリアスします。`messages` インポートを削除することで 88 KB が削減されます。削除しないままにすると、アプリは動作し続けますが、両方がシップされます。
+
+</Step>
+</Steps>
+
+### 後で削除できる内容
+
+| ファイル / パターン                                             | 理由                                                                                               |
+| --------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
+| `import en from "./locales/en.json"` およびそれらの関連ファイル | アダプターによるフォールバックとしてのみ使用される。88 KBはここから来ていた                        |
+| ルーターガード内の `setLocaleMessage()`                         | 何もしない。ルートごとのロードはコンパイラーの仕事になった                                         |
+| `@intlify/unplugin-vue-i18n`                                    | 不要：メッセージをプリコンパイルし、SFCブロックはアダプターが読み取らない                          |
+| SFC `<i18n>` ブロック                                           | 読み込まれない；これらをロケール JSON または コンポーネントごとの `.content.ts` に移動してください |
+
+### バイト数以外に得られるもの
+
+- **型付きキー。** `t("footer.github")` はコンパイルされた `footer` 辞書に対して型付けされます；間違ったパスは、キーがテキストとしてレンダリングされる代わりに TypeScript エラーになります。
+- **`npx intlayer test`** は、いずれかのロケールで欠落しているキーがある場合、CI に失敗します。**`npx intlayer fill`** は、あなた自身のプロバイダーキー（OpenAI、Anthropic、Mistral、Gemini...）を使用して欠落しているキーを翻訳し、`locales/{locale}.json` に書き戻します。
+- **ビジュアルエディターと CMS** は同じ JSON で動作するため、開発者以外は UI を通じて編集でき、ファイルが更新されます。
+- **`.content.ts` への段階的な移行。** 任意のコンポーネントは、co-located content ファイルを使用して `useI18n()` から `useIntlayer("footer")` に切り替えることができます。JSON と `.content.ts` の辞書は共存し、マージされます。
+
+## 始める前に知っておくべき制限事項
+
+- **SFC `<i18n>` ブロックは読み込まれません。** メッセージがコンポーネント内に存在する場合、それらをロケールファイル（または `.content.ts`、これは型付きの同じ概念）に移動する必要があります。
+- **ランタイムメッセージロードは廃止されました。** `setLocaleMessage()` と `mergeLocaleMessage()` は警告を出して返されます。実行時に CMS から取得した翻訳には、Intlayer の CMS、または `intlayer pull` / `push` コマンドが必要です。
+- **`messages` はフォールバックであり、無料ではありません。** `createI18n()` で JSON import を保持すると、bundle に 75 KB が保持されます。`intlayer test` がパスしたら削除してください。
+- **アダプターはネイティブランタイムではありません。** `vue-intlayer` の 3.9 KB に対して 7.9 KB です。すべてのコンポーネントが `useIntlayer` に移行したら、削除してください。
+
+## どのような場合にどちらを使うか？
+
+- **`vue-i18n` に留まる** アプリが SFC `<i18n>` ブロック、ランタイム `setLocaleMessage()` フロー、または 90 KB/ページがオーディエンスにとって問題でない場合。
+- **`@intlayer/vue-i18n` を使用する** `vue-i18n` を使用しており、88 KB の削減、コンポーネント 23 倍小型化、0% ページリーク、型付きキー、`.vue` ファイル編集なしの CI チェックが必要な場合。これは既存の `vue-i18n` コードベースのエントリーポイントです。
+- **ネイティブ (`vue-intlayer`) に移行する** 新規プロジェクト、またはアダプターが役目を果たした後。最軽量のランタイム (3.9 KB) と、`<i18n>` ブロックを型付きコンテンツで置き換える、コンポーネント単位の `.content.ts` モデルを備えています。
+
+## 関連する比較
+
+- [vue-i18n vs Intlayer](https://intlayer.org/blog/vue-i18n-vs-intlayer) (機能とDX)
+- [vue-i18n vs Intlayer ベンチマーク](https://intlayer.org/blog/vue-i18n-vs-intlayer-benchmark) (ライブラリ、同じベンチマーク)
+- [next-intl vs @intlayer/next-intl](https://intlayer.org/blog/next-intl-vs-intlayer-next-intl) (同じアダプターシリーズ)
+- [i18next vs @intlayer/i18next](https://intlayer.org/blog/i18next-vs-intlayer-i18next) (同じアダプターシリーズ)
+- [Lingui vs @intlayer/lingui](https://intlayer.org/blog/lingui-vs-intlayer-lingui) (同じアダプターシリーズ)
+- [マイグレーションガイド: vue-i18n to Intlayer](https://intlayer.org/doc/migration/vue-i18n)
+- [互換性アダプターリファレンス: vue-i18n](https://intlayer.org/doc/compatibility/vue-i18n), [Nuxt i18n](https://intlayer.org/doc/compatibility/nuxtjs-i18n)
+
+## 結論
+
+`@intlayer/vue-i18n` は `useI18n()` がバインドされるものを変更します：すべてのロケールのすべてのメッセージを保持するグローバルインスタンスから、そのコンポーネント用にコンパイルされたディクショナリーへ。同じ Vite + Vue 3 アプリで **ページあたり 88 KB削減**、**3倍小さいランタイム**、**23倍小さいコンポーネント** および **0% ページリーク** を実現し、設定ファイル、プラグインの一行、削除されたインポートのみで実装できます。SFC `<i18n>` ブロックとランタイムメッセージ読み込みの 2 つは実装されておらず、ネイティブ `vue-intlayer` ランタイムのサイズは引き続き半分です。
+
+すべてのrawデータ、テストアプリ、スクリプトは[Benchmark Bloomリポジトリ](https://github.com/intlayer-org/benchmark-bloom)にあります。自分で実行してみてください。
+
+詳細については、['Intlayerについて'ドキュメント](https://intlayer.org/doc/why)を参照してください。

package/blog/ja/vue-i18n_vs_intlayer.md

@@ -235,7 +235,7 @@ const { greeting } = useIntlayer("component-example");
 
 GitHub のスターは、プロジェクトの人気度、コミュニティの信頼、および長期的な関連性の強力な指標です。技術的品質の直接的な尺度ではありませんが、多くの開発者がプロジェクトを有用であると認識し、その進行状況をフォローし、採用する可能性があることを反映しています。プロジェクトの価値を見積もるために、スターは代替案間の牽引力を比較し、エコシステムの成長に関する洞察を提供するのに役立ちます。
 
-[![Star History Chart](https://api.star-history.com/svg?repos=intlify/vue-i18n&repos=aymericzip/intlayer&type=Date)](https://www.star-history.com/#intlify/vue-i18n&aymericzip/intlayer)
+[![Star History Chart](https://api.star-history.com/svg?repos=intlify/vue-i18n&repos=aymericzip/intlayer&type=Date)](https://star-history.com/#intlify/vue-i18n&aymericzip/intlayer)
 
 ## 結論
 

package/blog/ko/history_of_i18n.md

@@ -49,7 +49,7 @@ author: aymericzip
 
 이 글에서는 2011년부터 2026년까지의 진화 과정을 정리합니다. 각 세대의 도구들이 해결하고자 했던 과제, 성공 요인과 한계, 그리고 프론트엔드 아키텍처의 발전이 오늘날 우리가 i18n을 다루는 방식에 미친 영향을 살펴봅니다.
 
-![JavaScript 국제화 라이브러리 생태계 변천사](https://github.com/aymericzip/intlayer/blob/main/docs/assets/cloud_i18n_logo.png?raw=true)
+![JavaScript 국제화 라이브러리 생태계 변천사](https://github.com/aymericzip/intlayer/blob/main/docs/assets/cloud_i18n_logo.webp?raw=true)
 
 ## 목차
 
@@ -149,87 +149,87 @@ Jan Mühlemann은 고차 컴포넌트(`withTranslation`)와 React Context를 도
 
 <Tab label="Core JavaScript" value="javascript">
 
-| 첫 출시     | 라이브러리                           | 주요 해결 과제                                                                                                            | 핵심 혁신 요소                                                                                                                         |
-| ----------- | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
-| 2012년 1월  | `i18next`                            | 특정 프레임워크 종속 없이 브라우저와 Node.js 환경에서 런타임 사전 조회를 표준화.                                          | 핵심 번역 엔진과 로더, 감지기, 캐시 계층을 분리하는 유연한 플러그인 런타임 아키텍처.                                                   |
-| 2021년 2월  | `typesafe-i18n`                      | 타입이 지정되지 않은 문자열 키로 인한 런타임 무응답 오류 및 잘못된 변수 보간 방지.                                        | 번역 객체로부터 직접 자동 생성되며 런타임 의존성이 전혀 없는 완전한 타입 세이프 번역 함수.                                             |
-| 2023년 10월 | `paraglide` (`@inlang/paraglide-js`) | 런타임 사전 검색, 무거운 구문 파서, 클라이언트 번들 비대화 제거.                                                          | 메시지를 Tree-shaking이 가능한 순수 ECMAScript 모듈 및 일반 JavaScript 함수로 컴파일.                                                  |
-| 2024년 4월  | `intlayer`                           | 관리가 힘든 대형 네임스페이스 대체, 페이지 간 문구 유출 방지, Git 충돌 감소 및 TypeScript 기반의 엄격한 타입 안정성 확보. | `.content` 파일을 컴포넌트 옆에 배치하여 정밀하게 분할하고, TypeScript 타입을 자동 생성하며, 비주얼 CMS 및 AI 기반 CLI 번역 도구 제공. |
-| 2025년 6월  | `wuchale`                            | 개발 도중 텍스트를 수작업으로 추출하고 인위적인 번역 키를 짓는 번거로움 해소.                                             | AST 레벨에서 인라인 텍스트를 자동 감지하여 빌드 타임에 별도 래퍼 없는 로컬라이즈드 함수로 직접 컴파일.                                 |
+| 첫 출시     | 라이브러리                           | 작성자                                                       | 주요 해결 과제                                                                                                            | 핵심 혁신 요소                                                                                                                         |
+| ----------- | ------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
+| 2012년 1월  | `i18next`                            | Jan Mühlemann (`@jamuhl`)                                    | 특정 프레임워크 종속 없이 브라우저와 Node.js 환경에서 런타임 사전 조회를 표준화.                                          | 핵심 번역 엔진과 로더, 감지기, 캐시 계층을 분리하는 유연한 플러그인 런타임 아키텍처.                                                   |
+| 2021년 2월  | `typesafe-i18n`                      | Ivan Hofer (`@ivanhofer`)                                    | 타입이 지정되지 않은 문자열 키로 인한 런타임 무응답 오류 및 잘못된 변수 보간 방지.                                        | 번역 객체로부터 직접 자동 생성되며 런타임 의존성이 전혀 없는 완전한 타입 세이프 번역 함수.                                             |
+| 2023년 10월 | `paraglide` (`@inlang/paraglide-js`) | Samuel Stroschein (`@samuelstroschein`) / Inlang (`@inlang`) | 런타임 사전 검색, 무거운 구문 파서, 클라이언트 번들 비대화 제거.                                                          | 메시지를 Tree-shaking이 가능한 순수 ECMAScript 모듈 및 일반 JavaScript 함수로 컴파일.                                                  |
+| 2024년 8월  | `intlayer`                           | Aymeric Pineau (`@aymericzip`)                               | 관리가 힘든 대형 네임스페이스 대체, 페이지 간 문구 유출 방지, Git 충돌 감소 및 TypeScript 기반의 엄격한 타입 안정성 확보. | `.content` 파일을 컴포넌트 옆에 배치하여 정밀하게 분할하고, TypeScript 타입을 자동 생성하며, 비주얼 CMS 및 AI 기반 CLI 번역 도구 제공. |
+| 2025년 6월  | `wuchale`                            | Kidus Adugna (`@K1DV5`)                                      | 개발 도중 텍스트를 수작업으로 추출하고 인위적인 번역 키를 짓는 번거로움 해소.                                             | AST 레벨에서 인라인 텍스트를 자동 감지하여 빌드 타임에 별도 래퍼 없는 로컬라이즈드 함수로 직접 컴파일.                                 |
 
 </Tab>
 
 <Tab label="React" value="react">
 
-| 첫 출시     | 라이브러리       | 주요 해결 과제                                                                                       | 핵심 혁신 요소                                                                                                                                        |
-| ----------- | ---------------- | ---------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
-| 2014년 6월  | `react-intl`     | React 환경에서 숫자, 날짜, 통화 및 복잡한 복수형 서식화를 표준화.                                    | ICU MessageFormat 및 ECMA-402 규격을 지원하는 선언적 컴포넌트(`<FormattedMessage>`, `<FormattedDate>`).                                               |
-| 2015년 12월 | `react-i18next`  | React에 적합한 선언적 문법과 반응형 재렌더링을 지원하는 `i18next` 바인딩 제공.                       | 고차 컴포넌트(HOC)에서 `<Trans>` JSX 보간 및 `useTranslation` 훅 체계로 React의 패러다임과 함께 지속 진화.                                            |
-| 2018년 1월  | `@lingui/react`  | 런타임 ICU 파서가 클라이언트 번들 크기에 미치는 부담을 최소화.                                       | 빌드 타임에 Babel/SWC 매크로를 활용해 `<Trans>`와 `t`를 컴팩트한 인덱스 배열로 사전 컴파일.                                                           |
-| 2020년 12월 | `use-intl`       | 기존 라이브러리를 대체할 가볍고 훅 중심적이며 타입 안전한 React 전용 대안 제시.                      | 깊이 있는 TypeScript 통합을 지원하는 인체공학적인 `useTranslations` 및 `useFormatter` 훅.                                                             |
-| 2021년 2월  | `@tolgee/react`  | 개발자, 번역가, 디자이너 간의 커뮤니케이션 지연을 단축.                                              | 브라우저 화면에서 Alt 클릭으로 문구를 즉시 수정하고 화면 캡처를 동기화하는 인컨텍스트 편집 기능.                                                      |
-| 2024년 4월  | `react-intlayer` | 중앙집중식 JSON 파일과 비대한 네임스페이스 없이 React 컴포넌트 수명주기에 최적화된 고성능 환경 제공. | React 렌더링에 최적화된 `useIntlayer` 훅, 자동 생성되는 정밀 타입, 컴포넌트 단위 Tree-shaking 및 컨텍스트 보일러플레이트 없는 비주얼 CMS 실시간 연동. |
-| 2024년 7월  | `gt-react`       | 번역 파일의 수동 추출과 인수인계, 유지보수 작업을 자동화.                                            | 클라우드 기반 기계 번역 파이프라인을 통해 React 컴포넌트 내부에서 AI 자동 로컬라이제이션을 수행.                                                      |
-| 2025년 8월  | `@wuchale/jsx`   | JSX 작성 시 불필요한 번역 키 작명과 반복적인 훅 호출을 제거.                                         | AST 변환을 통해 JSX 내부의 원본 텍스트 노드를 감지하고 로컬라이즈된 동등 코드로 컴파일.                                                               |
+| 첫 출시     | 라이브러리       | 작성자                         | 주요 해결 과제                                                                                       | 핵심 혁신 요소                                                                                                                                        |
+| ----------- | ---------------- | ------------------------------ | ---------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 2014년 6월  | `react-intl`     | Yahoo! / FormatJS              | React 환경에서 숫자, 날짜, 통화 및 복잡한 복수형 서식화를 표준화.                                    | ICU MessageFormat 및 ECMA-402 규격을 지원하는 선언적 컴포넌트(`<FormattedMessage>`, `<FormattedDate>`).                                               |
+| 2015년 12월 | `react-i18next`  | Jan Mühlemann (`@jamuhl`)      | React에 적합한 선언적 문법과 반응형 재렌더링을 지원하는 `i18next` 바인딩 제공.                       | 고차 컴포넌트(HOC)에서 `<Trans>` JSX 보간 및 `useTranslation` 훅 체계로 React의 패러다임과 함께 지속 진화.                                            |
+| 2018년 1월  | `@lingui/react`  | Tomáš Ehrlich (`@tricoder42`)  | 런타임 ICU 파서가 클라이언트 번들 크기에 미치는 부담을 최소화.                                       | 빌드 타임에 Babel/SWC 매크로를 활용해 `<Trans>`와 `t`를 컴팩트한 인덱스 배열로 사전 컴파일.                                                           |
+| 2020년 12월 | `use-intl`       | Jan Amann (`@amannn`)          | 기존 라이브러리를 대체할 가볍고 훅 중심적이며 타입 안전한 React 전용 대안 제시.                      | 깊이 있는 TypeScript 통합을 지원하는 인체공학적인 `useTranslations` 및 `useFormatter` 훅.                                                             |
+| 2021년 2월  | `@tolgee/react`  | Jan Cizmar (`@jcizmar`)        | 개발자, 번역가, 디자이너 간의 커뮤니케이션 지연을 단축.                                              | 브라우저 화면에서 Alt 클릭으로 문구를 즉시 수정하고 화면 캡처를 동기화하는 인컨텍스트 편집 기능.                                                      |
+| 2024년 8월  | `react-intlayer` | Aymeric Pineau (`@aymericzip`) | 중앙집중식 JSON 파일과 비대한 네임스페이스 없이 React 컴포넌트 수명주기에 최적화된 고성능 환경 제공. | React 렌더링에 최적화된 `useIntlayer` 훅, 자동 생성되는 정밀 타입, 컴포넌트 단위 Tree-shaking 및 컨텍스트 보일러플레이트 없는 비주얼 CMS 실시간 연동. |
+| 2024년 7월  | `gt-react`       | Ernest McCarter (`@eoinest`)   | 번역 파일의 수동 추출과 인수인계, 유지보수 작업을 자동화.                                            | 클라우드 기반 기계 번역 파이프라인을 통해 React 컴포넌트 내부에서 AI 자동 로컬라이제이션을 수행.                                                      |
+| 2025년 6월  | `@wuchale/jsx`   | Kidus Adugna (`@K1DV5`)        | JSX 작성 시 불필요한 번역 키 작명과 반복적인 훅 호출을 제거.                                         | AST 변환을 통해 JSX 내부의 원본 텍스트 노드를 감지하고 로컬라이즈된 동등 코드로 컴파일.                                                               |
 
 </Tab>
 
 <Tab label="Next.js" value="nextjs">
 
-| 첫 출시     | 라이브러리                                  | 주요 해결 과제                                                                                  | 핵심 혁신 요소                                                                                                                                            |
-| ----------- | ------------------------------------------- | ----------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| 2018년 11월 | `next-i18next`                              | Next.js Pages Router에서 클라이언트 폭포수(waterfall) 요청 없이 `i18next` 기반 SSR 및 SSG 지원. | 페이지 Props를 통해 지역화된 네임스페이스를 전달하는 `serverSideTranslations` 및 `appWithTranslation`.                                                    |
-| 2019년 12월 | `next-translate`                            | Pages Router 기반 애플리케이션의 설정 복잡도를 낮추고 번들 크기를 축소.                         | 페이지별로 실제 필요한 번역 네임스페이스만 빌드 시점에 선별 주입하는 Webpack 로더 플러그인.                                                               |
-| 2020년 11월 | `next-intl`                                 | Next.js App Router, React Server Components (RSC), 스트리밍 SSR 패러다임에 맞춘 국제화 재설계.  | 클라이언트 JS를 전송하지 않고도 Next.js App Router 미들웨어, Server Actions, 비동기 Server Components와 자연스럽게 결합.                                  |
-| 2022년 7월  | `next-international`                        | 클라이언트 번들 오버헤드를 최소화하면서 Next.js에 엄격한 TypeScript 타입 안정성 제공.           | 스코프가 지정된 번역 키에 대한 정밀한 타입 생성과 App Router 및 Pages Router용 초경량 어댑터.                                                             |
-| 2024년 4월  | `paraglide-next` (`@inlang/paraglide-next`) | 런타임 라이브러리가 필요 없는 사전 컴파일 메시지를 Next.js App Router 및 Pages Router에 도입.   | 미들웨어 라우팅과 Tree-shaking 가능한 함수를 결합하여 RSC 및 클라이언트 번들에서 런타임 JSON 파싱을 완전히 배제.                                          |
-| 2024년 4월  | `next-intlayer`                             | 컴포넌트 간 `t()` 함수나 번역 사전을 Props로 연쇄 전달(Prop-drilling)해야 하는 불편함 해소.     | 동기 Server Components에서 Prop-drilling 없이 `useIntlayer`를 직접 호출 가능. 지연 없는 서버 렌더링, 전용 라우팅 미들웨어, 실시간 비주얼 CMS 동기화 지원. |
-| 2024년 9월  | `gt-next`                                   | AI 기술을 활용하여 Next.js의 다국어 콘텐츠 생성과 동적 로컬라이즈드 라우팅을 자동화.            | 클라우드 기반 기계 번역과 Next.js 엣지 미들웨어 및 캐시 계층을 결합한 App Router 통합.                                                                    |
+| 첫 출시     | 라이브러리                                  | 작성자                                                       | 주요 해결 과제                                                                                  | 핵심 혁신 요소                                                                                                                                            |
+| ----------- | ------------------------------------------- | ------------------------------------------------------------ | ----------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 2018년 11월 | `next-i18next`                              | Isaac Hinman (`@isaachinman`)                                | Next.js Pages Router에서 클라이언트 폭포수(waterfall) 요청 없이 `i18next` 기반 SSR 및 SSG 지원. | 페이지 Props를 통해 지역화된 네임스페이스를 전달하는 `serverSideTranslations` 및 `appWithTranslation`.                                                    |
+| 2020년 12월 | `next-translate`                            | Arvin Wiyono (`@arvinn`) / Vinissimus (`@vinissimus`)        | Pages Router 기반 애플리케이션의 설정 복잡도를 낮추고 번들 크기를 축소.                         | 페이지별로 실제 필요한 번역 네임스페이스만 빌드 시점에 선별 주입하는 Webpack 로더 플러그인.                                                               |
+| 2020년 12월 | `next-intl`                                 | Jan Amann (`@amannn`)                                        | Next.js App Router, React Server Components (RSC), 스트리밍 SSR 패러다임에 맞춘 국제화 재설계.  | 클라이언트 JS를 전송하지 않고도 Next.js App Router 미들웨어, Server Actions, 비동기 Server Components와 자연스럽게 결합.                                  |
+| 2022년 7월  | `next-international`                        | Tom Dussaix (`@tom-dussaix`)                                 | 클라이언트 번들 오버헤드를 최소화하면서 Next.js에 엄격한 TypeScript 타입 안정성 제공.           | 스코프가 지정된 번역 키에 대한 정밀한 타입 생성과 App Router 및 Pages Router용 초경량 어댑터.                                                             |
+| 2023년 10월 | `paraglide-next` (`@inlang/paraglide-next`) | Samuel Stroschein (`@samuelstroschein`) / Inlang (`@inlang`) | 런타임 라이브러리가 필요 없는 사전 컴파일 메시지를 Next.js App Router 및 Pages Router에 도입.   | 미들웨어 라우팅과 Tree-shaking 가능한 함수를 결합하여 RSC 및 클라이언트 번들에서 런타임 JSON 파싱을 완전히 배제.                                          |
+| 2024년 8월  | `next-intlayer`                             | Aymeric Pineau (`@aymericzip`)                               | 컴포넌트 간 `t()` 함수나 번역 사전을 Props로 연쇄 전달(Prop-drilling)해야 하는 불편함 해소.     | 동기 Server Components에서 Prop-drilling 없이 `useIntlayer`를 직접 호출 가능. 지연 없는 서버 렌더링, 전용 라우팅 미들웨어, 실시간 비주얼 CMS 동기화 지원. |
+| 2024년 7월  | `gt-next`                                   | Ernest McCarter (`@eoinest`)                                 | AI 기술을 활용하여 Next.js의 다국어 콘텐츠 생성과 동적 로컬라이즈드 라우팅을 자동화.            | 클라우드 기반 기계 번역과 Next.js 엣지 미들웨어 및 캐시 계층을 결합한 App Router 통합.                                                                    |
 
 </Tab>
 
 <Tab label="Vue & Nuxt" value="vue">
 
-| 첫 출시     | 라이브러리     | 주요 해결 과제                                                                               | 핵심 혁신 요소                                                                                                                           |
-| ----------- | -------------- | -------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
-| 2014년 5월  | `vue-i18n`     | Vue 생태계의 철학에 부합하는 직관적이고 반응형 중심의 국제화 환경 구축.                      | Vue 반응성 시스템과의 일체화, 템플릿 디렉티브(`v-t`), `$t` 헬퍼, 단일 파일 컴포넌트(SFC) 전용 `<i18n>` 커스텀 블록 제공.                 |
-| 2017년 11월 | `@nuxt/i18n`   | Nuxt 기반 프로젝트의 지역화된 URL 라우팅, SEO hreflang 태그, SSR 하이드레이션 무결성 관리.   | 접두사 및 도메인 기반의 라우트 자동 생성, SEO 메타 헤더 제어, 언어 청크 지연 로딩을 아우르는 풀스택 라우팅 모듈.                         |
-| 2019년 8월  | `fluent-vue`   | Vue 내에서 복잡한 문법적 성별, 격 변화, 비대칭적 자연어 구조를 매끄럽게 지원.                | Mozilla의 Project Fluent 문법을 Vue에 통합하여 미묘한 언어적 차이를 위한 복잡한 조건문 작성을 방지.                                      |
-| 2025년 4월  | `vue-intlayer` | 전역 네임스페이스 오염 없이 Vue 3 Composition API 및 Nuxt에 최적화된 네이티브 Intlayer 지원. | Vue 3 반응성 추적에 맞춤 설계된 `useIntlayer` Composable, 명확한 컴포넌트 스코프 분리, 완벽한 TypeScript 자동완성 및 비주얼 에디터 지원. |
+| 첫 출시     | 라이브러리     | 작성자                                      | 주요 해결 과제                                                                               | 핵심 혁신 요소                                                                                                                           |
+| ----------- | -------------- | ------------------------------------------- | -------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
+| 2014년 5월  | `vue-i18n`     | Kazupon (`@kazupon`)                        | Vue 생태계의 철학에 부합하는 직관적이고 반응형 중심의 국제화 환경 구축.                      | Vue 반응성 시스템과의 일체화, 템플릿 디렉티브(`v-t`), `$t` 헬퍼, 단일 파일 컴포넌트(SFC) 전용 `<i18n>` 커스텀 블록 제공.                 |
+| 2017년 11월 | `@nuxt/i18n`   | Nuxt 커뮤니티                               | Nuxt 기반 프로젝트의 지역화된 URL 라우팅, SEO hreflang 태그, SSR 하이드레이션 무결성 관리.   | 접두사 및 도메인 기반의 라우트 자동 생성, SEO 메타 헤더 제어, 언어 청크 지연 로딩을 아우르는 풀스택 라우팅 모듈.                         |
+| 2020년 8월  | `fluent-vue`   | Mozilla (`@mozilla`) / Demivan (`@demivan`) | Vue 내에서 복잡한 문법적 성별, 격 변화, 비대칭적 자연어 구조를 매끄럽게 지원.                | Mozilla의 Project Fluent 문법을 Vue에 통합하여 미묘한 언어적 차이를 위한 복잡한 조건문 작성을 방지.                                      |
+| 2025年 1월  | `vue-intlayer` | Aymeric Pineau (`@aymericzip`)              | 전역 네임스페이스 오염 없이 Vue 3 Composition API 및 Nuxt에 최적화된 네이티브 Intlayer 지원. | Vue 3 반응성 추적에 맞춤 설계된 `useIntlayer` Composable, 명확한 컴포넌트 스코프 분리, 완벽한 TypeScript 자동완성 및 비주얼 에디터 지원. |
 
 </Tab>
 
 <Tab label="Angular" value="angular">
 
-| 첫 출시    | 라이브러리          | 주요 해결 과제                                                                        | 핵심 혁신 요소                                                                                                    |
-| ---------- | ------------------- | ------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
-| 2017년 2월 | `ngx-translate`     | 언어별로 빌드 결과물을 별도 분리하지 않고 Angular 런타임에서 동적 번역 제공.          | 동적 번역 로딩과 실시간 언어 전환을 가능하게 하는 `TranslateService` 및 `translate` 파이프.                       |
-| 2019년 7월 | `@ngneat/transloco` | 구형 Angular i18n 라이브러리들의 성능 저하, 스코프 격리 부재, 편의 기능 미비를 개선.  | 구조적 디렉티브(`*transloco`), 지연 로딩 모듈을 위한 번역 스코프 격리, SSR 지원 및 텍스트 추출 CLI.               |
-| 2019년 9월 | `@angular/localize` | 언어마다 TypeScript 전체를 재컴파일하는 낭비를 줄이고 내장 i18n 시스템을 현대화.      | 빌드 후처리 단계에서 Ivy 컴파일러가 신속하게 치환하는 태그 템플릿 리터럴 `$localize`.                             |
-| 2021년 2월 | `@tolgee/ngx`       | 인터페이스 상에서의 실시간 번역 협업과 스크린샷 저장을 Angular 워크플로에 도입.       | Tolgee 플랫폼과 직접 연동되어 브라우저 상에서 텍스트를 즉시 편집할 수 있는 Angular 파이프 및 디렉티브.            |
-| 2025년 4월 | `angular-intlayer`  | 모던 Angular(Signals, Standalone 컴포넌트, SSR)에 특화된 네이티브 Intlayer 환경 구축. | Angular 변경 감지 시스템에 최적화된 Signal 기반 반응형 바인딩, Standalone DI 호환, 비주얼 CMS 실시간 동기화 지원. |
+| 첫 출시    | 라이브러리          | 작성자                                                       | 주요 해결 과제                                                                        | 핵심 혁신 요소                                                                                                    |
+| ---------- | ------------------- | ------------------------------------------------------------ | ------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
+| 2017년 2월 | `ngx-translate`     | Olivier Combe (`@ocombe`)                                    | 언어별로 빌드 결과물을 별도 분리하지 않고 Angular 런타임에서 동적 번역 제공.          | 동적 번역 로딩과 실시간 언어 전환을 가능하게 하는 `TranslateService` 및 `translate` 파이프.                       |
+| 2019년 7월 | `@ngneat/transloco` | Netanel Basal (`@NetanelBasal`) & Shahar Kazaz (`@shahar_k`) | 구형 Angular i18n 라이브러리들의 성능 저하, 스코프 격리 부재, 편의 기능 미비를 개선.  | 구조적 디렉티브(`*transloco`), 지연 로딩 모듈을 위한 번역 스코프 격리, SSR 지원 및 텍스트 추출 CLI.               |
+| 2019년 9월 | `@angular/localize` | Angular 팀 (@angular)                                        | 언어마다 TypeScript 전체를 재컴파일하는 낭비를 줄이고 내장 i18n 시스템을 현대화.      | 빌드 후처리 단계에서 Ivy 컴파일러가 신속하게 치환하는 태그 템플릿 리터럴 `$localize`.                             |
+| 2021년 2월 | `@tolgee/ngx`       | Jan Cizmar (`@jcizmar`)                                      | 인터페이스 상에서의 실시간 번역 협업과 스크린샷 저장을 Angular 워크플로에 도입.       | Tolgee 플랫폼과 직접 연동되어 브라우저 상에서 텍스트를 즉시 편집할 수 있는 Angular 파이프 및 디렉티브.            |
+| 2026년 3월 | `angular-intlayer`  | Aymeric Pineau (`@aymericzip`)                               | 모던 Angular(Signals, Standalone 컴포넌트, SSR)에 특화된 네이티브 Intlayer 환경 구축. | Angular 변경 감지 시스템에 최적화된 Signal 기반 반응형 바인딩, Standalone DI 호환, 비주얼 CMS 실시간 동기화 지원. |
 
 </Tab>
 
 <Tab label="Svelte & SvelteKit" value="svelte">
 
-| 첫 출시     | 라이브러리        | 주요 해결 과제                                                                          | 핵심 혁신 요소                                                                                                         |
-| ----------- | ----------------- | --------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
-| 2018년 7월  | `svelte-i18n`     | Svelte의 반응형 Store 철학에 어울리는 선언적 다국어 라이브러리 제공.                    | Store 기반의 `$t` 조회를 통해 언어가 변경될 때 대상 DOM만 정밀하고 기민하게 업데이트.                                  |
-| 2021년 12월 | `sveltekit-i18n`  | SvelteKit 애플리케이션에서 SSR과 라우트 기반 번역 파일 로딩을 깔끔하게 처리.            | 활성화된 라우트에 실제로 필요한 텍스트 및 포맷터만 선별하여 가져오는 모듈식 로더 아키텍처.                             |
-| 2021년 11월 | `@tolgee/svelte`  | Svelte 환경에서 실제 화면 컨텍스트를 보며 작업하는 인컨텍스트 번역 구현.                | Tolgee 인컨텍스트 오버레이 및 자동 스크린샷 캡처 기능과 직결된 Svelte Store 바인딩.                                    |
-| 2025년 4월  | `svelte-intlayer` | Svelte 5의 Runes 문법 및 SvelteKit에 최적화된 고성능 Intlayer 구현체 제공.              | Svelte 5 Runes(`$state`)에 맞춘 반응형 바인딩, 컴포넌트 단위의 `.content` 선언, 무설정 빌드 플러그인, 비주얼 CMS 지원. |
-| 2025년 7월  | `@wuchale/svelte` | Svelte 컴포넌트에서 사전을 별도 선언하고 `$t` 함수를 반복적으로 임포트하는 수고를 배제. | 빌드 타임에 템플릿을 직접 파싱하여 텍스트 노드를 래퍼 없는 로컬라이즈드 결과물로 컴파일하는 Svelte 프리프로세서.       |
+| 첫 출시     | 라이브러리        | 작성자                         | 주요 해결 과제                                                                          | 핵심 혁신 요소                                                                                                         |
+| ----------- | ----------------- | ------------------------------ | --------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
+| 2018년 7월  | `svelte-i18n`     | Kaisermann (`@kaisermann`)     | Svelte의 반응형 Store 철학에 어울리는 선언적 다국어 라이브러리 제공.                    | Store 기반의 `$t` 조회를 통해 언어가 변경될 때 대상 DOM만 정밀하고 기민하게 업데이트.                                  |
+| 2021년 12월 | `sveltekit-i18n`  | Ivan Fevrier (`@ivanfevrier`)  | SvelteKit 애플리케이션에서 SSR과 라우트 기반 번역 파일 로딩을 깔끔하게 처리.            | 활성화된 라우트에 실제로 필요한 텍스트 및 포맷터만 선별하여 가져오는 모듈식 로더 아키텍처.                             |
+| 2021년 11월 | `@tolgee/svelte`  | Jan Cizmar (`@jcizmar`)        | Svelte 환경에서 실제 화면 컨텍스트를 보며 작업하는 인컨텍스트 번역 구현.                | Tolgee 인컨텍스트 오버레이 및 자동 스크린샷 캡처 기능과 직결된 Svelte Store 바인딩.                                    |
+| 2025년 10월 | `svelte-intlayer` | Aymeric Pineau (`@aymericzip`) | Svelte 5의 Runes 문법 및 SvelteKit에 최적화된 고성능 Intlayer 구현체 제공.              | Svelte 5 Runes(`$state`)에 맞춘 반응형 바인딩, 컴포넌트 단위의 `.content` 선언, 무설정 빌드 플러그인, 비주얼 CMS 지원. |
+| 2025년 7월  | `@wuchale/svelte` | Kidus Adugna (`@K1DV5`)        | Svelte 컴포넌트에서 사전을 별도 선언하고 `$t` 함수를 반복적으로 임포트하는 수고를 배제. | 빌드 타임에 템플릿을 직접 파싱하여 텍스트 노드를 래퍼 없는 로컬라이즈드 결과물로 컴파일하는 Svelte 프리프로세서.       |
 
 </Tab>
 
 <Tab label="SolidJS" value="solid">
 
-| 첫 출시    | 라이브러리               | 주요 해결 과제                                                                           | 핵심 혁신 요소                                                                                        |
-| ---------- | ------------------------ | ---------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
-| 2021년 9월 | `@solid-primitives/i18n` | SolidJS의 세밀한(fine-grained) 반응성에 완벽하게 부합하는 네이티브 i18n 프리미티브 제공. | 가상 DOM이나 불필요한 재렌더링 없이 DOM 노드를 직접 업데이트하는 Signal 기반 번역 리졸버.             |
-| 2025년 4월 | `solid-intlayer`         | SolidJS 및 SolidStart의 아키텍처에 맞추어 설계된 네이티브 고성능 Intlayer 솔루션 제공.   | 가상 DOM 오버헤드를 배제한 Signal 최적화 바인딩, TypeScript 스키마 기반 자동완성, 비주얼 에디터 지원. |
-| 2026년 6월 | `@lingui/solid`          | 빌드 타임 매크로 추출 방식과 정교한 ICU MessageFormat 문법 지원을 SolidJS 생태계로 확장. | Solid의 세밀한 반응성에 맞춘 매크로 변환을 통해 메시지를 런타임 부담이 적은 간결한 구조로 컴파일.     |
+| 첫 출시    | 라이브러리               | 작성자                         | 주요 해결 과제                                                                           | 핵심 혁신 요소                                                                                        |
+| ---------- | ------------------------ | ------------------------------ | ---------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
+| 2021년 9월 | `@solid-primitives/i18n` | SolidJS 커뮤니티               | SolidJS의 세밀한(fine-grained) 반응성에 완벽하게 부합하는 네이티브 i18n 프리미티브 제공. | 가상 DOM이나 불필요한 재렌더링 없이 DOM 노드를 직접 업데이트하는 Signal 기반 번역 리졸버.             |
+| 2025년 7월 | `solid-intlayer`         | Aymeric Pineau (`@aymericzip`) | SolidJS 및 SolidStart의 아키텍처에 맞추어 설계된 네이티브 고성능 Intlayer 솔루션 제공.   | 가상 DOM 오버헤드를 배제한 Signal 최적화 바인딩, TypeScript 스키마 기반 자동완성, 비주얼 에디터 지원. |
+| 2026년 6월 | `@lingui/solid`          | Tomáš Ehrlich (`@tricoder42`)  | 빌드 타임 매크로 추출 방식과 정교한 ICU MessageFormat 문법 지원을 SolidJS 생태계로 확장. | Solid의 세밀한 반응성에 맞춘 매크로 변환을 통해 메시지를 런타임 부담이 적은 간결한 구조로 컴파일.     |
 
 </Tab>
 
@@ -237,7 +237,7 @@ Jan Mühlemann은 고차 컴포넌트(`withTranslation`)와 React Context를 도
 
 ## JavaScript i18n의 네 가지 아키텍처 시대
 
-![JavaScript i18n 라이브러리 기술 발전도](https://github.com/aymericzip/intlayer/blob/main/docs/assets/history_i18n.png?raw=true)
+![JavaScript i18n 라이브러리 기술 발전도](https://github.com/aymericzip/intlayer/blob/main/docs/assets/history_i18n.webp?raw=true)
 
 지난 15년간의 기술 흐름을 종합하면, JavaScript 국제화는 크게 네 가지 아키텍처 시대로 구분할 수 있습니다.
 
@@ -287,7 +287,7 @@ Jan Mühlemann은 고차 컴포넌트(`withTranslation`)와 React Context를 도
 
 대규모 언어 모델이 높은 언어적 정확도를 유지하면서도 번역 단가를 극소 단위로 낮춤에 따라 새로운 도구들이 등장했습니다.
 
-- Paraglide의 **linguo.dev**나 **General Translation** (`gt-react`, `gt-next`) 같은 플랫폼들은 전용 구독 티어와 클라우드 중계 파이프라인을 구성했습니다.
+- **lingo.dev**나 **General Translation** (`gt-react`, `gt-next`) 같은 플랫폼들은 전용 구독 티어와 클라우드 중계 파이프라인을 구성했습니다.
 - 반면 **Intlayer**는 오픈소스 CLI를 통해 AI 번역 기능을 기본 제공하며, 팀이 보유한 자체 API 키(OpenAI, Anthropic, Mistral, Google Gemini 등)를 직접 연결할 수 있도록 지원합니다. 중개 수수료나 플랫폼 종속 없이, 선택한 AI 제공업체의 순수 호출 원가만으로 운영할 수 있습니다.
 
 ### i18n을 넘어: 종합적인 다국어 콘텐츠 시스템으로