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_translations
color_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
¿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 –
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
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. –