# General Translation Knowledge Base: General Translation と Weblate の比較：どちらを使うべきか
URL: https://generaltranslation.com/ja/kb/general-translation-vs-weblate.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: Weblate は、コミュニティやチームでリポジトリ内のファイルを翻訳するために作られた、セルフホスト可能な Git ベースのローカライゼーションプラットフォームです。General Translation は、マークされた JSX と共有されたプロダクトの文脈を用いて、翻訳の生成を開発とリリースに組み込みます。既存の gettext ファイルをそのまま使い続けることも、インライン記述を導入して翻訳元カタログの保守そのものをなくすこともできます。
Category: ワークフローツール
Last updated: 2026-10-16
Authors: Kevin Wu, Jackie Chen
Published: 2026-10-16

Weblate は、Git を中心に構築されたオープンソースの Web ベース翻訳プラットフォームです。リポジトリを接続すると、Weblate が翻訳ファイルを読み込み、翻訳者または設定済みの翻訳サービスが訳文を入力し、Weblate がその結果をコミットするか、プルリクエストを作成します。コミュニティの翻訳者が参加するオープンソースプロジェクトで広く使われています。一方、General Translation は翻訳の生成をビルドに組み込みます。新しい文言とその翻訳を同じリリースで公開でき、チームはダッシュボードで内容をレビューできます。

## Weblate の強み

* **コピーレフトのオープンソース。** Weblate は [GPL-3.0-or-later ライセンスで公開されており](https://github.com/WeblateOrg/weblate)、プラットフォーム全体を無料でダウンロードして運用できます。導入や保守の支援が必要な場合は、有料のサポートプランも用意されています。
* **リブレプロジェクト向けの無料ホスティング。** ホスト版 Weblate は EU のインフラ上で稼働しており、公開されたリブレプロジェクトは Libre プランを無料で利用できます。制限は 16 万文字列プランと同じです。
* **Git ベースの継続的ローカライゼーション。** Weblate は、フォージから Webhook を受信したとき(または毎日の定期取得時)に変更を取り込み、作成者ごとに変更をまとめる遅延コミットで翻訳をコミットします。そのうえで、GitHub、GitLab、Gitea、Bitbucket、Azure DevOps、Pagure 上のブランチにプッシュするか、[プルリクエストを作成します](https://docs.weblate.org/en/latest/vcs.html)。ホスト版 Weblate は GitHub App 経由での接続にも対応しています。
* **非常に幅広いファイル形式に対応。** Weblate のドキュメントには、gettext PO、XLIFF 1.2 および 2.0、Android と Apple の strings、ARB、i18next JSON、Fluent、Java properties、.NET RESX、Ruby YAML、PHP と Laravel の文字列、Qt Linguist、CSV、Excel、Markdown など、[約 50 の形式](https://docs.weblate.org/en/latest/formats.html)が掲載されています。
* **ファイル関連の定型作業を担うアドオン。** [組み込みアドオン](https://docs.weblate.org/en/latest/admin/addons.html)を使えば、POT テンプレートからの PO ファイルの更新、MO ファイルの生成、コミットのスカッシュ、自動翻訳の実行を自動化できます。
* **機械翻訳と大規模言語モデル。** [外部連携](https://docs.weblate.org/en/latest/admin/machine.html)として、DeepL、Google、Azure、Amazon、LibreTranslate に加え、OpenAI、Azure OpenAI、Anthropic、Mistral、Ollama に対応しています。これらの大規模言語モデルのプロンプトには、該当する用語集の用語とスタイル設定が含まれます。さらに Weblate 独自の翻訳メモリも併せて利用できます。
* **品質チェック。** [数十種類のチェック](https://docs.weblate.org/en/latest/user/checks.html)により、プレースホルダー、複数形の欠落、最大長、ICU MessageFormat の構文、未変更の翻訳などを検査できます。また、自動修正機能が空白や省略記号を補正します。
* **コミュニティ翻訳。** ボランティアが翻訳を提案したりコメントしたりでき、レビュアーがそれを承認します。プロジェクトによっては[承認済みの文字列のみをコミットする](https://docs.weblate.org/en/latest/workflows.html)設定も可能です。スクリーンショット、用語集、ソース参照を通じて、翻訳者に文脈を提供できます。

## Weblate を導入してもエンジニアに残る作業

以下は gettext を使った Python アプリの例です。スペイン語のカタログは、最後の行が追加される前に翻訳されています。

```python title="app.py"
import gettext
t = gettext.translation("messages", localedir="locale", languages=["es"])
_ = t.gettext
print(_("Inbox"))
print(_("No messages yet."))  # 新しい文言（前回の翻訳作業の後に追加）
```

POT テンプレートを抽出し、`locale/es/LC_MESSAGES/messages.po` で "Inbox" だけを翻訳してから Babel 2.17.0 でコンパイルすると、スペイン語のユーザーには新しい行が英語のまま表示されます。

```text title="Output"
Bandeja de entrada
No messages yet.
```

その行は、以下の一連の流れが完了するまで英語のままです。

1. 文字列を `_()` でラップし、`xgettext` または `pybabel extract` で POT テンプレートを再生成してコミットします。
2. Weblate が Webhook または次回のフェッチで変更を取り込み、`msgmerge` アドオンが各 PO ファイルに新しいエントリを追加します。
3. ボランティア、翻訳者、または設定済みの機械翻訳で翻訳し、承認が必要な場合は結果をレビューします。
4. Weblate が変更をコミットしてプッシュするか、プルリクエストを作成します。その後、リリースプロセスで変更をマージし、MO ファイルをコンパイルしてデプロイします。

Weblate の外部で同じファイルを編集するとマージコンフリクトが発生することがあります。[Weblate のドキュメントでは](https://docs.weblate.org/en/latest/admin/continuous.html#avoiding-merge-conflicts-by-locking-weblate-while-doing-outside-changes)、ファイルを変更する間はコンポーネントをロックしてこれを回避するよう推奨しています。また、翻訳者が確認できるのは各文字列のソース参照とスクリーンショットだけで、その文字列をレンダリングするコードは見えません。

セルフホスティングは無料です。ホスト版の Weblate は、ホストされる文字列数 (翻訳元文字列数 ×「言語数 + 1」) に基づいて料金が決まり、どのプランでも言語数、プロジェクト数、翻訳者数は無制限です。 ([Weblate hosting](https://weblate.org/en/hosting/) を参照。2026年10月時点の情報です。)

## Weblate と General Translation の比較早見表

| 機能        | Weblate                                                          | General Translation                                                                                                              |
| --------- | ---------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| 文字列の保存場所  | リポジトリ内の翻訳ファイル (Weblate のコンポーネントにミラーリング)                          | コード内の [`<T>`](/docs/react/reference/components/t) の中、または既存のリソースファイル                                                              |
| コードとの連携方法 | Weblate が Git から取得し、コミットのプッシュまたはプルリクエストの作成を行う                    | ビルド時に [`npx gt translate`](/docs/cli/reference/commands/translate) を実行、または [Locadex](/docs/platform/locadex/quickstart) のプルリクエスト |
| 翻訳の担い手    | ボランティア、自社の翻訳者、機械翻訳、または大規模言語モデル                                   | コード、用語集、カスタムプロンプトの文脈を踏まえて AI が翻訳し、チームがダッシュボードでレビュー                                                                               |
| 各文字列の文脈   | ソース参照、スクリーンショット、用語集、翻訳メモリ                                        | インラインライブラリでマークされた JSX 構造、対応カタログ内の翻訳元の文脈、共有の用語集とカスタムプロンプト                                                                         |
| ファイル形式    | XLIFF、ARB、Fluent、Java properties など約 50 種類                       | JSON、YAML、PO、Markdown・MDX、iOS・Android の文字列など                                                                                     |
| ホスティング    | 無料でセルフホスト、または ホスト版 Weblate                                     | ホスト型プラットフォーム (ライブラリと CLI はオープンソース)                                                                                               |
| 料金        | セルフホストは無料、ホスト型プランはホストする文字列数に応じて課金、公開のリブレプロジェクト向けに無料の Libre プランあり | [使用量に応じた翻訳料金](https://generaltranslation.com/pricing)                                                                            |
| ライセンス     | GPL-3.0-or-later                                                 | JavaScript ライブラリと CLI は MIT ライセンス                                                                                                |

## チームが Weblate ではなく General Translation を選ぶ理由

General Translation なら、新しい文言を追加するリリースそのものに翻訳を組み込めます。gettext をそのまま使ってビルド時に PO ファイルを生成することも、インラインライブラリを使ってコンポーネント内の [`<T>`](/docs/react/reference/components/t) に翻訳元の文言を直接記述することもできます。

* **より速い。** [`npx gt translate`](/docs/cli/reference/commands/translate) はデプロイ前に翻訳を生成します。React および Next.js プロジェクトでは、[Locadex](/docs/platform/locadex/quickstart) が変更をプルリクエストとして用意できます。`gt.config.json` にロケールを追加すれば、次回の実行時にその言語の翻訳生成が始まります。
* **運用コストが低い。** 翻訳サービスは General Translation が運用するため、チームで翻訳サーバーをインストール、アップグレード、バックアップする必要はありません。インライン記述を採用すれば、エンジニアが翻訳元カタログを別途管理する必要もなくなります。
* **品質が高い。** インライン翻訳では、マークされた JSX の要素や複数形の分岐が文と一緒に渡されます。gettext の場合は、翻訳元のコメントと `msgctxt` によって各エントリの意味が補足されます。共有の[コンテキストグループ](/docs/platform/dashboard/guides/defining-context-for-translations)を通じて用語集とカスタムプロンプトが適用され、チームは[ダッシュボードの翻訳エディター](/docs/platform/dashboard/guides/reviewing-translations)で結果を仕上げられます。
* **リスクが低い。** 翻訳済みファイルはリポジトリで管理され、公開のタイミングはリリースプロセスで制御できます。gettext と標準の PO ファイルを使い続けることも、翻訳をバンドルに含めた General Translation の MIT ライセンスの JavaScript ライブラリを使うこともできます。どちらの配信方法でも、General Translation へのランタイム呼び出しは発生しません。

Profound のプラットフォームとドキュメントは、General Translation を利用して 47 以上のロケールで提供されています。 ([本番環境での導入事例](https://generaltranslation.com/enterprise)をご覧ください。)

## Weblate のほうが適しているケース

コミュニティ翻訳を活用したい場合、完全にセルフホストできるプラットフォームが必要な場合、または幅広いカタログ形式への対応を重視する場合は、Weblate を選びましょう。一方、新しいプロダクト文言をリリースごとに翻訳したい場合や、インライン記述でコードの文脈を活かしたい場合、既存の JSON、YAML、PO、Markdown ファイルを CLI から直接扱いたい場合は、General Translation が適しています。

## gettext ファイルで両方を併用する

General Translation の CLI は、Weblate が読み込むのと同じ gettext ファイルを翻訳します。`pot` エントリでテンプレートを指定し、各出力を Weblate が使用するフォルダ構成に対応付けます：

```json title="gt.config.json"
{
  "defaultLocale": "en",
  "locales": ["es", "fr", "pl"],
  "files": {
    "pot": {
      "include": ["locale/messages.pot"],
      "transformationFormat": "PO",
      "transform": {
        "match": "locale/messages\\.pot",
        "replace": "locale/{locale}/LC_MESSAGES/messages.po"
      }
    }
  }
}
```

`gt` 2.26.5 では、この設定により `locale/messages.pot` が `locale/es/LC_MESSAGES/messages.po` にマッピングされ、他の各ロケールにも同じパスが適用されます。複数形のエントリについては、General Translation が対象言語の `Plural-Forms` ヘッダーを書き込み、各 `msgstr[n]` の形式を埋めます。両者が同じファイルを編集しないよう、各言語の担当は1つに絞ってください。たとえば、コミュニティでカバーできない言語は General Translation に、それ以外は Weblate のボランティアに任せる、といった分担です。`pt_BR` のようにアンダースコアを含む gettext のフォルダー名は、標準の `pt-BR` にマッピングする [`customMapping`](/docs/cli/reference/config#custom-mapping) エントリを追加してください。 ([PO / POT](/docs/cli/reference/formats/po-pot-files) を参照。)

## General Translation は Weblate の代替になりますか？

はい。General Translation は、翻訳の生成、製品用語の共有、ダッシュボードでのレビューをリリースプロセスに統合します。上記の gettext ファイルはそのまま使い続けながら、翻訳の生成方法だけを切り替えられます。アプリケーション内の gettext 呼び出しを書き換える必要はありません。

## 要点

* Weblate は、オープンソースやコミュニティによる翻訳に適した強力なコピーレフトのプラットフォームです。Git ベースの継続的ローカライゼーション、無料のセルフホスティング、約 50 種類のファイル形式をサポートしています。
* 翻訳ワークフローは、リポジトリ内のカタログ、コントリビューター、Git との同期を軸に構成されています。
* General Translation はデプロイ前に翻訳を生成します。gettext や標準の PO ファイルをそのまま使い続けることも、インライン記述を採用し、翻訳元カタログを別途用意せずにコードの文脈を活かすこともできます。

## Related questions

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

## Previous and next questions

- Previous question: [General Translation と vue-i18n：どちらを使うべきか](https://generaltranslation.com/ja/kb/general-translation-vs-vue-i18n.mdx)
- Next question: [Google 翻訳の代替：General Translation と Google 翻訳の比較](https://generaltranslation.com/ja/kb/general-translation-vs-google-translate.mdx)

## Sitemap

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