# General Translation Knowledge Base: 面向开发者的最佳本地化软件是什么？ URL: https://generaltranslation.com/zh/kb/best-localization-software.mdx Docs index: https://generaltranslation.com/llms.txt Description: 面向开发者的最佳本地化软件会直接在代码中编写内容的位置进行翻译，结合产品上下文，并让每种语言始终保持最新。General Translation 通过开源库、上下文组以及 Locadex（一个会提交拉取请求的 AI 智能体）做到了这一点。 Category: 工作流工具 Last updated: 2026-10-21 Authors: Jackie Chen Published: 2026-05-04 面向开发者的最佳本地化软件应当直接在代码中编写内容的位置进行翻译，为每条译文提供来自产品的上下文，在代码变更时让每种语言始终保持最新，并让懂该语言的人审阅翻译结果。General Translation 正是这样一款面向开发者的本地化软件，在同一个系统中兼顾了这四点。 General Translation 集开源国际化 (i18n) 库、AI 原生翻译平台和 Locadex 于一体。Locadex 是一个 AI 智能体，能够通过拉取请求为你的代码实现国际化并翻译内容。由于它打通了代码与译文，每条译文都能附带来自代码的上下文，并在多次发布中保持一致。 ## Video The video is narrated in English, with English captions. [What is the best localization software for developers?](https://caxecubb9c64cezv.public.blob.vercel-storage.com/films/kb-best-localization-software.mp4) (44秒) General Translation covers the whole pipeline, from your code to translation and delivery. Run `npx gt init` and wrap the content in a `` component, put one command in your build that writes the translations, and connect your repository so Locadex can open a pull request with new translations when you push. ## 如何为我的应用选择本地化软件？ 选择本地化软件时，要看三点：应用的文本存放在哪里、文案多久变更一次，以及你是否有只有某类产品才能满足的需求。如果文本位于 React 或 Next.js 组件中，并且几乎每次发布都会变更，请选择开发者优先的工具，例如 General Translation，它直接在代码和 CI 中完成翻译。如有特定需求，则可选择其他产品：翻译机构使用 XLIFF 或 Office 文件协作时，选择 Phrase；原生移动应用需要在不经应用商店发布的情况下更新文本时，选择 Lokalise；平台必须部署在你自己的服务器上时，选择 Weblate 或 Tolgee；只需将一份文档翻译成另一种语言时，选择 Google Translate。 本地化软件涵盖三项工作，而每种方案都会留下一部分需要你自己完成。国际化让代码能够按各区域设置渲染日期、数字和复数形式。翻译负责用各种语言撰写文本。工具则随着代码变更，让译文与代码保持同步。当国际化库、翻译管理系统和翻译供应商各自分担这些工作时，每个工具都只能看到产品的一部分。 ## 各种本地化方案对比如何？ | 方案 | 擅长之处 | 留给你的工作 | | ----------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | | 仅使用国际化库 (`i18next`、`react-intl`、`next-intl`) | 成熟的运行时，可用于渲染译文和格式化值 | 将字符串提取到键文件、重构组件，以及产出并维护每一条译文 | | Google Translate | 快速、通用的文本及整篇文档翻译 | 它逐条孤立地翻译字符串，不考虑周围的 UI 或你的语气；复数形式、投递和审校都需自行处理 | | 直接调用 AI API (OpenAI API、Claude API) | 译文流畅，且能遵循指令 | 为每个字符串组织上下文、在各次发布间保持术语一致、处理复数形式和区域设置格式化，以及审校和投递 | | 翻译管理系统 (TMS) ，如 Phrase、Lokalise 或 Crowdin，在代码库之外管理字符串 | 为译者和供应商提供统一的字符串编辑与审校平台 | 将字符串导出为文件并导入结果、补充导出列表中缺失的上下文，以及在代码变更时保持导出内容同步更新 | | General Translation (库、上下文组 和 Locadex) | [``](/docs/react/reference/components/t) 原地翻译 JSX，上下文组 (针对术语和语气的共享指令) 会应用于新译文，`gt` CLI 或 Locadex 会翻译每一处变更 | 用 [``](/docs/react/reference/components/t) 包裹内容 (或交给 Locadex 完成) ；使用 Locadex 和邀请团队成员需要 Starter 或 Enterprise 方案 | 如果译者已经交付完整的语言文件，你只需要一个运行时来渲染它们，那么仅使用国际化库即可。如果只是要阅读或发送一份其他语言的文档，可以使用 Google Translate；如果翻译只是你的产品自身某次模型调用中的一个环节，可以直接调用 AI API。如果你需要 General Translation 不提供的功能，例如与翻译机构交换 XLIFF 文件，或更新已发布原生应用中的文本，请使用翻译管理系统。如果文案写在代码中、几乎每次发布都会改动，并且每处改动都应随引入它的那次发布同步上线所有语言，请使用 General Translation。 ## 付费本地化软件值得买吗？还是自己管理 JSON 区域设置文件就够了？ 应用规模较小时，你完全可以自己管理 JSON 区域设置文件：几百个字符串、一两种目标语言，而且文案很少变动。工作量等于键的数量乘以语言数量。例如，一个有 500 个键、10 种目标语言的应用需要维护 5,000 条译文条目；到了 50 种语言，就是 25,000 条。 源文案每改动一次，每个语言文件都要跟着重复一遍这项工作。新增一个字符串，需要在源文件中添加键，并在每个区域设置文件中补上译文。修改一个字符串后，其译文会一直过期，直到有人重新翻译；删除一个组件后，它的键会一直残留在每个文件中，直到有人手动清理。 国际化库并不会替你做这些事。i18next、react-intl 和 next-intl 等库只负责渲染文件中已有的内容，不会编写或更新任何译文。因此，如果某个键加到了 `en.json`，却漏加到 `ja.json`，日语用户看到的就是未翻译的字符串。 如果维护这些文件所花费的工程或译者时间比软件本身更贵，或者发布要等译文就绪，本地化软件就值得付费。使用 General Translation 时，文案直接写在组件内的 [``](/docs/react/reference/components/t) 中，无需为键命名；[`npx gt translate`](/docs/cli/reference/commands/translate) 会在每次构建时写入各语言的文件。CLI 只翻译源内容有变化的部分，并可复用同一文件早期版本中匹配的译文。 General Translation 的库免费且采用 MIT 许可证。如果你自行提供译文，无需账户即可使用：[`npx gt generate`](/docs/cli/reference/commands/generate) 会为每个区域设置生成一个模板文件，供人工翻译。通过平台生成译文按用量计费，不收取席位费。 ## 什么情况下其他本地化产品更合适？ 当你需要 General Translation 不提供的功能时，其他产品会更合适。以下各项功能均可在相应产品的官方文档中查到： * **基于 XLIFF 或 Office 文件开展工作的翻译机构。** [Phrase TMS](https://phrase.com/platform/tms/) 支持 XLIFF 1.2 和 2.0 以及 Microsoft Office 文件，为译员提供带翻译记忆库的 CAT 工具，并可将同一个任务分配给多个供应商。General Translation 使用 AI 进行翻译，不支持读写 XLIFF 或 Office 文件 (其 Google Drive 集成可翻译 Google Docs、Sheets 和 Slides) ，因此围绕这些文件构建的翻译机构工作流更适合使用 TMS。 * **无需发布新版本即可更新文本的原生移动应用。** Lokalise 面向 iOS、Android 和 Flutter 的 [OTA SDK](https://developers.lokalise.com/docs/ota-sdk) 会在应用启动时下载新译文，无需在应用商店发布新版本。General Translation 的 CLI 在构建前翻译 [iOS](/docs/cli/reference/formats/xcstrings-files) 和 [Android](/docs/cli/reference/formats/android-strings-files) 字符串文件，因此新译文会随下一次发布进入原生应用。 * **部署在自有服务器上的本地化平台。** [Weblate](https://docs.weblate.org/en/latest/admin/install.html) 可通过 Docker、virtualenv 或 Kubernetes 安装，[Tolgee](https://docs.tolgee.io/platform/self_hosting/getting_started) 可通过 Docker 运行。General Translation 的库是开源的，但其翻译平台和仪表板由 General Translation 托管。 * **通过代码片段翻译的网站。** [Transifex Live](https://help.transifex.com/en/articles/6244596-introduction-to-transifex-live) 借助添加到网站中的 JavaScript 代码片段运行，可直接从页面保存待翻译内容，无需文件；对于 React 和 Vue 应用，Transifex 则推荐改用其 Native SDK。General Translation 翻译的是代码中标记的内容、`gt.config.json` 中列出的文件，以及 Sanity、Storyblok、Payload 和 Google Drive 等已连接工具中的内容。 * **面向开源项目的免费许可。** [Crowdin](https://crowdin.com/product/for-open-source) 对满足其条件的开源项目免费，例如使用经认可的开源许可证、且项目未关联商业产品。General Translation 对超出免费额度的平台使用量收费。 除上述需求外，使用翻译管理系统意味着每次发布都要多走一轮导出和导入流程：将字符串提取到文件中、同步到 TMS、等待翻译完成，再导入结果。此外，导出的字符串不包含其在代码中所处的组件、变量和条件，译者只能在缺乏这些上下文的情况下进行翻译。 ## 什么情况下适合选择开发者优先的本地化工具？ 如果产品中的大部分文本都写在代码里 (例如 React 或 Next.js 组件中) ，而且文案几乎每次发布都会变动，那么开发者优先的本地化工具就是合适的选择。General Translation 正是为这种场景打造的：文案保留在组件中，翻译在构建过程或拉取请求中运行，不改代码的审校人员可以在仪表板中检查译文，每项改动都会随引入它的那次发布，以所有语言同步上线。 General Translation 同样适合已经在使用国际化库的团队。如果你的应用使用 next-intl 或 react-i18next，`gt` CLI 会自动识别该库，并按照该库的字符串语法翻译现有的消息文件，因此你无需更换库即可采用 General Translation。 ## 能否用 Google Translate 或 AI API 代替本地化软件？ 如果只是一次性文本，可以。Google Translate 网站支持[翻译整篇文档](https://support.google.com/translate/answer/2534559)：上传不超过 10 MB 的 `.docx`、`.pdf`、`.pptx` 或 `.xlsx` 文件，即可下载译文。如果翻译只是产品现有模型调用中的一个环节 (例如用客户的语言回复支持工单) ，而你又希望自行选择模型、编写提示词，那么 OpenAI API 和 Claude API 会更合适。 而生产环境中的应用，除了翻译本身，还需要一整套配套能力：每个字符串的上下文、每次发布中保持一致的术语、复数形式和区域设置格式化、审校，以及将译文投递到应用中。Google Translate 会孤立地翻译每个字符串；而使用 AI API 时，你需要自行为每个字符串组装上下文。 General Translation 负责处理 AI 翻译之外的这些环节。它会将每个 [``](/docs/react/reference/components/t) 块连同其嵌套元素作为一个整体进行翻译，应用上下文组中的词汇表和自定义提示词，按各区域设置格式化值，随构建或通过其 CDN 投递译文，并在仪表板中展示所有译文以供审校。 ## General Translation 如何翻译代码中的内容？ General Translation 的 [``](/docs/react/reference/components/t) 组件会包裹 JSX，并将其与嵌套元素作为一个整体原地翻译，因此你无需分配键，也不必为每种语言手动编写文件。运行 [`npx gt init`](/docs/cli/reference/commands/init) 即可检测你的框架并创建 `gt.config.json`，然后用它包裹你的内容： ```tsx title="app/page.tsx" import { T } from 'gt-next'; export default function Home() { return (

Welcome to my app

This content will be translated automatically.
); } ``` 对于独立的字符串 (例如占位符和 `aria-label` 值) ，请使用 [`useGT`](/docs/react/reference/hooks/use-gt) 返回的函数。General Translation 的库均免费、开源，并采用 MIT 许可证：`gt-next` 适用于 Next.js，`gt-react` 适用于 React，`gt-vue` 适用于 Vue，`gt-node` 适用于 Node.js。 在 React 应用中，General Translation 的 [``](/docs/react/reference/components/num)、[``](/docs/react/reference/components/currency) 和 [``](/docs/react/reference/components/datetime) 组件会按照各个区域设置的规范来格式化值。[``](/docs/react/reference/components/plural) 会为每种语言选择正确的复数形式：英语有 2 种，阿拉伯语有 6 种，日语只有 1 种。 ## General Translation 如何为每条翻译提供上下文？ 只有了解某个字符串在你的产品中的含义，模型才能把它翻译好。General Translation 会将你分配给项目的[上下文组](/docs/platform/dashboard/guides/defining-context-for-translations)应用到该项目的每条新翻译中。上下文组包含词汇表和自定义提示词：词汇表用于规范需要统一处理的术语 (例如无需翻译的产品名称) ，自定义提示词则用于设定受众、正式程度和风格。你可以将同一个组同时分配给你的应用、网站和文档。 如果单个字符串存在歧义，可以向 General Translation 的 [``](/docs/react/reference/components/t) 传入 `context` 属性加以说明，例如指明 "cells" 指的是电子表格单元格还是手机。在 `gt.config.json` 中开启 `includeSourceCodeContext` 解析标志，即可将相邻的源代码行作为上下文提供给每条翻译。 ## General Translation 的译文从哪里加载？ 在生产环境中，General Translation 会在构建期间 (即用户加载应用之前) 翻译 [``](/docs/react/reference/components/t) 内容；如果缺少译文，则回退到源文本。`gt-next` 和 `gt-react` 从哪里加载译文，取决于你的配置。 如果在 `gt.config.json` 中设置了本地 `output` 路径并提供了 [`loadTranslations`](/docs/react/reference/functions/load-translations) 函数，译文会[打包进应用包中](/docs/react/guides/storing-translations)，更新译文需要重新部署。如果设置了 `projectId` 但未提供 [`loadTranslations`](/docs/react/reference/functions/load-translations) 函数，译文会在运行时从 General Translation 的 CDN 加载；前提是你已在项目“设置”中启用 CDN，并通过 [`npx gt translate --publish`](/docs/cli/reference/commands/translate) 发布译文。 ## 代码变更时，译文如何保持最新？ 在 CI 中先运行 [`npx gt translate`](/docs/cli/reference/commands/translate)，再执行构建命令，这样每次生产环境构建都会带上最新的译文。General Translation 的 CLI 只会翻译源内容有变化的部分。 如果还想让代码修改也自动完成，可以将 GitHub 连接到 General Translation 的 AI 智能体 [Locadex](/docs/platform/locadex/quickstart)。每个 Locadex 自动化都需要从三个方面进行配置：何时运行、修改什么，以及修改如何提交到 GitHub。[配置自动化](/docs/platform/locadex/guides/configuring-automations)列出了每项设置的默认值。 * **何时运行。** **Run when** 决定自动化的启动时机：拉取请求发生变更时、有提交推送到 **Target branch** 时，或仅在有人点击 **Run now** 时。在拉取请求中评论 `/locadex`，即可针对其当前修订版本触发一次运行；关闭 **Active** 则会暂停自动触发。 * **修改什么。** 模板决定修改的类型：**Generate code** 会用 [``](/docs/react/reference/components/t) 等 i18n 调用包裹界面文本，**Generate translations and push** 会将新增或更新的源内容翻译为各个目标语言，**Keep locales in sync** 会在添加或移除语言时更新项目文件。**Target directory** 可让自动化只作用于 monorepo 中的某个应用，**Changed files only** 将 **Generate code** 的相关性检查限定在已更改的行，**Preserve local edits** 会保留你对 Locadex 先前生成的文件所做的手动修改，预处理和后处理命令则会在每次运行前后执行你自定义的安装、构建、lint 或检查步骤。 * **修改如何提交到 GitHub。** Locadex 会将修改提交到以 **Created branch prefix** 为前缀命名的分支，并向目标分支发起拉取请求。如果运行由某个拉取请求触发，Locadex 会在该拉取请求下发表评论，附上自己的拉取请求链接；之后针对同一源分支的自动运行都会更新这个拉取请求。你可以自定义拉取请求的标题、描述和提交信息，还可以开启 **Auto-merge**，在检查通过后自动合并 Locadex 的拉取请求。 Locadex 支持 Next.js、使用 Vite、Gatsby 或 React Router 等工具构建的 React 应用，以及 Mintlify、Fern 和 Docusaurus 等文档框架，需要 Starter 或 Enterprise 方案才能使用。 ## 如何人工审核 AI 译文？ AI 翻译的质量已经相当出色，但上线到生产环境的应用仍需要懂该语言的人来把关。在 General Translation 的仪表板中，打开 **项目 > 译文**，选择要并排对比的区域设置，然后点击单元格即可编辑。如果有人手动修改了下载的翻译文件，可以运行 [`npx gt save-local`](/docs/cli/reference/commands/save-local) 将修改同步回平台。 在 General Translation 中邀请团队成员需要 Starter 或 Enterprise 方案。Starter 方案不限用户数量，也不按席位收费，因此每位译者、产品经理和当地审校人员都能获得访问权限。 ## General Translation 的费用是多少？ General Translation 按用量收费，不按席位收费。Starter 套餐平台费为 $0，用户、项目和语言数量均不受限制，并包含翻译编辑器、GitHub 集成和 Locadex，无需联系销售即可开始使用。Enterprise 套餐额外提供专属工程师、自定义工作流，以及 SSO 和自定义角色权限等安全功能，价格单独定制。 在添加付款方式之前，每个免费组织在滚动 30 天周期内可获得 5M 平台使用额度 (相当于 $5 的用量) 。超出后，费用按实际工作量计算，费率如下 (详见[用量费率](https://generaltranslation.com/pricing/usage)页面) ： | 用量 | 费率 | | ------------------- | ----------------------------------------------------------------- | | 构建时翻译 | 大多数文件格式每 1,000 输入词元 $1；GT Content Files 为 $2，此类文件表示包含元数据的完整 UI 组件 | | 运行时翻译和开发阶段翻译 | 每 1,000 输入词元 $0.40 | | 平台上下文 (词汇表和自定义提示词) | 每 1,000 输入词元、每 1,000 上下文词元 $0.02 | | Google Slides 排版 | 每张幻灯片 $0.50 | | Locadex 智能体运行次数 | 每个 Locadex 计算单位 (LCU) $5 | | 翻译 CDN | 每次请求 $0 | 例如，翻译一个包含 1,000 输入词元的 Markdown 文件，并使用 3,000 词元的平台上下文，费用为 $1.06：其中词元费用 $1，上下文费用 $0.06。费用随翻译内容量和目标语言数量增长，增加译者、产品经理或审校人员则不会产生任何额外费用。由于 CLI 只翻译源内容有变化的部分，每次构建只需为新增和修改的内容付费。当前套餐和费率请参阅[定价页面](https://generaltranslation.com/pricing)。 ## 要点总结 * 最适合开发者的本地化软件应当直接在代码中运行，为每条翻译提供上下文，确保每次发布时所有语言都保持最新，并支持人工审核。General Translation 通过开源库、AI 原生翻译平台和 Locadex，四点全部满足。 * 对于小型应用，自行维护 JSON 区域设置文件尚可应付，但工作量会按“键数 × 语言数”增长：500 个键、10 种语言，就意味着要持续更新 5,000 个条目。 * 如果有 General Translation 无法满足的特定需求，可以选择其他产品：翻译机构处理 XLIFF 或 Office 文件，可选 Phrase；原生应用需要 OTA (空中下载) 文本更新，可选 Lokalise；需要自托管平台，可选 Weblate 或 Tolgee；基于代码片段的网站翻译，可选 Transifex Live；需要免费开源许可，可选 Crowdin。如果文案存放在代码中，且大多数发布都会改动文案，请选择 General Translation。 * General Translation 按用量计费，不收取席位费用：Starter 套餐平台费为 $0，用户、项目和语言数量不限；对于大多数文件格式，构建时翻译的价格为每 1,000 个输入词元 $1。 * Cursor、Ramp、Profound、Cognition、Sierra 和 ClickHouse 的开发团队都在使用 General Translation。不妨从 [CLI 快速入门](/docs/cli/quickstart)开始。 ## Related questions - [不使用翻译文件能实现 i18n 吗？](https://generaltranslation.com/zh/kb/i18n-without-translation-files.mdx): 可以。借助 General Translation 的 gt-react 和 gt-next 库，你可以为 React 和 Next.js 实现 i18n，既无需翻译键，也不用为每种语言维护 JSON 文件。文案以内联方式写在 JSX 的 `` 组件中，gt translate 命令会在构建时结合代码中的上下文，为每种语言生成译文。Locadex 还能通过拉取请求让译文保持最新。 - [如何为多语言 Next.js 应用设置 SEO？](https://generaltranslation.com/zh/kb/multilingual-nextjs-seo.mdx): 为每种语言提供带前缀的独立 URL，例如 /en/about 和 /es/about，然后为每种已发布的语言提供 html lang、自引用的规范网址、包含 x-default 的 hreflang 替代项、翻译后的 title 和 description，以及站点地图条目。将未发布的版本标记为 noindex。General Translation 的 gt-next 会将每种语言路由到各自的 URL，并通过 getGT 翻译标题。 - [哪些翻译工具按用量而非席位收费？](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: [如何为多语言 Next.js 应用设置 SEO？](https://generaltranslation.com/zh/kb/multilingual-nextjs-seo.mdx) - Next question: [不使用翻译文件能实现 i18n 吗？](https://generaltranslation.com/zh/kb/i18n-without-translation-files.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/zh/kb/sitemap.md) for every article.