# General Translation Knowledge Base: General Translation vs. i18next、react-intl、next-intl：どのi18nライブラリを使うべきか？
URL: https://generaltranslation.com/ja/kb/general-translation-vs-i18n-libraries.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: i18next、react-intl、next-intlなどのオープンソースライブラリ自体は、翻訳を一切行いません。これらが行うのは、あなた自身や翻訳者、あるいは別のサービスが作成し、言語ごとのカタログファイルに用意した翻訳を表示することだけです。General Translationのライブラリも同じくオープンソースで同じ役割を果たしますが、General Translationはさらに、コードを文脈として活用しながら翻訳そのものも行います。
Category: 国際化
Last updated: 2026-10-16
Authors: General Translation Team
Published: 2026-10-16

国際化 (i18n) ライブラリは、アプリの実行中に2つの役割を担います。ユーザーのロケールに応じたメッセージを選ぶことと、そのロケールに合わせて複数形・日付・数値を書式設定することです。i18next、react-intl、next-intl、Lingui、vue-i18nなどのオープンソースライブラリはどちらにも対応していますが、いずれもコンテンツを翻訳する機能は備えていません。翻訳はアプリの実行前に、あなた自身で済ませておく必要があります。具体的には、キーを使うかインラインのメッセージを抽出するかして各文字列をカタログファイルにまとめ、すべてのカタログを翻訳し、UIが変わるたびにそれらを最新の状態に保たなければなりません。General Translationのライブラリも同じランタイムの役割を果たしますが、General Translationはそれに加えて翻訳も行います。テキストはコンポーネント内にインラインで記述したままで構わず、翻訳はビルドステップの一部として生成されます。

## 定番ライブラリの優れている点

これらのライブラリはいずれも成熟しており、無料で広く利用されています。また、それぞれに異なる強みがあります。

* **i18next** は最もダウンロード数の多いライブラリです。あらゆる JavaScript 環境で動作し、公式の `i18next-cli` を使えば、コードからキーを抽出してその TypeScript 型を生成できます。
* **react-intl** (FormatJS) は、複数形や選択を表現する標準構文である ICU MessageFormat をベースにしています。ドキュメントでは、各 `defaultMessage` を翻訳者向けの `description` とともにインラインで記述し、`formatjs extract` でカタログにまとめる方法が推奨されています。
* **next-intl** は Next.js App Router 向けに作られています。翻訳をサーバーコンポーネント内で利用でき、サーバーコンポーネントでのみ使うメッセージはクライアントに送らずに済みます。メッセージキーの型チェックにも対応しています。バージョン 4.5 で追加されたインラインメッセージ API は、現在も実験的機能という位置づけです。
* **Lingui** は `<Trans>` などのマクロで原文をインラインに記述でき、メッセージ ID を自動生成し、メッセージを PO カタログに抽出します。
* **vue-i18n** は Vue 3 用の i18n プラグインで、メッセージを JSON、YAML、またはシングルファイルコンポーネント内の `<i18n>` ブロックで管理します。

いずれのライブラリも、翻訳者や翻訳管理システム (TMS) が普段から扱っている JSON や PO などのカタログ形式で翻訳を管理します。

## 開発者に委ねられる部分

これらのライブラリは、どれも翻訳そのものは行いません。翻訳は、あなた自身や翻訳者が用意するか、i18next チームが提供する Locize や、Crowdin のような TMS などの外部サービスを利用して用意する必要があります。以下は、react-i18next を使った小さな受信トレイコンポーネントの例です。

```json title="locales/en/translation.json"
{
  "inbox": {
    "title": "Inbox",
    "unread_one": "You have {{count}} unread message.",
    "unread_other": "You have {{count}} unread messages."
  }
}
```

```tsx title="Inbox.tsx"
import { useTranslation } from 'react-i18next';

export function Inbox({ count }: { count: number }) {
  const { t } = useTranslation();
  return (
    <section>
      <h1>{t('inbox.title')}</h1>
      <p>{t('inbox.unread', { count })}</p>
    </section>
  );
}
```

そのほかの言語には、`locales/es/translation.json` のように言語ごとのファイルが必要で、手作業で書くか翻訳に出すことになります。さらに各ファイルには、その言語の複数形を個別のキーとして用意しなければなりません。日本語は1つ、ポーランド語は4つ、アラビア語は6つ (`_zero`、`_one`、`_two`、`_few`、`_many`、`_other`) です。コンポーネントに文字列を追加しても、誰かが追加するまでは他のファイルにはどこにも存在しません。また、カタログを翻訳する人の目に入るのは `inbox.unread_other` と1つの文だけで、それが実際に表示される画面は見えません。

## General Translation も同じことができ、さらに翻訳まで生成します

General Translation のライブラリは、i18next、react-intl、next-intl と同じ役割を果たします。ロケールごとに適切なメッセージを選び、そのロケールの複数形規則を適用し、[`<Num>`](/docs/react/reference/components/num)、[`<Currency>`](/docs/react/reference/components/currency)、[`<DateTime>`](/docs/react/reference/components/datetime) で数値・通貨・日付を書式設定します。[`useGT`](/docs/react/reference/hooks/use-gt) の文字列では ICU 形式の変数を扱えます。キーを使いたいチーム向けには [`useTranslations`](/docs/react/reference/hooks/use-translations) によるキーベースの辞書を、`gt-next` ではロケールごとの URL も提供します。さらに General Translation は、他のライブラリにはできないこと、つまり翻訳そのものの生成まで行います。

以下は、同じ受信トレイを `gt-react` で実装した例です。文言はコンポーネント内に置いたまま、[`<T>`](/docs/react/reference/components/t) で翻訳対象の JSX を指定し、[`<Plural>`](/docs/react/reference/components/plural) に英語の各複数形を記述します。

```tsx title="Inbox.tsx"
import { T, Plural, Num } from 'gt-react';

export function Inbox({ count }: { count: number }) {
  return (
    <T>
      <section>
        <h1>Inbox</h1>
        <Plural
          n={count}
          one={<p>You have <Num>{count}</Num> unread message.</p>}
          other={<p>You have <Num>{count}</Num> unread messages.</p>}
        />
      </section>
    </T>
  );
}
```

ビルド前に [`npx gt translate`](/docs/cli/reference/commands/translate) を実行すると、各 [`<T>`](/docs/react/reference/components/t) ブロックが要素構造ごと General Translation API に送信され、すべての対象ロケールの翻訳が書き出されます。開発者が書くのは英語で使う複数形だけで、ポーランド語の `few` や `many` など、各対象言語に必要な形は翻訳時に生成されます。その後、[`<Plural>`](/docs/react/reference/components/plural) が読者のロケールの複数形規則に従って、翻訳済みのブランチを選択します。[`<Num>`](/docs/react/reference/components/num) はレンダリング時に読者のロケールに合わせて数値を書式設定し、[`<Var>`](/docs/react/reference/components/var) でラップした値が API に送信されることはありません。文を編集すれば次回の実行で再翻訳され、コンポーネントを削除すればその翻訳も削除されます。

General Translation のライブラリは Next.js (`gt-next`) 、React (`gt-react`) 、Vue 3 (`gt-vue`) 、Node.js (`gt-node`) に対応しており、React Native、TanStack Start、Python の Flask および FastAPI 向けの試験的なライブラリも用意されています。いずれも MIT ライセンスで、General Translation のアカウントがなくても動作します。翻訳は任意の提供元から読み込めるほか、手作業で翻訳するチーム向けには [`gt generate`](/docs/cli/reference/commands/generate) でテンプレートファイルを書き出せます。ICU メッセージの解析とフォーマットには General Translation 独自のパッケージを使用しているため、`gt-react` や `gt-next` が内部で他の i18nライブラリに依存することはありません。翻訳はデフォルトでビルドにファイルとして同梱されますが、General Translation の CDN から読み込むこともできます。

## ライブラリの比較

| ライブラリ                                                                | 文言の書き方                                                                                                           | コンテンツを翻訳するか | 翻訳の提供元                                                                                | 複数形                                                                             |
| -------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | ----------- | ------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- |
| [i18next](/kb/general-translation-vs-i18next) (`react-i18next` を使用)  | ロケールごとの JSON ファイルにキーを記述                                                                                          | いいえ         | 自分自身、翻訳者、または Locize などのサービス                                                           | 複数形ごとに1つのキー                                                                     |
| [`react-intl`](/kb/general-translation-vs-react-intl) (FormatJS)     | `defaultMessage` にインラインでテキストを記述し、JSON カタログに抽出                                                                    | いいえ         | 自分自身、翻訳者、または TMS                                                                      | ICU MessageFormat                                                               |
| `next-intl`                                                          | ロケールごとの JSON ファイルにキーを記述                                                                                          | いいえ         | 自分自身、翻訳者、または Crowdin などの TMS                                                          | ICU MessageFormat                                                               |
| [Lingui](/kb/general-translation-vs-lingui)                          | インラインのマクロで記述し、PO カタログに抽出                                                                                         | いいえ         | 自分自身、翻訳者、または Crowdin などの TMS                                                          | ICU MessageFormat                                                               |
| [`vue-i18n`](/kb/general-translation-vs-vue-i18n)                    | ロケールごとのメッセージオブジェクトにキーを記述                                                                                         | いいえ         | 自分自身、翻訳者、または TMS                                                                      | 各形式を縦棒で区切って記述。バージョン 11 ではポーランド語などの言語にカスタムルールが必要                                 |
| General Translation (`gt-react`、`gt-next`、`gt-vue`)                  | [`<T>`](/docs/react/reference/components/t) 内に JSX を記述、または [`useGT`](/docs/react/reference/hooks/use-gt) で文字列を渡す | はい          | コードの文脈をもとに [`npx gt translate`](/docs/cli/reference/commands/translate) で生成、またはチームが記述 | [`<Plural>`](/docs/react/reference/components/plural) のブランチ。各対象言語に必要な形式は翻訳時に生成される |

既存のカタログと翻訳プロセスがすでにうまく機能している場合、翻訳者や TMS がカタログファイルを前提としている場合、あるいは使用中のフレームワークが General Translation のライブラリでサポートされていない場合は、i18next、react-intl、next-intl、Lingui、vue-i18n を引き続き使用してください。コンポーネント内の文言を読みやすく保ちたい場合、コードの文脈を踏まえた翻訳を生成したい場合、そして翻訳作業の完了を待つことなく、ビルドのたびにすべての言語を最新の状態にしたい場合は、General Translation のライブラリを使用してください。

## 既存のライブラリを使い続けるか、ルートごとに移行する

ライブラリを切り替える必要はありません。`gt` CLI は `package.json` から `next-intl` または `i18next` を検出し、各ライブラリのメッセージ構文を保ったまま JSON ファイルを翻訳します。`i18next` が直接の依存関係として含まれていれば、`react-i18next` や `next-i18next` を使ったプロジェクトにも対応します。`gt.config.json` でカタログの場所を指定してください：

```json title="gt.config.json"
{
  "defaultLocale": "en",
  "locales": ["es", "fr", "ja"],
  "files": {
    "json": {
      "include": ["locales/[locale]/*.json"]
    }
  }
}
```

テキストだけでは伝えきれない文脈をキーに与えるには、`locales/en/translation.metadata.json` のような対応ファイルを追加し、そのキーに `context` または `maxChars` エントリを記述します。 ([キーごとのメタデータ](/docs/cli/reference/keyed-metadata)および[翻訳の生成](/docs/cli/guides/generating-translations)を参照してください。) 

[`<T>`](/docs/react/reference/components/t) に移行する場合は、[i18nライブラリの移行](/docs/react/guides/migrating-i18n-libraries)の手順に従ってください。このガイドでは3つの方法を紹介しています。キーの参照をインラインのテキストに置き換える方法、既存の辞書を残したまま [`useTranslations`](/docs/react/reference/hooks/use-translations) を呼び出す方法、そして両方のライブラリを併用しながらルートを1つずつ移行する方法です。

General Translation は、Cursor、Ramp、Profound、Cognition、Sierra、ClickHouse をはじめとする世界トップクラスの開発チームに信頼されています。お使いのアプリで試すなら、[Next.jsクイックスタート](/docs/react/nextjs-quickstart)、[Reactクイックスタート](/docs/react/react-quickstart)、または[Vueクイックスタート](/docs/vue/quickstart)から始めましょう。

## 重要なポイント

* i18next、react-intl、next-intl などのオープンソースのi18nライブラリは、翻訳そのものは行いません。開発者が自分で用意し、常に最新の状態に保たなければならない翻訳を、レンダリングして書式設定するだけです。
* General Translation のライブラリも同じくレンダリングと書式設定を担い、オープンソースかつ MIT ライセンスで提供されています。そのうえ General Translation は、[`<T>`](/docs/react/reference/components/t) にインラインで書かれた文章をもとに翻訳まで行います。そのため、同期を保つべきキーやカタログは不要です。
* i18next や next-intl を使い続けたまま `gt` CLI でそれらの JSON ファイルを翻訳することも、ルート単位で段階的に移行することもできます。

## Related questions

- [TMS（Smartling、Lokalise、Phrase、Crowdin、Transifex）ではなく General Translation を使う理由](https://generaltranslation.com/ja/kb/general-translation-vs-tms.mdx): Smartling、Lokalise、Phrase、Crowdin、Transifex などの翻訳管理システム（TMS）は翻訳者間の作業を取りまとめますが、文字列の抽出、送信、翻訳待ち、プロダクトへの再組み込みは依然としてエンジニアの仕事です。General Translation はコード内のコンテンツを文脈ごと翻訳し、リリースのたびに全言語をまとめて提供します。ロックインのないオープンソースのライブラリ上で動作します。
- [Google 翻訳の代替：General Translation と Google 翻訳の比較](https://generaltranslation.com/ja/kb/general-translation-vs-google-translate.mdx): Google 翻訳は、単発のテキストをすばやく翻訳するのに便利ですが、製品を別の言語でリリースするには、各文字列を文脈に沿って翻訳し、用語を統一し、変数や複数形を正しく扱い、レビューを行い、リリースプロセスを整える必要があります。General Translation はコード内の各文字列の文脈を理解し、コードからレビュー、そして毎回のリリースまで、ローカライゼーションのワークフロー全体を自動化します。
- [i18next の代替：General Translation と i18next の比較](https://generaltranslation.com/ja/kb/general-translation-vs-i18next.mdx): テキストを React コンポーネント内にインラインで記述したまま、JSX 構造とプロダクトの文脈を活かして翻訳を生成したい場合は、General Translation を選びましょう。i18next を使い続けながら、General Translation で既存のカタログを翻訳することもできます。i18next はメッセージのレンダリングと複数形の選択を担いますが、翻訳の生成には別のサービスが必要です。
- [react-intl の代替：General Translation と react-intl の比較](https://generaltranslation.com/ja/kb/general-translation-vs-react-intl.mdx): General Translation なら、React チームは ICU メッセージ構文をそのまま使いながら、翻訳の生成、用語の共有、ダッシュボード でのレビューを追加できます。react-intl が提供するのはフォーマット機能と FormatJS のカタログツールですが、General Translation は翻訳そのものも生成します。
- [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 が適しています。

## Previous and next questions

- Previous question: [Crowdin の代替ツール：General Translation と Crowdin の比較](https://generaltranslation.com/ja/kb/general-translation-vs-crowdin.mdx)
- Next question: [General Translation と Babel・Flask-Babel の比較：どちらを使うべきか](https://generaltranslation.com/ja/kb/general-translation-vs-flask-babel.mdx)

## Sitemap

See the [Knowledge Base sitemap](https://generaltranslation.com/ja/kb/sitemap.md) for every article.