2012-11-08 14 views
5

Sto creando la mia prima app Rails e avrò supporto per l'internazionalizzazione.In Rails, come organizzare i dati localizzati per gli elementi del modulo diversi dalle etichette?

Ho già letto il i18n guide ed è un'ottima fonte. E 'anche suggests a file organization per i file di localizzazione, che è un ottimo punto di partenza:

|-defaults 
|---es.rb 
|---en.rb 
|-models 
|---book 
|-----es.rb 
|-----en.rb 
|-views 
|---defaults 
|-----es.rb 
|-----en.rb 
|---books 
|-----es.rb 
|-----en.rb 
|---users 
|-----es.rb 
|-----en.rb 
|---navigation 
|-----es.rb 
|-----en.rb 

Tuttavia, io non sono sicuro di quello che è il posto migliore per tenere alcune informazioni aggiuntive (internazionalizzato) di solito si trova in forme, come:

  • segnaposto ingresso
  • testi helper (accanto all'ingresso, con informazioni più dettagliate su di esso)

la cosa è : questa informazione riguarda le visualizzazioni (non i modelli). Ma, è frequentemente descritto in base al modello, per ogni attributo - il che mi rende incline a metterli nei file dei modelli, sotto la proprietà activerecord.

La mia domanda: qual è il posto migliore dove mettere questi dati localizzati? Sia in termini di organizzazione dei file (quale cartella) e in termini di organizzazione all'interno del file.

+0

Quale versione di binari stai usando? La strategia di namespace di i18n è cambiata parecchio nel tempo. – numbers1311407

+0

Sto usando 3.2.8 – fegemo

risposta

4

Non penso che ci sia una risposta "corretta" a questa domanda.

Personalmente tendo ad essere in disaccordo con l'organizzazione suggerita dalla guida. i18n è, per sua natura, interamente nel dominio del livello vista. Lasciare una cartella "viste" è un po 'confuso e probabilmente ha portato più di uno sviluppatore al problema esatto che stai avendo ora.

Suggerirei di buttare via i file views/book e di mantenere tutto ciò che appartiene al modello nello stesso file. Tutte le traduzioni sono per "visualizzazioni" e mantenere tutte le traduzioni relative ai singoli modelli in un unico posto è probabilmente più pulito e meno soggetto a errori.

# locale/models/model.en (or es, etc) 

# all the activerecord translations 
activerecord: 
    models: 
    # ... 
    attributes: 
    # ... 
    errors: 
    # ... 
# then your form translations. 
helpers: 
    label: 
    # Here you might add overrides for activerecord attribute lookups, but 
    # do so with care (see note below). 

    # then below are your custom view fields 
    placeholders: 
    model: 
     attribute: 'translation' 
    details: 
    model: 
     attribute: 'translation' 

Una nota sul helpers.label contro activerecord.attributes:

Rails stesso currently guarda in due posti per le traduzioni delle etichette. Primo:

helpers: 
    label: 
    model: 
     attribute: 'translation' 

tornando al definizioni ActiveRecord:

activerecord: 
    attributes: 
    model: 
     attribute: 'translation' 

Questo è piuttosto di una trappola, in quanto significa etichette di forma e errori ActiveRecord (e altre definizioni) sarà diverso. Questo va bene se, ad esempio, vuoi che l'etichetta del modulo sia più di un prompt (ad esempio "Inserisci il corpo" per l'attributo "corpo"), ma può anche essere una fonte di errori se il tuo helper.label non si riferisce ovviamente a la traduzione di activerecord, es ("Inserisci il messaggio" per l'attributo "corpo"). Quindi scavalcare con cura.

+0

Grande, fantastica discussione. Grazie per aver condiviso la tua esperienza! – fegemo

+0

Per quanto ne so, il tuo collegamento "attualmente" dovrebbe ora indicare [qui] (https://github.com/rails/rails/blob/4-0-stable/actionpack/lib/action_view/helpers/tags/ etichetta.rb # L48) - ma non sono sicuro di come ciò dimostri che ricade nelle traduzioni di activerecord. Ti ricordi come viene seguita quella catena? – Gareth

Problemi correlati