¿Cuál es el camino recomendado de los raíles a I18n en Rails 3

Question

Lo primero que debo confirmar es que no proporcionaré nada en la base de datos con varios idiomas. Solo estoy hablando del texto en la página.

estoy un poco confundido acerca de la declaración en Rails Guide:

La biblioteca i18n adopta un enfoque pragmático a las teclas de configuración regional (después de un rato), incluyendo sólo la configuración regional parte (“lenguaje”), como: en,: pl, no la parte de región, como: en-US o: en-GB, que se utilizan tradicionalmente para separar "idiomas" y "configuración regional" o "dialectos". Muchas aplicaciones internacionales utilizan solo el elemento "idioma" de una configuración regional como: cs,: th o: es (para checo, tailandés y español). Sin embargo, también hay diferencias regionales dentro de diferentes grupos de idiomas que pueden ser importantes. Por ejemplo, en la ubicación: en-US tendría $ como símbolo de moneda, mientras que en: en-GB, tendría £. Nada le impide separar las configuraciones regionales y otras de esta manera: solo tiene que proporcionar la configuración regional completa "inglés - Reino Unido" en un diccionario: en-GB.

Supongamos que me gustaría tener un conjunto completo de localización en inglés, que contiene la parte de EE. UU. Y la parte de GB.

Por lo tanto, necesita tener en.yml, en-US.yml y en-GB.yml, 3 archivos en la carpeta local,

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

y cuando me puse I18n.locale = 'en-US' entonces se utilizarán las traducciones de texto en en-US.yml. ¿Es la forma recomendada de hacer I18n en los rieles 3?

Y es bueno que me quedo con el papel idéntico en.yml (como Lunes Martes, que son los mismos en los Estados Unidos y GB) y mantener las cosas diferentes (algo así como el signo de dinero) en archivos separados en-US.yml y en-GB.yml? ¿Es posible que los rieles encuentren automáticamente la pieza idéntica en en.yml? Como probé, no está admitido de fábrica

Answer 1

Para evitar tener duplicados de todas las traducciones que en-US y en-GB tienen en común, puede definir rutas de repliegue personalizadas para diferentes traducciones.

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

o

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

Así debe en-GB no tener una cierta traducción se puede caer de nuevo a en.yml o en-US.yml. De esta forma, puede mantener las traducciones específicas de la región en en-US.yml y en-GB.yml, mientras que todo lo que tienen en común puede ser in y hacer que las dos vuelvan a activarse en cuando no pueda encontrar un traducción específica en en-US.yml o en-GB.yml.