# General Translation Knowledge Base: i18next の代替：General Translation と i18next の比較 URL: https://generaltranslation.com/ja/kb/general-translation-vs-i18next.mdx Docs index: https://generaltranslation.com/llms.txt Description: テキストを React コンポーネント内にインラインで記述したまま、JSX 構造とプロダクトの文脈を活かして翻訳を生成したい場合は、General Translation を選びましょう。i18next を使い続けながら、General Translation で既存のカタログを翻訳することもできます。i18next はメッセージのレンダリングと複数形の選択を担いますが、翻訳の生成には別のサービスが必要です。 Category: 国際化 Last updated: 2026-10-16 Authors: Kevin Wu, Jackie Chen Published: 2026-10-16 i18next は、翻訳ファイルの読み込み、ユーザーの言語に応じたメッセージの選択、複数形の解決、値の補間、そして `Intl` による数値や日付の書式設定を行います。2012 年から npm で公開されており、`react-i18next` や `next-i18next` と組み合わせて React や Next.js アプリで広く使われています。ただし、i18next 自体は翻訳を行いません。すべての言語のすべてのメッセージは、開発者自身や翻訳者が用意するか、[i18next の開発元が運営する](https://www.i18next.com/) Locize などのサービスを利用して用意する必要があります。General Translation のライブラリも同様にレンダリングを担いますが、それに加えて、General Translation はコンポーネント内のテキストから翻訳を生成します。 ## i18nextの強み * **普及度。** 最も広く使われているJavaScript i18nフレームワークの1つです。 * **対応範囲の広さ。** [React、Vue、Angular、Svelteなどに対応するバインディング](https://www.i18next.com/overview/supported-frameworks)が用意されています。プラグインを使えば、HTTP経由でのファイル読み込みやユーザーの言語検出が可能で、`i18next-icu`を使えばメッセージ形式をICU MessageFormatに切り替えることもできます。 * **複数形と文脈の完全なサポート。** キーには`_one`、`_few`、`_many`などの[CLDR複数形サフィックス](https://www.i18next.com/translation-function/plurals)を付けることができ、`Intl.PluralRules`によって解決されます。`friend_male`のような文脈別のバリアントにも対応しています。 * **ツール。** 公式の[`i18next-cli`](https://github.com/i18next/i18next-cli)は、キーの抽出、TypeScript型の生成、各ロケールの複数形キーの書き出しを行います。また、`status`コマンドは未翻訳のキーを含むロケールがあるとエラーで終了するため、CIで翻訳漏れを検出できます。 * **サーバーコンポーネント。** [`next-i18next` 16](https://github.com/i18next/next-i18next)で、Next.js App Router向けのサーバーサイド翻訳関数が追加されました。 * **特定のサービスに依存しない。** カタログは自分で管理するプレーンなJSONです。i18nextはどの翻訳サービスとも組み合わせられ、翻訳サービスを使わなくても動作します。 ## i18next が開発者任せにしていること 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 (

{t('inbox.title')}

{t('inbox.unread', { count })}

); } ``` 他のすべての言語にも同じメッセージキーが必要で、各言語で使われる複数形をすべて用意しなければなりません。たとえばポーランド語には `unread_one`、`unread_few`、`unread_many`、`unread_other` が必要です。ポーランド語のファイルに英語の形式に合わせた `_one` と `_other` しかなく、[フォールバック言語](https://www.i18next.com/principles/fallback)が英語の場合、2 や 5 などの数では英語にフォールバックしてしまいます： ```text title="Output" pl, count 1: Masz 1 nieprzeczytaną wiadomość. pl, count 2: You have 2 unread messages. pl, count 5: You have 5 unread messages. pl, count 22: You have 22 unread messages. ``` CI で `i18next-cli status` を実行すれば、欠落している形式を検出できます。カタログの内容は翻訳サービスで生成できますが、アプリケーション側では引き続き `inbox.unread` のようなキーを参照します。これらのカタログを最新の状態に保つのは、抽出と翻訳のワークフローの役割です。 ## General Translation はテキストをインラインのまま管理し、翻訳を生成する General Translation のライブラリは、i18next と同じ役割を担います。ロケールごとにメッセージを選択し、そのロケールの複数形規則を適用し、変数を補間し、[``](/docs/react/reference/components/num)、[``](/docs/react/reference/components/currency)、[``](/docs/react/reference/components/datetime) で数値・通貨・日付を書式設定します。キーを使いたいチームは、[`useTranslations`](/docs/react/reference/hooks/use-translations) で辞書を管理することもできます。そのうえで General Translation は、i18next にはできないこと、つまり翻訳の生成まで行います。以下は、同じ受信トレイを `gt-react` で実装した例です。 ```tsx title="Inbox.tsx" import { T, Plural, Num } from 'gt-react'; export function Inbox({ count }: { count: number }) { return (

Inbox

You have {count} unread message.

} plural={

You have {count} unread messages.

} />
); } ``` [`npx gt translate`](/docs/cli/reference/commands/translate) は、ビルド前に各 [``](/docs/react/reference/components/t) ブロックを要素構造ごと General Translation API に送信し、すべての対象ロケールの翻訳を書き出します。汎用的な `singular` と `plural` の翻訳元分岐をもとに、各対象言語で必要な形の文言が生成されます。そのうえで、[``](/docs/react/reference/components/plural) がそのロケールの規則に従って翻訳済みの分岐を選択します。[``](/docs/react/reference/components/var) でラップした値が API に送信されることはありません。 [``](/docs/react/reference/components/t) 内の文を編集すると、次回の翻訳の実行時に各言語の翻訳が更新され、変更のないコンテンツについては既存の翻訳が再利用されます。レビュー担当者は [ダッシュボードの翻訳エディター](/docs/platform/dashboard/guides/reviewing-translations) で作業するため、翻訳を修正するためにコンポーネントを変更する必要はありません。 JavaScript ライブラリは MIT ライセンスで提供されており、翻訳を自前で用意すればアカウントなしで利用できます。すべての翻訳をバンドルから読み込むように設定したアプリでは、General Translation へのランタイム呼び出しは一切発生しません。また、`gt-react` や `gt-next` は内部で他の i18nライブラリに依存していません。 Cursor は General Translation を使って、Web サイトとドキュメントで 14 以上のロケールを展開しています。 ([本番環境でのデプロイ事例](https://generaltranslation.com/enterprise)をご覧ください。) ## i18next と General Translation の比較早見表 | 機能 | i18next | General Translation | | -------- | ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | テキストの書き方 | 言語・名前空間ごとの JSON ファイルにキーで記述 | [``](/docs/react/reference/components/t) 内の JSX、[`useGT`](/docs/react/reference/hooks/use-gt) による文字列、またはキー付きの辞書 | | コンテンツの翻訳 | なし | あり ([`npx gt translate`](/docs/cli/reference/commands/translate) を使用) | | 翻訳の提供元 | 開発者自身、翻訳者、または Locize などのサービス | コードの文脈を踏まえて生成、またはチームが作成 | | 複数形 | CLDR の形式ごとにキーを用意し、言語ごとに記述 | [``](/docs/react/reference/components/plural) の分岐として、ブロックの他の部分と一緒に翻訳 | | 翻訳の文脈 | 翻訳ワークフローから提供される翻訳元メッセージと文脈 | マークされた JSX ブロック内の構造、文脈メモ、共有の用語集とカスタムプロンプト | | フレームワーク | React、Next.js のほか、Vue、Angular、Svelte などのバインディング | React、Next.js、Vue、Node.js、および[その他の SDK](/docs/overview/get-started) | | アカウントの要否 | 不要 | ライブラリの利用には不要。翻訳は General Translation のプロジェクトを通じて実行 | 既存のカタログと翻訳プロセスがすでにうまく機能している場合、General Translation のライブラリが対応していないフレームワークで開発している場合、またはテキストを変更しても変わらない安定したキーを使いたい場合は、i18next を引き続き使うのがよいでしょう。テキストをコンポーネント内にインラインで記述したい場合、コードの文脈を踏まえた翻訳を生成したい場合、ビルドのたびにすべての言語を最新の状態に保ちたい場合は、General Translation がおすすめです。 ## i18nextはそのままで、General Translationに翻訳を任せる ライブラリを乗り換える必要はありません。`gt` CLIは`package.json`内の`i18next`を検出し、その補間構文をそのまま維持します。上記の受信トレイのカタログをドイツ語に翻訳する場合の設定は次のとおりです： ```json title="gt.config.json" { "defaultLocale": "en", "locales": ["de"], "files": { "json": { "include": ["locales/[locale]/translation.json"] } } } ``` 英語とドイツ語は、同じ `_one` と `_other` の複数形キー構造を使用します。この設定では、`locales/en/translation.json` から `locales/de/translation.json` が生成されます。文字列の表示場所など、キーごとの文脈は[キーごとのメタデータ](/docs/cli/reference/keyed-metadata)で追加できます。新しいテキストに対して [`npx gt translate`](/docs/cli/reference/commands/translate) を実行する前に、[`npx gt upload`](/docs/cli/reference/commands/upload) で翻訳元と既存の翻訳をインポートしてください。 [``](/docs/react/reference/components/t) に移行したい場合は、[i18nライブラリからの移行](/docs/react/guides/migrating-i18n-libraries)を参照してください。キーによる参照をインラインのテキストに置き換える方法、[`useTranslations`](/docs/react/reference/hooks/use-translations) で既存の辞書をそのまま使う方法、ルートを1つずつ移行しながら両方のライブラリを併用する方法を解説しています。 (i18next と他のライブラリの比較については、[General Translation と i18next、react-intl、next-intl の比較](/kb/general-translation-vs-i18n-libraries)を参照してください。) ## i18next でポーランド語など複数形の多い言語はどう扱えばよいですか？ 各言語には、その言語で使われるすべての CLDR 複数形に対応するキーが必要です。たとえばポーランド語では `_one`、`_few`、`_many`、`_other` が該当します。CI で `i18next-cli status` を実行すれば、不足している形式を検出できます。General Translation のインライン記述なら、上記のように `singular` と `plural` の分岐を書くだけで、翻訳サービスが対象言語の各形式を生成します。適切な形式は、ランタイムに [``](/docs/react/reference/components/plural) が選択します。 ## その他のi18next代替ライブラリ i18nextからの移行を検討しているチームは、以下のライブラリも比較検討しています。 * **react-intl:** ICUメッセージの書式設定を行い、FormatJSのカタログツールを提供します。 ([General Translation vs. react-intl](/kb/general-translation-vs-react-intl)を参照してください。) * **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:** 各コンポーネントのコンテンツを、全言語分を並べて記述した型付きの宣言ファイルで管理します。 ([General Translation vs. Intlayer](/kb/general-translation-vs-intlayer)を参照してください。) ## 重要なポイント * i18next はキーベースのカタログをレンダリングし、複数形の選択を処理します。翻訳自体は、人手または接続したサービスが作成します。 * General Translation のライブラリも同じように翻訳をレンダリングしますが、翻訳作業そのものも General Translation が担います。翻訳元となるのは、[``](/docs/react/reference/components/t) 内にインラインで記述したテキストです。 * i18next をそのまま使い続け、その JSON ファイルの翻訳を `gt` CLI に任せることも、ルート単位で段階的に [``](/docs/react/reference/components/t) へ移行することもできます。 ## 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はさらに、コードを文脈として活用しながら翻訳そのものも行います。 - [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 と 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: [Google 翻訳の代替：General Translation と Google 翻訳の比較](https://generaltranslation.com/ja/kb/general-translation-vs-google-translate.mdx) - Next question: [i18nは自前で構築すべきか、General Translationを使うべきか](https://generaltranslation.com/ja/kb/general-translation-vs-in-house-i18n.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/ja/kb/sitemap.md) for every article.