# General Translation Knowledge Base: General Translation と Symfony Translation の比較：どちらを使うべきか
URL: https://generaltranslation.com/ja/kb/general-translation-vs-symfony-translation.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: Symfony Translation は PHP と Twig でメッセージをレンダリングします。General Translation は CI で YAML カタログを翻訳し、翻訳元の変更に合わせて常に最新の状態に保つほか、レビュー担当者が翻訳を編集できる ダッシュボード も提供します。Symfony のレンダリングはそのままに、リリースワークフローに自動翻訳を組み込めます。
Category: 国際化
Last updated: 2026-10-16
Authors: Kevin Wu, Jackie Chen
Published: 2026-10-16

Symfony の Translation コンポーネントは、Symfony アプリでテキストを読者の言語で表示するための仕組みです。PHP の `trans()` や Twig の `|trans` フィルターが現在のロケールのカタログからキーを検索し、複数形や選択 (select) は ICU MessageFormat で処理します。このコンポーネントは翻訳の管理とレンダリングを担いますが、翻訳そのものを生成するわけではありません。各言語のカタログを作成するのは、開発者自身や翻訳者、あるいは Symfony と同期する翻訳管理システム (TMS) です。この抜け落ちた工程を担うのが General Translation です。General Translation の CLI が Symfony の YAML カタログを翻訳し、レンダリングはこれまでどおり Symfony が行います。

## Symfony Translation の得意なこと

* **PHP と Twig で共通の API。** `$translator->trans()`、[テンプレートで使える `|trans` フィルターと `{% trans %}` タグ](https://symfony.com/doc/current/translation.html#translations-in-templates)、そしてフラッシュメッセージのように作成時点では翻訳せず後から翻訳するメッセージ向けに、`TranslatableMessage` と組み合わせて使う `t()` が用意されています。
* **ドメインと多様なファイル形式。** カタログは `domain.locale.format`(`messages.fr.yaml`、`validators.fr.yaml`)という命名規則に従い、Symfony は YAML、XLIFF、PHP、JSON、PO および MO、CSV、INI、Qt、ICU リソースバンドルを読み込めます。[公式ドキュメントでは、シンプルなプロジェクトには YAML を](https://symfony.com/doc/current/translation.html#translation-resource-file-names-and-locations)、専用ツールや専門チームが翻訳を作成する場合には XLIFF を推奨しています。
* **ICU MessageFormat。** [カタログ名に `+intl-icu` を付ける](https://symfony.com/doc/current/reference/formats/message_format.html)(`messages+intl-icu.en.yaml`)と、そのカタログのメッセージで複数形、select、数値や日付の書式設定に ICU 構文を使えます。これには PHP の `intl` 拡張が必要です。Symfony のポリフィルは英語にしか対応していません。
* **抽出とチェック。** [`translation:extract` は Twig テンプレート、PHP コード、バリデーション制約からメッセージを抽出し](https://symfony.com/doc/current/translation.html#extracting-translation-contents-and-updating-catalogs-automatically)、カタログに追加します。`--format` を指定しなければ XLIFF 1.2 形式で出力されます。`debug:translation` は欠落・未使用・フォールバック中のメッセージを一覧表示し、`lint:translations` はカタログの内容を検証します。
* **フォールバック。** `es_AR` のメッセージがない場合は、[`es_419`、`es` の順にたどり、最終的に設定した代替ロケールへフォールバックします](https://symfony.com/doc/current/translation.html#fallback-translation-locales)。欠落はログに記録されます。
* **翻訳プロバイダー。** [`translation:push` と `translation:pull` を使えば、公式のブリッジパッケージを介して Crowdin、Loco、Lokalise、Phrase とカタログを同期できます](https://symfony.com/doc/current/translation.html#translation-providers)。独自のプロバイダーを作成することも可能です。
* **フレームワークのメッセージも同梱。** Validator コンポーネントには、50 以上の言語に翻訳済みの組み込み制約メッセージが付属しています。

このコンポーネントは [MIT ライセンスで提供されており、バージョン 8.1 には PHP 8.4.1 以降が必要です](https://packagist.org/packages/symfony/translation)。長期サポート(LTS)リリースは 7.4 です。

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

英語のカタログで ICU の複数形を書くと、次のようになります:

```yaml title="translations/messages+intl-icu.en.yaml"
inbox:
  title: Inbox
  unread: >-
    {count, plural,
      =0 {You have no unread messages.}
      one {You have # unread message.}
      other {You have # unread messages.}
    }
```

さらに、誰かが `messages+intl-icu.es.yaml` を手作業で作成しており、キーは同じで、複数形はスペイン語用に書き直されています。スタンドアロンのコンポーネント (`symfony/translation` 8.1.5) を使い、この 2 つとドイツ語をレンダリングすると次のようになります。

```php title="render.php"
<?php
require __DIR__.'/vendor/autoload.php';

use Symfony\Component\Translation\Loader\YamlFileLoader;
use Symfony\Component\Translation\Translator;

$translator = new Translator('en');
$translator->setFallbackLocales(['en']);
$translator->addLoader('yaml', new YamlFileLoader());

// +intl-icu サフィックスにより、messages ドメインで ICU MessageFormat が有効になります。
foreach (['en', 'es'] as $locale) {
    $file = __DIR__."/translations/messages+intl-icu.$locale.yaml";
    $translator->addResource('yaml', $file, $locale, 'messages+intl-icu');
}

foreach (['en', 'es', 'de'] as $locale) {
    echo $locale, ': ', $translator->trans('inbox.unread', ['count' => 3], 'messages', $locale), "\n";
}
```

```text title="Output"
en: You have 3 unread messages.
es: Tienes 3 mensajes sin leer.
de: You have 3 unread messages.
```

スペイン語が表示されるのは、人が翻訳したからです。ドイツ語にはカタログがないため、Symfony は何も告げずに英語へフォールバックします。本格的なアプリではこの欠落がログに記録され、`debug:translation de` でも一覧表示されますが、ドイツ語の訳文を書いてくれる仕組みはありません。新しいキーを追加するたびに、すべての言語でこのサイクルが繰り返されます。`translation:extract --force` は各カタログにキーを追加し、`__` をプレフィックスとして付けます (`--no-fill` を指定した場合は空になります) 。そのうえで、誰かが手作業で翻訳するか、プロバイダーコマンドで push/pull する TMS 上で翻訳することになります。プロバイダーが担うのはファイルの移動だけで、翻訳作業そのものや、それを行う TMS のプランは別途用意する必要があります。

## General TranslationとSymfonyアプリの連携

レンダリングはSymfonyに任せ、カタログの生成はGeneral TranslationのCLIに任せます。`yaml`エントリで翻訳ディレクトリを指定し、各ファイル名のロケール部分には`[locale]`を使用します：

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

[`npx gt translate`](/docs/cli/reference/commands/translate) は、`messages+intl-icu.en.yaml` や `validators.en.yaml` など、条件に一致するすべての英語カタログを読み込み、`messages+intl-icu.es.yaml`、`validators.es.yaml` をはじめとする各対象ロケールのファイルを書き出します。キーとドメイン名はそのまま保持されます。`translation:extract` で英語カタログに新しいキーを追加したら、CI でこのコマンドを実行してください。変更のないエントリには以前の翻訳が再利用されるため、毎回の実行で翻訳されるのは新規または変更されたテキストだけです。

Symfony では、次の点に注意してください。

* **ICU メッセージ。** Symfony が翻訳済みメッセージを ICU で書式設定できるよう、カタログ名の `+intl-icu` は残しておいてください。生成後は `lint:translations` を実行し、受信トレイのメッセージを件数 0、1、3 でプレビューして確認しましょう。
* **ロケールコード。** アプリで使っている既存のロケール名はそのまま使えます。`pt_BR` の場合は、`locales` に追加したうえで、`gt.config.json` に `"customMapping": { "pt_BR": { "code": "pt-BR" } }` を設定します。これにより CLI はブラジルポルトガル語で翻訳し、Symfony の命名規則に沿った `messages.pt_BR.yaml` というファイル名で書き出します ([`customMapping`](/docs/cli/reference/config#custom-mapping) を参照) 。
* **CI での Node.js。** CLI は npm パッケージなので、CI ジョブには Node.js が必要です。また、シークレットに `GT_API_KEY` と `GT_PROJECT_ID` を登録しておく必要があります ([CLI の設定](/docs/cli/guides/configuring#credentials)を参照) 。

General Translation はカタログを埋めるだけでなく、その一貫性も保ちます。コンテキストグループの用語集とカスタムプロンプトによって、割り当てられたすべてのプロジェクトに同じ用語とトーンが適用されます。さらに、チームは[ダッシュボードで翻訳をレビュー・編集](/docs/platform/dashboard/guides/reviewing-translations)できます。Symfony アプリ、ドキュメント、マーケティングサイトで同じコンテキストグループを使えば、製品用語を 3 つすべてで統一できます ([翻訳の文脈を定義する](/docs/platform/dashboard/guides/defining-context-for-translations)を参照) 。

## Symfony Translation と General Translation の比較

| 機能                | Symfony Translation                                | General Translation                                                 |
| ----------------- | -------------------------------------------------- | ------------------------------------------------------------------- |
| 役割                | PHP と Twig でメッセージを検索・レンダリングする                      | PHP と Twig の呼び出しが使用するカタログを生成する                                      |
| コンテンツの翻訳          | なし。プロバイダー経由で Crowdin、Loco、Lokalise、Phrase とカタログを同期 | あり。[`npx gt translate`](/docs/cli/reference/commands/translate) で翻訳 |
| カタログ形式            | YAML、XLIFF、PHP、JSON、PO/MO、CSV、INI、Qt、ICU リソースバンドル  | このカタログワークフローでは YAML と JSON                                          |
| 新しい文字列の検出         | `translation:extract` が Twig、PHP、制約をスキャン           | 英語のカタログに含まれる内容をすべて翻訳                                                |
| ICU MessageFormat | `intl` 拡張機能と `+intl-icu` カタログを使用                   | Symfony の ICU レンダラー向けにカタログの値を翻訳                                     |
| 未翻訳の扱い            | フォールバックチェーン、ログ、`debug:translation`                 | 実行のたびに、設定済みのすべてのロケールを書き出す                                           |
| コスト               | 無料 (MIT ライセンス) 。プロバイダーの料金は別途発生                     | [従量課金](https://generaltranslation.com/pricing)                      |

## どちらを使うべきか

レンダリングについては二者択一ではありません。Symfony アプリでは Symfony Translation をそのまま使い続けるべきです。検討すべきなのは、カタログをどのように埋めるかです。翻訳者が TMS 上で XLIFF を使って作業している場合、プロの翻訳者による人手による翻訳を発注している場合、あるいは現在のプロセスがすでにうまく回っている場合は、翻訳プロバイダーを引き続き利用してください ([TMS ではなく General Translation を使う理由](/kb/general-translation-vs-tms)を参照) 。変更のたびに CI で全ロケールの YAML カタログを翻訳し、用語の共有やレビューを ダッシュボード で行い、ファイルを送って戻りを待つ手間をなくしたい場合は、General Translation を使用してください。

## 両方を併用する

1. まず Symfony の YAML カタログを用意し、上記のとおり `gt.config.json` を追加します。
2. 既存の翻訳がある場合は、新しい翻訳を生成する前に [`npx gt upload`](/docs/cli/reference/commands/upload) でアップロードします。
3. Symfony が新しいメッセージを英語のカタログに抽出したら、CI で [`npx gt translate`](/docs/cli/reference/commands/translate) を実行します。
4. ダッシュボードで翻訳を確認します。ダウンロードした YAML をローカルで編集した場合は、次回の生成を実行する前に [`npx gt save-local`](/docs/cli/reference/commands/save-local) で同期してください。

## 重要なポイント

* Symfony Translation はメッセージのレンダリング、キーの抽出、TMS プロバイダーとの同期を担いますが、翻訳の作成自体は別途行う必要があります。
* General Translation は CI 上で Symfony の YAML カタログを翻訳します。キーとドメインはそのまま維持されるため、PHP や Twig からは引き続き同じメッセージを利用できます。
* XLIFF やプロの翻訳者を活用するなら TMS プロバイダーを引き続き使い、変更のたびにカタログを翻訳したい場合は General Translation を使いましょう。

## 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はさらに、コードを文脈として活用しながら翻訳そのものも行います。
- [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 はコード内のコンテンツを文脈ごと翻訳し、リリースのたびに全言語をまとめて提供します。ロックインのないオープンソースのライブラリ上で動作します。
- [General Translation と GNU gettext：両方必要か？](https://generaltranslation.com/ja/kb/general-translation-vs-gettext.mdx): 抽出とレンダリングには GNU gettext を引き続き使い、PO ファイルの生成と保守には General Translation を導入しましょう。General Translation は翻訳者向けメモやメッセージの文脈を生成に反映し、共通の用語を適用するほか、レビュー担当者向けに ダッシュボード エディターを提供します。既存の gettext 呼び出しやコンパイル済みのカタログには手を加える必要はありません。
- [General Translation と Rails I18n：両方必要か？](https://generaltranslation.com/ja/kb/general-translation-vs-rails-i18n.mdx): Rails I18n はメッセージの検索と、日付や数値の書式設定を担います。General Translation は翻訳を生成し、英語の変更に合わせて翻訳を常に最新の状態に保つほか、チームでレビューできるダッシュボードも提供します。両者を組み合わせれば、リリースのたびに翻訳済みの Rails カタログを出荷できます。
- [General Translation と Django の翻訳フレームワーク：両方必要なのか？](https://generaltranslation.com/ja/kb/general-translation-vs-django-i18n.mdx): Django の翻訳フレームワークと General Translation は併用できます。メッセージの抽出、言語の選択、レンダリングは Django が担当し、General Translation は製品の用語とダッシュボードでのレビュー内容を反映して、複数形を含む PO ファイルに翻訳を書き込みます。テンプレートや URL パターンはそのままで、翻訳はコードの変更に合わせて更新されます。

## Previous and next questions

- Previous question: [General Translation と Rails I18n：両方必要か？](https://generaltranslation.com/ja/kb/general-translation-vs-rails-i18n.mdx)
- Next question: [General Translation と Tolgee の比較：どちらを使うべきか？](https://generaltranslation.com/ja/kb/general-translation-vs-tolgee.mdx)

## Sitemap

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