2010-06-28 22 views
5

Estoy buscando consejos sobre mejores prácticas para localizar datos almacenados en la base de datos. Estoy trabajando en una aplicación web en la que todo el texto estático se localiza usando archivos. Tenemos varias opciones que el administrador puede configurar usando la interfaz de usuario que están almacenadas en la base de datos y necesitan localizar estos valores.localización de datos dinámicos

Hemos llegado con un par de ideas posibles. ¿Cuáles son sus pensamientos sobre estas soluciones? ¿Hay alguna opción mejor o incluso una mejor práctica estándar?

Per campo especializado Localización

Esta es la solución propuesta para best practices for multilanguage database design. Creamos una tabla separada para cada campo localizado. Por ejemplo, supongamos que tenemos la tabla colors con color_id, color_name y color_description columnas, podríamos romperlo a cabo en una tabla con los datos color no localizada y una mesa color_translationscolor_id, locale, color_name y color_description campos.

Sin embargo, nuestros clientes a menudo envían los archivos de localización a un tercero para hacer la traducción que se vuelve complicada.

Tabla única localización

Otra opción sería la creación de una sola tabla para representar la totalidad de la localización de la base de datos:

CREATE TABLE localized_text 
(
    key   VARCHAR(256) NOT NULL, 
    locale  CHAR(5) NOT NULL, 
    value  VARCHAR(256), 
    PRIMARY KEY (key, locale) 
); 

Esto sería más fácil de exportar para la localización fuera de sitio pero añade un nivel de indirección

+0

¿Hay alguna razón por la cual estas "varias opciones" no solo estén almacenadas como códigos en la base de datos y traducidas al nivel de presentación de la aplicación? De todos modos, creo que la opción uno es mucho más limpia, porque una tabla gigante con muchas traducciones diferentes para muchos dif. los modelos pueden tornarse infernales rápidamente –

+1

Creo que la principal objeción a simplemente almacenar códigos en la base de datos es que el usuario tiene que ir a dos lugares diferentes para configurar esto. Eso está bien para nuestros clientes más grandes que envían los archivos de localización para la traducción, pero no es ideal para clientes más pequeños. Incluso las empresas más grandes tendrían que copiar las claves de la interfaz de usuario en el archivo para su traducción. Una posible solución podría ser actualizar la interfaz de usuario para modificar los archivos de localización según sea necesario. ¿Alguien tiene alguna idea sobre eso? – Ross

+1

Haga la opción n. ° 1 e implemente una herramienta simple de importación/exportación para que sus clientes la usen para traducir el contenido personalizado fuera de la aplicación. –

Respuesta

1

Creamos una tabla separada para cada campo localizado. Por ejemplo, supongamos que tenemos los colores de las tablas con color_id, color_name y color_description columnas ....

Asumiendo que su mesa de colors es solamente texto estático, la opción obvia es agregar una columna a ella, tal vez nombrado locale y agregue filas para cada localidad que le interese. Luego únase a la configuración regional del cliente para producir la descripción individual que desea.

Para que esto funcione, debe separar las descripciones estáticas de los datos independientes de la configuración regional, ya que las descripciones localizadas introducen una relación de varios a uno. Como medida provisional, puede dejar las descripciones en inglés en la tabla principal y soltarlas una vez que todas las referencias a ellas desaparezcan.