Historia de usuario 8

Interpolación o multilenguaje según request o variable enviada desde un cliente

Historia de usuario

Los proyectos back están preparados para recopilar en el messages.properties los distintos
mensajes a mostrar a un cliente pero no permite el switch de un idioma a otro, se debe
implementar la configuración que permita ese cambio fácilmente. Como usuarios finales se
neceita en algún momento usar multilenguaje y los back deben estar preparados para tal fin.

Detalle

Se debe aplicar o dejar todo listo en back para que funcione el multilenguaje. Para ello se debe
investigar y aplicar las configuraciones necesarias para tal fin. A manera de información, se
debe modificar los distintos archivos de configuración, application de java,
application.properties y crear otro archivos de mensajes, por ejemplo messages_es.properties
para que según el idioma de sesión se haga un switch al adecuado de forma sencilla. Para ello
existe una variable accept en el header que podría permitir el cambio., analizarla,
implementarla y aplicarla a todos los proyectos comenzando en el proyecto base. Por otro
lado, la modificación o lectura en los interceptores o middleware de back de esas variables
permite el ajuste fácilmente.

PROCESO DE IMPLEMENTACION

La base para poder tener una aplicación internacionalizada son los archivos de idiomas, en
Spring Boot si no cambiamos nada por defecto estos archivos deberán llamarse
messages.properties, messages_es.properties, messages_en.properties, … es decir, el nombre
base del archivo (messages) seguido del código del idioma y en el caso de que queramos ser
más específicos también del código del país.

Dentro de estos archivos tendremos los pares de clave y valor que identifican a cada uno de los
textos que queremos tener en varios idiomas y obviamente la clave para un mismo texto tiene
que ser la misma en todos los archivos.

En Spring, el soporte para la internacionalización se proporciona a través de

AcceptHeaderLocaleResolver, es el solucionador de zonas predeterminado, que resuelve zonas
mediante el parámetro accept-language de la solicitud HTTP.

Configuración backend
En nuestro proyecto Spring Boot agregamos la dependencia web

Se creó el package co.edu.uis.rrhh.admonpersonal.internationalization

Se creó la clase CustomLocaleResolver que extiende de de AcceptHeaderLocaleResolver, este

analizador, de forma predeterminada, utiliza el campo Accept-Language del encabezado de la
solicitud para determinar el entorno de la solicitud actual y luego proporcionar la respuesta.
Como podemos observar en el método localeResolver le indicamos a Spring que vamos a
definir el idioma de las respuestas del webservice utilizando cabeceras en nuestros requests al
mismo. Además, hemos definido como idioma predeterminado el español.

Debemos agregar un bean en el contexto de nuestra aplicación en

AdministracionPersonalApplication para indicarle a Spring que vamos a trabajar con nuestra
clase CustomLocaleResolver que hemos definido en el paso anterior.

El archivo de mensajes se crea por defecto en el directorio src/main/resorces de nuestro

proyecto, messages.properties es la configuración predeterminada. Se deben crear los
archivos necesarios para los diferentes idiomas que tendrá soporte nuestra aplicación.

Se agregaron los archivos correspondientes para las traducciones en los archivos

messages_es.properties y messages_en.properties correspondientes para el idioma español e
inglés. Si se desea brindar soporte disponible en más idiomas agregar los archivos
messages_xx.properties correspondientes (ejemplo: messages_fr.properties para el idioma
francés).
Archivo messages_es.properties para el idioma español, este archivo debe de contener todos
los mensajes en español

Archivo messages_en.properties para el idioma inglés, este archivo debe de contener todos los
mensajes en ingles.

Se deben agregar las claves y su valor correspondientes en cada uno de los archivos
messages_xx.properties para brindar los mensajes en los diferentes idiomas.

Pruebas
Se creó una clase TestController para realizar pruebas que posteriormente fue eliminada del
proyecto.

Se utiliza postman para realizar las peticiones al backend

Petición GET hacia TestController: /api/test-i18n/test

- Prueba cuando no se envía el Accept-Language en el header. Devuelve el idioma por

defecto que se configuró que es el español
 - Prueba cuando se envía el Accept-Language en el header. Idioma español

- Prueba cuando se envía el Accept-Language en el header. Idioma ingles

Si en la petición se envía en el header el Accept-Language con un idioma que no está

soportado por el backend se retorna el idioma por defecto que es el español.
Se envió el idioma en fr para francés, como no está soportado por el backend se devuelve el
idioma por defecto que es español.
Petición POST hacia TipoCargoController: /api/tipoCargo

Realiza la validación de TipoCargoDTO

- Prueba para realizar las validaciones de los atributos en la clase TipoCargoDTO, sin
enviar el Accept-Language en el header, retorna el idioma configurado por defecto
que es el español

Body

{
    "nombre": "MOTIVOS DE DESVINCULACION",
    "senalPosesion": true
}

- Prueba para realizar las validaciones de los atributos en la clase TipoCargoDTO,

Accept-Language presente en el header, idioma español

Body

{
    "nombre": "MOTIVOS DE DESVINCULACION",
     "senalPosesion": true
}

- Prueba para realizar las validaciones de los atributos en la clase TipoCargoDTO,

Accept-Language presente en el header, idioma ingles

Body

{
    "nombre": "MOTIVOS DE DESVINCULACION",
    "senalPosesion": true
}

Si en la petición se envía en el header el Accept-Language con un idioma que no está

soportado por el backend se retorna el idioma por defecto que es el español.
Se envió el idioma en fr para francés, como no esta soportado por el backend se devuelve el
idioma por defecto que es español.