Rendu statique vs dynamique avec i18n dans Next.js
Le problème avec next-intl
Que se passe-t-il ? Lorsque vous utilisez useTranslations, getTranslations ou tout autre helper next-intl à l'intérieur d'un composant serveur dans une application routée i18n (/en/…, /fr/…), Next.js marque toute la route comme dynamique. ([Next Intl][1])
Pourquoi ? next-intl recherche la locale actuelle à partir d'un en-tête disponible uniquement dans la requête (x-next-intl-locale) via headers(). Comme headers() est une API dynamique, tout composant qui l'utilise perd l'optimisation statique. ([Next Intl][1], [Next.js][2])
Solution officielle (boilerplate)
- Exporter generateStaticParams avec toutes les locales supportées.
- Appeler setRequestLocale(locale) dans chaque layout/page avant d'appeler useTranslations. ([Next Intl][1]) Cela supprime la dépendance à l'en-tête, mais vous avez maintenant du code supplémentaire à maintenir et une API instable en production.
Comment intlayer contourne le problème
Choix de conception
- Paramètre de route uniquement – La locale provient du segment d'URL [locale] que Next.js transmet déjà à chaque page.
- Bundles à la compilation – Les traductions sont importées comme des modules ES classiques, elles sont donc optimisées par élimination des codes morts (tree-shaken) et intégrées lors de la compilation.
- Pas d’API dynamiques – useT() lit depuis le contexte React, pas depuis headers() ou cookies().
- Aucune configuration supplémentaire – Une fois que vos pages résident sous app/[locale]/, Next.js pré-rend automatiquement un fichier HTML par locale.