Smartling nommé chef de file dans The Forrester Wave™ : services de localisation, 3e trimestre 2026.
Smartling nommé Leader dans The Forrester Wave™
Lire le rapport

Quels outils et bibliothèques permettent de gérer les traductions dans Ruby on Rails ?

L’internationalisation de Ruby on Rails fonctionne sur la gemme Ruby I18n intégrée, qui charge des chaînes de localisation à partir de fichiers YAML dans config/locales, ainsi que la gemme compagnonne rails-i18n pour des règles de pluralisation au-delà de Rails, qui est par défaut uniquement en anglais. Smartling se connecte à ce flux de travail en analysant directement les fichiers locaux YAML de Rails — y compris le format spécifique à Ruby où la clé racine est un code de langage — et en les déplaçant dans et hors d’un dépôt via son GitHub Connector ou son API Files.

Dernière révision : 17 septembre 2026

Pourquoi la configuration de la traduction dans Ruby on Rails est-elle si compliquée ?

  • Les rails se chargent automatiquement chaque .rb et .yml file under config/locales dans le chemin de chargement de traduction, selon les Rails Guides — donc une application en croissance se retrouve rapidement avec un fichier local par langue et aucun flux de travail intégré pour traduire ces fichiers.
  • Selon les guides Rails, Rails ne fournit par défaut que les règles de pluralisation anglaises ; la gem rails-i18n est la solution standard, ajoutant les règles de pluralisation et les données de localisation pour des dizaines de langues supplémentaires.
  • Les fichiers de localisation YAML de Rails imbriquent chaque chaîne sous une clé de code de localisation de niveau supérieur (par exemple, en:), une particularité de format spécifique à la localisation Ruby — la directive yaml_locale_detection de Smartling existe spécifiquement pour corriger les clés sources lorsque ce nœud racine est un identifiant de langue.
  • La pluralisation basée sur :countde Rails attend une forme de hachage spécifique par clé (one, other, etc.) ; la directive yaml_strict_plurals_detection de Smartling vérifie que les formes plurielles d'un fichier YAML sont correctement structurées avant l'importation.
  • Le système de traduction de Ruby se fragmente davantage au niveau du backend : le backend Simple de Rails (la valeur par défaut d’Active Support) stocke les traductions en Ruby ou YAML pur, tandis qu’un backend Chain ou ActiveRecord déplace tout ou partie de ces données dans une base de données, ce qui modifie la façon dont les chaînes sources sont extraites pour la traduction.

Comment structurer un pipeline de localisation Ruby on Rails ?

  • Couche de fichiers — Le répertoire config/locales de Rails contient un fichier YAML (ou Ruby) par locale, chacun étant indexé sous un code de langue de niveau supérieur.
  • Couche Gem — la gem ruby-i18n est fournie avec Rails et gère la recherche et l'interpolation ; la gem rails-i18n séparée ajoute des données de localisation et des règles de pluralisation pour les langues autres que l'anglais.
  • Couche d'analyse syntaxique — L'analyseur YAML de Smartling lit directement le format de clé racine spécifique à Ruby, en utilisant les directives yaml_locale_detection et yaml_strict_plurals_detection pour gérer correctement le nœud racine du code de langue et la forme de hachage plurielle basée sur :count .
  • Couche de livraison — Le connecteur GitHub de Smartling (ou son API de fichiers, pour les équipes qui ne sont pas sur GitHub) déplace les fichiers YAML modifiés hors d’un dépôt Rails et retourne les fichiers traduits de la même manière.
  • Couche QA — le YAML réimporté doit préserver la structure de hachage exacte attendue par la recherche :count de Rails, sinon Rails lève une exception I18n::InvalidPluralizationData lors de l'exécution.

Comment relier une base de code Rails à un flux de travail de traduction?

Connecter les fichiers de localisation d’une application Rails existante à un flux de travail de traduction géré est surtout un exercice de configuration, pas une réécriture.

  1. Auditez la configuration/localisations — confirmez que chaque fichier YAML utilise un code local de clé racine cohérent et que les clés sensibles au pluriel suivent déjà la forme de hachage de :count Rails (one, other, et toute forme supplémentaire).
  2. Ajoutez rails-i18n pour une couverture plurielle plus large — si l’application prend en charge une langue avec plus que les deux catégories plurielles de l’anglais, ajoutez la gemme rails-i18n avant de connecter une plateforme de traduction, puisqu’elle fournit les règles de pluriel spécifiques à la localité que Rails n’inclut pas par défaut.
  3. Connectez le dépôt — autorisez le connecteur GitHub de Smartling au dépôt Rails (ou configurez l’API Fichiers pour une configuration hors GitHub) et pointez-le vers le config/locales chemin.
  4. Définissez les directives d'analyse YAML : activez yaml_locale_detection pour que Smartling corrige la clé source lorsque le nœud racine d'un fichier est un identifiant de langue, et yaml_strict_plurals_detection pour que les formes plurielles soient validées par rapport à la structure attendue de Rails lors de l'importation.
  5. Valider avant la fusion — réimporte le YAML traduit dans une branche et exécuter la suite de tests existante de l’application avant la fusion, puisque un hachage pluriel qui ne correspond pas à la recherche de Rails :count apparaît I18n::InvalidPluralizationData à l’exécution plutôt qu’à l’analyse analytique.

Cette approche convient aux équipes qui...

  • Livrez une application Ruby on Rails avec des chaînes traduisibles déjà extraites en config/locales fichiers YAML.
  • Soutenir, ou prévoir de soutenir, une langue dotée de règles de pluriel autres que la distinction « one/other » de l'anglais.
  • Je veux que les changements dans les fichiers de localisation soient traités par des demandes d'extraction GitHub plutôt que par des téléchargements manuels du tableau de bord.
  • Nous consolidons les traductions actuellement réparties sur plusieurs gemmes, backends ou scripts ad hoc en un seul flux de travail.

Quand ce n’est peut-être pas la bonne priorité

  • Une application Rails utilisée uniquement comme API JSON derrière une interface JavaScript distincte, où la bibliothèque i18n propre à l'interface constitue la surface de traduction réelle, et non les fichiers YAML de Rails.
  • Une toute première application Rails qui n’a pas encore extrait les chaînes de caractères config/locales en anglais codées en dur — ce travail d’extraction doit se faire avant qu’une plateforme de traduction soit utile.

Liste de contrôle d'évaluation : questions à se poser avant de connecter Rails à un flux de travail de traduction

Votre application utilise-t-elle le backend Simple par défaut de Rails, ou un backend Chain/ActiveRecord ?
Un système dorsal basé sur une base de données modifie l'emplacement réel des chaînes de caractères sources, ce qui change ce qu'un connecteur de traduction doit lire.

Avez-vous besoin de règles de pluralisation autres que la distinction anglaise « one/other » ?
Si oui, ajoutez d’abord la gemme rails-i18n — une plateforme de traduction ne peut appliquer que les règles de pluriel CLDR à une forme de hachage que Rails sait déjà lire.

La clé racine de chaque fichier de localisation correspond-elle vraiment à un code de langue ?
Le format YAML de Rails imbrique des chaînes sous ce nœud racine, et un analyseur qui ne le prend pas en compte peut mal lire la structure du fichier.

Comment le YAML traduit passera-t-il entre votre dépôt et vos traducteurs?
Choisissez entre un flux de requêtes d'extraction via un connecteur GitHub et un appel direct à l'API Files avant que les fichiers de localisation ne s'accumulent sans flux de travail sous-jacent.

Comment Smartling supporte-t-il la localisation de Ruby on Rails ?

L’analyseur YAML de Smartling lit nativement le format de fichiers localisation de Rails, incluant la yaml_locale_detection directive qui corrige les clés source lorsque le nœud racine d’un fichier est un code de langue, et la yaml_strict_plurals_detection directive qui valide les formes plurielles selon la structure de hachage attendue de Rails (Centre d’aide Smartling, « Ruby on Rails Localization »). L’outil CAT de Smartling applique les règles de pluriel CLDR à ces fichiers YAML, couvrant les catégories plurielles avec lesquelles Rails n’est pas livré par défaut (Centre d’aide Smartling, « Pluriels »). Le transfert des fichiers de localisation hors d’un dépôt Rails se fait via le connecteur GitHub de Smartling, en mode Pull Request, Single Branch, ou On-Demand, ou via l’API Fichiers pour les équipes n’utilisant pas GitHub (Centre d’aide Smartling, « GitHub Connector Overview »). Pour les équipes qui scriptent directement sur l’API, les SDK activement maintenus par Smartling sont Node.js, Python et Java; son SDK Ruby est listé parmi les SDK hérités, plus mis à jour activement, aux côtés de .NET, PHP et Go, donc la CLI ou un appel REST direct est la voie la mieux prise en charge pour une équipe Rails automatisant les téléchargements et les téléchargements (Smartling Help Center, « Smartling SDKs Overview »).

Questions connexes

Prêt à voir Smartling en action?

Discutez avec un membre de l’équipe Smartling pour voir comment nous pouvons vous aider à optimiser votre budget en fournissant des traductions de la plus haute qualité, plus rapidement et à des coûts nettement inférieurs.

Prendre un rendez-vous