# General Translation Knowledge Base: General Translation 与 Lingo.dev：该选哪一个？ URL: https://generaltranslation.com/zh/kb/general-translation-vs-lingo-dev.mdx Docs index: https://generaltranslation.com/llms.txt Description: Lingo.dev 以可配置的翻译引擎为核心，并提供 CLI、React 和 GitHub 工具来调用这些引擎。General Translation 是一个本地化平台，提供库、代码上下文、共享术语、所有方案均可用的仪表板审校，以及还能为代码完成国际化改造的 Locadex。如果你需要按语言对控制模型，请选择 Lingo.dev。 Category: 工作流工具 Last updated: 2026-10-28 Authors: General Translation Team Published: 2026-10-28 Lingo.dev 以可配置的翻译引擎为核心：你可以为每个语言对选择模型，再借助 CLI、React 和 GitHub 工具翻译文件、渲染本地化 UI，并创建翻译拉取请求。General Translation 则是一个本地化平台，围绕开源库、代码上下文、共享的上下文组、所有方案均可用的仪表板审校以及 Locadex 构建。Locadex 是一个 AI 智能体，能够为你的代码完成国际化改造，并通过拉取请求让译文始终保持最新。选择哪一个，取决于你希望如何配置和维护这套工作流：Lingo.dev 让你按语言对控制模型；General Translation 则将代码、翻译和团队审校整合到同一个平台中。 ## Lingo.dev 是什么 Lingo.dev 将其翻译 API 称为[本地化引擎](https://lingo.dev/en/docs/platform/engines)。每个引擎会为每个语言对分配一个模型，并配置按优先级排序的后备模型，这些模型均来自 Lingo.dev 所称的[数百个模型](https://lingo.dev/en/docs/platform/llm-models)。此外，引擎还会附带词汇表、规则和品牌语调。译文生成后，由 AI 审校人员对其[进行评分](https://lingo.dev/en/docs/platform)。 你可以通过以下方式调用引擎：`lingo` CLI (支持以 [18 种格式](https://lingo.dev/en/docs/cli/formats)推送区域设置文件并拉回译文) 、[GitHub App](https://lingo.dev/en/docs/workflows)、API，或托管的 [MCP 服务器](https://lingo.dev/en/docs/mcp)。[`@lingo.dev/react`](https://lingo.dev/en/docs/react/i18n/quickstart) 直接根据源语言调用渲染译文，由 CLI 负责提取，无需单独维护键命名空间。[alpha 版编译器](https://lingo.dev/en/docs/react/compiler)则会在构建时结合组件上下文翻译纯 JSX。在[定价](https://lingo.dev/en/pricing)方面，Lingo.dev 按 LLM 提供者的原价收费，另加收使用费用；其生产环境方案还需支付月度基础费用。 ## Lingo.dev 与 General Translation 对比一览 | | Lingo.dev | General Translation | | -------- | ------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | 类别 | 可配置的翻译引擎，附带 CLI、React 和 GitHub 工具 | 本地化平台：国际化库、CLI、仪表板和 [Locadex](/docs/platform/locadex/quickstart) | | 由谁渲染译文 | 你的国际化库、`@lingo.dev/react` 或 alpha 版编译器 | 采用 MIT 许可的 `gt-next`、`gt-react`、`gt-vue` 和 `gt-node`，或你现有的 i18next 或 next-intl 配置 | | 应用文案存放位置 | 区域设置文件、带必填上下文字符串的 `l.text()` 调用，或 alpha 版编译器中的普通 JSX | [``](/docs/react/reference/components/t) 中的内联 JSX、[`useGT`](/docs/react/reference/hooks/use-gt) 字符串，或你现有的资源文件 | | 上下文 | 引擎词汇表、规则和品牌语调；JSONC 备注或 `context` 字符串；alpha 版编译器中的组件上下文 | JSX 结构、变量、[`context`](/docs/react/reference/components/t#context) 备注，以及跨项目共享的上下文组 | | 全站一致性 | 所有引擎共享同一套词汇表、规则集和品牌语调；由 AI 审校检查词汇表合规性 | 对照现有译文进行一致性检查；对照源内容检查 MDX 结构 | | 人工审核 | Enterprise 异步流水线中的审校阶段，或直接编辑代码仓库中的文件 | 所有方案均提供仪表板审校，支持批注、版本历史和角色；Enterprise 方案提供审批 | | 代码国际化 | GitHub App 翻译文件；alpha 版编译器在构建时转换 JSX | Locadex 包裹未翻译的 UI 并创建拉取请求 | | 持续翻译 | GitHub App 在推送时创建或更新翻译拉取请求；在 CI 中运行 `lingo push` 发送新增和变更的键，并在源内容变更前保留手动修改 | 在 CI 中运行 [`npx gt translate`](/docs/cli/reference/commands/translate)，或使用 Locadex 拉取请求 | | 交付方式 | 代码仓库中的文件，或编译器应用包 | 代码仓库中的文件，或 General Translation 的 CDN | | 模型选择 | 每个语言对可从目录中任选模型；Enterprise 方案可使用自有密钥 | 由 General Translation 选择；Enterprise 项目可自选提供者 | | 定价 | LLM 成本按原价收取，另收使用费，Production 方案还收取基础费用 | [按用量计费，不按席位收费](https://generaltranslation.com/pricing) | ## 为什么团队选择 General Translation 而不是 Lingo.dev ### 在应用中渲染译文 两款工具都提供了渲染译文的方式。Lingo.dev 有三种方案： 1. **保留现有的国际化库。** 将 `.lingo/config.json` 指向该库的源文件，`lingo push` 就会发送新增和变更的键。你仍需为每个键命名，而单个字符串的上下文则来自 JSONC 文件中的注释，这些注释会被读取为[译者备注](https://lingo.dev/en/docs/cli/translator-notes)。纯 JSON 文件无法携带备注。 2. **采用 `@lingo.dev/react`。** 每个字符串都会变成类似 `l.text("Save", { context: "Form button" })` 的调用，其中 `context` 为[必填项](https://lingo.dev/en/docs/react/i18n/quickstart)。CLI 会提取这些调用，运行时再渲染翻译后的值，无需单独的键命名空间。 3. **采用编译器。** 它会结合组件上下文翻译普通 JSX，并将译文嵌入 Next.js App Router 和 Vite 应用的各区域设置应用包中。Lingo.dev 的文档将其标注为 [alpha 版本，且“不建议用于生产环境”](https://lingo.dev/en/docs/react/compiler)。 General Translation 的库可以渲染译文，并按区域设置格式化复数形式、日期、数字和货币，有无账户均可使用。你只需将 JSX 原样包裹在 [``](/docs/react/reference/components/t) 中，无需键、哈希值，也无需必填的上下文字符串。 (React Native、TanStack Start 和 Python SDK 目前仍处于实验阶段。) ### 来自代码的上下文 Lingo.dev 将引擎级词汇表、规则和品牌语调与逐字符串备注相结合；其 alpha 版编译器还能保留组件结构和插值上下文。General Translation 的 CLI 会将每个 [``](/docs/react/reference/components/t) 块连同其元素结构和变量占位符一并发送，因此包含链接和方案名称的句子会作为一个整体进行翻译。[上下文分组](/docs/platform/dashboard/guides/defining-context-for-translations)会为其所分配到的每个项目添加词汇表和自定义提示词，确保您的应用、文档和 CMS 内容使用统一的术语。 ### 审校 Lingo.dev 的[人工审核阶段](https://lingo.dev/en/docs/api/pipeline/human-review)运行在其异步流水线中，而根据其定价页面，该流水线仅在 Enterprise 方案中提供。在其他方案中，用户只能直接在代码仓库中编辑翻译后的文件。 在 General Translation 的[仪表板](/docs/platform/dashboard/guides/reviewing-translations)中，你的团队可以对照源文本编辑译文、比较不同区域设置、添加批注并浏览版本历史。所有方案均支持这些功能，且不限席位数。对已下载文件的手动修改可通过 [`npx gt save-local`](/docs/cli/reference/commands/save-local) 同步回平台。译文审批功能则需要 Enterprise 方案。 ### 对代码本身进行持续本地化 Lingo.dev 的 GitHub App 只会翻译与你的模式匹配的文件，不会为你的组件添加 i18n 调用。而 Locadex 的**生成代码**模板还会将未翻译的 UI 包裹在 [``](/docs/react/reference/components/t) 和 [`t()`](/docs/python/reference/functions/t) 调用中，并自动创建拉取请求。通过 `--publish` 发布到 General Translation CDN 的译文，无需重新构建，即可直接生效于从该 CDN 加载内容的应用。 Cursor 在其网站和文档中使用 General Translation，支持 14 种以上的区域设置。 (参见[生产环境部署案例](https://generaltranslation.com/enterprise)。) ## 何时适合选择 Lingo.dev * **你希望自行选择模型。** 你可以为每个语言对自行比较并选择 LLM，或使用自己的提供者密钥。 * **多个服务共用一个翻译 API。** 多个后端调用同一引擎，共享同一套词汇表和规则。 * **General Translation 无法读取的格式。** 你需要交换 XLIFF、Flutter ARB 或 Laravel PHP 文件。 General Translation 会替你选择模型；企业项目可以选择 Anthropic、OpenAI、xAI 或 Google 作为[提供者](/docs/platform/core/reference/gt-class-methods/translation/enqueue-files)。 ## 从 Lingo.dev 迁移到 General Translation Lingo.dev 的 CLI 会将普通的区域设置文件写入你的代码仓库，因此可以直接基于现有文件进行迁移。在 [`gt.config.json` 的 `files`](/docs/cli/reference/config#files) 中列出这些文件，运行 [`npx gt upload`](/docs/cli/reference/commands/upload) 将现有译文上传到平台，然后运行 [`npx gt translate`](/docs/cli/reference/commands/translate) 处理新增和变更的内容。如果应用使用 i18next 或 next-intl，CLI 会自动检测到该库，并按照其语法翻译对应的 JSON 文件，因此你可以继续沿用原有的渲染器。 词汇表术语可以导入到[上下文分组](/docs/platform/dashboard/guides/defining-context-for-translations)中，支持 CSV、TSV、JSON 和文本文件。如果之后想改用内联 JSX，请参阅[库迁移指南](/docs/react/guides/migrating-i18n-libraries)。如果你之前使用的是 Lingo.dev 的编译器，General Translation 的编译器同样可以借助[自动 JSX 注入](/docs/cli/guides/using-auto-jsx)，在构建时用 [``](/docs/react/reference/components/t) 包裹 JSX 文本。该功能默认关闭。 ## General Translation 能否替代 Lingo.dev？ 可以，尤其适合希望从组件开发到审校发布全程完成本地化的团队。Lingo.dev 提供可配置的引擎、React 渲染以及自动生成的翻译拉取请求。General Translation 将代码上下文与共享术语相结合，且所有方案均支持在仪表板中审校；此外，Locadex 还能为尚未翻译的 UI 自动添加 i18n 调用。 ## 其他 Lingo.dev 替代方案 * **Intlayer：**将每个组件的内容保存在带类型的声明文件中，并借助你配置的 AI 提供者补全缺失的语言。 (参见 [General Translation 与 Intlayer 对比](/kb/general-translation-vs-intlayer)。) * **Paraglide JS：**将你的消息目录编译为带类型、支持 tree-shaking 的函数。 (参见 [General Translation 与 Paraglide JS 对比](/kb/general-translation-vs-paraglide)。) * **i18next、react-intl 和 next-intl：**负责渲染你提供的消息目录，译文的生成则交由其他工具完成。 (参见 [General Translation 与国际化库对比](/kb/general-translation-vs-i18n-libraries)。) 如需在不使用键文件的情况下完成初始化设置，请参阅[无需翻译文件的国际化](/kb/i18n-without-translation-files)。如需让 Cursor 或 Claude Code 代为完成初始化设置，请参阅[使用编程智能体实现应用国际化](/kb/ai-agent-i18n-setup)。 ## 要点总结 * Lingo.dev 将可配置的翻译引擎与 CLI、React 和 GitHub 工具相结合；General Translation 则整合了库、代码上下文、团队审校和 Locadex。 * Lingo.dev 提供 React 渲染以及可感知组件上下文的 alpha 版编译器；但其内置的人工审核环节仅限 Enterprise 方案。 * General Translation 将文案内联在 [``](/docs/react/reference/components/t) 中，翻译时将其 JSX 结构作为上下文，并检查一致性；所有方案均支持团队在仪表板中审校。 * 如果你想自行选择模型，或需要处理 XLIFF、ARB 或 PHP 文件，请选择 Lingo.dev；若要迁移到 General Translation，可直接从其 CLI 已生成的区域设置文件入手。 ## Related questions - [General Translation 与 Intlayer：该选哪一个？](https://generaltranslation.com/zh/kb/general-translation-vs-intlayer.mdx): Intlayer 将每个组件的内容保存在组件旁的类型化声明文件中，所有语言并排编写，并可借助你配置的 AI 提供商补全缺失的语言。General Translation 则将文案以单一语言内联在组件中，并结合代码上下文生成其他语言的译文。 - [面向开发者的最佳 AI 翻译工具：翻译 API 与本地化平台对比](https://generaltranslation.com/zh/kb/best-ai-translation-tools.mdx): 如果你已经有自己的本地化流水线，可以直接使用翻译 API；如果你希望统一管理上下文、一致性检查、审校和持续交付，请选择 General Translation。DeepL、Google Cloud Translation、OpenAI 和 Claude 可以作为生产环境流水线的翻译引擎；而 General Translation 则直接为你的应用、文档和网站提供一整套流水线。 - [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 还会以你的代码为上下文完成翻译。 - [General Translation 与 Paraglide JS：该选哪一个？](https://generaltranslation.com/zh/kb/general-translation-vs-paraglide.mdx): 如果你希望将文案内联在代码中，并结合 React 组件结构、共享术语和仪表板审阅来生成译文，请选择 General Translation。如果你需要编译生成的带类型消息函数，以及按单条消息进行的 tree-shaking，请选择 Paraglide JS。Paraglide 负责渲染你的消息目录；General Translation 则将源文案与译文生成及后续更新衔接起来。 - [如何使用 Cursor 或 Claude Code 为应用实现国际化？](https://generaltranslation.com/zh/kb/ai-agent-i18n-setup.mdx): 在 Cursor 或 Claude Code 中使用 General Translation 的 Setup for Agents 提示词，选定一个功能和目标语言，然后让智能体完成实现并验证结果。借助浏览器登录、机器可读文档和 MCP 工具，初始化设置可以与翻译和审校环节无缝衔接。使用 Locadex，即可通过拉取请求自动完成后续的持续本地化工作。 ## Previous and next questions - Previous question: [DeepL 替代方案：General Translation 与 DeepL 对比](https://generaltranslation.com/zh/kb/general-translation-vs-deepl.mdx) - Next question: [Weglot 替代方案：General Translation 与 Weglot 对比](https://generaltranslation.com/zh/kb/general-translation-vs-weglot.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/zh/kb/sitemap.md) for every article.