# General Translation Knowledge Base: react-intl の代替：General Translation と react-intl の比較 URL: https://generaltranslation.com/ja/kb/general-translation-vs-react-intl.mdx Docs index: https://generaltranslation.com/llms.txt Description: General Translation なら、React チームは ICU メッセージ構文をそのまま使いながら、翻訳の生成、用語の共有、ダッシュボード でのレビューを追加できます。react-intl が提供するのはフォーマット機能と FormatJS のカタログツールですが、General Translation は翻訳そのものも生成します。 Category: 国際化 Last updated: 2026-10-16 Authors: Kevin Wu, Jackie Chen Published: 2026-10-16 react-intl は [FormatJS が提供する React ライブラリ](https://formatjs.github.io/docs/react-intl)です。各メッセージを ICU MessageFormat の `defaultMessage` としてインラインで記述し、翻訳者向けに `description` を添えます。その後 `formatjs extract` ですべてのメッセージを JSON カタログに抽出し、翻訳済みカタログを `IntlProvider` 経由でレンダリングします。react-intl 自体には翻訳機能はありません。抽出したカタログは、自分で翻訳するか、翻訳者や翻訳管理システム (TMS) に渡し、返ってきた翻訳済みファイルをコンパイルする必要があります。General Translation のライブラリも ICU メッセージをレンダリングできますが、それに加えて翻訳の生成まで行います。 ## react-intl の優れている点 * **全面的な ICU MessageFormat 対応。** [`#` や `=0` のような完全一致を使った複数形、`select`、`selectordinal`](https://formatjs.github.io/docs/core-concepts/icu-syntax) に対応しており、ブラウザの `Intl` API をベースに構築されています。 * **原文をインラインで記述。** FormatJS は [`defaultMessage` と `description` をインラインで記述し](https://formatjs.github.io/docs/getting-started/message-declaration)、メッセージ ID の生成は `babel-plugin-formatjs` または `@swc/plugin-formatjs` に任せることを推奨しています。そのため、誰もキーを自分で考える必要がありません。 * **TMS ワークフロー向けのツール群。** [`formatjs extract`](https://formatjs.github.io/docs/tooling/cli) がカタログを書き出し、組み込みのフォーマッターが Crowdin、Lokalise、Smartling、Transifex 向けのファイルを生成します。さらに、`formatjs compile` はメッセージを事前にパースし、`formatjs verify` はカタログにキーの欠落や余分なキーがないかをチェックします。 * **TypeScript 対応。** [バージョン 12 では、各メッセージの ICU 引数に型を付けられます](https://formatjs.github.io/docs/react-intl/upgrade-guide-12.x)。 * **活発なメンテナンス。** [バージョン 12 は 2026 年 9 月にリリースされました](https://github.com/formatjs/formatjs/blob/main/packages/react-intl/CHANGELOG.md)。ライセンスは BSD-3-Clause です。 ## react-intl が開発者に任せていること react-intl で作った小さな受信トレイを例に見てみましょう。英語のテキストは `defaultMessage` としてコンポーネント内にそのまま残ります。 ```jsx title="Inbox.jsx" import { FormattedMessage } from 'react-intl'; export function Inbox({ count }) { return (

); } ``` `formatjs extract` を実行すると、これらのメッセージが、生成された ID をキーとするカタログに変換されます: ```json title="lang/en.json" { "U5vJOY": { "defaultMessage": "You have {count, plural, one {# unread message} other {# unread messages}}.", "description": "Number of unread messages in the inbox" }, "gBGgGs": { "defaultMessage": "Inbox", "description": "Heading of the inbox page" } } ``` 対象言語ごとに、ICU 構文を保ったまま翻訳したメッセージを用意する必要があります。`IntlProvider` はメッセージ文字列とプリコンパイル済みメッセージのどちらも受け付けます。後者は `formatjs compile` で生成できます。抽出されたディスクリプターには、各メッセージとその説明が含まれます。この例のように ID を自動生成するには、ビルドに Babel または SWC のプラグインを設定してください。[Next.js App Router](https://formatjs.github.io/docs/guides/nextjs-app-router) では、react-intl のコンポーネントはクライアントコンポーネント内で動作します。一方、サーバー側のコードでは `react-intl/server` の `createIntl` を使ってメッセージを書式設定します。 ## ICUメッセージはそのままに、翻訳を生成する General Translationのライブラリは、react-intlと同じ役割を担います。ICUメッセージのレンダリング、各ロケールの複数形規則の適用、数値・通貨・日付の書式設定を行います。[`useGT`](/docs/react/reference/hooks/use-gt) は同じ構文に対応しているため、ICU文字列はほとんど変更せずに移行できます。 ```tsx title="Inbox.tsx" import { useGT } from 'gt-react'; export function Inbox({ count }: { count: number }) { const gt = useGT(); return (

{gt('Inbox', { $context: 'Heading of the inbox page' })}

{gt('You have {count, plural, one {# unread message} other {# unread messages}}.', { count, $context: 'Number of unread messages in the inbox', })}

); } ``` [`npx gt translate`](/docs/cli/reference/commands/translate) を実行すると、これらの文字列の抽出、文脈メモを活用した翻訳の生成、対象カタログへの書き出しまでを1つのコマンドで行えます。この例では、FormatJS の2つの description をどちらも `$context` として保持しています。共有の[用語集とカスタムプロンプト](/docs/platform/dashboard/guides/defining-context-for-translations)で用語やトーンを統一でき、レビュアーは[ダッシュボード](/docs/platform/dashboard/guides/reviewing-translations)で翻訳結果を編集できます。 `#` はロケールに応じて書式設定されるため、件数 12345 は英語では "12,345"、スペイン語では "12.345" と表示されます。マークアップを含む JSX には [``](/docs/react/reference/components/t) を使うと、要素を含むブロック全体をまとめて翻訳できます。`gt-next` では、サーバーコンポーネント内でもそのまま動作します。 Ramp のダッシュボード、ランディングページ、iOS アプリは、General Translation を利用して 11 以上のロケールで提供されています。 ([本番環境での導入事例](https://generaltranslation.com/enterprise)をご覧ください。) ## react-intl と General Translation の比較概要 | 機能 | react-intl | General Translation | | ------------------ | --------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | | テキストの記述方法 | ICU 形式の `defaultMessage` をインラインで記述し、JSON カタログに抽出 | [``](/docs/react/reference/components/t) 内にインライン JSX で記述、または [`useGT`](/docs/react/reference/hooks/use-gt) で ICU文字列を記述 | | コンテンツの翻訳 | なし | あり ([`npx gt translate`](/docs/cli/reference/commands/translate) を使用) | | カタログのワークフロー | メッセージを抽出し、任意のワークフローで翻訳したうえで、必要に応じてプリコンパイル。ID はプラグインが生成 | [`npx gt translate`](/docs/cli/reference/commands/translate) がビルド前に抽出と翻訳を実行 | | 翻訳の文脈 | メッセージとその説明 | `$context` 付きの ICU文字列、インラインコンポーネントでマークされた JSX 構造、共有の用語集とカスタムプロンプト | | Next.js App Router | クライアントコンポーネント内でコンポーネントを使用し、サーバー側では `createIntl` を使用 | サーバーコンポーネントとクライアントコンポーネントの両方で [``](/docs/react/reference/components/t) を使用 | | ライセンス | [BSD-3-Clause](https://github.com/formatjs/formatjs/blob/main/packages/react-intl/LICENSE.md) | MIT ライセンスの JavaScript ライブラリと CLI | ICU カタログや TMS のフォーマッターがすでに問題なく機能している場合、型付きのメッセージ引数や `formatjs verify` を活用している場合、または React 以外の環境で FormatJS を使用している場合は、react-intl を引き続き使うのがよいでしょう。ICU での記述はそのままに、翻訳の生成とレビューを開発ワークフローに組み込みたい場合は、General Translation がおすすめです。 ## react-intl からの移行 移行はコンポーネント単位またはルート単位で1つずつ進めてください。上記のとおり、各 `` を [`useGT`](/docs/react/reference/hooks/use-gt) の呼び出しに置き換え、ICU文字列はそのまま残し、description は `$context` として渡します。リッチな JSX には [``](/docs/react/reference/components/t#context) を使用します。まだ移行していないコンポーネントについては、既存の react-intl カタログを引き続き読み込んでください。すべてのコンポーネントの移行が完了したら、FormatJS プラグインと、extract および compile 用のスクリプトを削除します。 ([i18nライブラリの移行](/docs/react/guides/migrating-i18n-libraries)を参照してください。) ## その他のreact-intlの代替ライブラリ react-intlから移行するチームは、以下のライブラリも比較検討しています。 * **i18next:** キーで管理されたカタログを、複数形の選択に対応した形でレンダリングします。react-i18nextやnext-i18nextと組み合わせて、ReactやNext.jsアプリで広く使われています。 ([General Translation vs. i18next](/kb/general-translation-vs-i18next)を参照してください。) * **Lingui:** テキストをインラインで記述し、メッセージをカタログにコンパイルします。ランタイムは軽量です。 ([General Translation vs. Lingui](/kb/general-translation-vs-lingui)を参照してください。) * **next-intl:** Next.js App Routerアプリで、サーバーコンポーネントも含めてカタログのメッセージをレンダリングします。 ([next-intl vs. gt-next](/kb/next-intl-vs-gt-next)を参照してください。) * **Paraglide JS:** カタログを、型付きでツリーシェイキング可能なメッセージ関数にコンパイルします。 ([General Translation vs. Paraglide JS](/kb/general-translation-vs-paraglide)を参照してください。) * **Intlayer:** 各コンポーネントのコンテンツを型付きの宣言ファイルで管理し、全言語の内容を1つのファイルに並べて記述します。 ([General Translation vs. Intlayer](/kb/general-translation-vs-intlayer)を参照してください。) ## 重要なポイント * react-intl はICUメッセージの書式設定を行い、カタログ用のツールを提供しますが、翻訳の生成には別のワークフローが必要です。 * General Translation は1つのCLIコマンドで抽出から翻訳まで完了し、description の文脈を保持したうえで、レビュー担当者向けにダッシュボード上のエディターを提供します。 * 既存のICU文字列はほぼそのまま [`useGT`](/docs/react/reference/hooks/use-gt) に移行でき、コンポーネント単位で段階的に進められます。 ## Related questions - [General Translation vs. i18next、react-intl、next-intl：どのi18nライブラリを使うべきか？](https://generaltranslation.com/ja/kb/general-translation-vs-i18n-libraries.mdx): i18next、react-intl、next-intlなどのオープンソースライブラリ自体は、翻訳を一切行いません。これらが行うのは、あなた自身や翻訳者、あるいは別のサービスが作成し、言語ごとのカタログファイルに用意した翻訳を表示することだけです。General Translationのライブラリも同じくオープンソースで同じ役割を果たしますが、General Translationはさらに、コードを文脈として活用しながら翻訳そのものも行います。 - [i18next の代替：General Translation と i18next の比較](https://generaltranslation.com/ja/kb/general-translation-vs-i18next.mdx): テキストを React コンポーネント内にインラインで記述したまま、JSX 構造とプロダクトの文脈を活かして翻訳を生成したい場合は、General Translation を選びましょう。i18next を使い続けながら、General Translation で既存のカタログを翻訳することもできます。i18next はメッセージのレンダリングと複数形の選択を担いますが、翻訳の生成には別のサービスが必要です。 - [General Translation と Lingui：どちらを使うべきか？](https://generaltranslation.com/ja/kb/general-translation-vs-lingui.mdx): Lingui と同様にテキストをインラインで記述しつつ、JSX の構造を文脈として翻訳を生成したい場合は General Translation を選びましょう。Lingui はインラインのメッセージをカタログに抽出し、翻訳は翻訳者や連携サービスに委ねます。General Translation の CLI はコードの変更に合わせて翻訳を更新し、チームは ダッシュボード でその翻訳をレビューできます。 - [General Translation と vue-i18n：どちらを使うべきか](https://generaltranslation.com/ja/kb/general-translation-vs-vue-i18n.mdx): General Translation を使うと、Vue チームはテンプレートに翻訳元の文言を直接記述し、CLI で翻訳を生成できます。gt-vue プラグインは、そのコンテンツをロケール対応の複数形や数値フォーマットでレンダリングします。キーで管理する原文ファイルの保守をなくしたいなら General Translation が適しています。一方、Nuxt の i18n モジュールと確立されたカタログのワークフローを利用しているチームには、引き続き vue-i18n が適しています。 - [React で複数形を扱うには？](https://generaltranslation.com/ja/kb/how-to-handle-plurals-in-react.mdx): n === 1 のような条件分岐で複数形の選択ロジックをハードコードするのは避けましょう。英語のみのアプリなら小さなヘルパーで十分ですが、多言語アプリではロケール対応の複数形規則が必要になります。gt-react や gt-next の `` のような i18n コンポーネントを使えば、あらゆる言語の複数形に対応できます。 ## Previous and next questions - Previous question: [Phrase の代替ツール：General Translation と Phrase の比較](https://generaltranslation.com/ja/kb/general-translation-vs-phrase.mdx) - Next question: [Reactアプリに最適なi18nライブラリは？](https://generaltranslation.com/ja/kb/best-react-i18n-library.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/ja/kb/sitemap.md) for every article.