---
createdAt: 2025-05-20
updatedAt: 2025-06-29
title: العرض الثابت مقابل العرض الديناميكي مع i18n في Next.js
description: تعلم كيفية استخدام العرض الثابت مقابل العرض الديناميكي مع i18n في Next.js.
keywords:
- ثابت
- ديناميكي
- العرض
- i18n
- next.js
- next-intl
- intlayer
- إطار عمل
- وسيط
- التهيئة
slugs:
- frequent-questions
- static-rendering
---
# العرض الثابت مقابل العرض الديناميكي مع i18n في Next.js
## المشكلة مع **next-intl**
- **ماذا يحدث؟**
عندما تستخدم `useTranslations`، أو `getTranslations`، أو أي مساعد من next-intl _داخل مكون خادم_ في تطبيق موجه بـ i18n (`/en/…`، `/fr/…`)، يقوم Next.js بوضع علامة على المسار بأكمله كـ **ديناميكي**. ([Next Intl][1])
- **لماذا؟**
يبحث next-intl عن اللغة الحالية من خلال رأس خاص بالطلب فقط (`x-next-intl-locale`) عبر `headers()`. وبما أن `headers()` هي **واجهة برمجة تطبيقات ديناميكية**، فإن أي مكون يستخدمها يفقد التحسين الثابت. ([Next Intl][1]، [Next.js][2])
- **الحل الرسمي (النموذجي)**
1. تصدير `generateStaticParams` مع كل لغة مدعومة.
2. استدعاء `setRequestLocale(locale)` في **كل** تخطيط/صفحة _قبل_ استدعاء `useTranslations`. ([Next Intl][1])
هذا يزيل الاعتماد على الرأس، لكنك الآن لديك كود إضافي يجب صيانته وواجهة برمجة تطبيقات غير مستقرة في الإنتاج.
## كيف يتجنب **intlayer** المشكلة
**خيارات التصميم**
1. **معامل المسار فقط** – تأتي اللغة من جزء URL `[locale]` الذي يمرره Next.js بالفعل إلى كل صفحة.
2. **حزم وقت الترجمة** – تُستورد الترجمات كوحدات ES عادية، لذا يتم تقليلها (tree-shaken) وتضمينها أثناء وقت البناء.
3. **لا واجهات برمجة تطبيقات ديناميكية** – `useT()` يقرأ من سياق React، وليس من `headers()` أو `cookies()`.
4. **بدون إعدادات إضافية** – بمجرد أن تعيش صفحاتك تحت `app/[locale]/`، يقوم Next.js بإنشاء ملف HTML واحد لكل لغة تلقائيًا.