Translation QA Tools: Verificaciones de Calidad Automatizadas para Software Localizado

Translation QA Tools: Verificaciones de Calidad Automatizadas para Software Localizado

Conclusiones Clave

• La Translation QA automatizada detecta errores mecánicos (marcadores de posición faltantes, formato roto, terminología inconsistente) que los humanos suelen pasar por alto
• La QA debe ejecutarse en múltiples etapas: durante la traducción, antes de la revisión, antes del merge y antes del deployment
• La mayoría de las plataformas TMS incluyen verificaciones QA básicas, pero las herramientas QA dedicadas ofrecen un análisis más profundo
• Las pruebas de regresión visual detectan problemas de UI causados por el texto traducido (truncamiento, desbordamiento, problemas de layout)
• Un enfoque QA por capas — verificaciones mecánicas automatizadas + revisión lingüística humana — proporciona el mejor equilibrio calidad/costo

Por Qué Importa la Translation QA

Un solo marcador de posición faltante en una traducción puede hacer que su aplicación falle. Un término inconsistente puede confundir a los usuarios. Una etiqueta truncada puede inutilizar un botón. La Translation QA evita que estos problemas lleguen a producción.

Defectos de traducción comunes por categoría:

Tipos de Verificaciones QA Automatizadas

Validación de Marcadores de Posición

La verificación automatizada más crítica. Verifica que todas las variables, marcadores de posición y tokens de interpolación del string fuente existan en la traducción.

Qué verificar:

• Variables ICU: {name}, {count}
• Etiquetas HTML: <strong>, <a href="...">
• Especificadores de formato: %s, %d, %@
• Tokens personalizados: {{variable}}, $t(key)

Implementación:

function validatePlaceholders(sourceStr, translatedStr) {
  const pattern = /\{[^}]+\}|<[^>]+>|%[sd@]|\$t\([^)]+\)/g;
  const sourceTokens = (sourceStr.match(pattern) || []).sort();
  const translatedTokens = (translatedStr.match(pattern) || []).sort();

  const missing = sourceTokens.filter(t => !translatedTokens.includes(t));
  const extra = translatedTokens.filter(t => !sourceTokens.includes(t));

  return { valid: missing.length === 0, missing, extra };
}

Cumplimiento de Terminología

Verifica que los términos del glosario se traduzcan de forma consistente:

• El término fuente "Dashboard" siempre debe traducirse como "Tableau de bord" (francés), nunca como "Panneau"
• Los nombres de marca deben permanecer sin traducir
• Los términos técnicos deben usar la traducción aprobada

Validación de Longitud de Strings

Marca traducciones significativamente más largas que el texto fuente:

• Strings que superan la longitud fuente en más de un umbral configurable (p. ej., 150%)
• Strings más largas que un límite de caracteres (para elementos UI de ancho fijo)
• Traducciones vacías (el string está en blanco cuando la fuente no lo está)

Validación de Formato

Garantiza que los archivos de traducción sean sintácticamente válidos:

• JSON: JSON válido, sin comas finales, codificación correcta
• XLIFF: XML bien formado, espacio de nombres correcto
• PO: Pares msgid/msgstr coincidentes, formas plurales válidas
• Properties: Escape correcto para caracteres especiales

Verificación de Consistencia

Identifica casos donde el mismo texto fuente tiene múltiples traducciones diferentes, o donde textos fuente similares tienen traducciones inconsistentes.

Puntuación y Espacios en Blanco

• Espacios dobles en traducciones
• Puntuación final faltante (la fuente tiene punto, la traducción no)
• Comillas incorrectas para el locale objetivo (el francés usa « » no " ")
• Espacios en blanco iniciales/finales

QA en Su Flujo de Trabajo

Durante la Traducción (In-TMS)

La mayoría de las plataformas TMS ejecutan QA en tiempo real mientras trabajan los traductores:

• Resaltar marcadores de posición faltantes inmediatamente
• Advertir sobre violaciones al glosario
• Mostrar comparación de longitud entre fuente y traducción

Esto detecta problemas en el punto de creación, cuando son más baratos de corregir.

Antes de la Revisión

Ejecutar QA completa antes de que las traducciones entren a la etapa de revisión:

• Validación completa de marcadores en todos los strings
• Verificación de cumplimiento de terminología
• Análisis de consistencia
• Validación de longitud

Las traducciones que no superen las verificaciones críticas (marcadores faltantes) deben bloquearse para su revisión hasta que se corrijan.

Antes del Merge (CI/CD)

Agregar verificaciones QA a su pipeline CI/CD:

# Ejemplo de GitHub Actions
- name: Validate translations
  run: |
    npx translation-qa validate \
      --source src/locales/en.json \
      --translations "src/locales/*.json" \
      --checks placeholders,format,length \
      --max-length-ratio 1.5

Las verificaciones fallidas deben bloquear el merge del PR.

Antes del Deployment

Verificación final antes de que las traducciones lleguen a producción:

• Todos los locales cumplen el umbral mínimo de completitud
• No quedan problemas QA críticos abiertos
• Las pruebas de regresión visual pasan

Pruebas de Regresión Visual

La QA basada en texto detecta problemas de datos, pero las pruebas visuales detectan problemas de UI:

Qué Detectan las Pruebas Visuales

• Desbordamiento de texto por traducciones más largas
• Etiquetas truncadas en contenedores de ancho fijo
• Elementos desalineados por diferentes longitudes de texto
• Problemas de layout RTL
• Problemas de renderizado de fuentes con caracteres especiales

Implementación con Playwright

const locales = ['en', 'de', 'ja', 'ar'];
const pages = ['/dashboard', '/settings', '/profile'];

for (const locale of locales) {
  for (const page of pages) {
    await browser.goto(`/${locale}${page}`);
    await browser.screenshot({
      path: `visual-qa/${locale}${page.replace('/', '-')}.png`,
    });
  }
}

Compare capturas de pantalla con imágenes de referencia para detectar cambios de layout. Herramientas como Percy, Chromatic o la comparación visual integrada de Playwright manejan esto automáticamente.

Herramientas QA Dedicadas

Para equipos que necesitan un análisis más profundo que las verificaciones integradas del TMS:

Estas herramientas son más relevantes para flujos de trabajo empresariales con altos requisitos de calidad y grandes volúmenes de traducción.

Construyendo una Pipeline QA

Un enfoque práctico y por capas:

Capa 1 — Automatizada (Cada Traducción):

• Validación de marcadores de posición
• Validación de formato
• Verificaciones de longitud
• Cumplimiento de terminología

Capa 2 — Revisión (Contenido de Cara al Cliente):

• Revisión lingüística humana para precisión y naturalidad
• Revisión en contexto en entorno de staging

Capa 3 — Visual (Antes del Release):

• Comparación de capturas de pantalla para páginas e idiomas clave
• Verificación de layout RTL
• Verificación de diseño responsivo con contenido traducido

Capa 4 — Monitoreo (Post-Deployment):

• Problemas de traducción reportados por usuarios
• Seguimiento de errores para errores en tiempo de ejecución relacionados con traducciones
• Analytics para tasas de rebote específicas por locale o tickets de soporte

FAQ

¿Cuál es la QA mínima que todo equipo debería tener?

Como mínimo: validación de marcadores de posición y validación de formato en su pipeline CI/CD. Estas dos verificaciones previenen los problemas más impactantes — fallos en tiempo de ejecución por variables faltantes y fallos de build por archivos de traducción inválidos. Son fáciles de implementar y detectan problemas antes de que lleguen a los usuarios.

¿Cómo manejo la QA para idiomas que no hablo?

La QA automatizada maneja verificaciones mecánicas independientemente del conocimiento del idioma. Para la calidad lingüística, necesita hablantes nativos — ya sean revisores internos, revisores freelance encontrados en mercados de traductores, o servicios de revisión ofrecidos por su proveedor de TMS. Concentre el presupuesto de revisión humana en sus mercados de mayor prioridad y niveles de contenido.

¿Debería la QA bloquear el deployment?

Las verificaciones críticas (marcadores de posición faltantes, formato de archivo inválido) deben bloquear el deployment — estos causan errores en tiempo de ejecución o fallos de build. Las verificaciones no críticas (advertencias de longitud, sugerencias de terminología, notas de consistencia) deben generar advertencias pero no bloquear. Configure su pipeline CI/CD con niveles de severidad apropiados para cada tipo de verificación.