# General Translation Knowledge Base: General Translation 与 Lingui：该选哪一个？
URL: https://generaltranslation.com/zh/kb/general-translation-vs-lingui.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: 如果你希望像使用 Lingui 一样将文案内联在代码中，同时以 JSX 结构作为上下文自动生成译文，请选择 General Translation。Lingui 会将内联消息提取到消息目录中，交由译者或已连接的服务翻译。General Translation 的 CLI 会随代码变更自动更新译文，你的团队可以在仪表板中审阅。
Category: 国际化
Last updated: 2026-10-16
Authors: Kevin Wu, Jackie Chen
Published: 2026-10-16

在编写环节，Lingui 的做法与 General Translation 十分接近。你在组件中写下 `<Trans>Inbox</Trans>`，Lingui 的宏会将其编译为带有自动生成 ID 的 ICU 消息，`lingui extract` 会生成 PO 消息目录，`lingui compile` 再将翻译好的消息目录转换为轻量的 JavaScript 模块。Lingui 唯独没有覆盖的一步，恰恰是翻译本身：其文档建议[手动编辑消息目录，或通过 Crowdin、Translation.io 进行同步](https://lingui.dev/tools/introduction)。General Translation 同样让文案保持内联，但译文由 General Translation 直接生成。

## Lingui 的优势

* **借助宏内联源文本。** `<Trans>` 宏以及用于复数形式和普通字符串的 [Lingui 宏](https://lingui.dev/ref/macro)让英文直接保留在组件中，并编译为 ICU MessageFormat，因此无需编写键。
* **运行时轻量。** 消息会预先编译，据 Lingui 官方测算，其运行时[约为 2 kB](https://lingui.dev/introduction)。
* **对 Gettext 友好的消息目录。** [PO 是默认格式](https://lingui.dev/ref/catalog-formats)。`lingui extract` 会将新消息合并到每个区域设置中，并将已删除的消息标记为过时；`context` 和 `comment` 字段也会传达给译者。
* **服务端组件。** [自 4.10 版本起](https://lingui.dev/tutorials/react-rsc)，只要每个页面或布局都调用 `setI18n`，`<Trans>` 和 `useLingui` 即可在服务端使用。
* **开发活跃。** [第 6 版已于 2026 年 4 月发布](https://lingui.dev/blog/2026/04/22/announcing-lingui-6.0) (仅支持 ESM，需要 Node.js 22.19 或更高版本) ，采用 MIT 许可证。

## Lingui 留给你自己处理的部分

下面是一个用 Lingui React 宏实现的简单收件箱：

```jsx title="Inbox.jsx"
import { Trans, Plural } from '@lingui/react/macro';

export function Inbox({ count }) {
  return (
    <section>
      <h1>
        <Trans>Inbox</Trans>
      </h1>
      <p>
        <Trans>
          You have <Plural value={count} one="# unread message" other="# unread messages" />.
        </Trans>
      </p>
    </section>
  );
}
```

`lingui extract` 会把新的目标语言消息添加到 PO 消息目录中，但译文留空。你的译者或已连接的服务需要填写这些条目，并保留 ICU 语法。填写完成后的西班牙语消息目录如下：

```text title="locales/es/messages.po"
#: src/Inbox.jsx:7
msgid "Inbox"
msgstr "Bandeja de entrada"

#: src/Inbox.jsx:10
msgid "You have {count, plural, one {# unread message} other {# unread messages}}."
msgstr "Tienes {count, plural, one {# mensaje sin leer} other {# mensajes sin leer}}."
```

随后，[`lingui compile`](https://lingui.dev/ref/cli) 会将消息目录编译为应用可加载的模块。每次改动都要重走一遍&quot;提取、翻译、编译&quot;的流程；宏还依赖[构建转换](https://lingui.dev/installation) (Lingui 的 Babel 插件、Vite 插件，或实验性的 SWC 插件) ；此外，译者只能依据 PO 条目及其注释进行翻译，看不到组件本身。

## 保留内联文案，让 General Translation 生成消息目录

General Translation 的库沿用了同样的内联编写方式：文案写在 [`<T>`](/docs/react/reference/components/t) 中，复数形式放在 [`<Plural>`](/docs/react/reference/components/plural) 中，[`<Num>`](/docs/react/reference/components/num) 则按各个区域设置格式化数值。此外，General Translation 还能做到 Lingui 做不到的事：自动生成译文。下面用 `gt-react` 实现同一个收件箱：

```tsx title="Inbox.tsx"
import { T, Plural, Num } from 'gt-react';

export function Inbox({ count }: { count: number }) {
  return (
    <T>
      <section>
        <h1>Inbox</h1>
        <Plural
          n={count}
          singular={<p>You have <Num>{count}</Num> unread message.</p>}
          plural={<p>You have <Num>{count}</Num> unread messages.</p>}
        />
      </section>
    </T>
  );
}
```

[`npx gt translate`](/docs/cli/reference/commands/translate) 会在构建之前发送每个 [`<T>`](/docs/react/reference/components/t) 块及其元素结构，并生成目标消息目录。`singular` 和 `plural` 源分支为每种目标语言所需的各种形式提供措辞。[`<Plural>`](/docs/react/reference/components/plural) 在运行时选择对应的翻译分支。JSX 之外的字符串则交由 [`useGT`](/docs/react/reference/hooks/use-gt) 处理，它相当于 Lingui 的字符串宏。

在此示例中，收件箱标题和消息分支会一起送去翻译。你还可以添加 [`context` 备注](/docs/react/reference/components/t#context)，说明产品特有的含义。审阅者可以在[仪表板翻译编辑器](/docs/platform/dashboard/guides/reviewing-translations)中编辑生成的文本；下次运行 CLI 时，未更改的译文会被复用，新文案则会重新生成，无需单独执行消息目录编译命令。

Profound 的平台和文档借助 General Translation 以 47 种以上的区域设置发布。 (参见[生产环境部署](https://generaltranslation.com/enterprise)。)

## Lingui 与 General Translation 速览对比

| 功能       | Lingui                           | General Translation                                                                                            |
| -------- | -------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| 文案编写方式   | 使用 `<Trans>` 等内联宏                | 在 [`<T>`](/docs/react/reference/components/t) 中编写内联 JSX，在 [`useGT`](/docs/react/reference/hooks/use-gt) 中编写字符串 |
| 是否翻译你的内容 | 否                                | 是，通过 [`npx gt translate`](/docs/cli/reference/commands/translate)                                              |
| 每次变更所需步骤 | 提取、逐个翻译 PO 消息目录、编译，并在构建中配置宏转换      | 在构建前运行 [`npx gt translate`](/docs/cli/reference/commands/translate)                                            |
| 消息目录     | 每个区域设置一个 PO 文件，编译为 JavaScript 模块 | 按区域设置生成，存储在你的代码仓库或 General Translation 的 CDN 上                                                                 |
| 译者能看到的内容 | 消息本身，以及 `context` 和 `comment` 字段 | 已标记 JSX 块的内部结构、上下文备注，以及共享的词汇表和自定义提示词                                                                           |

如果你的译者习惯使用 gettext PO 消息目录，你在意 Lingui 编译后的精简运行时对应用包体积的影响，或者现有翻译流程已经运转良好，那就继续使用 Lingui。如果你想保留同样的内联编写方式，又不想反复经历提取、翻译、编译的流程，同时希望译文能结合代码上下文生成，那就选择 General Translation。

## 从 Lingui 迁移

一次迁移一个组件或路由。Lingui 的 `<Trans>` 对应 [`<T>`](/docs/react/reference/components/t)；其 `<Plural value={count} one="…" other="…" />` 对应 [`<Plural>`](/docs/react/reference/components/plural)，使用 `n={count}` 以及 `singular` 和 `plural` 分支，并用 [`<Num>`](/docs/react/reference/components/num) 显示数字。其字符串宏对应 [`useGT`](/docs/react/reference/hooks/use-gt)。尚未迁移的组件继续加载 Lingui 现有的译文。所有组件迁移完成后，移除宏转换以及 extract 和 compile 脚本。 (参见[迁移国际化库](/docs/react/guides/migrating-i18n-libraries)。)

## 要点总结

* Lingui 将文案内联在代码中，并编译出一个精简的运行时；各目标语言的消息目录则由译者或已连接的服务提供。
* General Translation 的库同样采用内联编写，而且翻译工作也由 General Translation 承担：它会结合代码的上下文进行翻译，无需反复处理消息目录。
* Lingui 的宏与 [`<T>`](/docs/react/reference/components/t)、[`<Plural>`](/docs/react/reference/components/plural) 和 [`useGT`](/docs/react/reference/hooks/use-gt) 高度对应，因此你可以逐个组件迁移。

## Related questions

- [General Translation 与 i18next、react-intl 和 next-intl 对比：应该选择哪个国际化库？](https://generaltranslation.com/zh/kb/general-translation-vs-i18n-libraries.mdx): i18next、react-intl 和 next-intl 等开源库本身并不翻译任何内容。它们只负责显示你在各语言目录文件中提供的译文，这些译文由你、你的译者或其他服务编写。General Translation 的库同样开源，承担同样的工作，此外 General Translation 还会以你的代码为上下文完成翻译。
- [i18next 替代方案：General Translation 与 i18next 对比](https://generaltranslation.com/zh/kb/general-translation-vs-i18next.mdx): 如果你希望将文案内联在 React 组件中，并借助其 JSX 结构和产品上下文生成译文，请选择 General Translation。你也可以继续使用 i18next，并用 General Translation 翻译现有的目录。i18next 负责消息渲染和复数形式选择，译文则需要由单独的服务生成。
- [react-intl 替代方案：General Translation 与 react-intl 对比](https://generaltranslation.com/zh/kb/general-translation-vs-react-intl.mdx): General Translation 让 React 团队在保留 ICU 消息语法的同时，获得译文生成、共享术语和仪表板审校能力。react-intl 提供格式化功能和 FormatJS 目录工具；General Translation 还能直接生成译文。
- [General Translation 与 vue-i18n 对比：该选哪一个？](https://generaltranslation.com/zh/kb/general-translation-vs-vue-i18n.mdx): General Translation 让 Vue 团队可以直接在模板中编写源文案，并通过 CLI 生成译文。其 gt-vue 插件在渲染这些内容时，会应用符合区域设置的复数形式和数字格式化。如果你希望免去维护基于键的源文件，可以选择它；而对于使用 Nuxt i18n 模块、已有成熟目录工作流的团队，vue-i18n 依然是合适的选择。
- [不用翻译文件也能做 i18n 吗？](https://generaltranslation.com/zh/kb/i18n-without-translation-files.mdx): 可以。使用 gt-react 或 gt-next 时，内容以内联方式直接写在组件中的 `<T>` 组件内，译文在构建时作为输出生成，因此无需编写键，也无需为每个区域设置编写 JSON 文件并保持同步。

## Previous and next questions

- Previous question: [General Translation 与 Intlayer：该选哪一个？](https://generaltranslation.com/zh/kb/general-translation-vs-intlayer.mdx)
- Next question: [General Translation 与 Locize 对比：该选哪个？](https://generaltranslation.com/zh/kb/general-translation-vs-locize.mdx)

## Sitemap

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