En toda aplicación multilenguaje se debería dedicar parte del esfuerzo del testing a los tests de localización. En estos tests se verifican varios componentes, esto hace que la localización se suela dividir en dos partes: la internacionalización (i18n) y la localización (l10n).
La internacionalización hace referencia a los aspectos de lenguaje e interfaz de usuario de nuestra aplicación. Se ha de verificar que no haya componentes hard-coded, o elementos específicos de una región. Normalmente revisaremos todo lo referente a componentes de lenguaje como la gramática, alfabetos o uso de mayúsculas, así como lo referente la user interface, como los mensajes, menús, iconos, imágenes, shortcuts y controles.
Es habitual revisar los componentes de lenguaje mediante un archivo de recursos que contiene todas las strings traducidas en los distintos lenguajes, aunque siempre será necesario hacer un testing en la aplicación real, para poder verificar que no se producen solapamientos de texto ni efectos gráficos no deseados.
Por otra parte, la localización, hace referencia a la verificación de los elementos que tienen un formato que depende de la región, por ejemplo: formatos de fecha, direcciones, unidades de medida o números de teléfono, donde cada país tiene su formato específico.
Son varios los trucos que cada uno emplea para testear la localización de un producto, prácticas como hacer builds especiales con caracteres de más en cada prefijo y sufijo del control son habituales, aunque la práctica más extendida suele ser la verificación “visual”, normalmente acompañada de un traductor nativo, para las correcciones gramaticales y propias del lenguaje.
Este tema que comentas al final sobre las regiones creo que es de suma importancia. No sólo por el tema de formateo de fechas, sino también las franjas horarias que tiene cada país. En muchos casos estos temas se dejan a un lado o no se les da la importancia que realmente tienen. Es aconsejable tener una buena estrategia de pruebas de localización desde etapas tempranas.
En un proyecto en el que trabajé durante un par de años tuvimos muchos problemas con este tema, y estoy seguro que a día de hoy este tema les sigue dando problemas.
Las pruebas de internacionalización y localización son bastante comunes en empresas con proyectos de CallCenter centralizados en un país para atender a toda una red de empresas distribuidas en varios países de diferentes franjas horarias, diferentes idiomas, leyes, etc.
Trabajé en un proyecto de está índole, con resultados bastante satisfactorios. Eso sí, siempre con el apoyo de un equipo (traductor, analista funcional, usuario) del país usuario.
Creo que es importante considerar este soporte para (primero) definir correctamente las pruebas a ejecutar y (segundo) tener la certeza de que los resultados obtenidos son los esperados.
Mi experiencia en cuanto a internalización ha sido muy satisfactoria cuando tuve la oportunidad de usar una herramienta que te permite partir del fichero de recursos original y crear tantos otros como necesites, usando el alfabeto (cirilico, japonés, hebreo, griego, etc.) y el idioma que elijas.
Esta herramienta te muestra string a string, todos los textos y te da la oportunidad de traducirlos a mano o bien crearte automáticamente una pseudo-traducción, que para verificar va más que bien.
Imaginad lo fácil que es detectar palabras en inglés cuando toda la aplicación está en ruso o japonés.
Además descubres cosméticos y problemas de alineación y posicionamiento para lenguajes como el hebreo se escriben de derecha a izquierda.
Definitivamente, te ahorra mucho trabajo y te permite hacer cosas que testeando sólo ‘visualmente’ no podrías.