5

estoy en busca de algunos consejos y recomendaciones para las mejores prácticas para el uso de la internacionalización. He buscado, pero realmente no he estado satisfecho con lo que leo. La mayoría de los artículos que he leído se centran en el uso de archivos yml para I18n que no funcionarán en mi situación.Rails 3 I18n para las tablas de bases de datos

Actualmente tengo varias tablas de bases de datos con texto en Inglés. Algunas de estas tablas tienen campos de texto con algunas oraciones largas y otras con más de 6 párrafos de texto. Me gustaría también tener estos campos en español.

El enfoque que estoy considerando actualmente es utilizar la gema registro i18n-activos y tienen 1 traducciones tabla que la aplicación va a utilizar para todas las traducciones en la aplicación

class CreateTranslations < ActiveRecord::Migration 
    def self.up 
     create_table :translations do |t| 
     t.string :locale 
     t.string :key 
     t.text :value 
     t.text :interpolations 
     t.boolean :is_proc, :default => false 

     t.timestamps 
     end 
    end 

    def self.down 
     drop_table :translations 
    end 
    end 

¿Es esta la mejor manera ¿para proceder?

Por un lado todas las traducciones serán muy bien almacenan en una tabla. Por otro lado, cada vez que un usuario consulta la base de datos para contenido I18n. La aplicación consultará la tabla original para la clave, y luego consultará la tabla de traducciones también. Otra preocupación es que la tabla de traducción será masiva y tendrá una gran cantidad de filas, ya que almacenará todas las traducciones de la aplicación (desde el título de la sección [unas pocas palabras] hasta páginas enteras de texto.

Cualquier información se agradece. Gracias

+0

También puede comprobación éste https://github.com/tr8n/tr8n también. –

Respuesta

6

El almacenamiento de traducciones en el db no es una solución tan mala. No tenga miedo de las tablas grandes: las bases de datos están hechas para eso. Solo asegúrese de que sus índices estén configurados correctamente y guarde en caché todo lo que pueda

Otra solución más rápida y posiblemente mejor es utilizar Redis como un servidor para I18n. Consulte http://guides.rubyonrails.org/i18n.html#using-different-backends y http://railscasts.com/episodes/256-i18n-backends.

Dondequiera que almacene las traducciones, no es necesario tratar de administrar las interpolaciones usted mismo ya que la biblioteca I18n maneja esto bastante bien (a menos que esté haciendo algo realmente personalizado, eso es).

-1

La única ventaja que tendrá que almacenar en una base de datos es que si usted pretende editar sobre la marcha. Entonces, si fue su intención, la sugerencia de los idlefingers es un camino por recorrer. Pero si no está pensando en eso, un YML simple haría el trabajo de traducir la interfaz, nombres de tablas, nombres de campos, etc.

Si desea almacenar sus datos con más de un idioma, debe gastarlos algún tiempo con un modelado de base de datos específico.

Puede hacer básicamente de dos maneras: - Duplicar los campos que necesite en más de un idioma - Duplicar inserta ítems y la bandera con el idioma, también puede indicar la versión original en todas las copias a un mejor seguimiento ellos.

+2

Almacenarlo en la base de datos reduce la necesidad de empujar y tirar solo para las actualizaciones de idioma, también lo hace para que no tenga que implementar una nueva versión simplemente porque actualice un archivo de idioma. Esto no es nada que ver con "la edición sobre la marcha" esto es todo que ver con traducciones no tener que ser gestionados por los desarrolladores. Estaría bastante enojado y ocupado si tuviera que actualizar constantemente un idioma para un traductor que no merece ningún acceso de repo. Algunas personas prefieren CopyCopter ... –

+0

Al optar por poner la traducción fuera del código, se pierde la relación de los cambios de código a los cambios de traducción. Puede o no ser un problema, todo depende de cuánto cambie su sitio.Además, si usted, por alguna razón, desea retroceder y revertir un cambio, no puede hacerlo simplemente revisando la versión en el sistema de revisión, tiene que ocuparse de las traducciones en su base de datos. Incluso aquellos que tienen alguna aplicación web para traducir cosas (wordpress es un buen ejemplo, el proyecto ubuntu otra) generan código en algún momento para que la versión lo controle. –

+0

Sus traducciones no deberían cambiar con el código. Una vez que defina una traducción, se mantendrá así a menos que se elimine el código o se agregue código. Tal refactorización drástica causa problemas y luego necesita abarcarlos en sus pruebas para evitar ese tipo de problemas. OMI: si está cambiando las claves de traducción constantemente, lo está haciendo mal. Las traducciones del sistema base tampoco tienen nada que ver con la forma en que maneja las traducciones en un sitio de producción. Lo que estoy diciendo es que no arroje las traducciones del sistema base de ActiveModel o ActiveSupport a su embarcación. Tratar con ellos cuando lo necesiten. –

Cuestiones relacionadas