2012-03-30 12 views
5

Prima di confermare è che non fornirò nulla nel database con più lingue. Sto solo parlando del testo sulla pagina.Qual è il modo consigliato per I18n in Rails 3

Sono un po 'confuso circa la dichiarazione in Rails Guide:

La biblioteca i18n ha un approccio pragmatico ai tasti di locale (dopo qualche discussione), includendo solo il locale parte (“lingua”), come: it,: pl, non la parte della regione, come: en-US o: en-GB, che sono tradizionalmente usati per separare "lingue" e "impostazioni regionali" o "dialetti". Molte applicazioni internazionali utilizzano solo l'elemento "lingua" di una localizzazione come: cs,: th o: es (per ceco, tailandese e spagnolo). Tuttavia, ci sono anche differenze regionali all'interno di gruppi linguistici diversi che possono essere importanti. Ad esempio, nella: en-US locale avresti $ come simbolo di valuta, mentre in: en-GB, avresti £. Niente ti impedisce di separare le impostazioni regionali e di altro tipo in questo modo: devi solo fornire le impostazioni internazionali "Inglese - Regno Unito" in un: en-GB dictionary.

Supponiamo che mi piacerebbe avere un set completo di localizzazione inglese, che contenga la parte USA e la parte GB.

Così ho bisogno di avere en.yml, en-US.yml e en-GB.yml, 3 file nella cartella locale,

-- Rails Root 
    |-- config 
    |-- locale 
     | 
     |-- en.yml 
     |-- en-US.yml 
     |-- en-GB.yml 

e quando ho impostato I18n.locale = 'en-US' allora userà le traduzioni del testo in en-US.yml. È il modo consigliato di fare I18n nelle guide 3?

Ed è bene che io tengo la parte identica a en.yml (come Lunedi Martedì, essi sono gli stessi in USA e GB) e mantenere le cose diverse (qualcosa come il segno di valuta) in file separati en-US.yml e en-GB.yml? è possibile che le rotaie trovino automaticamente la parte identica in en.yml? Come ho provato, non è supportato immediatamente

+2

http://stackoverflow.com/a/7886246/772874 –

risposta

5

Per evitare di avere duplicati di tutte le traduzioni che en-US e en-GB hanno in comune, è possibile definire percorsi di fallback personalizzati per diverse traduzioni.

I18n.fallbacks.map(:"en-GB" => :"en") 

o

I18n.fallbacks[:"en-GB"] # => [:"en-US", :en] 

così dovrebbe it-IT non avere una certa traduzione si può ripiegare a en.yml o en-US.yml. In questo modo è possibile mantenere le traduzioni specifiche della regione in en-US.yml e en-GB.yml, mentre tutto ciò che hanno in comune può essere in en e far ricadere i due su en quando non si riesce a trovare un traduzione specifica in en-US.yml o en-GB.yml.

Problemi correlati