知识库
使用 General Translation 对应用、文档和内容进行本地化的常见问题解答。
国际化
在代码库中配置 i18n：库、框架和组件。
- 应该自建 i18n，还是使用 General Translation？手写的 i18n（每种语言一个字典，外加一个简单的 t() 辅助函数）足以应对一两种语言、少量文案的场景。随着应用规模扩大，你会发现自己在重新实现复数规则、后备内容和文件同步，而且译文仍然得自己产出。General Translation 的开源库负责渲染，General Translation 则根据你的代码生成并更新译文。
- 发布多语言应用前应检查哪些事项？发布多语言应用前，需要在每个支持的区域设置中测试九项内容：包括错误情况在内的完整用户流程、语言检测与语言切换、变量与复数形式、货币与时区、文本扩展、从右到左布局、无障碍访问、生产环境中的译文交付，以及便于 SEO 抓取的语言 URL。每项检查都需要明确的通过标准。
- react-intl 替代方案：General Translation 与 react-intl 对比General Translation 让 React 团队在保留 ICU 消息语法的同时，获得译文生成、共享术语和仪表板审校能力。react-intl 提供格式化功能和 FormatJS 目录工具；General Translation 还能直接生成译文。
- i18next 替代方案：General Translation 与 i18next 对比如果你希望将文案内联在 React 组件中，并借助其 JSX 结构和产品上下文生成译文，请选择 General Translation。你也可以继续使用 i18next，并用 General Translation 翻译现有的目录。i18next 负责消息渲染和复数形式选择，译文则需要由单独的服务生成。
- General Translation 与 vue-i18n 对比：该选哪一个？General Translation 让 Vue 团队可以直接在模板中编写源文案，并通过 CLI 生成译文。其 gt-vue 插件在渲染这些内容时，会应用符合区域设置的复数形式和数字格式化。如果你希望免去维护基于键的源文件，可以选择它；而对于使用 Nuxt i18n 模块、已有成熟目录工作流的团队，vue-i18n 依然是合适的选择。
- General Translation 与 Symfony Translation：该选哪一个？Symfony Translation 负责在 PHP 和 Twig 中渲染消息。General Translation 则在 CI 中翻译其 YAML 消息目录，随源内容的变化持续同步更新，并为审校人员提供可直接编辑译文的仪表板。保留 Symfony 的渲染机制，同时为你的发布工作流加入自动化翻译。
- General Translation 与 Rails I18n：两者都需要吗？Rails I18n 负责查找消息并格式化日期和数字。General Translation 负责生成译文，在英文内容变更时让译文保持同步，并为团队提供用于审校的仪表板。两者搭配使用，即可在每次发布时交付已翻译的 Rails 目录。
- General Translation 与 Paraglide JS：该选哪一个？如果你希望将文案内联在代码中，并结合 React 组件结构、共享术语和仪表板审阅来生成译文，请选择 General Translation。如果你需要编译生成的带类型消息函数，以及按单条消息进行的 tree-shaking，请选择 Paraglide JS。Paraglide 负责渲染你的消息目录；General Translation 则将源文案与译文生成及后续更新衔接起来。
- General Translation 与 nestjs-i18n：该选哪一个？nestjs-i18n 在 NestJS 应用中为每个请求解析语言，并从按语言划分的 JSON 或 YAML 消息目录中渲染消息，但它本身并不翻译任何内容。General Translation 的 CLI 可以翻译这些消息目录，其 gt-node 库则能翻译仅在运行时才存在的内容。因此，你可以继续使用 nestjs-i18n，同时引入 General Translation。
- General Translation 与 Mobility：该选哪一个？Mobility 将翻译后的模型属性存储在您的数据库中。General Translation 则通过其 API，结合您的词汇表和自定义提示词生成这些译文。两者搭配使用，即可在保留现有 Rails 模型的同时，翻译商品列表、文章及其他数据库内容。
- General Translation 与 Lingui：该选哪一个？如果你希望像使用 Lingui 一样将文案内联在代码中，同时以 JSX 结构作为上下文自动生成译文，请选择 General Translation。Lingui 会将内联消息提取到消息目录中，交由译者或已连接的服务翻译。General Translation 的 CLI 会随代码变更自动更新译文，你的团队可以在仪表板中审阅。
- General Translation 与 Intlayer：该选哪一个？Intlayer 将每个组件的内容保存在组件旁的类型化声明文件中，所有语言并排编写，并可借助你配置的 AI 提供商补全缺失的语言。General Translation 则将文案以单一语言内联在组件中，并结合代码上下文生成其他语言的译文。
- General Translation 与 i18next、react-intl 和 next-intl 对比：应该选择哪个国际化库？i18next、react-intl 和 next-intl 等开源库本身并不翻译任何内容。它们只负责显示你在各语言目录文件中提供的译文，这些译文由你、你的译者或其他服务编写。General Translation 的库同样开源，承担同样的工作，此外 General Translation 还会以你的代码为上下文完成翻译。
- General Translation 与 GNU gettext：两者都需要吗？继续用 GNU gettext 负责提取和渲染，再引入 General Translation 来生成和维护 PO 文件。General Translation 会把译者备注和消息上下文纳入生成过程，统一应用共享术语，并为审校人员提供 仪表板 编辑器。你现有的 gettext 调用和已编译的消息目录均保持原样。
- General Translation 与 Django 翻译框架：两者都需要吗？将 Django 的翻译框架与 General Translation 搭配使用。Django 负责消息提取、语言选择和渲染；General Translation 则基于你的产品术语和仪表板审阅，填充 Django 的 PO 文件（包括复数形式）。你的模板和 URL 模式无需改动，译文会随代码同步更新。
- General Translation 与 Babel、Flask-Babel 对比：该选哪一个？Babel 可以为任意区域设置格式化日期、数字和货币，并管理 gettext 消息目录；Flask-Babel 则负责将其集成到 Flask 中，但两者都不会翻译你的字符串。General Translation 的 CLI 会为每种语言填充 Babel 的 PO 文件（包括复数形式），因此你可以继续使用 Flask-Babel，不必再手动翻译消息目录。
- 不用翻译文件也能做 i18n 吗？可以。使用 gt-react 或 gt-next 时，内容以内联方式直接写在组件中的 <T> 组件内，译文在构建时作为输出生成，因此无需编写键，也无需为每个区域设置编写 JSON 文件并保持同步。视频
- 如何在 JSX 中翻译条件文本？与其分别翻译三元表达式的两个分支，不如将整句包裹在 <T> 组件中，并用 <Branch> 表达条件。这样译者能看到完整的上下文，并能根据每种语言调整句子语序。视频
按区域设置格式化
各区域设置下的复数形式、日期、数字、货币和从右到左的文本。
翻译
机器翻译与 AI 翻译、翻译质量、上下文和词汇表。
多语言 SEO
多语言网站的区域设置路由、hreflang、站点地图和已翻译的元数据。
工作流工具
选择本地化工具，并通过持续本地化保持译文同步。
- 为什么选择 General Translation 而不是 TMS（Smartling、Lokalise、Phrase、Crowdin 或 Transifex）？Smartling、Lokalise、Phrase、Crowdin 或 Transifex 等翻译管理系统（TMS）负责协调译员，但工程师仍需提取字符串、发送出去、等待译文，再把译文接回产品中。General Translation 结合上下文直接翻译代码中的内容，每次发布都同步交付所有语言，并基于开源库运行，不存在供应商锁定。
- Transifex 替代方案：General Translation 与 Transifex 对比如果你希望翻译带标记的 JSX 时保留其结构和开发者上下文，并将译文打包进应用包或通过 CDN 分发，请选择 General Translation。Transifex Native 同样将字符串保留在代码中，但通过自家的内容分发服务发布。如果团队需要使用 Transifex 的翻译合作伙伴、质量评分或基于代码片段的网站翻译，Transifex 是很好的选择。
- Smartling 替代方案：General Translation 与 Smartling 对比如果你希望在发布流程中直接从代码生成应用译文，请选择 General Translation。Smartling 集翻译管理系统、AI 与人工翻译服务以及网站翻译代理于一体。General Translation 让文案保留在组件中，将其上下文一并带入翻译，并为团队提供用于审校的仪表板。
- React 应用最适合使用哪个国际化库？主流的 React 国际化库有四个：General Translation 的 gt-react、react-i18next、Lingui 和 React Intl。四者都能渲染和格式化译文，但只有 gt-react 还能根据你在 JSX 中内联编写的文案直接生成译文。如果想继续沿用 i18next 的消息目录和插件，请选择 react-i18next；如果需要将文案提取为编译后的消息目录，请选择 Lingui；如果需要 FormatJS 和 ICU MessageFormat，请选择 React Intl。
- Phrase 替代方案：General Translation 与 Phrase 对比如果你的应用和文档一起发布，General Translation 是 Phrase Strings 的有力替代方案。它基于代码和内容文件生成译文，统一应用共享术语，并直接在你的发布工作流中运行。Phrase 则将软件本地化与以文档为中心的 TMS、供应商管理以及丰富的翻译引擎选择融为一体。
- next-intl 替代方案：gt-next 与 next-intl 对比next-intl 负责渲染你在各语言消息目录中提供的译文。gt-next 同样会渲染译文，此外，General Translation 还能根据你在 JSX 中内联编写的文案生成译文。两者均采用 MIT 许可证，并支持 App Router 和服务端组件。如果你现有的 next-intl 目录运行良好，可以继续保留，并直接用 General Translation 翻译，无需迁移。
- Lokalise 替代方案：General Translation 与 Lokalise 对比对于希望在 JSX 中直接编写可读文案、并将翻译融入开发流程的团队来说，General Translation 是 Lokalise 的有力替代方案。Lokalise 的核心是共享键、设计工具集成和移动端 OTA（空中下载）投递。General Translation 根据应用中已标记的内容生成译文，并支持在其仪表板或 GitHub 拉取请求中进行审阅。
- General Translation 与 Weblate：该选哪一个？Weblate 是一个可自托管、基于 Git 的本地化平台，专为社区或团队协作翻译代码仓库文件而设计。General Translation 则将译文生成融入开发与发布流程，依托已标记的 JSX 和共享的产品上下文完成翻译。你可以继续沿用现有的 gettext 文件，也可以改用内联编写，连源文案目录的维护工作也一并省去。
- General Translation 与 Tolgee：该如何选择？Tolgee 是一个可自托管的平台，集基于键的消息、上下文内编辑和 AI 翻译于一体。General Translation 则将可读的文案直接保留在组件中，并根据标记的 JSX 生成译文，无需维护消息键，即可用所有语言发布新文案。
- General Translation 与 Locize 对比：该选哪个？Locize 是由 i18next 创建者打造的翻译管理系统，通过 CDN 分发译文，从运行中的应用收集新键，并提供 AI 翻译和上下文内编辑器。但国际化库及其键仍需你自己维护。General Translation 既可以充当你的国际化库并负责翻译，也可以翻译你现有的 i18next 文件。
- General Translation 与 i18n-tasks：应该选择哪一个？i18n-tasks 是一个 Ruby gem，用于查找缺失和未使用的 Rails I18n 键、整理区域设置文件，还能借助 Google Translate、DeepL、OpenAI、Yandex 或 watsonx 补全缺失的键。General Translation 则结合你的词汇表、自定义提示词和仪表板审校，翻译完整的区域设置文件。两者分工不同，许多团队完全可以搭配使用。
- Crowdin 替代方案：General Translation 与 Crowdin 对比如果你希望将文案保留在组件中，并随构建生成译文，请选择 General Translation。Crowdin 围绕资源文件、译者和审校工作流程来管理翻译项目，需要工程师将其接入应用，并随产品迭代持续维护。对于开源社区翻译和由供应商主导的翻译项目，Crowdin 依然是很好的选择。
- 对开发者来说，最好的本地化软件是什么？选择一套能覆盖整条流水线的系统——从代码中的国际化库，到翻译和投递——而不是把独立的库、翻译管理系统和翻译供应商拼凑在一起。视频