Cómo diseñar un sistema listo para la localización

En esta era de globalización, las empresas, incluidos los desarrolladores de software, siempre están interesadas en expandirse a nuevos mercados. Esto a menudo significa localizar sus productos para diferentes áreas. En este artículo, explicaremos algunos enfoques para diseñar su modelo de datos para la localización, específicamente, para administrar contenido en varios idiomas.

¿Qué es la localización?

La localización es el proceso de adaptar un producto a varios mercados. Es un factor destacado para lograr la máxima participación de mercado en términos de ventas de productos. Cuando la localización se realiza correctamente, los usuarios sentirán que el producto se elaboró ​​para su idioma, cultura y necesidades.

En lugares donde el inglés no es un primer idioma común, las encuestas han demostrado que los idiomas locales son mucho más preferidos para un producto de software. Este artículo de MediaPost contiene algunas cifras interesantes sobre la necesidad de idiomas distintos del inglés cuando se trata de ventas internacionales.

¿Qué puedes perder si no localizas?

Consideremos un ejemplo desafortunado de no localización. Para comodidad de los clientes, un portal de comercio electrónico les permitió agrupar compras individuales en un grupo de cuatro. Desafortunadamente, la pronunciación de la palabra "cuatro" en japonés suena como su palabra para "muerte". Los japoneses suelen evitar todo lo relacionado con este número porque se considera desafortunado. No hace falta decir que las ventas de esos productos no fueron bien en el mercado japonés.

Entonces, en respuesta a la pregunta anterior, podría perder mucho si no planifica cuidadosamente su mercado objetivo.

Traducción de contenido como localización

Cuando pensamos en la localización, la traducción de contenido suele ser lo primero que nos viene a la mente. El segundo pensamiento es "Necesitamos un modelo de base de datos robusto y eficiente para almacenar contenido traducido en varios idiomas".

Supongamos que se nos pide que diseñemos un modelo de datos para una aplicación de comercio electrónico multilingüe. Necesitaríamos almacenar campos de texto como product_name y la descripción de los productos en varios idiomas. También necesitaríamos almacenar campos de texto en otras tablas, como el customer mesa, en todos estos idiomas.

Para comprender cómo diseñar nuestro modelo de datos teniendo en cuenta la traducción de contenido, examinaremos diferentes enfoques mediante el uso de estas dos tablas. Cada uno de estos enfoques tiene pros y contras. Los enfoques que se muestran a continuación se pueden extender a otras tablas en su modelo de datos. Por supuesto, el enfoque exacto que elija se basará en sus propios requisitos.

Método 1:agregar columnas de idioma separadas para cada campo previsto

Este es el enfoque más simple en términos de desarrollo. Se puede implementar agregando una columna de idioma para cada campo.

Ventajas

• Es muy fácil de implementar.

• No hay complejidad en escribir SQL para obtener los datos subyacentes en cualquier idioma. Supongamos que quiero escribir una consulta para recuperar los detalles del producto y del cliente para un pedido en particular en el idioma francés. El código se vería así:

  Select p.product_name_FR, p.description_FR, p.price, 
         c.name_FR, c.address_FR, c.contact_name 
  from order_line o, product p, customer c
  	Where o.product_id = p.id and o.customer_id = c.id
  	And id = ;
  

Contras

• No hay escalabilidad:cada vez que se agrega un nuevo idioma, se deben agregar docenas de columnas adicionales en las tablas.
• Puede consumir mucho tiempo, especialmente si muchos campos deben tener varios idiomas.

• Los desarrolladores terminan escribiendo la consulta que se muestra a continuación para administrar todos los idiomas existentes. Por lo tanto, todos los SQL de su aplicación deben cambiar cuando se introduce un nuevo idioma. (Nota: @in_language significa el idioma actual de la aplicación; este parámetro proviene del front-end de la aplicación, mientras que el back-end recupera registros).

  SELECT CASE @in_language 
                WHEN ‘FR’ THEN p.product_name_FR
                WHEN ‘DE’ THEN p.product_name_DE
                DEFAULT THEN p.product_name_EN,
             p.price,
            CASE @in_language 
                WHEN ‘FR’ THEN c.name_FR
                WHEN ‘DE’ THEN c.name_DE
                DEFAULT THEN c.name_EN,
            c.contact_name
  FROM order_line o, product p, customer c
  	WHERE o.product_id = p.id AND o.customer_id = c.id
  	AND id = ;
  

Enfoque 2:crear una tabla separada para el texto traducido

En este enfoque, se usa una tabla separada para almacenar el texto traducido; en el siguiente ejemplo, llamamos a esta tabla translation . Contiene una columna para cada idioma. Los valores que se han traducido de valores de campo a todos los idiomas aplicables se almacenan como registros. En lugar de almacenar texto traducido real en tablas subyacentes, almacenamos su referencia a la translation mesa. Esta implementación nos permite crear un repositorio común de texto traducido sin realizar demasiados cambios en el modelo de datos existente.

Ventajas

• Es un buen enfoque si se va a implementar la localización en un modelo de datos existente.
• Una única columna adicional en la translation table es el único cambio necesario cuando se introduce un nuevo idioma.
• Cuando el texto original es el mismo en todas las tablas, no hay texto traducido redundante. Por ejemplo:supongamos que el nombre de un cliente y el nombre de un producto son idénticos. En este caso, solo se insertará un registro en la tabla de traducción y se hará referencia al mismo registro en el customer y product mesas.

Contras

• Todavía requiere un cambio en el modelo de datos.
• Puede haber valores NULL innecesarios en la tabla. Si se necesitan 1000 campos para un solo idioma admitido, terminará creando 1000 registros y muchos NULL.

• La complejidad de escribir SQL aumenta a medida que aumenta el número de uniones. Y cuando hay muchos registros en la translation tabla, los tiempos de recuperación son más lentos.

  Escribamos de nuevo un SQL para la declaración del problema de gestión del lenguaje:

  SELECT CASE @in_language 
                WHEN ‘FR’ THEN tp.text_FR
                WHEN ‘DE’ THEN tp.text_DE
                DEFAULT THEN p.product_name_EN,
             p.price,
            CASE @in_language 
                WHEN ‘FR’ THEN tc.text_FR
                WHEN ‘DE’ THEN tc.text_DE
                DEFAULT THEN c.name_EN,
            c.contact_name
  FROM order_line o, product p, customer c, translation tp, translation tc
  	WHERE o.product_id = p.id AND o.customer_id = c.id
  	AND p.name_translation_id = tp.id
  	AND c.name_translation_id = tc.id
  	AND id = ;
  
  

Una variante del método de la tabla de traducción

Para obtener un mejor rendimiento cuando se recupera el texto traducido, podemos dividir la translation tabla en varias tablas. Podemos agrupar los registros según el dominio, es decir, una tabla para customer , otra para product , etc

Enfoque 3:una tabla de traducción con filas para cada idioma

Esta implementación es bastante similar al segundo enfoque, pero almacena los valores del texto traducido en filas en lugar de columnas. Aquí, la translation la identificación de la tabla sigue siendo la misma para un valor de campo en cualquier idioma traducido. Una clave primaria compuesta {id , language_id } se almacena en la tabla de traducción y almacena el mismo translation_id para cada campo contra múltiples language_id .

Ventajas

• Esta implementación permite a los desarrolladores escribir SQL de recuperación de datos con bastante facilidad.
• También es fácil escribir OEM para este modelo.
• No se necesitan cambios en el modelo de datos cuando agrega un nuevo idioma; simplemente inserte los registros para el nuevo idioma.
• No hay consumo de memoria innecesario cuando un conjunto de campos no son aplicables a un idioma.

• Se reduce la complejidad de los SQL de recuperación de datos. Mira el siguiente ejemplo:

  SELECT tp.text,
          p.price,
         tc.text,
          c.contact_name
  FROM order_line o, product p, customer c, translation tp, 
       translation tc, language l
  	WHERE o.product_id = p.id AND o.customer_id = c.id
  	AND p.name_translation_id = tp.id
  	AND c.name_translation_id = tc.id
               AND tp.language_id = l.id
               AND tc.language_id = l.id
               AND l.name = @in_language
  	AND id = ;
  
  

Contras

• Se requiere un número relativamente alto de uniones para recuperar los datos traducidos.
• Con el tiempo, es posible que se almacene una gran cantidad de registros en la translation mesa. Dado que solo hay una tabla de traducción, todo el texto traducido se volcará en ella. Cuando tiene millones de campos para traducir y su aplicación admite una gran cantidad de idiomas, consultar una tabla para una traducción sería una actividad que llevaría mucho tiempo. Sin embargo, puede dividir la tabla de traducción según los idiomas o las áreas temáticas, como señalamos al final del segundo enfoque.

¿Qué pasa si combinamos los enfoques 2 y 3?

Específicamente, combinaremos la variante del Enfoque 2:dividir la translation table – con la idea de usar filas en una tabla. Podemos superar fácilmente la desventaja de tener registros enormes en la translation table creando múltiples tablas basadas en un dominio, como hicimos en la variante del Enfoque 2. Si hay una cantidad considerable de registros en la tabla de traducción basada en el dominio, podríamos dividir aún más las tablas según los campos individuales.

Enfoque n.° 4:creación de capas de entidad para campos traducidos y campos no traducidos

En esta solución, las tablas de entidades que contienen uno o más campos traducidos se dividen en dos capas:una para campos traducidos y otra para campos no traducidos. De esta manera, creamos capas separadas para cada uno.

Ventajas

• No es necesario unir tablas de traducción si solo se trata de campos no traducidos. Por lo tanto, los campos no traducidos obtienen un mejor rendimiento.
• Se requiere un número relativamente menor de uniones para recuperar textos traducidos.
• Es fácil escribir OEM.
• Los SQL para recuperar texto traducido son simples.
• Este es un enfoque comprobado para incorporar varios idiomas en todas las entidades.

Para demostrar el punto, aquí hay una consulta de muestra que recuperará el texto traducido:

SELECT pt.product_name, pt.description, p.price
FROM order_line o, product p, product_translation pt, language l
	WHERE o.product_id = p.id AND 
	AND p.id = pt.product_non_trans_id
	AND pt.language_id = l.id
               AND l.name = @in_language
	AND id = ;

Localización:ir más allá de la traducción de contenido

La localización no es solo traducir el contenido de su aplicación a otro idioma. Hay parámetros culturales y funcionales que también necesitan atención. Por ejemplo, un valor de fecha tiene el formato 'MM/DD/AAAA' en América del Norte, pero en la mayor parte de Asia se escribe como 'DD/MM/AAAA'.

Otro ejemplo tiene que ver con mostrar nombres en el encabezado de la aplicación. En los EE. UU., llamar a alguien por su nombre de pila es aceptable o incluso preferible; en esta cultura, el nombre del cliente se muestra en el encabezado tan pronto como el cliente inicia sesión. En Japón, sin embargo, las cosas son al revés:llamar a alguien por su nombre es descortés o incluso insultante. La localización tomaría esto en cuenta y evitaría el uso de nombres de pila para la audiencia japonesa de la aplicación.

Es posible que los parámetros de localización deban almacenarse en el back-end de la aplicación. Este es en gran medida el caso cuando tiene que diseñar alguna lógica de programa en torno a la localización. Probablemente podamos categorizar todos esos parámetros en categorías culturales y funcionales, y construir el modelo de datos a su alrededor.

Una reflexión más sobre la localización

La localización es necesaria cuando una marca global penetra en los mercados locales. Para localizar una aplicación, observe el panorama general. La localización es más que un rendimiento técnicamente perfecto. También significa dominar las culturas, los comportamientos e incluso las formas de pensar y de vivir locales.

¿Qué más se puede hacer para que una aplicación se adapte localmente? Háganos saber sus pensamientos en los comentarios.