Статическая и динамическая отрисовка с 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() - это динамический API, любой компонент, который его использует, теряет статическую оптимизацию. ([Next Intl][1], [Next.js][2])

    • Официальное решение (шаблон)

      1. Экспортируйте generateStaticParams для каждой поддерживаемой локали.
      2. Вызывайте setRequestLocale(locale) в каждом layout/странице до вызова useTranslations. ([Next Intl][1]) Это устраняет зависимость от заголовка, но теперь у вас появляется дополнительный код для поддержки и нестабильный API в продакшене.

    Как intlayer обходит эту проблему

    Выбор архитектуры

    1. Только параметр маршрута – Локаль берется из сегмента URL [locale], который Next.js уже передает каждой странице.
    2. Пакеты на этапе компиляции – Переводы импортируются как обычные ES-модули, поэтому они подвергаются tree-shaking и встраиваются на этапе сборки.
    3. Отсутствие динамических API – useT() читает данные из контекста React, а не из headers() или cookies().
    4. Никакой дополнительной настройки – Как только ваши страницы находятся в папке app/[locale]/, Next.js автоматически предварительно рендерит один HTML-файл для каждой локали.