このページとあなたの好きなAIアシスタントを使ってドキュメントを要約します
このページのコンテンツはAIを使用して翻訳されました。
英語の元のコンテンツの最新バージョンを見るこのドキュメントを改善するアイデアがある場合は、GitHubでプルリクエストを送信することで自由に貢献してください。
ドキュメントへのGitHubリンクドキュメントのMarkdownをクリップボードにコピー
Intlayer を使った next-i18next による Next.js 15 の翻訳 | 国際化 (i18n)
このガイドの対象者
- ジュニア: 正確な手順に従い、コードブロックをコピーしてください。動作する多言語アプリが手に入ります。
- ミッドレベル: チェックリストやベストプラクティスの注意点を活用して、よくある落とし穴を回避しましょう。
- シニア: 高レベルの構造、SEO、オートメーションのセクションをざっと確認してください。合理的なデフォルト設定や拡張ポイントが見つかります。
作成するもの
- ローカライズされたルートを持つ App Router プロジェクト(例:
/,/fr/...) - ロケール、デフォルトロケール、RTL対応を含む i18n 設定
- サーバーサイドの i18n 初期化とクライアントプロバイダー
- 名前空間付きの翻訳をオンデマンドで読み込み
hreflang、ローカライズされたsitemap、robotsを使った SEO- ロケールルーティング用のミドルウェア
- 翻訳ワークフローを自動化する Intlayer 統合(テスト、AI 補完、JSON 同期)
注意: next-i18next は i18next の上に構築されています。このガイドでは、App Router で next-i18next と互換性のある i18next のプリミティブを使用しつつ、アーキテクチャをシンプルかつ本番環境向けに保っています。
より広範な比較については、next-i18next vs next-intl vs Intlayer を参照してください。
1) プロジェクト構成
next-i18next の依存関係をインストールします:
明確な構造から始めましょう。メッセージはロケールとネームスペースごとに分割して保持します。
チェックリスト(中級/上級):
- ロケールごとにネームスペースあたり1つのJSONを保持する
- メッセージを過度に集中管理しない。小さなページや機能単位のネームスペースを使う
- すべてのロケールを一度にインポートしない。必要なものだけをロードする
2) 依存関係のインストール
next-i18next の API や設定の相互運用を使用する予定がある場合は、以下も追加してください:
3) コア i18n 設定
ロケール、デフォルトロケール、RTL、およびローカライズされたパス/URL のヘルパーを定義します。
シニアノート: next-i18next.config.js を使用する場合は、i18n.config.ts と整合性を保ち、ズレが生じないようにしてください。
4) サーバーサイドのi18n初期化
必要なロケール/ネームスペースのJSONのみをインポートする動的バックエンドで、サーバー上でi18nextを初期化します。
中間メモ: ペイロードを制限するために、ページごとのnamespaceリストは短く保ってください。グローバルな「キャッチオール」バンドルは避けてください。
5) Reactコンポーネント用クライアントプロバイダー
サーバー設定を反映し、要求されたnamespaceのみをロードするプロバイダーでクライアントコンポーネントをラップします。
ジュニア向けのヒント: クライアントにすべてのメッセージを渡す必要はありません。ページの名前空間だけから始めましょう。
6) ローカライズされたレイアウトとルート
言語と方向を設定し、ロケールごとにルートを事前生成して静的レンダリングを促進します。
7) サーバー+クライアント使用例ページ
翻訳(各名前空間ごとに src/locales/... に1つのJSON):
クライアントコンポーネント(必要な名前空間のみを読み込み):
ページやプロバイダーには必要な名前空間(例:
about)のみを含めるようにしてください。 Reactのバージョンが19未満の場合は、Intl.NumberFormatのような重いフォーマッターをメモ化してください。
クライアント境界内に埋め込まれた同期サーバーコンポーネント:
8) SEO: メタデータ、Hreflang、サイトマップ、ロボット
コンテンツの翻訳はリーチを拡大する手段です。多言語SEOを徹底的に設定しましょう。
ベストプラクティス:
- ルートに
langとdirを設定する - 各ロケールに対して
alternates.languagesを追加する(+x-default) - 翻訳されたURLを
sitemap.xmlにリストし、hreflangを使用する - ローカライズされたプライベートエリア(例:
/fr/admin)をrobots.txtで除外する
9) ロケールルーティングのためのミドルウェア
ロケールを検出し、ロケールがない場合はローカライズされたルートにリダイレクトします。
10) パフォーマンスと開発者体験(DX)のベストプラクティス
- htmlの
langとdirを設定する:src/app/[locale]/layout.tsxで実施済み。 - メッセージをネームスペースごとに分割する: バンドルを小さく保つ(
common.json、about.jsonなど)。 - クライアントのペイロードを最小化する: ページでは必要なネームスペースのみをプロバイダーに渡す。
- 静的ページを優先する: ロケールごとに
export const dynamic = 'force-static'とgenerateStaticParamsを使用する。 - サーバーコンポーネントを同期させる: レンダリング時の非同期呼び出しの代わりに事前計算された文字列やフォーマットを渡す。
- 重い処理をメモ化する: 特に古いReactバージョンのクライアントコードで重要。
- キャッシュとヘッダー: 可能な場合は動的レンダリングよりも静的または
revalidateを優先する。
11) テストとCI
tを使用するコンポーネントに対してユニットテストを追加し、キーが存在することを確認する。- 各ネームスペースがロケール間で同じキーを持っていることを検証します。
- デプロイ前にCIで不足しているキーを検出します。
Intlayerはこれらの多くを自動化します(次のセクションを参照)。
12) Intlayerを導入する(自動化)
IntlayerはJSON翻訳の同期を保ち、不足しているキーのテストを行い、必要に応じてAIで補完するのに役立ちます。
intlayerの依存関係をインストールします:
パッケージスクリプトを追加します:
一般的なフロー:
- CIで
pnpm i18n:testを実行し、キーが不足している場合にビルドを失敗させる - ローカルで
pnpm i18n:fillを実行し、新しく追加されたキーに対してAI翻訳を提案する
CLI引数を指定することも可能です。詳細はIntlayer CLIドキュメントをご覧ください。
13) トラブルシューティング
- キーが見つからない: ページやプロバイダーが正しいnamespaceをリストしていること、そしてJSONファイルが
src/locales/<locale>/<namespace>.jsonに存在することを確認してください。 - 言語が間違っている/英語が一瞬表示される:
middleware.tsのロケール検出とプロバイダーのlngを再確認してください。 - RTLレイアウトの問題:
dirがisRtl(locale)から正しく取得されているか、またCSSが[dir="rtl"]に対応しているかを確認してください。 - SEOのalternateが不足している:
alternates.languagesにすべてのロケールとx-defaultが含まれていることを確認してください。 - バンドルサイズが大きすぎる: namespaceをさらに分割し、クライアント側で
localesツリー全体をインポートしないようにしてください。
14) 次にやること
- 機能が拡張されるにつれて、より多くのロケールとネームスペースを追加する
- エラーページ、メール、およびAPI駆動のコンテンツをローカライズする
- 翻訳更新のために自動でPRをオープンするIntlayerのワークフローを拡張する
スターターをお探しの場合は、テンプレートをお試しください: https://github.com/aymericzip/intlayer-next-i18next-template。