Que tomar en cuenta al empezar un proyecto de i18n

¡Hola de nuevo! Ha pasado un buen tiempo desde mi último post. He estado algo ocupado con varias cosas como convertirme en papá de una bella niña (y ya esperando a la segunda), aprendiendo más de Testing y además haciendo pruebas, pero trataré de escribir más seguido. Actualización: Ha sido tanto tiempo desde que escribí este post que ahora tengo dos hermosas niñas de 3 y 1 años.

Durante los últimos meses me he unido a varias comunidades de Testers y me he dado cuenta que la misma pregunta ha sido hecha una y otra vez:

“Tengo un proyecto de internacionalización en puerta (a.k.a. i18n) Y no se dónde empezar o qué probar.”

Parafraseando un poco pero esa es básicamente la idea de todas estas preguntas. Por suerte, tengo un poco de experiencia con eso, ya que en el pasado estuve envuelto en 2 proyectos de esta naturaleza y con ayuda de mis conocimientos de más de un lenguaje. (Español, mi lengua nativa e Inglés, que sigo aprendiendo).

Dicho lo anterior, me gustaría mencionar algunos puntos que considero importantes a la hora de manejar las pruebas de un proyecto de i18n.

• Sé parte del proceso desde el inicio. Involúcrate en el proceso desde la planeación y arquitectura, ve a las juntas, lee toda la documentación del proyecto. Debes de tratar de desarrollar un entendimiento sólido de cómo tu equipo de desarrollo va a abordar el proyecto. Por ejemplo, en uno de mis proyectos, usamos archivos POT y PO que se enviaban a los traductores directamente y luego recibíamos ya con la traducción. En mi otro proyecto, la compañía usó un proveedor que ofrecía una plataforma de traducción.

• Identifica todos los riesgos. En uno de estos proyectos solíamos enviar a los traductores los textos. Luego de ser traducidos, el proveedor servía él mismo las traducciones al usuario final. El riesgo ahí era que si este servicio se caía, nuestros usuarios podían quedar con una mala experiencia de usuario, sin poder hacer mucho nosotros.

• Sé parte del equipo que planea el proceso de traducción. Por ejemplo, aprende todos los pasos que se requieren para que un texto en Inglés sea traducido a [inserta aquí tu lenguaje de preferencia]. Asegúrate de hacer preguntas como: ¿Usaremos traductores propios? ¿Usaremos algún proveedor? ¿Qué pasa si una traducción fue traducida incorrectamente? Si una mala traducción ocurre, para corregirla ¿Tiene que ir a través de todo el proceso para ser reparada? ¿Qué tanto tiempo puede tomarle a un texto ir de su forma original a mostrarse traducido en nuestro sitio?

• Una vez empezado el proceso de traducción, uno de los objetivos de nuestro equipo de desarrollo debe ser enviar los textos a traducir lo mas pronto posible, para evitar el caso en el que el proceso de desarrollo termine antes de que el proceso de traducción lo haga y atrasemos el release a producción por falta de traducciones.

• Asegúrate de saber dónde y cómo son enviadas las traducciones y como puedes probarlas. En uno de mis proyectos no siempre podíamos obtener las traducciones inmediatamente, por lo que confiábamos en un sistema que nuestro proveedor tenía, en el cual creaba un lenguaje llamado “reversi”. Una vez que un texto era enviado, podíamos seleccionar este idioma y este sistema volteaba el texto que había sido enviado a traducción. Algo como: “este texto de ejemplo” se mostraba como “olpmeje ed etse” de tal manera que podíamos ver de inicio si todos los textos habían sido enviados a traducción correctamente o no, sin necesidad de tener listas las traducciones.

• Busca errores de diseño. Algunos lenguajes como Alemán, Portugués y Español son mucho más largos que el Inglés, lo que significa que, al tener textos más largos, éstos pueden desfigurar tu diseño, especialmente en plataformas móviles. De igual manera busca errores de encoding en idiomas como Portugués o Español, ya que éste es un error muy común en estos idiomas ya que usan caracteres especiales. Pide a tus Product Owners y a cualquiera que provea de textos, textos originales lo mas cortos posibles, de tal manera que las traducciones también sean lo mas cortas posibles.

• Cuando estés probando traducciones, asegúrate de probar todo: Textos visibles, textos de error, cuadros de diálogo, botones, etc. No solo lo que quede visible a simple vista.

• Hay que recordar que cosas como fechas y otras medidas de unidad son formateadas de diferente manera en diferentes idiomas, por ejemplo: En Español las fechas llevan primero el día y luego el mes. Sin embargo, en Inglés va primero el mes y luego el día. En general hay que revisar todas las conversiones de unidades.

• Entiende bien toda la lógica de como un usuario termina viendo tal o cual idioma. Para las aplicaciones web, por ejemplo, hay diferentes variables que tu equipo puede tomar en cuenta como IP, Idioma del Sistema Operativo y/o Navegador. Sin embargo, se puede convertir en un desastre rápidamente. Por ejemplo, podríamos tomar en cuenta el lenguaje del navegador, pero hay ciertos lugares, como en Latinoamérica donde las computadoras se venden con el Sistema Operativo en Inglés y por lo tanto, los navegadores se instalan en ese idioma, pero eso no significa que esa sea la preferencia del usuario. Siempre tenemos que tener herramientas en nuestras aplicaciones que permitan al usuario elegir su idioma. En plataformas móviles podríamos usar la ubicación (GPS, IP) pero de nuevo, un Estadounidense podría entrar a nuestro sitio mientras está de vacaciones en Cancún y verlo en Español. Una buena combinación de ubicación/OS/Navegador es la mejor apuesta, pero recuerda siempre dejar la decisión final al usuario.

• Si estas probando en una Mac y necesitas cambiar tu idioma, trata de no usar Chrome. Éste navegador tiene sus preferencias de idioma ligadas al Sistema Operativo, por lo que si quieres cambiar el idioma en el navegador, tendrías que cambiarlo para todo el Sistema Operativo, lo cual no es tarea sencilla. Mejor usa Firefox, ya que puedes cambiar el idioma de este navegador desde su panel de preferencias.

• Si tu equipo usa ubicación (IP o algo similar) para cambiar idiomas, puedes utilizar proxies como HMA o AdClarity para cambiar fácilmente de idiomas, cambiando de ubicación.

• Si piensas implementar automatización necesitarás contacto directo y ayuda de tu equipo de desarrollo. Planeen una estrategia de identificación de elementos de tal manera que puedas usar classes, ids, tags, etc., para identificar elementos, en vez de sus textos. Para que de esa manera crees una suite que sea agnóstica al idioma y que puedas correrla en cualquiera.

Eso es todo lo que tengo por ahora… ¿Tienes alguna otra sugerencia? Déjamelo saber en la sección de comentarios aquí abajo y ¡Feliz 18n!