# General Translation Knowledge Base: General Translation と GNU gettext：両方必要か？
URL: https://generaltranslation.com/ja/kb/general-translation-vs-gettext.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: 抽出とレンダリングには GNU gettext を引き続き使い、PO ファイルの生成と保守には General Translation を導入しましょう。General Translation は翻訳者向けメモやメッセージの文脈を生成に反映し、共通の用語を適用するほか、レビュー担当者向けに ダッシュボード エディターを提供します。既存の gettext 呼び出しやコンパイル済みのカタログには手を加える必要はありません。
Category: 国際化
Last updated: 2026-10-16
Authors: Kevin Wu, Jackie Chen
Published: 2026-10-16

GNU gettext は、今なおソフトウェア翻訳の大半を支えるツールチェーンです。ユーザー向けの文字列を `_()` または `gettext()` でラップすると、`xgettext` がそれらを POT テンプレートに抽出し、`msginit` が言語ごとに PO ファイルを作成します。翻訳元が変更されれば `msgmerge` がそれらのファイルを更新し、最後に `msgfmt` が、プログラムが実行時に読み込む `.mo` ファイルへとコンパイルします。C プログラム、PHP の gettext 拡張、Python の `gettext` モジュール、WordPress、Django、Babel はいずれもこの形式を採用しています。一方で、翻訳作業の大部分は gettext の守備範囲外です。バージョン 1.0 以降はローカル LLM でエントリの下書きを作成できるようになりましたが、すべての PO ファイルのすべての `msgstr` を仕上げるのは、あなた自身や翻訳者、あるいは外部サービスです。General Translation はツールチェーンのどの部分も置き換えません。CLI がテンプレートから PO ファイルを書き出すだけなので、gettext のそれ以外のセットアップはそのまま使い続けられます。

## gettext の優れている点

* **原文がそのままキーになる。** コードには `_("Inbox")` のように原文を記述し、キー名は使いません。翻訳がない文字列はエラーにならず、[原文にフォールバック](https://www.gnu.org/software/gettext/manual/html_node/Interface-to-gettext.html)します。
* **言語ごとの複数形規則。** 各 PO ファイルには[その言語の規則を記した `Plural-Forms` ヘッダー](https://www.gnu.org/software/gettext/manual/html_node/Plural-forms.html)が含まれ、`msginit` が自動で記入します。たとえばポーランド語には 3 形式の規則が適用され、複数形のエントリごとに 3 つの `msgstr[n]` スロットが用意されます。
* **文脈が文字列とともに受け渡される。** `msgctxt` (`pgettext` から生成) は[動詞の "Archive" と名詞の "Archive" を区別](https://www.gnu.org/software/gettext/manual/html_node/Contexts.html)し、`#.` コメントは翻訳者へのメモを伝え (`xgettext --add-comments`) 、`#:` 行はソースコード上の位置を示します。さらに `python-format` などのフラグを付けておけば、プレースホルダーを壊す翻訳を `msgfmt --check` で検出して却下できます。
* **安全な更新。** `msgmerge` は[テンプレートが変更されても既存の翻訳を保持](https://www.gnu.org/software/gettext/manual/html_node/msgmerge-Invocation.html)し、原文が変更されたエントリには fuzzy マークを付けます。比較用に変更前の原文を残すこともできます (`--previous`) 。
* **ローカル LLM による下訳。** バージョン 1.0 以降は、[`msgpre` と `spit` を使い、ollama 経由でローカルの LLM により PO ファイルを事前翻訳](https://www.gnu.org/software/gettext/manual/html_node/Pretranslating.html)できます。これを叩き台として翻訳者がレビューします。
* **幅広いサポート。** PO は Poedit などの PO エディターや、ほとんどの翻訳管理システム (TMS) が読み書きできる形式です。ツール自体も[フリーソフトウェア](https://www.gnu.org/software/gettext/manual/html_node/Licenses.html)です (GPL。ランタイムライブラリは LGPL) 。

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

以下は、標準ライブラリの `gettext` モジュールを使った簡単な Python スクリプトです。

```python title="inbox.py"
import gettext, sys

lang = sys.argv[1]
count = int(sys.argv[2])
t = gettext.translation("inbox", localedir="locale", languages=[lang], fallback=True)
_ = t.gettext

# TRANSLATORS: 受信トレイページの見出し
print(_("Inbox"))
print(t.ngettext("You have %d unread message.", "You have %d unread messages.", count) % count)
print(t.pgettext("email verb", "Archive"))
```

[GNU gettext 1.0](https://lists.gnu.org/archive/html/info-gnu/2026-01/msg00007.html) を使った gettext のワークフローは次のとおりです。

```bash
xgettext --language=Python --keyword=pgettext:1c,2 --add-comments=TRANSLATORS -o po/inbox.pot inbox.py
msginit --no-translator --locale=pl_PL.UTF-8 -i po/inbox.pot -o po/pl.po
# po/pl.po のすべての msgstr に誰かが訳文を記入する
msgfmt --check -o locale/pl/LC_MESSAGES/inbox.mo po/pl.po
```

ポーランド語のファイルを埋めると、`python3 inbox.py pl 5` は "Masz 5 nieprzeczytanych wiadomości." と出力します。その後、誰かがコード内の "unread message" を "new message" に変更したとします。`xgettext` と `msgmerge --update --previous` は既存のポーランド語訳を引き継ぎますが、その訳はもう別のテキストに対するものなので、fuzzy としてマークされます：

```text title="po/pl.po"
#: inbox.py:10
#, fuzzy, python-format
#| msgid "You have %d unread message."
#| msgid_plural "You have %d unread messages."
msgid "You have %d new message."
msgid_plural "You have %d new messages."
msgstr[0] "Masz %d nieprzeczytaną wiadomość."
msgstr[1] "Masz %d nieprzeczytane wiadomości."
msgstr[2] "Masz %d nieprzeczytanych wiadomości."
```

`msgfmt` は [fuzzy エントリを除外する](https://www.gnu.org/software/gettext/manual/html_node/msgfmt-Invocation.html)ため (「2 translated messages, 1 fuzzy translation」と出力されます) 、同じコマンドを実行すると、ポーランド語の画面の中に英語の「You have 5 new messages.」がそのまま表示されてしまいます。古いポーランド語訳は「unread (未読) 」のままなので、翻訳を更新しなければなりません。General Translation を使えば、ビルドの一環として新しいテンプレートからこの更新版を生成できます。

## General Translation で gettext カタログを翻訳する

General Translation の CLI は、POT テンプレートを読み込んですべてのエントリを翻訳し、対象言語ごとに PO ファイルを書き出します。`gt.config.json` でテンプレートを指定し、各言語のファイルの出力先を設定してください。以下の設定は `gt` 2.26.5 で動作確認済みです：

```json title="gt.config.json"
{
  "defaultLocale": "en",
  "locales": ["de", "pl", "pt_BR"],
  "customMapping": {
    "pt_BR": { "code": "pt-BR" }
  },
  "files": {
    "pot": {
      "include": ["po/inbox.pot"],
      "transform": {
        "match": "^po/inbox\\.pot$",
        "replace": "po/{locale}.po"
      },
      "transformationFormat": "PO"
    }
  }
}
```

* **`pot` は PO ファイルと POT ファイルを読み込みます**。さらに `"transformationFormat": "PO"` を指定すると、翻訳済みの `.po` ファイルが出力されます。 ([PO / POT 形式リファレンス](/docs/cli/reference/formats/po-pot-files)を参照してください。) 
* **`transform` で出力ファイル名を指定します。** `{locale}` には `locales` に記述したとおりのロケールが入るため、`po/pl.po` や `po/pt_BR.po` が生成されます。 ([`transform`](/docs/cli/reference/config#files) を参照してください。) 
* **gettext のロケール名はそのまま使えます。** [`customMapping`](/docs/cli/reference/config#custom-mapping) で `pt_BR` を標準のロケールコード `pt-BR` に対応付けます。同じパターンは、WordPress プラグインの `languages/my-plugin.pot` や `languages/my-plugin-de_DE.po` といった別の構成にも応用できます。

CLI のセットアップが済んでいれば ([CLI クイックスタート](/docs/cli/quickstart)を参照) 、ワークフローは次のようになります。

```bash
xgettext --language=Python --keyword=pgettext:1c,2 --add-comments=TRANSLATORS -o po/inbox.pot inbox.py
msgconv --to-code=UTF-8 -o po/inbox.pot po/inbox.pot
npx gt translate
msgfmt --check -o locale/pl/LC_MESSAGES/inbox.mo po/pl.po
```

`xgettext` はテンプレートのヘッダーに `charset=CHARSET` をプレースホルダーとして残します。`msgconv` はこれを UTF-8 に設定しますが、これは `msginit` が言語ファイルに対して行う処理と同じです。[`npx gt translate`](/docs/cli/reference/commands/translate) は、各エントリについて PO ファイルが持つ情報 (`msgctxt`、`#.` 翻訳者コメント、`#:` 参照、フォーマットフラグ) を文脈として送信します。複数形のエントリでは、General Translation が対象言語の `Plural-Forms` ヘッダーを書き込み、ヘッダーが求めるすべての `msgstr[n]` スロット (ポーランド語なら 3 つ、アラビア語なら 6 つ) を埋めます。また、`%d` などのプレースホルダーが崩れずに保持されているかも検証します。

`msgid` が変更されると、General Translation は次回の実行時に新しいテキストの翻訳を生成します。変更のないエントリには以前の翻訳がそのまま使われます。既存の PO 翻訳は、最初の生成実行の前に [`npx gt upload`](/docs/cli/reference/commands/upload) でインポートしてください。その後ローカルの PO エディターで編集した内容は、次に生成する前に [`npx gt save-local`](/docs/cli/reference/commands/save-local) でプラットフォームに保存できます。

General Translation の価値は、`msgstr` を埋めるだけでなく、スタック全体を提供する点にあります。[コンテキストグループ](/docs/platform/dashboard/guides/defining-context-for-translations)内の用語集とカスタムプロンプトにより、PO ファイルをはじめ翻訳対象のあらゆるユーザー接点で用語とトーンを統一できます。レビュー担当者はダッシュボード上で、対象言語の複数形を含めて各 PO エントリを[確認・編集](/docs/platform/dashboard/guides/reviewing-translations)できます。さらに CLI は CI 上で実行できるため、どのリリースにも常に最新のカタログを含めて出荷できます。

ビルドの中で Node.js CLI を実行し、出力された PO を `msgfmt` でコンパイルしてください。アプリケーションはこれまでどおり、コンパイル済みの翻訳をローカルから読み込みます。

## GNU gettext と General Translation の比較一覧

| 機能              | GNU gettext                            | General Translation                                                    |
| --------------- | -------------------------------------- | ---------------------------------------------------------------------- |
| コードから文字列を抽出     | 対応 (`xgettext`)                        | 既存の POT テンプレートを読み込む                                                    |
| 言語ごとにファイルを作成    | 対応 (`msginit`)                         | 対応 (テンプレートから、設定済みのすべてのロケール分を作成)                                        |
| 翻訳を作成           | 1.0 以降はローカル LLM で下書きを作成し、翻訳者が仕上げる      | 対応 ([`npx gt translate`](/docs/cli/reference/commands/translate) を使用)  |
| 翻訳元文字列の変更時      | `msgmerge` が fuzzy としてマークし、レビューされるまで保留 | 次回の実行時に再翻訳し、変更のないエントリは再利用                                              |
| 複数形             | `msginit` がヘッダーを書き込み、各スロットは手動で埋める      | ヘッダーの書き込みとすべてのスロットの入力を自動で行う                                            |
| 翻訳のための文脈        | `msgctxt`、翻訳者コメント、参照、フラグ               | 左記に加え、用語集とカスタムプロンプト                                                    |
| 実行時に翻訳をコンパイル・参照 | 対応 (`msgfmt` と gettext ランタイム)          | 既存の gettext コンパイラとランタイムをそのまま使用                                         |
| 費用              | フリーソフトウェア                              | [従量課金制の翻訳](https://generaltranslation.com/pricing)                     |

## 使い分けの目安

翻訳者や TMS がすでに PO ファイルを埋めている場合、リリース前にすべての翻訳を人が書く必要がある場合、またはビルド環境で Node.js を実行できない場合は、gettext を単独で使用してください。翻訳ラウンドを待たずに、テンプレートが変更された時点ですべての言語のすべての PO ファイルを翻訳したい場合、しかも複数形のスロットを漏れなく埋め、用語を全体で統一したい場合は、General Translation を追加してください。

移行作業は一切不要です。General Translation は、`_()` 呼び出し、テンプレート、PO ファイル、ランタイムをそのまま活かします。置き換えるのは、`msgmerge` と `msgfmt` の間にある手作業のステップだけです。 (フレームワーク固有のセットアップについては、[General Translation と Django の翻訳フレームワークの比較](/kb/general-translation-vs-django-i18n)および[General Translation と Babel・Flask-Babel の比較](/kb/general-translation-vs-flask-babel)を参照してください。)

## 重要なポイント

* GNU gettext は翻訳の抽出、マージ、コンパイル、検索を担い、1.0 以降はローカル LLM で翻訳の下書きも作成できますが、翻訳を完成させるところまではしません。新規または変更された文字列は、誰かが翻訳またはレビューするまでソース言語のまま表示されます。
* General Translation の CLI は、`pot` キー、`"transformationFormat": "PO"`、出力パスを指定する `transform`、`pt_BR` などの名前を指定する `customMapping` を使って、POT テンプレートを言語ごとの PO ファイルに翻訳します。
* General Translation は、複数形のエントリごとに、`msgctxt` と翻訳者コメントを文脈として活用しながら、対象言語の `Plural-Forms` ヘッダーとすべての `msgstr[n]` スロットを書き出します。`msgfmt` と gettext ランタイムは、これまでどおりそのまま使えます。

## Related questions

- [General Translation と Django の翻訳フレームワーク：両方必要なのか？](https://generaltranslation.com/ja/kb/general-translation-vs-django-i18n.mdx): Django の翻訳フレームワークと General Translation は併用できます。メッセージの抽出、言語の選択、レンダリングは Django が担当し、General Translation は製品の用語とダッシュボードでのレビュー内容を反映して、複数形を含む PO ファイルに翻訳を書き込みます。テンプレートや URL パターンはそのままで、翻訳はコードの変更に合わせて更新されます。
- [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 はそのままに、カタログを手作業で翻訳する手間から解放されます。
- [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 と Weblate の比較：どちらを使うべきか](https://generaltranslation.com/ja/kb/general-translation-vs-weblate.mdx): Weblate は、コミュニティやチームでリポジトリ内のファイルを翻訳するために作られた、セルフホスト可能な Git ベースのローカライゼーションプラットフォームです。General Translation は、マークされた JSX と共有されたプロダクトの文脈を用いて、翻訳の生成を開発とリリースに組み込みます。既存の gettext ファイルをそのまま使い続けることも、インライン記述を導入して翻訳元カタログの保守そのものをなくすこともできます。
- [開発者にとって最適なローカライゼーションソフトウェアとは？](https://generaltranslation.com/ja/kb/best-localization-software.mdx): ライブラリ、翻訳管理システム、翻訳ベンダーを個別に組み合わせるのではなく、コード内のi18nライブラリから翻訳、配信まで、パイプライン全体を1つでカバーできるシステムを選びましょう。

## Previous and next questions

- Previous question: [General Translation と Django の翻訳フレームワーク：両方必要なのか？](https://generaltranslation.com/ja/kb/general-translation-vs-django-i18n.mdx)
- Next question: [General Translation と i18n-tasks：どちらを使うべきか？](https://generaltranslation.com/ja/kb/general-translation-vs-i18n-tasks.mdx)

## Sitemap

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