@intlayer/docs 9.5.2 → 9.5.4-canary.0

package/blog/it/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: Stessa API, Bundle Diverso"
+description: Cosa cambia quando un'app Vue 3 mantiene le sue chiamate vue-i18n ma le serve tramite l'adapter di compatibilità @intlayer/vue-i18n. JavaScript per pagina, dimensione runtime, dimensione dei componenti e leakage misurati sullo stesso codice Vite + Vue, più ciò che l'adapter mantiene, ignora e non può sostituire.
+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 | Stessa API, Bundle Diverso
+
+`@intlayer/vue-i18n` è un adapter di compatibilità: espone l'API di `vue-i18n` (`createI18n`, `useI18n`, `t()`, `d()`, `n()`, `$t`, `v-t`, `i18n.global.locale`...) e la serve dai dizionari compilati da Intlayer. I tuoi file `.vue` non cambiano. Cambia solo ciò a cui `t("footer.github")` è associato.
+
+Questo articolo misura tale sostituzione sulla stessa applicazione Vite + Vue 3, costruita una volta con `vue-i18n` e una volta con l'adapter. I numeri provengono da [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom). Per `vue-i18n` e Intlayer confrontati come librerie, leggi [vue-i18n vs Intlayer](https://intlayer.org/blog/vue-i18n-vs-intlayer) e il [vue-i18n vs Intlayer benchmark](https://intlayer.org/blog/vue-i18n-vs-intlayer-benchmark). Questo riguarda ciò che l'adapter cambia quando mantieni i tuoi componenti così come sono.
+
+<TOC/>
+
+> **tl;dr**: Sulla stessa app Vite + Vue 3, sostituire `vue-i18n` con `@intlayer/vue-i18n` ha ridotto il JavaScript per pagina da **134.9 KB a 47.0 KB** gzip (l'app senza i18n pesa 41.3 KB), il runtime da **24.3 KB a 7.9 KB**, il componente medio da **196 KB a 8.4 KB**, e la perdita di stringhe di pagine straniere da **90% a 0%**, senza modificare nessun file `.vue`. `createI18n({ messages })` continua a funzionare come fallback; rimuovi gli import JSON per ottenere i numeri di cui sopra. I blocchi SFC `<i18n>` e il runtime `setLocaleMessage()` sono le due funzionalità che non vengono trasferite.
+
+## Cos'è `@intlayer/vue-i18n`
+
+`vue-i18n` è un runtime. `createI18n({ messages: { en, fr, ... } })` costruisce un'istanza globale che contiene ogni messaggio di ogni locale; `useI18n()` collega ogni componente ad essa; `t("footer.github")` percorre l'albero al momento del rendering. Questo design è ciò che rende possibili i blocchi SFC `<i18n>` e `setLocaleMessage()`, ed è anche il motivo per cui il grafico delle dipendenze di ogni componente include l'intero albero.
+
+`@intlayer/vue-i18n` mantiene l'API e sostituisce l'albero:
+
+1. **Import aliasing.** `vueI18nVitePlugin()` da `@intlayer/vue-i18n/plugin` avvolge `vite-intlayer` e aggiunge un `resolve.alias` in modo che `vue-i18n` si risolva a `@intlayer/vue-i18n`. Nessun import viene rinominato.
+2. **JSON come fonte della verità.** Il plugin `syncJSON` legge il tuo `locales/{locale}.json` esistente con `format: "vue-i18n"` (in modo che `{name}`, `{0}` l'interpolazione di lista e `"car | cars"` i plurali con pipe siano analizzati correttamente) e riscrive le traduzioni quando la CLI o il CMS le aggiorna.
+3. **Binding nel sito di chiamata.** Il pass di ottimizzazione di Intlayer riscrive i siti di chiamata `useI18n()` in modo che il componente riceva i dizionari i cui nomi di chiavi, nella locale attiva, come importazioni che il bundler può tracciare e dividere.
+
+```vue fileName="src/components/Footer.vue"
+<!-- Il tuo codice, invariato -->
+<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="Ciò che il compilatore emette (semplificato)"
+import _dicHash_footer from "../.intlayer/dictionaries/footer.mjs";
+import { useDictionary as useI18n } from "@intlayer/vue-i18n";
+
+const { t } = useI18n(_dicHash_footer);
+```
+
+Il componente non raggiunge più l'albero dei messaggi globali. Raggiunge `footer`. Ecco perché la colonna component-size qui sotto scende da 196 KB a 8 KB.
+
+## Cosa mantiene l'adapter, cosa ignora e cosa non sostituisce
+
+| API `vue-i18n`                                                      | Con `@intlayer/vue-i18n`                                                                                                                  |
+| ------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
+| `useI18n()` → `{ t, d, n, te, tm, rt, locale, availableLocales }`   | ✅ Mantenuto. Le chiavi `t` sono tipizzate rispetto ai tuoi dizionari                                                                     |
+| `t("key", { name })`, `t("key", [a, b])`, `t("key", count)`         | ✅ Mantenuto. `{name}`, `{0}` e i plurali separati da pipe si risolvono come prima                                                        |
+| `d(date, "long")`, `n(value, "currency")`                           | ✅ Mantenuto. I `datetimeFormats` / `numberFormats` da `createI18n()` sono rispettati, supportati da `Intl` nativo                        |
+| `i18n.global.locale.value = "fr"`                                   | ✅ Mantenuto. Un `WritableComputedRef` supportato da Intlayer's client; la reattività si comporta come prima                              |
+| `$t`, `$tc`, `$te`, `$tm`, `$rt`, `$d`, `$n`, `$i18n` (Options API) | ✅ Mantenuto. Registrato su `app.config.globalProperties` da `app.use(i18n)`                                                              |
+| `v-t` directive                                                     | ✅ Mantenuto                                                                                                                              |
+| `legacy: true`                                                      | ✅ Accettato                                                                                                                              |
+| `createI18n({ messages })`                                          | ⚠️ I `messages` vengono utilizzati come **fallback runtime** con un avviso di sviluppo. Rimuovi gli import JSON per i guadagni nel bundle |
+| `setLocaleMessage()`, `mergeLocaleMessage()`                        | ❌ Avviso e nessuna azione. Il caricamento dei messaggi runtime è sostituito da dizionari in fase di build                                |
+| SFC `<i18n>` custom blocks                                          | ❌ Non letti. Sposta quei messaggi nel JSON locale (o in un `.content.ts` accanto al componente)                                          |
+| `@nuxtjs/i18n`                                                      | ⚠️ Adapter separato, vedi la [documentazione di compatibilità Nuxt](https://intlayer.org/doc/compatibility/nuxtjs-i18n)                   |
+
+## Il benchmark
+
+### Cosa è stato misurato
+
+La suite [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom) costruisce **la stessa applicazione Vite + Vue 3** con ogni setup: **10 pagine** (home, about, blog, careers, contact, FAQ, pricing, products, settings, team), **10 locales** (`en`, `fr`, `es`, `de`, `it`, `pt`, `zh`, `ja`, `ko`, `ru`), componenti identici e contenuti identici. Le pagine vengono misurate in `en` e `fr`.
+
+Entrambi sono stati costruiti nella configurazione **statica**, quella che la maggior parte dei progetti Vue utilizza: per `vue-i18n`, ogni JSON della locale importato e passato a `createI18n({ messages })`; per l'adapter, gli stessi componenti con `vite.config.ts` e `intlayer.config.ts` modificati e l'import di `messages` rimosso. Il nativo `vue-intlayer` è incluso come riferimento.
+
+Per ogni build, la suite registra:
+
+- **Lib size**: dimensione gzip (e minificata) di un componente vuoto che importa solo la libreria i18n.
+- **Page JS**: gzip JavaScript scaricato per pagina, mediato su tutte le pagine e le lingue.
+- **Locale leak %**: quota di stringhe tradotte nel JS scaricato che appartengono a una lingua che l'utente **non** sta visualizzando.
+- **Page leak %**: quota di stringhe tradotte nel JS scaricato che appartengono a una pagina su cui l'utente **non** si trova.
+- **Component avg**: dimensione gzip media di ogni componente compilato in isolamento.
+- **E2E reactivity**: tempo reale tra la selezione di una nuova lingua e l'aggiornamento di `html[lang]` nel DOM (Playwright, 5 iterazioni).
+- **Page load**: `PerformanceNavigationTiming.duration`.
+
+> I numeri sottostanti provengono dall'esecuzione del **2026-09-12** con `vue-i18n` 11.4.0 e `@intlayer/vue-i18n` 9.5.1. L'applicazione di test è deliberatamente piccola (poche decine di stringhe per locale), quindi le percentuali di dispersione descrivono un **pattern**: crescono con i tuoi contenuti mentre il costo runtime rimane fisso.
+
+### Risultati su 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 |
+
+> La colonna page-leak dell'app di base è lasciata vuota: senza una libreria i18n, il fingerprinting raccoglie stringhe hardcoded nei chunk condivisi e il numero non è significativo.
+
+**Come leggerlo**
+
+- **88 KB in meno per pagina, stessi componenti.** `vue-i18n` porta l'app di 41.3 KB a **134.9 KB**. La build dell'adapter degli stessi componenti arriva a **47.0 KB**, 5.7 KB in più dell'app di base. La maggior parte della differenza sono i 74.9 KB di `src/locales` che `createI18n({ messages })` inserisce in ogni pagina e l'adapter non raggruppa mai come blocco.
+- **Il runtime si riduce di 3x.** Un componente vuoto che importa solo `vue-i18n` costa **24.3 KB gzip / 83.2 KB minified**: `@intlify/core-base`, il message compiler e il runtime. L'adapter costa **7.9 KB / 23.2 KB**, la maggior parte è il core di Intlayer più la superficie API di `vue-i18n`.
+- **Componenti: 23x più piccoli.** Un componente `useI18n()` compilato in isolamento pesa in media **196 KB**, perché `t` è legato all'istanza che contiene ogni messaggio di ogni locale. Con l'adapter, lo stesso componente pesa in media **8.4 KB**: raggiunge il suo dizionario.
+- **Perdite di dati.** `vue-i18n` spedisce ogni locale e le stringhe di ogni pagina su ogni pagina: perdita di locale del 50% (sui due locale fingerprinted; con dieci locale bundled lo spreco reale è più alto), perdita di pagina del 90%. L'adapter riduce la perdita di pagina a **0%** perché ogni componente importa solo i suoi dizionari. La perdita di locale si attesta al 15% in questa esecuzione `static`; `importMode: 'dynamic'` è l'impostazione che la elimina, e quella configurazione non faceva parte di questa esecuzione Vue.
+- **Reattività e caricamento della pagina.** Il cambio di locale è economico per entrambi (1,5-2,8 ms); il sistema di reattività di Vue lo rende così una volta che i messaggi sono in memoria. Il caricamento della pagina passa da 13,6 ms a **9,3 ms**, in linea con 88 KB di JavaScript in meno da analizzare.
+- **Informazioni sulle righe native.** `vue-intlayer` in questa esecuzione ha raggruppato ogni locale in modalità `static` e ha raggiunto 57.1 KB con un runtime di 3.9 KB; i dizionari sincronizzati dell'adapter hanno portato meno stringhe di locale straniere, da qui la cifra più bassa per pagina. Il runtime nativo rimane il più leggero dei tre, e il suo modello `.content.ts` è dove i blocchi SFC `<i18n>` trovano il loro equivalente.
+
+## Perché i numeri cambiano
+
+Nulla in `src/components/` è cambiato, quindi i miglioramenti provengono da ciò a cui `useI18n` è vincolato.
+
+**Con `vue-i18n`**, il binding è l'istanza globale. `createI18n({ messages: { en, fr, ... } })` è un unico import che contiene tutto; ogni componente che chiama `useI18n()` può accedere a tutto, quindi il bundler non può fare splitting al di sotto dell'istanza. Ottimizzare significa che _tu_ dividi `en.json` per route, chiami `setLocaleMessage()` in un router guard, e mantenere corretta la mappa route-to-file mentre i componenti si muovono.
+
+```bash
+.
+├── locales
+│   ├── en.json                    # stringhe di ogni pagina
+│   └── fr.json
+└── src
+    ├── i18n.ts                    # createI18n({ messages: { en, fr, ... } })
+    ├── main.ts                    # app.use(i18n)
+    └── components
+        └── Footer.vue             # useI18n(); t("footer.github")
+```
+
+**Con `@intlayer/vue-i18n`**, il binding è il dizionario. `syncJSON` trasforma ogni chiave di primo livello di `en.json` in un dizionario; il passo di ottimizzazione passa al componente quelli i cui nomi chiave, mentre importa quelli che il bundler traccia e divide per pagina.
+
+```bash
+.
+├── intlayer.config.ts             # syncJSON({ format: "vue-i18n", source: ... })
+├── locales
+│   ├── en.json                    # unchanged, still the source of truth
+│   └── fr.json
+├── .intlayer/                     # generated: one dictionary per top-level key, per locale
+└── src
+    ├── i18n.ts                    # createI18n({})   ← messages import removed
+    ├── main.ts                    # app.use(i18n)    ← unchanged
+    └── components
+        └── Footer.vue             # useI18n(); t("footer.github")  ← unchanged
+```
+
+L'import `messages` in `i18n.ts` è la sola riga da eliminare. Sono i 88 KB.
+
+## Migrazione in tre step
+
+<Steps>
+<Step number={1} title="Installazione">
+
+```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
+```
+
+Il comando rileva `vue-i18n`, installa `intlayer`, `vue-intlayer`, `@intlayer/vue-i18n` e `@intlayer/sync-json-plugin`, e pre-compila `intlayer.config.ts`. Mantieni `vue-i18n` installato: è una peer dependency e fornisce i tipi.
+
+</Step>
+<Step number={2} title="Indirizza Intlayer ai tuoi file locale">
+
+```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" raggruppa ogni locale; "dynamic" carica quello attivo su richiesta
+    importMode: "dynamic",
+    format: "vue-i18n",
+  },
+  plugins: [
+    syncJSON({
+      // dialetto vue-i18n: {name}, {0}, "car | cars"
+      format: "vue-i18n",
+      source: ({ locale }) => `./locales/${locale}.json`,
+      location: "locales",
+    }),
+  ],
+};
+
+export default config;
+```
+
+`locales/{locale}.json` rimane dove si trova. Ogni chiave di primo livello (`footer`, `hero`...) diventa un dizionario.
+
+</Step>
+<Step number={3} title="Aggiungi il plugin e rimuovi l'importazione dei messaggi">
+
+```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";
+
+// Prima: createI18n({ locale: "en", messages: { en, fr, es } })
+export const i18n = createI18n({ locale: "en" });
+```
+
+`vueI18nVitePlugin()` avvolge `vite-intlayer` (content watching, dictionary compilation, the optimize pass) e aliasa `vue-i18n` all'adapter. Rimuovere l'importazione di `messages` è ciò che elimina gli 88 KB; lasciarla comporta che l'app continui a funzionare ma spedisce entrambi.
+
+</Step>
+</Steps>
+
+### Cosa puoi eliminare in seguito
+
+| File / pattern                                | Perché                                                                        |
+| --------------------------------------------- | ----------------------------------------------------------------------------- |
+| `import en from "./locales/en.json"` e simili | Utilizzato solo come fallback dall'adapter. Qui era il 88 KB                  |
+| `setLocaleMessage()` nei router guard         | No-op. Il caricamento per-route è ora compito del compiler                    |
+| `@intlify/unplugin-vue-i18n`                  | Non necessario: precompila i messaggi e i blocchi SFC che l'adapter non legge |
+| Blocchi SFC `<i18n>`                          | Non letti; spostali nel JSON locale o in un `.content.ts` per componente      |
+
+### Cosa guadagni oltre ai byte
+
+- **Chiavi tipizzate.** `t("footer.github")` è tipizzata rispetto al dizionario `footer` compilato; un percorso errato è un errore TypeScript anziché la chiave renderizzata come testo.
+- **`npx intlayer test`** fa fallire la CI su una chiave mancante in qualsiasi locale. **`npx intlayer fill`** traduce quelle mancanti con la tua chiave provider (OpenAI, Anthropic, Mistral, Gemini...) e le riscrive in `locales/{locale}.json`.
+- **Visual Editor e CMS** operano sullo stesso JSON, quindi i non sviluppatori modificano tramite un'interfaccia utente e i file si aggiornano.
+- **Migrazione incrementale a `.content.ts`.** Qualsiasi componente può passare da `useI18n()` a `useIntlayer("footer")` con un file di contenuto co-locato. I dizionari JSON e `.content.ts` coesistono e si uniscono.
+
+## Limiti da conoscere prima di iniziare
+
+- **I blocchi SFC `<i18n>` non vengono letti.** Se i tuoi messaggi risiedono all'interno dei componenti, devono spostarsi nei file locale (o in `.content.ts`, che è la stessa idea con i tipi).
+- **Il caricamento dei messaggi in runtime è scomparso.** `setLocaleMessage()` e `mergeLocaleMessage()` avvisano e tornano. Le traduzioni recuperate da un CMS in runtime hanno bisogno del CMS di Intlayer, o dei comandi `intlayer pull` / `push`.
+- **`messages` è un fallback, non gratuito.** Mantenere gli import JSON in `createI18n()` mantiene i 75 KB nel bundle. Eliminali una volta che `intlayer test` passa.
+- **L'adapter non è il runtime nativo.** 7.9 KB contro 3.9 KB per `vue-intlayer`. Una volta che ogni componente è passato a `useIntlayer`, eliminalo.
+
+## Quando usare quale?
+
+- **Rimani su `vue-i18n`** se la tua app dipende dai blocchi `<i18n>` SFC, dai flussi `setLocaleMessage()` a runtime, o se 90 KB per pagina non è una preoccupazione per il tuo pubblico.
+- **Usa `@intlayer/vue-i18n`** se sei su `vue-i18n` e vuoi i 88 KB, i componenti 23 volte più piccoli, 0% page leakage, chiavi tipizzate e controlli CI senza modificare un file `.vue`. Questo è il punto di ingresso per una codebase `vue-i18n` esistente.
+- **Vai nativo (`vue-intlayer`)** per i nuovi progetti, o una volta che l'adapter ha fatto il suo lavoro. Ha il runtime più leggero (3.9 KB) e il modello `.content.ts` per componente che sostituisce i blocchi `<i18n>` con contenuto tipizzato.
+
+## Confronti correlati
+
+- [vue-i18n vs Intlayer](https://intlayer.org/blog/vue-i18n-vs-intlayer) (funzionalità e DX)
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/blog/vue-i18n-vs-intlayer-benchmark) (le librerie, stesso benchmark)
+- [next-intl vs @intlayer/next-intl](https://intlayer.org/blog/next-intl-vs-intlayer-next-intl) (stessa serie di adapter)
+- [i18next vs @intlayer/i18next](https://intlayer.org/blog/i18next-vs-intlayer-i18next) (stessa serie di adapter)
+- [Lingui vs @intlayer/lingui](https://intlayer.org/blog/lingui-vs-intlayer-lingui) (stessa serie di adapter)
+- [Guida alla migrazione: vue-i18n a Intlayer](https://intlayer.org/doc/migration/vue-i18n)
+- [Riferimento dell'adattatore di compatibilità: vue-i18n](https://intlayer.org/doc/compatibility/vue-i18n), [Nuxt i18n](https://intlayer.org/doc/compatibility/nuxtjs-i18n)
+
+## Conclusione
+
+`@intlayer/vue-i18n` cambia a cosa è associato `useI18n()`: da un'istanza globale che contiene ogni messaggio di ogni locale a un dizionario compilato per quel componente. Sulla stessa app Vite + Vue 3 che è **88 KB più leggera per pagina**, un runtime **3 volte più piccolo**, **componenti 23 volte più piccoli** e **0% page leakage**, per un file di configurazione, una riga di plugin e un import eliminato. I blocchi SFC `<i18n>` e il caricamento dei messaggi a runtime sono le due cose che non supporta, e il runtime nativo `vue-intlayer` rimane metà della sua dimensione.
+
+Tutti i dati grezzi, le app di test e gli script si trovano nel [repository Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom). Eseguilo tu stesso.
+
+Consulta la documentazione ['Why Intlayer?'](https://intlayer.org/doc/why) per maggiori dettagli.

package/blog/it/vue-i18n_vs_intlayer_benchmark.md

@@ -0,0 +1,34 @@
+---
+createdAt: 2026-09-13
+updatedAt: 2026-09-13
+title: "vue-i18n vs Intlayer: Benchmark 2026"
+description: vue-i18n e Intlayer misurati sulla stessa app Vite + Vue 3. Dimensione della libreria, JavaScript per pagina, content leakage, dimensione del componente e reattività del cambio locale, con i numeri spiegati.
+keywords:
+  - vue-i18n
+  - Intlayer
+  - Internationalization
+  - i18n
+  - Benchmark
+  - Bundle size
+  - Blog
+  - Vue
+  - Nuxt
+  - Vite
+  - JavaScript
+slugs:
+  - blog
+  - vue-i18n-vs-intlayer-benchmark
+author: aymericzip
+---
+
+# vue-i18n VS Intlayer | Benchmark per l'Internazionalizzazione di Vue (i18n)
+
+`vue-i18n` è la libreria i18n di riferimento per Vue. Intlayer è un'alternativa basata su compiler e scoped per componenti con un'integrazione Vue (`vue-intlayer`). Abbiamo già confrontato le loro [funzionalità e developer experience](https://intlayer.org/blog/vue-i18n-vs-intlayer). Questo articolo analizza il costo di ciascuna una volta che l'app è compilata.
+
+I dati provengono da [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), una suite open-source che compila la stessa applicazione con ogni libreria e registra ciò che il browser effettivamente scarica ed esegue.
+
+<TOC/>
+
+> **tl;dr**: Sulla stessa app Vite + Vue 3, `vue-i18n` spedisce **134.9 KB** di JavaScript gzippato per pagina rispetto ai **41.3 KB** per l'app senza i18n. Intlayer spedisce **57.1 KB**. Il runtime di `vue-i18n` da solo pesa **24.3 KB gzip** (6x i 3.9 KB di Intlayer), ogni pagina porta **90% delle stringhe di pagine estere**, e un componente compilato in isolamento trascina **196 KB** perché è legato all'albero dei messaggi globale. L'adapter `@intlayer/vue-i18n` mantiene l'API di `vue-i18n` e ha misurato **47.0 KB** per pagina.
+
+## In breve

package/blog/ja/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 @@ ICU メッセージ構文の解釈や正規表現による変数展開を実行
 
 <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` のバインディングを提供する。                            | React の変遷に追従し、Higher-Order Components から `<Trans>` JSX 補間および `useTranslation` フックへ刷新。                                                  |
-| 2018 年 1 月  | `@lingui/react`  | 実行時の ICU 解析器がクライアントバンドルに与える容量負荷を軽減する。                                                        | Babel/SWC マクロを活用し、ビルド時に `<Trans>` や `t` をコンパクトなインデックス配列へと事前変換。                                                           |
-| 2020 年 12 月 | `use-intl`       | 従来の React i18n ライブラリに代わる、軽量でフック中心、かつ型安全な代替手段を提供する。                                     | 人間工学に基づいた使いやすい `useTranslations` や `useFormatter` フックと、TypeScript との深い統合。                                                         |
-| 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` のバインディングを提供する。                            | React の変遷に追従し、Higher-Order Components から `<Trans>` JSX 補間および `useTranslation` フックへ刷新。                                                  |
+| 2018 年 1 月  | `@lingui/react`  | Tomáš Ehrlich (`@tricoder42`)  | 実行時の ICU 解析器がクライアントバンドルに与える容量負荷を軽減する。                                                        | Babel/SWC マクロを活用し、ビルド時に `<Trans>` や `t` をコンパクトなインデックス配列へと事前変換。                                                           |
+| 2020 年 12 月 | `use-intl`       | Jan Amann (`@amannn`)          | 従来の React i18n ライブラリに代わる、軽量でフック中心、かつ型安全な代替手段を提供する。                                     | 人間工学に基づいた使いやすい `useTranslations` や `useFormatter` フックと、TypeScript との深い統合。                                                         |
+| 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 において、クライアント側の連続リクエストを発生させずに `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 に最適化した国際化アーキテクチャを再構築する。 | Next.js App Router ミドルウェア、Server Actions、非同期 Server Components とネイティブに統合し、クライアント JS なしでサーバー描画を完結。                |
-| 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 としてバケツリレーする不便さを解消する。                      | 同期的な Server Components 内で Prop-drilling なしに `useIntlayer` を直接呼び出し可能。待ち時間なしのサーバー描画、専用ルーティング、CMS 即時同期を提供。 |
-| 2024 年 9 月  | `gt-next`                                   | AI 翻訳エンジンを活用し、Next.js における多言語コンテンツ生成と動的ルーティングを自動化する。                        | App Router と深く統合し、クラウドベースの機械翻訳を Next.js Edge ミドルウェアおよびキャッシュ層と直結。                                                   |
+| 初期リリース  | ライブラリ                                  | 作成者                                                       | 解決を目指した課題                                                                                                   | 主な技術的ブレイクスルー                                                                                                                                  |
+| ------------- | ------------------------------------------- | ------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 2018 年 11 月 | `next-i18next`                              | Isaac Hinman (`@isaachinman`)                                | Next.js Pages Router において、クライアント側の連続リクエストを発生させずに `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 に最適化した国際化アーキテクチャを再構築する。 | Next.js App Router ミドルウェア、Server Actions、非同期 Server Components とネイティブに統合し、クライアント JS なしでサーバー描画を完結。                |
+| 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 としてバケツリレーする不便さを解消する。                      | 同期的な Server Components 内で Prop-drilling なしに `useIntlayer` を直接呼び出し可能。待ち時間なしのサーバー描画、専用ルーティング、CMS 即時同期を提供。 |
+| 2024年7月     | `gt-next`                                   | Ernest McCarter (`@eoinest`)                                 | AI 翻訳エンジンを活用し、Next.js における多言語コンテンツ生成と動的ルーティングを自動化する。                        | App Router と深く統合し、クラウドベースの機械翻訳を Next.js Edge ミドルウェアおよびキャッシュ層と直結。                                                   |
 
 </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 用ライブラリに存在した性能面のボトルネック、スコープ分離の難しさ、機能不足を解決する。               | 構造ディレクティブ (`*transloco`)、遅延読み込みモジュール向けの翻訳分離、SSR サポート、文案抽出 CLI。                          |
-| 2019 年 9 月 | `@angular/localize` | 言語ごとに TypeScript コードを完全再コンパイルする無駄を省き、Angular 組み込みのコンパイル時 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 用ライブラリに存在した性能面のボトルネック、スコープ分離の難しさ、機能不足を解決する。               | 構造ディレクティブ (`*transloco`)、遅延読み込みモジュール向けの翻訳分離、SSR サポート、文案抽出 CLI。                          |
+| 2019 年 9 月 | `@angular/localize` | Angular チーム (@angular)                                    | 言語ごとに TypeScript コードを完全再コンパイルする無駄を省き、Angular 組み込みのコンパイル時 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 とルート単位の翻訳データ読み込みを美しく管理する。                           | アクティブな SvelteKit ルートに必要な翻訳テキストとフォーマッターのみを過不足なく取得するモジュール式ローダー設計。                              |
-| 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 とルート単位の翻訳データ読み込みを美しく管理する。                           | アクティブな SvelteKit ルートに必要な翻訳テキストとフォーマッターのみを過不足なく取得するモジュール式ローダー設計。                              |
+| 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 の極めて細粒度なリアクティビティに最適化された 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 の極めて細粒度なリアクティビティに最適化された 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 @@ ICU メッセージ構文の解釈や正規表現による変数展開を実行
 
 ## JavaScript i18n における 4 つのアーキテクチャ世代
 
-![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 における国際化のアプローチは大きく 4 つの世代に分類できます。
 
@@ -287,7 +287,7 @@ ICU メッセージ構文の解釈や正規表現による変数展開を実行
 
 大規模言語モデルの進化によって、高い翻訳精度を保ちながら 1 回あたりのコストが極小化されたことで、新たな世代のツールが登場しました。
 
-- Paraglide の **linguo.dev** や **General Translation** (`gt-react`, `gt-next`) などは、独自の有料サブスクリプションや中継クラウド基盤を通じて AI 翻訳を提供しています。
+- **lingo.dev** や **General Translation** (`gt-react`, `gt-next`) などは、独自の有料サブスクリプションや中継クラウド基盤を通じて AI 翻訳を提供しています。
 - これに対し、**Intlayer** は CLI ツールを通じて AI 自動翻訳機能をオープンソースとして直接提供しています。チームは自分たちの API キー（OpenAI、Anthropic、Mistral、Google Gemini など）を接続するだけで利用でき、手数料やベンダーロックインなしに、各プロバイダーの実費のみで翻訳パイプラインを運用できます。
 
 ### 単なる i18n を超えて：包括的な多言語コンテンツ基盤へ