Localization l10n en Hybris (I)

Introducción

SAP Hybris Commerce es una plataforma global - (Fuente:https://commons.wikimedia.org/)

Hoy vamos a empezar una serie de post para ver como SAP Hybris Commerce da soporte a la localización, es decir, soporte a múltiples idiomas.

Me he encontrado con muchas dudas por parte de clientes, desarrolladores, consultores... acerca de la localización en Hybris Commerce, por eso quiero iniciar un serial para tratar la localización.

Hay que tener claro que la localización se da en diferentes puntos de la plataforma Hybris, en un principio se me ocurren estos:
  1. Localización en el modelo de datos (Types y Models)
  2. Localización en los atributos de clasificación
  3. Localización en los Cockptis
  4. Localización en el Backoffice
  5. Localización en el Storefront
Para resolver en los diferentes puntos Hybris implementa diferentes estrategias. Veremos una por una

1. Localización en el modelo de datos (Types y Models)

Hybris en el modelo de datos tiene soporte para la localización tanto en el nombre y descripción de los atributos de los tipos Types como en los valores.

Nombre y descripción de los tipos y sus atributos

Se utiliza para las etiquetas de nombre de las herramientas de Backoffice, hmc, product cockpit, cms cockpit, etc.

Se definen los ficheros

  • extension-locales_es.properties

Los propios ficheros autogenerados nos indican cómo rellenarlos

  • type.<code of type>.name=XY
  • type.<code of type>.<qualifier of attribute>.name=XY
  • type.<code of type>.description=XY
  • type.<code of type>.<qualifier of attribute>.description=XY

En un ejemplo real:
  • type.product.code.name=Número de artículo
  • type.product.code.description=Identificador único del código de artículo
¡Importante!

La codificación de los ficheros .properties tiene que ser UTF-8, si abrimos un fichero en Eclipse por ejemplo y vemos que tiene caracteres extraños, seguramente la codificación esté mal.
Imagen de codificación Eclipse
Por defecto Eclipse elige otra codificación a UTF-8

Valores multilenguaje de los atributos

De manera muy sencilla podemos indicar que determinando atributo de un tipo es multilenguaje, es decir, un valor diferente por idioma. Un caso típico es el campo nombre de los productos.

Para indicar que un atributo es multivaluado simplemente al definirlo le incluimos un prefijo especial en el type. Se realiza en los ficheros *-items.xml de la forma:

  • <attribute autocreate="true" qualifier="name" type="localized:java.lang.String">

Hybris de manera estándar está preparado para "soportar" este tipo de localización y en todas sus herramientas de backoffice tiene un desplegable para introducir los valores del atributo.
Imagen de un atributo localizable
El campo Identificador (nombre de producto)

¿Cuándo definir un atributo multilenguaje?

Parece una pregunta con respuesta obvia pero a veces creamos un atributo sin pararse a pensar si es susceptible de ser es localizado o no. Antes de definir un atributo nuevo, dedica 5 minutos a pensarlo antes. ¿Puede tener valores diferentes en regiones? ¿Se va a ver en el Storefront? ¿Es un atributo que influye en alguna lógica de negocio? ¿Se utiliza como cláusula, índice, pk...?

¿Cómo pasar un atributo no localizado a uno que lo es?

Si por nuevos requisitos o funcionalidades tenemos que convertir un atributo no localizado en uno que lo es. La operación implica varios pasos que deben seguir este orden:

  1. Recuperar los valores actuales a través de una exportación usando ImpexExport
  2. Actualizar la definición del modelo de datos en los *-items.xml
  3. Importar los valores exportados previamente incluyendo en el Impex la clave del idioma del atributo original por ejemplo: name[lang=es]

Localización en nivel de base de datos

Sin entrar en detalle, Hybris maneja los atributos localizados en tablas diferentes, estas tablas tienen el sufijo lp. Por ejemplo para almacenar los atributos tenemos la tabla products, los valores de los atributos localizados se almacenan en la tabla productslp. Podemos verlo de una manera sencilla en el hAC.

Tenemos esta consulta en HybrisSQL:
  • SELECT {p.name} FROM {Product AS p}
La traduce en SQL nativo a:
  • SELECT  lp_t0.p_name  FROM productslp lp_t0 WHERE ...
¡¡Vemos que no hace referencia a la tabla products!!

Por lo que si combinamos dos atributos (uno multi y otro que no lo es) en una misma consulta como:
  • SELECT {p.name}, {p.code} FROM {Product AS p}
Su traducción a SQL nativo es:
  • SELECT  lp_t0.p_name ,  item_t0.p_code  FROM products item_t0 JOIN productslp lp_t0 ON item_t0.PK = lp_t0.ITEMPK AND lp_t0.LANGPK =?  WHERE ...
Aunque en la mayoría de los casos nos abstraemos de estos detalles. En determinados momentos necesitamos conocer cómo trabaja la plataforma.

En el siguiente artículo entraremos

Más info

Comentarios

Entradas populares de este blog

SAP Hybris Commerce - SAP Commerce Cloud Versión 1808

Páginas responsive en Hybris

Logs en Hybris Commerce