globalize.now vs i18next
globalize.nowとi18nextは、それぞれ異なる課題に答えます。i18nextは、実行時に翻訳を読み込み、複数形のルール、変数の埋め込み、ロケールの切り替えを処理するオープンソースの国際化ライブラリです。globalize.nowは、開発時に動作するローカライゼーション基盤であり、ハードコードされた文字列を抽出し、キーを生成し、ロケールファイルを作成し、Gitへのプッシュのたびに翻訳を同期し続けます。
これは二者択一の話ではありません。i18next（あるいはnext-intl、react-intl、Lingui）は、文字列を実行時にどう取得しフォーマットするかを担います。一方globalize.nowは、コードが変化し続ける中で、それらの文字列をどうキーやロケールファイルとしてバージョン管理に取り込むかを担います。リポジトリがすでに整理されているなら、お好みのランタイムを導入してください。まだ整理できていないなら、まずglobalize.nowを実行し、ランタイムに一貫した入力データを渡せる状態にしましょう。
Next.jsでの手順を詳しく知りたい方は、 Next.js連携ガイド.
i18nextを選ぶべきケース…
i18nextは、実行時に翻訳データを読み込み、複数形のルール、フォーマット、ロケール切り替えを処理するオープンソースのJavaScript国際化ライブラリです。
次のような場合はi18nextが適しています。
- キーとロケールファイルがすでに存在しており、実績のあるランタイムAPIが必要な場合。
- ブラウザやサーバーで複数形処理、名前空間、遅延読み込みを利用したい場合。
- エンジニアが実装を担当しており、構造的なi18n対応にまだ抜け漏れがない場合。
globalize.nowを選ぶべきケース…
globalize.nowは、AI搭載のローカライズインフラであり、AI生成コードベースからハードコードされたUI文字列を自動的に抽出し、翻訳キーとロケールファイルを生成し、Gitへのプッシュのたびに翻訳を同期させます—手動のエクスポートも、レビュー待ち行列も、i18n負債も不要です。
次のような場合はglobalize.nowがおすすめです：
- AIによるコーディングの影響で、JSXやテンプレートにまだ文字列がハードコードされたまま残っている場合。
- ランタイムライブラリを活かす前に、自動抽出とGitプッシュ連携がまず必要な場合。
- i18nextに限らず、next-intlやLinguiなど他のスタックの構築を支援するエージェントスキルが欲しい場合。
機能比較(概要 ― 詳細は各社の公式サイトでご確認ください)。
| 機能 | globalize.now | i18next |
|---|---|---|
| 実行時の翻訳読み込みと複数形ルール | No | Yes |
| アプリシェル内でのロケール・言語切り替え | なし | あり |
| コードからユーザーに表示される文字列の自動抽出 | あり | なし |
| 翻訳キーの生成と重複排除 | あり | なし |
| リポジトリ内でのロケールファイル作成 | あり | なし |
| Gitプッシュのたびに自動同期 | あり | なし |
| 手動のエクスポート作業が不要なGit中心の自動化 | あり | 部分対応 |
| Cursor、Claude Code、Copilot向けのCLI／エージェントスキル | あり | 部分対応 |
| i18nextに限らず、next-intlやLinguiなど他のスタックにも対応 | あり | 該当なし |
| アプリケーションコード側でのエンジニアリング対応が必要 | 部分対応 | あり |
| マーケティングサイトで公開されている料金 | 部分対応 | あり |
- * 実行時の翻訳読み込みと複数形ルール: 補足: globalize.nowではなくi18nextが担う領域です。
- * マーケティングサイトで公開されている料金: 補足: i18nextのコア自体はOSSですが、ホスティングサービスの内容は異なるため、最新のページで確認してください。
i18nextの方が適しているケース
エンジニアがすでにUIテキストをリソースファイルに分割済みで、主にAPIの使い勝手やプラグイン、エコシステムとの連携が重要な場合はi18nextを選びましょう。カタログがすでに存在する段階であれば、これが適切なレイヤーです。
globalize.nowの方が適しているケース
アプリがまだ英語をハードコードしたまま表示しており、機能開発を止めずに文字列をキーへ変換する仕組みが必要なチームには、globalize.nowを選びましょう。Gitプッシュのたびに自動化を走らせることで、新しいUIがカタログを素通りするのを防げます。
globalize.nowとi18nextを併用する方法
両者を意図的に組み合わせましょう。まずglobalize.nowでロケールJSONを生成・同期し、そのリソースをクライアントやサーバーのバンドル内でi18nextで読み込みます。globalize.nowは特定ライブラリに依存しないため、抽出結果の信頼性が確保された後、チームは自分たちのスタックに合ったランタイムを自由に選べます。
よくある質問
globalize.nowはi18nextの代替となりますか？
いいえ。i18nextは引き続き、メッセージの読み込みとフォーマットを担うランタイムライブラリです。globalize.nowは、AIが生成したUIが変わり続ける中で、メッセージをGit上でどう作成・更新するかを自動化します。カタログを常に正確な状態に保つ自動化の後、あるいはそれと並行して、i18nextを利用してください。両者は異なるレイヤーを担っており、多くの場合は互いを補完し合う関係にあります。
両方とも必要ですか？
本番環境で動的に複数言語を提供するならランタイムライブラリが必要です。文字列がまだカタログの外に存在しているなら、インフラ自動化が必要です。多くのチームは、ファイル管理にglobalize.nowを、読み込みにi18nextを使っています。すでに手動で抽出作業を終えているなら、次にハードコードされた文字列が発生するまではi18nextだけで十分な場合もあります。
globalize.nowはnext-intlでも使えますか？
はい。globalize.nowは特定ライブラリに依存しません。フレームワークに応じて、エージェントスキルがnext-intl、Lingui、その他のパターンの構築を支援できます。i18nextは、そのエコシステムの豊富さから多くのチームが話題にするランタイムの一つにすぎません。ご自身のアーキテクチャに合ったランタイムを選び、globalize.nowはGitを基盤とした自動化に専念させましょう。
globalize.nowはどのランタイムライブラリに対応していますか？
スキルは、next-intlを使ったNext.js App Router、Lingui、開発者ガイドに記載されているReact構成など、一般的なスタックを対象としています。目指すゴールは常に同じで、安定したキーとロケールファイルをGitに取り込み、プッシュ時に同期することです。新しいスキルが公開されるたびに、developersページで正確な対応表をご確認ください。
i18nextのみの構成から、globalize.now＋i18nextの構成へ移行できますか？
はい。まずはi18nextを取り除くことなく、自動化ツールに文字列の棚卸しとキーの提案をさせるところから始めましょう。ロケールファイルが生成され、接続された後も、i18nextはローダーとして使い続けられます。これにより、一気に書き換える方式に比べてリスクを抑えられます。一晩で完了する変更ではなく、段階的なプルリクエストの積み重ねになると考えてください。
globalize.nowが行い、i18nextが行わないことは何ですか？
globalize.nowはコードをスキャンし、ユーザーに表示される文字列を抽出してキーを生成し、ロケールファイルを書き出します。そして、デフォルトではGitプッシュのたびに、翻訳が更新された際にプルリクエストを自動で開きます。i18nextはリソースを利用する側であり、機能追加が進む中でそれらのファイルをJSXとどう整合させ続けるかは決めません。その整合性の問題こそ、globalize.nowが自動化する部分です。
i18nextが行い、globalize.nowが行わないことは何ですか？
i18nextは、実行中のアプリにおける複数形処理のルール、変数の埋め込み、名前空間、遅延読み込み、実行時の言語切り替えを担います。これらはクライアントやサーバーのバンドル側で扱うべき事柄であり、Git自動化サービスの領域ではありません。役割は明確に分けましょう。インフラ側はファイルを維持し、i18nextはそれを描画します。
i18nextは、globalize.nowを実行する前と後、どちらでインストールすべきですか？
すでにローカライズされたバンドルを配信している場合は、i18nextをランタイムとしてそのままインストール、あるいは使い続けてください。一方、文字列がまだカタログを素通りしている場合は、i18nextのプラグインを調整する前に、キーやJSONファイルが揃うようglobalize.nowを実行しましょう。安全な順序としては、まず抽出とGit同期を自動化し、その後、生成されたリソースを読み込むようにi18nextを設定することです。こうすることで、バージョン管理上まだ安定していない文字列を翻訳してしまう事態を避けられます。
リポジトリを接続する
アプリ内でリポジトリを接続するだけで、Gitへのプッシュのたびにglobalize.nowがロケールファイルを最新の状態に保ちます。