Statyczne vs dynamiczne renderowanie z i18n w Next.js

    Problem z next-intl

    • Co się dzieje? Gdy używasz useTranslations, getTranslations lub jakiegokolwiek helpera next-intl wewnątrz komponentu serwerowego w aplikacji z trasowaniem i18n (/en/…, /fr/…), Next.js oznacza całą trasę jako dynamiczną. ([Next Intl][1])

    • Dlaczego? next-intl odczytuje bieżący locale z nagłówka dostępnego tylko w żądaniu (x-next-intl-locale) za pomocą headers(). Ponieważ headers() jest dynamicznym API, każdy komponent, który z niego korzysta, traci optymalizację statyczną. ([Next Intl][1], [Next.js][2])

    • Oficjalne obejście (boilerplate)

      1. Eksportuj generateStaticParams dla każdego obsługiwanego locale.
      2. Wywołaj setRequestLocale(locale) w każdym layoucie/stronie przed wywołaniem useTranslations. ([Next Intl][1]) To usuwa zależność od nagłówka, ale teraz masz dodatkowy kod do utrzymania oraz niestabilne API w produkcji.

    Jak intlayer omija ten problem

    Wybory projektowe

    1. Tylko parametr trasy – Locale pochodzi z segmentu URL [locale], który Next.js już przekazuje do każdej strony.
    2. Pakiety w czasie kompilacji – Tłumaczenia są importowane jako zwykłe moduły ES, dzięki czemu są poddawane tree-shakingowi i osadzane podczas budowania.
    3. Brak dynamicznych API – useT() odczytuje dane z kontekstu React, a nie z headers() czy cookies().
    4. Zero dodatkowej konfiguracji – Gdy Twoje strony znajdują się pod app/[locale]/, Next.js automatycznie prerenderuje jeden plik HTML na locale.