# General Translation Knowledge Base: i18next 替代方案：General Translation 与 i18next 对比 URL: https://generaltranslation.com/zh/kb/general-translation-vs-i18next.mdx Docs index: https://generaltranslation.com/llms.txt Description: 如果你希望将文案内联在 React 组件中，并借助其 JSX 结构和产品上下文生成译文，请选择 General Translation。你也可以继续使用 i18next，并用 General Translation 翻译现有的目录。i18next 负责消息渲染和复数形式选择，译文则需要由单独的服务生成。 Category: 国际化 Last updated: 2026-10-16 Authors: Kevin Wu, Jackie Chen Published: 2026-10-16 i18next 负责加载翻译文件、根据用户的语言选取对应消息、解析复数形式、对值进行插值，并使用 `Intl` 格式化数字和日期。它自 2012 年起便已发布在 npm 上，搭配 `react-i18next` 和 `next-i18next`，是 React 和 Next.js 应用的常见选择。但 i18next 本身并不负责翻译：每种语言的每条消息都得由你、你的译者或 Locize 之类的服务提供，而 Locize 正是[由 i18next 的开发者运营](https://www.i18next.com/)的。General Translation 的库同样能完成这些渲染工作，此外，General Translation 还能根据组件中的文案直接生成译文。 ## i18next 的优势 * **普及度高。** 它是使用最广泛的 JavaScript i18n 框架之一。 * **覆盖面广。** [绑定库支持 React、Vue、Angular、Svelte 等框架](https://www.i18next.com/overview/supported-frameworks)，插件可通过 HTTP 加载文件、检测用户语言，还能借助 `i18next-icu` 将消息切换为 ICU MessageFormat 格式。 * **完整的复数形式与上下文支持。** 键可以带有 [CLDR 复数后缀](https://www.i18next.com/translation-function/plurals) (如 `_one`、`_few` 和 `_many`) ，并通过 `Intl.PluralRules` 解析；也可以带有上下文变体，如 `friend_male`。 * **工具链完善。** 官方的 [`i18next-cli`](https://github.com/i18next/i18next-cli) 可以提取键、生成 TypeScript 类型，并为每个区域设置写入复数键；当某个区域设置存在未翻译的键时，其 `status` 命令会报错退出，便于 CI 及时发现遗漏。 * **服务端组件。** [`next-i18next` 16](https://github.com/i18next/next-i18next) 为 Next.js App Router 新增了服务器端翻译函数。 * **不绑定特定服务。** 消息目录是完全由你掌控的纯 JSON 文件，i18next 可以搭配任意翻译服务使用，也可以完全不用。 ## i18next 留给你自己处理的部分 下面是一个用 react-i18next 实现的简单收件箱示例。每个字符串都要有一个键，每种复数形式也各自需要一个键： ```json title="locales/en/translation.json" { "inbox": { "title": "Inbox", "unread_one": "You have {{count}} unread message.", "unread_other": "You have {{count}} unread messages." } } ``` ```tsx title="Inbox.tsx" import { useTranslation } from 'react-i18next'; export function Inbox({ count }: { count: number }) { const { t } = useTranslation(); return (

{t('inbox.title')}

{t('inbox.unread', { count })}

); } ``` 其他每种语言都需要相同的消息键，并提供该语言实际使用的复数形式：例如波兰语需要 `unread_one`、`unread_few`、`unread_many` 和 `unread_other`。如果波兰语文件中只有照搬英语的 `_one` 和 `_other` 形式，而你的[后备语言](https://www.i18next.com/principles/fallback)是英语，那么像 2 和 5 这样的数量就会回退显示为英语： ```text title="Output" pl, count 1: Masz 1 nieprzeczytaną wiadomość. pl, count 2: You have 2 unread messages. pl, count 5: You have 5 unread messages. pl, count 22: You have 22 unread messages. ``` 在 CI 中运行 `i18next-cli status` 即可发现缺失的复数形式。翻译服务可以生成目录内容，但你的应用仍需引用 `inbox.unread` 这样的键，并依靠提取和翻译工作流让这些消息目录保持最新。 ## General Translation 将文案内联在代码中，并自动生成译文 General Translation 的库与 i18next 的作用相同：为每个区域设置选取对应的消息、应用相应的复数规则、对变量进行插值，并通过 [``](/docs/react/reference/components/num)、[``](/docs/react/reference/components/currency) 和 [``](/docs/react/reference/components/datetime) 格式化数字、货币和日期；习惯使用键的团队也可以通过 [`useTranslations`](/docs/react/reference/hooks/use-translations) 继续使用字典。不仅如此，General Translation 还能做到 i18next 做不到的事：自动生成译文。下面是用 `gt-react` 实现的同一个收件箱： ```tsx title="Inbox.tsx" import { T, Plural, Num } from 'gt-react'; export function Inbox({ count }: { count: number }) { return (

Inbox

You have {count} unread message.

} plural={

You have {count} unread messages.

} />
); } ``` [`npx gt translate`](/docs/cli/reference/commands/translate) 会在构建之前，将每个 [``](/docs/react/reference/components/t) 块连同其元素结构一起发送到 General Translation API，并为每个目标区域设置生成译文。通用的 `singular` 和 `plural` 源分支为每种目标语言所需的各个形式提供措辞依据。随后，[``](/docs/react/reference/components/plural) 会按照该区域设置的规则选出对应的已翻译分支。用 [``](/docs/react/reference/components/var) 包裹的值永远不会发送到 API。 当你修改 [``](/docs/react/reference/components/t) 中的句子时，下一次翻译运行会为每种语言更新该句子，未改动的内容则直接复用已有翻译。审校人员可在[仪表板翻译编辑器](/docs/platform/dashboard/guides/reviewing-translations)中完成工作，因此修改翻译无需改动组件。 这些 JavaScript 库采用 MIT 许可证；如果你自行提供翻译，无需注册账户即可使用。若应用配置为从应用包中加载全部翻译，则运行时不会向 General Translation 发起任何调用。`gt-react` 和 `gt-next` 底层不依赖任何其他国际化库。 Cursor 借助 General Translation，在其网站和文档中支持 14 种以上的区域设置。 (参见[生产环境部署案例](https://generaltranslation.com/enterprise)。) ## i18next 与 General Translation 速览 | 功能 | i18next | General Translation | | -------- | ------------------------------------------ | --------------------------------------------------------------------------------------------------------------------- | | 文案编写方式 | 按语言和命名空间存放在 JSON 文件中的键 | 写在 [``](/docs/react/reference/components/t) 中的 JSX、通过 [`useGT`](/docs/react/reference/hooks/use-gt) 传入的字符串，或基于键的字典 | | 是否翻译你的内容 | 否 | 是，使用 [`npx gt translate`](/docs/cli/reference/commands/translate) | | 译文来源 | 你自己、译员，或 Locize 等服务 | 结合代码上下文自动生成，或由你的团队编写 | | 复数形式 | 每种 CLDR 形式对应一个键，需为每种语言分别编写 | [``](/docs/react/reference/components/plural) 分支，随所在代码块的其余内容一并翻译 | | 翻译上下文 | 由你的翻译工作流提供的源消息和上下文 | 已标记 JSX 块内部的结构、上下文备注，以及共享的词汇表和自定义提示词 | | 框架 | React、Next.js，以及 Vue、Angular、Svelte 等框架的绑定 | React、Next.js、Vue、Node.js 以及[其他 SDK](/docs/overview/get-started) | | 是否需要账户 | 否 | 使用库无需账户；翻译需通过 General Translation 项目运行 | 如果你现有的消息目录和翻译流程运转良好，或你所用的框架不受 General Translation 的库支持，又或者你希望键不随文案变更而变化，请继续使用 i18next。如果你希望直接在组件中内联编写文案、结合代码上下文生成译文，并让每种语言随每次构建保持最新，请使用 General Translation。 ## 保留 i18next，交给 General Translation 来翻译 您无需更换库。`gt` CLI 会检测到 `package.json` 中的 `i18next`，并保留其插值语法。以下是将上文收件箱目录翻译为德语的配置： ```json title="gt.config.json" { "defaultLocale": "en", "locales": ["de"], "files": { "json": { "include": ["locales/[locale]/translation.json"] } } } ``` 英语和德语使用相同的 `_one` 和 `_other` 复数键结构。此配置会根据 `locales/en/translation.json` 生成 `locales/de/translation.json`。你可以通过[键级元数据](/docs/cli/reference/keyed-metadata)为每个键添加上下文，例如字符串在界面中出现的位置。先运行 [`npx gt upload`](/docs/cli/reference/commands/upload) 导入源内容和现有译文，再运行 [`npx gt translate`](/docs/cli/reference/commands/translate) 翻译新增文案。 如果想改用 [``](/docs/react/reference/components/t)，请参阅[迁移国际化库](/docs/react/guides/migrating-i18n-libraries)。该指南介绍了如何将键查找替换为内联文案、如何借助 [`useTranslations`](/docs/react/reference/hooks/use-translations) 保留现有字典，以及如何在逐个路由迁移的过程中让两个库并行运行。 (如需了解 i18next 与其他方案的对比，请参阅 [General Translation 与 i18next、react-intl 和 next-intl 对比](/kb/general-translation-vs-i18n-libraries)。) ## 如何在 i18next 中处理波兰语等复数形式繁多的语言？ 每种语言都需要为其用到的每种 CLDR 复数形式提供一个键，例如波兰语需要 `_one`、`_few`、`_many` 和 `_other`。在 CI 中运行 `i18next-cli status`，即可发现缺失的形式。借助 General Translation 的内联编写，你只需编写上文所示的 `singular` 和 `plural` 分支，翻译服务便会生成目标语言所需的各个形式，再由 [``](/docs/react/reference/components/plural) 在运行时选择正确的形式。 ## 其他 i18next 替代方案 准备弃用 i18next 的团队还会比较以下这些库： * **react-intl：** 格式化 ICU 消息，并提供 FormatJS 目录工具链。 (参见 [General Translation vs. react-intl](/kb/general-translation-vs-react-intl)。) * **Lingui：** 将文案内联在代码中，并将消息编译为目录，运行时体积小巧。 (参见 [General Translation vs. Lingui](/kb/general-translation-vs-lingui)。) * **next-intl：** 在 Next.js App Router 应用中渲染目录中的消息，支持服务端组件。 (参见 [next-intl vs. gt-next](/kb/next-intl-vs-gt-next)。) * **Paraglide JS：** 将目录编译为带类型、支持 tree-shaking 的消息函数。 (参见 [General Translation vs. Paraglide JS](/kb/general-translation-vs-paraglide)。) * **Intlayer：** 将每个组件的内容保存在带类型的声明文件中，各语言内容并列存放。 (参见 [General Translation vs. Intlayer](/kb/general-translation-vs-intlayer)。) ## 要点总结 * i18next 负责渲染基于键的消息目录并处理复数选择；译文则由人工或接入的服务提供。 * General Translation 的库同样负责渲染译文，此外 General Translation 还会根据 [``](/docs/react/reference/components/t) 中内联编写的文案直接完成翻译。 * 你可以继续使用 i18next，让 `gt` CLI 翻译其 JSON 文件；也可以按路由逐步迁移到 [``](/docs/react/reference/components/t)。 ## 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 还会以你的代码为上下文完成翻译。 - [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 与 Lingui：该选哪一个？](https://generaltranslation.com/zh/kb/general-translation-vs-lingui.mdx): 如果你希望像使用 Lingui 一样将文案内联在代码中，同时以 JSX 结构作为上下文自动生成译文，请选择 General Translation。Lingui 会将内联消息提取到消息目录中，交由译者或已连接的服务翻译。General Translation 的 CLI 会随代码变更自动更新译文，你的团队可以在仪表板中审阅。 - [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 依然是合适的选择。 - [如何在 React 中处理复数形式？](https://generaltranslation.com/zh/kb/how-to-handle-plurals-in-react.mdx): 不要用 n === 1 这类判断硬编码复数逻辑。如果应用只支持英语，一个简单的辅助函数就够用了；但多语言应用需要符合区域设置的复数规则，而 gt-react 或 gt-next 中的 `` 等 i18n 组件能够为每种语言处理这些规则。 ## Previous and next questions - Previous question: [Google Translate 替代方案：General Translation 与 Google Translate 对比](https://generaltranslation.com/zh/kb/general-translation-vs-google-translate.mdx) - Next question: [Lokalise 替代方案：General Translation 与 Lokalise 对比](https://generaltranslation.com/zh/kb/general-translation-vs-lokalise.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/zh/kb/sitemap.md) for every article.