# General Translation Knowledge Base: next-intl 替代方案：gt-next 与 next-intl 对比 URL: https://generaltranslation.com/zh/kb/next-intl-vs-gt-next.mdx Docs index: https://generaltranslation.com/llms.txt Description: next-intl 负责渲染你在各语言消息目录中提供的译文。gt-next 同样会渲染译文，此外，General Translation 还能根据你在 JSX 中内联编写的文案生成译文。两者均采用 MIT 许可证，并支持 App Router 和服务端组件。如果你现有的 next-intl 目录运行良好，可以继续保留，并直接用 General Translation 翻译，无需迁移。 Category: 工作流工具 Last updated: 2026-10-16 Authors: Jackie Chen Published: 2026-10-16 next-intl 和 gt-next 都能为 Next.js App Router 应用 (包括服务端组件) 提供本地化支持。两者的区别在于译文从何而来：next-intl 显示的是由你的团队或翻译服务写入各语言 JSON 目录的消息；而 gt-next 将源文案直接内联在 JSX 中，由 General Translation 在构建步骤中生成全部译文。 因此，你有三种选择：一是保留 next-intl 和现有的翻译流程；二是保留 next-intl，让 General Translation 翻译其目录，组件无需任何改动；三是改用 gt-next，采用内联文案并自动生成译文。 ## next-intl 与 gt-next 有何区别？ | 问题 | next-intl | gt-next (General Translation) | | ---------- | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | 是否会翻译你的内容？ | 否。它只负责渲染你提供的消息，这些消息由你的团队或 Crowdin 等服务提供 | 是。[`gt translate`](/docs/cli/reference/commands/translate) 会结合代码中的上下文生成译文，你的团队也可以自行编写 | | 源文案存放在哪里？ | 以键值形式存放在 JSON 目录中；通过 `useExtracted` 进行内联提取仍处于实验阶段 | 以内联 JSX 形式写在 [``](/docs/react/reference/components/t) 中，字符串则通过 [`useGT`](/docs/react/reference/hooks/use-gt) 处理；同时也支持基于键的字典 | | 是否支持服务端组件？ | 是，同步组件和异步组件需使用不同的 API | 是：[``](/docs/react/reference/components/t)、[`useGT`](/docs/react/reference/hooks/use-gt) 和 [`getGT`](/docs/react/nextjs/reference/functions/get-gt) | | 是否支持客户端组件？ | 需包裹在 `NextIntlClientProvider` 内 | 需包裹在 [`GTProvider`](/docs/react/reference/components/gt-provider) 内 | | 区域设置路由 | 通过中间件配合带区域设置前缀的路由实现 | 通过 [`createNextMiddleware`](/docs/react/nextjs/app-router-middleware) 配合 `app/[locale]` 路由段实现 | | 复数形式 | 在每个目录中使用 ICU MessageFormat | 使用 [``](/docs/react/reference/components/plural) 分支，与所在内容块一同翻译 | | 译文交付 | 目录文件随应用一起打包 | 随应用打包，或通过 General Translation 的 CDN 交付，无需重新部署即可更新 | | 许可证 | MIT | MIT | 来源：[next-intl App Router 初始化设置](https://next-intl.dev/docs/getting-started/app-router)、[next-intl 服务端与客户端用法](https://next-intl.dev/docs/environments/server-client-components)、[gt-next 快速入门](/docs/react/nextjs-quickstart)。 ## 同一个标题在各个库中如何实现？ 在 next-intl 的消息目录工作流中，源消息存放在 JSON 文件中： ```json { "Projects": { "heading": "Find your next project" } } ``` 该组件根据命名空间和键选择消息： ```tsx import { useTranslations } from 'next-intl'; export default function ProjectHeading() { const t = useTranslations('Projects'); return

{t('heading')}

; } ``` 而使用 gt-next 时，同一句话可以直接留在组件中： ```tsx import { T } from 'gt-next'; export default function ProjectHeading() { return (

Find your next project

 ); } ``` 以上两段代码片段均假设各个库的提供者和配置均已就绪。请参阅 [next-intl 初始化设置指南](https://next-intl.dev/docs/getting-started/app-router)和 [`` 参考](/docs/react/reference/components/t)。 使用消息目录时，审阅者可以脱离代码单独阅读文案。而使用内联文案，审阅者可以直接在所属的 JSX 中查看每个句子，General Translation 也能以该结构作为上下文进行翻译。对于仍有歧义的措辞，gt-next 的 [`` 支持 `context` 属性](/docs/react/reference/components/t#context)，next-intl 的[实验性提取功能则支持消息描述](https://next-intl.dev/docs/usage/extraction#descriptions)。 next-intl 的实验性 [`useExtracted`](https://next-intl.dev/docs/usage/extraction) API 同样支持内联编写消息，并将其提取到消息目录中。提取改变的只是文案的编写方式，并不会翻译提取出的消息目录，这些消息目录仍需由你的团队或翻译服务提供译文。 ## 能否在继续使用 next-intl 的同时使用 General Translation？ 可以。`gt` CLI 会根据你的 `package.json` 检测到 next-intl，并在保留 next-intl 消息语法的前提下[翻译其 JSON 消息目录](/docs/cli/guides/generating-translations)。你的组件、翻译调用和路由都无需改动。 如需试用，只需在 `gt.config.json` 中指定源消息目录和目标消息目录，导入已有的译文，然后翻译一个新的区域设置即可。审校人员可以在[仪表板翻译编辑器](/docs/platform/dashboard/guides/reviewing-translations)中修正翻译结果。如果他们直接编辑代码仓库中已下载的消息目录，请在下一次翻译运行前执行 [`gt save-local`](/docs/cli/reference/commands/save-local)，以保留这些修改。 如果你之后迁移到 gt-next，可参阅[迁移指南](/docs/react/guides/migrating-i18n-libraries)，其中介绍了如何导入已审校的译文、保留现有字典，以及如何在逐个路由迁移期间同时运行两个库。 ## 每个库如何处理服务端组件和客户端组件？ 两个库都无需将 App Router 页面转换为客户端组件即可实现本地化，区别只在于各个环境中调用的 API 不同。 | 组件 | next-intl | gt-next | | ------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 同步服务端组件 | [`useTranslations`](https://next-intl.dev/docs/environments/server-client-components#using-internationalization-in-server-components)，使用请求配置 | JSX 使用 [``](/docs/react/reference/components/t)；字符串使用 [`useGT`](/docs/react/reference/hooks/use-gt) | | 异步服务端组件 | 从 `next-intl/server` 中 await [`getTranslations`](https://next-intl.dev/docs/environments/server-client-components#async-components) | 从 `gt-next/server` 中 await [`getGT`](/docs/react/nextjs/reference/functions/get-gt)，然后调用其返回的函数 | | 客户端组件 | 在 `NextIntlClientProvider` 内使用 [`useTranslations`](https://next-intl.dev/docs/environments/server-client-components#using-internationalization-in-client-components) | 在 [`GTProvider`](/docs/react/reference/components/gt-provider) 内使用 [``](/docs/react/reference/components/t) 或 [`useGT`](/docs/react/reference/hooks/use-gt) | 无论使用哪个库，都应将交互式控件保留在客户端组件中，而在服务端翻译页面的其余部分。此外，next-intl 还支持从服务端组件向客户端控件[传递已翻译的标签](https://next-intl.dev/docs/environments/server-client-components#option-1-passing-translated-labels-to-client-components)，这样客户端就无需接收完整的目录。 ## gt-next 的译文在生产环境中如何交付？ gt-next 支持两种交付方式： * **将译文打包进应用**：使用[本地加载器](/docs/react/guides/storing-translations)。生产环境中的应用直接读取自身的翻译文件，运行时不会调用 General Translation。译文更新会随下一次构建一并发布。 * **从 General Translation 的 CDN 加载译文**：使用[远程交付配置](/docs/react/nextjs/config)。已发布的修改无需重新构建即可同步到已部署的应用，具体生效时间取决于应用的版本和缓存设置。 gt-next 采用 [MIT 许可证](https://github.com/generaltranslation/gt)，无需 General Translation 账户即可渲染打包的译文，这与 next-intl 渲染其消息目录的方式相同。 ## 哪些团队在生产环境中使用 gt-next？ Cursor、Ramp、Profound、Cognition、Sierra 和 ClickHouse 的开发团队都在使用 General Translation。Profound 的核心产品是一款基于 Next.js App Router 构建的应用，其本地化工作正是借助 General Translation 完成的。查看[生产环境部署案例](https://generaltranslation.com/enterprise)。 ## 何时选择 next-intl 或 gt-next？ **继续使用 next-intl**：适用于其目录模型契合你的应用、且现有翻译流程运转良好的情况。如果主要痛点在于繁琐重复的键管理，不妨先试试它的实验性提取功能，再决定是否迁移。 **继续使用 next-intl 并引入 General Translation**：适用于翻译产出成为瓶颈的情况。`gt` CLI 会直接翻译你现有的消息目录，你的组件、调用和路由都无需改动。 **选择 gt-next**：适用于希望将文案内联写在 JSX 中、并在每次构建时生成译文的情况。建议先挑一个路由试用，该路由最好同时涵盖服务端组件和客户端组件、复数形式、富文本以及元数据。在替代内容就绪之前，保留该路由的区域设置 URL 和现有译文；迁移更多路由之前，先检查一遍生产环境构建。 如需开始，请按照 [Next.js App Router 快速入门](/docs/react/nextjs-quickstart) 操作。如需比较更多库，请参阅 [General Translation 与 i18next、react-intl 和 next-intl 的对比](/kb/general-translation-vs-i18n-libraries)。 ## 常见问题 ### next-intl 会翻译我的内容吗？ 不会。next-intl 只负责渲染和格式化消息目录中的消息。译文需由您的团队、译者或 [Crowdin](https://next-intl.dev/docs/workflows/localization-management) 等服务提供。此外，General Translation 也能直接翻译 next-intl 消息目录，无需迁移。 ### General Translation 能和 next-intl 一起使用吗？ 可以。`gt` CLI 会翻译 next-intl 的 JSON 消息目录，并保留 next-intl 的消息语法，因此你可以继续沿用现有的组件和路由。请参阅[生成翻译](/docs/cli/guides/generating-translations)。 ### gt-next 是免费开源的吗？ 是的。gt-next 采用 MIT 许可证，无需账户即可渲染内置在应用包中的译文。如需使用 General Translation 的托管服务生成译文，请参阅[定价](https://generaltranslation.com/pricing)。 ### gt-next 是否支持 React 服务器组件？ 支持。在同步服务端组件中使用 [``](/docs/react/reference/components/t) 和 [`useGT`](/docs/react/reference/hooks/use-gt)，在异步服务端组件中则使用 [`getGT`](/docs/react/nextjs/reference/functions/get-gt)。 ### 能否按路由逐步从 next-intl 迁移到 gt-next？ 可以。[迁移指南](/docs/react/guides/migrating-i18n-libraries)介绍了如何让两个库并行运行、导入现有译文，以及在需要的地方保留基于键的字典。 ## 其他 next-intl 替代方案 对于 Next.js 应用，团队还会考虑以下这些库： * **i18next：** 基于键值目录进行渲染，支持复数选择；搭配 react-i18next 和 next-i18next 使用，是 React 和 Next.js 应用的常见选择。 (参见 [General Translation vs. i18next](/kb/general-translation-vs-i18next)。) * **react-intl：** 用于格式化 ICU 消息，并提供 Next.js App Router 使用指南。 (参见 [General Translation vs. react-intl](/kb/general-translation-vs-react-intl)。) * **Paraglide JS：** 将目录编译为带类型、支持 tree-shaking 的消息函数，并提供适用于 webpack 构建的 Next.js 集成。 (参见 [General Translation vs. Paraglide JS](/kb/general-translation-vs-paraglide)。) ## 要点总结 * next-intl 和 gt-next 都支持 App Router、服务端组件和区域设置路由，且均采用 MIT 许可证。 * next-intl 负责渲染你提供的译文。gt-next 同样能渲染译文，此外 General Translation 还能以你的代码作为上下文，直接从内联 JSX 生成译文。 * 使用 General Translation 无需迁移：`gt` CLI 可以直接翻译现有的 next-intl 消息目录。 * 如果决定迁移，请逐个路由进行迁移，并在新译文就绪之前继续加载现有译文。 ## 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 还会以你的代码为上下文完成翻译。 - [如何为多语言 Next.js 应用设置 SEO？](https://generaltranslation.com/zh/kb/multilingual-nextjs-seo.mdx): 为每种语言提供独立的 URL，设置 html lang 属性，将每个页面的规范网址指向页面自身，为每种语言添加 hreflang 替代项，翻译标题和描述，并在站点地图中列出所有语言版本。 - [不用翻译文件也能做 i18n 吗？](https://generaltranslation.com/zh/kb/i18n-without-translation-files.mdx): 可以。使用 gt-react 或 gt-next 时，内容以内联方式直接写在组件中的 `` 组件内，译文在构建时作为输出生成，因此无需编写键，也无需为每个区域设置编写 JSON 文件并保持同步。 - [如何在 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: [Lokalise 替代方案：General Translation 与 Lokalise 对比](https://generaltranslation.com/zh/kb/general-translation-vs-lokalise.mdx) - Next question: [Phrase 替代方案：General Translation 与 Phrase 对比](https://generaltranslation.com/zh/kb/general-translation-vs-phrase.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/zh/kb/sitemap.md) for every article.