# General Translation Knowledge Base: 对于每天都要发布的团队，哪款持续本地化工具最合适？ URL: https://generaltranslation.com/zh/kb/best-continuous-localization-tools.mdx Docs index: https://generaltranslation.com/llms.txt Description: 选择 General Translation，即可在每次构建前翻译新文案，并借助已标记 JSX 中的上下文和共享的产品术语提升翻译准确性。你的团队可以在仪表板中审校并修正措辞，Locadex 则会自动创建拉取请求，将新的 UI 文本标记为待翻译。你无需改动现有的 i18next 或 next-intl 初始化设置，即可采用这一工作流。 Category: 工作流工具 Last updated: 2026-11-12 Authors: Jackie Chen Published: 2026-11-12 对于每天部署多次的团队来说，持续本地化工具需要满足两点要求。首先，译文必须在引入该文案的那次发布中就已就绪，而这一点可以通过在构建前于持续集成 (CI) 中完成翻译步骤来实现。其次，每新增一条文案，开发者的额外成本都应几乎为零，因为每周新增的文案多达数十条。如今已有多款工具支持在 CI 中翻译，因此真正起决定作用的通常是第二点：每新增一个字符串，各工具需要开发者额外做多少工作——从键和资源文件条目，到同步规则和审校。 ## 各类持续本地化工具对比如何？ | 工具与方式 | 触发方式 | 译文存放位置 | 能否赶上新增文案的那次部署？ | 开发者如何提供新文案 | | ----------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- | ---------------------------- | ----------------------------------- | -------------------------------------------------------------------------------- | | General Translation CLI | 在构建前运行 [`npx gt translate`](/docs/cli/reference/commands/translate) | 本地文件，或发布到 GT CDN 上的译文 | 能；构建会等待翻译完成 | 用 [``](/docs/react/reference/components/t) 包裹的 JSX (包括嵌套元素) ，无需键；或受支持的现有消息目录 | | General Translation 的 [Locadex](/kb/ai-coding-agent-vs-translation-pipeline#where-does-locadex-fit) | 已配置的拉取请求、推送或手动触发 | Locadex 拉取请求，可选启用 Auto-merge | 能，前提是其拉取请求在部署前合并 | 无需操作；**生成代码**会在拉取请求中包裹新的 UI 文本 | | CI 中的 [Crowdin CLI](https://crowdin.github.io/crowdin-cli/commands/crowdin-auto-translate) | 上传源文件，使用已配置的 AI 或机器翻译自动翻译，下载后再构建 | 构建工作区中的文件 | 能，前提是任务会等待 AI 或机器翻译完成并下载结果 | 资源文件及其 `crowdin.yml` 映射；可通过提取自动生成条目 | | [Crowdin GitHub 集成](https://support.crowdin.com/github-integration/) | 代码仓库同步，默认每小时一次，可配置调度 | 来自 `l10n_` 服务分支的拉取请求 | 仅当你暂缓发布、等同步拉取请求合并后才能 | 映射的代码仓库路径中的源文件 | | [Lingo.dev](https://lingo.dev/en/docs/workflows) CLI 或 GitHub App | 在 CI 中运行 `lingo push --wait`，或已配置的代码仓库事件 | 构建文件、翻译拉取请求，或源 PR 分支上的提交 | CI 中能；使用 GitHub App 时，需其提交已包含在发布版本中 | 区域设置文件，或提取的 [React 内联调用](https://lingo.dev/en/docs/react/i18n/quickstart)，无需单独的键 | | [Lokalise GitHub app](https://docs.lokalise.com/en/articles/1684090-github) | 按需或在推送时导入文件 | 由导出生成的拉取请求 | 仅当你暂缓发布、等导出拉取请求合并后才能 | 源资源文件及导入/导出设置 | | [Phrase Strings Repo Sync](https://support.phrase.com/hc/en-us/articles/5784125562012-GitHub-Strings) | 从受监控的分支导入 | 由 Repo Sync 导出生成的拉取请求 | 仅当你暂缓发布、等导出拉取请求合并后才能 | 资源文件及 `.phrase.yml` 映射 | 即使文件交换已经自动化，代码仓库同步仍需要配置项目、源路径、导出规则和发布顺序，并随着应用规模增长持续维护。 如果翻译机构在 CAT (计算机辅助翻译) 编辑器中翻译或交换 XLIFF 文件，如果你希望在同一平台上采购专业人工翻译，或者原生移动应用需要绕过应用商店发布、通过空中下载 (OTA) 更新字符串，请使用 Crowdin、Lokalise 或 Phrase 等翻译管理系统 (TMS) 。如果你想为每个语言对自行选择模型，请使用 Lingo.dev。如果你希望将标记的组件结构、共享的产品术语、译文生成和团队审校与发布流程打通，请使用 General Translation。如果你已在使用 next-intl 或 react-i18next，CLI 可以直接[翻译这些消息目录](/docs/cli/guides/generating-translations)，你的库和已审校的译文都能保留；内联 JSX 可以留待以后再考虑。 ## 除了在 CI 中翻译，General Translation 还能带来什么？ 真正决定日常成本的，是围绕每个新字符串展开的各项工作，而 General Translation 恰恰在这方面与众不同： * **翻译整个 JSX 块，而非零散字符串。** 新句子就是写在渲染它的组件中、位于 [``](/docs/react/reference/components/t) 内的 JSX，链接和格式一并包含，无需创建源键。你只需编辑组件；CLI 会提取内容，通过服务生成译文，并更新 SDK 所渲染的区域设置输出。 * **上下文直接来自代码。** CLI 会将标记的 JSX 作为一个整体发送，并附带其元素结构和 `context` 备注 (如有) ，因此文档按钮上的 "Save" 与价格徽章上的 "Save 20%" 送达时会带有各自不同的上下文。[上下文组](/docs/platform/dashboard/guides/defining-context-for-translations) (包括产品术语词汇表和用于控制语气的自定义提示词) 可在你的应用、文档和营销项目之间共享，确保术语统一。 * **自动标记新的 UI 文本。** Locadex 的**生成代码**自动化会找出尚未包裹的面向用户的文本，并提交拉取请求将其包裹起来，让流水线有内容可译。 * **复用已完成的翻译。** 未更改的源版本会直接复用已完成的工作；对于受支持的格式，已更改文件中的匹配内容同样可以复用。只有新增语言或主动重新翻译才会产生额外工作量。初始化设置请参阅 [CI 中的翻译指南](/kb/translations-in-ci)。 * **不按席位收费。** 按你请求的翻译工作量计费，且 Starter 方案包含无限用户，因此新增审校人员或产品经理不会产生任何额外费用。[定价对比](/kb/translation-pricing-without-seat-fees)分别梳理了 Crowdin、Lokalise 和 Weblate 的席位费、消息目录容量和翻译用量。 [Cursor 借助 General Translation 为其网站和文档支持 14 种以上的区域设置](https://generaltranslation.com/enterprise)。 ## 如何通过 GitHub Actions 或 Vercel 在每次构建时运行它？ 按照 [CLI 快速入门](/docs/cli/quickstart) 配置好项目和本地翻译加载器后，将翻译步骤加入构建命令。在 Vercel 上，将项目的 **Build Command** 设置为： ```bash npx gt translate && next build ``` 然后将 `GT_API_KEY` (一个项目密钥，需将 **文件** 设为 **写入**、启用 **Translation queue**，并将 **Context** 设为 **写入**) 和 `GT_PROJECT_ID` 添加为环境变量。在 GitHub Actions 中，在安装依赖后运行同一命令，并将该密钥存储为代码仓库密钥。如果翻译失败，构建会中止。在生成前添加 [`npx gt validate`](/docs/cli/reference/commands/validate) 来检查已标记的内容；同时测试各个页面，找出尚未标记的文本。如需通过 CDN 投递，请[在翻译步骤中启用发布](/kb/build-time-vs-runtime-translation#how-does-general-translation-deliver-translations)。 如果预览分支需要独立的翻译历史，请使用[分支跟踪](/docs/cli/guides/branching) ([`npx gt translate --enable-branching`](/docs/cli/reference/commands/translate)) 。CLI 会自动检测当前分支 (包括在 Vercel 上) ，让并行开发各自使用独立的译文。 ## 如何在不拖慢发布节奏的前提下检查译文？ 审校人员可以在[仪表板](/kb/review-translations)中对比和编辑译文。对发布至关重要的文案应在发布前完成审校；发布后再润色的措辞，可以将已保存的修正打包进下一次构建，或[发布到 CDN](/kb/build-time-vs-runtime-translation)。通过 CDN 加载的页面会在翻译缓存和页面缓存刷新后获取这些修正。企业批准工作流可以按区域设置分配审校人员组，并设定截止日期和需要审校的分支，确保每种语言都有专人负责。 ## 关键要点 * 只要在构建之前运行翻译，就能按时发布。Crowdin 的 CLI、Lingo.dev 和 General Translation 都支持这一点；而代码仓库同步会通过拉取请求返回译文，你必须先合并该请求才能部署。 * 持续本地化的日常成本，取决于每个新字符串需要多少额外工作。使用 General Translation 时，只需用 [``](/docs/react/reference/components/t) 包裹 JSX；如果交由 Locadex 自动包裹，则无需任何操作。上下文组还能让应用和文档中的术语保持一致。由于支持现有消息目录，你无需替换现有库即可上手。 * 如果你需要在 CAT 编辑器中采用翻译机构工作流、购买人工翻译服务，或为原生移动应用提供空中 (OTA) 更新，请选择 Crowdin、Lokalise 或 Phrase。 * General Translation 按用量计费，不收取席位费用。请从 [CLI 快速入门](/docs/cli/quickstart)开始。 ## Related questions - [如何在每次部署时保持译文同步更新？](https://generaltranslation.com/zh/kb/translations-in-ci.mdx): 在每次生产环境构建之前，将翻译作为流水线中的一个步骤运行，这样新增文案就会在引入它的那次部署中以翻译好的形式一同上线。General Translation 的 gt CLI 通过 npx gt translate 实现这一点，所需的项目 API 密钥和项目 ID 以 CI 密钥的形式存储。 - [AI 编程智能体与翻译流水线：本地化自动化该选哪个？](https://generaltranslation.com/zh/kb/ai-coding-agent-vs-translation-pipeline.mdx): 用编程智能体完成国际化初始化设置，再用翻译流水线在应用持续迭代时让每种语言保持最新。General Translation 会翻译新增和改动的文案，复用已完成的翻译，并为团队提供共享术语和仪表板审校。Locadex 将这两类工作串联起来，以拉取请求的形式提交代码改动和翻译。 - [构建时、运行时还是翻译代理：应该如何交付译文？](https://generaltranslation.com/zh/kb/build-time-vs-runtime-translation.mdx): 使用 General Translation 在发布前为应用中的已知内容生成译文，然后将其打包进代码，或从其 CDN 加载。打包方式让文案与特定发布版本绑定；而在 CDN 上发布的修改无需重新部署代码，即可在新的渲染中生效。对于访客需要即时获取的内容，请使用请求时翻译；如果无法修改网站代码，则使用代理。 - [General Translation 与 TMS（Crowdin、Lokalise、Phrase）对比](https://generaltranslation.com/zh/kb/general-translation-vs-tms.mdx): 如果开发者希望译文生成、源自代码的上下文以及审校流程都与产品发布紧密衔接，请选择 General Translation。你可以保留现有的消息目录和渲染库，也可以直接编写内联 JSX，无需翻译键。TMS 适合以语言供应商、CAT 编辑器和 XLIFF 交换为核心的翻译项目，其集成可以自动完成文件传输。 - [哪些翻译工具按用量而非席位收费？](https://generaltranslation.com/zh/kb/translation-pricing-without-seat-fees.mdx): 如果你希望翻译支出与实际请求的工作量挂钩，请选择 General Translation：用户数量不限，Starter 方案平台费用为 $0。Crowdin 和 Lokalise 的付费方案不限翻译角色数量，但会对部分其他角色收费；Hosted Weblate 不限译者数量，但按托管字符串容量收费。 ## Previous and next questions - Previous question: [AI 编程智能体与翻译流水线：本地化自动化该选哪个？](https://generaltranslation.com/zh/kb/ai-coding-agent-vs-translation-pipeline.mdx) - Next question: [构建时、运行时还是翻译代理：应该如何交付译文？](https://generaltranslation.com/zh/kb/build-time-vs-runtime-translation.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/zh/kb/sitemap.md) for every article.