# General Translation Knowledge Base: 面向开发者的最佳 AI 翻译工具：翻译 API 与本地化平台对比 URL: https://generaltranslation.com/zh/kb/best-ai-translation-tools.mdx Docs index: https://generaltranslation.com/llms.txt Description: 如果你已经有自己的本地化流水线，可以直接使用翻译 API；如果你希望统一管理上下文、一致性检查、审校和持续交付，请选择 General Translation。DeepL、Google Cloud Translation、OpenAI 和 Claude 可以作为生产环境流水线的翻译引擎；而 General Translation 则直接为你的应用、文档和网站提供一整套流水线。 Category: 翻译 Last updated: 2026-10-28 Authors: General Translation Team Published: 2026-10-28 如果你已经有自己的本地化流水线，可以直接使用翻译 API；如果你希望统一管理上下文、一致性检查、审校和持续交付，请选择 General Translation。如今的 AI 翻译已经相当出色：把一个页面交给模型，几秒钟就能得到流畅的西班牙语译文。产品本地化真正的难点在于：如何把翻译与代码、审校人员以及发布流程衔接起来，最终让产品顺利上线。 ## 本地化平台与 AI 翻译 API 的对比 无论是 DeepL 这样的机器翻译引擎，还是 Claude 这样的通用模型，翻译 API 都能利用你提供的上下文、术语和示例，有些还支持翻译记忆库。而要对产品进行本地化，就需要把这些能力串联到以下四个工作流中： * **上下文。** 你的产品如何运作、每个字符串的用途、你的语言风格和术语，以及以往译文改了什么、为什么改。 * **一致性。** 同一术语在第 1 页和第 400 页保持一致，在应用、文档和网站中同样保持一致，且变量、复数形式和结构完好无损。 * **审校。** 一个供团队对照源文查看每条译文、进行编辑、添加备注，并控制谁能修改哪些内容的地方。 * **持续翻译。** 每次更新都能单独翻译，无需全部重新运行，同时保留审校人员的修改，并将结果投递到团队日常工作的地方。 使用 API 时，需要由你的集成来提供上下文和术语、验证结果，并打通审校与投递环节。General Translation 则统一管理这些工作流，覆盖从代码库中的内容到每次发布中经过审校的译文的全过程。 ## 面向开发者的 AI 翻译工具对比 | 工具 | 类别 | 上下文 | 一致性 | 审校 | 持续翻译 | | --------------------------------- | ---------- | ------------------------------ | --------------------- | ---------------- | ------------------------ | | General Translation | 本地化平台 | JSX 结构、`context` 备注、键级元数据和上下文组 | 共享词汇表、一致性检查、MDX 结构检查 | 仪表板，支持批注、历史记录和角色 | 仅翻译变更内容；Locadex 自动创建拉取请求 | | TMS AI (Lokalise、Crowdin、Phrase) | 翻译管理系统 | 词汇表、风格指南、键描述、截图 | 词汇表和翻译记忆库 | 译员编辑器和工作流 | 与代码仓库同步资源文件 | | DeepL API | 机器翻译 API | 每个请求附带一个 `context` 字符串 | 每个请求单独提供词汇表和翻译记忆库 | 需自行构建 | 需自行构建 | | Google Cloud Translation | 机器翻译 API | 词汇表，以及基于示例句的自适应翻译 | 每个请求指定词汇表 ID | 需自行构建 | 需自行构建 | | OpenAI API、Claude API | 通用 LLM API | 取决于你在提示词中提供的内容 | 在提示词中提供术语和示例；在代码中自行校验 | 需自行构建 | 需自行构建 | ## 该选哪一个？ * **General Translation：** 你希望将上下文、一致性检查、审校和交付统一管理，让你的应用、文档或网站每次发布都能同步上线所有语言版本。 * **TMS AI：** 你已有本地化团队和外部译者在 Lokalise、Crowdin 或 Phrase 中负责本地化项目。 * **DeepL API：** 你需要在保留原有格式的同时翻译 Word、PowerPoint 或 PDF 文件，或者需要在现有系统中集成机器翻译引擎。 * **Google Cloud Translation：** 你正在使用 Google Cloud，并希望基于自己的示例句子调优自适应翻译。 * **OpenAI 或 Claude API：** 翻译只是你的产品现有模型调用中的一个环节，例如用客户的语言回复支持工单。 ## General Translation：本地化平台 General Translation 直接在内容编写的位置完成翻译。在 React 和 Next.js 中，[``](/docs/react/reference/components/t) 会将 JSX 作为一个整体发送，连同其中的元素、变量以及一条可选的 [`context`](/docs/react/reference/components/t#context) 备注。`gt` CLI 可翻译 JSON、YAML、Markdown、PO、iOS 和 Android 字符串文件以及[其他格式](/docs/cli/reference/config#files)；`gt-node` 中的 [`tx`](/docs/node/reference/functions/tx) 则用于翻译仅在运行时才存在的内容。 * **上下文：**[上下文组](/docs/platform/dashboard/guides/defining-context-for-translations)包含词汇表和自定义提示词：前者用于统一产品名称和关键术语，后者用于控制语气，并可针对单个区域设置。上下文组会应用于所有分配了它的项目。 * **一致性：**一致性检查会将新译文与现有译文进行比对。Markdown 和 MDX 页面会先经过一轮校对，再与源内容逐项核对：标题、代码块、链接、导入语句和 frontmatter 必须保持一致，否则译文会被自动修正。 * **审校：**审校人员可以在[仪表板](/docs/platform/dashboard/guides/reviewing-translations)中对照源内容编辑译文、添加批注并查看版本历史记录。访问权限由角色控制；Enterprise 方案还提供 SSO 和审计日志。 * **持续翻译：**在 CI 中运行 [`npx gt translate`](/docs/cli/reference/commands/translate) 时，只会翻译源内容有变动的部分。[Locadex](/docs/platform/locadex/quickstart) 是一个 AI 智能体，会在你指定的拉取请求或提交上运行，并创建一个包含译文的拉取请求。 [按用量计费，不按席位收费](https://generaltranslation.com/pricing)。Cursor 已在其网站和文档中使用 General Translation，覆盖 14 种以上的区域设置。 (参见[生产环境部署案例](https://generaltranslation.com/enterprise)。) ## TMS AI：Lokalise、Crowdin 和 Phrase 翻译管理系统直接在其编辑器内运行 AI。Lokalise 的 [Pro AI](https://docs.lokalise.com/en/articles/11776521-what-is-standard-ai-mt-and-pro-ai) 会利用键描述、词汇表、风格指南和任务说明，而其 Standard AI/MT 档位则调用 Google Translate 和 DeepL，不使用这些上下文。[Crowdin AI](https://support.crowdin.com/crowdin-ai/) 可接入 OpenAI、Gemini、Anthropic 等服务商，并可在提示词中加入词汇表术语、翻译记忆库建议以及带标注的截图。Phrase [Language AI](https://phrase.com/platform/ai/) 会将任务分配到 30 多个引擎，并把得分较低的片段送交审校。这三者处理的都是从你的代码仓库同步过来的资源文件。 (参见 [General Translation 与 Lokalise 对比](/kb/general-translation-vs-lokalise)、[与 Crowdin 对比](/kb/general-translation-vs-crowdin)以及[与 Phrase 对比](/kb/general-translation-vs-phrase)。) ## DeepL API：机器翻译引擎 [DeepL API](https://developers.deepl.com/api-reference/translate/request-translation) 既可以翻译字符串数组 (逐个独立翻译) ，也可以翻译 Word、PowerPoint、PDF 等完整文档，并保留原有格式。它的 `context` 参数用于描述上下文文本，`formality` 用于设置语气的正式程度；单个请求最多可应用五个[词汇表](https://developers.deepl.com/docs/customize/managing-glossaries)，[翻译记忆库](https://developers.deepl.com/docs/customize/using-translation-memories)则可复用已审核通过的译文。但对于应用程序，你仍需自行提取字符串、保护占位符、补全额外的复数形式，并将结果写回。 (参见 [General Translation 与 DeepL 对比](/kb/general-translation-vs-deepl)。) ## Google Cloud Translation：神经网络模型与 LLM 模型 [Cloud Translation](https://docs.cloud.google.com/translate/docs/overview) 提供 Google 的神经机器翻译 (NMT) 模型，以及一个 [Translation LLM](https://docs.cloud.google.com/translate/docs/advanced/compare-models)，据 Google 介绍，后者由 Gemini 驱动。Advanced 版本新增了[自适应翻译](https://docs.cloud.google.com/translate/docs/advanced/adaptive-translation)，可基于至少五组示例句对调整输出；此外还支持词汇表、自定义模型和批量翻译。请求中没有可用于标明字符串出现位置的字段。如果向用户展示翻译结果，Google 要求注明[出处](https://docs.cloud.google.com/translate/attribution)。 (参见 [General Translation 与 Google Translate 对比](/kb/general-translation-vs-google-translate)。) ## OpenAI API 与 Claude API：在自己的提示词中完成翻译 LLM API 的翻译流畅自然，并能遵循有关语气、术语和格式的指令。[OpenAI API](https://developers.openai.com/api/docs/guides/structured-outputs) 和 [Claude API](https://platform.claude.com/docs/en/build-with-claude/structured-outputs) 都能将输出约束为符合 JSON schema 的格式，便于批处理一组键。其余部分则全靠你自己编写代码：提示词、为每个字符串附带哪些词汇表术语、检查占位符是否完整保留、确保每次运行的措辞保持一致，以及提供一个供审校人员修正输出的地方。 ## 生产环境本地化在模型之外还需要什么 基准测试以完整文档为单位对翻译引擎进行排名，而应用实际发送的却是简短的标签、带变量的句子和复数消息。 (参见[AI 翻译的准确度足以用于生产环境应用吗？](/kb/is-ai-translation-accurate)) ### 缺少上下文的短字符串 “Save”译成德语，既可以是 *speichern* (保存文件) ，也可以是 *sparen* (节省开支) 。如果只给引擎这一个单词，它只能靠猜。General Translation 在发送每个 [``](/docs/react/reference/components/t) 块时，都会附带其周围的元素和可选的备注；对于 JSON 和 YAML，还可以通过[键级元数据](/docs/cli/reference/keyed-metadata)文件为每个键添加备注和长度限制。 ### 术语漂移 API 可以在提示词中应用词汇表、翻译记忆库或术语，但你的集成需要负责让这些输入在各个请求和项目之间始终保持最新。如果缺少这种协调，同一个产品名称可能在这次发布中被翻译了，到下次发布时却又保留原文。上下文分组会在词汇表中固定术语，并通过自定义提示词设定语气 (例如德语中使用正式的“Sie”) ，并应用于所有已分配的项目。 (参见[如何在 AI 翻译中保持术语一致？](/kb/ai-translation-glossary)) ### 变量、复数形式与结构遭到破坏 翻译时必须完整保留 `{name}`，并为每种语言提供相应的复数形式：英语有两种，阿拉伯语则有六种。对于文档，标题 ID、代码块和链接都必须原样保留。General Translation 的 [``](/docs/react/reference/components/var) 会将动态值排除在翻译之外，[``](/docs/react/reference/components/plural) 会覆盖目标语言所需的每一种复数形式，MDX 页面也会对照其源结构进行校验。 ### 修改无法保留 审校人员的修正应当在下一次运行后依然保留。在仪表板中，审校人员可以打开 **项目 > 译文**，对比不同区域设置并编辑任意条目，下一次 Locadex 运行会将这些修改纳入拉取请求。 (参见[如何审校和编辑译文？](/kb/review-translations)) ## 常见问题 ### 对开发者来说，DeepL 和 Google Translate 哪个更好？ 目前没有公开的基准测试能给出定论，因为主流的机器翻译评测任务 WMT 会对商业引擎做匿名处理。建议用你自己的字符串实测对比，并考察各自 API 支持哪些功能：DeepL 提供上下文字段、正式程度设置和自定义指令；Google 则提供基于 Gemini 的 Translation LLM，以及基于示例句对的自适应翻译。两者都只是 API，所以无论选哪个，围绕它们的流水线都得你自己搭建。 ### 我可以用 ChatGPT 或 Claude 翻译我的应用吗？ 可以。只要你的流水线能够提供上下文和术语、检查占位符和复数形式，并打通审校与投递环节，它们的 API 就足以支撑生产环境中的本地化。General Translation 会围绕模型管理这整套工作流，你的团队无需自行维护这些环节，即可交付译文。 ### 哪款 AI 翻译工具能与我现有的国际化库配合使用？ 都可以。如果使用 API，你需要编写脚本，从库所加载的资源文件中提取字符串，再将译文写回。TMS 集成则负责同步这些文件。General Translation 的 CLI 同样能翻译这些文件：如果你的 `package.json` 中声明了 `next-intl` 或 `i18next`，它会[沿用该库的字符串语法](/docs/cli/guides/generating-translations)，无需更换库。 ## 要点总结 * 如果你已自建本地化流水线，请选择翻译 API；如果你希望统一管理上下文、一致性检查、审校和持续交付，请选择 General Translation。 * DeepL 和 Google Cloud Translation 是处理文本和文档的强大翻译引擎；OpenAI 和 Claude API 则适合在你自己的模型调用中完成翻译。无论选择哪一种，流水线都需要你自行搭建和维护。 * Lokalise、Crowdin 和 Phrase 提供的 TMS AI 适合以译员为主导、基于同步资源文件的项目。 * General Translation 是专为每次发布都有变化的产品打造的本地化平台：它从代码和上下文组中获取上下文，并提供一致性和结构检查、仪表板审校以及 Locadex 拉取请求。 ## Related questions - [DeepL 替代方案：General Translation 与 DeepL 对比](https://generaltranslation.com/zh/kb/general-translation-vs-deepl.mdx): DeepL 是一款机器翻译 API，你发送的每段文本或每份文档，它都会返回对应的译文。General Translation 则是一个本地化平台，它补足了 API 留给你自行处理的部分：来自代码和团队的上下文、在所有用户交互界面中保持一致的术语、在仪表板中进行审校，以及随每次发布持续翻译。 - [AI 翻译的准确度足以用于生产环境应用吗？](https://generaltranslation.com/zh/kb/is-ai-translation-accurate.mdx): 对于使用广泛的语言，通常可以，但前提是它要先通过针对你自己的语言、UI 字符串和高风险内容的评估。在 WMT25 中，Gemini 2.5 Pro 在 16 个语言对中有 10 个达到或超过了人工参考译文的水平，但文档级基准测试无法说明简短的界面字符串是否已经可以上线。 - [Google Translate 替代方案：General Translation 与 Google Translate 对比](https://generaltranslation.com/zh/kb/general-translation-vs-google-translate.mdx): Google Translate 适合快速翻译一次性文本，但要以另一种语言发布产品，还需要结合上下文翻译每个字符串、保持术语一致、正确处理变量和复数形式、进行审校，并建立发布流程。General Translation 能理解代码中每个字符串的上下文，将从代码、审校到每一次发布的整个本地化工作流全面自动化。 - [如何在 AI 翻译中保持术语一致？](https://generaltranslation.com/zh/kb/ai-translation-glossary.mdx): 维护一份统一的词汇表来收录已批准的术语（包括无需翻译的名称），在每次翻译请求中都应用它，避免变量和代码被翻译，并对结果进行审校。General Translation 通过上下文组实现这一点：上下文组中的词汇表和自定义提示词会应用于其分配到的每个项目；对于始终不翻译的值，则可使用 Var 组件。 - [面向开发者的最佳本地化软件是什么？](https://generaltranslation.com/zh/kb/best-localization-software.mdx): 面向开发者的最佳本地化软件会直接在代码中编写内容的位置进行翻译，结合产品上下文，并让每种语言始终保持最新。General Translation 通过开源库、上下文组以及 Locadex（一个会提交拉取请求的 AI 智能体）做到了这一点。 ## Previous and next questions - Previous question: [如何翻译 YAML 区域设置文件？](https://generaltranslation.com/zh/kb/translate-yaml-files.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/zh/kb/sitemap.md) for every article.