@intlayer/docs 8.9.4 → 8.9.6-canary.0

package/docs/ar/benchmark/index.md

@@ -30,6 +30,3 @@ Benchmark Bloom هي مجموعة لقياس الأداء تقيس التأثي
 - [**Vue Benchmark Report**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/benchmark/vue.md)
 - [**Solid Benchmark Report**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/benchmark/solid.md)
 - [**Svelte Benchmark Report**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/benchmark/svelte.md)
-- [**Vue Benchmark Report**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/benchmark/vue.md)
-- [**Solid Benchmark Report**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/benchmark/solid.md)
-- [**Svelte Benchmark Report**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/benchmark/svelte.md)

package/docs/ar/benchmark/nextjs.md

@@ -61,6 +61,13 @@ history:
 
 يحاول Intlayer التحسين عبر هذه الأبعاد.
 
+## TL;DR
+
+- **Intlayer** و **next-translate**: أفضل الخيارات لأداء Next.js، حيث يقدمان أصغر حجم وأفضل دعم للرندرة الستاتيكية.
+- **next-intl**: الخيار الأكثر رواجًا ولكنه ثقيل ومعقد في التحسين للتطبيقات الكبيرة.
+- **next-i18next**: شائع وغني بالإضافات، ولكنه يأتي بحجم حزمة كبير (~3 أضعاف Intlayer).
+- **تجنب**: **gt-next** و **lingo.dev** بسبب مشكلات الأداء الخطيرة، والارتباط بالبائع (vendor lock-in)، والأخطاء التي تعطل البناء.
+
 ## اختبر تطبيقك
 
 لتسليط الضوء على هذه المشكلات، قمت ببناء ماسح ضوئي مجاني يمكنك تجربته [هنا](https://intlayer.org/i18n-seo-scanner).
@@ -99,14 +106,14 @@ history:
 في هذه المقارنة، قمنا بمقارنة المكتبات التالية:
 
 - `Base App` (بدون مكتبة i18n)
-- `next-intlayer` (v8.7.5)
+- `next-intlayer` (v8.7.12)
 - `next-i18next` (v16.0.5)
 - `next-intl` (v4.9.1)
 - `@lingui/core` (v5.3.0)
 - `next-translate` (v3.1.2)
 - `next-international` (v1.3.1)
 - `@inlang/paraglide-js` (v2.15.1)
-- `tolgee` (v7.0.0)
+- `@tolgee/react` (v7.0.0)
 - `@lingo.dev/compiler` (v0.4.0)
 - `wuchale` (v0.22.11)
 - `gt-next` (v6.16.5)
@@ -161,10 +168,10 @@ history:
 
 **(General Translation)** (`gt-next@6.16.5`):
 
-- لتطبيق بحجم 110 كيلوبايت، تضيف `gt-react` أكثر من 440 كيلوبايت إضافية.
+- لتطبيق بحجم 110 كيلوبايت، تضيف `gt-next` أكثر من 440 كيلوبايت إضافية.
 - `Quota Exceeded, please upgrade your plan` (تم تجاوز الحصة، يرجى ترقية خطتك) في أول بناء للمشروع.
 - لا يتم رندرة الترجمات؛ أحصل على خطأ `Error: <T> used on the client-side outside of <GTProvider>` ، والذي يبدو أنه خلل في المكتبة.
-- أثناء تنفيذ **gt-tanstack-start-react** ، صادفت أيضًا [مشكلة](https://github.com/generaltranslation/gt/issues/1210#event-24510646961) في المكتبة: `does not provide an export named 'printAST' - @formatjs/icu-messageformat-parser` ، والتي كانت تؤدي إلى تعطل التطبيق. بعد الإبلاغ عن هذه المشكلة، قام المطور بإصلاحها خلال 24 ساعة.
+- أثناء تنفيذ **gt-next** ، صادفت أيضًا [مشكلة](https://github.com/generaltranslation/gt/issues/1210#event-24510646961) في المكتبة: `does not provide an export named 'printAST' - @formatjs/icu-messageformat-parser` ، والتي كانت تؤدي إلى تعطل التطبيق. بعد الإبلاغ عن هذه المشكلة، قام المطور بإصلاحها خلال 24 ساعة.
 - المكتبة تمنع الرندرة الستاتيكية لصفحات Next.js.
 
 **(Lingo.dev)** (`@lingo.dev/compiler@0.4.0`):
@@ -186,9 +193,11 @@ history:
 أنا شخصياً لا أحب الاضطرار إلى إعادة إنشاء ملفات JS قبل كل رفع للكود، مما يخلق خطراً دائماً لتضارب الدمج (merge conflicts). كما يبدو أن الأداة تركز على Vite أكثر من Next.js.
 أخيرًا، مقارنة بالحلول الأخرى، لا يستخدم Paraglide مخزنًا (مثل React context) لجلب اللغة الحالية لرندرة المحتوى. لكل عقدة يتم تحليلها، سيطلب اللغة من localStorage / cookie وما إلى ذلك. يؤدي ذلك إلى تنفيذ منطق غير ضروري يؤثر على تفاعلية المكونات.
 
+> ملاحظة حول paraglide: يقوم الحل بحقن الكود في قاعدة الكود الخاصة بك للاستيراد، ونتيجة لذلك يكون مقياس 'حجم المكتبة' في تقرير المقارنة 0 تقريبًا. توليد الكود أمر جيد، لأن الدالة المستخدمة ستتضمن فقط المنطق الضروري (البادئة الكاملة مقابل عدم وجود بادئة، الكوكيز مقابل التخزين، إلخ). في المقابل، يقوم Intlayer بتنفيذ هذا التصفية عبر حقن متغيرات البيئة في البناء لإجبار المجمع على إزالة المحتوى حسب المنطق. بفضل هذا، ينتهي الأمر بـ paraglide و intlayer كحلول أخف بـ 6 إلى 10 مرات من i18next أو next-intl.
+
 ### 3 — حلول مقبولة
 
-**(Tolgee)** (`tolgee@7.0.0`):
+**(Tolgee)** (`@tolgee/react@7.0.0`):
 
 يعالج `Tolgee` العديد من المشكلات المذكورة سابقًا. وجدت صعوبة في اعتماده أكثر من الأدوات المماثلة. لا يوفر سلامة الأنواع (type safety) ، مما يجعل اكتشاف المفاتيح المفقودة وقت البناء أكثر صعوبة. اضطررت لتغليف دوال Tolgee بدوالي الخاصة لإضافة ميزة اكتشاف المفاتيح المفقودة.
 
@@ -216,7 +225,7 @@ history:
 
 خيار `next-translate` هو توصيتي الرئيسية إذا كنت تحب واجهة برمجية بأسلوب `t()`. إنه أنيق عبر `next-translate-plugin` ، حيث يحمل مساحات الأسماء من خلال `getStaticProps` مع مجمع Webpack / Turbopack. إنه أيضًا الخيار الأخف هنا (~2.5 كيلوبايت). بالنسبة لمساحات الأسماء، فإن تحديدها لكل صفحة أو مسار في الإعدادات مدروس جيدًا وأسهل في الصيانة من البدائل الرئيسية مثل **next-intl** أو **next-i18next**. في الإصدار `3.1.2` ، لاحظت أن الرندرة الستاتيكية لم تعمل؛ حيث تراجع Next.js إلى الرندرة الديناميكية.
 
-**(Intlayer)** (`next-intlayer@8.7.5`):
+**(Intlayer)** (`next-intlayer@8.7.12`):
 
 لن أحكم شخصيًا على `next-intlayer` من أجل الموضوعية، لأنه حلي الخاص.
 

package/docs/ar/benchmark/solid.md

@@ -0,0 +1,155 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+title: أفضل حل i18n لـ Solid في عام 2026 - تقرير قياسي
+description: قارن بين مكتبات تدويل Solid (i18n) مثل solid-primitives وsolid-i18next وIntlayer. تقرير أداء مفصل حول حجم الحزمة والتسرب والتفاعل.
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - solid
+  - performance
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+  - solid
+author: Aymeric PINEAU
+applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-solid-template
+history:
+  - version: 8.7.12
+    date: 2026-01-06
+    changes: "بدء التقييم القياسي"
+---
+
+# مكتبات i18n لـ Solid — تقرير التقييم القياسي 2026
+
+هذه الصفحة هي تقرير تقييم قياسي لحلول i18n على Solid.
+
+## جدول المحتويات
+
+<Toc/>
+
+## التقييم القياسي التفاعلي
+
+<I18nBenchmark framework="vite-solid" vertical/>
+
+## مرجع النتائج:
+
+<iframe 
+  src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_solid.md" 
+  width="100%" 
+  height="600px"
+  style="border:none;">
+</iframe>
+
+> https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_solid.md
+
+راجع مستودع التقييم القياسي الكامل [هنا](https://github.com/intlayer-org/benchmark-i18n/tree/main).
+
+## مقدمة
+
+تعد حلول التدويل من بين أثقل الاعتمادات في تطبيق Solid. الخطر الرئيسي هو شحن محتوى غير ضروري: ترجمات لصفحات أخرى ولغات أخرى في حزمة مسار واحد.
+
+مع نمو تطبيقك، يمكن أن تؤدي هذه المشكلة بسرعة إلى تضخم ملفات JavaScript المرسلة إلى العميل وإبطاء التنقل.
+
+في الممارسة العملية، بالنسبة للتطبيقات الأقل تحسينًا، يمكن أن ينتهي الأمر بصفحة مدولة لتكون أثقل بعدة مرات من النسخة بدون i18n.
+
+التأثير الآخر هو على تجربة المطور (DX): كيفية التصريح عن المحتوى، والأنواع، وتنظيم فضاء الأسماء، والتحميل الديناميكي، والتفاعل عند تغيير اللغة.
+
+## TL;DR
+
+- **Intlayer**: الخيار الموصى به لتطبيقات Solid المهنية التي تحتاج إلى ميزات متقدمة وتحسين (v8.7.12).
+- **@solid-primitives/i18n**: بديل خفيف الوزن ممتاز للمشاريع البسيطة، على الرغم من افتقاره إلى ميزات متقدمة مثل التحميل الكسول (lazy loading).
+- **solid-i18next**: خيار معياري ولكنه ثقيل (~4.7 أضعاف Intlayer) مع نفس عيوب React i18next.
+- **Paraglide**: نهج مبتكر ولكن DX معقد ومشكلات في التخلص من الكود غير المستخدم (tree-shaking) في بعض الإعدادات.
+
+## اختبر تطبيقك
+
+لتحديد مشكلات تسرب i18n بسرعة، قمت بإعداد ماسح ضوئي مجاني متاح [هنا](https://intlayer.org/i18n-seo-scanner).
+
+<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## المشكلة
+
+هناك ركيزتان أساسيتان للحد من تكلفة تطبيق متعدد اللغات:
+
+- تقسيم المحتوى حسب الصفحة / فضاء الأسماء حتى لا يتم تحميل قواميس كاملة عندما لا تحتاج إليها.
+- تحميل اللغة الصحيحة ديناميكيًا، فقط عند الحاجة إليها.
+
+فهم القيود التقنية لهذه الأساليب:
+
+**التحميل الديناميكي**
+
+بدون التحميل الديناميكي، تحتفظ معظم الحلول بالرسائل في الذاكرة منذ الريندر الأول، مما يضيف عبئًا كبيرًا للتطبيقات التي تحتوي على العديد من المسارات واللغات.
+
+مع التحميل الديناميكي، فإنك تقبل بمقايضة: ملفات JS أولية أقل، ولكن أحيانًا طلب إضافي عند تبديل اللغة.
+
+**تقسيم المحتوى (Splitting)**
+
+تعتبر الصيغ المبنية حول `t('a.b.c')` مريحة للغاية ولكنها غالبًا ما تشجع على الاحتفاظ بكائنات JSON كبيرة أثناء التشغيل. هذا النموذج يجعل التخلص من الكود غير المستخدم (tree-shaking) صعبًا ما لم توفر المكتبة استراتيجية حقيقية لتقسيم المحتوى لكل صفحة.
+
+## منهجية البحث
+
+في هذا التقييم القياسي، قارنا المكتبات التالية:
+
+- `Base App` (بدون مكتبة i18n)
+- `solid-intlayer` (v8.7.12)
+- `@solid-primitives/i18n` (v2.2.1)
+- `solid-i18next` (v17.0.2)
+- `@inlang/paraglide-js` (v2.17.0)
+
+الإطار هو `Solid` مع تطبيق متعدد اللغات يتكون من **10 صفحات** و **10 لغات**.
+
+قارنا بين **أربع استراتيجيات تحميل**:
+
+| الاستراتيجية           | بدون فضاء أسماء (عام)                          | مع فضاء أسماء (محدد/scoped)                                           |
+| :--------------------- | :--------------------------------------------- | :-------------------------------------------------------------------- |
+| **التحميل الثابت**     | **Static**: كل شيء في الذاكرة عند بدء التشغيل. | **Scoped static**: مقسم حسب فضاء الأسماء؛ يتم تحميل كل شيء عند البدء. |
+| **التحميل الديناميكي** | **Dynamic**: تحميل عند الطلب حسب اللغة.        | **Scoped dynamic**: تحميل دقيق حسب فضاء الأسماء واللغة.               |
+
+## ملخص الاستراتيجيات
+
+- **ثابت (Static)**: بسيط؛ لا يوجد تأخير في الشبكة بعد التحميل الأولي. الجانب السلبي: حجم حزمة كبير.
+- **ديناميكي (Dynamic)**: يقلل الوزن الأولي (تحميل كسول). مثالي عندما يكون لديك العديد من اللغات.
+- **ثابت بنطاق (Scoped static)**: يحافظ على تنظيم الكود (فصل منطقي) بدون طلبات شبكة إضافية معقدة.
+- **ديناميكي بنطاق (Scoped dynamic)**: أفضل نهج لتقسيم الكود والأداء. يقلل من استخدام الذاكرة عن طريق تحميل ما تحتاجه الرؤية الحالية واللغة النشطة فقط.
+
+## النتائج بالتفصيل
+
+### 1 — حلول يجب تجنبها
+
+> لا يوجد حل واضح يجب تجنبه في نظام Solid البيئي.
+
+### 2 — حلول مقبولة
+
+**(solid-i18next)** (`solid-i18next@17.0.2`):
+
+ربما يكون `solid-i18next` هو الخيار الأكثر شيوعًا لأنه كان من أوائل الحلول التي لبت احتياجات i18n لتطبيقات JavaScript. كما أنه يحتوي على مجموعة واسعة من المكونات الإضافية للمجتمع لمشكلات محددة.
+
+الحزمة ثقيلة (~14.6kb، أي حوالي 4.7 أضعاف `solid-intlayer`).
+
+ومع ذلك، فإنه يشترك في نفس العيوب الرئيسية مثل الحلول المبنية على `t('a.b.c')`: التحسينات ممكنة ولكنها تستهلك الكثير من الوقت، والمشاريع الكبيرة تكتنفها مخاطر الممارسات السيئة (فضاءات الأسماء + التحميل الديناميكي + الأنواع).
+
+**(@solid-primitives/i18n)** (`@solid-primitives/i18n@2.2.1`):
+
+مكون Solid البدائي خفيف الوزن وفعال للغاية. أوصي بهذا الحل للمشاريع الخفيفة، ولكنه قد يفتقر بسرعة إلى الميزات للحلول المهنية بما في ذلك إدارة ملفات تعريف الارتباط، وإعادة توجيه الوكيل، والمنسقات وما إلى ذلك.
+كما يفتقد إلى التحميل الكسول وتقسيم فضاءات الأسماء لتحسين حجم الصفحة.
+
+**(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
+
+يقدم `Paraglide` نهجًا مبتكرًا ومدروسًا جيدًا. ومع ذلك، في هذا التقييم القياسي، لم يعمل tree-shaking الذي تعلن عنه شركتهم مع التنفيذ الخاص بي. سير العمل و DX أيضًا أكثر تعقيدًا من الخيارات الأخرى.
+شخصيًا، لا أحب الاضطرار إلى إعادة إنشاء ملفات JS قبل كل عملية push، مما يخلق خطرًا مستمرًا لتعارض الدمج عبر طلبات السحب.
+أخيرًا، مقارنة بالحلول الأخرى، لا يستخدم Paraglide مخزنًا (مثل Solid signal) لاسترداد اللغة الحالية لريندر المحتوى. لكل عقدة يتم تحليلها، سيطلب اللغة من localStorage / cookie وما إلى ذلك. يؤدي هذا إلى تنفيذ منطق غير ضروري يؤثر على تفاعل المكونات.
+
+### 3 — التوصيات
+
+**(Intlayer)** (`solid-intlayer@8.7.12`):
+
+لن أحكم شخصيًا على `solid-intlayer` من أجل الموضوعية، لأنه الحل الخاص بي.
+
+### ملاحظة شخصية
+
+هذه الملاحظة شخصية ولا تؤثر على نتائج التقييم القياسي. ومع ذلك، في عالم i18n غالبًا ما ترى إجماعًا حول نمط مثل `const t = useTranslation('xx')` + `<>{t('xx.xx')}</>` للمحتوى المترجم.
+
+في تطبيقات Solid، يعد حقن وظيفة كـ `JSX.Element` في نظري نمطًا مضادًا (anti-pattern). كما أنه يضيف تعقيدًا يمكن تجنبه وعبئًا في تنفيذ JavaScript (حتى لو كان بالكاد يلاحظ).

package/docs/ar/benchmark/svelte.md

@@ -0,0 +1,148 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+title: أفضل حل i18n لـ Svelte في عام 2026 - تقرير قياسي
+description: قارن بين مكتبات تدويل Svelte (i18n) مثل svelte-i18n وParaglide وIntlayer. تقرير أداء مفصل حول حجم الحزمة والتسرب والتفاعل.
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - svelte
+  - performance
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+  - svelte
+author: Aymeric PINEAU
+applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-svelte-template
+history:
+  - version: 8.7.12
+    date: 2026-01-06
+    changes: "بدء التقييم القياسي"
+---
+
+# مكتبات i18n لـ Svelte — تقرير التقييم القياسي 2026
+
+هذه الصفحة هي تقرير تقييم قياسي لحلول i18n على Svelte.
+
+## جدول المحتويات
+
+<Toc/>
+
+## التقييم القياسي التفاعلي
+
+<I18nBenchmark framework="vite-svelte" vertical/>
+
+## مرجع النتائج:
+
+<iframe 
+  src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_svelte.md" 
+  width="100%" 
+  height="600px"
+  style="border:none;">
+</iframe>
+
+> https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_svelte.md
+
+راجع مستودع التقييم القياسي الكامل [هنا](https://github.com/intlayer-org/benchmark-i18n/tree/main).
+
+## مقدمة
+
+تعد حلول التدويل من بين أثقل الاعتمادات في تطبيق Svelte. الخطر الرئيسي هو شحن محتوى غير ضروري: ترجمات لصفحات أخرى ولغات أخرى في حزمة مسار واحد.
+
+مع نمو تطبيقك، يمكن أن تؤدي هذه المشكلة بسرعة إلى تضخم ملفات JavaScript المرسلة إلى العميل وإبطاء التنقل.
+
+في الممارسة العملية، بالنسبة للتطبيقات الأقل تحسينًا، يمكن أن ينتهي الأمر بصفحة مدولة لتكون أثقل بعدة مرات من النسخة بدون i18n.
+
+التأثير الآخر هو على تجربة المطور (DX): كيفية التصريح عن المحتوى، والأنواع، وتنظيم فضاء الأسماء، والتحميل الديناميكي، والتفاعل عند تغيير اللغة.
+
+## TL;DR
+
+- **Intlayer**: الخيار الأكثر كفاءة في الأداء (v8.7.12) مع أصغر بصمة (footprint).
+- **Paraglide**: منافس قوي للتخلص من الكود غير المستخدم (tree-shaking) ولكنه يمتلك تجربة مطور أكثر تعقيدًا وعبئًا في التفاعل.
+- **svelte-i18n**: كامل ومعياري لـ Svelte، ولكنه يحمل وزن حزمة أكبر بكثير (~7 أضعاف Intlayer).
+
+## اختبر تطبيقك
+
+لتحديد مشكلات تسرب i18n بسرعة، قمت بإعداد ماسح ضوئي مجاني متاح [هنا](https://intlayer.org/i18n-seo-scanner).
+
+<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## المشكلة
+
+هناك ركيزتان أساسيتان للحد من تكلفة تطبيق متعدد اللغات:
+
+- تقسيم المحتوى حسب الصفحة / فضاء الأسماء حتى لا يتم تحميل قواميس كاملة عندما لا تحتاج إليها.
+- تحميل اللغة الصحيحة ديناميكيًا، فقط عند الحاجة إليها.
+
+فهم القيود التقنية لهذه الأساليب:
+
+**التحميل الديناميكي**
+
+بدون التحميل الديناميكي، تحتفظ معظم الحلول بالرسائل في الذاكرة منذ الريندر الأول، مما يضيف عبئًا كبيرًا للتطبيقات التي تحتوي على العديد من المسارات واللغات.
+
+مع التحميل الديناميكي، فإنك تقبل بمقايضة: ملفات JS أولية أقل، ولكن أحيانًا طلب إضافي عند تبديل اللغة.
+
+**تقسيم المحتوى (Splitting)**
+
+تعتبر الصيغ المبنية حول `t('a.b.c')` مريحة للغاية ولكنها غالبًا ما تشجع على الاحتفاظ بكائنات JSON كبيرة أثناء التشغيل. هذا النموذج يجعل التخلص من الكود غير المستخدم (tree-shaking) صعبًا ما لم توفر المكتبة استراتيجية حقيقية لتقسية المحتوى لكل صفحة.
+
+## منهجية البحث
+
+في هذا التقييم القياسي، قارنا المكتبات التالية:
+
+- `Base App` (بدون مكتبة i18n)
+- `svelte-intlayer` (v8.7.12)
+- `svelte-i18n` (v4.0.1)
+- `@inlang/paraglide-js` (v2.17.0)
+
+الإطار هو `Svelte` مع تطبيق متعدد اللغات يتكون من **10 صفحات** و **10 لغات**.
+
+قارنا بين **أربع استراتيجيات تحميل**:
+
+| الاستراتيجية           | بدون فضاء أسماء (عام)                          | مع فضاء أسماء (محدد/scoped)                                           |
+| :--------------------- | :--------------------------------------------- | :-------------------------------------------------------------------- |
+| **التحميل الثابت**     | **Static**: كل شيء في الذاكرة عند بدء التشغيل. | **Scoped static**: مقسم حسب فضاء الأسماء؛ يتم تحميل كل شيء عند البدء. |
+| **التحميل الديناميكي** | **Dynamic**: تحميل عند الطلب حسب اللغة.        | **Scoped dynamic**: تحميل دقيق حسب فضاء الأسماء واللغة.               |
+
+## ملخص الاستراتيجيات
+
+- **ثابت (Static)**: بسيط؛ لا يوجد تأخير في الشبكة بعد التحميل الأولي. الجانب السلبي: حجم حزمة كبير.
+- **ديناميكي (Dynamic)**: يقلل الوزن الأولي (تحميل كسول). مثالي عندما يكون لديك العديد من اللغات.
+- **ثابت بنطاق (Scoped static)**: يحافظ على تنظيم الكود (فصل منطقي) بدون طلبات شبكة إضافية معقدة.
+- **ديناميكي بنطاق (Scoped dynamic)**: أفضل نهج لتقسيم الكود والأداء. يقلل من استخدام الذاكرة عن طريق تحميل ما تحتاجه الرؤية الحالية واللغة النشطة فقط.
+
+## النتائج بالتفصيل
+
+### 1 — حلول يجب تجنبها
+
+> لا يوجد حل واضح يجب تجنبه في نظام Svelte البيئي.
+
+### 2 — حلول مقبولة
+
+**(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
+
+يقدم `Paraglide` نهجًا مبتكرًا ومدروسًا جيدًا. في سياق تطبيق Vite + Svelte، يعمل التخلص من الكود غير المستخدم (tree-shaking) الذي تعلن عنه شركتهم كما هو متوقع، وهو أمر رائع.
+ولكن في حالة React + TanStack Start، لم يعمل tree-shaking كما هو متوقع، والأمر نفسه بالنسبة لـ Next.js. ومع ذلك، فإن استخدام Paraglide في مشروع Svelte و TanStack Start يستحق التدقيق.
+سير العمل و DX أيضًا أكثر تعقيدًا من الخيارات الأخرى.
+شخصيًا، لا أحب الاضطرار إلى إعادة إنشاء ملفات JS قبل كل عملية push، مما يخلق خطرًا مستمرًا لتعارض الدمج عبر طلبات السحب (PRs). يبدو أن الأداة تركز أيضًا على Vite أكثر من Next.js.
+أخيرًا، مقارنة بالحلول الأخرى، لا يستخدم Paraglide مخزنًا (مثل Svelte store) لاسترداد اللغة الحالية لريندر المحتوى. لكل عقدة يتم تحليلها، سيطلب اللغة من localStorage / cookie وما إلى ذلك. يؤدي هذا إلى تنفيذ منطق غير ضروري يؤثر على تفاعل المكونات.
+
+> ملاحظة حول paraglide: يقوم الحل بحقن الكود في قاعدة الكود الخاصة بك للاستيراد؛ ونتيجة لذلك، فإن مقياس "حجم المكتبة" في تقرير التقييم القياسي هو 0 تقريبًا. يعد إنشاء الكود (Code generation) أمرًا جيدًا، لأن الوظيفة المستخدمة ستتضمن فقط المنطق الضروري (بادئة في كل مكان مقابل لا بادئة، ملف تعريف ارتباط مقابل تخزين، إلخ). بالمقارنة، تقوم Intlayer بإجراء هذا التصفية عبر حقن متغيرات البيئة أثناء البناء لإجبار أداة التجميع على التخلص من الكود غير المستخدم للمحتوى اعتمادًا على المنطق. بفضل هذا، ينتهي الأمر بـ paraglide و intlayer كحلول أخف بـ 6 إلى 10 مرات من i18next أو next-intl.
+
+**(svelte-i18n)** (`svelte-i18n@3.4.0`):
+
+يلبي هذا الحل جميع احتياجات i18n في مشروع Svelte. ولكن كما هو الحال مع i18next أو غيرها من حلول i18n الرئيسية، فهي ثقيلة بعض الشيء (~15.9kb، أي حوالي 7 أضعاف `svelte-intlayer`).
+
+### 3 — التوصيات
+
+**(Intlayer)** (`svelte-intlayer@8.7.12`):
+
+لن أحكم شخصيًا على `svelte-intlayer` من أجل الموضوعية، لأنه الحل الخاص بي.
+
+### ملاحظة شخصية
+
+هذه الملاحظة شخصية ولا تؤثر على نتائج التقييم القياسي. ومع ذلك، في عالم i18n غالبًا ما ترى إجماعًا حول نمط مثل `const t = useTranslation('xx')` + `<>{t('xx.xx')}</>` للمحتوى المترجم.
+
+في تطبيقات Svelte، يعد حقن وظيفة كـ `Slot` في نظري نمطًا مضادًا (anti-pattern). كما أنه يضيف تعقيدًا يمكن تجنبه وعبئًا في تنفيذ JavaScript (حتى لو كان بالكاد يلاحظ).

package/docs/ar/benchmark/tanstack.md

@@ -57,6 +57,13 @@ history:
 
 التأثير الآخر هو على تجربة المطور (DX): كيفية الإعلان عن المحتوى، والأنواع، وتنظيم مساحة الأسماء، والتحميل الديناميكي، والتفاعلية عند تغيير اللغة.
 
+## TL;DR
+
+- **Intlayer**: يوفر أفضل أداء وأصغر حجم للحزمة (v8.7.12) لـ TanStack Start.
+- **react-i18next** و **use-intl**: بدائل ناضجة مع أنظمة بيئية كبيرة، ولكنها أثقل بكثير وأكثر تعقيدًا في التحسين.
+- **Paraglide**: فكرة مبتكرة لـ tree-shaking لكنها لا تعمل في الممارسة العملية. تجربة مطور (DX) معقدة وعبء تفاعلي في TanStack Start.
+- **تجنب**: **General Translation (GT)** و **Lingo.dev** بسبب مشكلات الأداء الخطيرة، وقيود حصة الذكاء الاصطناعي، والارتباط بالبائع (vendor lock-in).
+
 ## اختبر تطبيقك
 
 لاكتشاف مشكلات تسرب i18n بسرعة، قمت بإعداد ماسح ضوئي مجاني متاح [هنا](https://intlayer.org/i18n-seo-scanner).
@@ -87,12 +94,12 @@ history:
 في هذه المقارنة، قمنا بمقارنة المكتبات التالية:
 
 - `Base App` (بدون مكتبة i18n)
-- `react-intlayer` (v8.7.5-canary.0)
+- `react-intlayer` (v8.7.12)
 - `react-i18next` (v17.0.2)
 - `use-intl` (v4.9.1)
 - `@lingui/core` (v5.3.0)
 - `@inlang/paraglide-js` (v2.15.1)
-- `tolgee` (v7.0.0)
+- `@tolgee/react` (v7.0.0)
 - `react-intl` (v10.1.1)
 - `wuchale` (v0.22.11)
 - `gt-react` (vlatest)
@@ -150,7 +157,9 @@ history:
 
 يقدم `Paraglide` نهجًا مبتكرًا ومدروسًا جيدًا. ومع ذلك، في هذه المقارنة، لم تعمل ميزة Tree-shaking التي تروج لها شركتهم في تنفيذ Next.js أو TanStack Start. كما أن سير العمل وتجربة المطور أكثر تعقيدًا من الخيارات الأخرى. أنا شخصياً لست معجباً بضرورة إعادة إنشاء ملفات JS قبل كل رفع للكود، مما يخلق خطراً دائماً لتضارب الدمج بين المطورين.
 
-**(Tolgee)** (`tolgee@7.0.0`):
+> ملاحظة حول paraglide: يقوم هذا الحل بحقن الكود في قاعدة الكود الخاصة بك لعمليات الاستيراد، ونتيجة لذلك فإن مقياس 'lib size' في تقرير المقارنة هو 0 تقريبًا. توليد الكود (Code generation) أمر جيد، لأن الدالة المستخدمة ستشمل فقط المنطق الضروري (البادئة للكل مقابل عدم وجود بادئة، الكوكيز مقابل التخزين، إلخ). في المقابل، يقوم Intlayer بمعالجة هذا الفلترة باستخدام حقن متغيرات البيئة في البناء لإجبار أداة التجميع (bundler) على عمل tree-shake للمحتوى اعتمادًا على المنطق. بفضل هذا، ينتهي الأمر بـ paraglide و intlayer بكونهما حلولًا أخف بـ 6 إلى 10 مرات من i18next أو next-intl.
+
+**(Tolgee)** (`@tolgee/react@7.0.0`):
 
 يعالج `Tolgee` العديد من المشكلات المذكورة سابقًا. وجدت صعوبة في البدء معه أكثر من الأدوات الأخرى ذات التوجهات المشابهة. لا يوفر سلامة الأنواع، مما يجعل اكتشاف المفاتيح المفقودة وقت البناء أمراً صعباً للغاية. اضطررت لتغليف واجهات برمجة تطبيقات Tolgee بواجهاتي الخاصة لإضافة ميزة اكتشاف المفاتيح المفقودة.
 

package/docs/ar/benchmark/vue.md

@@ -0,0 +1,160 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+title: أفضل حل i18n لـ Vue في عام 2026 - تقرير قياسي
+description: قارن بين مكتبات تدويل Vue (i18n) مثل vue-i18n وfluent-vue وIntlayer. تقرير أداء مفصل حول حجم الحزمة والتسرب والتفاعل.
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - vue
+  - performance
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+  - vue
+author: Aymeric PINEAU
+applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-vue-template
+history:
+  - version: 8.7.12
+    date: 2026-01-06
+    changes: "بدء التقييم القياسي"
+---
+
+# مكتبات i18n لـ Vue — تقرير التقييم القياسي 2026
+
+هذه الصفحة هي تقرير تقييم قياسي لحلول i18n على Vue.
+
+## جدول المحتويات
+
+<Toc/>
+
+## التقييم القياسي التفاعلي
+
+<I18nBenchmark framework="vite-vue" vertical/>
+
+## مرجع النتائج:
+
+<iframe 
+  src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_vue.md" 
+  width="100%" 
+  height="600px"
+  style="border:none;">
+</iframe>
+
+> https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_vue.md
+
+راجع مستودع التقييم القياسي الكامل [هنا](https://github.com/intlayer-org/benchmark-i18n/tree/main).
+
+## مقدمة
+
+تعد حلول التدويل من بين أثقل الاعتمادات في تطبيق Vue. الخطر الرئيسي هو شحن محتوى غير ضروري: ترجمات لصفحات أخرى ولغات أخرى في حزمة مسار واحد.
+
+مع نمو تطبيقك، يمكن أن تؤدي هذه المشكلة بسرعة إلى تضخم ملفات JavaScript المرسلة إلى العميل وإبطاء التنقل.
+
+في الممارسة العملية، بالنسبة للتطبيقات الأقل تحسينًا، يمكن أن ينتهي الأمر بصفحة مدولة لتكون أثقل بعدة مرات من النسخة بدون i18n.
+
+التأثير الآخر هو على تجربة المطور (DX): كيفية التصريح عن المحتوى، والأنواع، وتنظيم فضاء الأسماء، والتحميل الديناميكي، والتفاعل عند تغيير اللغة.
+
+## TL;DR
+
+- **Intlayer**: الحل الأخف وزنًا (v8.7.12) مع ميزة النطاق (scoping) والتحميل الديناميكي المدمجة.
+- **vue-i18n**: المعيار الصناعي مع نظام بيئي غني، ولكنه قد يصبح أثقل بكثير ويصعب تحسينه لتقسيم الكود في التطبيقات الكبيرة.
+- **fluent-vue**: تنظيم مبتكر للرسائل ولكنه يفتقر إلى سلامة النوع (type-safety) ويعد حلاً ثقيلًا للغاية.
+
+## اختبر تطبيقك
+
+لتحديد مشكلات تسرب i18n بسرعة، قمت بإعداد ماسح ضوئي مجاني متاح [هنا](https://intlayer.org/i18n-seo-scanner).
+
+<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## المشكلة
+
+هناك ركيزتان أساسيتان للحد من تكلفة تطبيق متعدد اللغات:
+
+- تقسيم المحتوى حسب الصفحة / فضاء الأسماء حتى لا يتم تحميل قواميس كاملة عندما لا تحتاج إليها.
+- تحميل اللغة الصحيحة ديناميكيًا، فقط عند الحاجة إليها.
+
+فهم القيود التقنية لهذه الأساليب:
+
+**التحميل الديناميكي**
+
+بدون التحميل الديناميكي، تحتفظ معظم الحلول بالرسائل في الذاكرة منذ الريندر الأول، مما يضيف عبئًا كبيرًا للتطبيقات التي تحتوي على العديد من المسارات واللغات.
+
+مع التحميل الديناميكي، فإنك تقبل بمقايضة: ملفات JS أولية أقل، ولكن أحيانًا طلب إضافي عند تبديل اللغة.
+
+**تقسيم المحتوى (Splitting)**
+
+تعتبر الصيغ المبنية حول `const { t } = useI18n()` + `t('a.b.c')` مريحة للغاية ولكنها غالبًا ما تشجع على الاحتفاظ بكائنات JSON كبيرة أثناء التشغيل. هذا النموذج يجعل التخلص من الكود غير المستخدم (tree-shaking) صعبًا ما لم توفر المكتبة استراتيجية حقيقية لتقسيم المحتوى لكل صفحة.
+
+## منهجية البحث
+
+في هذا التقييم القياسي، قارنا المكتبات التالية:
+
+- `Base App` (بدون مكتبة i18n)
+- `vue-intlayer` (v8.7.12)
+- `vue-i18n` (v11.4.0)
+- `fluent-vue` (v3.8.2)
+
+الإطار هو `Vue` مع تطبيق متعدد اللغات يتكون من **10 صفحات** و **10 لغات**.
+
+قارنا بين **أربع استراتيجيات تحميل**:
+
+| الاستراتيجية           | بدون فضاء أسماء (عام)                          | مع فضاء أسماء (محدد/scoped)                                           |
+| :--------------------- | :--------------------------------------------- | :-------------------------------------------------------------------- |
+| **التحميل الثابت**     | **Static**: كل شيء في الذاكرة عند بدء التشغيل. | **Scoped static**: مقسم حسب فضاء الأسماء؛ يتم تحميل كل شيء عند البدء. |
+| **التحميل الديناميكي** | **Dynamic**: تحميل عند الطلب حسب اللغة.        | **Scoped dynamic**: تحميل دقيق حسب فضاء الأسماء واللغة.               |
+
+## ملخص الاستراتيجيات
+
+- **ثابت (Static)**: بسيط؛ لا يوجد تأخير في الشبكة بعد التحميل الأولي. الجانب السلبي: حجم حزمة كبير.
+- **ديناميكي (Dynamic)**: يقلل الوزن الأولي (تحميل كسول). مثالي عندما يكون لديك العديد من اللغات.
+- **ثابت بنطاق (Scoped static)**: يحافظ على تنظيم الكود (فصل منطقي) بدون طلبات شبكة إضافية معقدة.
+- **ديناميكي بنطاق (Scoped dynamic)**: أفضل نهج لتقسيم الكود والأداء. يقلل من استخدام الذاكرة عن طريق تحميل ما تحتاجه الرؤية الحالية واللغة النشطة فقط.
+
+### ما قمت بقياسه:
+
+قمت بتشغيل نفس التطبيق متعدد اللغات في متصفح حقيقي لكل تقنية، ثم سجلت ما تم نقله بالفعل عبر الشبكة والوقت الذي استغرقته الأمور. يتم الإبلاغ عن الأحجام **بعد ضغط الويب العادي**، لأن ذلك أقرب إلى ما يقوم الأشخاص بتنزيله بالفعل.
+
+- **حجم مكتبة التدويل**: بعد التجميع والتخلص من الكود غير المستخدم والتصغير، يكون حجم مكتبة i18n هو حجم كود المزودين (providers) والمكونات البرمجية (composables) في مكون فارغ. لا يشمل ذلك تحميل ملفات الترجمة. إنه يوضح مدى "تكلفة" المكتبة قبل دخول المحتوى الخاص بك.
+
+- **JavaScript لكل صفحة**: لكل مسار في التقييم، مقدار البرامج النصية التي يسحبها المتصفح لتلك الزيارة، بمتوسط عبر الصفحات في المجموعة (وعبر اللغات). الصفحات الثقيلة هي صفحات بطيئة.
+
+- **التسرب من اللغات الأخرى (Leakage)**: هو محتوى نفس الصفحة ولكن بلغة أخرى يتم تحميله بالخطأ في الصفحة التي يتم فحصها. هذا المحتوى غير ضروري ويجب تجنبه (مثلاً: محتوى صفحة `/fr/about` في حزمة صفحة `/en/about`).
+
+- **التسرب من المسارات الأخرى**: نفس الفكرة لـ **الشاشات الأخرى** في التطبيق: ما إذا كانت نصوصها مرافقة عندما تفتح صفحة واحدة فقط. (مثلاً: محتوى صفحة `/en/about` في حزمة صفحة `/en/contact`). تشير النتيجة العالية إلى ضعف التقسيم أو الحزم الواسعة جدًا.
+
+- **متوسط حجم حزمة المكون**: يتم قياس عناصر واجهة المستخدم الشائعة **واحدًا تلو الآخر** بدلاً من الاختباء داخل رقم تطبيق عملاق واحد. يوضح ما إذا كان التدويل يضخم المكونات اليومية بهدوء. على سبيل المثال، إذا تمت إعادة ريندر المكون الخاص بك، فسيقوم بتحميل كل تلك البيانات من الذاكرة. إرفاق ملف JSON عملاق بأي مكون يشبه ربط مخزن كبير من البيانات غير المستخدمة التي ستؤدي إلى إبطاء أداء مكوناتك.
+
+- **استجابة تبديل اللغة**: أقوم بتبديل اللغة باستخدام أداة التحكم الخاصة بالتطبيق وأحسب الوقت المستغرق حتى تتحول الصفحة بوضوح، وهو ما سيلاحظه الزائر.
+
+- **عمل الريندر بعد تغيير اللغة**: متابعة أكثر دقة: مقدار الجهد الذي بذلته الواجهة لإعادة الرسم للغة الجديدة بمجرد بدء التبديل. مفيد عندما يختلف الوقت "المحسوس" وتكلفة الإطار العملي.
+
+- **وقت تحميل الصفحة الأولي**: من التنقل حتى يعتبر المتصفح الصفحة محملة بالكامل للسيناريوهات التي اختبرتها. جيد لمقارنة البدايات الباردة.
+
+- **وقت الهيدرة (Hydration)**: الوقت الذي يقضيه العميل في تحويل HTML الخادم إلى واجهة تفاعلية. تعني الشرطة في الجداول أن هذا التنفيذ لم يوفر رقم هيدرة موثوقًا به في هذا التقييم.
+
+## النتائج بالتفصيل
+
+### 1 — حلول يجب تجنبها
+
+> لا يوجد حل واضح يجب تجنبه في نظام Vue البيئي.
+
+### 2 — حلول مقبولة
+
+**(vue-i18n)** (`vue-i18n@11.4.0`):
+
+- **vue-i18n** هي بدون منازع مكتبة i18n الأكثر استخدامًا لـ Vue، فهي تحتوي على الكثير من الميزات ونظام بيئي ضخم. ولكن تحت الغطاء، الحل ثقيل نوعًا ما. حتى لو قامت vue-i18n بدمج التحميل الكسول للرسائل، فإنها تفتقر إلى ميزة النطاق (scoping). في حالة تطبيق Vue SPA كلاسيكي، لا توجد مشكلة، ولكن بالنسبة لتطبيق Nuxt، باستخدام @nuxt/i18n، فإنه يؤدي إلى تضمين الرسائل من جميع الصفحات في صفحة واحدة. بالنسبة لتطبيق Nuxt كبير يضم أكثر من 10 صفحات، يمكن أن يصبح الأمر إشكاليًا حقًا.
+
+الحزمة ثقيلة جدًا (~24.3kb، أي حوالي 9 أضعاف `vue-intlayer`).
+
+**(fluent-vue)** (`fluent-vue@0.5.0`):
+
+- **fluent-vue** يقدم محاولة ابتكار من خلال تنسيق .ftl. تنظيم الرسائل رائع، وأسهل في البدء. ولكن في الممارسة العملية، يؤدي نقص سلامة النوع إلى زيادة خطر الخطأ ويمكن أن يصبح استهلاك الوقت في تصحيح الأخطاء سريعًا. علاوة على ذلك، يقوم هذا الحل بتحميل الرسائل باستخدام مكون vite الإضافي الذي يفرض تحميل كل المحتوى بجميع اللغات في كل صفحة. بالإضافة إلى ذلك، هذا حل ثقيل للغاية (~92.7kb، أي حوالي 34 ضعف `vue-intlayer`).
+
+### 3 — التوصيات
+
+**(Intlayer)** (`vue-intlayer@8.7.12`):
+
+لن أحكم شخصيًا على `vue-intlayer` من أجل الموضوعية، لأنه الحل الخاص بي.