# General Translation Knowledge Base: General Translation と Django の翻訳フレームワーク：両方必要なのか？
URL: https://generaltranslation.com/ja/kb/general-translation-vs-django-i18n.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: Django の翻訳フレームワークと General Translation は併用できます。メッセージの抽出、言語の選択、レンダリングは Django が担当し、General Translation は製品の用語とダッシュボードでのレビュー内容を反映して、複数形を含む PO ファイルに翻訳を書き込みます。テンプレートや URL パターンはそのままで、翻訳はコードの変更に合わせて更新されます。
Category: 国際化
Last updated: 2026-10-16
Authors: Kevin Wu, Jackie Chen
Published: 2026-10-16

Django には完全な国際化 (i18n) フレームワークが組み込まれています。`gettext` や `{% translate %}` で文字列をマークすると、`makemessages` がそれらを言語ごとの PO ファイルに抽出し、`compilemessages` が Django の読み込む `.mo` ファイルをビルドします。そして `LocaleMiddleware` がリクエストごとに言語を選択します。General Translation は、この抽出とコンパイルの間に翻訳のステップを加えます。General Translation の CLI が英語のカタログを読み取り、Django が読み込む翻訳済みの PO ファイルを書き出します。

## Video

The video is narrated in English, with English captions.

[General Translation vs. Django's translation framework: do you need both?](https://caxecubb9c64cezv.public.blob.vercel-storage.com/films/kb-general-translation-vs-django-i18n.mp4) (46 秒)

Use both: Django extracts messages, selects the language, and renders, and General Translation fills its PO files, plural forms included, with your terminology and Dashboard review. To set it up, keep running makemessages, point `gt.config.json` at your locale folders, and run `npx gt translate` before compilemessages in CI. A Glossary keeps terms consistent, and reviewers edit entries in the Dashboard.

## Django の翻訳フレームワークが優れている点

* **あらゆる場所で文字列をマークできる。** `gettext` と `ngettext` は [Python コードに対応](https://docs.djangoproject.com/en/5.2/topics/i18n/translation/#internationalization-in-python-code)し、`gettext_lazy` はモデルフィールドやフォームのラベルなど、インポート時に定義される文字列に対応します。`pgettext` は曖昧な単語に文脈を付加でき、テンプレートでは `{% translate %}` と `{% blocktranslate %}` (複数形には `count` を使用) を利用できます。
* **抽出とコンパイルを標準搭載。** `makemessages` は GNU gettext の `xgettext` を Python ファイルとテンプレートに対して実行し、[新しい文字列を言語ごとの `django.po` ファイルにマージ](https://docs.djangoproject.com/en/5.2/topics/i18n/translation/#message-files)します (配置先は `locale/<locale>/LC_MESSAGES/`) 。文字列の直前に `# Translators:` コメントを書くと、そのコメントが PO ファイルに出力され、翻訳者が参照できます。
* **リクエストごとに言語を選択。** `LocaleMiddleware` は、まず `i18n_patterns` が付加した [URL プレフィックスを確認](https://docs.djangoproject.com/en/5.2/topics/i18n/translation/#how-django-discovers-language-preference)し、続いて言語クッキー、`Accept-Language` ヘッダー、`LANGUAGE_CODE` の順にチェックします。選択対象は `LANGUAGES` に列挙された言語のみで、`de-at` が見つからない場合は `de` にフォールバックします。
* **文字列以外にも対応。** 日付や数値は[アクティブなロケールに合わせてフォーマット](https://docs.djangoproject.com/en/5.2/topics/i18n/formatting/)され、`JavaScriptCatalog` はブラウザ向けに別途 `djangojs` カタログを配信します。
* **Django 自体が翻訳済み。** 管理画面や組み込みアプリには[約 100 言語分のカタログが同梱](https://github.com/django/django/tree/stable/5.2.x/django/contrib/admin/locale)されており、フレームワーク自体も BSD ライセンスのもとで無料で利用できます。

## Django が開発者に委ねていること

[Django の公式ドキュメント](https://docs.djangoproject.com/en/5.2/topics/i18n/translation/#compiling-message-files)には、Django 自体が担わないステップが説明されています。翻訳者がメッセージファイルへの記入を終えたら、そのファイルをコンパイルする、というステップです。以下は複数形を含むテンプレートの例です。

```html title="shop/templates/shop/inbox.html"
{% load i18n %}
<p>{% blocktranslate count counter=count %}{{ counter }} file{% plural %}{{ counter }} files{% endblocktranslate %}</p>
```

Django 5.2 では、`python manage.py makemessages -l ru` を実行すると、ロシア語の4形式の複数形規則が Django 本体のカタログからヘッダーにコピーされますが、エントリには空のスロットが2つしか書き込まれません：

```text title="locale/ru/LC_MESSAGES/django.po"
"Plural-Forms: nplurals=4; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 && "
"n%10<=4 && (n%100<12 || n%100>14) ? 1 : n%10==0 || (n%10>=5 && n%10<=9) || "
"(n%100>=11 && n%100<=14)? 2 : 3);\n"

#: shop/templates/shop/inbox.html:2
#, python-format
msgid "%(counter)s file"
msgid_plural "%(counter)s files"
msgstr[0] ""
msgstr[1] ""
```

テストでは、この2つのスロットだけを埋めたカタログでも `compilemessages` はエラーなくビルドでき、ページには &quot;1 файл&quot; と &quot;3 файла&quot; が表示されました。ところが件数が5の場合は、英語の &quot;5 files&quot; が表示されました。5に対してルールが選ぶスロットが、一度も埋められていなかったためです。空のカタログも同じく、エラーを出さないまま失敗します。`pt_BR` に何もない状態では、`/pt-br/` のページはすべて英語でレンダリングされました。しかも新しい文字列をマークするたびに、すべての言語でこのサイクルを繰り返すことになります。

さらに、Django が対応するのはコード内の文字列までです。製品名やページなど、データベースに保存されたコンテンツを翻訳するには、サードパーティ製のパッケージが必要になります。django-modeltranslation は登録したモデルに[言語ごとのフィールドを追加](https://django-modeltranslation.readthedocs.io/en/latest/registration.html)し、django-parler は翻訳を別テーブルに保持します。どちらも翻訳の保存先は用意してくれますが、翻訳そのものを作成してくれるわけではありません。

## General TranslationでDjangoのPOファイルを翻訳する

General TranslationのCLIは、Djangoがすでに管理している英語のカタログを読み込んですべてのエントリを翻訳し、各対象言語のPOファイルをDjangoが参照する場所に書き出します。英語のカタログは`makemessages`で常に最新の状態に保っておきましょう：

```bash
python manage.py makemessages -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": ["locale/[locale]/LC_MESSAGES/*.po"],
      "transformationFormat": "PO"
    }
  }
}
```

ここで押さえておくべき点がいくつかあります。詳細はすべて [PO / POT 形式リファレンス](/docs/cli/reference/formats/po-pot-files)で説明しています。

* **PO ファイルと POT ファイルのどちらでも、キーは `pot` です。** `transformationFormat` は `PO` にする必要があります。指定しない場合、出力は未翻訳のテンプレートのままになります。
* **ロケールディレクトリには Django の名前を使用します。** CLI は `[locale]` を、記述したとおりの各ロケールにそのまま置き換えます。[`customMapping`](/docs/cli/reference/config#custom-mapping) を使うと、Django の `pt_BR` ディレクトリを標準のロケールコード `pt-BR` に対応付けられます。
* **`*.po` はすべてのドメインを対象にします。** `makemessages -d djangojs -l en` も実行している場合は、`djangojs.po` も含まれます。

CLI をセットアップしたら ([CLI クイックスタート](/docs/cli/quickstart)を参照) 、[`npx gt translate`](/docs/cli/reference/commands/translate) を実行し、続けて `python manage.py compilemessages` を実行します。General Translation は、各エントリについて PO ファイルが持つ情報を文脈として一緒に送信します。具体的には、`msgctxt`、`# Translators:` コメント、ソース参照、`python-format` などのフラグです。複数形のエントリでは、対象言語の `Plural-Forms` ヘッダーを書き込み、そのヘッダーが必要とするすべての `msgstr[n]` スロットを埋めます。また、`%(counter)s` のようなプレースホルダーが崩れずに保持されているかも確認します。ロシア語の場合は、標準的な 3 形式の gettext ルールが使われます。Django はカタログごとにルールを個別に読み込むため、Django 自体のロシア語カタログにある 4 形式のルールと競合することはありません。

変更のないエントリは以前の翻訳を再利用するため、次回の実行では変更された部分だけが翻訳されます。すべてを再翻訳するには `--force` を指定します。PO ファイルに既存の翻訳がある場合は、新しい翻訳を生成する前に [`npx gt upload`](/docs/cli/reference/commands/upload) を実行してください。その後のローカルでの編集を残したい場合は、次の翻訳を実行する前に [`npx gt save-local`](/docs/cli/reference/commands/save-local) で同期してください。

ここでフルスタックが真価を発揮します。[コンテキストグループ](/docs/platform/dashboard/guides/defining-context-for-translations)の用語集とカスタムプロンプトを使えば、Django のカタログと、そのグループに割り当てられた他のプロジェクトとの間で、製品用語やトーンを統一できます。レビュー担当者はダッシュボードで、複数形も含めて[各 PO エントリを編集](/docs/platform/dashboard/guides/reviewing-translations)できます。CI で `makemessages`、[`gt translate`](/docs/cli/reference/commands/translate)、`compilemessages` を実行すれば、リリースのたびに翻訳を更新できます。

データベースのコンテンツなど、実行時にしか存在しないテキストについては、General Translation の API でリクエストごとに文字列を翻訳できます ([`POST /v2/translate`](/docs/platform/openapi/reference/translation/translate-content)) 。結果の保存はご自身で行ってください。たとえば django-modeltranslation の言語別フィールドに保存できます。

CLI を実行するマシンには Node.js をインストールしてください。コンパイル済みのカタログは、これまでどおり Django が既存の Python ランタイムで提供します。

## Django の翻訳フレームワークと General Translation の比較

| 機能                          | Django の翻訳フレームワーク                                                                              | General Translation                                             |
| --------------------------- | ---------------------------------------------------------------------------------------------- | --------------------------------------------------------------- |
| コードとテンプレート内の文字列のマーク付け       | 対応：`gettext`、`{% translate %}` など                                                              | 既存の Django のメッセージ呼び出しをそのまま使用                                    |
| PO ファイルへの文字列の抽出             | 対応：`makemessages`                                                                              | `makemessages` が出力したファイルを読み込む                                   |
| 翻訳の書き込み                     | 非対応                                                                                            | 対応：[`npx gt translate`](/docs/cli/reference/commands/translate) |
| 複数形                         | Django のカタログのヘッダーを使用し、各スロットは手動で埋める                                                             | 対象言語のヘッダーを書き込み、すべてのスロットを自動で埋める                                  |
| 翻訳のための文脈                    | PO ファイル内の `# Translators:` コメントと `msgctxt`                                                     | 同様に対応し、さらに用語集とカスタムプロンプトも利用可能                                    |
| リクエストごとの言語切り替えと URL プレフィックス | 対応：`LocaleMiddleware` と `i18n_patterns`                                                        | Django のルーティングと言語選択をそのまま利用                                      |
| データベースのコンテンツ                | django-modeltranslation などのサードパーティパッケージ                                                        | ランタイムの API 翻訳 (結果の保存はユーザー側で行う)                                  |
| コスト                         | 無料のオープンソース ([BSD](https://docs.djangoproject.com/en/5.2/faq/general/#how-is-django-licensed))  | [従量課金制の翻訳料金](https://generaltranslation.com/pricing)            |

## どちらを使うべきか

翻訳者や翻訳管理システムがすでに PO ファイルを埋めている場合、提供言語が 1〜2 言語だけで手作業でも翻訳できる場合、あるいはすべての翻訳を人の手で書く必要がある場合は、Django のフレームワークを単体で使用してください。変更のたびにすべての言語の PO ファイルを埋め、複数形を漏れなく揃え、用語の一貫性を保ちたい場合、しかもマージからリリースまでの間に翻訳作業を挟みたくない場合は、General Translation を追加しましょう。

どちらか一方を選ぶ必要はありません。マーキング、抽出、コンパイル、言語選択は Django が担い、翻訳は General Translation が担います。テンプレート、ミドルウェア、URL パターンはそのままなので、移行作業は一切不要です。

## 重要なポイント

* Django の翻訳フレームワークは翻訳をレンダリングするだけで、翻訳そのものは作成しません。複数形のスロットが欠けていたり、カタログが空だったりしても、ビルドエラーにはならず英語にフォールバックします。
* General Translation は、`makemessages` で生成された英語のカタログを、言語ごとの PO ファイルに翻訳します。テンプレート、ミドルウェア、URL パターンは変更せずにそのまま使えます。
* General Translation は各複数形エントリに対して、対象言語の `Plural-Forms` ヘッダーとすべての `msgstr[n]` スロットを書き込みます。また、`msgctxt` と翻訳者向けコメントを文脈として渡します。

## 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 と Babel・Flask-Babel の比較：どちらを使うべきか](https://generaltranslation.com/ja/kb/general-translation-vs-flask-babel.mdx): Babel はあらゆるロケールの日付、数値、通貨を書式設定し、gettext カタログを管理します。Flask-Babel はそれを Flask と連携させるライブラリですが、どちらも文字列の翻訳までは行いません。General Translation の CLI は、Babel の PO ファイルを複数形も含めて全言語分自動で埋めるため、Flask-Babel はそのままに、カタログを手作業で翻訳する手間から解放されます。
- [General Translation と Rails I18n：両方必要か？](https://generaltranslation.com/ja/kb/general-translation-vs-rails-i18n.mdx): Rails I18n はメッセージの検索と、日付や数値の書式設定を担います。General Translation は翻訳を生成し、英語の変更に合わせて翻訳を常に最新の状態に保つほか、チームでレビューできるダッシュボードも提供します。両者を組み合わせれば、リリースのたびに翻訳済みの Rails カタログを出荷できます。
- [General Translation と TMS（Crowdin、Lokalise、Phrase）の比較](https://generaltranslation.com/ja/kb/general-translation-vs-tms.mdx): 翻訳の生成、コードから導出した文脈、レビューをプロダクトのリリースと連動させたい開発チームには General Translation が適しています。既存のカタログとレンダリングライブラリをそのまま使うことも、翻訳キーを使わずにインライン JSX を記述することもできます。TMS は、言語ベンダー、CAT エディター、XLIFF でのやり取りを中心とした翻訳プログラムに適しており、そのインテグレーションを使えばファイル転送を自動化できます。
- [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はさらに、コードを文脈として活用しながら翻訳そのものも行います。

## Previous and next questions

- Previous question: [General Translation と Babel・Flask-Babel の比較：どちらを使うべきか](https://generaltranslation.com/ja/kb/general-translation-vs-flask-babel.mdx)
- Next question: [General Translation と GNU gettext：両方必要か？](https://generaltranslation.com/ja/kb/general-translation-vs-gettext.mdx)

## Sitemap

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