Respuesta.

La primera ola de automatización de pruebas prácticamente no se ocupó de la verificación de la localización (i18n), ya que los principales mercados estaban orientados a una interfaz en inglés. Sin embargo, a medida que las aplicaciones se globalizaron, los requisitos de calidad de localización aumentaron: la interfaz debe mostrarse correctamente en todos los idiomas soportados y los recursos textuales y las cadenas formateadas deben cargarse correctamente en función de la configuración regional elegida.

El problema principal es que la verificación manual es muy costosa y las pruebas automáticas son complejas debido a la variabilidad del formato, el contexto y las particularidades de los idiomas (por ejemplo, de derecha a izquierda o características gramaticales). Puede haber ausencia de traducción de fragmentos, errores de formato y violaciones de diseño.

Las soluciones incluyen trabajar con datos de prueba para cada configuración regional, utilizar pruebas de instantáneas, comparar elementos de la interfaz de usuario con estándares, implementar utilidades de verificación basadas en el principio "clave-valor" para archivos de recursos, extracción automatizada y comparación de cadenas a través de interfaces API y ejecución regular de linters en archivos de recursos.

Características clave:

Verificación de la existencia y visualización correcta de todos los idiomas soportados.
Comparación de traducciones de referencia con la visualización actual en la interfaz.
Validadores de longitud y formato de textos para evitar violaciones de diseño.

Preguntas capciosas.

¿Se puede hacer una prueba universal que valide cualquier localización con un solo script?

En parte sí, pero las particularidades de los idiomas (casos, género, dirección de entrada) a menudo requieren ajustes manuales o condiciones adicionales en tales pruebas. La universalidad al 100% no es posible.

Si el archivo de traducción existe y se carga con éxito, ¿significa esto que la prueba de i18n ha pasado?

No. El archivo puede estar incorrectamente vinculado del lado de la aplicación, puede haber un error en la clave, el contexto de uso de la traducción puede estar comprometido, pueden existir caracteres especiales no considerados, etc.

¿Tiene sentido automatizar la prueba de localización para idiomas con < 1% de usuarios?

Sí, si la criticidad empresarial incluso de un solo usuario es alta, por ejemplo, al cumplir obligaciones contractuales o para mercados con requisitos especiales. La automatización ahorra recursos en comparación con las verificaciones manuales.

Errores típicos y anti-patrones

Comprobar solo la existencia del archivo, y no la visualización real en la interfaz.
Comparación rígida de cadenas sin tener en cuenta las particularidades gramaticales y del formato del idioma.
Copia ciega de la prueba de una localización a otras sin adaptación.

Ejemplo de la vida real

Caso negativo

El equipo implementó pruebas automáticas para comparar claves en un archivo .po con el texto original en inglés, creyendo que con eso era suficiente. No se escribieron pruebas de interfaz de usuario, y en el lanzamiento de la versión árabe, se descubrió que todo el texto se había desplazado fuera de los botones, y algunas cadenas no se traducían en absoluto debido a claves incorrectas.

Ventajas:

Implementación rápida de la automatización para i18n.

Desventajas:

Bajo nivel de cobertura de escenarios de usuarios reales.
Errores importantes de UX quedaron sin ser detectados.

Caso positivo

Se implementó una asociación de linting de recursos y pruebas automáticas, que exploraron la interfaz en todos los idiomas, tomaron capturas de pantalla y las compararon con el diseño de referencia. Al detectar la mezcla de elementos RTL/LTR, el equipo encontró la causa raíz y la solucionó antes del lanzamiento.