@intlayer/docs 9.5.1 → 9.5.3

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

@@ -0,0 +1,288 @@
+---
+createdAt: 2026-09-13
+updatedAt: 2026-09-13
+title: "vue-i18n बनाम @intlayer/vue-i18n: समान API, विभिन्न Bundle"
+description: जब एक Vue 3 ऐप अपनी vue-i18n कॉल को रखता है लेकिन @intlayer/vue-i18n compat adapter के माध्यम से उन्हें serve करता है तो क्या बदलता है। प्रति-पेज JavaScript, runtime size, component size और leakage को same Vite + Vue code पर मापा गया है, साथ ही adapter क्या रखता है, क्या ignore करता है और क्या replace नहीं कर सकता है।
+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 बनाम @intlayer/vue-i18n | समान API, विभिन्न Bundle
+
+`@intlayer/vue-i18n` एक compat adapter है: यह `vue-i18n` API (`createI18n`, `useI18n`, `t()`, `d()`, `n()`, `$t`, `v-t`, `i18n.global.locale`...) को expose करता है और इसे Intlayer द्वारा compiled dictionaries से serve करता है। आपकी `.vue` files नहीं बदलती हैं। जो `t("footer.github")` से bound है, वह बदलता है।
+
+यह लेख एक ही Vite + Vue 3 एप्लिकेशन पर इस स्वैप को मापता है, एक बार `vue-i18n` के साथ और एक बार एडेप्टर के साथ निर्मित। संख्याएँ [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom) से आती हैं। `vue-i18n` और Intlayer की तुलना लाइब्रेरी के रूप में करने के लिए, [vue-i18n vs Intlayer](https://intlayer.org/blog/vue-i18n-vs-intlayer) और [vue-i18n vs Intlayer benchmark](https://intlayer.org/blog/vue-i18n-vs-intlayer-benchmark) पढ़ें। यह इस बारे में है कि जब आप अपने components को वैसे ही रखते हैं तो एडेप्टर क्या बदलता है।
+
+<TOC/>
+
+> **tl;dr**: एक ही Vite + Vue 3 ऐप्लिकेशन पर, `vue-i18n` को `@intlayer/vue-i18n` से बदलने से प्रति-पृष्ठ JavaScript **134.9 KB से 47.0 KB** gzip तक कम हो गया (i18n के बिना ऐप 41.3 KB वजन का है), runtime **24.3 KB से 7.9 KB**, औसत component **196 KB से 8.4 KB**, और foreign-page string leakage **90% से 0%**, बिना किसी `.vue` फ़ाइल को संपादित किए। `createI18n({ messages })` fallback के रूप में काम करता रहता है; ऊपर दिए गए नंबर प्राप्त करने के लिए JSON imports हटाएं। SFC `<i18n>` blocks और runtime `setLocaleMessage()` वे दो features हैं जो carry over नहीं होते हैं।
+
+## `@intlayer/vue-i18n` क्या है
+
+`vue-i18n` एक runtime है। `createI18n({ messages: { en, fr, ... } })` हर locale के हर message को hold करने वाला एक global instance बनाता है; `useI18n()` हर component को इससे bind करता है; `t("footer.github")` render time पर tree को traverse करता है। यह design SFC `<i18n>` blocks और `setLocaleMessage()` को संभव बनाता है, और यह भी है कि क्यों हर component का dependency graph पूरे tree को शामिल करता है।
+
+`@intlayer/vue-i18n` API को keep करता है और tree को replace करता है:
+
+1. **Import aliasing.** `@intlayer/vue-i18n/plugin` से `vueI18nVitePlugin()` `vite-intlayer` को wrap करता है और एक `resolve.alias` add करता है ताकि `vue-i18n` `@intlayer/vue-i18n` को resolve करे। कोई import rename नहीं है।
+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"
+<!-- आपका कोड, अपरिवर्तित -->
+<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="कंपाइलर जारी करता है (सरलीकृत)"
+import _dicHash_footer from "../.intlayer/dictionaries/footer.mjs";
+import { useDictionary as useI18n } from "@intlayer/vue-i18n";
+
+const { t } = useI18n(_dicHash_footer);
+```
+
+घटक अब वैश्विक संदेश ट्री तक नहीं पहुंचता है। यह `footer` तक पहुंचता है। यही कारण है कि नीचे दिए गए घटक-आकार स्तंभ 196 KB से 8 KB तक गिरता है।
+
+## एडेप्टर क्या रखता है, अनदेखा करता है, और प्रतिस्थापित नहीं करता है
+
+| `vue-i18n` API                                                      | `@intlayer/vue-i18n` के साथ                                                                                                             |
+| ------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
+| `useI18n()` → `{ t, d, n, te, tm, rt, locale, availableLocales }`   | ✅ संरक्षित। `t` keys आपके dictionaries के विरुद्ध typed हैं                                                                            |
+| `t("key", { name })`, `t("key", [a, b])`, `t("key", count)`         | ✅ संरक्षित। `{name}`, `{0}` और pipe-separated plurals पहले की तरह resolve होते हैं                                                     |
+| `d(date, "long")`, `n(value, "currency")`                           | ✅ संरक्षित। `createI18n()` से `datetimeFormats` / `numberFormats` को सम्मानित किया जाता है, native `Intl` द्वारा backed                |
+| `i18n.global.locale.value = "fr"`                                   | ✅ रखा गया। एक `WritableComputedRef` जो Intlayer के क्लाइंट द्वारा समर्थित है; reactivity पहले की तरह व्यवहार करता है                   |
+| `$t`, `$tc`, `$te`, `$tm`, `$rt`, `$d`, `$n`, `$i18n` (Options API) | ✅ रखा गया। `app.use(i18n)` द्वारा `app.config.globalProperties` पर पंजीकृत                                                             |
+| `v-t` निर्देश                                                       | ✅ रखा गया                                                                                                                              |
+| `legacy: true`                                                      | ✅ स्वीकार किया गया                                                                                                                     |
+| `createI18n({ messages })`                                          | ⚠️ `messages` को **runtime fallback** के रूप में उपयोग किया जाता है जिसमें एक dev warning है। Bundle gains के लिए JSON imports को हटाएं |
+| `setLocaleMessage()`, `mergeLocaleMessage()`                        | ❌ चेतावनी दें और कुछ न करें। Runtime message loading को build-time dictionaries से बदल दिया गया है                                     |
+| SFC `<i18n>` custom blocks                                          | ❌ नहीं पढ़े गए। उन messages को locale JSON में (या component के बगल में `.content.ts` में) स्थानांतरित करें                            |
+| `@nuxtjs/i18n`                                                      | ⚠️ अलग adapter, [Nuxt compat doc](https://intlayer.org/doc/compatibility/nuxtjs-i18n) देखें                                             |
+
+## बेंचमार्क
+
+### क्या मापा गया था
+
+[Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom) suite **एक ही Vite + Vue 3 एप्लिकेशन** को प्रत्येक setup के साथ बनाता है: **10 pages** (home, about, blog, careers, contact, FAQ, pricing, products, settings, team), **10 locales** (`en`, `fr`, `es`, `de`, `it`, `pt`, `zh`, `ja`, `ko`, `ru`), identical components और identical content। Pages को `en` और `fr` में मापा जाता है।
+
+दोनों को **static** configuration में बनाया गया था, वह configuration जो अधिकांश Vue projects ship करते हैं: `vue-i18n` के लिए, हर locale का JSON imported और `createI18n({ messages })` को pass किया जाता है; adapter के लिए, `vite.config.ts` और `intlayer.config.ts` को बदले जाने के साथ same components और `messages` import को हटाया जाता है। Native `vue-intlayer` को reference के लिए शामिल किया गया है।
+
+प्रत्येक build के लिए, suite निम्नलिखित को record करता है:
+
+- **Lib size**: एक खाली component का gzip (और minified) size जो केवल i18n library को import करता है।
+- **Page JS**: प्रति page download किया गया gzip JavaScript, सभी pages और locales पर averaged।
+- **Locale leak %**: downloaded JS में translated strings का share जो एक locale के हैं जिसे user **नहीं** देख रहा है।
+- **Page leak %**: downloaded JS में translated strings का share जो एक page के हैं जिस page पर user **नहीं** है।
+- **Component avg**: प्रत्येक component का average gzip size जो isolation में compiled है।
+- **E2E reactivity**: एक नया locale select करने और DOM में `html[lang]` update होने के बीच wall-clock time (Playwright, 5 iterations)।
+- **Page load**: `PerformanceNavigationTiming.duration`।
+
+> नीचे दी गई संख्याएं **2026-09-12** को `vue-i18n` 11.4.0 और `@intlayer/vue-i18n` 9.5.1 के साथ चलाने से आई हैं। test application जानबूझकर छोटा है (प्रति locale कुछ दर्जन strings), इसलिए leakage percentages एक **pattern** का वर्णन करते हैं: ये आपकी content के साथ बढ़ते हैं जबकि runtime cost fixed रहता है।
+
+### 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** (कोई 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 |
+
+> base app का page-leak column खाली छोड़ा गया है: बिना i18n library के, fingerprinting shared chunks में hard-coded strings को pick करता है और संख्या meaningful नहीं होती है।
+
+**इसे कैसे पढ़ें**
+
+- **88 KB प्रति page कम, same components।** `vue-i18n` app को 41.3 KB से **134.9 KB** तक ले जाता है। उसी components का adapter build **47.0 KB** पर landing करता है, base app से 5.7 KB ऊपर। ज्यादातर अंतर 74.9 KB का `src/locales` है जो `createI18n({ messages })` हर page में pull करता है और adapter कभी एक block के रूप में bundle नहीं करता है।
+- **Runtime 3x सिकुड़ता है।** एक खाली component जो केवल `vue-i18n` import करता है उसकी कीमत **24.3 KB gzip / 83.2 KB minified** है: `@intlify/core-base`, message compiler और runtime। Adapter की कीमत **7.9 KB / 23.2 KB** है, इसमें अधिकांश Intlayer का core और `vue-i18n` API surface है।
+- **Components: 23x छोटे।** एक `useI18n()` component जो isolation में compile होता है औसतन **196 KB** होता है, क्योंकि `t` उस instance से bound होता है जो हर locale का हर message रखता है। Adapter के साथ, वही component औसतन **8.4 KB** होता है: यह अपने dictionary तक पहुंचता है।
+- **Leakage.** `vue-i18n` हर पेज पर हर locale और हर पेज की सभी strings को भेजता है: 50% locale leakage (दोनों fingerprinted locales पर; दस locales bundled होने पर वास्तविक waste अधिक है), 90% page leakage। Adapter page leakage को **0%** तक कम करता है क्योंकि प्रत्येक component केवल अपने dictionaries को import करता है। Locale leakage इस `static` run में 15% पर बैठी है; `importMode: 'dynamic'` वह setting है जो इसे हटाती है, और वह configuration इस Vue run का हिस्सा नहीं था।
+- **Reactivity और page load.** Locale switching दोनों के लिए सस्ता है (1.5-2.8 ms); Vue की reactivity system एक बार जब messages मेमोरी में हों तो ऐसा बनाती है। Page load 13.6 ms से **9.3 ms** तक जाता है, जो 88 KB कम JavaScript parse करने के अनुरूप है।
+- **नेटिव पंक्तियों के बारे में।** `vue-intlayer` इस रन में `static` मोड में हर लोकेल को बंडल करता है और 3.9 KB रनटाइम के साथ 57.1 KB पर पहुंचता है; एडेप्टर के सिंक्रोनाइज़्ड डिक्शनरीज़ में कम विदेशी-लोकेल स्ट्रिंग्स थीं, इसलिए प्रति-पृष्ठ आंकड़ा कम है। नेटिव रनटाइम तीनों में सबसे हल्का रहता है, और इसका `.content.ts` मॉडल वह जगह है जहां SFC `<i18n>` ब्लॉक अपने समकक्ष को खोजते हैं।
+
+## संख्याएं क्यों बदलती हैं
+
+`src/components/` में कुछ भी नहीं बदला, इसलिए लाभ इसी से आते हैं कि `useI18n` किससे बंधा है।
+
+**`vue-i18n` के साथ**, binding global instance है। `createI18n({ messages: { en, fr, ... } })` एक import है जो सब कुछ hold करता है; हर component जो `useI18n()` को call करता है वह सब कुछ तक पहुँच सकता है, इसलिए bundler instance के नीचे split नहीं कर सकता। Optimizing का मतलब है कि _आप_ `en.json` को route से split करें, एक router guard में `setLocaleMessage()` को call करें, और जैसे components move हों वैसे route-to-file map को सही रखें।
+
+```bash
+.
+├── locales
+│   ├── en.json                    # हर page की strings
+│   └── fr.json
+└── src
+    ├── i18n.ts                    # createI18n({ messages: { en, fr, ... } })
+    ├── main.ts                    # app.use(i18n)
+    └── components
+        └── Footer.vue             # useI18n(); t("footer.github")
+```
+
+**`@intlayer/vue-i18n` के साथ**, binding dictionary है। `syncJSON` `en.json` की प्रत्येक top-level key को एक dictionary में बदल देता है; optimize pass component को उन्हें देता है जिनकी keys का नाम है, जैसे imports जिन्हें bundler trace करता है और प्रति पृष्ठ split करता है।
+
+```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
+```
+
+`i18n.ts` में `messages` import वह एक पंक्ति है जिसे हटाना है। वह 88 KB है।
+
+## तीन चरणों में माइग्रेशन
+
+<Steps>
+<Step number={1} title="इंस्टॉल करें">
+
+```bash packageManager="npm"
+npx intlayer init --interactive
+```
+
+```bash packageManager="pnpm"
+pnpm dlx intlayer init --interactive
+```
+
+```bash packageManager="yarn"
+yarn dlx intlayer init --interactive
+```
+
+```bash packageManager="bun"
+bunx intlayer init --interactive
+```
+
+कमांड `vue-i18n` का पता लगाता है, `intlayer`, `vue-intlayer`, `@intlayer/vue-i18n` और `@intlayer/sync-json-plugin` इंस्टॉल करता है, और `intlayer.config.ts` को पहले से भरता है। `vue-i18n` को इंस्टॉल रखें: यह एक peer dependency है और types प्रदान करता है।
+
+</Step>
+<Step number={2} title="Intlayer को अपनी लोकेल फाइलों की ओर इंगित करें">
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+import { syncJSON } from "@intlayer/sync-json-plugin";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    defaultLocale: Locales.ENGLISH,
+  },
+  dictionary: {
+    // "static" हर locale को bundle करता है; "dynamic" आवश्यकता के अनुसार सक्रिय को लोड करता है
+    importMode: "dynamic",
+    format: "vue-i18n",
+  },
+  plugins: [
+    syncJSON({
+      // vue-i18n dialect: {name}, {0}, "car | cars"
+      format: "vue-i18n",
+      source: ({ locale }) => `./locales/${locale}.json`,
+      location: "locales",
+    }),
+  ],
+};
+
+export default config;
+```
+
+`locales/{locale}.json` अपनी जगह पर रहता है। हर top-level key (`footer`, `hero`...) एक dictionary बन जाती है।
+
+</Step>
+<Step number={3} title="प्लगइन जोड़ें और संदेशों के आयात को हटाएं">
+
+```ts fileName="vite.config.ts"
+import { defineConfig } from "vite";
+import vue from "@vitejs/plugin-vue";
+import { vueI18nVitePlugin } from "@intlayer/vue-i18n/plugin";
+
+export default defineConfig({
+  plugins: [vue(), vueI18nVitePlugin()],
+});
+```
+
+```ts fileName="src/i18n.ts"
+import { createI18n } from "vue-i18n";
+
+// पहले: createI18n({ locale: "en", messages: { en, fr, es } })
+export const i18n = createI18n({ locale: "en" });
+```
+
+`vueI18nVitePlugin()` `vite-intlayer` को लपेटता है (content watching, dictionary compilation, optimize pass) और `vue-i18n` को adapter के रूप में alias करता है। `messages` import को हटाना ही 88 KB को छोड़ता है; इसे रखने से ऐप काम करता रहता है लेकिन दोनों को ship करता है।
+
+</Step>
+</Steps>
+
+### आप बाद में क्या हटा सकते हैं
+
+| File / pattern                                  | Why                                                                                   |
+| ----------------------------------------------- | ------------------------------------------------------------------------------------- |
+| `import en from "./locales/en.json"` और friends | Adapter द्वारा केवल फॉलबैक के रूप में उपयोग किया जाता है। यह वह जगह है जहां 88 KB था  |
+| `setLocaleMessage()` in router guards           | No-op। प्रति-route लोडिंग अब compiler का काम है                                       |
+| `@intlify/unplugin-vue-i18n`                    | आवश्यक नहीं: यह messages को precompile करता है और SFC blocks को adapter नहीं पढ़ता है |
+| SFC `<i18n>` ब्लॉक्स                            | पढ़े नहीं जाते; उन्हें locale JSON या प्रति component `.content.ts` में ले जाएं       |
+
+### आप बाइट्स से परे क्या हासिल करते हैं
+
+- **Typed keys।** `t("footer.github")` को compiled `footer` dictionary के विरुद्ध type किया जाता है; एक गलत path TypeScript error है जो key को text के रूप में rendered करने के बजाय।
+- **`npx intlayer test`** किसी भी locale में एक missing key पर CI को विफल करता है। **`npx intlayer fill`** missing ones को आपके own provider key (OpenAI, Anthropic, Mistral, Gemini...) से translate करता है और उन्हें `locales/{locale}.json` में वापस लिखता है।
+- **Visual Editor और CMS** एक ही JSON पर operate करते हैं, इसलिए non-developers एक UI के माध्यम से edit करते हैं और files update हो जाती हैं।
+- **`.content.ts` में incremental move करें।** कोई भी component `useI18n()` से `useIntlayer("footer")` में switch कर सकता है एक co-located content file के साथ। JSON और `.content.ts` dictionaries coexist करते हैं और merge होते हैं।
+
+## शुरू करने से पहले जानने योग्य सीमाएं
+
+- **SFC `<i18n>` blocks को read नहीं किया जाता है।** यदि आपके messages components के अंदर हैं, तो उन्हें locale files में move करने की आवश्यकता है (या `.content.ts` में, जो types के साथ एक ही विचार है)।
+- **Runtime message loading gone है।** `setLocaleMessage()` और `mergeLocaleMessage()` warn करते हैं और return करते हैं। Runtime पर CMS से fetch किए गए translations को Intlayer के CMS की आवश्यकता है, या `intlayer pull` / `push` commands की।
+- **`messages` एक fallback है, free नहीं है।** `createI18n()` में JSON imports को रखने से bundle में 75 KB रहता है। एक बार `intlayer test` pass होने के बाद उन्हें delete करें।
+- **adapter native runtime नहीं है।** `vue-intlayer` के लिए 3.9 KB के मुकाबले 7.9 KB। एक बार जब हर component `useIntlayer` पर चला गया हो, तो इसे छोड़ दें।
+
+## कौन सा कब उपयोग करें?
+
+- **`vue-i18n` पर बने रहें** यदि आपका app SFC `<i18n>` blocks पर निर्भर करता है, runtime `setLocaleMessage()` flows पर, या यदि 90 KB प्रति page आपके audience के लिए चिंता का विषय नहीं है।
+- **`@intlayer/vue-i18n` का उपयोग करें** यदि आप `vue-i18n` पर हैं और 88 KB, 23x छोटे components, 0% page leakage, typed keys और CI checks चाहते हैं बिना किसी `.vue` file को edit किए। यह एक existing `vue-i18n` codebase के लिए entry point है।
+- **Native पर जाएं (`vue-intlayer`)** नई projects के लिए, या एक बार adapter ने अपना काम कर दिया हो। इसके पास सबसे हल्का runtime (3.9 KB) और per-component `.content.ts` model है जो `<i18n>` blocks को typed content से replace करता है।
+
+## संबंधित तुलनाएं
+
+- [vue-i18n vs Intlayer](https://intlayer.org/blog/vue-i18n-vs-intlayer) (features और DX)
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/blog/vue-i18n-vs-intlayer-benchmark) (libraries, same benchmark)
+- [next-intl vs @intlayer/next-intl](https://intlayer.org/blog/next-intl-vs-intlayer-next-intl) (same adapter series)
+- [i18next vs @intlayer/i18next](https://intlayer.org/blog/i18next-vs-intlayer-i18next) (same adapter series)
+- [Lingui vs @intlayer/lingui](https://intlayer.org/blog/lingui-vs-intlayer-lingui) (same adapter series)
+- [Migration guide: vue-i18n to Intlayer](https://intlayer.org/doc/migration/vue-i18n)
+- [Compat adapter reference: vue-i18n](https://intlayer.org/doc/compatibility/vue-i18n), [Nuxt i18n](https://intlayer.org/doc/compatibility/nuxtjs-i18n)
+
+## निष्कर्ष
+
+`@intlayer/vue-i18n` `useI18n()` को जो है उससे बदलता है: एक global instance जो हर locale के हर message को hold करता है से एक dictionary में जो उस component के लिए compile है। Vite + Vue 3 app के **88 KB कम प्रति पृष्ठ**, **3x छोटा runtime**, **23x छोटे components** और **0% पृष्ठ leakage** के साथ, एक config file, एक plugin line और एक deleted import के लिए। SFC `<i18n>` blocks और runtime message loading ये दो चीजें हैं जो यह carry नहीं करता, और native `vue-intlayer` runtime अपने आकार का आधा रहता है।
+
+[Benchmark Bloom repository](https://github.com/intlayer-org/benchmark-bloom) में सभी raw data, test apps और scripts हैं। इसे अपने आप चलाएं।
+
+अधिक विवरण के लिए ['Why Intlayer?' doc](https://intlayer.org/doc/why) देखें।

package/blog/id/history_of_i18n.md

@@ -0,0 +1,304 @@
+---
+createdAt: 2026-09-09
+updatedAt: 2026-09-10
+title: "Sejarah i18n JavaScript: Dari 2011 hingga 2026"
+description: Pelajari evolusi internasionalisasi frontend dari tahun 2011 hingga 2026. Temukan tanggal rilis, tantangan arsitektur, dan inovasi utama di React, Vue, Next.js, Angular, Svelte, dan Solid.
+keywords:
+  - sejarah i18n
+  - internasionalisasi JavaScript
+  - React i18n
+  - Next.js i18n
+  - Vue i18n
+  - Angular i18n
+  - Svelte i18n
+  - Solid i18n
+  - i18next
+  - intlayer
+slugs:
+  - blog
+  - history-of-js-internationalization
+author: aymericzip
+---
+
+# Sejarah Internasionalisasi JavaScript (i18n)
+
+Internasionalisasi bukanlah hal baru. Jauh sebelum JavaScript dan web modern hadir, perangkat lunak sudah harus menangani berbagai bahasa, mata uang, format tanggal, dan konvensi regional. Sistem operasi grafis awal seperti GEM dan Mac OS telah memecahkan banyak masalah ini sejak tahun 1980-an.
+
+Konsep yang sama akhirnya diadopsi oleh framework backend. Ruby on Rails, Django, framework Java, dan aplikasi PHP masing-masing mengembangkan pendekatan internasionalisasi mereka sendiri. Masalah dasarnya sudah cukup dipahami dengan baik:
+
+- Di mana terjemahan harus disimpan?
+- Bagaimana kita memformat tanggal, angka, dan mata uang?
+- Bagaimana kita menangani bentuk jamak dan perbedaan tata bahasa?
+- Bagaimana kita menentukan bahasa mana yang harus dilihat pengguna?
+
+Ketika server me-render halaman, prosesnya relatif mudah. Aplikasi dapat memuat terjemahan yang sesuai, me-render HTML, dan mengirimkan hasilnya ke browser.
+
+> Perhatikan bahwa PHP dan GNU gettext merupakan cikal bakal pola helper `t()` yang kemudian menjadi standar di JavaScript dan JSX.
+
+Kemudian JavaScript mulai mengambil alih browser.
+
+Ketika aplikasi beralih dari halaman yang di-render server ke aplikasi client-side yang semakin kompleks, internasionalisasi juga menjadi tantangan di frontend. Tiba-tiba, browser harus memuat terjemahan, beralih bahasa, memformat nilai, menangani bentuk jamak, dan memperbarui UI tanpa memuat ulang halaman.
+
+Dan itu memunculkan pertanyaan baru:
+
+**Bagaimana cara membuat aplikasi multibahasa tanpa mengirimkan data terjemahan dan kode runtime dalam jumlah besar ke setiap pengguna?**
+
+Pertanyaan tersebut telah membentuk arah pengembangan JavaScript i18n selama lebih dari satu dekade.
+
+Solusinya telah banyak berubah. Kita beralih dari objek global JavaScript dan pemanggilan `t('some.key')`, ke pustaka khusus framework, ekstraksi waktu kompilasi (compile-time), tipe yang dibuat oleh TypeScript, komponen server, tree-shaking, hingga pendekatan berbasis compiler di mana terjemahan diubah menjadi kode JavaScript selama proses build.
+
+Artikel ini mengulas evolusi tersebut dari sekitar tahun 2011 hingga 2026: apa yang dicoba diselesaikan oleh setiap generasi alat, apa yang berhasil, apa yang tidak, dan bagaimana arsitektur aplikasi frontend memengaruhi cara kita menangani i18n saat ini.
+
+![Ekosistem Pustaka Internasionalisasi JavaScript](https://github.com/aymericzip/intlayer/blob/main/docs/assets/cloud_i18n_logo.png?raw=true)
+
+## Daftar Isi
+
+<TOC/>
+
+## Era Web Awal: Internasionalisasi JavaScript Sebelum 2016
+
+Untuk memahami posisi alat i18n modern saat ini, kita perlu melihat kembali bagaimana rasanya membangun aplikasi web antara tahun 2011 dan 2015.
+
+### Migrasi Logika ke Client
+
+Pada awal dekade 2010-an, internasionalisasi sebagian besar merupakan tanggung jawab sisi server. JavaScript umumnya hanya berfungsi sebagai lapisan tambahan untuk animasi, validasi formulir, dan widget DOM sederhana melalui jQuery.
+
+Seiring meningkatnya popularitas Single-Page Applications (SPA) dengan Backbone.js, Knockout.js, dan versi awal AngularJS, logika rendering berpindah langsung ke browser. Kode client-side tiba-tiba perlu menampilkan tanggal lokal, memformat mata uang, menangani bentuk jamak, dan menukar teks secara dinamis tanpa refresh halaman penuh.
+
+Namun lingkungan browser pada tahun 2011 belum siap menghadapi tantangan ini:
+
+<AccordionGroup>
+<Accordion header="Tidak ada API internasionalisasi bawaan">
+
+Spesifikasi ECMAScript Internationalization API (ECMA-402) baru diselesaikan pada Desember 2012, memperkenalkan objek global `Intl`. Sebelum vendor browser mengadopsi `Intl`, pemformatan tanggal dan angka paling mendasar sekalipun memerlukan fungsi kustom atau polyfill yang berat.
+
+</Accordion>
+<Accordion header="Belum ada bundler modul modern">
+
+Alat seperti Webpack masih dalam tahap awal, dan ESM belum didukung langsung di browser. Pengembang memuat skrip melalui tag `<script>`, sering kali menyuntikkan terjemahan ke dalam objek global seperti `window.translations = { ... }`.
+
+</Accordion>
+<Accordion header="Payload JSON monolitik">
+
+Terjemahan ditulis dalam file JSON terpusat yang sangat besar. Seorang pengguna di Tokyo yang membuka halaman beranda tetap mengunduh string untuk pengaturan akun, panel penagihan, dan dasbor admin.
+
+</Accordion>
+</AccordionGroup>
+
+### Gelombang Pertama Pustaka Client-Side
+
+Antara tahun 2012 dan 2015, fondasi awal i18n JavaScript modern mulai dibangun:
+
+<AccordionGroup>
+<Accordion header="i18next (Januari 2012)">
+
+Diciptakan oleh Jan Mühlemann, `i18next` menetapkan cetak biru untuk kamus key-value runtime di JavaScript. Pustaka ini memperkenalkan penelusuran kunci, interpolasi variabel, aturan pluralisasi, serta arsitektur yang dapat diperluas untuk detektor bahasa dan backend. Pustaka ini segera menjadi standar di vanilla JS dan backend awal Node.js.
+
+</Accordion>
+<Accordion header="vue-i18n (Mei 2014)">
+
+Diciptakan oleh Kazupon (Kazuya Kawaguchi), `vue-i18n` mengadaptasi internasionalisasi langsung ke model data-binding reaktif Vue.js, memperkenalkan direktif template (`v-t`) dan helper `$t()`.
+
+</Accordion>
+<Accordion header="react-intl (Juni 2014)">
+
+Diciptakan oleh Yahoo! sebagai bagian dari proyek FormatJS, `react-intl` membawa standar ICU MessageFormat dan API browser `Intl` ke React melalui komponen deklaratif seperti `<FormattedMessage>` dan `<FormattedDate>`.
+
+</Accordion>
+<Accordion header="react-i18next (Desember 2015)">
+
+Jan Mühlemann membawa `i18next` ke komunitas React yang berkembang pesat, memanfaatkan Higher-Order Components (`withTranslation`) dan React context untuk me-render ulang komponen saat terjadi pergantian bahasa.
+
+</Accordion>
+</AccordionGroup>
+
+### Keterbatasan Era Pra-2016
+
+Meskipun alat-alat ini memungkinkan aplikasi client multibahasa, kendala arsitektur pada era tersebut menimbulkan masalah berkelanjutan:
+
+<AccordionGroup>
+<Accordion header="Kunci String yang Rapuh">
+
+Pencarian seperti `t('marketing.landing.hero.cta')` tidak menyediakan verifikasi statis. Kesalahan ketik pada kunci gagal secara diam-diam di lingkungan produksi, menampilkan teks kosong atau ID kunci mentah kepada pengguna akhir.
+
+</Accordion>
+<Accordion header="Beban Parsing Runtime">
+
+Mem-parsing sintaks pesan ICU dan mengevaluasi interpolasi berbasis regex saat runtime menghabiskan siklus CPU pada perangkat seluler.
+
+</Accordion>
+<Accordion header="Ukuran Bundle yang Membengkak">
+
+Tanpa pemisahan kode berbasis rute atau komponen, semua string terlokalisasi dimuat sekaligus, memperlambat metrik pemuatan halaman awal.
+
+</Accordion>
+<Accordion header="Jarak antara Pengembang dan Penerjemah">
+
+Kamus disimpan dalam file JSON terpusat yang jauh dari komponen yang menampilkannya, menyebabkan kunci terbengkalai dan terjemahan yang hilang menjadi hal yang biasa.
+
+</Accordion>
+</AccordionGroup>
+
+## Era Framework: Evolusi di Berbagai Ekosistem
+
+Antara tahun 2016 dan 2026, arsitektur frontend berubah secara mendasar. TypeScript menjadi standar industri, arsitektur berbasis komponen semakin matang, bundler seperti Webpack, Vite, dan Turbopack memperkenalkan code-splitting, React Server Components mengembalikan rendering ke server, dan compiler mulai menganalisis kode aplikasi.
+
+Tab berikut menyajikan bagaimana setiap framework dan ekosistem menjawab tantangan ini, mendokumentasikan tanggal rilis, motivasi utama, dan inovasi penting dalam tabel perbandingan. Di seluruh ekosistem ini, `react-intlayer` dan seluruh padanannya (`next-intlayer`, `vue-intlayer`, `angular-intlayer`, `svelte-intlayer`, dan `solid-intlayer`) merupakan implementasi berkinerja tinggi yang dirancang khusus untuk lingkungan runtime masing-masing.
+
+<Tabs>
+
+<Tab label="Core JavaScript" value="javascript">
+
+| Rilis Pertama | Pustaka                              | Masalah yang Ingin Dipecahkan                                                                                                                                | Inovasi Utama                                                                                                                                                      |
+| ------------- | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| Januari 2012  | `i18next`                            | Menstandarisasi pencarian kamus runtime untuk browser dan Node.js tanpa keterikatan framework.                                                               | Arsitektur runtime modular yang memisahkan terjemahan inti dari pemuat, detektor, dan caching.                                                                     |
+| Februari 2021 | `typesafe-i18n`                      | Mencegah kesalahan runtime diam-diam akibat kunci string tanpa tipe data.                                                                                    | Fungsi terjemahan bertipe penuh yang dibuat langsung dari objek terjemahan tanpa dependensi runtime.                                                               |
+| Oktober 2023  | `paraglide` (`@inlang/paraglide-js`) | Menghilangkan pencarian kamus runtime, parser berat, dan pembengkakan ukuran bundle.                                                                         | Mengompilasi pesan menjadi modul ECMAScript yang mendukung tree-shaking dan fungsi JS murni.                                                                       |
+| April 2024    | `intlayer`                           | Menggantikan namespace yang sulit dipelihara, menghindari kebocoran konten antarhalaman, dan menyelesaikan kurangnya keamanan tipe bawaan di era TypeScript. | Menempatkan file `.content` langsung di tempat fungsi dipanggil, membuat tipe TypeScript otomatis, serta menyediakan CMS visual dan alat CLI terjemahan AI bawaan. |
+| Juni 2025     | `wuchale`                            | Menghilangkan kerumitan mengekstrak string teks secara manual dan membuat kunci terjemahan saat pengembangan.                                                | Pra-pemrosesan tingkat AST yang mendeteksi teks inline dan mengompilasinya menjadi fungsi lokal tanpa wrapper saat build.                                          |
+
+</Tab>
+
+<Tab label="React" value="react">
+
+| Rilis Pertama | Pustaka          | Masalah yang Ingin Dipecahkan                                                                                                     | Inovasi Utama                                                                                                                                          |
+| ------------- | ---------------- | --------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| Juni 2014     | `react-intl`     | Menstandarisasi pemformatan angka, tanggal, mata uang, dan jamak kompleks di React.                                               | Komponen deklaratif (`<FormattedMessage>`, `<FormattedDate>`) yang mengimplementasikan standar ICU MessageFormat dan ECMA-402.                         |
+| Desember 2015 | `react-i18next`  | Menyediakan binding React yang idiomatis untuk `i18next` dengan rendering ulang reaktif.                                          | Berkembang bersama React dari Higher-Order Components ke interpolasi JSX `<Trans>` dan hook `useTranslation`.                                          |
+| Januari 2018  | `@lingui/react`  | Mengurangi penalti ukuran bundle JavaScript yang disebabkan oleh parser ICU runtime.                                              | Makro Babel/SWC waktu kompilasi yang menyusun `<Trans>` dan `t` menjadi array terindeks yang ringkas saat build.                                       |
+| Desember 2020 | `use-intl`       | Memberikan alternatif ringan, berbasis hook, dan aman secara tipe untuk pustaka i18n React tradisional.                           | Hook ergonomis `useTranslations` dan `useFormatter` dengan integrasi TypeScript yang mendalam.                                                         |
+| Februari 2021 | `@tolgee/react`  | Menghilangkan siklus umpan balik yang lambat antara pengembang, penerjemah, dan desainer.                                         | Pengeditan kontekstual di browser yang memungkinkan pengguna menekan Alt-klik pada teks untuk mengedit langsung dan mengambil screenshot.              |
+| April 2024    | `react-intlayer` | Menyediakan implementasi Intlayer berkinerja tinggi untuk siklus hidup React, meniadakan kamus JSON terpusat dan namespace rumit. | Hook `useIntlayer` yang dioptimalkan untuk rendering React, tipe TypeScript otomatis, tree-shaking per komponen, dan sinkronisasi CMS visual langsung. |
+| Juli 2024     | `gt-react`       | Mengotomatiskan ekspor file manual, serah terima penerjemah, dan pemeliharaan terjemahan.                                         | Lokalisasi AI otomatis cloud-native langsung di dalam komponen React dengan jalur terjemahan mesin.                                                    |
+| Agustus 2025  | `@wuchale/jsx`   | Menghilangkan penamaan kunci manual dan boilerplate hook terjemahan dalam JSX React.                                              | Transformasi AST yang mengekstrak node teks JSX mentah secara otomatis dan mengompilasinya menjadi bentuk lokal.                                       |
+
+</Tab>
+
+<Tab label="Next.js" value="nextjs">
+
+| Rilis Pertama  | Pustaka                                     | Masalah yang Ingin Dipecahkan                                                                                                          | Inovasi Utama                                                                                                                                                                                        |
+| -------------- | ------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| November 2018  | `next-i18next`                              | Mendukung SSR dan SSG dengan `i18next` di Next.js Pages Router tanpa request waterfall di client.                                      | `serverSideTranslations` dan `appWithTranslation` meneruskan namespace lokal ke page props.                                                                                                          |
+| Desember 2019  | `next-translate`                            | Menyederhanakan konfigurasi dan mengurangi bobot bundle pada aplikasi Next.js Pages Router.                                            | Plugin Webpack loader yang menyuntikkan hanya namespace terjemahan yang diperlukan per halaman secara otomatis.                                                                                      |
+| November 2020  | `next-intl`                                 | Merancang ulang i18n Next.js untuk App Router, React Server Components (RSC), dan streaming SSR.                                       | Integrasi native dengan middleware Next.js App Router, Server Actions, dan Server Components asinkron tanpa JS di client.                                                                            |
+| Juli 2022      | `next-international`                        | Memaksimalkan keamanan tipe TypeScript dengan overhead bundle client minimal untuk Next.js.                                            | Pembuatan tipe ketat untuk kunci terjemahan terlingkup dengan adapter ringan untuk App Router dan Pages Router.                                                                                      |
+| April 2024     | `paraglide-next` (`@inlang/paraglide-next`) | Membawa pesan terkompilasi zero-runtime ke Next.js App Router dan Pages Router.                                                        | Perutean middleware yang dipadukan dengan fungsi pesan tree-shakable, menghindari parsing JSON runtime di RSC dan bundle client.                                                                     |
+| April 2024     | `next-intlayer`                             | Menyediakan adapter Server Component berkinerja tinggi untuk Next.js App Router dan Pages Router tanpa meneruskan `t()` sebagai props. | Adapter Server Component bawaan yang memungkinkan `useIntlayer` dipanggil langsung di komponen server sinkron (seperti Navbar) tanpa prop-drilling, disertai rendering server instan dan CMS visual. |
+| September 2024 | `gt-next`                                   | Mengotomatiskan pembuatan konten multibahasa dan perutean lokal dinamis di Next.js menggunakan AI.                                     | Integrasi App Router yang memadukan terjemahan mesin berbasis cloud dengan edge middleware dan lapisan caching Next.js.                                                                              |
+
+</Tab>
+
+<Tab label="Vue & Nuxt" value="vue">
+
+| Rilis Pertama | Pustaka        | Masalah yang Ingin Dipecahkan                                                                                                 | Inovasi Utama                                                                                                                                                   |
+| ------------- | -------------- | ----------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Mei 2014      | `vue-i18n`     | Menyediakan internasionalisasi reaktif dan idiomatis untuk aplikasi Vue.                                                      | Integrasi reaktivitas mendalam, direktif template (`v-t`), helper `$t`, dan custom block `<i18n>` pada Single-File Component.                                   |
+| November 2017 | `@nuxt/i18n`   | Menangani routing URL lokal, tag SEO hreflang, dan hidrasi SSR di Nuxt.                                                       | Modul perutean full-stack yang menghasilkan rute lokal, header meta SEO, dan pemuatan chunk secara lazy.                                                        |
+| Agustus 2019  | `fluent-vue`   | Menangani gender tata bahasa, kasus gramatikal yang kompleks, dan struktur bahasa asimetris di Vue.                           | Integrasi sintaks Mozilla Project Fluent di Vue untuk menghindari logika kondisional yang rumit dalam variasi linguistik.                                       |
+| April 2025    | `vue-intlayer` | Menyediakan implementasi Intlayer yang dirancang langsung untuk Vue 3 Composition API dan Nuxt tanpa polusi namespace global. | Composable `useIntlayer` yang disesuaikan untuk pelacakan reaktivitas Vue 3, pelingkupan komponen langsung, autocompletion TypeScript penuh, dan editor visual. |
+
+</Tab>
+
+<Tab label="Angular" value="angular">
+
+| Rilis Pertama  | Pustaka             | Masalah yang Ingin Dipecahkan                                                                                     | Inovasi Utama                                                                                                                        |
+| -------------- | ------------------- | ----------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| Februari 2017  | `ngx-translate`     | Menyediakan terjemahan dinamis saat runtime di Angular tanpa perlu build terpisah untuk setiap bahasa.            | `TranslateService` dan pipe `translate` yang memungkinkan pemuatan terjemahan dinamis dan pergantian bahasa runtime.                 |
+| Juli 2019      | `@ngneat/transloco` | Menyelesaikan masalah performa, ketiadaan scoping, dan fitur yang kurang pada pustaka Angular lama.               | Direktif struktural (`*transloco`), terjemahan terlingkup untuk modul lazy-load, dukungan SSR, dan CLI ekstraksi.                    |
+| September 2019 | `@angular/localize` | Memodernisasi i18n bawaan Angular untuk menghindari kompilasi ulang TypeScript untuk setiap bahasa.               | Tagged template literals dengan `$localize` yang disuntikkan sebagai tahap cepat pasca-build di mesin compiler Ivy.                  |
+| Februari 2021  | `@tolgee/ngx`       | Mengintegrasikan lokalisasi in-context kolaboratif dan tangkapan layar ke dalam alur kerja Angular.               | Pipe dan direktif Angular yang terhubung langsung ke Tolgee untuk penerjemahan langsung di browser.                                  |
+| April 2025     | `angular-intlayer`  | Menyediakan implementasi Intlayer berkinerja tinggi untuk Angular modern (Signals, komponen standalone, dan SSR). | Integrasi konten reaktif berbasis Signal untuk deteksi perubahan modern, injeksi dependensi standalone, dan sinkronisasi CMS visual. |
+
+</Tab>
+
+<Tab label="Svelte & SvelteKit" value="svelte">
+
+| Rilis Pertama | Pustaka           | Masalah yang Ingin Dipecahkan                                                          | Inovasi Utama                                                                                                                          |
+| ------------- | ----------------- | -------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
+| Juli 2018     | `svelte-i18n`     | Menyediakan pustaka i18n reaktif yang selaras dengan reactive store bawaan Svelte.     | Pencarian `$t` berbasis store yang memastikan pembaruan DOM secara presisi saat locale berubah.                                        |
+| Desember 2021 | `sveltekit-i18n`  | Menangani pemuatan terjemahan berbasis rute dan SSR secara rapi di aplikasi SvelteKit. | Arsitektur pemuat modular yang hanya mengambil terjemahan dan pemformat yang diperlukan untuk rute aktif.                              |
+| November 2021 | `@tolgee/svelte`  | Mengaktifkan lokalisasi in-context di aplikasi Svelte.                                 | Binding store Svelte yang terintegrasi dengan overlay terjemahan Tolgee di browser dan pembuatan screenshot otomatis.                  |
+| April 2025    | `svelte-intlayer` | Menyediakan implementasi Intlayer berkinerja tinggi untuk Svelte 5 dan SvelteKit.      | Binding konten reaktif yang disesuaikan untuk Svelte 5 Runes (`$state`), deklarasi `.content` per komponen, dan pengeditan CMS visual. |
+| Juli 2025     | `@wuchale/svelte` | Menghilangkan boilerplate deklarasi kamus dan impor fungsi `$t` di komponen Svelte.    | Preprocessor Svelte yang mem-parsing template saat build dan menyusun node teks menjadi output lokal tanpa wrapper.                    |
+
+</Tab>
+
+<Tab label="SolidJS" value="solid">
+
+| Rilis Pertama  | Pustaka                  | Masalah yang Ingin Dipecahkan                                                                    | Inovasi Utama                                                                                                              |
+| -------------- | ------------------------ | ------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------- |
+| September 2021 | `@solid-primitives/i18n` | Menyediakan primitif i18n yang sesuai dengan reaktivitas halus (fine-grained) SolidJS.           | Resolver terjemahan reaktif berbasis sinyal yang memperbarui node DOM tanpa virtual DOM atau re-render yang tidak perlu.   |
+| April 2025     | `solid-intlayer`         | Menyediakan implementasi Intlayer berkinerja tinggi yang dirancang untuk SolidJS dan SolidStart. | Binding konten sadar sinyal tanpa overhead Virtual DOM, autokompleksi skema TypeScript penuh, dan integrasi editor visual. |
+| Juni 2026      | `@lingui/solid`          | Memperluas ekstraksi makro waktu kompilasi dan dukungan ICU MessageFormat ke SolidJS.            | Transformasi makro yang disesuaikan dengan reaktivitas Solid, mengompilasi pesan menjadi struktur runtime yang ringkas.    |
+
+</Tab>
+
+</Tabs>
+
+## Empat Era Arsitektur JavaScript i18n
+
+![Sejarah Pustaka JavaScript i18n](https://github.com/aymericzip/intlayer/blob/main/docs/assets/history_i18n.png?raw=true)
+
+Melihat kembali perkembangan selama lima belas tahun, kita dapat membagi sejarah internasionalisasi JavaScript ke dalam empat era arsitektur:
+
+<AccordionGroup>
+<Accordion header="1. Era Kamus Runtime (2011 hingga 2017)">
+
+Ditandai oleh `i18next`, `react-intl`, dan `vue-i18n`. Aplikasi memuat katalog JSON statis ke memori, dan fungsi runtime mencocokkan string kunci dengan objek bersarang. Pluralisasi dan interpolasi diproses di browser melalui pencocokan regex dan parser ICU runtime.
+
+</Accordion>
+<Accordion header="2. Era Makro Waktu Kompilasi dan Type Safety (2018 hingga 2021)">
+
+Ditandai oleh `lingui`, `next-translate`, `transloco`, dan `typesafe-i18n`. Pengembang menyadari dampak buruk parsing runtime terhadap kinerja serta kelemahan kunci tanpa tipe data. Makro Babel mengekstrak pesan saat build, plugin bundler membagi kamus per halaman, dan compiler TypeScript mulai memverifikasi argumen terjemahan.
+
+</Accordion>
+<Accordion header="3. Era Server Component dan Streaming (2022 hingga 2024)">
+
+Ditandai oleh `next-intl`, `next-international`, dan adapter RSC generasi awal. Dengan hadirnya React Server Components dan Next.js App Router, fokus beralih ke rendering konten lokal di server tanpa mengirimkan kamus terjemahan atau runtime i18n client ke browser.
+
+</Accordion>
+<Accordion header="4. Era Kompiler Modern dan Konten Terpadu (2024 hingga 2026)">
+
+Ditandai oleh `paraglide`, `intlayer`, dan `wuchale`. Alat-alat modern memandang internasionalisasi bukan sekadar penggantian teks, melainkan sebagai arsitektur konten yang terintegrasi. Kompiler mengubah pesan langsung menjadi fungsi kode yang mendukung tree-shaking, deklarasi konten ditempatkan bersama komponen, dan editor visual, alat MCP, serta jalur otomatisasi AI terintegrasi langsung ke alur kerja pengembang. Dalam model ini, Intlayer memisahkan deklarasi konten dan pembuatan tipe otomatis dari pengiriman runtime, menyediakan implementasi berkinerja tinggi (`react-intlayer`, `next-intlayer`, `vue-intlayer`, `angular-intlayer`, `svelte-intlayer`, dan `solid-intlayer`) yang disesuaikan secara khusus untuk setiap framework.
+
+</Accordion>
+</AccordionGroup>
+
+## Kesimpulan: Menyeimbangkan DX, Performa, dan Disrupsi AI
+
+Selama lima belas tahun dan empat gelombang arsitektur, tantangan utama internasionalisasi JavaScript tetap konsisten: menyelaraskan pengalaman pengembang (DX) dan pemeliharaan kode jangka panjang sambil menyajikan kinerja optimal di sisi klien.
+
+Apa yang berawal dari variabel global dan file JSON terpusat yang sulit dikelola kini telah berkembang menjadi konten yang ditempatkan bersama komponen, keamanan tipe TypeScript otomatis, rendering server tanpa waterfall, dan tree-shaking pada waktu build.
+
+### Disrupsi AI dan Model SaaS Tradisional
+
+Katalis penting dalam beberapa tahun terakhir adalah pembuatan terjemahan AI otomatis, yang secara mendasar menantang model bisnis platform pelokalan tradisional (TMS).
+
+Secara historis, mengumpulkan konten ke dalam file JSON monolitik adalah kompromi untuk mempermudah integrasi Sistem Manajemen Terjemahan (TMS). Repositori terpusat memberi penerjemah non-teknis dan platform TMS pihak ketiga target impor dan ekspor yang mudah. Namun, kemudahan bagi layanan eksternal ini menimbulkan biaya arsitektur yang tinggi bagi pengembang: konflik git merge yang sering terjadi pada feature branch, kunci terabaikan yang sulit dilacak, kurangnya konteks tingkat komponen, dan namespace global yang rumit.
+
+Dengan hadirnya AI generatif dan perkakas kompilasi modern, Pengalaman Pengembang (DX) kini menjadi prioritas utama. Build tools dan CLI kini dapat menemukan, memvalidasi, dan menerjemahkan file konten per komponen secara otomatis, meniadakan kebutuhan untuk mengorbankan arsitektur yang bersih demi alur kerja penerjemahan.
+
+Selama lebih dari satu dekade, platform komersial membangun pendapatan berulang di sekitar friksi TMS manual tersebut:
+
+- Solusi seperti **Locize** (platform SaaS komersial di balik `i18next`) dan **Crowdin** (sponsor utama dan mitra integrasi untuk `vue-i18n`, `next-intl`, `use-intl`, dan `lingui`) memusatkan model bisnis mereka pada penyimpanan terjemahan berbayar, batasan paket bertingkat, dan biaya per kata.
+- Karena platform lawas ini memonetisasi volume dan proses kerja manual, mereka memiliki sedikit insentif ekonomi untuk mengotomatiskan pembuatan terjemahan end-to-end secara gratis langsung di rantai alat pengembang.
+
+### Gelombang AI Baru vs. Biaya Penyedia Langsung
+
+Ketika Model Bahasa Besar (LLM) modern menurunkan biaya terjemahan hingga pecahan sen sekaligus meningkatkan akurasi linguistik, generasi alat komersial baru muncul untuk memanfaatkan pasar ini:
+
+- Platform seperti Paraglide dengan **linguo.dev** atau **General Translation** (`gt-react`, `gt-next`) telah berusaha memanfaatkan tren AI dengan memperkenalkan langganan berbayar baru dan perantara cloud berbayar.
+- Sebaliknya, **Intlayer** menyediakan terjemahan AI otomatis langsung dari CLI-nya, memungkinkan tim menghubungkan kunci API mereka sendiri (seperti OpenAI, Anthropic, Mistral, atau Google Gemini). Tidak ada mark-up, komisi, atau vendor lock-in, beroperasi sepenuhnya pada biaya langsung penyedia AI pilihan Anda.
+
+### Lebih dari Sekadar i18n: Sistem Konten Multibahasa yang Lengkap
+
+Terakhir, pengembangan web modern telah melangkah jauh melampaui penggantian teks sederhana. Aplikasi saat ini tidak hanya perlu menerjemahkan kata tunggal seperti `"Submit"` atau `"Log In"`, tetapi juga membutuhkan konten terstruktur yang dinamis di seluruh alur interaksi pengguna.
+
+Intlayer memandang masalah ini bukan sebagai alat pencarian kunci string yang sempit, melainkan sebagai sistem konten multibahasa yang komprehensif. Dengan dukungan kelas satu untuk dokumen Markdown, struktur HTML, skema data bersarang, dan pengeditan visual CMS yang mulus, Intlayer menjembatani rekayasa tingkat kode, alur kerja AI otomatis, dan manajemen konten.
+
+Untuk perbandingan arsitektur lebih mendalam dan panduan migrasi praktis, jelajahi sumber daya berikut:
+
+- [Compiler vs. Declarative Internationalization](https://github.com/aymericzip/intlayer/blob/main/docs/blog/id/compiler_vs_declarative_i18n.md)
+- [Per-Component vs. Centralized i18n](https://github.com/aymericzip/intlayer/blob/main/docs/blog/id/per-component_vs_centralized_i18n.md)
+- [Kinerja dan Tolok Ukur](https://intlayer.org/doc/benchmark)
+- [Adapter Kompatibilitas Intlayer](https://intlayer.org/doc/concept/compatibility)