# General Translation Knowledge Base: General Translation と Lingui：どちらを使うべきか？
URL: https://generaltranslation.com/ja/kb/general-translation-vs-lingui.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: Lingui と同様にテキストをインラインで記述しつつ、JSX の構造を文脈として翻訳を生成したい場合は General Translation を選びましょう。Lingui はインラインのメッセージをカタログに抽出し、翻訳は翻訳者や連携サービスに委ねます。General Translation の CLI はコードの変更に合わせて翻訳を更新し、チームは ダッシュボード でその翻訳をレビューできます。
Category: 国際化
Last updated: 2026-10-16
Authors: Kevin Wu, Jackie Chen
Published: 2026-10-16

記述する側から見ると、Lingui のアプローチは General Translation とよく似ています。コンポーネント内に `<Trans>Inbox</Trans>` と書くと、Lingui のマクロがそれを自動生成された ID 付きの ICU メッセージにコンパイルします。続いて `lingui extract` が PO カタログを書き出し、`lingui compile` が翻訳済みのカタログを軽量な JavaScript モジュールに変換します。ただし、Lingui は翻訳そのものは行いません。公式ドキュメントでは、[カタログを手作業で編集するか、Crowdin や Translation.io と同期する](https://lingui.dev/tools/introduction)方法が案内されています。General Translation もテキストをインラインに保ちますが、翻訳の生成まで General Translation が担います。

## Lingui の優れている点

* **マクロによるインラインの翻訳元。** `<Trans>` マクロと、複数形やプレーンな文字列向けの [Lingui のマクロ](https://lingui.dev/ref/macro)を使えば、英語をコンポーネント内に書いたまま ICU MessageFormat にコンパイルされるため、キーを書く必要は一切ありません。
* **軽量なランタイム。** メッセージは事前にコンパイルされ、Lingui 自身の計測ではランタイムのサイズは[約 2 kB](https://lingui.dev/introduction) です。
* **Gettext と相性の良いカタログ。** [デフォルトの形式は PO](https://lingui.dev/ref/catalog-formats) で、`lingui extract` は新しいメッセージをすべてのロケールにマージし、削除されたメッセージを obsolete としてマークします。さらに、`context` と `comment` フィールドの内容は翻訳者にも伝わります。
* **サーバーコンポーネント。** [バージョン 4.10 以降](https://lingui.dev/tutorials/react-rsc)、各ページまたはレイアウトで `setI18n` を呼び出せば、`<Trans>` と `useLingui` をサーバー上で使用できます。
* **活発な開発。** [2026 年 4 月にバージョン 6 がリリースされました](https://lingui.dev/blog/2026/04/22/announcing-lingui-6.0) (ESM のみ、Node.js 22.19 以降が必要) 。ライセンスは MIT です。

## Lingui が開発者に任せていること

Lingui の React マクロを使った、小さな受信トレイの例を見てみましょう。

```jsx title="Inbox.jsx"
import { Trans, Plural } from '@lingui/react/macro';

export function Inbox({ count }) {
  return (
    <section>
      <h1>
        <Trans>Inbox</Trans>
      </h1>
      <p>
        <Trans>
          You have <Plural value={count} one="# unread message" other="# unread messages" />.
        </Trans>
      </p>
    </section>
  );
}
```

`lingui extract` は、新しいターゲット言語のメッセージを訳文が空の状態で PO カタログに追加します。これらのエントリは、翻訳者または連携サービスが ICU 構文を保持したまま埋めていきます。翻訳が完了したスペイン語カタログは次のようになります。

```text title="locales/es/messages.po"
#: src/Inbox.jsx:7
msgid "Inbox"
msgstr "Bandeja de entrada"

#: src/Inbox.jsx:10
msgid "You have {count, plural, one {# unread message} other {# unread messages}}."
msgstr "Tienes {count, plural, one {# mensaje sin leer} other {# mensajes sin leer}}."
```

次に、[`lingui compile`](https://lingui.dev/ref/cli) がカタログを、アプリが読み込むモジュールに変換します。この抽出・翻訳・コンパイルのサイクルは変更のたびに繰り返す必要があります。また、マクロには[ビルド時の変換](https://lingui.dev/installation) (Lingui の Babel プラグイン、Vite プラグイン、または実験的な SWC プラグイン) が必要です。さらに翻訳者は、コンポーネントではなく PO エントリとそのコメントだけを頼りに作業することになります。

## インラインのテキストはそのままに、カタログの生成は General Translation に任せる

General Translation のライブラリでも、同じインライン記述をそのまま使えます。テキストは [`<T>`](/docs/react/reference/components/t) に、複数形は [`<Plural>`](/docs/react/reference/components/plural) に記述し、[`<Num>`](/docs/react/reference/components/num) が各ロケールに合わせて値を書式設定します。さらに General Translation は、Lingui にはできない翻訳の生成まで行います。以下は、同じ受信トレイを `gt-react` で実装した例です。

```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}
          singular={<p>You have <Num>{count}</Num> unread message.</p>}
          plural={<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) ブロックを要素構造ごと送信し、ビルド前に対象言語のカタログを生成します。翻訳元の `singular` と `plural` の分岐は、各対象言語で必要となる形式の文言の元になります。[`<Plural>`](/docs/react/reference/components/plural) は、ランタイムに翻訳済みの分岐を選択します。JSX の外にある文字列は、Lingui の文字列マクロに相当する [`useGT`](/docs/react/reference/hooks/use-gt) で処理します。

この例では、受信トレイの見出しとメッセージの分岐がまとめて翻訳に送られます。製品固有の意味を説明する [`context` メモ](/docs/react/reference/components/t#context) を追加することもできます。レビュアーは、生成されたテキストを [ダッシュボードの翻訳エディター](/docs/platform/dashboard/guides/reviewing-translations) で編集します。次回の CLI 実行では、変更のない翻訳はそのまま再利用され、新しい文言だけが生成されます。カタログをコンパイルするための別コマンドは必要ありません。

Profound のプラットフォームとドキュメントは、General Translation によって 47 以上のロケールで提供されています。 ([本番環境での導入事例](https://generaltranslation.com/enterprise)を参照してください。)

## Lingui と General Translation の比較

| 機能          | Lingui                                     | General Translation                                                                                            |
| ----------- | ------------------------------------------ | -------------------------------------------------------------------------------------------------------------- |
| テキストの書き方    | `<Trans>` などのインラインマクロ                      | [`<T>`](/docs/react/reference/components/t) 内のインライン JSX と、[`useGT`](/docs/react/reference/hooks/use-gt) による文字列 |
| コンテンツの翻訳    | なし                                         | あり ([`npx gt translate`](/docs/cli/reference/commands/translate) で実行)                                          |
| 変更ごとの手順     | 抽出、PO カタログごとの翻訳、コンパイル (ビルドにマクロ変換の組み込みが必要)  | ビルド前に [`npx gt translate`](/docs/cli/reference/commands/translate) を実行するだけ                                     |
| カタログ        | ロケールごとの PO ファイルを JavaScript モジュールにコンパイル    | ロケールごとに生成され、リポジトリまたは General Translation の CDN に保存                                                             |
| 翻訳者が参照できる情報 | メッセージと、`context` および `comment` フィールド       | マークされた JSX ブロック内の構造、文脈メモ、共有の用語集とカスタムプロンプト                                                                      |

翻訳者が gettext の PO カタログで作業している場合、コンパイル済みの軽量なランタイムによるバンドルサイズの削減を重視する場合、あるいは現在の翻訳プロセスがすでにうまく回っている場合は、Lingui を使い続けるのがよいでしょう。抽出・翻訳・コンパイルのサイクルを経ずに同じインライン記述を実現し、コードの文脈を踏まえた翻訳を生成したい場合は、General Translation を選んでください。

## Lingui からの移行

移行はコンポーネントまたはルート単位で 1 つずつ進めてください。Lingui の `<Trans>` は [`<T>`](/docs/react/reference/components/t) に対応します。Lingui の `<Plural value={count} one="…" other="…" />` は、`n={count}` と `singular`・`plural` の分岐を指定した [`<Plural>`](/docs/react/reference/components/plural) に対応し、数値には [`<Num>`](/docs/react/reference/components/num) を使用します。文字列マクロは [`useGT`](/docs/react/reference/hooks/use-gt) に対応します。まだ移行していないコンポーネントでは、Lingui の既存の翻訳を引き続き読み込んでください。すべてのコンポーネントの移行が完了したら、マクロ変換と extract・compile スクリプトを削除します ([i18nライブラリの移行](/docs/react/guides/migrating-i18n-libraries)を参照) 。

## 重要なポイント

* Lingui はテキストをインラインで記述し、軽量なランタイムにコンパイルします。各ターゲット言語のカタログは、翻訳者または連携サービスが用意します。
* General Translation のライブラリでも同じようにインライン記述ができ、さらに翻訳そのものも General Translation が行います。コードの文脈を踏まえて翻訳するため、カタログを往復させるサイクルは不要です。
* Lingui のマクロは [`<T>`](/docs/react/reference/components/t)、[`<Plural>`](/docs/react/reference/components/plural)、[`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 はメッセージのレンダリングと複数形の選択を担いますが、翻訳の生成には別のサービスが必要です。
- [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 が適しています。
- [翻訳ファイルなしで i18n はできますか？](https://generaltranslation.com/ja/kb/i18n-without-translation-files.mdx): はい。gt-react または gt-next を使えば、コンテンツは `<T>` コンポーネントで囲んだままコンポーネント内にインラインで記述でき、翻訳はビルド時に出力として生成されます。そのため、キーやロケールごとの JSON ファイルを作成したり、同期を保ったりする必要はありません。

## Previous and next questions

- Previous question: [General Translation と Intlayer の比較：どちらを使うべきか](https://generaltranslation.com/ja/kb/general-translation-vs-intlayer.mdx)
- Next question: [General Translation と Locize：どちらを使うべきか？](https://generaltranslation.com/ja/kb/general-translation-vs-locize.mdx)

## Sitemap

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