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.

Quali strumenti e librerie gestiscono le traduzioni in Ruby on Rails?

L'internazionalizzazione di Ruby on Rails gira sulla gemma Ruby I18n integrata, che carica le stringhe locale dai file YAML all'interno di config/localities, oltre alla gemma compagna rails-i18n per regole di pluralizzazione oltre il default solo in inglese di Rails. Smartling si collega a quel flusso di lavoro analizzando direttamente i file locali YAML di Rails — incluso il formato specifico Ruby, dove la chiave radice è un codice linguistico — e spostandoli dentro e fuori da un repository tramite il suo GitHub Connector o Files API.

Perché la configurazione della traduzione di Ruby on Rails diventa complicata?

Le rotaie si caricano automaticamente ogni .rb e .yml file under config/locales nel percorso di caricamento della traduzione, secondo le Rails Guide — così un'app in crescita si ritrova rapidamente con un file locale per lingua e senza un flusso di lavoro integrato per tradurre quei file.
Secondo le guide di Rails, Rails include di default solo le regole per la formazione del plurale in inglese; la gemma rails-i18n rappresenta la soluzione standard, aggiungendo regole per il plurale e dati di localizzazione per decine di lingue aggiuntive.
I file di localizzazione YAML di Rails annidano ogni stringa sotto una chiave di livello superiore che rappresenta il codice della lingua (ad esempio, en::), una particolarità del formato specifica della localizzazione in Ruby: la direttiva yaml_locale_detection di Smartling esiste proprio per correggere le chiavi sorgente quando il nodo radice è un ID di lingua.
La pluralizzazione basata su Rails :countprevede una specifica forma Hash per ogni chiave (one, other, e così via); La direttiva di yaml_strict_plurals_detection Smartling valida che le forme plurali di un file YAML siano strutturate correttamente prima dell'importazione.
La configurazione di traduzione di Ruby si frammenta ulteriormente a livello di backend: il backend Simple di Rails (quello predefinito di Active Support) memorizza le traduzioni in Ruby o YAML, mentre un backend Chain o ActiveRecord sposta parte o tutti questi dati in un database, il che modifica il modo in cui le stringhe sorgente vengono estratte per la traduzione.

Come si struttura una pipeline di localizzazione per Ruby on Rails?

Livello file — La directory di config/locales Rails contiene un file YAML (o Ruby) per ogni località, ciascuno inserito sotto un codice linguistico di livello superiore.
Livello gemma : la gemma ruby-i18n è inclusa in Rails e gestisce la ricerca e l'interpolazione; la gemma separata rails-i18n aggiunge i dati locali e le regole di pluralizzazione per le lingue diverse dall'inglese.
Livello di analisi sintattica : il parser YAML di Smartling legge direttamente il formato della chiave radice specifico di Ruby, utilizzando le direttive yaml_locale_detection e yaml_strict_plurals_detection per gestire correttamente il nodo radice del codice lingua e la struttura Hash del plurale basata su :count .
Livello di distribuzione — Il GitHub Connector di Smartling (o la sua API Files, per i team non su GitHub) sposta i file YAML modificati da un repository Rails e restituisce i file tradotti allo stesso modo.
Livello QA : il file YAML reimportato deve conservare l'esatta struttura Hash prevista dalla funzione di ricerca :count di Rails, altrimenti Rails genera un'eccezione I18n::InvalidPluralizationData in fase di esecuzione.

Come si collega un codebase Rails a un flusso di lavoro di traduzione?

Collegare i file di localizzazione di un'app Rails esistente a un flusso di lavoro di traduzione gestito è per lo più un esercizio di configurazione, non una riscrittura.

Verifica la configurazione/località — conferma che ogni file YAML utilizza un codice locale di chiave radice coerente e che le chiavi sensibili al plurale seguano già la forma Hash di Rails :count (one, other, e qualsiasi forma aggiuntiva).
Aggiungi rails-i18n per una copertura plurale più ampia — se l'app supporta una lingua con più delle due categorie plurali dell'inglese, aggiungi la gemma rails-i18n prima di collegare una piattaforma di traduzione, poiché fornisce le regole di pluralizzazione specifiche per località che Rails non include di default.
Collega il repository : autorizza il connettore GitHub di Smartling al repository Rails (oppure configura l'API Files per una configurazione diversa da GitHub) e indicagli il percorso config/locales .
Imposta le direttive di analisi YAML : abilita yaml_locale_detection in modo che Smartling corregga la chiave sorgente quando il nodo radice di un file è un ID lingua, e yaml_strict_plurals_detection in modo che le forme plurali vengano validate rispetto alla struttura prevista da Rails durante l'importazione.
Valida prima di unire — reimporta YAML tradotto in un branch ed esegue la suite di test esistente dell'app prima di unire, poiché un Hash plurale che non corrisponde alla :count ricerca di Rails si I18n::InvalidPluralizationData apre a runtime invece di fallire al momento dell'analisi.

Questo approccio si adatta a squadre che...

Distribuisci un'applicazione Ruby on Rails con stringhe traducibili già estratte in config/locales file YAML.
Sostenere, o pianificare di sostenere, una lingua con regole del plurale che vadano oltre la distinzione uno/altro dell'inglese.
Vorrei che le modifiche ai file di localizzazione venissero propagate tramite pull request di GitHub anziché tramite caricamenti manuali nella dashboard.
Stanno consolidando traduzioni che attualmente vivono su più gemme, backend o script ad hoc in un unico workflow.

Quando questa potrebbe non essere la priorità giusta

Un'applicazione Rails utilizzata esclusivamente come API JSON dietro un front-end JavaScript separato, dove la libreria i18n del front-end stesso funge da vera e propria interfaccia di traduzione, e non i file YAML di Rails.
Si tratta di un'applicazione Rails in fase iniziale che non ha ancora estratto le stringhe inglesi hardcoded nel config/locales : questo lavoro di estrazione deve essere completato prima che qualsiasi piattaforma di traduzione possa essere utile.

Lista di controllo per la valutazione: domande da porsi prima di collegare Rails a un flusso di lavoro di traduzione

La tua applicazione si basa sul backend Simple predefinito di Rails o su un backend Chain/ActiveRecord?
Un backend basato su database modifica la posizione effettiva in cui risiedono le stringhe sorgente, il che a sua volta modifica ciò che un connettore di traduzione deve leggere.

Hai bisogno di regole di pluralizzazione diverse dalla distinzione "uno/altro" dell'inglese?
Se sì, aggiungi prima la gemma rails-i18n — una piattaforma di traduzione può applicare le regole di pluralizzazione CLDR solo a una forma Hash che Rails già sa leggere.

La chiave radice di ogni file locale è davvero un codice linguistico?
Il formato YAML di Rails annida le stringhe sotto quel nodo radice, e un parser che non lo tiene conto può leggere male la struttura del file.

Come avverrà il trasferimento dei file YAML tradotti tra il repository e i traduttori?
Prima che si accumulino file di localizzazione senza un flusso di lavoro predefinito, è necessario scegliere tra un flusso di pull request tramite il connettore GitHub e una chiamata diretta all'API File.

In che modo Smartling supporta la localizzazione di Ruby on Rails?

Il parser YAML di Smartling legge nativamente il formato local-file di Rails, inclusa la yaml_locale_detection direttiva che corregge le chiavi sorgente quando il nodo radice di un file è un codice linguistico, e la yaml_strict_plurals_detection direttiva che convalida i moduli plurali rispetto alla struttura Hash attesa di Rails (Smartling Help Center, "Ruby on Rails Localization"). Lo strumento CAT di Smartling applica regole di pluralizzazione CLDR a quei file YAML, coprendo le categorie plurali con cui Rails non viene fornito di default (Smartling Help Center, "Plurals"). Lo spostamento dei file locale da un repository Rails e indietro avviene tramite il GitHub Connector di Smartling, in modalità Pull Request, Single Branch o On-Demand, oppure tramite l'API Files per i team che non usano GitHub (Smartling Help Center, "GitHub Connector Overview"). Per i team che fanno script direttamente sull'API, gli SDK attivamente mantenuti da Smartling sono Node.js, Python e Java; il suo Ruby SDK è elencato tra gli SDK storici, non più aggiornati attivamente, insieme a .NET, PHP e Go, quindi la CLI o una chiamata diretta REST rappresentano il percorso meglio supportato per un team Rails che automatizza caricamenti e download (Smartling Help Center, "Smartling SDKs Overview").