Statisches vs. dynamisches Rendering mit i18n in Next.js

    Das Problem mit next-intl

    • Was passiert? Wenn Sie useTranslations, getTranslations oder einen anderen next-intl-Helfer innerhalb einer Server-Komponente in einer i18n-gerouteten App (/en/…, /fr/…) verwenden, markiert Next.js die gesamte Route als dynamisch. ([Next Intl][1])

    • Warum? next-intl liest die aktuelle Locale aus einem nur bei der Anfrage verfügbaren Header (x-next-intl-locale) über headers() aus. Da headers() eine dynamische API ist, verliert jede Komponente, die darauf zugreift, die statische Optimierung. ([Next Intl][1], [Next.js][2])

    • Offizieller Workaround (Boilerplate)

      1. Exportieren Sie generateStaticParams mit jeder unterstützten Locale.
      2. Rufen Sie setRequestLocale(locale) in jedem Layout/Seite vor dem Aufruf von useTranslations auf. ([Next Intl][1]) Dies entfernt die Abhängigkeit vom Header, aber Sie haben nun zusätzlichen Code zu pflegen und eine instabile API in der Produktion.

    Wie intlayer das Problem umgeht

    Designentscheidungen

    1. Nur Routen-Parameter – Die Locale stammt aus dem [locale] URL-Segment, das Next.js bereits an jede Seite übergibt.
    2. Kompilierungszeit-Bundles – Übersetzungen werden als reguläre ES-Module importiert, sodass sie baumgeschüttelt und zur Build-Zeit eingebettet werden.
    3. Keine dynamischen APIs – useT() liest aus dem React-Kontext, nicht aus headers() oder cookies().
    4. Keine zusätzliche Konfiguration – Sobald Ihre Seiten unter app/[locale]/ liegen, rendert Next.js automatisch eine HTML-Datei pro Locale vor.