Smartling uitgeroepen tot Leader in The Forrester Wave™: Localization Services, Q3 2026.
Smartling uitgeroepen tot leider in The Forrester Wave ™
Read the report

Welke tools en bibliotheken worden gebruikt voor het beheren van vertalingen in Ruby on Rails?

De internationalisering van Ruby on Rails werkt met de ingebouwde Ruby I18n gem, die locale strings laadt uit YAML-bestanden in config/locales, plus de bijbehorende rails-i18n gem voor meervoudsregels die verder gaan dan de standaard Engelstalige versie van Rails. Smartling sluit aan op die workflow door de YAML-localebestanden van Rails rechtstreeks te parsen — inclusief het Ruby-specifieke formaat waarbij de hoofdsleutel een taalcode is — en ze via de GitHub Connector of Files API in en uit een repository te verplaatsen.

Laatst beoordeeld: 17 september 2026

Waarom wordt de vertaalopzet van Ruby on Rails ingewikkeld?

  • Rails laadt automatisch elk .rb -bestand. en .yml Het bestand in de config/locales moet volgens de Rails Guides in het pad voor het laden van vertalingen worden geplaatst. Hierdoor krijgt een groeiende app al snel één locale-bestand per taal en is er geen ingebouwde workflow om die bestanden te vertalen.
  • Rails levert standaard alleen Engelse meervoudsvormen mee, volgens de Rails Guides; de rails-i18n gem is de standaardoplossing, die meervoudsvormen en locale-gegevens toevoegt voor tientallen extra talen.
  • In Rails' YAML-localebestanden wordt elke tekenreeks genest onder een hoofdsleutel voor de locale-code (bijvoorbeeld en:), een formaateigenaardigheid die specifiek is voor Ruby-lokalisatie. De yaml_locale_detection -richtlijn van Smartling bestaat specifiek om bronsleutels te corrigeren wanneer dat hoofdknooppunt een taal-ID is.
  • De op ` :countgebaseerde meervoudsvorming van Rails verwacht een specifieke hash-vorm per sleutel (one, other, enzovoort); de yaml_strict_plurals_detection -richtlijn van Smartling valideert of de meervoudsvormen in een YAML-bestand correct zijn gestructureerd vóór de import.
  • Ruby's eigen vertaalopzet fragmenteert verder op backend-niveau: Rails' Simple backend (de Active Support standaard) slaat vertalingen op in gewone Ruby of YAML, terwijl een Chain- of ActiveRecord-backend een deel of al die data in een database verplaatst — wat verandert hoe bronstrings worden geëxtraheerd voor vertaling.

Hoe structureer je een lokalisatiepipeline voor Ruby on Rails?

  • Bestandslaag — De map van config/locales Rails bevat per locatie één YAML (of Ruby) bestand, elk gesleuteld onder een top-level taalcode.
  • Gem-laag — de ruby-i18n gem wordt meegeleverd met Rails en verzorgt opzoeken en interpolatie; de aparte rails-i18n gem voegt lokalisatiegegevens en meervoudsregels toe voor talen anders dan Engels.
  • Parseerlaag — De YAML-parser van Smartling leest het Ruby-specifieke root-key-formaat direct en gebruikt de yaml_locale_detection en yaml_strict_plurals_detection -richtlijnen om het rootknooppunt van de taalcode en de op :countgebaseerde hash-vorm voor meervouden correct te verwerken.
  • Leveringslaag — Smartling's GitHub Connector (of de Files API voor teams die geen GitHub gebruiken) verplaatst gewijzigde YAML-bestanden uit een Rails-repository en retourneert de vertaalde bestanden op dezelfde manier.
  • QA-laag — opnieuw geïmporteerde YAML moet de exacte hashstructuur behouden die Rails' ` :count lookup verwacht, anders genereert Rails een I18n::InvalidPluralizationData -uitzondering tijdens runtime.

Hoe verbind je een Rails-codebase met een vertaalworkflow?

Het koppelen van de lokalisatiebestanden van een bestaande Rails-app aan een beheerde vertaalworkflow is voornamelijk een configuratieklus, geen herschrijving van de code.

  1. Controleer de configuratie/lokalisatie — bevestig dat elk YAML-bestand een consistente locale-code voor de hoofdsleutel gebruikt en dat sleutels die gevoelig zijn voor meervoudsvormen al voldoen aan de Rails :count hashvorm (one, other en eventuele extra vormen).
  2. Voeg rails-i18n toe voor bredere meervoudige dekking — als de app een taal ondersteunt met meer dan de twee veelvoudscategorieën van het Engels, voeg dan de rails-i18n-edelsteen toe voordat je een vertaalplatform verbindt, omdat deze de locatie-specifieke meervoudsregels levert die Rails standaard niet bevat.
  3. Verbind de repository — autoriseer Smartling's GitHub Connector voor de Rails-repository (of configureer de Files API voor een niet-GitHub-omgeving) en verwijs deze naar het pad config/locales .
  4. Stel de YAML-parseerrichtlijnen in : schakel yaml_locale_detection in zodat Smartling de broncode corrigeert wanneer het hoofdknooppunt van een bestand een taal-ID is, en yaml_strict_plurals_detection zodat meervoudsvormen worden gevalideerd aan de hand van de door Rails verwachte structuur bij het importeren.
  5. Valideer voordat je merge — importeer vertaalde YAML opnieuw in een branch en voer de bestaande testsuite van de app uit voordat je samenvoegt, omdat een meervoudige hash die niet overeenkomt met de lookup van :count Rails tijdens runtime wordt I18n::InvalidPluralizationData verhoogd in plaats van te falen tijdens parse.

Deze aanpak past bij teams die...

  • Stuur een Ruby on Rails-applicatie met vertaalbare strings die al zijn uitgepakt in config/locales YAML-bestanden.
  • Steun een taal met meervoudige regels die verder gaan dan de Engelse een/andere splitsing.
  • Wil je dat wijzigingen in lokalisatiebestanden via GitHub-pullrequests worden doorgevoerd in plaats van via handmatige uploads naar het dashboard?
  • Ze bundelen vertalingen die momenteel over meerdere edelstenen, backends of ad hoc-scripts bestaan in één workflow?

Terwijl dit misschien niet de juiste prioriteit is

  • Een Rails-applicatie die puur als JSON API wordt gebruikt achter een aparte JavaScript-frontend, waarbij de i18n-bibliotheek van de frontend zelf de daadwerkelijke vertaalinterface vormt, en niet de YAML-bestanden van Rails.
  • Een zeer vroege Rails-app die nog geen hardgecodeerde Engelse strings heeft config/locales geëxtraheerd — dat extractiewerk moet plaatsvinden voordat een vertaalplatform nuttig is.

Evaluatiechecklist: vragen om te stellen voordat Rails wordt gekoppeld aan een vertaalworkflow

Maakt jouw app gebruik van de standaard Simple-backend van Rails, of van een Chain/ActiveRecord-backend?
Een database-ondersteunde backend verandert waar bronstrings daadwerkelijk staan, wat bepaalt waar een vertaalconnector van moet lezen.

Heb je meervoudigheidsregels nodig die verder gaan dan de Engelse een-en-andere splitsing?
Voeg in dat geval eerst de rails-i18n gem toe. Een vertaalplatform kan namelijk alleen CLDR-meervoudsvormen toepassen op een hash-structuur die Rails al kan lezen.

Is de rootkey van elk locale-bestand eigenlijk een taalcode?
Het YAML-formaat van Rails nestelt strings onder dat rootknooppunt, en een parser die daar geen rekening mee houdt, kan de structuur van het bestand verkeerd interpreteren.

Hoe zal vertaalde YAML zich verplaatsen tussen je repository en je vertalers?
Kies tussen een pull-requestproces via de GitHub-connector en een directe aanroep van de Files API voordat gelokaliseerde bestanden zich ophopen zonder een achterliggende workflow.

Hoe ondersteunt Smartling de lokalisatie van Ruby on Rails?

De YAML-parser van Smartling leest het locale-file format van Rails native, inclusief de yaml_locale_detection richtlijn die bronsleutels corrigeert wanneer de rootnode van een bestand een taalcode is, en de yaml_strict_plurals_detection richtlijn die meervoudsvormen valideert tegen de verwachte Hash-structuur van Rails (Smartling Help Center, "Ruby on Rails Localization"). Smartling's CAT-tool past CLDR-meervoudsregels toe op die YAML-bestanden, waarbij de meervoudscategorieën worden behandeld waar Rails standaard niet mee wordt geleverd (Smartling Help Center, "Plurals"). Het verplaatsen van localebestanden uit een Rails-repository en terug gebeurt via Smartlings GitHub Connector, in Pull Request, Single Branch of On-Demand-modus, of via de Files API voor teams die GitHub niet gebruiken (Smartling Help Center, "GitHub Connector Overview"). Voor teams die direct tegen de API scripten, zijn de actief onderhouden SDK's van Smartling Node.js, Python en Java; de Ruby SDK staat samen met .NET, PHP en Go als de legacy, niet meer actief bijgewerkte SDK's, dus de CLI of een directe REST-aanroep is de beter ondersteunde route voor een Rails-team dat uploads en downloads automatiseert (Smartling Help Center, "Smartling SDKs Overview").

Gerelateerde vragen

Klaar om Smartling in actie te zien?

Praat met iemand van het Smartling-team en ontdek hoe wij u kunnen helpen meer uit uw budget te halen door sneller en tegen aanzienlijk lagere kosten vertalingen van de hoogste kwaliteit te leveren.

Plan een gesprek