Cómo probar traducciones, idiomas y formatos regionales

La internacionalización y la localización son dos fases distintas y complementarias del proceso de hacer que una aplicación funcione en varios idiomas y regiones, y confundirlas lleva a organizar mal el trabajo. La internacionalización, que suele abreviarse como i18n porque hay dieciocho letras entre la primera i y la última n de la palabra en inglés, es el trabajo de preparar la aplicación para que pueda soportar múltiples idiomas y convenciones regionales, sin estar atada a ninguno en concreto. Consiste en decisiones de diseño y desarrollo como sacar todos los textos visibles del código y ponerlos en archivos de traducción separados, no asumir un formato fijo de fecha, número o moneda sino formatearlos según la región del usuario, y diseñar la interfaz de modo que se adapte a textos de distinta longitud y a distintas direcciones de lectura. La internacionalización se hace, idealmente, una sola vez y bien, como una base sobre la que después se puede añadir cualquier idioma. La localización, que se abrevia l10n por las diez letras entre la l y la n, es el trabajo de adaptar esa aplicación ya internacionalizada a un idioma y una región concretos: producir las traducciones a ese idioma, aplicar los formatos de fecha, número y moneda de ese lugar, y ajustar cualquier detalle cultural específico. La localización se realiza una vez por cada idioma y región que se quiera soportar. La relación entre ambas es de dependencia: la localización solo puede hacerse bien si la internacionalización está bien hecha, porque si los textos están incrustados en el código o los formatos están fijados, no habrá manera de adaptarlos por mucha traducción que se haga. Por eso, al probar, conviene verificar tanto que la internacionalización sea sólida, es decir, que la aplicación esté realmente preparada, como que cada localización concreta sea correcta y completa.

Probar idiomas no se limita a revisar que las traducciones estén bien escritas porque la mayoría de los problemas que introduce el soporte de varios idiomas no son de redacción, sino de funcionamiento y de presentación de la aplicación. Aunque comprobar la calidad y corrección de las traducciones es importante, y normalmente lo hacen personas que dominan cada idioma, el testing de localización tiene que ir mucho más allá y verificar que la aplicación siga viéndose y funcionando bien en cada idioma y región. El problema más frecuente y más descuidado es el de la longitud del texto: la misma frase ocupa un espacio muy distinto según el idioma, de modo que una etiqueta, un botón o un título que caben perfectamente en un idioma pueden ser bastante más largos en otro y desbordar su contenedor, cortarse, superponerse con otros elementos o romper por completo el diseño de la pantalla. Otro conjunto de problemas tiene que ver con los formatos regionales: las fechas cambian de orden y de estilo entre regiones, hasta el punto de volverse ambiguas si se muestran solo con números; los números invierten la puntuación de miles y decimales; y las monedas cambian de símbolo, de posición y de número de decimales. A esto se suma que algunos idiomas se escriben y se leen de derecha a izquierda, lo que invierte toda la disposición de la interfaz, y que las reglas gramaticales de plurales y género difieren entre idiomas. Todos estos son problemas que una simple revisión de la calidad del texto traducido no detecta, porque no dependen de si la traducción es buena, sino de si la aplicación está bien preparada para acomodar las particularidades de cada idioma y región. Por eso el testing de idiomas es una actividad técnica y visual además de lingüística, y descuidar esa parte es lo que produce las interfaces rotas o confusas que a veces se ven en versiones mal localizadas.

El texto largo rompe el diseño porque muchas interfaces se diseñan y se prueban inicialmente con un solo idioma, a menudo con textos cortos, y sus contenedores se ajustan a esas longitudes concretas sin dejar suficiente margen para textos más largos. Cuando la misma interfaz se traduce a un idioma en el que las palabras y las frases equivalentes son considerablemente más largas, y hay idiomas en los que ciertas expresiones pueden ocupar bastante más espacio que en otros, el texto traducido ya no cabe en el espacio previsto. Las consecuencias visibles de esto pueden ser de varios tipos: el texto desborda su contenedor y se sale de los límites visuales; se corta abruptamente, dejando palabras incompletas o puntos suspensivos que ocultan información importante; se superpone con otros elementos de la interfaz, volviéndose ilegible; o fuerza a que los elementos se reorganicen de forma que rompe la maquetación de la pantalla, descolocando botones, columnas o tarjetas. Este problema es especialmente insidioso porque no aparece en el idioma original con el que se diseñó y probó, sino solo al cambiar a otros idiomas, por lo que es fácil que pase inadvertido si no se prueba deliberadamente con cada idioma. La solución de fondo está en la fase de internacionalización, diseñando interfaces flexibles que no asuman longitudes fijas y que permitan que los contenedores crezcan o que el texto se ajuste con elegancia. Y la forma de detectarlo durante las pruebas es doble: por un lado, recorrer las pantallas en los idiomas reales buscando desbordes; por otro, y muy eficaz, estresar el diseño usando textos de prueba deliberadamente largos incluso antes de tener las traducciones definitivas, lo que permite descubrir qué elementos no soportan el crecimiento del texto y corregirlos a tiempo. Las pruebas de regresión visual ayudan mucho aquí, porque comparan automáticamente el aspecto de las pantallas entre idiomas y resaltan dónde el diseño se ha alterado.

Las fechas, los números y las monedas son una fuente clásica y peligrosa de problemas en la localización, porque sus convenciones de formato varían mucho entre regiones y, si no se manejan según la región del usuario, producen desde confusión hasta errores graves. En el caso de las fechas, el problema principal es el orden de sus componentes: distintas regiones colocan el día, el mes y el año en órdenes diferentes, de modo que una fecha escrita únicamente con números puede resultar genuinamente ambigua, ya que una misma combinación de dos números puede interpretarse como una fecha en una región y como otra completamente distinta en otra. Esta ambigüedad no es un detalle menor, porque puede llevar a que un usuario entienda una fecha equivocada, con consecuencias reales en reservas, plazos o vencimientos. La solución pasa por mostrar las fechas en un formato claro y adecuado a la región del usuario, o en formatos inequívocos. En el caso de los números, el problema es que la puntuación que separa los miles y los decimales se invierte entre regiones, de modo que el mismo valor numérico se escribe de maneras distintas, y una lectura descuidada puede confundir una cantidad con otra que difiere enormemente. En el caso de las monedas, además de heredar el problema de la puntuación de los números, se suman variaciones en el símbolo de la moneda, en su posición respecto a la cantidad, y en el número de decimales que se usan habitualmente. Todo esto significa que mostrar cantidades y fechas no puede hacerse con un formato fijo incrustado en el código, sino que debe adaptarse a la región de cada usuario, idealmente apoyándose en las herramientas y los datos estandarizados de formateo que existen para ello. Al probar, hay que verificar estos formatos con datos representativos de cada región soportada, comprobando que las fechas no sean ambiguas, que los números se puntúen correctamente y que las monedas se muestren con su símbolo, posición y decimales apropiados, ya que son errores fáciles de pasar por alto pero de impacto potencialmente serio.

Soportar idiomas que se escriben y se leen de derecha a izquierda implica bastante más que traducir el texto, porque cambia por completo la orientación de la interfaz y requiere que la aplicación esté preparada para invertir su disposición. En estos idiomas, la lectura fluye en sentido contrario al de los idiomas de izquierda a derecha, y esa inversión no afecta solo a las palabras, sino a la maquetación entera de la pantalla. Lo que normalmente está a la izquierda pasa a la derecha y viceversa, la alineación del texto se invierte, los elementos de navegación y los menús cambian de lado, ciertos iconos direccionales como las flechas deben apuntar al sentido contrario para conservar su significado, y en general la interfaz se refleja como en un espejo para resultar natural a quien lee en esa dirección. Preparar una aplicación para esto forma parte de la internacionalización, y suele apoyarse en mecanismos que permiten declarar la dirección del contenido y aplicar automáticamente la inversión del diseño, en lugar de tener posiciones fijas incrustadas. A la hora de probar el soporte de estos idiomas, hay que verificar no solo que el texto se muestre correctamente, sino que toda la disposición se haya invertido de forma coherente: que la alineación sea la adecuada, que los elementos estén en el lado correcto, que los iconos direccionales apunten en el sentido apropiado, que la navegación resulte natural, y que no queden elementos descolocados o mezclados por una inversión incompleta. Es un tipo de prueba que se descuida con frecuencia cuando el equipo trabaja habitualmente en idiomas de izquierda a derecha, precisamente porque requiere pensar en un modo de lectura distinto del propio, pero es imprescindible si se quiere ofrecer una experiencia correcta a los usuarios de esos idiomas, y omitirlo produce interfaces que resultan incómodas o confusas para ellos.

Se pueden y se deben detectar muchos problemas de localización incluso antes de disponer de las traducciones reales, gracias a una técnica muy útil que consiste en usar textos de prueba artificiales diseñados para estresar la interfaz, a veces llamada pseudo-localización o pseudo-traducción. La idea es reemplazar temporalmente los textos originales por versiones generadas automáticamente que conservan el sentido reconocible pero que están deliberadamente alargadas y modificadas para simular las condiciones más exigentes que impondrán las traducciones reales. Estos textos de prueba suelen ser bastante más largos que los originales, para reproducir el caso de los idiomas en los que el texto se expande y así descubrir qué botones, etiquetas y contenedores desbordan o rompen el diseño cuando el contenido crece. También pueden incluir caracteres especiales o acentuados para comprobar que la aplicación los muestra correctamente y no los corrompe, y a veces se marcan con símbolos al principio y al final de cada cadena, lo que permite detectar de un vistazo si algún texto quedó cortado o si alguna cadena no fue extraída del código y sigue mostrándose sin sustituir. Este enfoque tiene varias ventajas importantes. Permite empezar a probar la robustez de la interfaz frente a la localización muy temprano en el desarrollo, sin esperar a que el equipo de traducción entregue su trabajo, lo que adelanta la detección de problemas cuando son más baratos de corregir. Ayuda a distinguir los problemas estructurales de la aplicación, como los desbordes de diseño o las cadenas no internacionalizadas, de los problemas propios de la calidad de la traducción, que se evalúan aparte con las traducciones reales. Y hace visibles de forma inmediata los textos que quedaron incrustados en el código sin extraer, porque esos aparecen sin transformar mientras todo lo demás se muestra alterado. Complementada con las pruebas de regresión visual, que comparan el aspecto de las pantallas, esta técnica permite abordar la mayor parte de los problemas técnicos de localización de manera anticipada y sistemática, dejando para más adelante únicamente la verificación de la corrección lingüística de las traducciones definitivas.