Next.jsにおけるi18nの静的レンダリングと動的レンダリングの比較

next-intlに関する問題

• 何が起こるのか？ i18nルーティングされたアプリ（/en/…、/fr/…）のサーバーコンポーネント内でuseTranslations、getTranslations、または任意のnext-intlヘルパーを使用すると、Next.jsはそのルート全体を動的としてマークします。([Next Intl][1])

• なぜか？ next-intlは、リクエスト専用ヘッダー（x-next-intl-locale）からheaders()を介して現在のロケールを取得します。headers()は動的APIであるため、それに触れるコンポーネントは静的最適化を失います。([Next Intl][1], [Next.js][2])

• 公式の回避策（ボイラープレート）

  1. サポートされているすべてのロケールでgenerateStaticParamsをエクスポートします。
  2. useTranslationsを呼び出す前に、すべてのレイアウト/ページでsetRequestLocale(locale)を呼び出します。([Next Intl][1]) これによりヘッダー依存がなくなりますが、追加のコード管理が必要になり、本番環境で不安定なAPIとなります。

intlayerが問題を回避する方法

設計上の選択

1. ルートパラメータのみ – ロケールはNext.jsがすでに各ページに渡している[locale]のURLセグメントから取得されます。
2. コンパイル時バンドル – 翻訳は通常のESモジュールとしてインポートされるため、ツリーシェイクされビルド時に埋め込まれます。
3. 動的APIなし – useT()はheaders()やcookies()からではなく、Reactコンテキストから読み取ります。
4. 追加設定不要 – ページがapp/[locale]/配下にあると、Next.jsはロケールごとに1つのHTMLファイルを自動的にプリレンダリングします。