@intlayer/docs 9.5.2 → 9.5.4-canary.0

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

@@ -0,0 +1,287 @@
+---
+createdAt: 2026-09-13
+updatedAt: 2026-09-13
+title: "vue-i18n vs @intlayer/vue-i18n: Même API, Bundle différent"
+description: Ce qui change quand une application Vue 3 garde ses appels vue-i18n mais les exécute via l'adaptateur de compatibilité @intlayer/vue-i18n. JavaScript par page, taille d'exécution, taille de composant et fuites mesurées sur le même code Vite + Vue, plus ce que l'adaptateur conserve, ignore et ne peut pas remplacer.
+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 | Même API, Bundle différent
+
+`@intlayer/vue-i18n` est un adaptateur de compatibilité : il expose l'API `vue-i18n` (`createI18n`, `useI18n`, `t()`, `d()`, `n()`, `$t`, `v-t`, `i18n.global.locale`...) et la sert à partir des dictionnaires compilés par Intlayer. Vos fichiers `.vue` ne changent pas. Ce à quoi `t("footer.github")` est lié, si.
+
+Cet article mesure ce changement sur la même application Vite + Vue 3, compilée une fois avec `vue-i18n` et une fois avec l'adaptateur. Les chiffres proviennent de [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom). Pour `vue-i18n` et Intlayer comparés en tant que bibliothèques, lisez [vue-i18n vs Intlayer](https://intlayer.org/blog/vue-i18n-vs-intlayer) et le [benchmark vue-i18n vs Intlayer](https://intlayer.org/blog/vue-i18n-vs-intlayer-benchmark). Celui-ci porte sur ce que l'adaptateur change lorsque vous conservez vos composants tels qu'ils sont.
+
+<TOC/>
+
+> **tl;dr**: Sur la même app Vite + Vue 3, remplacer `vue-i18n` par `@intlayer/vue-i18n` a réduit le JavaScript par page de **134.9 KB à 47.0 KB** gzip (l'app sans i18n pèse 41.3 KB), le runtime de **24.3 KB à 7.9 KB**, le composant moyen de **196 KB à 8.4 KB**, et les fuites de chaînes de caractères cross-page de **90% à 0%**, sans éditer aucun fichier `.vue`. `createI18n({ messages })` continue de fonctionner comme fallback ; supprimez les imports JSON pour obtenir les chiffres ci-dessus. Les blocs SFC `<i18n>` et le `setLocaleMessage()` au runtime sont les deux features qui ne sont pas supportées.
+
+## Ce qu'est `@intlayer/vue-i18n`
+
+`vue-i18n` est un runtime. `createI18n({ messages: { en, fr, ... } })` construit une instance globale contenant chaque message de chaque locale ; `useI18n()` lie chaque composant à celle-ci ; `t("footer.github")` parcourt l'arborescence au moment du rendu. Cette conception est ce qui rend possible les blocs SFC `<i18n>` et `setLocaleMessage()`, et c'est aussi pourquoi le graphe de dépendances de chaque composant inclut l'arborescence entière.
+
+`@intlayer/vue-i18n` conserve l'API et remplace l'arborescence :
+
+1. **Import aliasing.** `vueI18nVitePlugin()` provenant de `@intlayer/vue-i18n/plugin` enveloppe `vite-intlayer` et ajoute un `resolve.alias` afin que `vue-i18n` se résolve en `@intlayer/vue-i18n`. Aucune importation n'est renommée.
+2. **JSON as source of truth.** The `syncJSON` plugin reads your existing `locales/{locale}.json` with `format: "vue-i18n"` (so `{name}`, `{0}` list interpolation and `"car | cars"` pipe plurals are parsed correctly) and writes translations back when the CLI or the CMS updates them.
+3. **Call-site binding.** The Intlayer optimize pass rewrites `useI18n()` call sites so the component receives the dictionaries its keys name, in the active locale, as imports the bundler can trace and split.
+
+```vue fileName="src/components/Footer.vue"
+<!-- Votre code, inchangé -->
+<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="Ce que le compilateur émet (simplifié)"
+import _dicHash_footer from "../.intlayer/dictionaries/footer.mjs";
+import { useDictionary as useI18n } from "@intlayer/vue-i18n";
+
+const { t } = useI18n(_dicHash_footer);
+```
+
+Le composant n'accède plus à l'arborescence globale des messages. Il accède à `footer`. C'est pourquoi la colonne taille du composant ci-dessous chute de 196 KB à 8 KB.
+
+## Ce que l'adaptateur conserve, ignore et ne remplace pas
+
+| `vue-i18n` API                                                      | Avec `@intlayer/vue-i18n`                                                                                                                                |
+| ------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `useI18n()` → `{ t, d, n, te, tm, rt, locale, availableLocales }`   | ✅ Conservé. Les clés `t` sont typées par rapport à vos dictionnaires                                                                                    |
+| `t("key", { name })`, `t("key", [a, b])`, `t("key", count)`         | ✅ Conservé. `{name}`, `{0}` et les pluriels séparés par des pipes se résolvent comme avant                                                              |
+| `d(date, "long")`, `n(value, "currency")`                           | ✅ Conservé. Les `datetimeFormats` / `numberFormats` issus de `createI18n()` sont respectés, soutenus par `Intl` natif                                   |
+| `i18n.global.locale.value = "fr"`                                   | ✅ Conservé. Une `WritableComputedRef` soutenue par le client d'Intlayer ; la réactivité se comporte comme avant                                         |
+| `$t`, `$tc`, `$te`, `$tm`, `$rt`, `$d`, `$n`, `$i18n` (Options API) | ✅ Conservé. Enregistré sur `app.config.globalProperties` par `app.use(i18n)`                                                                            |
+| `v-t` directive                                                     | ✅ Conservé                                                                                                                                              |
+| `legacy: true`                                                      | ✅ Accepté                                                                                                                                               |
+| `createI18n({ messages })`                                          | ⚠️ `messages` sont utilisés comme **fallback à l'exécution** avec un avertissement de développement. Supprimez les imports JSON pour les gains de bundle |
+| `setLocaleMessage()`, `mergeLocaleMessage()`                        | ❌ Avertissement et ne fait rien. Le chargement des messages à l'exécution est remplacé par des dictionnaires au moment de la compilation                |
+| SFC `<i18n>` custom blocks                                          | ❌ Non lu. Déplacez ces messages dans le JSON de localisation (ou un `.content.ts` à côté du composant)                                                  |
+| `@nuxtjs/i18n`                                                      | ⚠️ Adaptateur séparé, voir la [documentation de compatibilité Nuxt](https://intlayer.org/doc/compatibility/nuxtjs-i18n)                                  |
+
+## Le benchmark
+
+### Ce qui a été mesuré
+
+La suite [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom) construit **la même application Vite + Vue 3** avec chaque configuration : **10 pages** (accueil, à propos, blog, carrières, contact, FAQ, tarification, produits, paramètres, équipe), **10 locales** (`en`, `fr`, `es`, `de`, `it`, `pt`, `zh`, `ja`, `ko`, `ru`), des composants identiques et un contenu identique. Les pages sont mesurées en `en` et `fr`.
+
+Les deux ont été construits dans la configuration **statique**, celle que la plupart des projets Vue livrent : pour `vue-i18n`, chaque JSON de locale importé et passé à `createI18n({ messages })`; pour l'adaptateur, les mêmes composants avec `vite.config.ts` et `intlayer.config.ts` modifiés et l'import `messages` supprimé. Le natif `vue-intlayer` est inclus pour référence.
+
+Pour chaque build, la suite enregistre :
+
+- **Lib size** : taille gzip (et minifiée) d'un composant vide qui importe uniquement la bibliothèque i18n.
+- **Page JS** : JavaScript gzip téléchargé par page, moyenné sur toutes les pages et locales.
+- **Locale leak %** : part des chaînes traduites dans le JS téléchargé qui appartiennent à une locale que l'utilisateur n'est **pas** en train de consulter.
+- **Page leak %** : part des chaînes traduites dans le JS téléchargé qui appartiennent à une page sur laquelle l'utilisateur n'est **pas**.
+- **Component avg** : taille gzip moyenne de chaque composant compilé de manière isolée.
+- **E2E reactivity** : temps écoulé entre la sélection d'une nouvelle locale et la mise à jour de `html[lang]` dans le DOM (Playwright, 5 itérations).
+- **Page load** : `PerformanceNavigationTiming.duration`.
+
+> Les chiffres ci-dessous proviennent de l'exécution datée du **12-09-2026** avec `vue-i18n` 11.4.0 et `@intlayer/vue-i18n` 9.5.1. L'application de test est volontairement petite (quelques dizaines de chaînes par locale), donc les pourcentages de fuite décrivent un **modèle** : ils augmentent avec votre contenu tandis que le coût d'exécution reste fixe.
+
+### Résultats sur Vite + Vue 3
+
+| Configuration            | Stratégie | Taille Lib (gz) | Taille Lib (min) | Moyenne Page JS (gz) | Fuite de locale | Fuite de page | Moyenne Component (gz) | Réactivité E2E | Chargement de page |
+| ------------------------ | --------- | --------------: | ---------------: | -------------------: | --------------: | ------------: | ---------------------: | -------------: | -----------------: |
+| **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 colonne page-leak de l'application de base est laissée vide : sans bibliothèque i18n, l'empreinte digitale détecte les chaînes codées en dur dans les chunks partagés et le nombre n'est pas significatif.
+
+**Comment le lire**
+
+- **88 KB de moins par page, mêmes composants.** `vue-i18n` prend l'application de 41.3 KB à **134.9 KB**. La build de l'adaptateur des mêmes composants atterrit à **47.0 KB**, 5.7 KB au-dessus de l'application de base. La plupart de la différence est les 74.9 KB de `src/locales` que `createI18n({ messages })` intègre dans chaque page et que l'adaptateur ne regroupe jamais en bloc.
+- **Le runtime se réduit 3x.** Un composant vide qui importe seulement `vue-i18n` coûte **24.3 KB gzip / 83.2 KB minifié** : `@intlify/core-base`, le compilateur de messages et le runtime. L'adapter coûte **7.9 KB / 23.2 KB**, la plupart étant le core d'Intlayer plus la surface API `vue-i18n`.
+- **Composants : 23x plus petits.** Un composant `useI18n()` compilé en isolation fait en moyenne **196 KB**, parce que `t` est lié à l'instance qui contient chaque message de chaque locale. Avec l'adapter, le même composant fait en moyenne **8.4 KB** : il accède à son propre dictionnaire.
+- **Fuite.** `vue-i18n` envoie chaque locale et les strings de chaque page sur chaque page : 50% de fuite de locale (sur les deux locales avec empreinte ; avec dix locales bundlées, le vrai gaspillage est plus élevé), 90% de fuite de page. L'adapter réduit la fuite de page à **0%** parce que chaque composant n'importe que ses dictionnaires. La fuite de locale s'élève à 15% dans cette exécution `static` ; `importMode: 'dynamic'` est le paramètre qui la supprime, et cette configuration ne faisait pas partie de cette exécution Vue.
+- **Réactivité et chargement de page.** Le changement de locale est peu coûteux pour les deux (1,5-2,8 ms) ; le système de réactivité de Vue le rend possible une fois que les messages sont en mémoire. Le chargement de page passe de 13,6 ms à **9,3 ms**, en ligne avec 88 KB de JavaScript en moins à analyser.
+- **À propos des lignes natives.** `vue-intlayer` dans cette exécution a regroupé chaque locale en mode `static` et a atteint 57,1 KB avec un runtime de 3,9 KB ; les dictionnaires synchronisés de l'adaptateur contenaient moins de chaînes de locale étrangère, d'où la figure inférieure par page. Le runtime natif reste le plus léger des trois, et son modèle `.content.ts` est l'équivalent des blocs SFC `<i18n>`.
+
+## Pourquoi les chiffres changent
+
+Rien dans `src/components/` n'a changé, donc les gains proviennent de ce à quoi `useI18n` est lié.
+
+**Avec `vue-i18n`**, la liaison est l'instance globale. `createI18n({ messages: { en, fr, ... } })` est une seule importation qui contient tout ; chaque composant qui appelle `useI18n()` peut y accéder en entier, donc le bundler ne peut pas diviser en dessous de l'instance. L'optimisation signifie que _vous_ divisez `en.json` par route, appelez `setLocaleMessage()` dans un garde de routeur, et gardez la carte route-vers-fichier correcte au fur et à mesure que les composants se déplacent.
+
+```bash
+.
+├── locales
+│   ├── en.json                    # chaînes de caractères de chaque page
+│   └── fr.json
+└── src
+    ├── i18n.ts                    # createI18n({ messages: { en, fr, ... } })
+    ├── main.ts                    # app.use(i18n)
+    └── components
+        └── Footer.vue             # useI18n(); t("footer.github")
+```
+
+**Avec `@intlayer/vue-i18n`**, la liaison est le dictionnaire. `syncJSON` transforme chaque clé de premier niveau de `en.json` en dictionnaire; la passe d'optimisation fournit au composant ceux dont les clés sont nommées, en tant qu'imports que le bundler trace et divise par page.
+
+```bash
+.
+├── intlayer.config.ts             # syncJSON({ format: "vue-i18n", source: ... })
+├── locales
+│   ├── en.json                    # inchangé, toujours la source de vérité
+│   └── fr.json
+├── .intlayer/                     # généré: un dictionnaire par clé de premier niveau, par locale
+└── src
+    ├── i18n.ts                    # createI18n({})   ← import messages supprimé
+    ├── main.ts                    # app.use(i18n)    ← inchangé
+    └── components
+        └── Footer.vue             # useI18n(); t("footer.github")  ← inchangé
+```
+
+L'import `messages` dans `i18n.ts` est la seule ligne à supprimer. C'est les 88 KB.
+
+## Migration en trois étapes
+
+<Steps>
+<Step number={1} title="Installer">
+
+```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
+```
+
+La commande détecte `vue-i18n`, installe `intlayer`, `vue-intlayer`, `@intlayer/vue-i18n` et `@intlayer/sync-json-plugin`, et pré-remplit `intlayer.config.ts`. Gardez `vue-i18n` installé : c'est une peer dependency et elle fournit les types.
+
+</Step>
+<Step number={2} title="Pointer Intlayer vers vos fichiers de 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" regroupe chaque locale ; "dynamic" charge celle active à la demande
+    importMode: "dynamic",
+    format: "vue-i18n",
+  },
+  plugins: [
+    syncJSON({
+      // dialecte vue-i18n : {name}, {0}, "voiture | voitures"
+      format: "vue-i18n",
+      source: ({ locale }) => `./locales/${locale}.json`,
+      location: "locales",
+    }),
+  ],
+};
+
+export default config;
+```
+
+`locales/{locale}.json` reste à sa place. Chaque clé de haut niveau (`footer`, `hero`...) devient un dictionnaire.
+
+</Step>
+<Step number={3} title="Ajouter le plugin et supprimer l'importation des messages">
+
+```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";
+
+// Avant : createI18n({ locale: "en", messages: { en, fr, es } })
+export const i18n = createI18n({ locale: "en" });
+```
+
+`vueI18nVitePlugin()` enveloppe `vite-intlayer` (surveillance du contenu, compilation du dictionnaire, l'étape d'optimisation) et crée un alias de `vue-i18n` vers l'adaptateur. La suppression de l'importation `messages` est ce qui réduit les 88 KB ; la laisser conserve le fonctionnement de l'application mais expédie les deux.
+
+</Step>
+
+### Ce que vous pouvez supprimer par la suite
+
+| Fichier / pattern                                | Pourquoi                                                                                 |
+| ------------------------------------------------ | ---------------------------------------------------------------------------------------- |
+| `import en from "./locales/en.json"` et consorts | Utilisé uniquement comme fallback par l'adaptateur. C'est là que venaient les 88 KB      |
+| `setLocaleMessage()` dans les gardes de router   | Sans effet. Le chargement par route est maintenant le travail du compilateur             |
+| `@intlify/unplugin-vue-i18n`                     | Non nécessaire : il précompile les messages et les blocs SFC que l'adaptateur ne lit pas |
+| Blocs SFC `<i18n>`                               | Non lus ; déplacez-les vers le JSON des locales ou vers un `.content.ts` par composant   |
+
+### Ce que vous gagnez au-delà des octets
+
+- **Clés typées.** `t("footer.github")` est typé par rapport au dictionnaire `footer` compilé ; un mauvais chemin est une erreur TypeScript au lieu que la clé soit rendue comme texte.
+- **`npx intlayer test`** échoue dans CI si une clé manque dans n'importe quelle locale. **`npx intlayer fill`** traduit les clés manquantes avec votre propre clé de fournisseur (OpenAI, Anthropic, Mistral, Gemini...) et les réécrit dans `locales/{locale}.json`.
+- **Visual Editor et CMS** opèrent sur le même JSON, donc les non-développeurs éditent via une interface utilisateur et les fichiers se mettent à jour.
+- **Passage progressif à `.content.ts`.** Tout composant peut passer de `useI18n()` à `useIntlayer("footer")` avec un fichier de contenu co-localisé. Les dictionnaires JSON et `.content.ts` coexistent et fusionnent.
+
+## Limitations à connaître avant de commencer
+
+- **Les blocs SFC `<i18n>` ne sont pas lus.** Si vos messages se trouvent à l'intérieur des composants, ils doivent être déplacés vers les fichiers de locale (ou vers `.content.ts`, qui est la même idée avec les types).
+- **Le chargement des messages à l'exécution a disparu.** `setLocaleMessage()` et `mergeLocaleMessage()` avertissent et retournent. Les traductions récupérées d'un CMS à l'exécution nécessitent le CMS d'Intlayer, ou les commandes `intlayer pull` / `push`.
+- **`messages` est un fallback, pas gratuit.** Garder les imports JSON dans `createI18n()` maintient les 75 KB dans le bundle. Supprimez-les une fois que `intlayer test` passe.
+- **L'adaptateur n'est pas le runtime natif.** 7.9 KB contre 3.9 KB pour `vue-intlayer`. Une fois que chaque composant a migré vers `useIntlayer`, supprimez-le.
+
+## Quand utiliser quoi ?
+
+- **Restez sur `vue-i18n`** si votre app dépend des blocs SFC `<i18n>`, des flux runtime `setLocaleMessage()`, ou si 90 KB par page n'est pas une préoccupation pour votre audience.
+- **Utilisez `@intlayer/vue-i18n`** si vous êtes sur `vue-i18n` et souhaitez les 88 KB économisés, les composants 23x plus petits, 0% de fuite de page, les clés typées et les vérifications CI sans éditer un fichier `.vue`. C'est le point d'entrée pour une codebase `vue-i18n` existante.
+- **Allez au natif (`vue-intlayer`)** pour les nouveaux projets, ou une fois que l'adaptateur a fait son travail. Il dispose du runtime le plus léger (3.9 KB) et du modèle `.content.ts` par composant qui remplace les blocs `<i18n>` par du contenu typé.
+
+## Comparaisons associées
+
+- [vue-i18n vs Intlayer](https://intlayer.org/blog/vue-i18n-vs-intlayer) (features et DX)
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/blog/vue-i18n-vs-intlayer-benchmark) (les libraries, même benchmark)
+- [next-intl vs @intlayer/next-intl](https://intlayer.org/blog/next-intl-vs-intlayer-next-intl) (même série d'adapter)
+- [i18next vs @intlayer/i18next](https://intlayer.org/blog/i18next-vs-intlayer-i18next) (même série d'adapter)
+- [Lingui vs @intlayer/lingui](https://intlayer.org/blog/lingui-vs-intlayer-lingui) (même série d'adapter)
+- [Guide de migration : vue-i18n vers Intlayer](https://intlayer.org/doc/migration/vue-i18n)
+- [Référence de l'adaptateur de compatibilité : vue-i18n](https://intlayer.org/doc/compatibility/vue-i18n), [Nuxt i18n](https://intlayer.org/doc/compatibility/nuxtjs-i18n)
+
+## Conclusion
+
+`@intlayer/vue-i18n` change ce à quoi `useI18n()` est lié : d'une instance globale contenant chaque message de chaque locale à un dictionnaire compilé pour ce composant. Sur la même application Vite + Vue 3 qui est **88 KB moins lourde par page**, un **runtime 3x plus petit**, des **composants 23x plus petits** et **0% de fuite de page**, pour un fichier de configuration, une ligne de plugin et une importation supprimée. Les blocs SFC `<i18n>` et le chargement de messages au runtime sont les deux choses qu'il ne gère pas, et le runtime `vue-intlayer` natif reste moitié moins volumineux.
+
+Toutes les données brutes, les applications de test et les scripts se trouvent dans le [référentiel Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom). Exécutez-le vous-même.
+
+Reportez-vous à la [documentation 'Pourquoi Intlayer ?'](https://intlayer.org/doc/why) pour plus de détails.

package/blog/fr/vue-i18n_vs_intlayer_benchmark.md

@@ -0,0 +1,39 @@
+---
+createdAt: 2026-09-13
+updatedAt: 2026-09-13
+title: "vue-i18n vs Intlayer : Benchmark 2026"
+description: vue-i18n et Intlayer mesurés sur la même app Vite + Vue 3. Taille de la librairie, JavaScript par page, fuite de contenu, taille des composants et réactivité du changement de locale, avec les chiffres expliqués.
+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 d'internationalisation Vue (i18n)
+
+`vue-i18n` est la bibliothèque i18n de référence pour Vue. Intlayer est une alternative basée sur un compilateur, délimitée au composant, avec une intégration Vue (`vue-intlayer`). Nous avons déjà comparé leurs [fonctionnalités et expérience développeur](https://intlayer.org/blog/vue-i18n-vs-intlayer). Cet article examine le coût de chacun une fois l'application construite.
+
+Les données proviennent de [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), une suite open-source qui construit la même application avec chaque bibliothèque et enregistre ce que le navigateur télécharge et exécute réellement.
+
+<TOC/>
+
+> **tl;dr**: Sur la même app Vite + Vue 3, `vue-i18n` embarque **134.9 KB** de JavaScript gzippé par page contre **41.3 KB** pour l'app sans i18n. Intlayer embarque **57.1 KB**. Le runtime `vue-i18n` seul pèse **24.3 KB gzip** (6x les 3.9 KB d'Intlayer), chaque page porte **90% des chaînes de pages étrangères**, et un composant compilé en isolation traîne **196 KB** car il est lié à l'arbre global des messages. L'adaptateur `@intlayer/vue-i18n` conserve l'API `vue-i18n` et a mesuré **47.0 KB** par page.
+
+## En résumé
+
+- **vue-i18n** - La bibliothèque i18n de facto pour Vue 2 / Vue 3 et le cœur de `@nuxtjs/i18n`. Messages au style ICU, blocs `<i18n>` dans les SFC, directive `v-t`, formatters `d()` / `n()`, grand écosystème. Les messages sont enregistrés sur une instance globale à `createI18n()`; le chargement lazy par locale suit un pattern `setLocaleMessage()` manuel, et la division per-route est à construire vous-même.
+- **Intlayer** - Modèle de contenu centré sur les composants. Les dictionnaires `.content.ts` se situent à côté du composant qu'ils servent, un compilateur build-time (`vite-intlayer`) tree-shake et lazy-load par composant et par locale, les types TypeScript stricts sont générés depuis votre contenu, et les traductions manquantes échouent au moment du build. Inclut des helpers pour router / SEO, un Visual Editor / CMS et une traduction assistée par IA.
+
+| Bibliothèque | Stars GitHub | Commits totaux | Dernier commit | Première version | Version NPM | Téléchargements NPM |

package/blog/hi/history_of_i18n.md

@@ -49,7 +49,7 @@ author: aymericzip
 
 यह लेख 2011 से 2026 तक के इस विकास पर नज़र डालता है: प्रत्येक पीढ़ी के उपकरणों ने क्या हल करने का प्रयास किया, क्या सफल रहा, क्या नहीं, और फ्रंटएंड आर्किटेक्चर ने आज i18n के हमारे तरीके को कैसे प्रभावित किया।
 
-![जावास्क्रिप्ट अंतर्राष्ट्रीयकरण लाइब्रेरी इकोसिस्टम](https://github.com/aymericzip/intlayer/blob/main/docs/assets/cloud_i18n_logo.png?raw=true)
+![जावास्क्रिप्ट अंतर्राष्ट्रीयकरण लाइब्रेरी इकोसिस्टम](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   | `i18next`                            | फ्रेमवर्क लॉक-इन के बिना ब्राउज़र और Node.js के लिए रनटाइम डिक्शनरी लुकअप को मानकीकृत करना।                       | प्लगेबल रनटाइम आर्किटेक्चर जो कोर अनुवाद को लोडर्स, डिटेक्टरों और कैशिंग से अलग करता है।                                              |
-| फरवरी 2021   | `typesafe-i18n`                      | अनटाइप्ड स्ट्रिंग कुंजियों के कारण होने वाली मूक रनटाइम त्रुटियों को रोकना।                                       | बिना किसी रनटाइम निर्भरता के अनुवाद ऑब्जेक्ट्स से सीधे उत्पन्न पूरी तरह से टाइप-सुरक्षित अनुवाद फ़ंक्शन।                              |
-| अक्टूबर 2023 | `paraglide` (`@inlang/paraglide-js`) | रनटाइम डिक्शनरी लुकअप, भारी पार्सर्स और बंडल ब्लोट को समाप्त करना।                                                | संदेशों को ट्री-शेकेबल ECMAScript मॉड्यूल और प्लेन JS फ़ंक्शंस में संकलित करना।                                                       |
-| अप्रैल 2024  | `intlayer`                           | अनियंत्रित नेमस्पेस को बदलना, पेज-टू-पेज कंटेंट लीकेज से बचना, और टाइपस्क्रिप्ट युग में टाइप सुरक्षा प्रदान करना। | फ़ंक्शन कॉल के साथ सीधे `.content` फ़ाइलों को रखना, ऑटो-जेनरेटेड टाइपस्क्रिप्ट प्रकार, और इन-बिल्ट विज़ुअल CMS व AI ट्रांसलेशन टूल्स। |
-| जून 2025     | `wuchale`                            | विकास के दौरान मैन्युअल रूप से टेक्स्ट निकालने और कुंजियाँ बनाने की समस्या को हटाना।                              | AST-स्तरीय प्रीप्रोसेसिंग जो इनलाइन टेक्स्ट का पता लगाती है और बिल्ड टाइम पर स्थानीयकृत फ़ंक्शन बनाती है।                             |
+| प्रथम रिलीज़ | लाइब्रेरी                            | लेखक                                                         | हल करने का उद्देश्य                                                                                               | प्रमुख नवाचार                                                                                                                         |
+| ------------ | ------------------------------------ | ------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
+| जनवरी 2012   | `i18next`                            | Jan Mühlemann (`@jamuhl`)                                    | फ्रेमवर्क लॉक-इन के बिना ब्राउज़र और Node.js के लिए रनटाइम डिक्शनरी लुकअप को मानकीकृत करना।                       | प्लगेबल रनटाइम आर्किटेक्चर जो कोर अनुवाद को लोडर्स, डिटेक्टरों और कैशिंग से अलग करता है।                                              |
+| फरवरी 2021   | `typesafe-i18n`                      | Ivan Hofer (`@ivanhofer`)                                    | अनटाइप्ड स्ट्रिंग कुंजियों के कारण होने वाली मूक रनटाइम त्रुटियों को रोकना।                                       | बिना किसी रनटाइम निर्भरता के अनुवाद ऑब्जेक्ट्स से सीधे उत्पन्न पूरी तरह से टाइप-सुरक्षित अनुवाद फ़ंक्शन।                              |
+| अक्टूबर 2023 | `paraglide` (`@inlang/paraglide-js`) | Samuel Stroschein (`@samuelstroschein`) / Inlang (`@inlang`) | रनटाइम डिक्शनरी लुकअप, भारी पार्सर्स और बंडल ब्लोट को समाप्त करना।                                                | संदेशों को ट्री-शेकेबल ECMAScript मॉड्यूल और प्लेन JS फ़ंक्शंस में संकलित करना।                                                       |
+| अगस्त 2024   | `intlayer`                           | Aymeric Pineau (`@aymericzip`)                               | अनियंत्रित नेमस्पेस को बदलना, पेज-टू-पेज कंटेंट लीकेज से बचना, और टाइपस्क्रिप्ट युग में टाइप सुरक्षा प्रदान करना। | फ़ंक्शन कॉल के साथ सीधे `.content` फ़ाइलों को रखना, ऑटो-जेनरेटेड टाइपस्क्रिप्ट प्रकार, और इन-बिल्ट विज़ुअल CMS व AI ट्रांसलेशन टूल्स। |
+| जून 2025     | `wuchale`                            | Kidus Adugna (`@K1DV5`)                                      | विकास के दौरान मैन्युअल रूप से टेक्स्ट निकालने और कुंजियाँ बनाने की समस्या को हटाना।                              | AST-स्तरीय प्रीप्रोसेसिंग जो इनलाइन टेक्स्ट का पता लगाती है और बिल्ड टाइम पर स्थानीयकृत फ़ंक्शन बनाती है।                             |
 
 </Tab>
 
 <Tab label="React" value="react">
 
-| प्रथम रिलीज़ | लाइब्रेरी        | हल करने का उद्देश्य                                                                                                 | प्रमुख नवाचार                                                                                                               |
-| ------------ | ---------------- | ------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
-| जून 2014     | `react-intl`     | रिएक्ट में संख्याओं, तिथियों, मुद्राओं और जटिल बहुवचनों के लिए स्वरूपण का मानकीकरण।                                 | ICU MessageFormat और ECMA-402 मानकों को लागू करने वाले घोषणात्मक घटक (`<FormattedMessage>`, `<FormattedDate>`)।             |
-| दिसंबर 2015  | `react-i18next`  | रिएक्टिव री-रेंडरिंग के साथ रिएक्ट के लिए `i18next` बाइंडिंग प्रदान करना।                                           | हायर-ऑर्डर घटकों से `<Trans>` JSX इंटरपोलेशन और `useTranslation` हुक तक विकास।                                              |
-| जनवरी 2018   | `@lingui/react`  | रनटाइम ICU पार्सर्स के कारण जावास्क्रिप्ट बंडल आकार दंड को कम करना।                                                 | बिल्ड टाइम पर `<Trans>` और `t` को कॉम्पैक्ट अनुक्रमित सरणियों में संकलित करने वाले Babel/SWC मैक्रोज़।                      |
-| दिसंबर 2020  | `use-intl`       | लीगेसी रिएक्ट i18n लाइब्रेरीज़ के लिए एक हल्का, हुक-आधारित, टाइप-सुरक्षित विकल्प देना।                              | गहरे टाइपस्क्रिप्ट एकीकरण के साथ सुविधाजनक `useTranslations` और `useFormatter` हुक।                                         |
-| फरवरी 2021   | `@tolgee/react`  | डेवलपर्स, अनुवादकों और डिज़ाइनरों के बीच धीमी प्रतिक्रिया लूप को समाप्त करना।                                       | इन-कॉन्टेक्स्ट ब्राउज़र संपादन जो उपयोगकर्ताओं को Alt-क्लिक करने, अनुवाद संपादित करने और स्क्रीनशॉट लेने की अनुमति देता है। |
-| अप्रैल 2024  | `react-intlayer` | रिएक्ट घटक जीवनचक्र के लिए अनुकूलित उच्च-प्रदर्शन Intlayer समाधान प्रदान करना, जिससे केंद्रीकृत JSON समाप्त हो सके। | रिएक्ट रेंडरिंग के लिए तैयार `useIntlayer` हुक, ऑटो-जेनरेटेड टाइपस्क्रिप्ट प्रकार, घटक-स्तरीय ट्री-शेकिंग और विज़ुअल CMS।   |
-| जुलाई 2024   | `gt-react`       | मैन्युअल फ़ाइल निर्यात और अनुवाद रखरखाव को स्वचालित करना।                                                           | मशीन अनुवाद पाइपलाइनों के साथ रिएक्ट घटकों के भीतर सीधे क्लाउड-नेटिव स्वचालित AI स्थानीयकरण।                                |
-| अगस्त 2025   | `@wuchale/jsx`   | JSX में मैन्युअल की-नामकरण और बॉयलरप्लेट अनुवाद हुक को हटाना।                                                       | AST परिवर्तन जो स्वचालित रूप से कच्चे JSX टेक्स्ट नोड्स को स्थानीयकृत समकक्षों में बदलता है।                                |
+| प्रथम रिलीज़ | लाइब्रेरी        | लेखक                           | हल करने का उद्देश्य                                                                                                 | प्रमुख नवाचार                                                                                                               |
+| ------------ | ---------------- | ------------------------------ | ------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
+| जून 2014     | `react-intl`     | Yahoo! / FormatJS              | रिएक्ट में संख्याओं, तिथियों, मुद्राओं और जटिल बहुवचनों के लिए स्वरूपण का मानकीकरण।                                 | ICU MessageFormat और ECMA-402 मानकों को लागू करने वाले घोषणात्मक घटक (`<FormattedMessage>`, `<FormattedDate>`)।             |
+| दिसंबर 2015  | `react-i18next`  | Jan Mühlemann (`@jamuhl`)      | रिएक्टिव री-रेंडरिंग के साथ रिएक्ट के लिए `i18next` बाइंडिंग प्रदान करना।                                           | हायर-ऑर्डर घटकों से `<Trans>` JSX इंटरपोलेशन और `useTranslation` हुक तक विकास।                                              |
+| जनवरी 2018   | `@lingui/react`  | Tomáš Ehrlich (`@tricoder42`)  | रनटाइम ICU पार्सर्स के कारण जावास्क्रिप्ट बंडल आकार दंड को कम करना।                                                 | बिल्ड टाइम पर `<Trans>` और `t` को कॉम्पैक्ट अनुक्रमित सरणियों में संकलित करने वाले Babel/SWC मैक्रोज़।                      |
+| दिसंबर 2020  | `use-intl`       | Jan Amann (`@amannn`)          | लीगेसी रिएक्ट i18n लाइब्रेरीज़ के लिए एक हल्का, हुक-आधारित, टाइप-सुरक्षित विकल्प देना।                              | गहरे टाइपस्क्रिप्ट एकीकरण के साथ सुविधाजनक `useTranslations` और `useFormatter` हुक।                                         |
+| फरवरी 2021   | `@tolgee/react`  | Jan Cizmar (`@jcizmar`)        | डेवलपर्स, अनुवादकों और डिज़ाइनरों के बीच धीमी प्रतिक्रिया लूप को समाप्त करना।                                       | इन-कॉन्टेक्स्ट ब्राउज़र संपादन जो उपयोगकर्ताओं को Alt-क्लिक करने, अनुवाद संपादित करने और स्क्रीनशॉट लेने की अनुमति देता है। |
+| अगस्त 2024   | `react-intlayer` | Aymeric Pineau (`@aymericzip`) | रिएक्ट घटक जीवनचक्र के लिए अनुकूलित उच्च-प्रदर्शन Intlayer समाधान प्रदान करना, जिससे केंद्रीकृत JSON समाप्त हो सके। | रिएक्ट रेंडरिंग के लिए तैयार `useIntlayer` हुक, ऑटो-जेनरेटेड टाइपस्क्रिप्ट प्रकार, घटक-स्तरीय ट्री-शेकिंग और विज़ुअल CMS।   |
+| जुलाई 2024   | `gt-react`       | Ernest McCarter (`@eoinest`)   | मैन्युअल फ़ाइल निर्यात और अनुवाद रखरखाव को स्वचालित करना।                                                           | मशीन अनुवाद पाइपलाइनों के साथ रिएक्ट घटकों के भीतर सीधे क्लाउड-नेटिव स्वचालित AI स्थानीयकरण।                                |
+| जून 2025     | `@wuchale/jsx`   | Kidus Adugna (`@K1DV5`)        | JSX में मैन्युअल की-नामकरण और बॉयलरप्लेट अनुवाद हुक को हटाना।                                                       | AST परिवर्तन जो स्वचालित रूप से कच्चे JSX टेक्स्ट नोड्स को स्थानीयकृत समकक्षों में बदलता है।                                |
 
 </Tab>
 
 <Tab label="Next.js" value="nextjs">
 
-| प्रथम रिलीज़ | लाइब्रेरी                                   | हल करने का उद्देश्य                                                                                                             | प्रमुख नवाचार                                                                                                                                                   |
-| ------------ | ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| नवंबर 2018   | `next-i18next`                              | क्लाइंट वॉटरफॉल के बिना Next.js Pages Router में `i18next` के साथ SSR और SSG का समर्थन।                                         | पेज प्रॉप्स में स्थानीयकृत नेमस्पेस पास करने वाले `serverSideTranslations` और `appWithTranslation`।                                                             |
-| दिसंबर 2019  | `next-translate`                            | Next.js Pages Router ऐप्स में कॉन्फ़िगरेशन को सरल बनाना और बंडल का वजन कम करना।                                                 | Webpack लोडर प्लगइन जो प्रति पेज केवल आवश्यक अनुवाद नेमस्पेस इंजेक्ट करता है।                                                                                   |
-| नवंबर 2020   | `next-intl`                                 | App Router, रिएक्ट सर्वर कंपोनेंट्स (RSC) और स्ट्रीमिंग SSR के लिए Next.js i18n को फिर से डिजाइन करना।                          | बिना किसी क्लाइंट JS के Next.js App Router मिडलवेयर, सर्वर एक्शन्स और एसिंक्रोनस सर्वर कंपोनेंट्स के साथ मूल एकीकरण।                                            |
-| जुलाई 2022   | `next-international`                        | न्यूनतम क्लाइंट बंडल ओवरहेड के साथ टाइपस्क्रिप्ट टाइप सुरक्षा को अधिकतम करना।                                                   | हल्के App Router और Pages Router एडेप्टर के साथ स्कोप्ड कुंजियों के लिए सख्त प्रकार का निर्माण।                                                                 |
-| अप्रैल 2024  | `paraglide-next` (`@inlang/paraglide-next`) | Next.js App Router और Pages Router में जीरो-रनटाइम संकलित संदेश लाना।                                                           | ट्री-शेकेबल संदेश फ़ंक्शंस के साथ मिडलवेयर रूटिंग जो RSC में रनटाइम JSON पार्सिंग से बचाती है।                                                                  |
-| अप्रैल 2024  | `next-intlayer`                             | Next.js App Router के लिए उच्च-प्रदर्शन सर्वर कंपोनेंट एडेप्टर देना, जिससे प्रॉप्स के रूप में `t()` पास करने की आवश्यकता न रहे। | मूल सर्वर कंपोनेंट एडेप्टर जो प्रॉप-ड्रिलिंग के बिना सीधे समकालिक सर्वर घटकों (जैसे Navbar) में `useIntlayer` कॉल करने की अनुमति देता है, साथ ही लाइव CMS सिंक। |
-| सितंबर 2024  | `gt-next`                                   | AI अनुवाद का उपयोग करके Next.js में बहुभाषी सामग्री निर्माण और स्थानीयकृत रूटिंग को स्वचालित करना।                              | क्लाउड मशीन अनुवाद को Next.js एज मिडलवेयर और कैशिंग परतों के साथ जोड़ने वाला एकीकरण।                                                                            |
+| प्रथम रिलीज़ | लाइब्रेरी                                   | लेखक                                                         | हल करने का उद्देश्य                                                                                                             | प्रमुख नवाचार                                                                                                                                                   |
+| ------------ | ------------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| नवंबर 2018   | `next-i18next`                              | Isaac Hinman (`@isaachinman`)                                | क्लाइंट वॉटरफॉल के बिना Next.js Pages Router में `i18next` के साथ SSR और SSG का समर्थन।                                         | पेज प्रॉप्स में स्थानीयकृत नेमस्पेस पास करने वाले `serverSideTranslations` और `appWithTranslation`।                                                             |
+| दिसंबर 2020  | `next-translate`                            | Arvin Wiyono (`@arvinn`) / Vinissimus (`@vinissimus`)        | Next.js Pages Router ऐप्स में कॉन्फ़िगरेशन को सरल बनाना और बंडल का वजन कम करना।                                                 | Webpack लोडर प्लगइन जो प्रति पेज केवल आवश्यक अनुवाद नेमस्पेस इंजेक्ट करता है।                                                                                   |
+| दिसंबर 2020  | `next-intl`                                 | Jan Amann (`@amannn`)                                        | App Router, रिएक्ट सर्वर कंपोनेंट्स (RSC) और स्ट्रीमिंग SSR के लिए Next.js i18n को फिर से डिजाइन करना।                          | बिना किसी क्लाइंट JS के Next.js App Router मिडलवेयर, सर्वर एक्शन्स और एसिंक्रोनस सर्वर कंपोनेंट्स के साथ मूल एकीकरण।                                            |
+| जुलाई 2022   | `next-international`                        | Tom Dussaix (`@tom-dussaix`)                                 | न्यूनतम क्लाइंट बंडल ओवरहेड के साथ टाइपस्क्रिप्ट टाइप सुरक्षा को अधिकतम करना।                                                   | हल्के App Router और Pages Router एडेप्टर के साथ स्कोप्ड कुंजियों के लिए सख्त प्रकार का निर्माण।                                                                 |
+| अक्टूबर 2023 | `paraglide-next` (`@inlang/paraglide-next`) | Samuel Stroschein (`@samuelstroschein`) / Inlang (`@inlang`) | Next.js App Router और Pages Router में जीरो-रनटाइम संकलित संदेश लाना।                                                           | ट्री-शेकेबल संदेश फ़ंक्शंस के साथ मिडलवेयर रूटिंग जो RSC में रनटाइम JSON पार्सिंग से बचाती है।                                                                  |
+| अगस्त 2024   | `next-intlayer`                             | Aymeric Pineau (`@aymericzip`)                               | Next.js App Router के लिए उच्च-प्रदर्शन सर्वर कंपोनेंट एडेप्टर देना, जिससे प्रॉप्स के रूप में `t()` पास करने की आवश्यकता न रहे। | मूल सर्वर कंपोनेंट एडेप्टर जो प्रॉप-ड्रिलिंग के बिना सीधे समकालिक सर्वर घटकों (जैसे Navbar) में `useIntlayer` कॉल करने की अनुमति देता है, साथ ही लाइव CMS सिंक। |
+| जुलाई 2024   | `gt-next`                                   | Ernest McCarter (`@eoinest`)                                 | AI अनुवाद का उपयोग करके Next.js में बहुभाषी सामग्री निर्माण और स्थानीयकृत रूटिंग को स्वचालित करना।                              | क्लाउड मशीन अनुवाद को Next.js एज मिडलवेयर और कैशिंग परतों के साथ जोड़ने वाला एकीकरण।                                                                            |
 
 </Tab>
 
 <Tab label="Vue & Nuxt" value="vue">
 
-| प्रथम रिलीज़ | लाइब्रेरी      | हल करने का उद्देश्य                                                                                    | प्रमुख नवाचार                                                                                                                                 |
-| ------------ | -------------- | ------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------- |
-| मई 2014      | `vue-i18n`     | Vue अनुप्रयोगों के लिए मुहावरेदार, प्रतिक्रियाशील अंतर्राष्ट्रीयकरण प्रदान करना।                       | गहरी प्रतिक्रियाशीलता एकीकरण, टेम्पलेट निर्देश (`v-t`), `$t` हेल्पर, और एकल-फ़ाइल घटक `<i18n>` कस्टम ब्लॉक।                                   |
-| नवंबर 2017   | `@nuxt/i18n`   | Nuxt में स्थानीयकृत URL रूटिंग, SEO hreflang टैग और SSR हाइड्रेशन को संभालना।                          | पूर्ण-स्टैक रूटिंग मॉड्यूल जो स्थानीयकृत रूट, SEO मेटा हेडर और लेज़ी चंक लोडिंग उत्पन्न करता है।                                              |
-| अगस्त 2019   | `fluent-vue`   | Vue में जटिल व्याकरणिक लिंग, कारक और विषम भाषा संरचनाओं को संभालना।                                    | भाषाई विविधताओं के लिए जटिल सशर्त कोड से बचने के लिए मोज़िला प्रोजेक्ट फ्लूएंट का एकीकरण।                                                     |
-| अप्रैल 2025  | `vue-intlayer` | Vue 3 Composition API और Nuxt के लिए विशेष रूप से डिज़ाइन किया गया उच्च प्रदर्शन वाला Intlayer समाधान। | Vue 3 प्रतिक्रियाशील ट्रैकिंग के लिए तैयार `useIntlayer` कंपोजेबल, प्रत्यक्ष घटक स्कोपिंग, पूर्ण टाइपस्क्रिप्ट ऑटोकम्प्लीशन, और दृश्य संपादक। |
+| प्रथम रिलीज़ | लाइब्रेरी      | लेखक                                        | हल करने का उद्देश्य                                                                                    | प्रमुख नवाचार                                                                                                                                 |
+| ------------ | -------------- | ------------------------------------------- | ------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------- |
+| मई 2014      | `vue-i18n`     | Kazupon (`@kazupon`)                        | Vue अनुप्रयोगों के लिए मुहावरेदार, प्रतिक्रियाशील अंतर्राष्ट्रीयकरण प्रदान करना।                       | गहरी प्रतिक्रियाशीलता एकीकरण, टेम्पलेट निर्देश (`v-t`), `$t` हेल्पर, और एकल-फ़ाइल घटक `<i18n>` कस्टम ब्लॉक।                                   |
+| नवंबर 2017   | `@nuxt/i18n`   | Nuxt समुदाय                                 | Nuxt में स्थानीयकृत URL रूटिंग, SEO hreflang टैग और SSR हाइड्रेशन को संभालना।                          | पूर्ण-स्टैक रूटिंग मॉड्यूल जो स्थानीयकृत रूट, SEO मेटा हेडर और लेज़ी चंक लोडिंग उत्पन्न करता है।                                              |
+| अगस्त 2020   | `fluent-vue`   | Mozilla (`@mozilla`) / Demivan (`@demivan`) | Vue में जटिल व्याकरणिक लिंग, कारक और विषम भाषा संरचनाओं को संभालना।                                    | भाषाई विविधताओं के लिए जटिल सशर्त कोड से बचने के लिए मोज़िला प्रोजेक्ट फ्लूएंट का एकीकरण।                                                     |
+| जनवरी 2025   | `vue-intlayer` | Aymeric Pineau (`@aymericzip`)              | Vue 3 Composition API और Nuxt के लिए विशेष रूप से डिज़ाइन किया गया उच्च प्रदर्शन वाला Intlayer समाधान। | Vue 3 प्रतिक्रियाशील ट्रैकिंग के लिए तैयार `useIntlayer` कंपोजेबल, प्रत्यक्ष घटक स्कोपिंग, पूर्ण टाइपस्क्रिप्ट ऑटोकम्प्लीशन, और दृश्य संपादक। |
 
 </Tab>
 
 <Tab label="Angular" value="angular">
 
-| प्रथम रिलीज़ | लाइब्रेरी           | हल करने का उद्देश्य                                                                                               | प्रमुख नवाचार                                                                                                                  |
-| ------------ | ------------------- | ----------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
-| फरवरी 2017   | `ngx-translate`     | प्रत्येक लोकेल के लिए अलग बंडल तैनात किए बिना Angular में गतिशील रनटाइम अनुवाद प्रदान करना।                       | `TranslateService` और `translate` पाइप गतिशील अनुवाद लोडिंग और भाषा टॉगलिंग को सक्षम करते हैं।                                 |
-| जुलाई 2019   | `@ngneat/transloco` | पुरानी Angular लाइब्रेरीज़ में प्रदर्शन बाधाओं और स्कोपिंग की कमी को हल करना।                                     | संरचनात्मक निर्देश (`*transloco`), लेज़ी-लोडेड मॉड्यूल के लिए स्कोप्ड अनुवाद, SSR समर्थन, और एक्सट्रैक्शन CLI।                 |
-| सितंबर 2019  | `@angular/localize` | प्रत्येक भाषा के लिए टाइपस्क्रिप्ट को फिर से संकलित करने से बचने के लिए Angular के अंतर्निहित i18n का आधुनिकीकरण। | Ivy कंपाइलर इंजन में एक तेज़ पोस्ट-बिल्ड चरण के रूप में इंजेक्ट किए गए `$localize` के साथ टैग किए गए टेम्पलेट लिटरल्स।         |
-| फरवरी 2021   | `@tolgee/ngx`       | Angular वर्कफ़्लो में सहयोगी इन-कॉन्टेक्स्ट अनुवाद और स्क्रीनशॉट कैप्चरिंग को एकीकृत करना।                        | लाइव इन-ब्राउज़र स्थानीयकरण के लिए सीधे Tolgee से जुड़े Angular पाइप और निर्देश।                                               |
-| अप्रैल 2025  | `angular-intlayer`  | आधुनिक Angular (Signals, स्टैंडअलोन घटक और SSR) के लिए तैयार किया गया उच्च प्रदर्शन समाधान।                       | आधुनिक Angular परिवर्तन पहचान, स्टैंडअलोन निर्भरता इंजेक्शन, और लाइव CMS के लिए डिज़ाइन किया गया सिग्नल-आधारित सामग्री एकीकरण। |
+| प्रथम रिलीज़ | लाइब्रेरी           | लेखक                                                         | हल करने का उद्देश्य                                                                                               | प्रमुख नवाचार                                                                                                                  |
+| ------------ | ------------------- | ------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
+| फरवरी 2017   | `ngx-translate`     | Olivier Combe (`@ocombe`)                                    | प्रत्येक लोकेल के लिए अलग बंडल तैनात किए बिना Angular में गतिशील रनटाइम अनुवाद प्रदान करना।                       | `TranslateService` और `translate` पाइप गतिशील अनुवाद लोडिंग और भाषा टॉगलिंग को सक्षम करते हैं।                                 |
+| जुलाई 2019   | `@ngneat/transloco` | Netanel Basal (`@NetanelBasal`) & Shahar Kazaz (`@shahar_k`) | पुरानी Angular लाइब्रेरीज़ में प्रदर्शन बाधाओं और स्कोपिंग की कमी को हल करना।                                     | संरचनात्मक निर्देश (`*transloco`), लेज़ी-लोडेड मॉड्यूल के लिए स्कोप्ड अनुवाद, SSR समर्थन, और एक्सट्रैक्शन CLI।                 |
+| सितंबर 2019  | `@angular/localize` | Angular टीम (@angular)                                       | प्रत्येक भाषा के लिए टाइपस्क्रिप्ट को फिर से संकलित करने से बचने के लिए Angular के अंतर्निहित i18n का आधुनिकीकरण। | Ivy कंपाइलर इंजन में एक तेज़ पोस्ट-बिल्ड चरण के रूप में इंजेक्ट किए गए `$localize` के साथ टैग किए गए टेम्पलेट लिटरल्स।         |
+| फरवरी 2021   | `@tolgee/ngx`       | Jan Cizmar (`@jcizmar`)                                      | Angular वर्कफ़्लो में सहयोगी इन-कॉन्टेक्स्ट अनुवाद और स्क्रीनशॉट कैप्चरिंग को एकीकृत करना।                        | लाइव इन-ब्राउज़र स्थानीयकरण के लिए सीधे Tolgee से जुड़े Angular पाइप और निर्देश।                                               |
+| मार्च 2026   | `angular-intlayer`  | Aymeric Pineau (`@aymericzip`)                               | आधुनिक Angular (Signals, स्टैंडअलोन घटक और SSR) के लिए तैयार किया गया उच्च प्रदर्शन समाधान।                       | आधुनिक Angular परिवर्तन पहचान, स्टैंडअलोन निर्भरता इंजेक्शन, और लाइव CMS के लिए डिज़ाइन किया गया सिग्नल-आधारित सामग्री एकीकरण। |
 
 </Tab>
 
 <Tab label="Svelte & SvelteKit" value="svelte">
 
-| प्रथम रिलीज़ | लाइब्रेरी         | हल करने का उद्देश्य                                                                          | प्रमुख नवाचार                                                                                                                        |
-| ------------ | ----------------- | -------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
-| जुलाई 2018   | `svelte-i18n`     | Svelte रिएक्टिव स्टोर्स के अनुरूप एक प्रतिक्रियाशील अंतर्राष्ट्रीयकरण लाइब्रेरी प्रदान करना। | स्टोर-समर्थित `$t` लुकअप जो लोकेल बदलने पर सटीक DOM अपडेट सुनिश्चित करता है।                                                         |
-| दिसंबर 2021  | `sveltekit-i18n`  | SvelteKit अनुप्रयोगों में SSR और रूट-आधारित अनुवाद लोडिंग को स्पष्ट रूप से संभालना।          | सक्रिय SvelteKit रूट के लिए आवश्यक अनुवाद और फ़ॉर्मेटर्स लाने वाला मॉड्यूलर लोडर आर्किटेक्चर।                                        |
-| नवंबर 2021   | `@tolgee/svelte`  | Svelte अनुप्रयोगों में इन-कॉन्टेक्स्ट स्थानीयकरण को सक्षम करना।                              | Tolgee ओवरले और स्वचालित स्क्रीनशॉट निर्माण के साथ एकीकृत Svelte स्टोर बाइंडिंग।                                                     |
-| अप्रैल 2025  | `svelte-intlayer` | Svelte 5 और SvelteKit के लिए विशेष रूप से डिज़ाइन किया गया Intlayer समाधान।                  | Svelte 5 Runes (`$state`) के लिए प्रतिक्रियाशील सामग्री बाइंडिंग, घटक-स्तरीय `.content` घोषणाएं, और विज़ुअल CMS संपादन।              |
-| जुलाई 2025   | `@wuchale/svelte` | Svelte घटकों में डिक्शनरी घोषित करने और `$t` फ़ंक्शन आयात करने के बॉयलरप्लेट को हटाना।       | Svelte प्रीप्रोसेसर जो बिल्ड टाइम पर टेम्प्लेट को पार्स करता है और टेक्स्ट नोड्स को शून्य-रैपर स्थानीयकृत आउटपुट में संकलित करता है। |
+| प्रथम रिलीज़ | लाइब्रेरी         | लेखक                           | हल करने का उद्देश्य                                                                          | प्रमुख नवाचार                                                                                                                        |
+| ------------ | ----------------- | ------------------------------ | -------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| जुलाई 2018   | `svelte-i18n`     | Kaisermann (`@kaisermann`)     | Svelte रिएक्टिव स्टोर्स के अनुरूप एक प्रतिक्रियाशील अंतर्राष्ट्रीयकरण लाइब्रेरी प्रदान करना। | स्टोर-समर्थित `$t` लुकअप जो लोकेल बदलने पर सटीक DOM अपडेट सुनिश्चित करता है।                                                         |
+| दिसंबर 2021  | `sveltekit-i18n`  | Ivan Fevrier (`@ivanfevrier`)  | SvelteKit अनुप्रयोगों में SSR और रूट-आधारित अनुवाद लोडिंग को स्पष्ट रूप से संभालना।          | सक्रिय SvelteKit रूट के लिए आवश्यक अनुवाद और फ़ॉर्मेटर्स लाने वाला मॉड्यूलर लोडर आर्किटेक्चर।                                        |
+| नवंबर 2021   | `@tolgee/svelte`  | Jan Cizmar (`@jcizmar`)        | Svelte अनुप्रयोगों में इन-कॉन्टेक्स्ट स्थानीयकरण को सक्षम करना।                              | Tolgee ओवरले और स्वचालित स्क्रीनशॉट निर्माण के साथ एकीकृत Svelte स्टोर बाइंडिंग।                                                     |
+| अक्टूबर 2025 | `svelte-intlayer` | Aymeric Pineau (`@aymericzip`) | Svelte 5 और SvelteKit के लिए विशेष रूप से डिज़ाइन किया गया Intlayer समाधान।                  | Svelte 5 Runes (`$state`) के लिए प्रतिक्रियाशील सामग्री बाइंडिंग, घटक-स्तरीय `.content` घोषणाएं, और विज़ुअल CMS संपादन।              |
+| जुलाई 2025   | `@wuchale/svelte` | Kidus Adugna (`@K1DV5`)        | Svelte घटकों में डिक्शनरी घोषित करने और `$t` फ़ंक्शन आयात करने के बॉयलरप्लेट को हटाना।       | Svelte प्रीप्रोसेसर जो बिल्ड टाइम पर टेम्प्लेट को पार्स करता है और टेक्स्ट नोड्स को शून्य-रैपर स्थानीयकृत आउटपुट में संकलित करता है। |
 
 </Tab>
 
 <Tab label="SolidJS" value="solid">
 
-| प्रथम रिलीज़ | लाइब्रेरी                | हल करने का उद्देश्य                                                                         | प्रमुख नवाचार                                                                                                          |
-| ------------ | ------------------------ | ------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
-| सितंबर 2021  | `@solid-primitives/i18n` | SolidJS सूक्ष्म प्रतिक्रियाशीलता से मेल खाने वाला एक मुहावरेदार i18n प्रिमिटिव प्रदान करना। | वर्चुअल DOM या अनावश्यक री-रेंडर के बिना DOM नोड्स को अपडेट करने वाला सिग्नल-आधारित अनुवाद समाधान।                     |
-| अप्रैल 2025  | `solid-intlayer`         | SolidJS और SolidStart के लिए विशेष रूप से विकसित उच्च-प्रदर्शन Intlayer समाधान।             | वर्चुअल DOM ओवरहेड के बिना सॉलिड की सूक्ष्म प्रतिक्रियाशीलता के लिए अनुकूलित सामग्री बाइंडिंग और विज़ुअल एडिटर एकीकरण। |
-| जून 2026     | `@lingui/solid`          | SolidJS में कंपाइल-टाइम मैक्रो एक्सट्रैक्शन और ICU MessageFormat समर्थन का विस्तार करना।    | सॉलिड की प्रतिक्रियाशीलता के अनुकूल मैक्रो परिवर्तन, जो संदेशों को कॉम्पैक्ट रनटाइम संरचनाओं में संकलित करते हैं।      |
+| प्रथम रिलीज़ | लाइब्रेरी                | लेखक                           | हल करने का उद्देश्य                                                                         | प्रमुख नवाचार                                                                                                          |
+| ------------ | ------------------------ | ------------------------------ | ------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
+| सितंबर 2021  | `@solid-primitives/i18n` | SolidJS समुदाय                 | SolidJS सूक्ष्म प्रतिक्रियाशीलता से मेल खाने वाला एक मुहावरेदार i18n प्रिमिटिव प्रदान करना। | वर्चुअल DOM या अनावश्यक री-रेंडर के बिना DOM नोड्स को अपडेट करने वाला सिग्नल-आधारित अनुवाद समाधान।                     |
+| जुलाई 2025   | `solid-intlayer`         | Aymeric Pineau (`@aymericzip`) | SolidJS और SolidStart के लिए विशेष रूप से विकसित उच्च-प्रदर्शन Intlayer समाधान।             | वर्चुअल DOM ओवरहेड के बिना सॉलिड की सूक्ष्म प्रतिक्रियाशीलता के लिए अनुकूलित सामग्री बाइंडिंग और विज़ुअल एडिटर एकीकरण। |
+| जून 2026     | `@lingui/solid`          | Tomáš Ehrlich (`@tricoder42`)  | SolidJS में कंपाइल-टाइम मैक्रो एक्सट्रैक्शन और ICU MessageFormat समर्थन का विस्तार करना।    | सॉलिड की प्रतिक्रियाशीलता के अनुकूल मैक्रो परिवर्तन, जो संदेशों को कॉम्पैक्ट रनटाइम संरचनाओं में संकलित करते हैं।      |
 
 </Tab>
 
@@ -237,7 +237,7 @@ ICU संदेश सिंटैक्स को पार्स करना
 
 ## जावास्क्रिप्ट i18n के चार वास्तुशिल्प युग
 
-![जावास्क्रिप्ट i18n लाइब्रेरीज़ का इतिहास](https://github.com/aymericzip/intlayer/blob/main/docs/assets/history_i18n.png?raw=true)
+![जावास्क्रिप्ट i18n लाइब्रेरीज़ का इतिहास](https://github.com/aymericzip/intlayer/blob/main/docs/assets/history_i18n.webp?raw=true)
 
 पंद्रह वर्षों के विकास को देखते हुए, हम जावास्क्रिप्ट अंतर्राष्ट्रीयकरण के इतिहास को चार अलग-अलग वास्तुशिल्प युगों में वर्गीकृत कर सकते हैं:
 
@@ -287,7 +287,7 @@ ICU संदेश सिंटैक्स को पार्स करना
 
 जैसे-जैसे आधुनिक बड़े भाषा मॉडलों (LLMs) ने भाषाई सटीकता बढ़ाते हुए अनुवाद लागत को नगण्य कर दिया, इस बाजार पर कब्जा करने के लिए वाणिज्यिक उपकरणों की एक नई पीढ़ी सामने आई:
 
-- 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) को कनेक्ट कर सकती हैं। कोई अतिरिक्त मार्कअप या वेंडर लॉक-इन नहीं है, यह सीधे आपके चुने हुए AI प्रदाता की लागत पर चलता है।
 
 ### केवल i18n से अधिक: एक संपूर्ण बहुभाषी सामग्री प्रणाली