ruby on rails - with - ¿Cómo se estructuran los archivos i18n yaml en Rails?

rails i18n with parameters

Question

Comencé a poblar un archivo en yaml en Rails y ya puedo decir que se volverá desordenado y fuera de lugar en poco tiempo. ¿Existe una convención para mantener este archivo organizado?

Hasta ahora tengo esta estructura:

language:
  resource:
    pages: # index, show, new, edit
      page html elements: # h1, title
  activerecord:
    attributes:
      model:
        property:

Ahora tengo las siguientes cosas que quiero encajar en esta estructura, pero no estoy seguro de cómo:

1. Navegación
2. Texto del botón (guardar cambios, crear cuenta, etc.)
3. Mensajes de error del flash del controlador
4. Cómo agregar claves de palabras múltiples. ¿Uso un espacio o un guión bajo? Por ejemplo, t(".update button") ) o t(".update_button")

¿Hay una convención para la estructura del archivo local?

Answer 1

Descubrí que la mejor estrategia general es reproducir algo la estructura de archivos para que, dada cualquier traducción, pueda encontrar inmediatamente su origen. Esto me da algún tipo de contexto para hacer la traducción.

La mayoría de las traducciones de aplicaciones se encuentran en vistas, por lo que mi espacio de nombres de mayor nivel suele ser views .

Creo espacios de nombres secundarios para el nombre del controlador y el nombre de acción o parcial que se usa ex:

• views.users.index.title
• views.articles._sidebar.header

Ambos ejemplos deberían hacer obvio qué parte de mi aplicación estamos traduciendo y qué archivo buscar para encontrarla.

Menciona la navegación y los botones, si van a ser genéricos, entonces pertenecen al espacio de nombres views.application al igual que sus contrapartes de vista:

• views.application._main_nav.links.about_us - un enlace en la navegación principal de nuestra aplicación parcial
• views.application.buttons.save
• views.application.buttons.create - Tengo un montón de estos botones listos para usar cuando sea necesario

Los mensajes flash se generan desde el controlador, por lo que su espacio de nombre de nivel superior es ... ¡ controllers ! :)

Aplicamos la misma lógica que aplicamos a las vistas:

• controllers.users.create.flash.success|alert|notice

De nuevo, si quisiera proporcionar mensajes flash genéricos como "Operación exitosa", escribiría algo como esto:

• controllers.application.create.flash.notice

Finalmente, las claves pueden ser cualquier cosa que sea válida en YAML, pero por favor, use periodos . como separadores y subrayaciones entre palabras como una cuestión de convención.

Lo único que queda por resolver ahora es obtener las traducciones de los rieles en su propio espacio de nombres para limpiar nuestro nivel superior :)

Answer 2

La edición directa de los archivos yaml lleva a archivos desordenados e ilegibles.
Además, será difícil para usted proporcionar acceso a los traductores si, algún día, desea que un no desarrollador agregue un nuevo idioma.

Yo 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.

Answer 3

Pasaron casi dos años desde que hice esta pregunta y deseo compartir algunas ideas. Creo que la estructura óptima es para crear espacios de nombres de acuerdo con su rol de MVC (modelos, vistas, controladores). Esto mantiene ordenado el archivo de configuración regional e impide las colisiones de espacios de nombres (por ejemplo, el alcance 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 el uso de espacios de nombres ordenados como ese rompe la función de búsqueda lenta en Rails. Si utiliza la búsqueda diferida, Rails insertará el espacio de nombre automáticamente, y no incluirá los espacios de nombres de nivel superior que creó ( views , controllers , etc.).

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

Para resolver este problema github.com/abitdodgy/i18n_lazy_scope . Le permite usar la búsqueda diferida con sus propios espacios de nombres personalizados.

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

Answer 4

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

Dado que me gustaría

1. mantener la estructura predeterminada de la aplicación para que pueda usar búsquedas abreviadas "perezosas" como t(''.some_translation'') en mis vistas,
2. evitar la mayor repetición de cuerdas posible, en particular con palabras que no son exactamente iguales, pero que también tienen contextos / significados idénticos,
3. solo tiene que cambiar una tecla una vez para que se refleje en todos los lugares a los que se hace referencia,

para un archivo config / locales / en.yml que se parece a 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" no son ambiguos y tienen el mismo significado en sus respectivas vistas. Sería un poco molesto tener que ir y cambiarlos todos si decido cambiar "Correo electrónico" a "Correo electrónico", por lo que me gustaría refactorizar las cadenas para hacer referencia a un diccionario de algún tipo. Entonces, ¿qué tal si agregamos 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

Cada vez que obtenga más de una instancia de exactamente la misma palabra / frase en sus vistas, podría refactorizarla en 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 idioma de destino por una cadena estática o agréguela como una entrada adicional al diccionario de la lengua de destino. Estoy seguro de que el diccionario de cada idioma se puede refactorizar en otro archivo si se vuelven demasiado grandes e inmanejables.

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

Answer 5

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

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

Así que lo intentaré directamente aquí:

• Navegación

  Creo que te refieres a los elementos de navegación como migas de pan, pestañas, ... Debes definir vistas para ellos, y luego pegarlos a la regla para mover todos los elementos de la vista en archivos separados en las views directorio (mira la guía de estilo para la regla) .

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

  Ver elementos, entrar en los mismos archivos también. Si usa los mismos botones en diferentes vistas, defina un archivo común, y luego use eso.

• Mensajes de error del flash del controlador

  Usaría la misma regla que para las vistas. Defina un directorio separado, incluya allí los archivos para los controladores.

• Cómo agregar claves de palabras múltiples. ¿Uso un espacio o un guión bajo? Por ejemplo, t (". Botón de actualización")) o t (". Update_button")

  Yo personalmente preferiría usar el .update_button , not .update button , porque hace más explícito que esta es una clave.

Answer 6

Viniendo 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 según la estructura DOM. Si bien este es un buen enfoque para las 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 raros (algunos traductores ni siquiera saben lo que significa MVC).

entonces mi archivo de traducción está estructurado así

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

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

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

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

El código para los métodos de scoping de traducción está disponible en esa respuesta