React-Intl VS React-i18next VS Intlayer | React国際化 (i18n)
以下は、React用の3つの人気のあるi18n(国際化)ライブラリReact-Intl、React-i18next、およびIntlayerの簡潔な比較です。それぞれのライブラリは、Reactアプリケーションに多言語サポートを統合するためのユニークな機能とワークフローを提供しています。この文を読んだ後で、どのソリューションがあなたのニーズに最も適しているかを決定できるようになるはずです。
1. はじめに
Reactアプリケーションにおける国際化(i18n)は、複数の方法で実現できます。ここで紹介する3つのライブラリは、それぞれ異なる設計哲学、機能のセット、およびコミュニティサポートを持っています:
- React-Intl
- React-i18next
- Intlayer
以下には、それぞれのソリューションの概要、特徴の比較、長所と短所、および使用例があります。
2. React-Intl
概要
React-Intlは、FormatJSスイートの一部です。メッセージフォーマット、複数形、日付/時間、および数値フォーマットを扱うための強力なAPIとコンポーネントのセットを提供します。React-Intlは、メッセージ構文とフォーマットを標準化するエコシステムの一部であるため、エンタープライズアプリケーションで広く使用されています。
主な機能
- ICUメッセージ構文: メッセージの補間、複数形、その他のための包括的な構文を提供します。
- ローカライズされたフォーマット: ロケールに基づいた日付、時間、数値、および相対時間をフォーマットするためのビルトインユーティリティ。
- 宣言的コンポーネント: JSXでのシームレスな使用のために、<FormattedMessage>、<FormattedNumber>、<FormattedDate>などを公開します。
- 豊富なエコシステム: メッセージの抽出、管理、コンパイルのためのFormatJSツール(例:babel-plugin-react-intl)と良好に統合されます。
一般的なワークフロー
- メッセージカタログを定義する(通常はロケールごとのJSONファイル)。
- アプリをラップする <IntlProvider locale="ja" messages={messages}>の中で。
- 使用する <FormattedMessage id="myMessage" defaultMessage="Hello world" />またはuseIntl()フックを使用して翻訳文字列にアクセスする。
長所
- 確立されており、多くの本番環境で使用されています。
- 複数形、性別、タイムゾーンなどを含む高度なメッセージフォーマット。
- メッセージの抽出とコンパイルに対する強力なツールサポート。
短所
- ICUメッセージフォーマットに慣れる必要があり、冗長になる可能性があります。
- 文字列ベース以上の動的または複雑な翻訳の処理はあまり簡単ではありません。
3. React-i18next
概要
React-i18nextは、最も人気のあるJavaScript i18nフレームワークの1つであるi18nextのReact拡張です。ランタイム翻訳、レイジーローディング、および言語の検出に対する広範な機能を提供し、さまざまなユースケースに対して非常に柔軟です。
主な機能
- 柔軟な翻訳構造: ICUのような単一のフォーマットに縛られません。JSONで翻訳を格納したり、補間や複数形を使用することができます。
- 動的な言語切り替え: ビルトインの言語検出プラグインとランタイム更新。
- ネストされた構造化翻訳: JSON内で翻訳を簡単にネストできます。
- 広範なプラグインエコシステム: 検出(ブラウザ、パス、サブドメインなど)、リソースの読み込み、キャッシュなどのためのプラグインがあります。
一般的なワークフロー
- i18nextとreact-i18nextをインストールする。
- i18nを設定して翻訳(JSON)の読み込みと、言語の検出またはフォールバックを設定します。
- アプリをラップする I18nextProviderの中で。
- useTranslation()フックまたは<Trans>コンポーネントを使用して翻訳を表示します。
長所
- 非常に柔軟で、機能が豊富。
- 非常に活発なコミュニティと大規模なプラグインエコシステム。
- 翻訳の動的なロードが容易(例: サーバーからの需要に応じた)。
短所
- 設定が冗長になることがあります、特に高度なニーズがある場合。
- 強い型付けの翻訳を好む場合は、追加のTypeScriptの設定が必要になることがあります。
4. Intlayer
概要
Intlayerは、典型的なJSONカタログからシフトして、コンポーネントごとのコンテンツ宣言、型安全性、および動的ルーティングに焦点を当てた新しいオープンソースのi18nライブラリです。これは、現代的なReactワークフロー向けに設計されており、Create React AppとViteの両方のセットアップをサポートしています。また、ロケールベースのルーティングや自動生成されたTypeScript型などの高度な機能も含まれています。
主な機能
- 宣言的コンテンツファイル: 各コンポーネントまたはモジュールは、専用の.content.tsxまたは.content.jsonファイルにその翻訳を宣言できます。また、使用されている場所にコンテンツを近づけます。
- ビルトインのルーティング&ミドルウェア: ローカライズされたルーティングのためのオプションモジュール(例:/ja/about, /fr/about)およびユーザーのロケールを検出するためのサーバーミドルウェア。
- 自動生成されたTypeScript型: 自動補完やコンパイル時のエラー検出などの機能を持つ型安全性を確保します。
- 動的でリッチな翻訳: より複雑なユースケース(例: リンク、太字のテキスト、翻訳内のアイコン)に対してJSX/TSXを翻訳に含めることができます。
一般的なワークフロー
- intlayerとreact-intlayerをインストールする。
- intlayer.config.tsを作成し、使用可能なロケールおよびデフォルトロケールを定義する。
- Intlayer CLIまたはプラグインを使用してコンテンツ宣言をトランスパイルする。
- アプリをラップする <IntlayerProvider>の中で、useIntlayer("keyName")でコンテンツを取得します。
長所
- TypeScriptフレンドリーで、型生成とエラーチェックが組み込まれています。
- リッチなコンテンツが可能(例: 翻訳としてReactノードを渡すこと)。
- ローカライズされたルーティングが即座に使用可能。
- 人気のビルドツール(CRA, Vite)と統合されており、簡単な設定が可能です。
短所
- まだ比較的新しいライブラリであるため、React-IntlやReact-i18nextに比べて。
- 「コンポーネントレベルのコンテンツ宣言」アプローチに多く依存 — 従来の.jsonカタログからのシフトかもしれません。
- より確立されたライブラリに比べて、エコシステムやコミュニティが小さめです。
5. 機能比較
機能 | React-Intl | React-i18next | Intlayer |
---|---|---|---|
主なユースケース | 文字列ベースの翻訳、日付/数値フォーマット、ICUメッセージ構文 | 簡単な動的切り替え、ネスティング、プラグインエコシステムを持つフル機能のi18n | 宣言的コンテンツ、ローカライズされたルーティング、およびオプションのサーバーミドルウェアの型安全な翻訳 |
アプローチ | <IntlProvider>とFormatJSメッセージコンポーネントを利用 | I18nextProviderとuseTranslation()フックを利用 | <IntlayerProvider>とuseIntlayer()フックを利用したコンテンツ宣言 |
ローカリゼーションフォーマット | ICUベースの文字列(JSONまたはJavaScriptカタログ) | JSONリソースファイル(またはカスタムローダー)。ICU形式はi18nextプラグインを通じてオプション | .content.[ts/js/tsx]またはJSON宣言; 文字列やReactコンポーネントを含むことができる |
ルーティング | 外部で処理(ローカライズされたルーティングの組み込みなし) | i18nextプラグインを介した外部での処理(パス、サブドメインの検出など) | ビルトインのローカライズされたルーティングサポート(例:/ja/about, /fr/about)、およびオプションのサーバーミドルウェア(SSR/Vite用) |
TypeScriptサポート | 良好(公式パッケージの型) | 良好だが、厳密なチェックを希望する場合、型翻訳のための追加設定が必要 | 優れている(コンテンツキーと翻訳のための自動生成された型定義) |
複数形とフォーマット | 高度: 日付/時間/数値フォーマット、複数形/性別サポートが組み込まれている | 構成可能な複数形。日付/時間のフォーマットは通常、外部ライブラリやi18nextプラグインで実行される | 標準のJavaScriptIntlに依存することができますが、コンテンツにロジックを埋め込むこともできます。FormatJSほど専門的ではありませんが、一般的なケースを処理します。 |
コミュニティとエコシステム | 大規模で、FormatJSエコシステムの一部 | 非常に大規模で、非常に活発で、たくさんのプラグイン(検出、キャッシング、フレームワーク用) | 小規模ですが成長中; オープンソースで、現代的なアプローチ |
学習曲線 | 中程度(ICUメッセージ構文とFormatJSの規則を学ぶ) | 低から中程度(使いやすいが、高度な設定は冗長になることも) | 中程度(コンテンツ宣言と専門的なビルド手順の概念) |
6. それぞれを選ぶ際の考慮事項
React-Intl
- 強力なフォーマットが必要な場合、日付/時間/数値、および強力なICUメッセージ構文。
- 翻訳に対して「標準ベース」のアプローチを好む場合。
- ローカライズされたルーティングや強い型付けの翻訳キーは必要ない。
React-i18next
- 柔軟で確立された解決策が必要で、動的でオンデマンドの翻訳の読み込みが必要な場合。
- 「URL、クッキー、ローカルストレージ」などからのプラグインベースの言語検出や、高度なキャッシュが必要な場合。
- 最も大規模なエコシステムが必要で、さまざまなフレームワーク(Next.js、React Nativeなど)向けの多くの既存統合が必要な場合。
Intlayer
- 強いTypeScript統合が欲しい場合、自動生成された型があり、ほとんど翻訳キーを見逃しません。
- 宣言的コンテンツをコンポーネントの近くに配置することを好み、Reactノードや翻訳における高度なロジックを含めたい場合。
- 組み込みのローカライズされたルーティングが必要で、SSRやViteの設定に簡単に組み込むことができる場合。
- 現代的なアプローチを求めるか、単一のライブラリでコンテンツ管理(i18n)とルーティングを型安全な方法でカバーしたい場合。
7. 結論
各ライブラリは、Reactアプリケーションの国際化に対して堅牢なソリューションを提供します:
- React-Intlはメッセージフォーマットに優れ、ICUメッセージ構文に重点を置いたエンタープライズソリューションに人気です。
- React-i18nextは、高度に柔軟でプラグイン駆動の環境を提供し、動的または高度なi18nニーズに対応します。
- Intlayerは、コンテンツ宣言、進化したローカライズされたルーティング、およびプラグインベース(CRA、Vite)の統合を融合させた現代的で型安全なアプローチを提供します。
あなたの選択は、プロジェクトの要件、望ましい開発者体験(DX)、および型付け翻訳や高度なルーティングの重要性によって大きく異なります。組み込みのローカライズされたルーティングとTypeScriptの統合を重視する場合は、Intlayerが最も魅力的かもしれません。戦闘実績があり、エコシステムが豊富なソリューションを求める場合は、React-i18nextが素晴らしい選択肢です。単純なICUベースのフォーマットが必要な場合は、React-Intlが信頼できる選択肢です。
さらなる読み物
- React-Intl ドキュメント
- React-i18next ドキュメント
- Intlayer + CRA のスタートガイド(あなたのドキュメントから)
- Intlayer + Vite & React のスタートガイド(あなたのドキュメントから)
要件に応じてアプローチを自由に組み合わせてください。「一律すべてに合う」ソリューションはなく、それぞれのライブラリは新しいユースケースに対応するために進化を続けています。
このドキュメントを改善するアイデアがある場合は、GitHubでプルリクエストを送信することで自由に貢献してください。
ブログへのGitHubリンク