【ITニュース解説】I built a fully native, zero-dependency i18n kit for React Native's New Architecture
2026年10月21日に「Dev.to」が公開したITニュース「I built a fully native, zero-dependency i18n kit for React Native's New Architecture」について初心者にもわかりやすく解説しています。
ITニュース概要
React Native向けに、新しいアーキテクチャに準拠した多言語対応(i18n)ライブラリ「react-native-i18n-kit」が公開された。これは、既存ライブラリが抱える古いアーキテクチャや多くの依存関係といった課題を解決するため、ゼロ依存で開発された。ネイティブ機能と連携し、正確な地域情報、複数形、RTL対応などを提供することで、多言語アプリ開発を効率化する。
ITニュース解説
現代のアプリ開発において、世界中のユーザーに利用されるためには、アプリを様々な言語や地域に適応させる「国際化(i18n)」と「地域化(l10n)」が不可欠である。これは単にメニューやボタンのテキストを翻訳するだけでなく、日付や時刻の表示形式、数値の区切り方、通貨記号、さらには言語に応じた複数形のルール、右から左へ記述する言語(RTL)への対応など、多岐にわたる調整を必要とする。しかし、この国際化の実現は多くの開発者にとって手間がかかる作業であり、既存のツールやライブラリにはいくつかの課題が残っていたのが実情であった。
そうした背景の中、React Native向けの新しい国際化キット「react-native-i18n-kit」が開発された。このキットは、React Nativeの新しいアーキテクチャに特化し、従来の国際化ライブラリが抱えていた問題を根本から解決することを目指している。開発者がこのライブラリを構築した動機は、既存のツールでは実現が困難だった、より高度で効率的な国際化機能へのニーズにあった。
従来のライブラリの主な問題点として、まず挙げられるのが、デバイスの地域情報をJavaScript側で推測している点である。デバイス自体は、使用しているカレンダー、タイムゾーン、小数点以下の区切り文字、12時間制・24時間制の好み、計測システムなど、正確な地域情報をすでに持っているにもかかわらず、多くのライブラリはこれをJavaScriptのコードで無理に解釈しようとしていた。これは非効率的であり、誤った情報を提供するリスクもあった。また、多くの国際化ライブラリがReact Nativeの古いアーキテクチャを前提に作られており、新しいアーキテクチャへの移行が進む中で互換性の問題が生じていた。新しいアーキテクチャでは、JavaScriptとネイティブコード間の通信を行う「ブリッジ」が廃止され、「TurboModule」という新しい仕組みが導入されるため、これに対応した設計が必要とされていた。さらに、国際化機能を実現するために多くの依存ライブラリ(翻訳、日付フォーマット、デバイス情報取得など)を組み込む必要があり、これらがコードの肥大化や管理の複雑さを招いていた。加えて、Android 15では、プリビルドされたネイティブライブラリファイルが16KBのページサイズに整列していることが必須となり、この要件を満たさないライブラリはリリースを妨げる可能性も出てきていた。
「react-native-i18n-kit」は、これらの課題に対し、ネイティブコードを活用し、外部依存を排除し、新しいアーキテクチャに最初から対応するという明確な目標を持って開発された。具体的には、AndroidではKotlin、iOSではSwiftというそれぞれのプラットフォームのネイティブ言語で記述されており、TypeScriptの厳格な型チェックにも対応している。
このライブラリが提供する主な機能は多岐にわたる。まず、デバイスが設定している言語、国、カレンダー、タイムゾーン、数値の区切り方、12時間・24時間表示、メートル法・ヤードポンド法といった詳細な地域設定を、JavaScriptの推測に頼らずネイティブから直接、正確に検出する。これにより、アプリはユーザーのデバイス環境に完全に合致した表示が可能となる。
言語の切り替えも非常にスムーズで、setLocale()関数を呼び出すだけでアプリ全体が瞬時に再レンダリングされ、再起動なしに表示言語が変更される。また、国際化の重要な要素である複数形(例えば、0個、1個、2個、少数、多数など)の処理には、国際化データの標準であるCLDR (Common Locale Data Repository) のルールが活用されている。これにより、英語の「one/other」だけでなく、アラビア語のように6つの異なる複数形を持つ言語や、フランス語のように0を単数形として扱う言語にも正確に対応できる。
さらに、RTL(右から左へ記述する言語)への対応も徹底している。言語がRTLであるかどうかを正確に判断し、必要に応じてレイアウトの方向を自動的に調整する。レイアウト方向の変更にアプリの再起動が必要な場合は、その旨を開発者に通知する仕組みも備わっている。
ユーザーがアプリ使用中にOSのシステム言語を変更した場合でも、その変更をリアルタイムで検知し、アプリ内の表示も即座に更新される機能も備えている。一度ユーザーがアプリ内で言語を選択すると、その選択はネイティブの設定保存機能(AndroidのSharedPreferencesやiOSのUserDefaults)に保存され、アプリを再起動してもその言語が維持されるため、ユーザーは毎回設定し直す必要がない。
ロケールマッチングも非常に賢い。例えば、「zh-Hans-CN」のような複雑なロケールコードや、古いAndroidデバイスでヘブライ語が「iw」と報告されるような場合でも、ライブラリは利用可能な最適な言語を自動的に選択する。これにより、開発者は煩雑なロケールコードの対応に頭を悩ませる必要がなくなる。
数値、通貨、パーセンテージ、日付、相対時間といった要素も、ユーザーのロケールに合わせて適切にフォーマットされる。例えば、同じ数字「1234567.891」でも、英語圏では「1,234,567.891」、フランス語圏では「1 234 567,891」のように表示される。React NativeのJavaScriptエンジンであるHermesが一部の国際化API(Intl.RelativeTimeFormatなど)を標準で持たない場合でも、このライブラリはプラットフォームが持つネイティブのフォーマッタ(AndroidのICUやiOSのFoundation.Localeなど)に自動的にフォールバックし、常に適切な出力を行う。無効な入力があった場合には、型付きのエラーを発生させ、ユーザーに不適切な表示がされることを防ぐ。
アプリからデバイスの情報を取得する際も、useDeviceLocale()フックを通じて国、タイムゾーン、数値フォーマット設定、12/24時間表示の使用、メートル法の使用といった情報がOSから直接提供されるため、正確かつリアルタイムな情報に基づいてアプリの動作を調整できる。
開発者の視点から見ると、このライブラリは堅牢なエラーハンドリング機構を備えている。国際化に関するエラーはすべてI18nKitErrorという単一のクラスとして定義され、INVALID_LOCALEやPROVIDER_NOT_FOUNDといった安定したエラーコードを持つ。これにより、エラー発生時に適切な処理を実装しやすくなる。また、存在しない翻訳キーが指定された場合でも、アプリがクラッシュする代わりに、開発モードでは警告が表示され、キー自体が返されるため、ユーザー体験を損なうことがない。
このライブラリはテスト駆動開発で構築されており、翻訳機能、複数形ルール、ロケールマッチング、フォーマッタ、プロバイダー、ネイティブAPIバインディング、さらにはAndroidのKotlin側に対する単体テストなど、広範なテストスイートが用意されている。これにより、品質と信頼性が高く保たれている。
「react-native-i18n-kit」をアプリに導入するには、まず翻訳ファイルをJSON形式で用意する。次に、アプリのルートコンポーネントをLocalizationProviderでラップし、翻訳ファイルとデフォルトのロケールを指定する。その後は、useTranslation()フックを使って、アプリのどのコンポーネントからでも翻訳テキストや書式設定機能にアクセスできるようになる。
このライブラリは、React Native 0.85以降(新しいアーキテクチャ)を要件とし、Android API 29+およびiOS 15.1+、そしてTypeScript 5+(厳格モード推奨)が必要となる。このように、「react-native-i18n-kit」は、React Nativeでグローバルなアプリを構築する際の国際化・地域化の課題を、現代的で堅牢なアプローチで解決する、強力なソリューションを提供している。