El escenario
Eres el propietario de una tienda en línea, ubicada en Polonia. La mayoría de sus clientes son de Polonia y hablan polaco. Pero también quiere vender sus productos en el extranjero y sus clientes internacionales hablan principalmente inglés. Por lo tanto, desea que su tienda en línea esté disponible tanto en polaco e inglés . También espera que sus productos se vendan bien en Francia, por lo que anticipa que tendrá que preparar un francés versión de la tienda también (y tal vez español también, porque ¿por qué no?).
Quiere que sus usuarios puedan cambiar desde la versión polaca
a la versión en inglés y viceversa.
Y, obviamente, desea que los detalles del producto cambien de polaco a inglés.
¿Cómo se crea una aplicación web en varios idiomas?
Hay dos tipos de texto en su aplicación. Uno es estático datos:etiquetas de botones, encabezados de tablas, gráficos (que a menudo contienen texto). El otro es el definido por el usuario datos, como el nombre del producto, el precio del producto, la descripción del producto, etc. Los datos normalmente se toman de la base de datos.
Los datos estáticos son lo que le gustaría escribir como un literal de cadena en su salida. Los datos definidos por el usuario son datos que usted toma de su base de datos.
Hoy no hablaré de datos estáticos. Cualquier marco web razonable manejará la internacionalización de los datos estáticos. Consulte la documentación del marco de su aplicación web para obtener más detalles. Busque palabras clave como "internacionalización", "i18n", "localización" o "traducciones".
Hoy hablaré sobre la estructura de base de datos que solemos usar aquí en e-point para manejar datos en varios idiomas. En la base de datos de tu tienda, probablemente tengas el product tabla que almacena información sobre todos los productos disponibles en la tienda.
El product la tabla tiene columnas como name , description y price . Cuando traduces la información del producto a otros idiomas, solo tienes que traducir algunas columnas. Aquí traducirías solo el name y description , pero el price no cambia cuando cambias de idioma.
Cuando agregamos soporte para varios idiomas, agregamos una nueva tabla llamada language_version , que almacena todas las versiones de idiomas disponibles en la tienda. Por lo general, agregamos una columna llamada code y uno llamado is_default (con una restricción apropiada:solo una versión puede ser la predeterminada).
A continuación, dividimos el product tabla en dos tablas:tabla product y tabla product_lv . Para cada producto, habrá una fila en el product tabla y múltiples filas en el product_lv mesa; una fila para cada versión de idioma. La tabla product_lv solo contiene columnas que deben traducirse:name y description . Las columnas que son independientes del idioma (como price , porque usted vende por el mismo precio sin importar si su cliente habla inglés o polaco) quédese en la tabla product .
Hacemos lo mismo para cada tabla que contiene datos traducidos. Los datos traducidos van a la table_lv tabla, los datos independientes del idioma permanecen en la tabla principal.
Pros y Contras
Una desventaja obvia es que todas las operaciones de creación, recuperación, actualización o eliminación (CRUD) se vuelven un poco más complicadas. Siempre tiene que unirse a una tabla de versión de idioma adicional para obtener la descripción correcta.
La ventaja de este diseño es que no tiene que cambiar el esquema de su base de datos cuando agrega una nueva versión de idioma. No estoy diciendo que agregar una nueva versión de idioma sea fácil. Después de todo, tienes que traducir TODAS las descripciones de los productos. Este es un desafío organizativo, pero desde el punto de vista de la base de datos es bastante fácil:muchas inserciones.
¿Cómo diseñan sus bases de datos multilingües?
