Como comenté en el resumen del año, 2021 ha sido el año de la internacionalización para www.centraldereservas.com. Y como suele pasar cuando a veces los proyectos se desarrollan rápido, es que a veces suceden cosas que nadie había previsto. Os cuento una de ellas.
Al equipo nos llegó la incidencia de que se estaban grabando en los sistemas como «???» algunos datos del titular de la reserva, lo cual daba problemas al llegar al alojamiento. En concreto teníamos 36 reservas con ese problema, 10 de ellas pendiente de entrar aun al alojamiento.
En España los hoteles no se preocupan mucho, pero en otros países, los datos del titular deben aparecer exactamente como los del pasaporte, incluso habiendo casos que hay que rellenar igual los de todos los integrantes de la reserva.
Al ponernos a investigar vimos que lo que ocurría es el usuario estaba rellenando el formulario con caracteres no latinos. Eso al mandarlo a otros sistemas los procesaba como «???». La solución era simple para nuestro proyecto, bastaba con cambiar la codificación de «Latin1» a «UTF 8» (o en concreto utf8_mb4, que sino luego alguien puede poner un emoji) en nuestras peticiones al xml.
¿Pero qué pasaba? El resto de sistemas a los que teníamos que mandar esa información, que tenían que procesarla y almacenarla, no podía cambiarlo asi de fácil (por lo visto hacer eso en Perl debe ser un festival sino se hace al inicio…). De hecho por eso en nuestro caso estaba como «Latin1» porque había sido un requerimiento inicial por parte de ese sistema.
Por ello tuvimos que pensar en una solución por nuestra parte sin involucrar al resto de sistemas. Al equipo se le ocurrieron 2:
- Usar una librería de transliteración, que básicamente convierte una cadena de caracteres que no sea «latin1» a un equivalente fonético de como sonaría escrito con caracteres «latin1». Es decir la palabra rusa, la palabra rusa «Русский» (que significa «ruso»), generaría la cadena de texto ‘Russkiy’, que es como suena aproximadamente dicha palabra.
- Que al escribir el usuario esos campos con caracteres no latinos, les saliera un mensaje de advertencia, y a ser posible al rellenar el primer campo y no cuando hubiera rellenado todos los del formulario.
Como ya he comentado antes, el hecho de escribir mal el nombre del cliente poniendo un equivalente fonético, podría dar problemas al cliente al llegar al alojamiento, lo cual derivaría en problemas a nuestro servicio de atención al cliente. Por ellos nos decidimos por la solución 2.
Además para evitar los problemas de diferencias entre los datos del pasaporte y la reserva, añadimos en los campos de Nombre y Apellidos, la coletilla «como aparece en el pasaporte», ya que en los países que tienen un alfabeto distinto al latino tienen 2 nombres en su pasaporte.
En una mañana teníamos el error descubierto, puesto las soluciones en común, implementado y puesto en producción, evitando asi que entrasen más reservas con este problema. Bravo equipo!