# General Translation Knowledge Base: General Translation と Babel・Flask-Babel の比較：どちらを使うべきか URL: https://generaltranslation.com/ja/kb/general-translation-vs-flask-babel.mdx Docs index: https://generaltranslation.com/llms.txt Description: Babel はあらゆるロケールの日付、数値、通貨を書式設定し、gettext カタログを管理します。Flask-Babel はそれを Flask と連携させるライブラリですが、どちらも文字列の翻訳までは行いません。General Translation の CLI は、Babel の PO ファイルを複数形も含めて全言語分自動で埋めるため、Flask-Babel はそのままに、カタログを手作業で翻訳する手間から解放されます。 Category: 国際化 Last updated: 2026-10-16 Authors: Kevin Wu, Jackie Chen Published: 2026-10-16 Babel は Unicode CLDR データを使って日付、数値、通貨を書式設定し、`pybabel` コマンドで gettext メッセージカタログの抽出、更新、コンパイルを行います。Flask-Babel は、これらのツールを Flask のリクエスト処理や Jinja テンプレートと連携させます。General Translation は抽出からコンパイルまでの間にカタログを埋めるため、既存の Flask-Babel のセットアップはそのままに、アプリに自動翻訳を導入できます。 ## Babel と Flask-Babel の強み * **CLDR に基づくロケールフォーマット。** [Babel 2.18.0 には CLDR 47](https://babel.pocoo.org/en/latest/changelog.html#version-2-18-0) のデータが同梱されており、1,000 を超えるロケール識別子に対応しています。たとえば `format_currency(1234.5, "EUR")` はスペイン語で "1.234,50 €" を、`format_date` はポーランド語で "16 października 2026" を返します。 * **カタログツール。** [`pybabel extract`](https://babel.pocoo.org/en/latest/cmdline.html) は `babel.cfg` のマッピングに従って Python ファイルと Jinja テンプレートを読み込みます。`pybabel init` は適切な複数形規則とスロット(ポーランド語では 3 つ)を備えた PO ファイルを生成し、`pybabel update` は新しい文字列をマージしつつ変更された文字列に fuzzy マークを付け、`pybabel compile` は `.mo` ファイルをビルドします。 * **Flask インテグレーション。** `locale_selector` と `timezone_selector` で[リクエストごとのロケールとタイムゾーンを決定](https://python-babel.github.io/flask-babel/#configuration)でき、`lazy_gettext` はインポート時に定義される文字列を扱えます。Jinja テンプレートでは `_()`、`{% trans %}`、フォーマット用フィルターが使えるほか、`force_locale` でロケールを一時的に切り替えられるため、別の言語でメールを送信するといった用途にも対応できます。 * **安定性があり無料。** どちらも BSD ライセンスです([Babel のライセンス](https://babel.pocoo.org/en/latest/license.html)を参照)。Babel はあらゆる Python プログラムで利用でき、Flask-Babel の[現在のリリースは 4.0.0](https://github.com/python-babel/flask-babel/releases/tag/v4.0.0) です。 ## Babel と Flask-Babel が開発者任せにしていること 以下は、シンプルな Flask-Babel アプリの例です。 ```python title="app.py" from datetime import date from flask import Flask, request from flask_babel import Babel, gettext, ngettext, format_currency, format_date def select_locale(): return request.accept_languages.best_match(["en", "es", "pl"]) app = Flask(__name__) babel = Babel(app, locale_selector=select_locale) @app.route("/inbox/") def inbox(count): return { "title": gettext("Inbox"), "unread": ngettext("You have %(num)d unread message.", "You have %(num)d unread messages.", count), "price": format_currency(1234.5, "EUR"), "date": format_date(date(2026, 10, 16), format="long"), } ``` `pybabel extract`、`pybabel init -l pl`、`pybabel compile` を実行すると、すべての `msgstr` が空のポーランド語カタログが生成されます。この状態で Flask-Babel 4.0.0 に `Accept-Language: pl` を指定したリクエストを送ると、次のレスポンスが返されました: ```json title="Output" { "date": "16 października 2026", "price": "1 234,50 €", "title": "Inbox", "unread": "You have 5 unread messages." } ``` Babel はポーランド語向けに日付と価格を書式設定してくれますが、文字列はすべて英語のまま残り、警告も一切出ません。各文字列は、誰かがポーランド語の 3 つの複数形すべてを含めて PO エントリを埋めるまで待たされ、その後さらに `pybabel compile` と再デプロイを待つことになります。文字列を追加・編集するたびに、言語ごとにこの作業を繰り返さなければなりません。 ## General Translation で Babel のカタログを翻訳する Flask-Babel ですでに問題なく運用できている場合は、そのまま使い続け、カタログの書き出しは General Translation の CLI に任せましょう。英語のカタログを一度作成し、抽出のたびに更新してください。こうすることで、翻訳元が翻訳と同じツリー内に配置されます： ```bash pybabel extract -F babel.cfg -k lazy_gettext -o messages.pot . pybabel init -i messages.pot -d translations -l en # 初回のみ pybabel update -i messages.pot -d translations -l en # 抽出するたびに実行 ``` 次に、`gt.config.json` でそのファイルを指定します。この設定は `gt` 2.26.5 で動作確認済みです。 ```json title="gt.config.json" { "defaultLocale": "en", "locales": ["es", "pl", "pt_BR"], "customMapping": { "pt_BR": { "code": "pt-BR" } }, "files": { "pot": { "include": ["translations/[locale]/LC_MESSAGES/messages.po"], "transformationFormat": "PO" } } } ``` `pot` キーは PO および POT ファイルを読み込み、`"transformationFormat": "PO"` は翻訳済みの `.po` ファイルを書き出します ([PO / POT フォーマットのリファレンス](/docs/cli/reference/formats/po-pot-files)を参照) 。[`customMapping`](/docs/cli/reference/config#custom-mapping) は、Babel の `pt_BR` ディレクトリを標準のロケールコード `pt-BR` に対応付けます。まず [CLI](/docs/cli/quickstart) をセットアップしてください。既存の翻訳がある場合は、新しい翻訳を生成する前に [`npx gt upload`](/docs/cli/reference/commands/upload) でインポートします。その後 [`npx gt translate`](/docs/cli/reference/commands/translate) を実行し、続けて `pybabel compile -d translations` を実行します。 General Translation は、各エントリを `msgctxt`、翻訳者向けコメント、ソース参照、フラグとともに文脈として送信します。複数形のエントリでは、対象言語の `Plural-Forms` ヘッダーを書き込んだうえで、すべての `msgstr[n]` スロットを埋めます。そのため、ポーランド語であれば3つの形がすべて揃います。また、`%(num)d` などのプレースホルダーが崩れずに保持されているかも検証します。変更のないエントリについては、次回の実行時に以前の翻訳がそのまま再利用されます。[コンテキストグループ](/docs/platform/dashboard/guides/defining-context-for-translations)に用語集とカスタムプロンプトを設定しておけば、カタログと製品のその他の部分とで用語を統一できます。また、レビュー担当者はダッシュボードで[各エントリを編集](/docs/platform/dashboard/guides/reviewing-translations)できます。CI で CLI を実行すれば、デプロイのたびに最新のカタログが反映されます。その後ローカルでの編集を加えた場合は、再度生成する前に [`npx gt save-local`](/docs/cli/reference/commands/save-local) で保存してください。 ## Babel・Flask-Babel と General Translation の比較 | 機能 | Babel と Flask-Babel | General Translation | | --------------- | ----------------------------------------------------- | ---------------------------------------------------------------------- | | 文字列の書き方 | `gettext` 呼び出しと Jinja の `{% trans %}` で記述し、PO ファイルに抽出 | これらの呼び出しとテンプレートはそのまま使い、抽出されたカタログを翻訳 | | コンテンツの翻訳 | なし | あり ([`npx gt translate`](/docs/cli/reference/commands/translate) を使用) | | 複数形 | `pybabel init` がスロットを生成し、各スロットは手動で埋める | 対象言語に必要なすべての PO スロットを生成 | | 日付・数値・通貨のフォーマット | あり (CLDR に基づく) | Babel のフォーマットをそのまま利用 | | Jinja テンプレート | あり | 既存のテンプレートから抽出されたメッセージを翻訳 | | フレームワーク | Babel はあらゆる環境で利用可能、Flask-Babel は Flask 向け | Flask などの gettext アプリケーションの PO カタログに対応した CLI | | ライセンス | BSD | MIT ライセンスの CLI | | 費用 | 無料 | [従量課金制の翻訳](https://generaltranslation.com/pricing) | ## 使い分けの目安 翻訳者や TMS から必要なカタログがすでに納品されている場合は、現在の翻訳プロセスをそのまま続けてください。新規・変更されたメッセージを開発中に翻訳したい場合や、チームがプロジェクト間で共有している用語管理・レビューツールを活用したい場合は、General Translation を導入しましょう。Jinja、リクエストのロケール、日付、通貨は引き続き Flask-Babel が処理するため、アプリケーションコードを変更する必要はありません。 ## 重要なポイント * Babel はあらゆるロケールに対応した日付・数値・通貨の書式設定と gettext カタログの管理を担い、Flask-Babel はそれを Flask に統合します。ただし、どちらも文字列そのものを翻訳するわけではありません。 * General Translation の CLI は、`pot` キー、`"transformationFormat": "PO"`、そして `pt_BR` のようなディレクトリ用の `customMapping` を使って Babel の PO ファイルを翻訳し、言語ごとにすべての複数形スロットを埋めます。 * Flask-Babel のレンダリングとフォーマットはそのまま活かし、既存の翻訳をインポートしたうえで、抽出とコンパイルの間に General Translation を組み込みましょう。 ## Related questions - [General Translation と GNU gettext：両方必要か？](https://generaltranslation.com/ja/kb/general-translation-vs-gettext.mdx): 抽出とレンダリングには GNU gettext を引き続き使い、PO ファイルの生成と保守には General Translation を導入しましょう。General Translation は翻訳者向けメモやメッセージの文脈を生成に反映し、共通の用語を適用するほか、レビュー担当者向けに ダッシュボード エディターを提供します。既存の gettext 呼び出しやコンパイル済みのカタログには手を加える必要はありません。 - [General Translation と Django の翻訳フレームワーク：両方必要なのか？](https://generaltranslation.com/ja/kb/general-translation-vs-django-i18n.mdx): Django の翻訳フレームワークと General Translation は併用できます。メッセージの抽出、言語の選択、レンダリングは Django が担当し、General Translation は製品の用語とダッシュボードでのレビュー内容を反映して、複数形を含む PO ファイルに翻訳を書き込みます。テンプレートや URL パターンはそのままで、翻訳はコードの変更に合わせて更新されます。 - [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 はコード内のコンテンツを文脈ごと翻訳し、リリースのたびに全言語をまとめて提供します。ロックインのないオープンソースのライブラリ上で動作します。 - [翻訳ファイルなしで i18n はできますか？](https://generaltranslation.com/ja/kb/i18n-without-translation-files.mdx): はい。gt-react または gt-next を使えば、コンテンツは `` コンポーネントで囲んだままコンポーネント内にインラインで記述でき、翻訳はビルド時に出力として生成されます。そのため、キーやロケールごとの JSON ファイルを作成したり、同期を保ったりする必要はありません。 ## Previous and next questions - Previous question: [General Translation vs. i18next、react-intl、next-intl：どのi18nライブラリを使うべきか？](https://generaltranslation.com/ja/kb/general-translation-vs-i18n-libraries.mdx) - Next question: [General Translation と Django の翻訳フレームワーク：両方必要なのか？](https://generaltranslation.com/ja/kb/general-translation-vs-django-i18n.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/ja/kb/sitemap.md) for every article.