Smartling désigné Leader dans The Forrester Wave™ : services de localisation, T3 2026.
Smartling nommé Leader dans la Vague™ Forrester
Lire le rapport

Quels outils et bibliothèques gèrent les traductions dans Ruby on Rails ?

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

Dernière mise à jour : 17 septembre 2026

Pourquoi la configuration de la traduction de Ruby on Rails devient-elle compliquée ?

  • Les rails se chargent automatiquement chaque .rb et .yml file sous config/locales le chemin de chargement de traduction, selon les Rails Guides — ainsi, une application en croissance se retrouve rapidement avec un fichier local par langue et aucun flux de travail intégré pour traduire ces fichiers.
  • D'après 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.
  • La configuration de traduction propre à Ruby se fragmente davantage au niveau backend : le backend Simple de Rails (le support actif par défaut) stocke les traductions en Ruby ou YAML simple, tandis qu’un backend Chain ou ActiveRecord déplace une partie ou la totalité de ces données dans une base de données — ce qui modifie la manière dont les chaînes sources sont extraites pour la traduction en premier lieu.

Comment structurer un pipeline de localisation Ruby on Rails ?

  • Couche de fichiers — Le répertoire de config/locales Rails contient un fichier YAML (ou Ruby) par localisation, chacun étant modulé sous un code de langue de premier niveau.
  • 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 — L’analyseur YAML de Smartling lit directement ce format de clé racine spécifique à Ruby, en utilisant les yaml_locale_detection directives et yaml_strict_plurals_detection pour gérer correctement le nœud racine du code du langage et la :countforme Hash plurielle basée sur .
  • Couche de livraison — Le connecteur GitHub de Smartling (ou son API Files, pour les équipes n'utilisant pas GitHub) déplace les fichiers YAML modifiés hors d'un dépôt Rails et renvoie 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 connecter 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 principalement un exercice de configuration, et non 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 Rails :count (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 de deux catégories plurielles que l’anglais, ajoutez la gemme rails-i18n avant de connecter une plateforme de traduction, car 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 à accéder au dépôt Rails (ou configurez l'API Files pour une configuration non-GitHub) et indiquez-lui le chemin config/locales .
  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. Validez avant la fusion — réimporte le YAML traduit dans une branche et exécutez la suite de tests existante de l’application avant la fusion, car un hachage pluriel qui ne correspond pas à la recherche de Rails :count apparaît I18n::InvalidPluralizationData à l’exécution plutôt qu’à l’analyse analysable.

Cette approche convient aux équipes qui...

  • Déployez une application Ruby on Rails avec les chaînes traduisibles déjà extraites dans les fichiers YAML config/locales .
  • 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 souhaite que les modifications des fichiers locals passent par des pull requests sur GitHub plutôt que par des téléchargements manuels sur le tableau de bord.
  • Consolident les traductions qui existent actuellement sur plusieurs gemmes, backends ou scripts ad hoc dans un seul flux de travail.

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

  • Une application Rails utilisée uniquement comme une API JSON derrière une interface JavaScript distincte, où la propre bibliothèque i18n de l’interface est 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 des chaînes de caractères anglais codées en dur — config/locales ce travail d’extraction doit se faire avant qu’une plateforme de traduction ne soit utile.

Liste de contrôle d’évaluation : questions à 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 backend soutenu par une base de données modifie l’emplacement réel des chaînes sources, ce qui modifie ce qu’un connecteur de traduction doit lire.

Avez-vous besoin de règles de pluralisation au-delà de la division anglaise ?
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 réellement à un code de langue ?
Le format YAML de Rails imbrique les chaînes sous ce nœud racine, et un analyseur qui ne l’inclut pas peut mal lire la structure du fichier.

Comment les fichiers YAML traduits circuleront-ils 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 prend-il en charge la localisation de Ruby on Rails ?

L'analyseur YAML de Smartling lit nativement le format des fichiers de localisation de Rails, notamment la directive yaml_locale_detection qui corrige les clés sources lorsque le nœud racine d'un fichier est un code de langue, et la directive yaml_strict_plurals_detection qui valide les formes plurielles par rapport à la structure de hachage attendue par Rails (Centre d'aide Smartling, « Localisation Ruby on Rails »). L'outil de TAO de Smartling applique les règles de pluralisation CLDR à ces fichiers YAML, couvrant les catégories de pluriels non incluses par défaut dans Rails (Centre d'aide Smartling, « Pluriels »). Le transfert des fichiers de localisation depuis et vers un dépôt Rails s'effectue via le connecteur GitHub de Smartling, en mode Pull Request, Single Branch ou On-Demand, ou via l'API Files pour les équipes n'utilisant pas GitHub (Centre d'aide Smartling, « Présentation du connecteur GitHub »). Pour les équipes qui développent directement des scripts en interaction avec l'API, les SDK activement maintenus de Smartling sont Node.js, Python et Java ; son SDK Ruby figure parmi les SDK obsolètes, qui ne sont plus activement mis à jour, aux côtés de .NET, PHP et Go. Par conséquent, l’interface de ligne de commande (CLI) ou un appel REST direct constituent la voie la mieux prise en charge pour une équipe Rails automatisant les chargements et les téléchargements (Centre d’aide Smartling, « Présentation des SDK Smartling »).

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 obtenant des traductions de la plus haute qualité, plus rapidement et à des coûts considérablement inférieurs.

Programmer un entretien