@intlayer/docs 9.5.6 → 9.5.8

package/blog/ar/next-intl_vs_intlayer-next-intl.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "next-intl مقابل @intlayer/next-intl: نفس الواجهة البرمجية، حزمة مختلفة"
 description: ما الذي يتغير عندما يتم تقديم واردات next-intl من تطبيق Next.js بواسطة محول التوافق @intlayer/next-intl. تم قياس حجم الحزمة والتسرب وحجم المكون والترطيب على نفس الكود، بالإضافة إلى ما يحتفظ به المحول ويتجاهله ولا يمكنه الاستبدال.
 keywords:
@@ -26,6 +26,8 @@ author: aymericzip
 
 # next-intl مقابل @intlayer/next-intl | نفس الواجهة البرمجية، حزمة مختلفة
 
+![next-intl VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 `@intlayer/next-intl` هو محول توافقية: يكشف API `next-intl` (`useTranslations`، `getTranslations`، `useLocale`، `t.rich()`، ICU plurals، `NextIntlClientProvider`...) ويقدمه من القواميس المجمعة بواسطة Intlayer. كود التطبيق لا يتغير. الـ bundle يتغير.
 
 تقارن هذه المقالة بين الاثنين على نفس تطبيق Next.js، تم بناؤه مرة مع `next-intl` ومرة مع المحول. تأتي الأرقام من [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom)، مجموعة مفتوحة المصدر تسجل ما يقوم المتصفح بتنزيله فعلياً. إذا كنت تريد مقارنة `next-intl` مقابل Intlayer كمكتبات، اقرأ [next-intl vs Intlayer](https://intlayer.org/blog/next-intl-vs-intlayer). هذا يتعلق بما يغيره المحول عندما تحافظ على مكوناتك كما هي.
@@ -109,6 +111,10 @@ const AboutPage = () => {
 
 ### النتائج على Next.js
 
+اختر المقاييس والمكتبات التي تهمك:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | الإعداد                   | الاستراتيجية   | حجم المكتبة (gz) | متوسط صفحة JS (gz) | تسرب Locale | تسرب الصفحة | متوسط المكون (gz) | التفاعل E2E | الماء (Hydration) |
 | ------------------------- | -------------- | ---------------: | -----------------: | ----------: | ----------: | ----------------: | ----------: | ----------------: |
 | **base** (no i18n)        | -              |           0.0 KB |           141.0 KB |        0.0% |        0.0% |            0.9 KB |     13.4 ms |           11.8 ms |
@@ -129,6 +135,15 @@ const AboutPage = () => {
 - **الـ Hydration أسرع بمقدار 2 ms** (12.8 مقابل 14.7 ms): لا توجد كائن رسائل يجب فكّه من حمولة RSC قبل أن يتمكن React من الـ hydrate.
 - **المحول ليس وقت التشغيل الأصلي.** `next-intlayer` يجلس عند **141.3 KB**، +0.3 KB فوق تطبيق الأساس، مع وقت تشغيل 5.5 KB. يحمل المحول سطح API الخاص بـ `next-intl` (`useFormatter`, `t.rich`, محلل ICU) فوق نواة Intlayer، وبالتالي 8.0 KB و +6 KB لكل صفحة. إنه الجسر، وليس الوجهة.
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-nextjs.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> الجدول الكامل، لكل مكتبة واستراتيجية، في [تقرير قياس أداء Next.js](https://intlayer.org/ar/doc/benchmark/nextjs).
+
 ### النتائج على TanStack Start (`use-intl`)
 
 `use-intl` هو النواة المستقلة عن الإطار العمل الخاصة بـ `next-intl`. محولها، `@intlayer/use-intl`، يتبع نفس التصميم مع plugin Vite (`@intlayer/use-intl/plugin`).
@@ -152,11 +167,24 @@ const AboutPage = () => {
 - **تبديل اللغة أسرع.** إعدادات `use-intl` المُحسَّنة تستغرق **13-21 ms** لتحديث `html[lang]`؛ المحول يستغرق **4-9 ms**. عدد أقل من المكونات يعاد تصيير، ولا شيء يتم اختياره مرة أخرى من شجرة الرسائل.
 - **`static` يحتفظ بكل لغة.** صف `static` في المحول يُظهر تسرب لغة بنسبة 49.7%، نفس نسبة Intlayer الأصلية في وضع `static`: يتم تجميع جميع اللغات، فقط قواميس الصفحة. سطر واحد من الإعدادات (`importMode: 'dynamic'`) يزيله.
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-tanstack.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> الجدول الكامل في [تقرير قياس أداء TanStack Start](https://intlayer.org/ar/doc/benchmark/tanstack).
+
 ## لماذا تتحرك الأرقام
 
+![The Intlayer compiler extracts content from components](https://github.com/aymericzip/intlayer/blob/main/docs/assets/compiler.webp?raw=true)
+
 لم يتغير شيء في المكون، لذا تأتي المكاسب بالكامل من ما هو `useTranslations` مرتبطة به.
 
-**مع `next-intl`**، الربط هو مع المزود. يتلقى `NextIntlClientProvider` كائن `messages` كاملًا للإعدادات المحلية؛ كل استدعاء `useTranslations("about")` يقرأ منه. يرى bundler مكونًا واحدًا يستورد hook واحدًا يقرأ سياقًا واحدًا، ولا يمكنه معرفة أن فرع `about` فقط هو المستخدم. تشارك المسارات أدناه نفس كائن الرسائل، لذلك يقرأ عمود تسرب الصفحة ~90% حتى تقسم الملف بنفسك.
+**مع `next-intl`**، الربط هو مع المزود. يتلقى `NextIntlClientProvider` كائن `messages` كاملًا للإعدادات المحلية؛ كل استدعاء `useTranslations("about")` يقرأ منه. يرى bundler مكونًا واحدًا يستورد hook واحدًا يقرأ سياقًا واحدًا، ولا يمكنه معرفة أن فرع `about` فقط هو المستخدم. تشارك المسارات أدناه نفس كائن الرسائل، لذلك يقرأ عمود تسرب الصفحة ~90% حتى تقسم الملف بنفسك, ويتزايد الهدر على محورين في وقت واحد، الصفحات واللغات:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
 
 ```bash
 .
@@ -280,25 +308,106 @@ export default withIntlayer(nextConfig);
 
 ## الحدود التي يجب أن تعرفها قبل البدء
 
-- **يتم نقل إعدادات التوجيه إلى `intlayer.config.ts`.** تحتفظ دوال `createNavigation(routing)` و `createMiddleware(routing)` بتوقيعها لكنها تتجاهل الوسيط: تأتي locales واللغة الافتراضية واستراتيجية البادئة من إعدادات `routing` في Intlayer. إذا كنت تستخدم `pathnames` الموضعية في `next-intl` (`/about` → `/a-propos`)، فإن المحول لا يقوم بالاستيفاء؛ `routing.rewrite` في Intlayer يغطي هذه الحالة لكنها تغيير منفصل.
-- **`useTranslations()` بدون مساحة اسم غير مرتبط.** تحتاج مرحلة التحسين إلى مساحة اسم ثابتة لمعرفة أي قاموس يجب استيراده. لا يزال الاستدعاء الأساسي يعمل، من خلال سجل وقت التشغيل الذي يشير إلى كل قاموس، وهو بالضبط التسرب الذي كنت تحاول إزالته. مرر مساحة الاسم.
-- **المحول ليس مجانيًا.** 8.0 كيلوبايت من وقت التشغيل مقابل 5.5 كيلوبايت لـ `next-intlayer`، و+6-7 كيلوبايت لكل صفحة فوق البناء الأصلي. يغطي سطح API `next-intl`. إذا وصلت إلى نقطة حيث تم نقل كل مكون إلى `useIntlayer`، أسقط المحول.
-- **`messages`, `timeZone`, `now` على المزود يتم تجاهلها.** يتم دعم المنسقات بواسطة `Intl` الأصلي والإعدادات المحلية فقط تؤثر على مخرجاتها؛ إذا كنت تعتمد على منطقة زمنية مفروضة أو `now` ثابتة لتواريخ مستقرة من حيث الترطيب، فتعامل معها في موقع الاستدعاء.
+<AccordionGroup>
+<Accordion header="تنتقل إعدادات التوجيه إلى intlayer.config.ts">
+
+تحتفظ `createNavigation(routing)` و `createMiddleware(routing)` بتوقيعها ولكنها تتجاهل الوسيط: اللغات، واللغة الافتراضية، واستراتيجية البادئة تأتي من إعدادات `routing` في Intlayer. وإذا كنت تستخدم مسارات `pathnames` المترجمة في `next-intl` (`/about` إلى `/a-propos`)، فإن المحول لا يستنبطها؛ بينما يغطي `routing.rewrite` في Intlayer تلك الحالة ولكنه تغيير منفصل.
+
+</Accordion>
+<Accordion header="useTranslations() بدون مساحة أسماء ليست مرتبطة">
+
+تحتاج مرحلة التحسين إلى مساحة أسماء ثابتة لمعرفة أي قاموس يجب استيراده. الاستدعاء البسيط بدون مساحة أسماء يستمر في العمل عبر سجل وقت التشغيل الذي يشير إلى كل قاموس، وهو بالضبط التسريب الذي تحاول التخلص منه. قم بتمرير مساحة الاسم.
+
+</Accordion>
+<Accordion header="المحول ليس مجانياً من حيث الحجم">
+
+8.0 كيلوبايت لوقت التشغيل مقابل 5.5 كيلوبايت لـ `next-intlayer`، و +6-7 كيلوبايت لكل صفحة مقارنة بالبناء الأصلي. هذا هو ثمن توفير واجهة برمجة تطبيقات `next-intl`. وعندما يتم نقل كل مكون إلى `useIntlayer`، قم بإزالة المحول.
+
+</Accordion>
+<Accordion header="يتم تجاهل messages و timeZone و now في المزود">
+
+تعتمد أدوات التنسيق على `Intl` الأصلي وتؤثر اللغة فقط على مخرجاتها. إذا كنت تعتمد على منطقة زمنية مفروضة أو قيمة `now` ثابتة لتواريخ مستقرة أثناء الـ Hydration، فتعامل مع ذلك في موضع الاستدعاء. راجع [تنسيق التاريخ والوقت والأرقام](https://intlayer.org/ar/blog/date-time-number-formatting-locales).
+
+</Accordion>
+</AccordionGroup>
 
 ## متى تستخدم أيًا منها؟
 
-- **ابقَ على `next-intl`** إذا كان تطبيقك صغيرًا، والحزمة ليست مصدر قلق، وفريقك مرتاح لامتلاك المساحات والقيام بـ `pick()` لكل صفحة.
-- **استخدم `@intlayer/next-intl`** إذا كنت تستخدم `next-intl` حالياً وتريد تحسينات الحزمة والتسرب والتنويم، والمفاتيح المكتوبة بشكل صحيح وأدوات CLI / CMS دون إعادة كتابة. هذه هي نقطة الدخول الموصى بها لأي codebase `next-intl` موجود.
-- **استخدم المحلل الأصلي (`next-intlayer`)** للمشاريع الجديدة، أو بعد انتهاء المحول من مهمته. إنها الأخف من بين الثلاثة (5.5 KB، +0.3 KB لكل صفحة) وتفتح مكونات الخادم المتزامنة وملفات `.content.ts` لكل مكون ومجموعة الميزات الكاملة.
+<AccordionGroup>
+<Accordion header="البقاء على next-intl">
+
+إذا كان تطبيقك صغيراً، وحجم الحزمة لا يشكل مصدر قلق، وفريقك مرتاح في إدارة مساحات الأسماء و `pick()` لكل صفحة.
+
+</Accordion>
+<Accordion header="استخدام @intlayer/next-intl">
+
+أنت تستخدم `next-intl` اليوم وتريد مكاسب الحزمة ومنع التسريب والـ Hydration السريع والمفاتيح المكتوبة وأدوات CLI / CMS دون الحاجة إلى إعادة كتابة الكود. هذه هي نقطة البداية الموصى بها لأي قاعدة كود `next-intl` حالية.
+
+</Accordion>
+<Accordion header="الانتقال إلى الحل الأصلي (next-intlayer)">
+
+للمشاريع الجديدة، أو بمجرد أن يكمل المحول مهمته الانتقالية. إنه الأخف بين الخيارات الثلاثة (5.5 كيلوبايت، +0.3 كيلوبايت لكل صفحة) ويفعل مكونات الخادم المتزامنة، وملفات `.content.ts` لكل مكون، وكامل مجموعة الميزات. ابدأ مع [Intlayer مع Next.js](https://intlayer.org/ar/doc/environment/nextjs).
+
+</Accordion>
+</AccordionGroup>
+
+## الأسئلة الشائعة
+
+<FAQ>
+
+<Question title="هل يظل كود تطبيقي دون أي تعديل بالفعل؟">
+
+في Next.js، نعم بالنسبة للمكونات: عدل بناء الاختبار `next.config.ts` و `intlayer.config.ts` فقط. وتصبح `getRequestConfig` في `src/i18n.ts`، وخاصية `messages` في المزود، واستدعاءات `pick()` لكل صفحة بمثابة كود غير مستخدم يمكنك حذفه لاحقاً.
+
+</Question>
+
+<Question title="ماذا يحدث لرسائل ICU؟">
+
+تستمر في العمل. يتم حل `t("key", { count })` و `t.rich()` و `t.markup()` و `select` و `selectordinal` و `#` و `{ts, date, long}` بواسطة محلل ICU الخاص بـ Intlayer. راجع [تنسيق رسائل ICU](https://intlayer.org/ar/blog/icu-message-format).
+
+</Question>
+
+<Question title="لماذا المحول أثقل من next-intlayer الأصلي؟">
+
+لأنه يحمل واجهة برمجة تطبيقات `next-intl` فوق نواة Intlayer: `useFormatter` و `t.rich` ومحلل ICU ومساعدات التنقل. وهذا يعادل 8.0 كيلوبايت مقابل 5.5 كيلوبايت، و +6 كيلوبايت لكل صفحة. إنه جسر عبور وليس الوجهة النهائية.
+
+</Question>
+
+<Question title="هل يمكنني الترحيل مكوناً تلو الآخر؟">
+
+نعم. يمكن لأي مكون الانتقال من `useTranslations("about")` إلى `useIntlayer("about")` مع ملف `.content.ts` مجاور له. تتعايش قواميس JSON و `.content.ts` وتندمج بسلاسة.
+
+</Question>
+
+<Question title="هل تعمل أسماء المسارات المترجمة (pathnames)؟">
+
+ليس من خلال `pathnames` الخاصة بـ `next-intl`: يقبلها المحول لغرض التحقق من الأنواع فقط ولكنه لا يستنبطها. استخدم بدلاً من ذلك `routing.rewrite` من Intlayer.
+
+</Question>
+
+</FAQ>
 
 ## المقارنات ذات الصلة
 
-- [next-intl vs Intlayer](https://intlayer.org/blog/next-intl-vs-intlayer) (المكتبات، نفس المعيار)
-- [i18next vs @intlayer/i18next](https://intlayer.org/blog/i18next-vs-intlayer-i18next) (نفس سلسلة المحول)
-- [Lingui vs @intlayer/lingui](https://intlayer.org/blog/lingui-vs-intlayer-lingui) (نفس سلسلة المحول)
-- [vue-i18n vs @intlayer/vue-i18n](https://intlayer.org/blog/vue-i18n-vs-intlayer-vue-i18n) (نفس سلسلة المحول)
-- [دليل الهجرة: next-intl إلى Intlayer](https://intlayer.org/doc/migration/next-intl)
-- [مرجع محول التوافقية: next-intl](https://intlayer.org/doc/compatibility/next-intl)
+نفس سلسلة المحولات:
+
+- [i18next vs @intlayer/i18next](https://intlayer.org/ar/blog/i18next-vs-intlayer-i18next)
+- [Lingui vs @intlayer/lingui](https://intlayer.org/ar/blog/lingui-vs-intlayer-lingui)
+- [vue-i18n vs @intlayer/vue-i18n](https://intlayer.org/ar/blog/vue-i18n-vs-intlayer-vue-i18n)
+
+مقارنة مباشرة بين المكتبات:
+
+- [next-intl vs Intlayer](https://intlayer.org/ar/blog/next-intl-vs-intlayer), نفس الاختبار المرجعي
+- [next-i18next vs next-intl vs Intlayer](https://intlayer.org/ar/blog/next-i18next-vs-next-intl-vs-intlayer)
+- [Is next-intl outdated?](https://intlayer.org/ar/blog/is-next-intl-outdated)
+
+وثائق مرجعية:
+
+- [Compat adapter: next-intl](https://intlayer.org/ar/doc/compatibility/next-intl)
+- [دليل الترحيل: من next-intl إلى Intlayer](https://intlayer.org/ar/doc/migration/next-intl)
+- [تقرير قياس أداء Next.js](https://intlayer.org/ar/doc/benchmark/nextjs) و [تقرير قياس أداء TanStack Start](https://intlayer.org/ar/doc/benchmark/tanstack)
+- [تحسين الحزمة](https://intlayer.org/ar/doc/concept/bundle-optimization) و [مترجم Intlayer](https://intlayer.org/ar/doc/compiler)
+- [المحرر المرئي](https://intlayer.org/ar/doc/concept/editor)، [نظام إدارة المحتوى CMS](https://intlayer.org/ar/doc/concept/cms) و [الترجمة بالذكاء الاصطناعي](https://intlayer.org/ar/doc/concept/auto-fill)
 
 ## الخلاصة
 

package/blog/ar/next-intl_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "next-intl مقابل Intlayer: معيار ومقارنة 2026"
 description: "مقارنة دقيقة بين next-intl وIntlayer على Next.js App Router وTanStack Start. حجم الحزمة، تسرب المحتوى، حجم المكونات، وسرعة تبديل اللغة وتجربة المطور."
 keywords:
@@ -22,15 +22,15 @@ author: aymericzip
 
 # next-intl مقابل Intlayer | مقارنة أداء التدويل (i18n) في React وNext.js
 
-مكتبة `next-intl` هي الخيار الافتراضي لتدويل تطبيقات Next.js App Router اليوم: تكامل محكم مع التوجيه، دعم كامل لـ ICU MessageFormat، وتجربة مطور مألوفة لأي شخص استخدم أنظمة i18n الكلاسيكية.
+![next-intl VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
 
-أما `Intlayer` فتعيد التفكير في المشكلة من أساسها: لا توجد قواميس مركزية، ولا حاجة لمطابقة مساحات الأسماء (namespaces) مع المسارات يدوياً. يتم الإعلان عن المحتوى بجانب كل مكون، بينما يتكفل مترجم وقت البناء بحزم ما تحتاجه كل صفحة فقط.
+مكتبة `next-intl` هي أكثر مكتبات i18n شيوعاً لـ Next.js. وتعتبر Intlayer بديلاً قائماً على المترجم بنطاق محدد على مستوى المكونات. كلاهما يقدم حلول التدويل لتطبيقات App Router. والسؤال الأهم هو ما تكلفة كل منهما بمجرد بناء التطبيق.
 
-تقارن هذه المقالة المكتبتين بناءً على بيانات مستخرجة من [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom)، وهو مشروع اختبار مفتوح المصدر يبني التطبيق نفسه مع كل مكتبة ويسجل ما يقوم المتصفح بتنزيله وتنفيذه فعلياً.
+هذا المقال ليس دليلاً تعليمياً، بل هو مقارنة مدعومة بالأرقام من [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom)، وهو مشروع اختبار مفتوح المصدر يبني التطبيق نفسه مع كل مكتبة ويقيس ما يقوم المتصفح بتنزيله وتنفيذه فعلياً.
 
 <TOC/>
 
-> **باختصار (tl;dr)**: تضيف `next-intl` ما لا يقل عن **+12.6 كيلوبايت gzip** في كل صفحة لمجرد وقت التشغيل (runtime)، وتسرب **~90% من سلاسل الصفحات الأخرى** في إعداداتها القياسية (`static` و`dynamic`). يتطلب التخلص من هذا التسرب تقسيم الكتالوجات إلى مساحات أسماء واختيارها يدوياً لكل صفحة، وهي مهمة معقدة يتجنبها معظم المطورين. في المقابل، يضمن مترجم `Intlayer` تسريباً بنسبة **0%**، ومكونات أصغر **بثلاث مرات**، و**+0.3 كيلوبايت** فقط فوق التطبيق الأساسي، كل ذلك بدون أي إعدادات يدوية إضافية.
+> **tl;dr**: في نفس تطبيق Next.js، تضيف `next-intl` **+12.6 كيلوبايت gzip** من JavaScript على كل صفحة، مقابل **+0.3 كيلوبايت** لـ Intlayer. دون أي عمل إضافي، ترسل `next-intl` **~90% من سلاسل الصفحات الأجنبية** مع كل صفحة. يتطلب الوصول إلى تسريب بنسبة 0% مع `next-intl` تحديد نطاقات مساحات الأسماء واستخدام `pick(messages, [...])` لكل صفحة. بينما تصل Intlayer إلى 0% افتراضياً لأن مترجمها يحدد نطاق المحتوى لكل مكون. وإذا كنت تريد واجهة برمجة تطبيقات `next-intl` مع مخرجات Intlayer، فقد سجل محول `@intlayer/next-intl` **147.5 كيلوبايت** لكل صفحة مقابل **153.6 كيلوبايت** مع المكتبة الأصلية.
 
 ## نظرة عامة
 
@@ -89,6 +89,10 @@ author: aymericzip
 
 ### النتائج على Next.js (App Router)
 
+اختر المقاييس والمكتبات التي تهمك:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | المكتبة                       | الاستراتيجية   | حجم المكتبة (gz) | متوسط JS للصفحة (gz) | تسرب اللغة | تسرب الصفحة | متوسط المكون (gz) | تفاعلية E2E | الترطيب |
 | ----------------------------- | -------------- | ---------------: | -------------------: | ---------: | ----------: | ----------------: | ----------: | ------: |
 | **base** (بدون i18n)          | -              |           0.0 KB |             141.0 KB |       0.0% |        0.0% |            0.9 KB |     13.4 ms | 11.8 ms |
@@ -107,8 +111,19 @@ author: aymericzip
 - **التسريب.** في الإعدادين الأكثر استخداماً (`static` و`dynamic`)، ترسل `next-intl` ما يقرب من **~90% من سلاسل الصفحات الأخرى** في كل صفحة، لأن ملف `en.json` كاملاً يدخل في مزود العميل. يتطلب الوصول إلى 0% تقسيماً يدوياً دقيقاً. أما Intlayer فيحقق 0% تلقائياً.
 - **حجم المكون.** المكون الذي يستدعي `useTranslations()` يُترجم في المتوسط إلى 21.8 كيلوبايت؛ والمكون نفسه مع `useIntlayer()` يبلغ 6.9 كيلوبايت فقط. وفي وضع `scoped-static` تقفز مكونات `next-intl` إلى 80.1 كيلوبايت لأن كل مكون يُضمن مساحة أسمائه داخلياً.
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-nextjs.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> الجدول الكامل، لكل مكتبة واستراتيجية، في [تقرير قياس أداء Next.js](https://intlayer.org/ar/doc/benchmark/nextjs).
+
 ### النتائج على TanStack Start (`use-intl`)
 
+تعتبر `use-intl` النواة المستقلة عن أي إطار عمل لمكتبة `next-intl`. نفس واجهة برمجة التطبيقات ونفس تنسيق الرسائل. مقارنتها مع `intlayer` على TanStack Start تزيل العوامل الخاصة بـ Next.js من المعادلة.
+
 | المكتبة                      | الاستراتيجية   | حجم المكتبة (gz) | متوسط JS للصفحة (gz) | تسرب اللغة | تسرب الصفحة | متوسط المكون (gz) | تفاعلية E2E |
 | ---------------------------- | -------------- | ---------------: | -------------------: | ---------: | ----------: | ----------------: | ----------: |
 | **base** (بدون i18n)         | -              |           0.0 KB |             111.0 KB |       0.0% |        0.0% |            0.7 KB |      8.1 ms |
@@ -127,8 +142,19 @@ author: aymericzip
 - يظهر الفارق المعماري بوضوح في **حجم المكونات**: 76-87 كيلوبايت مع `use-intl` مقابل 6-8 كيلوبايت مع Intlayer.
 - **تبديل اللغة** أسرع بمرتين إلى أربع مرات مع Intlayer (3 مللي ثانية مقابل 7-21 مللي ثانية).
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-tanstack.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> الجدول الكامل في [تقرير قياس أداء TanStack Start](https://intlayer.org/ar/doc/benchmark/tanstack).
+
 ## لماذا هذا الفارق؟ الكتالوجات المركزية مقابل القواميس المجمعة
 
+![Centralized catalogs versus per-component dictionaries](https://github.com/aymericzip/intlayer/blob/main/docs/assets/project_stucture_18n_vs_intlayer.png?raw=true)
+
 تتبع `next-intl` النموذج التقليدي: ملف JSON واحد لكل لغة، يُحمّل في `getRequestConfig`، ويُمرر إلى `NextIntlClientProvider`، ويُقرأ عبر `t("namespace.key")`.
 
 ```bash
@@ -150,6 +176,10 @@ author: aymericzip
 
 لا يمكن لوقت التشغيل معرفة المفاتيح التي ستستخدمها الصفحة فعلياً، لذا فإن الخيار الآمن هو إرسال الكتالوج بأكمله.
 
+تزداد تكلفة عدم الوصول إلى هناك على محورين في وقت واحد، الصفحات واللغات:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
+
 بينما تقلب Intlayer هذه المسؤولية؛ حيث يتم الإعلان عن المحتوى بجانب المكون المعني مباشرة:
 
 ```bash
@@ -177,7 +207,8 @@ author: aymericzip
 
 ### مكون العميل (Client Component)
 
-**next-intl**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-intl" value="next-intl">
 
 ```json fileName="messages/en.json"
 {
@@ -188,7 +219,7 @@ author: aymericzip
 }
 ```
 
-```tsx fileName="src/components/Counter.tsx"
+```tsx fileName="src/components/ClientCounter.tsx"
 "use client";
 
 import { useState } from "react";
@@ -210,7 +241,10 @@ export const Counter = () => {
 };
 ```
 
-**Intlayer**
+> تذكر تضمين مساحة الأسماء `counter` في الرسائل الممررة إلى `NextIntlClientProvider` في كل صفحة تعرض هذا المكون.
+
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/components/Counter/index.content.ts"
 import { t, type Dictionary } from "intlayer";
@@ -249,11 +283,16 @@ export const Counter = () => {
 };
 ```
 
+لا يوجد شيء لتسجيله في الصفحة: المكون يجلب محتواه الخاص معه.
+
+</Tab>
+</Tabs>
 ### مكونات الخادم المتزامنة (Server Components)
 
 غالباً ما تكون عناصر واجهة المستخدم المشتركة (شريط التنقل، التذييل، البطاقات) مكونات خادم تُعرض كأبناء لمكونات العميل، لذا لا يمكن أن تكون غير متزامنة (`async`).
 
-**next-intl**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-intl" value="next-intl">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 type ServerCounterProps = {
@@ -269,7 +308,10 @@ export const ServerCounter = ({ t, formattedCount }: ServerCounterProps) => (
 );
 ```
 
-**Intlayer**
+يتعين على الصفحة استدعاء `await getTranslations("counter")` و `await getFormatter()`، ثم تمرير النتائج كـ props. لم يعد المكون مستقلاً بذاته.
+
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 import { useIntlayer } from "next-intlayer/server";
@@ -288,9 +330,12 @@ export const ServerCounter = ({ count }: { count: number }) => {
 };
 ```
 
+</Tab>
+</Tabs>
 ### البيانات الوصفية (Metadata)
 
-**next-intl**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-intl" value="next-intl">
 
 ```tsx fileName="src/app/[locale]/about/page.tsx"
 import type { Metadata } from "next";
@@ -323,7 +368,8 @@ export const generateMetadata = async ({
 };
 ```
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```tsx fileName="src/app/[locale]/about/page.tsx"
 import { getIntlayer, getMultilingualUrls } from "intlayer";
@@ -347,6 +393,9 @@ export const generateMetadata = async ({
 };
 ```
 
+</Tab>
+</Tabs>
+
 ## الاحتفاظ بـ API الخاص بـ next-intl مع مخرجات Intlayer
 
 لا يتعين عليك إعادة كتابة مكوناتك للحصول على أرقام الأداء الموضحة أعلاه. حزمة `@intlayer/next-intl` هي محول متوافق مباشرة: يحتفظ بـ `useTranslations` و`getTranslations` و`useFormatter` و`t.rich()` وصيغ الجمع في ICU، ويقدمها من قواميس Intlayer التي يترجمها مترجم Intlayer.
@@ -368,17 +417,84 @@ export default withIntlayer(nextConfig);
 
 ## متى تختار أياً منهما؟
 
-- **اختر next-intl** إذا كنت بحاجة إلى معيار مجتمع Next.js الواسع، أو تعتمد بشكل كبير على ICU MessageFormat، أو كان تطبيقك صغيراً إلى متوسط الحجم، أو كنت مدمجاً بالفعل مع منصات ترجمة مركزية (Crowdin، Phrase، Lokalise...).
-- **اختر Intlayer** إذا كنت تريد **محتوى بنطاق المكونات**، و**TypeScript صارماً**، و**أخطاء للمفاتيح المفقودة عند البناء**، و**تقليم الشجرة والتحميل الكسول دون أي جهد**، ومكونات خادم متزامنة، وأدوات تحرير مدمجة (محرر مرئي، CMS، ترجمة بالذكاء الاصطناعي، خادم MCP).
-- **اختر `@intlayer/next-intl`** إذا كنت تستخدم `next-intl` بالفعل وتريد مكاسب الحزمة والأداء دون إعادة كتابة التطبيق.
+<AccordionGroup>
+<Accordion header="اختر next-intl">
+
+أنت تريد معيار النظام البيئي لـ Next.js، وتعتمد على ICU MessageFormat، وتطبيقك صغير إلى متوسط الحجم، أو تتكامل مع منصة ترجمة (Crowdin، Phrase، Lokalise...) تتوقع ملفات JSON مركزية. خصص وقتاً لتقسيم الكتالوجات إلى مساحات أسماء واختيار الرسائل باستخدام `pick()` لكل صفحة إذا كان الأداء مهماً.
+
+</Accordion>
+<Accordion header="اختر Intlayer">
+
+تريد **محتوى مخصصاً لكل مكون**، و**TypeScript صارماً**، و**أخطاء المفاتيح المفقودة في وقت البناء**، و**tree-shaking والتحميل الكسول دون أي جهد إضافي**، ومكونات خادم متزامنة، وأدوات تحرير مدمجة ([المحرر المرئي](https://intlayer.org/ar/doc/concept/editor)، [نظام إدارة المحتوى CMS](https://intlayer.org/ar/doc/concept/cms)، [الترجمة بالذكاء الاصطناعي](https://intlayer.org/ar/doc/concept/auto-fill)، [خادم MCP](https://intlayer.org/ar/doc/mcp-server)). ملائم بشكل خاص لقواعد الكود الكبيرة والمعيارية وأنظمة التصميم.
+
+</Accordion>
+<Accordion header="اختر @intlayer/next-intl">
+
+أنت تستخدم بالفعل `next-intl` وتريد الحصول على مزايا حجم الحزمة دون إعادة كتابة الكود. يحافظ [محول التوافق](https://intlayer.org/ar/doc/compatibility/next-intl) على عمليات الاستيراد وملف `messages/{locale}.json` كمصدر وحيد للحقيقة. تم قياسه جنباً إلى جنب في [next-intl مقابل @intlayer/next-intl](https://intlayer.org/ar/blog/next-intl-vs-intlayer-next-intl).
+
+</Accordion>
+</AccordionGroup>
+
+## الأسئلة الشائعة
+
+<FAQ>
+
+<Question title="هل next-intl أبطأ من Intlayer؟">
+
+ليس في وقت العرض (Render time). الفرق يكمن في ما يتم إرساله إلى المتصفح: يضيف `next-intl` **+12.6 كيلوبايت gzip** من وقت التشغيل على كل صفحة، وفي معظم الإعدادات الشائعة، يرسل ~90% من سلاسل الصفحات الأجنبية مع كل صفحة. تبديل اللغة وتفعيل الـ Hydration متقاربان على Next.js (15-18 مللي ثانية)؛ وعلى TanStack Start، يستغرق `use-intl` من 7 إلى 21 مللي ثانية مقارنة بـ 3-4 مللي ثانية لـ Intlayer.
+
+</Question>
+
+<Question title="هل يمكنني الوصول إلى تسريب بنسبة 0% مع next-intl؟">
+
+نعم، باستخدام إعداد `scoped-dynamic`: قسّم `messages/{locale}.json` إلى مساحة أسماء لكل مسار، ثم استخدم `pick(messages, [...])` في كل صفحة وحافظ على صحة هذا التعيين مع تنقل المكونات. هذا هو الجهد الذي تعكسه صفوف `scoped-*` في الاختبار. يصل Intlayer إلى 0% بدون ذلك لأن المترجم يحدد نطاق المحتوى لكل مكون. راجع [تحسين الحزمة](https://intlayer.org/ar/doc/concept/bundle-optimization).
+
+</Question>
+
+<Question title="هل يجب علي إعادة كتابة مكوناتي للترحيل؟">
+
+لا. يحافظ `@intlayer/next-intl` على `useTranslations` و `getTranslations` و `useFormatter` و `t.rich()` وصيغ الجمع في ICU ومساعدات التنقل، ويقدمها من قواميس مجمعة بواسطة مترجم Intlayer. سطر إضافي واحد في `next.config.ts`. دليلك خطوة بخطوة في [دليل ترحيل next-intl](https://intlayer.org/ar/doc/migration/next-intl).
+
+</Question>
+
+<Question title="هل يدعم Intlayer تنسيق رسائل ICU؟">
+
+دعم ICU الأصلي قيد التطوير في واجهة برمجة التطبيقات الأساسية. لكن محولات التوافق (`@intlayer/next-intl`، `@intlayer/use-intl`) تدعم ICU بالكامل: صيغ الجمع، و `select`، و `selectordinal`، و `#` و `{ts, date, long}` تتم معالجتها عبر محلل ICU في Intlayer. اقرأ [تنسيق رسائل ICU](https://intlayer.org/ar/blog/icu-message-format) لمزيد من التفاصيل.
+
+</Question>
+
+<Question title="هل يمكنني الاحتفاظ بملفات messages/{locale}.json؟">
+
+نعم. يقرأها [المكون الإضافي لمزامنة JSON](https://intlayer.org/ar/doc/compatibility/next-intl)، ويقسم المفاتيح العليا إلى قواميس، ويكتب الترجمات مرة أخرى في نفس الملفات عندما تقوم أداة CLI أو CMS بتحديثها. سير عمل المترجمين لديك لن يتغير.
+
+</Question>
+
+</FAQ>
 
 ## مقارنات ذات صلة
 
-- [i18next مقابل Intlayer](https://intlayer.org/ar/blog/i18next-vs-intlayer) (الاختبار نفسه)
-- [Lingui مقابل Intlayer](https://intlayer.org/ar/blog/lingui-vs-intlayer) (الاختبار نفسه)
-- [vue-i18n مقابل Intlayer](https://intlayer.org/ar/blog/vue-i18n-vs-intlayer-benchmark) (الاختبار نفسه)
-- [next-i18next مقابل next-intl مقابل Intlayer](https://intlayer.org/ar/blog/next-i18next-vs-next-intl-vs-intlayer)
-- [هل أصبحت next-intl قديمة؟](https://intlayer.org/ar/blog/is-next-intl-outdated)
+نفس المقارنة المرجعية، مكتبات أخرى:
+
+- [i18next vs Intlayer](https://intlayer.org/ar/blog/i18next-vs-intlayer)
+- [Lingui vs Intlayer](https://intlayer.org/ar/blog/lingui-vs-intlayer)
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/ar/blog/vue-i18n-vs-intlayer-benchmark)
+- [next-i18next vs next-intl vs Intlayer](https://intlayer.org/ar/blog/next-i18next-vs-next-intl-vs-intlayer)
+- [react-i18next vs react-intl vs Intlayer](https://intlayer.org/ar/blog/react-i18next-vs-react-intl-vs-intlayer)
+
+المزيد حول next-intl:
+
+- [next-intl vs @intlayer/next-intl](https://intlayer.org/ar/blog/next-intl-vs-intlayer-next-intl), المحول المقاس على نفس التطبيق
+- [Is next-intl outdated?](https://intlayer.org/ar/blog/is-next-intl-outdated)
+- [Using Intlayer with next-intl](https://intlayer.org/ar/blog/intlayer-with-next-intl)
+- [How to internationalize a Next.js app with next-intl](https://intlayer.org/ar/blog/nextjs-internationalization-using-next-intl)
+
+وثائق مرجعية:
+
+- [تقرير قياس أداء Next.js](https://intlayer.org/ar/doc/benchmark/nextjs) و [تقرير قياس أداء TanStack Start](https://intlayer.org/ar/doc/benchmark/tanstack)
+- [محول التوافق: next-intl](https://intlayer.org/ar/doc/compatibility/next-intl) و [دليل الترحيل](https://intlayer.org/ar/doc/migration/next-intl)
+- [تحسين الحزمة](https://intlayer.org/ar/doc/concept/bundle-optimization) و [مترجم Intlayer](https://intlayer.org/ar/doc/compiler)
+- [i18n لكل مكون مقابل المركزية](https://intlayer.org/ar/blog/per-component-vs-centralized-i18n)
+- [i18n المعتمدة على المترجم مقابل التصريحية](https://intlayer.org/ar/blog/compiler-vs-declarative-i18n)
 
 ## نجوم GitHub