---
createdAt: 2025-05-20
updatedAt: 2025-06-29
title: Статическая и динамическая отрисовка с i18n в Next.js
description: Узнайте, как использовать статическую и динамическую отрисовку с i18n в Next.js.
keywords:
- статическая
- динамическая
- отрисовка
- i18n
- next.js
- next-intl
- intlayer
- фреймворк
- middleware
- конфигурация
slugs:
- frequent-questions
- 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()` - это **динамический 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-файл для каждой локали.