¿Cómo se estructuran los archivos i18n yaml en Rails?

Sé que ya se ha aceptado una respuesta, pero esta pregunta me proporcionó algo de alimento para la reflexión y pensé que compartiría otra estructura para los archivos yml de Rails i18n para su consideración/crítica.

Dado que me gustaría

1. mantenga la estructura predeterminada de la aplicación para que pueda usar búsquedas abreviadas "perezosas" como t('.some_translation') en mis vistas,
2. evite tantas repeticiones de cadena como sea posible, en particular con palabras que no son solo las mismas, sino que también tienen idénticas contextos/significados,
3. solo tiene que cambiar una clave una vez para que se refleje en todas partes donde se hace referencia,

Para un config/locales/es.yml archivo que se ve algo como esto:

activerecord:
  attributes:
    user:
      email: Email
      name: Name
      password: Password
      password_confirmation: Confirmation
  models:
    user: User
users:
  fields:
    email: Email
    name: Name
    password: Password
    confirmation: Confirmation
sessions:
  new:
    email: Email
    password: Password

Puedo ver que hay una repetición significativa, y que el contexto de palabras como "Correo electrónico" y "Contraseña" son inequívocos y tienen el mismo significado en sus respectivos puntos de vista. Sería un poco molesto tener que ir y cambiarlos todos si decido cambiar "Correo electrónico" a "e-mail", así que me gustaría refactorizar las cadenas para hacer referencia a un diccionario de algún tipo. Entonces, ¿qué tal agregar un hash de diccionario a la parte superior del archivo con algunos & anclajes como este:

dictionary:
  email: &email Email
  name: &name Name
  password: &password Password
  confirmation: &confirmation Confirmation

activerecord:
  attributes:
    user:
      email: *email
      name: *name
      password: *password
      password_confirmation: *confirmation
  models:
    user: User
users:
  fields:  
    email: *email
    name: *name
    password: *password
    confirmation: *confirmation
sessions:
  new:
    email: *email
    password: *password

Cuando tienes más de una instancia de exactamente la misma palabra/frase en su opinión, podría refactorizar para el diccionario. Si la traducción del diccionario de una clave en el idioma base no tiene sentido para un idioma de destino, simplemente cambie el valor referenciado en el destino idioma a una cadena estática o añadirlo como una entrada adicional al diccionario del idioma de destino. Estoy seguro de que el diccionario de cada idioma podría ser refactorizado en otro archivo si se vuelven demasiado grandes y difíciles de manejar.

Esta forma de estructurar los archivos i18n yaml parecía funcionar bien con algunas aplicaciones de prueba locales que probé. Espero que la maravillosa Localeapp proporcione soporte para este tipo de anclaje/referencia en el futuro. Pero de todos modos, toda esta charla diccionario no puede ser una idea original, así que hay otros problemas con la referencia de anclaje en YAML, o tal vez solo con todo el concepto de "diccionario" en general? ¿O es mejor simplemente arrancar el backend predeterminado por completo y reemplazarlo con Redis o algo así?

Su pregunta no es fácil de responder, y no hay mucho material disponible sobre ese tema. He encontrado los mejores recursos son:

• Guía de estilos de Rails , sección Internacionalización
• Hay muchos recursos en el wiki de I18n, pero no he encontrado algunos que respondan a sus preguntas.

Así que voy a darle una oportunidad directamente aquí:

• Navegación

  Creo que te refieres aquí a los elementos de navegación como migas de pan, pestañas,... Tiene que definir vistas para ellos, y luego pegarse a la regla para mover todos los elementos de la vista en archivos separados en el directorio views (consulte la guía de estilos para la regla).

• Texto del botón (guardar cambios, crear cuenta, etc.)

  Ver elementos, entrar en los mismos archivos también. Si utiliza los mismos botones en diferentes vistas, defina un archivo común y utilícelo.

• Mensajes de error de controller flash

  Usaría lo mismo regla en cuanto a las opiniones. Defina un directorio separado, incluya allí los archivos para los controladores.

• Cómo agregar claves de varias palabras. ¿Uso un espacio o un subrayado? For exmaple, t(".botón de actualización")) o t(".update_button")

  Personalmente preferiría usar .update_button, no .update button, porque hace más explícito que esta es una clave.

Han pasado casi dos años desde que hice esta pregunta, y quiero compartir algunas ideas. Creo que la estructura óptima es para las traducciones de espacio de nombres de acuerdo a su rol MVC (modelos, vistas, controladores). Esto mantiene ordenado el archivo de configuración regional y evita colisiones de espacios de nombres (por ejemplo, el ámbito en.users puede representar una vista o un controlador).

en:
  controllers:
    users:
      show:
        welcome_flash: "Welcome back!"
  mailers:
    users_mailer:
      welcome_email:
        subject: "Good of you to join us"
  views:
    users:
      show:
        notice: "Oh no!

Pero usar espacios de nombres ordenados como ese rompe la función de búsqueda perezosa en Rails. Si utiliza lazy lookup, Rails insertará el espacio de nombres automáticamente para usted, y no incluirá los espacios de nombres de nivel superior que creó (views, controllers, etc...).

Por ejemplo, el ámbito de t('.welcome_flash') se resuelve en en.users.show. Lo cual apesta porque los usuarios no están claramente definidos. ¿Qué es eso? Un controlador? ¿Una vista? Algo más?

Para resolver este problema he creado la gema I18nLazyLookup. Le permite usar lazy lookup con sus propios espacios de nombres personalizados.

En lugar de usar t, puede usar t_scoped('welcome_flash'), y eso sería resolver automáticamente el ámbito a en.controllers.users.show. También funciona para vistas y correos, y puede personalizar el espacio de nombres de la manera que desee.

Editar directamente los archivos yaml conduce a archivos desordenados e ilegibles.
Además, será difícil para usted proporcionar acceso a traductores si, algún día, desea que un no desarrollador agregue un nuevo idioma.

Recomendaría usar localeapp, que genera un solo archivo yaml.
Pero le permite ver y administrar fácilmente sus traducciones en una interfaz web.
Y para crear acceso adicional a los traductores.

Viene varios años después de la batalla, pero aquí hay una respuesta (algo totalmente) diferente.

Para empezar, no me gusta el estilo estándar t('.xxx') con el espacio de nombres predeterminado basado en la estructura del archivo. Tampoco me gusta mucho la categorización de las traducciones dependiendo de la estructura DOM. Si bien este es un buen enfoque para traducciones muy estructuradas, a menudo es repetitivo y no muy intuitivo.

Prefiero reagrupar mis traducciones en categorías más útiles, para que sea más fácil para mis traductores, porque pueden trabajar en temas concretos, en lugar de algunos estilos extraños (algunos traductores ni siquiera saben lo que significa MVC)

Así que mi archivo de traducción está estructurado de esta manera

fr:
  theme1:
    theme11:
      translationxxx: blabla
  theme2:
    translationyyy: blabla

Dependiendo de las necesidades, los "temas" pueden ser un modelo, un contexto más abstracto, etc. eso es lo más intuitivo para los traductores.

Debido a que esto sería una molestia para escribir cada vez que el alcance en mis vistas, he añadido algunos métodos de conveniencia en mis ayudantes para tener un contexto de traducción basado en pila.

• Presiono / pop ámbitos de traducción en una pila en mis vistas llamando a t_scope([new_scope] y pop_t
• Sobrescribo el helper t para usar el último ámbito de la pila

El código para los métodos de alcance de la traducción está disponible en que responden