Pruebas de Localización: Guía Completa para Verificar Software Multilingüe

Pruebas de Localización: Guía Completa para Verificar Software Multilingüe

Puntos Clave

• Las pruebas de localización verifican que tu software funcione correctamente en todos los locales objetivo — no solo que las traducciones sean precisas
• Las categorías de prueba incluyen: lingüísticas, cosméticas/UI, funcionales, específicas de locale y de accesibilidad
• La pseudo-localización detecta problemas de i18n de forma temprana simulando expansión de texto, caracteres especiales y RTL sin traducciones reales
• Las pruebas automatizadas pueden verificar placeholders, longitud de cadenas, corrección de formato y diseño de UI, pero la precisión lingüística requiere revisión humana
• Las pruebas deben realizarse continuamente junto con el desarrollo, no como una fase final antes del lanzamiento

¿Qué son las Pruebas de Localización?

Las pruebas de localización verifican que un producto localizado funcione correctamente para su público objetivo. Va más allá de comprobar si las traducciones son precisas para asegurarse de que toda la experiencia del usuario — diseño de UI, formato, funcionalidad y adecuación cultural — sea correcta para cada locale.

Un error común es pensar que las pruebas de localización son solo corrección de traducciones. En realidad, muchos errores de localización son técnicos: texto truncado, diseños rotos, formatos de fecha incorrectos, enlaces no funcionales o errores de codificación que no tienen nada que ver con la calidad de la traducción.

Categorías de Pruebas

Pruebas Lingüísticas

Verifica que las traducciones sean precisas, naturales y apropiadas para el público objetivo.

Qué verificar:

• Precisión de la traducción (¿transmite el significado correcto?)
• Naturalidad (¿suena como lengua nativa, no como texto traducido?)
• Consistencia terminológica (¿se traduce "Dashboard" de la misma manera en todas partes?)
• Tono y formalidad (¿coincide con la voz del producto para ese mercado?)
• Gramática y ortografía (correctas para el locale — inglés británico vs. americano, portugués brasileño vs. europeo)

Quién lo hace: Hablantes nativos del idioma objetivo, idealmente con conocimiento del dominio.

Pruebas Cosméticas / UI

Verifica que el contenido traducido se muestre correctamente en la interfaz de usuario.

Qué verificar:

Cómo probar: Inspección visual de cada pantalla en cada idioma objetivo. Las herramientas de comparación de capturas de pantalla (Percy, Chromatic) pueden automatizar la detección de cambios de diseño.

Pruebas Funcionales

Verifica que la aplicación funcione correctamente en todos los locales.

Qué verificar:

• El cambio de locale funciona correctamente (cambiar de idioma no pierde el estado)
• Los formularios aceptan entradas específicas del locale (nombres con diacríticos, direcciones en diferentes formatos)
• La búsqueda funciona con caracteres acentuados (buscar "café" encuentra "cafe" y viceversa)
• El ordenamiento sigue reglas específicas del locale (el orden alfabético sueco difiere del inglés)
• Los enlaces y la navegación funcionan en todas las versiones de idioma
• Las entradas de moneda, fecha y número aceptan formatos apropiados para el locale

Pruebas Específicas de Locale

Verifica que las características conscientes del locale funcionen correctamente para cada locale objetivo.

Qué verificar:

Pruebas de Accesibilidad

Verifica que el contenido localizado siga siendo accesible.

Qué verificar:

• Los lectores de pantalla leen correctamente el contenido traducido
• El atributo lang está correctamente establecido en el elemento HTML y en los cambios de idioma en línea
• El contenido RTL está correctamente marcado con dir="rtl"
• El contraste de color se mantiene con texto traducido (diferente longitud puede afectar el diseño)
• La navegación por teclado funciona en todos los locales

Pseudo-Localización

La pseudo-localización es una técnica para encontrar errores de internacionalización antes de que las traducciones reales estén disponibles. Transforma las cadenas fuente de maneras que simulan los desafíos de localización:

Tipos de Pseudo-Localización

Caracteres acentuados: Reemplazar caracteres ASCII con equivalentes acentuados.

• "Settings" → "Šéttîñgš"
• Prueba: Manejo de Unicode, renderizado de fuentes, codificación de caracteres

Expansión de texto: Rellenar cadenas para simular la expansión del 30-40% común en idiomas europeos.

• "Save" → "[Šåvé xxxxxxxxx]"
• Prueba: Flexibilidad del diseño, truncamiento de texto, diseño responsive

Corchetes/marcadores: Envolver cadenas en marcadores visibles para identificar texto no traducido o hardcodeado.

• "Settings" → "[Šéttîñgš]"
• Prueba: Completitud de la externalización de cadenas — cualquier texto sin corchetes está hardcodeado

Simulación RTL: Invertir la dirección del texto para probar el espejado del diseño.

• Prueba: Espejado de UI, manejo de texto bidireccional, CSS logical properties

Cuándo Usar la Pseudo-Localización

• Durante el desarrollo: Activar la pseudo-localización en builds de desarrollo para detectar problemas a medida que se introducen
• Antes de la traducción: Verificar que todas las cadenas estén externalizadas y que la UI maneje la expansión antes de invertir en traducciones reales
• En CI/CD: Agregar un paso de build de pseudo-localización que falle si se detectan cadenas hardcodeadas

// Ejemplo: configuración de pseudo-localización
{
  "pseudoLocale": {
    "enabled": true,
    "strategy": "accented",
    "expansion": 1.35,
    "brackets": true
  }
}

Enfoques de Pruebas Automatizadas

Validación de Placeholders

Verifica que todos los placeholders de las cadenas fuente existan en las traducciones:

// Prueba: Cada {placeholder} en la fuente existe en la traducción
function validatePlaceholders(source, translation) {
  const sourcePlaceholders = source.match(/\{[^}]+\}/g) || [];
  const translationPlaceholders = translation.match(/\{[^}]+\}/g) || [];

  for (const placeholder of sourcePlaceholders) {
    if (!translationPlaceholders.includes(placeholder)) {
      throw new Error(`Placeholder faltante ${placeholder} en la traducción`);
    }
  }
}

Pruebas de Regresión Visual

Usa herramientas como Playwright o Cypress para capturar capturas de pantalla en cada locale y comparar con baselines:

// Playwright: Capturar capturas de pantalla para cada locale
for (const locale of ['en', 'de', 'ja', 'ar']) {
  await page.goto(`https://app.example.com/${locale}/dashboard`);
  await page.screenshot({
    path: `screenshots/${locale}-dashboard.png`,
    fullPage: true,
  });
}

Verificación de Completitud de Traducciones

// Verificar que todas las claves fuente tengan traducciones
function checkCompleteness(sourceKeys, translationKeys, locale) {
  const missing = sourceKeys.filter(key => !translationKeys.includes(key));
  if (missing.length > 0) {
    console.warn(`${locale}: ${missing.length} traducciones faltantes`);
    console.warn('Claves faltantes:', missing.slice(0, 10));
  }
}

Validación de Formato

Verifica que los archivos de traducción sean válidos:

• Los archivos JSON se analizan sin errores
• Los archivos XLIFF son XML bien formado
• Los archivos PO tienen pares msgid/msgstr coincidentes
• No hay claves duplicadas dentro de un archivo

Integración en el Flujo de Trabajo de Pruebas

Durante el Desarrollo

1. Pseudo-localización activada en builds de desarrollo
2. Los desarrolladores ven texto expandido/acentuado y corrigen problemas de diseño inmediatamente
3. Sin dependencia de traductores ni traducciones listas

En CI/CD

1. La validación de placeholders se ejecuta en cada PR
2. La completitud de traducciones se verifica para todos los locales objetivo
3. La validación de formato asegura que los archivos de traducción sean sintácticamente correctos
4. Las pruebas de regresión visual detectan problemas de diseño en locales clave

Antes del Lanzamiento

1. Revisión lingüística completa por hablantes nativos para contenido nuevo o modificado
2. Revisión en contexto en el entorno de staging
3. Pruebas funcionales de características específicas del locale
4. Verificación del diseño RTL para árabe/hebreo
5. Auditoría de accesibilidad para todos los locales

Preguntas Frecuentes

¿Cuánto tiempo debo presupuestar para las pruebas de localización?

Planifica 2-4 horas de revisión lingüística por cada 1,000 palabras por idioma para la revisión humana. Las pruebas funcionales y de UI dependen de la complejidad de la aplicación — presupuesta 1-2 días por locale objetivo para un pase completo. Las comprobaciones automatizadas (placeholders, formato, completitud) se ejecutan en minutos como parte de CI/CD.

¿Puedo automatizar las pruebas lingüísticas?

Parcialmente. Las herramientas automatizadas pueden verificar gramática y ortografía, marcar terminología inconsistente y detectar patrones comunes (puntuación faltante, formalidad incorrecta). Sin embargo, verificar la precisión de la traducción, naturalidad y adecuación cultural requiere hablantes nativos humanos. Automatiza las comprobaciones mecánicas e invierte tiempo humano en la revisión matizada.

¿Cuáles son los errores de localización más comunes?

Basado en la experiencia común de la industria: (1) truncamiento de texto por traducciones más largas, (2) cadenas hardcodeadas que se perdieron durante la externalización, (3) formato incorrecto de fecha/número, (4) diseños rotos en idiomas RTL, (5) placeholders eliminados o duplicados en traducciones, (6) problemas de codificación con caracteres especiales.