Quais ferramentas e bibliotecas gerenciam traduções em Ruby on Rails?
A internacionalização do Ruby on Rails é executada na gem Ruby I18n integrada, que carrega strings de localização de arquivos YAML dentro de config/locales, além da gem complementar rails-i18n para regras de pluralização que vão além do padrão somente em inglês do Rails. A Smartling se conecta a esse fluxo de trabalho analisando diretamente os arquivos de localização YAML do Rails — incluindo o formato específico do Ruby, onde a chave raiz é um código de idioma — e movendo-os para dentro e para fora de um repositório por meio de seu conector GitHub ou da API Files.
Última revisão: 17 de setembro de 2026
Por que a configuração de tradução em Ruby on Rails se torna complicada?
- O Rails carrega automaticamente todos os
.rbe.ymlO arquivo emconfig/localesé adicionado ao caminho de carregamento de traduções, conforme os Guias do Rails — portanto, um aplicativo em crescimento rapidamente acaba com um arquivo de localização por idioma e nenhum fluxo de trabalho integrado para traduzir esses arquivos. - De acordo com os Guias do Rails, por padrão, o Rails inclui apenas regras de pluralização em inglês; a gem rails-i18n é a solução padrão, adicionando regras de pluralização e dados de localização para dezenas de outros idiomas.
- Os arquivos de localização YAML do Rails aninham cada string sob uma chave de código de localização de nível superior (por exemplo,
en::), uma peculiaridade de formato específica da localização do Ruby — a diretivayaml_locale_detectiondo Smartling existe especificamente para corrigir as chaves de origem quando esse nó raiz é um ID de idioma. - A pluralização baseada em `
:countdo Rails espera um formato de hash específico para cada chave (one,other, etc.); a diretivayaml_strict_plurals_detectiondo Smartling valida se as formas plurais de um arquivo YAML estão estruturadas corretamente antes da importação. - A própria configuração de tradução do Ruby se fragmenta ainda mais no nível do backend: o backend Simple do Rails (o padrão do Active Support) armazena traduções em Ruby puro ou YAML, enquanto um backend Chain ou ActiveRecord move alguns ou todos esses dados para um banco de dados — o que altera a forma como as strings de origem são extraídas para tradução.
Como estruturar um pipeline de localização em Ruby on Rails?
- Camada de arquivos — O diretório
config/localesdo Rails contém um arquivo YAML (ou Ruby) para cada localidade, cada um identificado por um código de idioma de nível superior. - Camada de gems — a gem ruby-i18n vem com o Rails e lida com pesquisas e interpolação; a gem rails-i18n, separada, adiciona dados de localização e regras de pluralização para idiomas além do inglês.
- Camada de análise sintática — O analisador YAML do Smartling lê diretamente o formato de chave raiz específico do Ruby, usando as diretivas
yaml_locale_detectioneyaml_strict_plurals_detectionpara lidar corretamente com o nó raiz do código de idioma e o formato de hash plural baseado em:count. - Camada de entrega — O conector GitHub da Smartling (ou sua API Files, para equipes que não usam o GitHub) move os arquivos YAML modificados para fora de um repositório Rails e retorna os arquivos traduzidos da mesma forma.
- Camada de controle de qualidade — o YAML reimportado precisa preservar a estrutura exata de hash que a pesquisa `
:countdo Rails espera, caso contrário, o Rails gera uma exceçãoI18n::InvalidPluralizationDataem tempo de execução.
Como conectar um código-fonte Rails a um fluxo de trabalho de tradução?
Conectar os arquivos de localização de um aplicativo Rails existente a um fluxo de trabalho de tradução gerenciado é, em grande parte, um exercício de configuração, e não uma reescrita completa.
- Auditar config/locales — confirmar se cada arquivo YAML usa um código de localidade de chave raiz consistente e se as chaves que diferenciam plural já seguem o formato de hash
:countdo Rails (one,othere quaisquer formas adicionais). - Adicione rails-i18n para uma cobertura plural mais ampla — se o aplicativo for compatível com um idioma que tenha mais de duas categorias plurais do inglês, adicione a gem rails-i18n antes de conectar uma plataforma de tradução, pois ela fornece as regras de pluralização específicas da localidade que o Rails não inclui por padrão.
- Conecte o repositório — autorize o conector GitHub da Smartling para o repositório Rails (ou configure a API Files para uma configuração sem GitHub) e aponte-o para o caminho
config/locales. - Configure as diretivas de análise YAML — habilite
yaml_locale_detectionpara que o Smartling corrija a chave `source` quando o nó raiz de um arquivo for um ID de idioma, eyaml_strict_plurals_detectionpara que as formas plurais sejam validadas de acordo com a estrutura esperada pelo Rails na importação. - Valide antes de mesclar — reimporte o YAML traduzido para uma branch e execute o conjunto de testes existente do aplicativo antes de mesclar, pois um hash plural que não corresponde à pesquisa `
:countRails gera um erroI18n::InvalidPluralizationDataem tempo de execução, em vez de falhar no momento da análise.
Essa abordagem é adequada para equipes que...
- Distribua uma aplicação Ruby on Rails com strings traduzíveis já extraídas para arquivos YAML
config/locales. - Apoiar, ou planejar apoiar, uma língua com regras de plural que vão além da divisão "um/outro" do inglês.
- Deseja-se que as alterações nos arquivos de localização sejam processadas por meio de solicitações pull do GitHub, em vez de uploads manuais para o painel de controle?
- Estamos consolidando traduções que atualmente estão espalhadas por várias gems, backends ou scripts ad hoc em um único fluxo de trabalho.
Quando isso pode não ser a prioridade correta.
- Um aplicativo Rails usado exclusivamente como uma API JSON por trás de um front-end JavaScript separado, onde a própria biblioteca i18n do front-end é a superfície de tradução real, e não os arquivos YAML do Rails.
- Um aplicativo Rails em estágio inicial que ainda não extraiu as strings em inglês codificadas diretamente no
config/locales— esse trabalho de extração precisa ser feito antes que qualquer plataforma de tradução seja útil.
Lista de verificação para avaliação: perguntas a serem feitas antes de conectar o Rails a um fluxo de trabalho de tradução.
Seu aplicativo utiliza o backend Simple padrão do Rails ou um backend Chain/ActiveRecord?
Um backend baseado em banco de dados altera o local onde as strings de origem realmente residem, o que muda o que um conector de tradução precisa ler.
Você precisa de regras de pluralização além da divisão "um/outro" do inglês?
Nesse caso, adicione primeiro a gem rails-i18n — uma plataforma de tradução só pode aplicar regras de pluralização CLDR a um formato Hash que o Rails já sabe ler.
A chave raiz de cada arquivo de localização é, na verdade, um código de idioma?
O formato YAML do Rails aninha strings sob esse nó raiz, e um analisador que não leve isso em consideração pode interpretar incorretamente a estrutura do arquivo.
Como o YAML traduzido será transferido entre seu repositório e seus tradutores?
Antes que os arquivos de localização se acumulem sem um fluxo de trabalho subjacente, decida entre um fluxo de pull request com conector do GitHub e uma chamada direta à API de Arquivos.
Como a Smartling oferece suporte à localização em Ruby on Rails?
O analisador YAML do Smartling lê o formato de arquivo de localização do Rails nativamente, incluindo a diretiva yaml_locale_detection , que corrige as chaves de origem quando o nó raiz de um arquivo é um código de idioma, e a diretiva yaml_strict_plurals_detection , que valida as formas plurais de acordo com a estrutura Hash esperada pelo Rails (Central de Ajuda do Smartling, "Localização do Ruby on Rails"). A ferramenta CAT do Smartling aplica as regras de pluralização CLDR a esses arquivos YAML, abrangendo as categorias de plural que o Rails não inclui por padrão (Central de Ajuda do Smartling, "Plurais"). A movimentação de arquivos de localização de um repositório Rails para outro é feita por meio do Conector GitHub do Smartling, nos modos Pull Request, Single Branch ou On-Demand, ou por meio da API Files para equipes que não utilizam o GitHub (Central de Ajuda do Smartling, "Visão Geral do Conector GitHub"). Para equipes que programam diretamente na API, os SDKs da Smartling, que recebem manutenção ativa, são em Node.js. Python e Java; seu SDK para Ruby está listado entre os SDKs legados, que não recebem mais atualizações ativas, juntamente com .NET, PHP e Go, portanto, a CLI ou uma chamada REST direta é o caminho mais bem suportado para uma equipe Rails que automatiza uploads e downloads (Central de Ajuda da Smartling, "Visão geral dos SDKs da Smartling").
Pronto para ver o Smartling em ação?
Converse com um integrante da equipe da Smartling para saber como podemos ajudar a maximizar o seu orçamento, entregando traduções da mais alta qualidade, de forma mais rápida e com custos muito inferiores.