インターネット ユーザーの 75% 以上が母国語でのブラウジングを好み、ローカライズを行っている企業では英語以外の市場でのコンバージョン率が 70% 高くなりました。 Next.js と next-intl を組み合わせることで、あらゆるロケールにわたってルーティング、翻訳、書式設定、SEO を処理する堅牢な国際化フレームワークが提供されます。
インターネット ユーザーの 75% 以上が母国語でのブラウジングを好み、ローカライズを行っている企業では英語以外の市場でのコンバージョン率が 70% 高くなりました。 Next.js と next-intl を組み合わせることで、あらゆるロケールにわたってルーティング、翻訳、書式設定、SEO を処理する堅牢な国際化フレームワークが提供されます。
重要なポイント
- next-intl は Next.js App Router およびサーバー コンポーネントとシームレスに統合します
- ロケール接頭辞付きルーティングにより、他の言語の接頭辞を追加しながら英語の URL をクリーンに保ちます
- サーバー コンポーネントは、クライアント側の JavaScript バンドルのオーバーヘッドなしで翻訳を読み込みます。
- 国際的な SEO には適切な hreflang タグと多言語サイトマップが不可欠です
プロジェクトのセットアップ
next-intl をインストールし、routing.ts、navigation.ts、request.ts を含む i18n ディレクトリでプロジェクトを整理します。 App Router の [locale] の下にアプリを配置します。翻訳 JSON ファイルをプロジェクト ルートのメッセージ ディレクトリに保存します。
ルーティング構成
ロケール配列、デフォルト ロケール、およびロケール プレフィックス戦略を指定して、defineRouting() でルーティングを定義します。 「必要に応じて」戦略では、デフォルト ロケール (英語) のプレフィックスを省略し、その他のロケールには /es/、/fr/、/ar/ プレフィックスを追加します。
createNavigation(routing) を使用してナビゲーション ラッパーを作成し、ロケール対応の Link、useRouter、usePathname、およびリダイレクト関数を取得します。アプリ全体で Next.js ネイティブ ナビゲーションの代わりにこれらを使用します。
ミドルウェアのセットアップ
Next.js 16 で、proxy.ts ファイルを作成します (古い middleware.ts パターンを置き換えます)。 createMiddleware(routing)で作成したプロキシ関数をエクスポートします。 API ルート、静的ファイル、および _next パスを除外するようにマッチャーを構成します。
翻訳ファイル
JSON 構造 (ネストされた、フラットではない)
名前空間ごとに編成されたネストされたキーを使用します。 「home.title」のようなフラットなドット区切りのキーは絶対に使用しないでください。next-intl 名前空間の解決が妨げられます。翻訳は次のように構造化されます。
- 共通: 共通の用語 (ボタン、ラベル、読み込み状態)
- nav: ナビゲーション項目
- ホーム: ホームページのコンテンツ
- about: ページのコンテンツについて
- admin.common: 共有管理規約
- admin.products: 製品管理ページ
サーバーコンポーネント
非同期サーバー コンポーネントでは getTranslations("namespace") を使用します。これにより、クライアント バンドルに影響を与えることなく、サーバーに翻訳が読み込まれます。文字列変換の場合は t("key") を呼び出し、リッチ テキストの場合は t.rich("key", { 太字: (チャンク) => ... }) を呼び出します。
クライアントコンポーネント
「use client」とマークされたクライアント コンポーネントで useTranslations("namespace") フックを使用します。フックは同じ t() 関数を提供します。アクティブな名前空間の翻訳のみがクライアント バンドルに含まれます。
RTL (右から左) のサポート
アラビア語、ヘブライ語、ウルドゥー語、およびその他の RTL 言語の場合は、現在のロケールに基づいて HTML 要素に dir="rtl" を設定します。ロケール レイアウトで、ロケールが rtlLocales 配列内にあるかどうかを確認し、それに応じて方向を設定します。
RTL モードで自動的に反転するレイアウトには、Tailwind CSS 論理プロパティ (pl、pr、ml、mr の代わりに ps、pe、ms、me) を使用します。 RTL スクリプトに適切なフォントをロードします (例: アラビア語とウルドゥー語の場合は Noto Sans Arabic)。
SEO: メタデータと Hreflang
動的メタデータ
すべてのページでは、ロケールを認識したタイトル、説明、hreflang 代替のために、generateMetadata() (決して静的エクスポート const メタデータを使用しない) を使用する必要があります。各ロケールをその URL パスにマッピングする alters.langages オブジェクトと、英語バージョンを指す x-default エントリを構築します。
多言語サイトマップ
すべてのロケールのすべてのページに対してサイトマップ エントリを生成します。各エントリには、すべてのロケール バリアントをマッピングする alters.langages を含める必要があります。これにより、検索エンジンは各市場で正しい言語バージョンを提供できるようになります。
コンテンツ言語メタタグ
ロケール レイアウトにコンテンツ言語メタ タグを設定して、検索エンジンと AI クローラーがページ言語を識別できるようにします。これは、Bing および新興の AI 検索エンジンにとって特に重要です。
翻訳ワークフロー
- すべての翻訳可能な文字列の信頼できる唯一の情報源として en.json を編集します
- 翻訳スクリプトを実行して、新しいキーをすべてのロケール ファイルに反映します (初期ドラフトには Google Translate API または DeepL を使用)
- 翻訳をネイティブ スピーカーとレビューして、品質と文化的適切性を確認します
- RTL 言語を徹底的にテストします -- レイアウトの反転、テキストの配置、フォーム入力をチェックします
- hreflang 検証ツールと Google Search Console の国際ターゲティングを使用して SEO を検証
大きな翻訳ファイルの処理
5,000 以上の変換キーを持つアプリケーションの場合は、JSON ファイルを名前空間ごとに整理して保守性を向上させます。 next-intl は、現在のページに必要な名前空間のみを読み込み、パフォーマンスを最適に保ちます。
パフォーマンスに関する考慮事項
- サーバー レンダリング: 翻訳はサーバーにロードされます。コンポーネントがクライアント コンポーネントでない限り、変換 JSON はクライアントに送信されません。
- 名前空間の分割: 翻訳ファイル全体ではなく、ページごとにアクティブな名前空間のみが読み込まれます。
- 静的生成: getTranslations() を使用するページは、すべてのロケールに対してビルド時に静的に生成できます。
- バンドル サイズ: クライアント コンポーネントには、名前空間の変換のみが含まれます。 useTranslations("home") を使用するページには、「home」名前空間のみが付属します。
よくある落とし穴
- フラット キー: ネストされた { "home": { "title": "..." } } の代わりに "home.title" をキーとして使用すると、名前空間の解決が中断されます
- 翻訳の欠落: 常にフォールバック動作を提供します -- 翻訳が欠落している場合、next-intl はキー名を表示しますが、これはユーザーには壊れているように見えます
- ハードコードされた文字列: 翻訳システムの外にある文字列がないかコードベースを監査します。
- 日付/数値の書式設定: 一貫した動作を実現するために、toLocaleDateString() の代わりに next-intl フォーマッタを使用します。
- 静的メタデータ:generateMetadata() の代わりにエクスポート const メタデータを使用すると、ロケールを認識したタイトルと説明が防止されます。
よくある質問
Q: next-intl はいくつのロケールを処理できますか?
実際的な制限はありません。 11 以上のロケールと 7,000 以上の変換キーを持つアプリケーションは、パフォーマンスの問題なく実行されます。サーバー側のレンダリングは、翻訳によってクライアント バンドルが肥大化しないことを意味します。
Q: i18n はページ読み込みパフォーマンスに影響しますか?
サーバー コンポーネントの場合、翻訳の読み込みはサーバー上で行われます。パフォーマンスへの影響は無視できます。クライアント コンポーネントには、名前空間の変換のみが含まれており、通常は数 KB です。
Q: 複数の言語で動的データベース コンテンツを処理するにはどうすればよいですか?
静的 UI テキストは JSON ファイルを使用します。データベース コンテンツ (ブログ投稿、製品説明) では、翻訳を専用の列またはテーブルに保存するか、翻訳ワークフローが組み込まれた CMS を使用する必要があります。一部のチームは、UI に JSON、コンテンツにデータベースというハイブリッドを使用しています。
Q: 数値と日付の形式についてはどうすればよいですか?
next-intl は、数値、通貨、日付、および相対時間をロケールに応じた書式設定するための useFormatter() を提供します。すべての書式設定は国際標準に従い、ロケール規則が自動的に尊重されます。
次は何ですか
国際化は、英語以外のあらゆる市場に利益をもたらす投資です。最も価値の高いロケールから始めて、そこから拡張していきます。
i18n 実装のヘルプについては ECOSIRE にお問い合わせ、多言語 ERP 導入については Odoo 実装サービス をご覧ください。
ECOSIRE が発行 -- エンタープライズ ソフトウェア ソリューションによるビジネスの拡大を支援します。
執筆者
ECOSIRE Teamテクニカルライティング
ECOSIRE のテクニカルライティングチームは、Odoo ERP、Shopify による EC、AI エージェント、Power BI による分析、GoHighLevel による自動化、そしてエンタープライズソフトウェアのベストプラクティスを扱っています。私たちのガイドは、企業が十分な情報に基づいてテクノロジーを判断できるよう支援します。
関連記事
Next.js の国際化: 11 ロケールの実装
next-intl v4 を使用して、本番環境に対応した 11 ロケールの Next.js アプリを構築します。ルーティング、RTL サポート、翻訳ワークフロー、hreflang SEO、サーバー/クライアント コンポーネント パターンをカバーします。
Next.js 16 アプリルーター: 制作パターンと落とし穴
本番環境に対応した Next.js 16 の App Router パターン: サーバー コンポーネント、キャッシュ戦略、メタデータ API、エラー境界、回避すべきパフォーマンスの落とし穴。
React Query (TanStack): データ取得パターン
TanStack Query v5 のマスター データ フェッチ パターン: クエリ、ミューテーション、オプティミスティック更新、無限スクロール、プリフェッチ、キャッシュの無効化、Next.js App Router との統合。