i18next

単純な文字列置換ではなく、plural・context・nesting・interpolationを翻訳関数に集約する

READMEはi18nextの主要機能としてpluralization、context、nesting、variable replacementを挙げています。pluralはJavaScriptのIntl.PluralRulesに沿った形式で、言語ごとのone/otherだけでなくzero・two・few・manyなど複数の形を扱えます。動的な値は{{value}}形式で補間でき、翻訳文の構造とアプリケーション側の値を分離できます。

出典：[2][5][4]

翻訳ファイルの保存場所や言語判定をcoreへ固定せず、backend・detector・cacheをpluginとして選ぶ

i18nextは翻訳リソースの取得方法をbackend pluginとして分離し、HTTP、filesystem、localStorageなど複数の実装を組み合わせられます。language detector、cache、post processorも別componentとして選択できるため、browserとserverでresource loadingや検出方法を変えながら、t()を中心とした翻訳APIは共通化できます。

出典：[2][7]

React専用ではなく、React・Vue・Next.js・SvelteからNode/Denoまでbindingを替えて同じcoreを使う

公式ドキュメントはReact/React Native向けreact-i18next、Vue向けi18next-vue、Next.js向けnext-i18next、Node/Deno HTTP middlewareなど多数のintegrationを案内しています。core自体はbrowser、Node、Denoで動作するため、表示層ごとのbindingと翻訳resourceを分離して設計できます。packageはESMとCommonJSのentry point、TypeScript定義を持ち、TypeScript 5・6・7をoptional peer dependencyとして扱っています。

出典：[6][3]

複数の画面技術・実行環境で、翻訳キーとlocale resourceの考え方を共通化したい場合に

Web frontendとNode.js backendで共通の翻訳resourceを扱いたい場合、ReactからVueなどへUI技術が変わってもi18nの中核を維持したい場合、複数形やcontextを各画面で独自実装せず言語規則に沿って管理したい場合に向きます。小規模なJSON resourceからbackend pluginによる動的読み込みまで段階的に拡張できます。

framework bindingと周辺pluginの保守状況はcoreと別に確認する

Supported Frameworksページは、掲載されているintegration一覧そのものは公式に一括保守されておらず、各libraryのmaintainerが情報を提供していると明記しています。一部は更新停止やdeprecatedになる可能性があるため、React・Vue・Next.jsなどで採用するときはi18next coreの更新状況だけでなく、binding側の対応version、SSR/SSG、framework固有のroutingやresource loadingも確認する必要があります。

出典：[6]

補間値のescapeを無効化するとXSS対策の責任がアプリ側へ移る。Locizeも必須ではない

i18nextはinterpolation valueを既定でescapeし、XSSを軽減します。一方、escapeValue: falseや{{- value}}でescapeを無効化できます。公式ドキュメントは、この場合はuser inputを自分でescapeするよう警告し、外部由来の値ではskipOnVariablesをtrueのまま使うことも強く推奨しています。

READMEには開発者が提供する翻訳管理サービスLocizeへの導線がありますが、同時にi18nextはLocizeなしでも完全に動作すると明記されています。OSSのi18next本体、framework binding、翻訳resourceの運用、SaaS型translation managementを別々の選択肢として評価する方が構成を誤りにくいです。

出典：[4][2][8]