# General Translation Knowledge Base: General Translation 与 Weblate：该选哪一个？
URL: https://generaltranslation.com/zh/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 提交结果或发起拉取请求。许多拥有社区译者的开源项目都选择在 Weblate 上进行翻译。General Translation 则把译文生成放进构建环节：新文案可以与其译文在同一次发布中上线，你的团队还能在仪表板中进行审阅。

## Weblate 的优势

* **Copyleft 开源。** Weblate [采用 GPL-3.0-or-later 许可证](https://github.com/WeblateOrg/weblate)，你可以免费下载并运行整个平台；如果需要协助安装和维护，还可以选择付费支持计划。
* **为自由项目提供免费托管。** 托管版 Weblate 运行在欧盟基础设施上，公开的自由项目可免费使用其 Libre 计划，限额与 16 万字符串计划相同。
* **基于 Git 的持续本地化。** 当你的代码托管平台发送 Webhook 时 (或每日定时拉取) ，Weblate 会拉取变更，采用按作者分组的延迟提交方式提交译文，再推送到你的分支，或在 GitHub、GitLab、Gitea、Bitbucket、Azure DevOps 和 Pagure 上[创建拉取请求](https://docs.weblate.org/en/latest/vcs.html)。托管版 Weblate 还支持通过 GitHub App 连接。
* **文件格式支持极为广泛。** Weblate 的文档列出了[约 50 种格式](https://docs.weblate.org/en/latest/formats.html)，包括 gettext PO、XLIFF 1.2 和 2.0、Android 和 Apple 字符串、ARB、i18next JSON、Fluent、Java properties、.NET RESX、Ruby YAML、PHP 和 Laravel 字符串、Qt Linguist、CSV、Excel 以及 Markdown。
* **用附加组件处理文件琐事。** [内置附加组件](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 按托管字符串数计费，即源字符串数乘以 (语言数加一) ，所有套餐均不限语言、项目和译者数量。 (参见 [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 结构；受支持消息目录中的源上下文；共享的词汇表和自定义提示词                                                                                 |
| 文件格式      | 约 50 种，包括 XLIFF、ARB、Fluent 和 Java properties | JSON、YAML、PO、Markdown 和 MDX、iOS 和 Android 字符串 等                                                                         |
| 托管方式      | 可免费自托管，或使用 Hosted Weblate                    | 托管平台；开源库和 CLI                                                                                                               |
| 定价        | 自托管免费；托管方案按托管字符串数计费；公开的自由软件项目可使用免费的 Libre 方案 | [按用量计费](https://generaltranslation.com/pricing)                                                                             |
| 许可证       | GPL-3.0-or-later                             | JavaScript 库和 CLI 采用 MIT 许可证                                                                                                |

## 为什么团队选择 General Translation 而非 Weblate

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。如果你希望新的产品文案随每次发布一并完成翻译，在内联编写时获得代码上下文，并能通过 CLI 直接处理现有的 JSON、YAML、PO 或 Markdown 文件，请选择 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]` 形式。请为每种语言只指定一个负责方，例如社区未覆盖的语言交给 General Translation，其余语言交给 Weblate 的志愿者，以免双方编辑同一个文件。如果 gettext 文件夹名称中带有下划线 (例如 `pt_BR`) ，请添加一个 [`customMapping`](/docs/cli/reference/config#custom-mapping) 条目，将其映射到标准的 `pt-BR`。 (参见 [PO / POT](/docs/cli/reference/formats/po-pot-files)。)

## General Translation 能否替代 Weblate？

可以。General Translation 将译文生成、统一的产品术语以及仪表板审校融入您的发布流程。您可以继续使用上文所示的 gettext 文件，只需改变其译文的生成方式，无需改动应用中的 gettext 调用。

## 要点总结

* Weblate 是一款采用强 Copyleft 许可的开源与社区翻译平台，支持基于 Git 的持续本地化和免费自托管，并兼容约 50 种文件格式。
* 其翻译工作流围绕代码仓库中的消息目录、贡献者和 Git 同步展开。
* General Translation 在部署前生成译文。你可以继续沿用 gettext 和标准 PO 文件，也可以采用内联编写，直接在代码中提供上下文，无需单独维护源文案目录。

## Related questions

- [为什么选择 General Translation 而不是 TMS（Smartling、Lokalise、Phrase、Crowdin 或 Transifex）？](https://generaltranslation.com/zh/kb/general-translation-vs-tms.mdx): Smartling、Lokalise、Phrase、Crowdin 或 Transifex 等翻译管理系统（TMS）负责协调译员，但工程师仍需提取字符串、发送出去、等待译文，再把译文接回产品中。General Translation 结合上下文直接翻译代码中的内容，每次发布都同步交付所有语言，并基于开源库运行，不存在供应商锁定。
- [General Translation 与 GNU gettext：两者都需要吗？](https://generaltranslation.com/zh/kb/general-translation-vs-gettext.mdx): 继续用 GNU gettext 负责提取和渲染，再引入 General Translation 来生成和维护 PO 文件。General Translation 会把译者备注和消息上下文纳入生成过程，统一应用共享术语，并为审校人员提供 仪表板 编辑器。你现有的 gettext 调用和已编译的消息目录均保持原样。
- [General Translation 与 Tolgee：该如何选择？](https://generaltranslation.com/zh/kb/general-translation-vs-tolgee.mdx): Tolgee 是一个可自托管的平台，集基于键的消息、上下文内编辑和 AI 翻译于一体。General Translation 则将可读的文案直接保留在组件中，并根据标记的 JSX 生成译文，无需维护消息键，即可用所有语言发布新文案。
- [General Translation 与 Django 翻译框架：两者都需要吗？](https://generaltranslation.com/zh/kb/general-translation-vs-django-i18n.mdx): 将 Django 的翻译框架与 General Translation 搭配使用。Django 负责消息提取、语言选择和渲染；General Translation 则基于你的产品术语和仪表板审阅，填充 Django 的 PO 文件（包括复数形式）。你的模板和 URL 模式无需改动，译文会随代码同步更新。
- [对开发者来说，最好的本地化软件是什么？](https://generaltranslation.com/zh/kb/best-localization-software.mdx): 选择一套能覆盖整条流水线的系统——从代码中的国际化库，到翻译和投递——而不是把独立的库、翻译管理系统和翻译供应商拼凑在一起。

## Previous and next questions

- Previous question: [General Translation 与 vue-i18n 对比：该选哪一个？](https://generaltranslation.com/zh/kb/general-translation-vs-vue-i18n.mdx)
- Next question: [Google Translate 替代方案：General Translation 与 Google Translate 对比](https://generaltranslation.com/zh/kb/general-translation-vs-google-translate.mdx)

## Sitemap

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