# General Translation Knowledge Base: 对开发者来说，最好的本地化软件是什么？ URL: https://generaltranslation.com/zh/kb/best-localization-software.mdx Docs index: https://generaltranslation.com/llms.txt Description: 选择一套能覆盖整条流水线的系统——从代码中的国际化库，到翻译和投递——而不是把独立的库、翻译管理系统和翻译供应商拼凑在一起。 Category: 工作流工具 Last updated: 2026-05-04 Authors: Jackie Chen Published: 2026-05-04 如果你现在搜索“最好的本地化软件”，会看到十几篇出自本地化供应商之手的文章，每一篇都把自家产品排在第一。它们对比功能矩阵、罗列优缺点，最后得出的结论 (真是出人意料！) 无一例外都是：选我们。 我们不打算这么做。我们要讲的是：为什么这一整类产品都在解决错误的问题，以及解决正确的问题应该是什么样子。 ## 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. ## 本地化技术栈被割裂成了三块 在 2026 年发布一款多语言应用，需要把三套完全独立的系统拼凑在一起： 1. **国际化库** —— 在你的代码库中负责字符串提取、插值、复数处理和区域设置路由。它负责渲染译文，却不负责产出译文。 2. **翻译管理系统 (TMS) ** —— 存储翻译文件、管理工作流并协调交接。它介于你的代码和译者之间，但本身并不做翻译。 3. **语言服务提供商 (LSP) ** —— 真正产出已翻译内容的人工译者、翻译机构或机器翻译引擎。他们对你的代码和 TMS 一无所知。 库不了解你的译文，TMS 不了解你的代码，翻译服务商则两者都不了解。要把它们串联起来，前期得投入数周的工程时间；此后每个迭代还要耗费大量工时去同步文件、解决合并冲突、调试 Webhook，并时刻照看一条本就不是为此设计的流水线。 ## “端到端”究竟意味着什么 General Translation 不是一个库，也不是一个 TMS，而是一整条流水线。Cursor、Ramp、Profound、Cognition、Sierra 和 ClickHouse 等开发者优先的团队都在使用它。 * **开源开发者库**：[`gt-next`](/docs/react/nextjs-quickstart)、[`gt-react`](/docs/react/react-quickstart)，并支持 [React Native/Expo](/docs/react/react-native-quickstart)。即插即用的 SDK，全面支持 TypeScript。 * **AI 优先的翻译平台**：能够理解你的代码库、产品和术语，而不是在现有流程上硬套一层通用机器翻译。 * **AI 智能体 Locadex**：一位[自动化国际化工程师](/docs/platform/locadex/quickstart)，它会扫描你的代码库、完成代码国际化、生成译文，并在每次推送时自动创建拉取请求。 库与翻译引擎由我们一体化打造，让本地化轻松十倍。无需导出/导入 JSON，无需管理文件，也无需对接翻译机构。译文直接从你的源代码流向生产环境。 ## 传统 TMS 平台的问题出在哪里 传统的翻译管理系统诞生于 AI 出现之前的时代。它们预设了一套固定的工作流：从代码库中提取内容，上传到仪表板，分配给译者，再经过审校、批准、导出，最后重新集成回去。这套流程有时行得通，但速度慢、成本高，而且很脆弱。 **它们管理的是文件，而不是代码。** TMS 会导入你的翻译文件 (JSON、XLIFF、PO 等) ，并提供管理这些文件的工具。但真正的事实来源是你的代码库：组件、变量、UI 层级。只管理文件而不理解代码，上下文必然会在传递过程中丢失。 过去几年，大多数平台都加入了 AI/MT 功能，通常的做法是把字符串路由到第三方机器翻译引擎，再让你自行选择用哪一个。AI 看到的只是一个个孤立的字符串，看不到你的组件树、变量名，也看不到周围的 UI。这正是 MT 输出仍需大量编辑的原因。 **它们靠增加人手来扩展，而不是靠减少工作量。** TMS 的商业模式建立在协调人工译者的基础上：角色、权限、审校链、审批工作流。对于受监管的企业内容，这些确实必不可少；但对于一个要以 20 种语言发布 SaaS 应用的开发团队来说，这纯粹是额外负担。 至于定价？一些最热门的平台甚至要先和销售沟通才能看到报价。另一些则按席位收费，团队越大，费用涨得越快。成本难以预测，就很难为新增语言做预算。 ## 独立国际化库的问题在哪里 React 和 Next.js 生态中流行的国际化库在渲染方面表现出色：插值、复数处理、区域设置路由、服务端组件支持，一应俱全。 **但它们根本不负责翻译。** 你给它们什么，它们就渲染什么。你仍然需要： * 将每个可翻译字符串提取到 JSON 文件中 * 为每个区域设置单独维护一个文件 * 手动翻译这些文件、聘请译员，或者接入 TMS * 随着代码库的变化，保持每个文件同步 10 种语言、500 个键，就意味着要维护 5,000 个条目；50 种语言则是 25,000 个。这些工作，库一点忙也帮不上。它只负责渲染你给它的内容——充其量只解决了一半的问题。 ## General Translation 如何实现闭环 **1. 安装并编写代码。** 运行[初始化设置向导](/docs/cli/quickstart)，然后用 [``](/docs/react/reference/components/t) 组件包裹内容即可。无需提取键，也无需 JSON 文件。 ```tsx import { T } from 'gt-next'; export default function Home() { return (

Welcome to our app

This content is translated automatically.

 ); } ``` **2. 开发。** 译文按需生成。切换语言，立即查看效果。 **3. 发布。** 一条命令即可在构建时生成所有译文。译文均为预先生成，经过缓存后通过 CDN 分发。[查看部署指南 →](/docs/react/nextjs-quickstart#11-deploy-to-production) **4. 自动化。** [Locadex](/docs/platform/locadex/quickstart) 会持续监控你的代码仓库。每次推送代码后，它会扫描变更、对新内容进行国际化处理、生成译文，并自动创建 PR。整个流程无需人工参与，除非你希望介入。如需介入，翻译编辑器会并排展示差异，你可以在内容上线前后随时编辑。 ## 为什么大多数翻译 AI 都会出错 大多数本地化 AI 都是逐条、孤立地翻译字符串。“Apple”可能指水果，也可能指公司；“Cell”可能指生物细胞，也可能指电子表格的单元格。缺少上下文，AI 只能靠猜。 General Translation 的 AI 能够掌握代码库的完整上下文：组件层级、变量名、周边 UI，以及你的产品词汇表。译文地道自然，无需手动润色。遇到特殊情况，你还可以直接在组件中[添加明确的上下文](/docs/react/reference/components/t#props)。 ## 按用量计费，而非按人头计费 GT 采用按用量计费的定价模式，翻译多少就付多少。没有随团队扩张而水涨船高的按席位收费，也无需联系销售。[查看完整定价 →](https://generaltranslation.com/pricing) ## Related questions - [不用翻译文件也能做 i18n 吗？](https://generaltranslation.com/zh/kb/i18n-without-translation-files.mdx): 可以。使用 gt-react 或 gt-next 时，内容以内联方式直接写在组件中的 `` 组件内，译文在构建时作为输出生成，因此无需编写键，也无需为每个区域设置编写 JSON 文件并保持同步。 - [如何为多语言 Next.js 应用设置 SEO？](https://generaltranslation.com/zh/kb/multilingual-nextjs-seo.mdx): 为每种语言提供独立的 URL，设置 html lang 属性，将每个页面的规范网址指向页面自身，为每种语言添加 hreflang 替代项，翻译标题和描述，并在站点地图中列出所有语言版本。 - [为什么选择 General Translation 而不是 TMS（Smartling、Lokalise、Phrase、Crowdin 或 Transifex）？](https://generaltranslation.com/zh/kb/general-translation-vs-tms.mdx): Smartling、Lokalise、Phrase、Crowdin 或 Transifex 等翻译管理系统（TMS）负责协调译员，但工程师仍需提取字符串、发送出去、等待译文，再把译文接回产品中。General Translation 结合上下文直接翻译代码中的内容，每次发布都同步交付所有语言，并基于开源库运行，不存在供应商锁定。 ## 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.