---
createdAt: 2025-05-20
updatedAt: 2025-06-29
title: العرض الثابت مقابل العرض الديناميكي مع i18n في Next.js
description: تعلم كيفية استخدام العرض الثابت مقابل العرض الديناميكي مع i18n في Next.js.
keywords:
  - ثابت
  - ديناميكي
  - العرض
  - i18n
  - next.js
  - next-intl
  - intlayer
  - إطار عمل
  - وسيط
  - التهيئة
slugs:
  - doc
  - faq
  - 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 واحد لكل لغة تلقائيًا.
