@intlayer/docs 9.5.1 → 9.5.3

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

@@ -0,0 +1,286 @@
+---
+createdAt: 2026-09-13
+updatedAt: 2026-09-13
+title: "vue-i18n مقابل @intlayer/vue-i18n: نفس الواجهة البرمجية، حزمة مختلفة"
+description: ما الذي يتغير عندما تحتفظ تطبيقات Vue 3 باستدعاءات vue-i18n الخاصة بها لكنها تخدمها من خلال محول التوافق @intlayer/vue-i18n. JavaScript لكل صفحة، حجم وقت التشغيل، حجم المكون والتسرب المقاس على نفس كود Vite + Vue، بالإضافة إلى ما يحتفظ به المحول وما يتجاهله وما لا يمكنه استبداله.
+keywords:
+  - vue-i18n
+  - "@intlayer/vue-i18n"
+  - Intlayer
+  - محول التوافق
+  - الهجرة
+  - الدولية
+  - i18n
+  - مقارنة الأداء
+  - حجم الحزمة
+  - مدونة
+  - Vue
+  - Nuxt
+  - Vite
+slugs:
+  - blog
+  - vue-i18n-vs-intlayer-vue-i18n
+author: aymericzip
+---
+
+# vue-i18n مقابل @intlayer/vue-i18n | نفس الواجهة البرمجية، حزمة مختلفة
+
+`@intlayer/vue-i18n` هو محول توافقي: يعرّض واجهة برمجية (API) من `vue-i18n` (`createI18n`، `useI18n`، `t()`، `d()`، `n()`، `$t`، `v-t`، `i18n.global.locale`...) ويقدمها من القواميس المترجمة بواسطة Intlayer. ملفات `.vue` الخاصة بك لا تتغير. ما يرتبط به `t("footer.github")` هو ما يتغير.
+
+تقيس هذه المقالة هذا التبديل على نفس تطبيق 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). هذا يتعلق بما يغيره المحول عندما تحتفظ بمكوناتك كما هي.
+
+<TOC/>
+
+> **ملخص سريع**: على نفس تطبيق Vite + Vue 3، استبدال `vue-i18n` بـ `@intlayer/vue-i18n` أخذ JavaScript لكل صفحة من **134.9 KB إلى 47.0 KB** gzip (التطبيق بدون i18n يزن 41.3 KB)، وقت التشغيل من **24.3 KB إلى 7.9 KB**، متوسط المكون من **196 KB إلى 8.4 KB**، وتسرب السلاسل النصية للصفحات الأجنبية من **90% إلى 0%**، بدون تعديل أي ملف `.vue`. `createI18n({ messages })` يستمر في العمل كخيار بديل؛ أزل استيراد JSON للحصول على الأرقام أعلاه. كتل SFC `<i18n>` و `setLocaleMessage()` في وقت التشغيل هما الميزتان اللتان لا تنتقلان.
+
+## ما هو `@intlayer/vue-i18n`
+
+`vue-i18n` هي runtime. `createI18n({ messages: { en, fr, ... } })` تبني instance عام يحتفظ بكل رسالة من كل locale؛ `useI18n()` تربط كل component بها؛ `t("footer.github")` تمشي عبر الشجرة في وقت rendering. هذا التصميم هو ما يجعل SFC `<i18n>` blocks و `setLocaleMessage()` ممكنة، وهو أيضاً السبب في أن dependency graph لكل component يتضمن الشجرة بأكملها.
+
+`@intlayer/vue-i18n` تحافظ على API وتستبدل الشجرة:
+
+1. **Import aliasing.** `vueI18nVitePlugin()` من `@intlayer/vue-i18n/plugin` تغلف `vite-intlayer` وتضيف `resolve.alias` بحيث أن `vue-i18n` يتم حلها إلى `@intlayer/vue-i18n`. لم يتم إعادة تسمية أي import.
+2. **JSON كمصدر الحقيقة.** يقرأ plugin `syncJSON` ملف `locales/{locale}.json` الموجود لديك باستخدام `format: "vue-i18n"` (لذلك يتم تحليل استيفاء `{name}`، `{0}` list والجمع بين الأنابيب `"car | cars"` بشكل صحيح) ويكتب الترجمات مرة أخرى عندما يحدثها CLI أو CMS.
+3. **ربط موقع الاستدعاء.** تعيد مرحلة تحسين Intlayer كتابة مواقع استدعاء `useI18n()` بحيث يحصل المكون على القواميس الخاصة به مفاتيح الأسماء، في الإعدادات المحلية النشطة، كواردات يمكن للـ bundler تتبعها وتقسيمها.
+
+```vue fileName="src/components/Footer.vue"
+<!-- الكود الخاص بك، بدون تغيير -->
+<script setup lang="ts">
+import { useI18n } from "vue-i18n";
+
+const { t } = useI18n();
+</script>
+
+<template>
+  <a href="https://github.com/intlayer-org/benchmark-bloom">{{
+    t("footer.github")
+  }}</a>
+</template>
+```
+
+```ts fileName="ما يصدره المترجم (مبسط)"
+import _dicHash_footer from "../.intlayer/dictionaries/footer.mjs";
+import { useDictionary as useI18n } from "@intlayer/vue-i18n";
+
+const { t } = useI18n(_dicHash_footer);
+```
+
+لم تعد المكون تصل إلى شجرة الرسائل العامة. تصل إلى `footer`. هذا هو السبب في انخفاض عمود حجم المكون أدناه من 196 كيلوبايت إلى 8 كيلوبايت.
+
+## ما يحافظ عليه المحول وما يتجاهله وما لا يستبدله
+
+| `vue-i18n` API                                                      | مع `@intlayer/vue-i18n`                                                                                                                    |
+| ------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
+| `useI18n()` → `{ t, d, n, te, tm, rt, locale, availableLocales }`   | ✅ تم الاحتفاظ به. مفاتيح `t` مُكتوبة ضد قاموسك                                                                                            |
+| `t("key", { name })`, `t("key", [a, b])`, `t("key", count)`         | ✅ تم الاحتفاظ به. يتم حل `{name}`، `{0}` والجمع الفاصل بينها كما هو الحال من قبل                                                          |
+| `d(date, "long")`, `n(value, "currency")`                           | ✅ تم الاحتفاظ به. يتم احترام `datetimeFormats` / `numberFormats` من `createI18n()`، مدعومة بـ `Intl` الأصلي                               |
+| `i18n.global.locale.value = "fr"`                                   | ✅ تم الحفاظ عليه. `WritableComputedRef` مدعوم بـ Intlayer الخاص بالعميل؛ التفاعلية تتصرف كما هي                                           |
+| `$t`, `$tc`, `$te`, `$tm`, `$rt`, `$d`, `$n`, `$i18n` (Options API) | ✅ تم الحفاظ عليه. تم تسجيله على `app.config.globalProperties` بواسطة `app.use(i18n)`                                                      |
+| `v-t` directive                                                     | ✅ تم الحفاظ عليه                                                                                                                          |
+| `legacy: true`                                                      | ✅ مقبول                                                                                                                                   |
+| `createI18n({ messages })`                                          | ⚠️ يتم استخدام `messages` كـ **fallback في وقت التشغيل** مع تحذير في بيئة التطوير. قم بإزالة استيرادات JSON للحصول على مكاسب في حجم الحزمة |
+| `setLocaleMessage()`, `mergeLocaleMessage()`                        | ❌ تحذير وعدم القيام بأي شيء. يتم استبدال تحميل الرسائل في وقت التشغيل بقواميس build-time                                                  |
+| كتل `<i18n>` المخصصة في SFC                                         | ❌ لا يتم قراءتها. انقل تلك الرسائل إلى JSON اللغة (أو `.content.ts` بجانب المكون)                                                         |
+| `@nuxtjs/i18n`                                                      | ⚠️ محول منفصل، انظر [وثائق توافق Nuxt](https://intlayer.org/doc/compatibility/nuxtjs-i18n)                                                 |
+
+## المعايير
+
+### ما تم قياسه
+
+تبني مجموعة [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom) **نفس تطبيق Vite + Vue 3** مع كل إعداد: **10 صفحات** (الرئيسية، حول، مدونة، الوظائف، اتصل، الأسئلة الشائعة، التسعير، المنتجات، الإعدادات، الفريق)، **10 لغات** (`en`، `fr`، `es`، `de`، `it`، `pt`، `zh`، `ja`، `ko`، `ru`)، مكونات متطابقة وأمتعة متطابقة. تُقاس الصفحات في `en` و `fr`.
+
+تم بناء كليهما في **الإعداد الثابت**، الذي تشحنه معظم مشاريع Vue: بالنسبة لـ `vue-i18n`، يتم استيراد JSON لكل لغة وتمريره إلى `createI18n({ messages })`؛ بالنسبة للمحول، نفس المكونات مع تغيير `vite.config.ts` و `intlayer.config.ts` وإزالة استيراد `messages`. يتم تضمين `vue-intlayer` الأصلي للمرجع.
+
+لكل بناء، تسجل المجموعة:
+
+- **حجم المكتبة**: حجم gzip (والمصغر) لمكون فارغ يستورد فقط مكتبة i18n.
+- **صفحة JS**: JavaScript بصيغة gzip يتم تنزيله لكل صفحة، بمتوسط على جميع الصفحات والإعدادات المحلية.
+- **تسرب الإعدادات المحلية %**: حصة السلاسل المترجمة في JavaScript المُنزَّل التي تنتمي إلى إعداد محلي لا يعرضه المستخدم.
+- **تسرب الصفحة %**: حصة السلاسل المترجمة في JavaScript المُنزَّل التي تنتمي إلى صفحة لا يوجد عليها المستخدم.
+- **متوسط المكون**: متوسط حجم gzip لكل مكون تم تجميعه بشكل منفصل.
+- **تفاعلية E2E**: وقت الساعة الحائط بين تحديد إعداد محلي جديد وتحديث `html[lang]` في DOM (Playwright، 5 تكرارات).
+- **تحميل الصفحة**: `PerformanceNavigationTiming.duration`.
+
+> الأرقام أدناه تأتي من التشغيل بتاريخ **2026-09-12** مع `vue-i18n` 11.4.0 و `@intlayer/vue-i18n` 9.5.1. تطبيق الاختبار صغير عن قصد (عدة عشرات من السلاسل النصية لكل locale)، لذا فإن نسب تسرب الـ locale تصف **نمطًا**: فهي تزداد مع محتواك بينما تبقى تكلفة التشغيل ثابتة.
+
+### النتائج على Vite + Vue 3
+
+| الإعداد                  | الإستراتيجية | حجم المكتبة (gz) | حجم المكتبة (min) | متوسط صفحة JS (gz) | تسرب Locale | تسرب الصفحة | متوسط المكون (gz) | استجابة E2E | تحميل الصفحة |
+| ------------------------ | ------------ | ---------------: | ----------------: | -----------------: | ----------: | ----------: | ----------------: | ----------: | -----------: |
+| **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 |
+
+> عمود تسرب الصفحة في تطبيق الأساس مترك فارغاً: بدون مكتبة i18n، يلتقط بصمة الأصابع السلاسل المشفرة في الأجزاء المشتركة والرقم ليس ذا معنى.
+
+**كيفية قراءته**
+
+- **88 KB أقل لكل صفحة، نفس المكونات.** يأخذ `vue-i18n` تطبيق 41.3 KB إلى **134.9 KB**. يصل بناء المحول للمكونات نفسها إلى **47.0 KB**، 5.7 KB فوق تطبيق الأساس. معظم الفرق هو 74.9 KB من `src/locales` التي يسحبها `createI18n({ messages })` إلى كل صفحة والمحول لا يجمعها أبداً كتكتل.
+- **Runtime ينكمش 3 مرات.** مكون فارغ يستورد فقط `vue-i18n` يكلف **24.3 KB gzip / 83.2 KB minified**: `@intlify/core-base`، مترجم الرسائل والـ runtime. المحول يكلف **7.9 KB / 23.2 KB**، معظمها نواة Intlayer بالإضافة إلى سطح API `vue-i18n`.
+- **المكونات: أصغر 23 مرة.** مكون `useI18n()` مترجم بشكل معزول يبلغ متوسطه **196 KB**، لأن `t` مرتبط بالمثيل الذي يحتفظ بكل رسالة من كل locale. مع المحول، نفس المكون يبلغ متوسطه **8.4 KB**: فهو يصل إلى قاموسه الخاص.
+- **تسرب البيانات.** يشحن `vue-i18n` كل locale وسلاسل كل صفحة على كل صفحة: تسرب locale بنسبة 50% (على locale المرقمة الاثنين؛ مع عشرة locales مجمعة فإن الهدر الفعلي أعلى)، تسرب صفحة بنسبة 90%. يقلل المحول تسرب الصفحة إلى **0%** لأن كل مكون يستورد فقط قاموسه الخاص. يجلس تسرب Locale عند 15% في هذا التشغيل `static`؛ `importMode: 'dynamic'` هو الإعداد الذي يزيله، وكان هذا التكوين ليس جزءاً من تشغيل Vue هذا.
+- **التفاعلية وتحميل الصفحة.** تبديل Locale رخيص لكليهما (1.5-2.8 ms)؛ نظام التفاعلية في Vue يجعل الأمر كذلك بمجرد أن تكون الرسائل في الذاكرة. يذهب تحميل الصفحة من 13.6 ms إلى **9.3 ms**، متماشياً مع 88 KB أقل من JavaScript للتحليل.
+- **حول الصفوف الأصلية.** `vue-intlayer` في هذا التشغيل جمعت كل اللغة في وضع `static` وحققت 57.1 كيلوبايت مع وقت تشغيل 3.9 كيلوبايت؛ قاموس المحول المتزامن حمل سلاسل لغات أجنبية أقل، وبالتالي الرقم الأقل لكل صفحة. وقت التشغيل الأصلي يبقى الأخف من بين الثلاثة، وموديل `.content.ts` الخاص به هو حيث تجد كتل SFC `<i18n>` معادلتها.
+
+## لماذا تتحرك الأرقام
+
+لم يتغير شيء في `src/components/`، لذا الفوائد تأتي من ما ترتبط به `useI18n`.
+
+**مع `vue-i18n`**, الربط هو المثيل العام. `createI18n({ messages: { en, fr, ... } })` هو استيراد واحد يحتوي على كل شيء؛ كل مكون يستدعي `useI18n()` يمكنه الوصول إلى كل شيء، لذلك لا يمكن للـ bundler أن ينقسم دون المثيل. التحسين يعني _أنت_ تقسم `en.json` حسب المسار، تستدعي `setLocaleMessage()` في حارس التوجيه، وتحافظ على خريطة المسار إلى الملف صحيحة عند تحرك المكونات.
+
+```bash
+.
+├── locales
+│   ├── en.json                    # سلاسل كل صفحة
+│   └── fr.json
+└── src
+    ├── i18n.ts                    # createI18n({ messages: { en, fr, ... } })
+    ├── main.ts                    # app.use(i18n)
+    └── components
+        └── Footer.vue             # useI18n(); t("footer.github")
+```
+
+**مع `@intlayer/vue-i18n`**، الربط هو القاموس. `syncJSON` يحول كل مفتاح من المستوى الأعلى في `en.json` إلى قاموس؛ تمرير التحسين يسلم المكون الذي يسمي مفاتيحه، حيث يتتبع bundler الواردات ويقسمها حسب الصفحة.
+
+```bash
+.
+├── intlayer.config.ts             # syncJSON({ format: "vue-i18n", source: ... })
+├── locales
+│   ├── en.json                    # لم يتغير، لا يزال مصدر الحقيقة
+│   └── fr.json
+├── .intlayer/                     # تم إنشاؤه: قاموس واحد لكل مفتاح من المستوى الأعلى، لكل locale
+└── src
+    ├── i18n.ts                    # createI18n({})   ← تم إزالة استيراد messages
+    ├── main.ts                    # app.use(i18n)    ← لم يتغير
+    └── components
+        └── Footer.vue             # useI18n(); t("footer.github")  ← لم يتغير
+```
+
+سطر `messages` المستورد في `i18n.ts` هو السطر الوحيد الذي يجب حذفه. هذا هو 88 كيلوبايت.
+
+## الهجرة في ثلاث خطوات
+
+<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 ويوفر الأنواع.
+
+</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؛ "dynamic" تحميل النشط عند الطلب
+    importMode: "dynamic",
+    format: "vue-i18n",
+  },
+  plugins: [
+    syncJSON({
+      // لهجة vue-i18n: {name}, {0}, "car | cars"
+      format: "vue-i18n",
+      source: ({ locale }) => `./locales/${locale}.json`,
+      location: "locales",
+    }),
+  ],
+};
+
+export default config;
+```
+
+يبقى `locales/{locale}.json` في مكانه. كل مفتاح على المستوى الأعلى (`footer`, `hero`...) يصبح قاموس.
+<Step number={3} title="أضف الـ plugin وحذف استيراد الرسائل">
+
+```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` (مراقبة المحتوى، تجميع القاموس، عملية التحسين) ويقوم بإنشاء alias لـ `vue-i18n` إلى الـ adapter. إزالة استيراد `messages` هو ما يقلل 88 KB؛ تركه في الكود يبقي التطبيق يعمل لكنه يشحن الاثنين معاً.
+
+</Step>
+</Steps>
+
+### ما يمكنك حذفه لاحقًا
+
+| الملف / النمط                                          | السبب                                                                 |
+| ------------------------------------------------------ | --------------------------------------------------------------------- |
+| `import en from "./locales/en.json"` والملفات المشابهة | يُستخدم فقط كآلية احتياطية من قِبل adapter. هنا كان موقع 88 كيلوبايت  |
+| `setLocaleMessage()` في route guards                   | عملية بلا تأثير. تحميل لكل مسار هو وظيفة المترجم الآن                 |
+| `@intlify/unplugin-vue-i18n`                           | غير مطلوب: فهو يقوم بتجميع الرسائل وكتل SFC التي لا يقرأها adapter    |
+| كتل `<i18n>` في المكونات أحادية الملف (SFC)            | لا تُقرأ؛ انقلها إلى ملفات JSON المحلية أو إلى `.content.ts` لكل مكون |
+
+### ما الذي تكسبه بعيداً عن البايتات
+
+- **مفاتيح مكتوبة.** `t("footer.github")` مكتوب مقابل قاموس `footer` المترجم؛ المسار الخاطئ هو خطأ في TypeScript بدلاً من عرض المفتاح كنص.
+- **`npx intlayer test`** يفشل في CI عند وجود مفتاح مفقود في أي محلية. **`npx intlayer fill`** يترجم الناقصة باستخدام مفتاح مزود خاص بك (OpenAI أو Anthropic أو Mistral أو Gemini...) ويكتبها مرة أخرى في `locales/{locale}.json`.
+- **محرر مرئي و CMS** يعملان على نفس JSON، لذا يقوم المطورون بعدم التحرير من خلال واجهة المستخدم وتحديث الملفات.
+- **الانتقال التدريجي إلى `.content.ts`.** يمكن لأي مكون الانتقال من `useI18n()` إلى `useIntlayer("footer")` مع ملف محتوى مرافق. قواميس JSON و`.content.ts` موجودة وتندمج معاً.
+
+## الحدود التي يجب معرفتها قبل البدء
+
+- **كتل SFC `<i18n>` لا تُقرأ.** إذا كانت رسائلك موجودة داخل المكونات، فيجب نقلها إلى ملفات الإعدادات الإقليمية (أو إلى `.content.ts`، وهي نفس الفكرة مع الأنواع).
+- **تحميل الرسائل في وقت التشغيل قد اختفى.** `setLocaleMessage()` و `mergeLocaleMessage()` تحذر وتعود. الترجمات المجلوبة من نظام إدارة المحتوى في وقت التشغيل تحتاج إلى نظام إدارة محتوى Intlayer، أو أوامر `intlayer pull` / `push`.
+- **`messages` هو بديل، وليس مجاني.** الاحتفاظ باستيرادات JSON في `createI18n()` يحتفظ بـ 75 KB في الحزمة. احذفها بمجرد نجاح `intlayer test`.
+- **المحول ليس runtime الأصلي.** 7.9 KB مقابل 3.9 KB لـ `vue-intlayer`. بمجرد انتقال كل component إلى `useIntlayer`، يمكنك حذفه.
+
+## متى تستخدم أي منها؟
+
+- **ابق على `vue-i18n`** إذا كان تطبيقك يعتمد على كتل SFC `<i18n>`، على تدفقات runtime `setLocaleMessage()`، أو إذا لم يكن 90 KB لكل صفحة مصدر قلق لجمهورك.
+- **استخدم `@intlayer/vue-i18n`** إذا كنت على `vue-i18n` وتريد توفير 88 KB، و23x أصغر components، 0% page leakage، typed keys وفحوصات CI دون تعديل ملف `.vue`. هذه هي نقطة الدخول لـ codebase `vue-i18n` موجود.
+- **اذهب للنسخة الأصلية (`vue-intlayer`)** للمشاريع الجديدة، أو بمجرد انتهاء المحول من عمله. لديها أخف runtime (3.9 KB) والنموذج `.content.ts` لكل component الذي يحل محل كتل `<i18n>` بمحتوى مكتوب (typed).
+
+## المقارنات ذات الصلة
+
+- [vue-i18n مقابل Intlayer](https://intlayer.org/blog/vue-i18n-vs-intlayer) (الميزات وتجربة المطور)
+- [معيار vue-i18n مقابل Intlayer](https://intlayer.org/blog/vue-i18n-vs-intlayer-benchmark) (المكتبات، نفس المعيار)
+- [next-intl مقابل @intlayer/next-intl](https://intlayer.org/blog/next-intl-vs-intlayer-next-intl) (نفس سلسلة المحولات)
+- [i18next مقابل @intlayer/i18next](https://intlayer.org/blog/i18next-vs-intlayer-i18next) (نفس سلسلة المحولات)
+- [Lingui مقابل @intlayer/lingui](https://intlayer.org/blog/lingui-vs-intlayer-lingui) (نفس سلسلة المحولات)
+- [دليل الترحيل: من vue-i18n إلى Intlayer](https://intlayer.org/doc/migration/vue-i18n)
+- [مرجع محول التوافق: vue-i18n](https://intlayer.org/doc/compatibility/vue-i18n), [Nuxt i18n](https://intlayer.org/doc/compatibility/nuxtjs-i18n)
+
+## الخلاصة
+
+يغير `@intlayer/vue-i18n` ما يرتبط به `useI18n()`: من مثيل عام يحمل كل رسالة من كل locale إلى قاموس مُجمّع لتلك المكون. في نفس تطبيق Vite + Vue 3 الذي هو **88 KB أقل لكل صفحة**، وقت تشغيل **أصغر 3 مرات**، مكونات **أصغر 23 مرة** و**تسرب صفحة 0%**، لملف إعدادات وسطر plugin وواحد استيراد محذوف. كتل SFC `<i18n>` وتحميل الرسائل في وقت التشغيل هما الشيئان اللذان لا يحملهما، وبقي runtime `vue-intlayer` الأصلي نصف حجمه.
+
+جميع البيانات الأولية وتطبيقات الاختبار والسكريبتات موجودة في [مستودع Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom). قم بتشغيلها بنفسك.
+
+راجع وثيقة ['Why Intlayer?'](https://intlayer.org/doc/why) للحصول على مزيد من التفاصيل.

package/blog/de/history_of_i18n.md

@@ -0,0 +1,304 @@
+---
+createdAt: 2026-09-09
+updatedAt: 2026-09-09
+title: "Die Geschichte der JavaScript-i18n: Von 2011 bis 2026"
+description: "Erfahren Sie mehr über die Evolution der Frontend-Internationalisierung von 2011 bis 2026. Release-Daten, Architekturprobleme und Innovationen in React, Vue, Next.js, Angular, Svelte und Solid."
+keywords:
+  - i18n Geschichte
+  - JavaScript Internationalisierung
+  - React i18n
+  - Next.js i18n
+  - Vue i18n
+  - Angular i18n
+  - Svelte i18n
+  - Solid i18n
+  - i18next
+  - intlayer
+slugs:
+  - blog
+  - history-of-js-internationalization
+author: aymericzip
+---
+
+# Die Geschichte der JavaScript-Internationalisierung (i18n)
+
+Internationalisierung ist kein neues Thema. Lange vor JavaScript und dem modernen Web mussten Softwaresysteme bereits mit mehreren Sprachen, Währungen, Datumsformaten und regionalen Konventionen umgehen. Frühe grafische Betriebssysteme wie GEM und Mac OS lösten viele dieser Probleme bereits in den 1980er Jahren.
+
+Dieselben Konzepte fanden ihren Weg in Backend-Frameworks. Ruby on Rails, Django, Java-Frameworks und PHP-Anwendungen entwickelten jeweils eigene Ansätze zur Internationalisierung. Die Kernfragen waren klar umrissen:
+
+- Wo sollen Übersetzungen gespeichert werden?
+- Wie formatieren wir Datumsangaben, Zahlen und Währungen?
+- Wie handhaben wir Pluralformen und grammatikalische Unterschiede?
+- Wie bestimmen wir die passende Sprache für den Nutzer?
+
+Solange der Server vollständige HTML-Seiten erzeugte, war das Vorgehen überschaubar. Die Anwendung lud die passenden Texte, renderte das Dokument und lieferte es an den Browser aus.
+
+> PHP und GNU gettext dienten als Wegbereiter für das `t()`-Helfer-Muster, das später in JavaScript und JSX allgegenwärtig wurde.
+
+Dann übernahm JavaScript zunehmend die Kontrolle im Browser.
+
+Mit dem Wechsel von rein serverseitigen Seiten zu komplexen Single-Page Applications (SPAs) verlagerte sich die Internationalisierung ins Frontend. Der Browser musste plötzlich Übersetzungen nachladen, Sprachen dynamisch umschalten, Werte formatieren, Pluralregeln anwenden und die Oberfläche ohne Seiten-Reload aktualisieren.
+
+Daraus ergab sich eine zentrale Frage:
+
+**Wie lässt sich eine Anwendung mehrsprachig gestalten, ohne jedem Nutzer gigantische Übersetzungsmengen und schweren Laufzeitcode aufzubürden?**
+
+Diese Frage prägte die Entwicklung von JavaScript-i18n über mehr als ein Jahrzehnt.
+
+Die Lösungen haben sich grundlegend gewandelt: von globalen JavaScript-Objekten und einfachen `t('key')`-Aufrufen über frameworkspezifische Bibliotheken, Typensicherheit mit TypeScript, Server Components und Tree-Shaking bis hin zu modernen Compiler-Ansätzen, die Übersetzungen direkt während des Builds in optimierten Code überführen.
+
+Dieser Artikel beleuchtet diese Entwicklung von 2011 bis 2026: welche Probleme die einzelnen Werkzeuge lösen wollten, was funktionierte, wo Grenzen lagen und wie moderne Frontend-Architekturen die i18n von heute bestimmen.
+
+![JavaScript Internationalisierungs-Ökosystem](https://github.com/aymericzip/intlayer/blob/main/docs/assets/cloud_i18n_logo.png?raw=true)
+
+## Inhaltsverzeichnis
+
+<TOC/>
+
+## Das frühe Web: JavaScript-Internationalisierung vor 2016
+
+Um moderne i18n-Lösungen einordnen zu können, lohnt ein Blick auf die Arbeitsweisen zwischen 2011 und 2015.
+
+### Verlagerung der Logik auf den Client
+
+Anfang der 2010er Jahre lag die Internationalisierung fast ausschließlich beim Server. JavaScript diente meist nur als Ergänzung für Animationen, Formularprüfungen und kleinere DOM-Elemente via jQuery.
+
+Als SPAs mit Backbone.js, Knockout.js und frühem AngularJS populär wurden, wanderte die Rendering-Logik direkt in den Browser. Der Client musste nun lokalisierte Datumsangaben darstellen, Währungen anpassen, Pluralregeln berechnen und Texte ohne Neuladen austauschen.
+
+Doch der Browser von 2011 bot dafür kaum native Unterstützung:
+
+<AccordionGroup>
+<Accordion header="Keine native Internationalisierungs-API">
+
+Die Spezifikation der ECMAScript Internationalization API (ECMA-402) wurde erst im Dezember 2012 mit dem globalen Objekt `Intl` verabschiedet. Vor der breiten Einführung in Browsern erforderten selbst einfache Formatierungen eigene Hilfsfunktionen oder schwere Polyfills.
+
+</Accordion>
+<Accordion header="Keine modernen Modul-Bundler">
+
+Werkzeuge wie Webpack standen am Anfang, und native ES-Module existierten in Browsern nicht. Entwickler banden Skripte über `<script>`-Tags ein und legten Übersetzungen oft in globalen Objekten wie `window.translations = { ... }` ab.
+
+</Accordion>
+<Accordion header="Monolithische JSON-Dateien">
+
+Übersetzungen wurden in riesigen, zentralen JSON-Dateien gepflegt. Ein Nutzer in Tokio, der lediglich die Startseite aufrief, lud gleichzeitig die Texte für Kontoeinstellungen, Abrechnungsdialoge und Administrationsbereiche herunter.
+
+</Accordion>
+</AccordionGroup>
+
+### Die erste Welle clientseitiger Bibliotheken
+
+Zwischen 2012 und 2015 entstand das Fundament moderner i18n in JavaScript:
+
+<AccordionGroup>
+<Accordion header="i18next (Januar 2012)">
+
+Entwickelt von Jan Mühlemann, definierte `i18next` den Standard für Schlüssel-Wert-Wörterbücher zur Laufzeit. Es führte Pfadnavigation, Variableninterpolation, Pluralregeln und eine modulare Architektur für Sprachdetektoren und Backends ein. Es etablierte sich rasch als De-facto-Standard in Vanilla JS und Node.js.
+
+</Accordion>
+<Accordion header="vue-i18n (Mai 2014)">
+
+Entwickelt von Kazuya Kawaguchi (Kazupon), passte `vue-i18n` die Internationalisierung an das Reaktivitätsmodell von Vue.js an und führte Vorlagendirektiven (`v-t`) sowie den Helfer `$t()` ein.
+
+</Accordion>
+<Accordion header="react-intl (Juni 2014)">
+
+Als Teil des FormatJS-Projekts von Yahoo! brachte `react-intl` standardisierte ICU MessageFormat- und `Intl`-APIs über deklarative Komponenten wie `<FormattedMessage>` und `<FormattedDate>` in das React-Ökosystem.
+
+</Accordion>
+<Accordion header="react-i18next (Dezember 2015)">
+
+Jan Mühlemann übertrug `i18next` in die React-Welt, zunächst mit Higher-Order Components (`withTranslation`) und Kontextanbietern, um Komponenten bei Sprachwechseln neu zu rendern.
+
+</Accordion>
+</AccordionGroup>
+
+### Grenzen der Ära vor 2016
+
+Obwohl diese Werkzeuge mehrsprachige Webanwendungen ermöglichten, brachten die damaligen Architekturen spürbare Nachteile mit sich:
+
+<AccordionGroup>
+<Accordion header="Fragile String-Schlüssel">
+
+Schlüsselaufrufe wie `t('marketing.landing.hero.cta')` boten keinerlei statische Typprüfung. Tippfehler fielen oft erst im Produktivbetrieb durch leere Flächen oder unübersetzte Schlüssel auf.
+
+</Accordion>
+<Accordion header="Parsing-Aufwand zur Laufzeit">
+
+Das Auswerten von ICU-Nachrichtensyntax und regulären Ausdrücken im Browser beanspruchte insbesondere auf Mobilgeräten messbare Rechenleistung.
+
+</Accordion>
+<Accordion header="Unnötig große Bundles">
+
+Ohne komponentenbasiertes oder routenbasiertes Code-Splitting wurden sämtliche Übersetzungstexte auf einmal ausgeliefert, was die Ladezeiten verlängerte.
+
+</Accordion>
+<Accordion header="Kluft zwischen Code und Übersetzung">
+
+Zentralisierte JSON-Dateien lagen weit entfernt von den Komponenten, die sie verwendeten. Verwaiste Schlüssel und fehlende Übersetzungen waren die häufige Folge.
+
+</Accordion>
+</AccordionGroup>
+
+## Die Framework-Ära: Entwicklung über Ökosysteme hinweg
+
+Zwischen 2016 und 2026 wandelte sich die Frontend-Entwicklung grundlegend. TypeScript wurde zum Branchenstandard, Komponentenmodelle reiften aus, Bundler wie Webpack, Vite und Turbopack etablierten granulares Code-Splitting, React Server Components verlagerten Render-Logik zurück auf den Server, und Compiler begannen, Anwendungscode direkt zu analysieren.
+
+Die folgenden Tabs zeigen, wie die einzelnen Ökosysteme auf diese Herausforderungen reagierten. In diesen Umgebungen bieten `react-intlayer` und seine Pendants (`next-intlayer`, `vue-intlayer`, `angular-intlayer`, `svelte-intlayer` und `solid-intlayer`) leistungsfähige Implementierungen, die auf die jeweilige Laufzeitumgebung zugeschnitten sind.
+
+<Tabs>
+
+<Tab label="Core JavaScript" value="javascript">
+
+| Erster Release | Bibliothek                           | Zielsetzung                                                                                                                                                    | Wichtigste Innovation                                                                                                                                                  |
+| -------------- | ------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Januar 2012    | `i18next`                            | Standardisierung von Dictionary-Lookups zur Laufzeit für Browser und Node.js ohne Framework-Bindung.                                                           | Modulare Laufzeitarchitektur mit Trennung von Übersetzungslogik, Ladern, Detektoren und Caching.                                                                       |
+| Februar 2021   | `typesafe-i18n`                      | Vermeidung von Laufzeitfehlern und fehlerhaften Interpolationen durch ungetypte Zeichenketten.                                                                 | Vollständig typisierte Übersetzungsfunktionen, die direkt aus Übersetzungsobjekten generiert werden, ohne Laufzeitabhängigkeiten.                                      |
+| Oktober 2023   | `paraglide` (`@inlang/paraglide-js`) | Beseitigung von Laufzeit-Dictionaries, schweren Parsern und unnötigem Bundle-Overhead.                                                                         | Kompiliert Meldungen in reine, tree-shakable ECMAScript-Module und JavaScript-Funktionen.                                                                              |
+| April 2024     | `intlayer`                           | Ersatz schwer wartbarer Namespaces, Vermeidung von Content-Leaks zwischen Seiten, Reduzierung von Git-Merge-Konflikten und native Typsicherheit in TypeScript. | Colocation von `.content`-Dateien direkt am Komponentenaufruf, automatische Typgenerierung, integriertes visuelles CMS und KI-gestützte Übersetzungswerkzeuge per CLI. |
+| Juni 2025      | `wuchale`                            | Beseitigung des manuellen Extrahierens von Texten und Erfindens von Übersetzungsschlüsseln während der Entwicklung.                                            | AST-Vorverarbeitung, die Inline-Texte erkennt und direkt zur Build-Zeit in lokalisierte Funktionen ohne Wrapper überführt.                                             |
+
+</Tab>
+
+<Tab label="React" value="react">
+
+| Erster Release | Bibliothek       | Zielsetzung                                                                                                                                    | Wichtigste Innovation                                                                                                                                     |
+| -------------- | ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Juni 2014      | `react-intl`     | Standardisierung der Formatierung von Zahlen, Daten, Währungen und komplexen Pluralen in React.                                                | Deklarative Komponenten (`<FormattedMessage>`, `<FormattedDate>`) auf Basis von ICU MessageFormat und ECMA-402.                                           |
+| Dezember 2015  | `react-i18next`  | Idiomatische React-Anbindung für `i18next` mit reaktivem Re-Rendering.                                                                         | Kontinuierliche Weiterentwicklung von Higher-Order Components hin zu JSX-Interpolation mit `<Trans>` und dem `useTranslation`-Hook.                       |
+| Januar 2018    | `@lingui/react`  | Verringerung von Bundle-Größen durch Vermeidung schwerer ICU-Parser zur Laufzeit.                                                              | Babel/SWC-Makros zur Build-Zeit, die `<Trans>` und `t` in kompakte indizierte Arrays kompilieren.                                                         |
+| Dezember 2020  | `use-intl`       | Schlanke, hook-basierte und typsichere Alternative zu älteren React-i18n-Lösungen.                                                             | Ergonomische Hooks `useTranslations` und `useFormatter` mit tiefer TypeScript-Integration.                                                                |
+| Februar 2021   | `@tolgee/react`  | Verkürzung von Feedbackschleifen zwischen Entwicklern, Übersetzern und Designern.                                                              | In-Context-Bearbeitung im Browser per Alt-Klick mit Echtzeit-Aktualisierung und Screenshot-Erfassung.                                                     |
+| April 2024     | `react-intlayer` | Optimierte React-Implementierung von Intlayer für den Komponenten-Lebenszyklus ohne zentrale JSON-Monolithen oder unübersichtliche Namespaces. | Leistungsfähiger `useIntlayer`-Hook, automatisch generierte TypeScript-Typen, Tree-Shaking pro Komponente und Live-Synchronisation mit dem visuellen CMS. |
+| Juli 2024      | `gt-react`       | Automatisierung manueller Datei-Exporte und Übersetzungsabläufe.                                                                               | Cloud-basierte KI-Lokalisierung direkt in React-Komponenten über automatisierte Übersetzungspipelines.                                                    |
+| August 2025    | `@wuchale/jsx`   | Verzicht auf manuelle Schlüsselvergabe und sich wiederholende Hooks in JSX.                                                                    | AST-Transformation, die JSX-Textknoten automatisch erkennt und in lokalisierte Äquivalente kompiliert.                                                    |
+
+</Tab>
+
+<Tab label="Next.js" value="nextjs">
+
+| Erster Release | Bibliothek                                  | Zielsetzung                                                                                               | Wichtigste Innovation                                                                                                                                             |
+| -------------- | ------------------------------------------- | --------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| November 2018  | `next-i18next`                              | SSR- und SSG-Unterstützung mit `i18next` im Next.js Pages Router ohne clientseitige Abfragekaskaden.      | `serverSideTranslations` und `appWithTranslation` zur Übergabe lokalisierter Namespaces über Page-Props.                                                          |
+| Dezember 2019  | `next-translate`                            | Einfachere Konfiguration und reduziertes Bundle-Gewicht im Pages Router.                                  | Webpack-Loader-Plugin, das gezielt nur die jeweils benötigten Übersetzungs-Namespaces pro Seite einbindet.                                                        |
+| November 2020  | `next-intl`                                 | Neuausrichtung der Internationalisierung auf App Router, React Server Components (RSC) und Streaming SSR. | Native Integration mit Next.js App Router Middleware, Server Actions und asynchronen Server Components ohne zwingendes Client-JS.                                 |
+| Juli 2022      | `next-international`                        | Maximale TypeScript-Typsicherheit bei minimalem Bundle-Overhead für Next.js.                              | Strikte Typgenerierung für abgegrenzte Übersetzungsschlüssel mit schlanken Adaptern für App Router und Pages Router.                                              |
+| April 2024     | `paraglide-next` (`@inlang/paraglide-next`) | Vorkompilierte Meldungen ohne Laufzeit-Bibliothek für Next.js App Router und Pages Router.                | Middleware-Routing kombiniert mit tree-shakable Funktionen, wodurch Laufzeit-JSON-Parsing in RSC und Client-Bundles entfällt.                                     |
+| April 2024     | `next-intlayer`                             | Server-Component-Adapter ohne lästiges Weiterreichen von `t()`-Funktionen oder Wörterbüchern über Props.  | Direkter Aufruf von `useIntlayer` in synchronen Server Components ohne Prop-Drilling, kaskadenfreies Server-Rendering, lokalisierte Middleware und Live-CMS-Sync. |
+| September 2024 | `gt-next`                                   | Automatisierte mehrsprachige Inhaltserstellung und dynamisches lokales Routing in Next.js mit KI.         | App-Router-Integration, die cloudbasierte maschinelle Übersetzung mit Next.js Edge Middleware und Caching verknüpft.                                              |
+
+</Tab>
+
+<Tab label="Vue & Nuxt" value="vue">
+
+| Erster Release | Bibliothek     | Zielsetzung                                                                                                          | Wichtigste Innovation                                                                                                                                            |
+| -------------- | -------------- | -------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Mai 2014       | `vue-i18n`     | Idiomatische, reaktive Internationalisierung für Vue-Anwendungen.                                                    | Tiefe Reaktivitätsanbindung, Vorlagendirektiven (`v-t`), `$t`-Helfer und eigene `<i18n>`-Blöcke in Single-File-Components.                                       |
+| November 2017  | `@nuxt/i18n`   | Lokalisierte URL-Routen, SEO-hreflang-Tags und SSR-Hydration in Nuxt.                                                | Full-Stack-Routingmodul mit Unterstützung für Routenpräfixe, Domains, SEO-Meta-Header und Lazy-Loading von Sprachfragmenten.                                     |
+| August 2019    | `fluent-vue`   | Unterstützung komplexer grammatikalischer Fälle, Geschlechter und asymmetrischer Sprachstrukturen.                   | Integration der Mozilla Project Fluent Syntax in Vue, um verschachtelte Verzweigungen für sprachliche Feinheiten zu vermeiden.                                   |
+| April 2025     | `vue-intlayer` | Maßgeschneiderte Intlayer-Lösung für Vue 3 Composition API und Nuxt ohne Verschmutzung globaler Gültigkeitsbereiche. | Auf Vue 3 abgestimmtes `useIntlayer`-Composable mit Reaktivitäts-Tracking, klarer Komponenten-Isolation, vollständiger TypeScript-Autovervollständigung und CMS. |
+
+</Tab>
+
+<Tab label="Angular" value="angular">
+
+| Erster Release | Bibliothek          | Zielsetzung                                                                                                 | Wichtigste Innovation                                                                                                                                    |
+| -------------- | ------------------- | ----------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Februar 2017   | `ngx-translate`     | Dynamische Laufzeitübersetzung in Angular ohne separate Builds pro Sprache.                                 | `TranslateService` und `translate`-Pipe für dynamisches Nachladen von Texten und Umschalten zur Laufzeit.                                                |
+| Juli 2019      | `@ngneat/transloco` | Beseitigung von Performanceengpässen und fehlender Isolation in älteren Angular-Bibliotheken.               | Strukturelle Direktive (`*transloco`), isolierte Übersetzungen für Lazy-Loading-Module, SSR-Unterstützung und Extraktions-CLI.                           |
+| September 2019 | `@angular/localize` | Modernisierung der internen Angular-i18n zur Vermeidung wiederholter TypeScript-Kompilierungen pro Sprache. | Tagged Template Literals mit `$localize`, die in einem schnellen Post-Build-Schritt im Ivy-Compiler verarbeitet werden.                                  |
+| Februar 2021   | `@tolgee/ngx`       | Integration kollaborativer In-Context-Übersetzung und Screenshot-Erstellung in Angular-Workflows.           | Angular-Pipes und -Direktiven mit direkter Anbindung an Tolgee für In-Browser-Übersetzung.                                                               |
+| April 2025     | `angular-intlayer`  | Native Intlayer-Implementierung für modernes Angular (Signals, Standalone Components und SSR).              | Signal-basierte reaktive Inhaltsanbindung abgestimmt auf Angular Change Detection, Standalone Dependency Injection und Live-Synchronisation mit dem CMS. |
+
+</Tab>
+
+<Tab label="Svelte & SvelteKit" value="svelte">
+
+| Erster Release | Bibliothek        | Zielsetzung                                                                                      | Wichtigste Innovation                                                                                                                          |
+| -------------- | ----------------- | ------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------- |
+| Juli 2018      | `svelte-i18n`     | Reaktive Internationalisierungsbibliothek abgestimmt auf Svelte Stores.                          | Store-basierter `$t`-Zugriff für präzise DOM-Updates bei Sprachwechseln.                                                                       |
+| Dezember 2021  | `sveltekit-i18n`  | Saubere Handhabung von SSR und routenbasiertem Nachladen in SvelteKit-Anwendungen.               | Modulare Lade-Architektur, die exakt jene Übersetzungen und Formatierer abruft, die für die aktuelle Route nötig sind.                         |
+| November 2021  | `@tolgee/svelte`  | In-Context-Lokalisierung für Svelte-Anwendungen.                                                 | Svelte-Store-Anbindungen mit Integration in das Tolgee In-Context-Overlay und automatisierter Screenshot-Erstellung.                           |
+| April 2025     | `svelte-intlayer` | Performante Intlayer-Implementierung speziell für Svelte 5 und SvelteKit.                        | Reaktive Bindings für Svelte 5 Runes (`$state`), komponentennahe `.content`-Deklarationen, konfigurationslose Build-Plugins und visuelles CMS. |
+| Juli 2025      | `@wuchale/svelte` | Verzicht auf manuelle Wörterbuchdeklarationen und wiederkehrende `$t`-Importe in Svelte-Dateien. | Svelte-Präprozessor, der Templates zur Build-Zeit analysiert und Textknoten ohne zusätzliche Hüllen übersetzt.                                 |
+
+</Tab>
+
+<Tab label="SolidJS" value="solid">
+
+| Erster Release | Bibliothek               | Zielsetzung                                                                     | Wichtigste Innovation                                                                                                                     |
+| -------------- | ------------------------ | ------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
+| September 2021 | `@solid-primitives/i18n` | Idiomatische i18n-Primitive passend zur feingranularen Reaktivität von SolidJS. | Signal-basierter Übersetzungsauflöser, der DOM-Knoten ohne virtuelles DOM oder unnötige Re-Renders aktualisiert.                          |
+| April 2025     | `solid-intlayer`         | Leistungsfähige Intlayer-Lösung nativ entwickelt für SolidJS und SolidStart.    | Signal-optimierte Bindings ohne Virtual-DOM-Overhead, vollständige TypeScript-Schema-Autovervollständigung und visuelle Editor-Anbindung. |
+| Juni 2026      | `@lingui/solid`          | Erweiterung von Build-Zeit-Makroextraktion und ICU MessageFormat auf SolidJS.   | Makrotransformationen angepasst an die Reaktivität von Solid, die Meldungen in kompakte Laufzeitstrukturen überführen.                    |
+
+</Tab>
+
+</Tabs>
+
+## Die vier Architektur-Epochen der JavaScript-i18n
+
+![Die Geschichte der JavaScript-i18n-Bibliotheken](https://github.com/aymericzip/intlayer/blob/main/docs/assets/history_i18n.png?raw=true)
+
+Rückblickend auf fünfzehn Jahre Entwicklung lässt sich die Geschichte der JavaScript-Internationalisierung in vier prägende Architektur-Epochen unterteilen:
+
+<AccordionGroup>
+<Accordion header="1. Die Ära der Laufzeit-Wörterbücher (2011 bis 2017)">
+
+Geprägt von `i18next`, `react-intl` und `vue-i18n`. Anwendungen luden statische JSON-Dateien vollständig in den Speicher, und Laufzeitfunktionen glich Zeichenkettenschlüssel mit verschachtelten Objekten ab. Pluralisierung und Variablenersetzung wurden im Client über reguläre Ausdrücke und Parser abgewickelt.
+
+</Accordion>
+<Accordion header="2. Die Ära der Build-Makros und Typsicherheit (2018 bis 2021)">
+
+Geprägt von `lingui`, `next-translate`, `transloco` und `typesafe-i18n`. Entwickler erkannten die Performancekosten des Parsings zur Laufzeit und die Fehleranfälligkeit ungetypter Schlüssel. Babel-Makros extrahierten Texte beim Build, Bundler-Plugins unterteilten Dictionaries nach Seiten, und TypeScript-Compiler begannen, Übersetzungsargumente statisch zu validieren.
+
+</Accordion>
+<Accordion header="3. Die Ära der Server Components und des Streamings (2022 bis 2024)">
+
+Geprägt von `next-intl`, `next-international` und frühen RSC-Adaptern. Mit React Server Components und dem Next.js App Router lag das Hauptaugenmerk darauf, Inhalte serverseitig zu rendern, ohne Übersetzungskataloge oder schwere i18n-Laufzeiten an den Browser ausliefern zu müssen.
+
+</Accordion>
+<Accordion header="4. Die Ära moderner Compiler und einheitlicher Content-Systeme (2024 bis 2026)">
+
+Geprägt von `paraglide`, `intlayer` und `wuchale`. Moderne Tools begreifen Internationalisierung als umfassende Inhaltsarchitektur statt reinen Zeichenkettenersatz. Compiler transformieren Nachrichten direkt in optimierten, tree-shakable Code, Inhaltsdeklarationen liegen direkt bei den Komponenten, und visuelle Editoren sowie automatisierte KI-Pipelines fügen sich nahtlos in Entwickler-Workflows ein. In diesem Ansatz trennt Intlayer Inhaltsdeklaration und automatische Typgenerierung von der Auslieferung und stellt maßgeschneiderte, performante Implementierungen (`react-intlayer`, `next-intlayer`, `vue-intlayer`, `angular-intlayer`, `svelte-intlayer` und `solid-intlayer`) bereit.
+
+</Accordion>
+</AccordionGroup>
+
+## Fazit: Entwicklererfahrung, Performance und der Einfluss von KI
+
+Über fünfzehn Jahre und vier Architekturphasen hinweg blieb die zentrale Herausforderung stets dieselbe: eine hervorragende Entwicklererfahrung (DX) und langfristige Wartbarkeit mit erstklassiger Client-Performance in Einklang zu bringen.
+
+Was mit globalen Variablen und unübersichtlichen JSON-Dateien begann, hat sich zu komponentenlokalisierten Inhalten, automatisierter TypeScript-Typsicherheit, kaskadenfreiem Server-Rendering und kompilierungsbasierter Optimierung weiterentwickelt.
+
+### Automatisierte Übersetzung und traditionelle Plattformen
+
+Ein wesentlicher Wendepunkt der letzten Jahre ist die automatisierte Übersetzung mittels KI, die traditionelle Geschäftsmodelle klassischer Lokalisierungsplattformen infrage stellt.
+
+Früher war die Zentralisierung in monolithischen JSON-Dateien ein notwendiger Kompromiss, um Übersetzungssysteme (TMS) anzubinden. Eine einzige Datei bot externen Übersetzern eine einfache Schnittstelle. Für Entwickler bedeutete dies jedoch gravierende architektonische Nachteile: häufige Git-Konflikte, verwaiste Schlüssel, fehlender Kontext auf Komponentenebene und unübersichtliche Namespaces.
+
+Dank generativer KI und moderner Compiler-Werkzeuge steht die Developer Experience (DX) wieder im Mittelpunkt. Build-Tools und CLIs können komponentenbasierte Inhaltsdateien eigenständig auffinden, validieren und übersetzen, ohne dass für externe Übersetzungsprozesse architektonische Kompromisse nötig sind.
+
+Kommerzielle Plattformen bauten über viele Jahre ihr Geschäftsmodell genau auf diesen manuellen Abläufen auf:
+
+- Dienste wie **Locize** (die SaaS-Plattform hinter `i18next`) und **Crowdin** (Integrationspartner diverser Open-Source-Bibliotheken) setzten auf gehosteten Übersetzungsspeicher, Tarife mit Kontingenten und Abrechnung nach Wortanzahl.
+- Da ihr Modell auf manuellen Zyklen und Volumen basiert, besteht wenig Anreiz, direkte, kostenfreie Automatisierungen ohne Zwischenschritte direkt in Entwicklungsumgebungen bereitzustellen.
+
+### Neue KI-Tools im Vergleich zu direkten API-Kosten
+
+Mit der Senkung der Übersetzungskosten bei gleichzeitig gestiegener sprachlicher Qualität durch moderne Sprachmodelle entstanden neue Anbieter:
+
+- Werkzeuge wie Paraglide mit **linguo.dev** oder **General Translation** (`gt-react`, `gt-next`) setzen auf eigene Cloud-Pipelines mit fortlaufenden Abonnements.
+- **Intlayer** hingegen integriert die KI-gestützte Übersetzung direkt in seine Open-Source-CLI. Teams hinterlegen einfach ihre eigenen API-Schlüssel (OpenAI, Anthropic, Mistral oder Google Gemini). Ohne Zwischengebühren oder Plattformbindung erfolgt die Übersetzung zu den reinen Rohkosten des gewählten KI-Anbieters.
+
+### Mehr als i18n: Ein ganzheitliches System für mehrsprachige Inhalte
+
+Moderne Webentwicklung geht weit über das Übersetzen einzelner Begriffe wie `"Absenden"` oder `"Anmelden"` hinaus. Heutige Anwendungen benötigen strukturierte, dynamische und reichhaltige Inhalte entlang komplexer Nutzeroberflächen.
+
+Intlayer versteht sich daher nicht bloß als Schlüssel-Lookup-Werkzeug, sondern als ganzheitliches Content-System. Mit nativer Unterstützung für Markdown, HTML-Strukturen, verschachtelte Datenschemata und visuelle CMS-Bearbeitung verbindet es moderne Code-Architektur mit effizienten Redaktionsabläufen.
+
+Weiterführende Vergleiche und praxisnahe Anleitungen finden Sie in folgenden Ressourcen:
+
+- [Compiler vs. deklarative Internationalisierung](https://github.com/aymericzip/intlayer/blob/main/docs/blog/de/compiler_vs_declarative_i18n.md)
+- [Komponentenbasierte vs. zentralisierte i18n](https://github.com/aymericzip/intlayer/blob/main/docs/blog/de/per-component_vs_centralized_i18n.md)
+- [Performance und Benchmarks](https://intlayer.org/doc/benchmark)
+- [Intlayer Kompatibilitäts-Adapter](https://intlayer.org/doc/concept/compatibility)