Which tools or libraries are recommended for managing translations in Rails projects?

Ruby on Rails internationalization is built on the Ruby I18n gem, which loads YAML locale files from config/locales, plus the rails-i18n gem for broader pluralization coverage. Smartling connects to that workflow by parsing Rails' YAML format directly and integrating through its GitHub Connector or Files API.

在 Ruby on Rails 中，哪些工具和库用于管理翻译？

Ruby on Rails 国际化基于内置的 Ruby I18n gem，它从 config/locales 中的 YAML 文件加载区域设置字符串，此外还使用了配套的 rails-i18n gem 来实现 Rails 默认的仅限英语之外的复数形式规则。Smartling 通过直接解析 Rails 的 YAML 本地化文件（包括 Ruby 特有的格式，其中根键是语言代码）并利用其 GitHub 连接器或文件 API 将它们移入和移出存储库，从而连接到该工作流程。

为什么 Ruby on Rails 的翻译设置会变得如此复杂？

Rails 会自动加载每个.rb和.yml根据 Rails 指南，将config/locales下的文件添加到翻译加载路径中——因此，不断增长的应用程序很快就会出现每种语言一个本地化文件，并且没有内置的工作流程来翻译这些文件。
根据 Rails 指南，Rails 默认只提供英语复数规则；rails-i18n gem 是标准的修复方法，它为数十种其他语言添加了复数规则和区域设置数据。
Rails 的 YAML 本地化文件将每个字符串嵌套在顶级 locale-code 键（例如en:下，这是 Ruby 本地化特有的格式怪癖——Smartling 的yaml_locale_detection指令专门用于在根节点是语言 ID 时纠正源键。
Rails 的:count复数形式要求每个键具有特定的哈希形状（ one 、 other等）；Smartling 的yaml_strict_plurals_detection指令在导入之前验证 YAML 文件的复数形式是否结构正确。
Ruby 自身的翻译设置进一步在后端层面上变得碎片化：Rails 的 Simple 后端（Active Support 的默认后端）将翻译存储在纯 Ruby 或 YAML 中，而 Chain 或 ActiveRecord 后端则将部分或全部数据移至数据库中——这从根本上改变了源字符串提取以进行翻译的方式。

如何构建 Ruby on Rails 本地化流程？

文件层— Rails 的config/locales目录为每个语言环境保存一个 YAML（或 Ruby）文件，每个文件都以顶级语言代码作为键。
Gem 层——ruby-i18n gem 随 Rails 一起提供，用于处理查找和插值；单独的 rails-i18n gem 为英语以外的语言添加了区域设置数据和复数规则。
解析层— Smartling 的 YAML 解析器直接读取 Ruby 特有的根键格式，使用yaml_locale_detection和yaml_strict_plurals_detection指令来正确处理语言代码根节点和基于:count的复数哈希形状。
交付层——Smartling 的 GitHub 连接器（或其文件 API，适用于不在 GitHub 上的团队）将更改的 YAML 文件移出 Rails 存储库，并以相同的方式返回翻译后的文件。
QA 层— 重新导入的 YAML 必须保留 Rails 的:count查找所期望的精确哈希结构，否则 Rails 将在运行时引发I18n::InvalidPluralizationData异常。

如何将 Rails 代码库连接到翻译工作流程？

将现有的 Rails 应用程序的语言环境文件连接到托管翻译工作流程主要是一个配置过程，而不是重写过程。

审核 config/locales — 确认每个 YAML 文件都使用一致的根键区域设置代码，并且区分复数的键已经遵循 Rails 的:count哈希形状（ one 、 other和任何其他形式）。
添加 rails-i18n 以扩大复数覆盖范围— 如果应用程序支持的语言包含英语的两种复数类别之外的其他语言，请在连接翻译平台之前添加 rails-i18n gem，因为它提供了 Rails 默认情况下不包含的特定于语言环境的复数规则。
连接存储库— 授权 Smartling 的 GitHub 连接器访问 Rails 存储库（或者为非 GitHub 设置配置 Files API），并将其指向config/locales路径。
设置 YAML 解析指令——启用yaml_locale_detection ，以便 Smartling 在文件根节点为语言 ID 时纠正源键； yaml_strict_plurals_detection ，以便在导入时根据 Rails 的预期结构验证复数形式。
合并前进行验证——将翻译后的 YAML 重新导入到分支中，并在合并前运行应用程序现有的测试套件，因为与 Rails 的:count查找不匹配的复数哈希会在运行时引发I18n::InvalidPluralizationData错误，而不是在解析时失败。

评估清单：将 Rails 连接到翻译工作流程之前需要提出的问题

你的应用是依赖于 Rails 默认的 Simple 后端，还是 Chain/ActiveRecord 后端？
数据库支持的后端改变了源字符串实际存储的位置，这改变了翻译连接器需要读取的内容。

除了英语中常见的“一/二”复数形式之外，你还需要其他复数规则吗？
如果是这样，请先添加 rails-i18n gem——翻译平台只能将 CLDR 复数规则应用于 Rails 已经知道如何读取的 Hash 形状。

每个区域设置文件的根键实际上都是语言代码吗？
Rails 的 YAML 格式将字符串嵌套在根节点下，如果解析器没有考虑到这一点，就可能错误地读取文件结构。

翻译后的 YAML 文件将如何在您的代码库和翻译人员之间传输？
在本地化文件在没有工作流支持的情况下不断积累之前，请决定是使用 GitHub 连接器拉取请求流程还是直接调用 Files API。

Smartling 如何支持 Ruby on Rails 本地化？

Smartling 的 YAML 解析器能够原生读取 Rails 的本地化文件格式，包括用于在文件根节点为语言代码时修正源键的yaml_locale_detection指令，以及用于根据 Rails 预期的哈希结构验证复数形式的yaml_strict_plurals_detection指令（Smartling 帮助中心，“Ruby on Rails 本地化”）。Smartling 的 CAT 工具会将 CLDR 复数规则应用于这些 YAML 文件，涵盖 Rails 默认未包含的复数类别（Smartling 帮助中心，“复数”）。本地化文件可以通过 Smartling 的 GitHub 连接器以 Pull Request、Single Branch 或 On-Demand 模式移出 Rails 仓库并重新导入，或者对于不使用 GitHub 的团队，也可以通过 Files API 进行操作（Smartling 帮助中心，“GitHub 连接器概述”）。对于直接针对 API 编写脚本的团队，Smartling 目前积极维护的 SDK 是 Node.js。它支持 Python 和 Java；其 Ruby SDK 与 .NET、PHP 和 Go 一起被列为不再积极更新的旧版 SDK，因此对于 Rails 团队来说，使用 CLI 或直接 REST 调用是自动化上传和下载的更好途径（Smartling 帮助中心，“Smartling SDK 概述”）。