<%= t(".unread", count: @count) %>
``` 选择西班牙语并不会翻译这个文件。启用英语后备内容后，西班牙语读者看到的仍然是 "Inbox" 和 "You have 3 unread messages."。Rails 必须先有西班牙语目录，才能显示西班牙语文案。每新增或修改一条英语消息，每种语言都要重复同样的工作。 [rails-i18n](https://github.com/svenfuchs/rails-i18n) gem 提供区域设置格式和复数规则。[i18n-tasks](/kb/general-translation-vs-i18n-tasks) 负责检查缺失的键和复数形式。General Translation 则提供这些工具所需的已翻译消息。 ## 使用 General Translation 翻译 Rails 区域设置文件 查找仍交给 Rails I18n 处理，其他区域设置文件则由 General Translation 生成。`gt` CLI 基于 Node.js 运行，能够翻译 YAML 文件，并保留原有的键。在这个英译西的示例中，请将消息放在 `translations/en.yml` 中，并去掉最外层的 `en:` 键： ```yaml title="translations/en.yml" inbox: show: title: "Inbox" unread: one: "You have %{count} unread message." other: "You have %{count} unread messages." ``` 将 `gt.config.json` 指向这些工作文件。随后只需一个简短的导出步骤，即可补上 Rails 的区域设置键，并生成应用所加载的目录： ```json title="gt.config.json" { "defaultLocale": "en", "locales": [ "es" ], "files": { "yaml": { "include": [ "translations/[locale].yml" ] } } } ``` 按照[生成译文](/docs/cli/guides/generating-translations)中的说明设置 `GT_PROJECT_ID` 和 `GT_API_KEY`。如果此目录已有译文，请将其放入 `translations/es.yml` (去掉顶层的 `es:` 根键) ，然后先运行 [`npx gt upload`](/docs/cli/reference/commands/upload)，再生成新译文。 ```ruby title="script/export_rails_locales.rb" require "json" require "yaml" require "fileutils" config = JSON.parse(File.read("gt.config.json")) locales = ([config.fetch("defaultLocale")] + config.fetch("locales")).uniq catalogs = locales.to_h do |locale| messages = YAML.safe_load_file("translations/#{locale}.yml", aliases: true) raise "Expected a message map for #{locale}" unless messages.is_a?(Hash) [locale, { locale => messages }.to_yaml] end FileUtils.mkdir_p("config/locales") catalogs.each do |locale, catalog| File.write("config/locales/#{locale}.yml", catalog) end ``` ```bash npx gt translate && ruby script/export_rails_locales.rb ``` 导出操作会为此目录写入 `config/locales/en.yml` 和 `config/locales/es.yml`。请继续在 `translations/` 中编辑工作文件；应用加载的是导出后的副本。在下一次翻译运行之前，请使用 [`npx gt save-local`](/docs/cli/reference/commands/save-local) 同步本地翻译的修改。 General Translation 会结合项目的[词汇表和自定义提示词](/docs/platform/dashboard/guides/defining-context-for-translations)翻译每个文件，确保产品名称或正式语气在所有区域设置文件中保持一致；你的团队还可以在仪表板中[审阅和编辑译文](/docs/platform/dashboard/guides/reviewing-translations)。未更改的条目会复用已有译文，因此即使在 CI 中每次合并都运行 CLI，也只会翻译有变动的内容。 发布前，请运行 `i18n-tasks missing` 和 `i18n-tasks check-consistent-interpolations`，检查导出的目录中的键、复数形式和 `%{count}` 占位符。 ## Rails I18n 与 General Translation 对比一览 | 功能 | Rails I18n | General Translation | | --------------- | ---------------------------------- | ----------------------------------------------------------------------------- | | 简介 | 用于查找和格式化译文的 Ruby 库 | 翻译平台，提供 CLI、适用于 JavaScript 和 Python 的库以及仪表板 | | 在 Rails 应用中渲染译文 | 支持，可用于视图、数据控制者和邮件程序 | 为相同的 Rails I18n 调用提供目录 | | 生成译文 | 不支持 | 支持，通过 [`npx gt translate`](/docs/cli/reference/commands/translate) 生成 YAML 文件 | | 复数规则 | 默认使用英语规则；配合 rails-i18n 可使用 CLDR 规则 | 翻译已配置的源复数形式，由 Rails 在运行时选择 | | 跨文件一致性 | 取决于你的译者 | 词汇表和自定义提示词作用于每个文件 | | 审核 | 沿用你的拉取请求流程 | 仪表板，外加你的拉取请求流程 | | 费用 | 免费，MIT 许可 | [按用量计费](https://generaltranslation.com/pricing) | 如果译者或供应商已经在为你交付区域设置文件，或者你只支持一两种语言、可以手动编辑，那么单独使用 Rails I18n 就足够了。如果英文内容经常变动，而你希望在 CI 中自动重新生成所有区域设置文件并保持术语统一，不必再等待一轮又一轮的翻译往返，就可以引入 General Translation。 ## 关键要点 * Rails I18n 负责渲染 `config/locales` 中的译文，并格式化日期和数字；rails-i18n 则补充复数规则和区域设置数据。但两者都不会替你编写译文。 * General Translation 会结合你的词汇表和自定义提示词翻译 YAML，并在英文内容变更时让译文保持同步。 * 将可编辑的目录存放在 `translations/` 中，运行 [`npx gt translate`](/docs/cli/reference/commands/translate) 后，再按 Rails 的区域设置根目录将其导出。 ## Related questions - [General Translation 与 i18n-tasks：应该选择哪一个？](https://generaltranslation.com/zh/kb/general-translation-vs-i18n-tasks.mdx): i18n-tasks 是一个 Ruby gem，用于查找缺失和未使用的 Rails I18n 键、整理区域设置文件，还能借助 Google Translate、DeepL、OpenAI、Yandex 或 watsonx 补全缺失的键。General Translation 则结合你的词汇表、自定义提示词和仪表板审校，翻译完整的区域设置文件。两者分工不同，许多团队完全可以搭配使用。 - [General Translation 与 Mobility：该选哪一个？](https://generaltranslation.com/zh/kb/general-translation-vs-mobility.mdx): Mobility 将翻译后的模型属性存储在您的数据库中。General Translation 则通过其 API，结合您的词汇表和自定义提示词生成这些译文。两者搭配使用，即可在保留现有 Rails 模型的同时，翻译商品列表、文章及其他数据库内容。 - [General Translation 与 i18next、react-intl 和 next-intl 对比：应该选择哪个国际化库？](https://generaltranslation.com/zh/kb/general-translation-vs-i18n-libraries.mdx): i18next、react-intl 和 next-intl 等开源库本身并不翻译任何内容。它们只负责显示你在各语言目录文件中提供的译文，这些译文由你、你的译者或其他服务编写。General Translation 的库同样开源，承担同样的工作，此外 General Translation 还会以你的代码为上下文完成翻译。 - [为什么选择 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 结合上下文直接翻译代码中的内容，每次发布都同步交付所有语言，并基于开源库运行，不存在供应商锁定。 - [对开发者来说，最好的本地化软件是什么？](https://generaltranslation.com/zh/kb/best-localization-software.mdx): 选择一套能覆盖整条流水线的系统——从代码中的国际化库，到翻译和投递——而不是把独立的库、翻译管理系统和翻译供应商拼凑在一起。 ## Previous and next questions - Previous question: [General Translation 与 Paraglide JS：该选哪一个？](https://generaltranslation.com/zh/kb/general-translation-vs-paraglide.mdx) - Next question: [General Translation 与 Symfony Translation：该选哪一个？](https://generaltranslation.com/zh/kb/general-translation-vs-symfony-translation.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/zh/kb/sitemap.md) for every article.