العرض الثابت مقابل العرض الديناميكي مع 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 واحد لكل لغة تلقائيًا.