Comprobaciones de calidad del contenido de producto

Define el contrato de calidad antes de generar

Escribe reglas de aceptación para cada campo. Los campos de identidad y revisión deben coincidir con la fuente. El texto editable debe usar el locale solicitado, incluir la información obligatoria y respetar el formato del destino. Las afirmaciones necesitan evidencia de respaldo. Una única etiqueta de aprobado o fallido es demasiado gruesa para explicar qué condición bloqueó un producto.

Mantén separados los defectos comprobables por máquina de los juicios editoriales. El texto ausente y la desviación de identificadores pueden localizarse de forma determinista. Determinar si una traducción exagera un beneficio requiere contexto y una revisión cualificada. Dirige cada problema a la persona o sistema que pueda resolverlo y mantén el resultado vinculado a la revisión del candidato.

Compara los valores protegidos después de ensamblar

Genera solo los campos de texto permitidos y ensambla después el registro candidato usando los valores protegidos copiados de la fuente. Ejecuta una segunda comparación sobre ese registro ensamblado. Así detectas tanto errores del mapeador como ediciones accidentales realizadas durante la revisión.

El ejemplo de JavaScript ilustrativo espera objetos validados por esquema con valores escalares protegidos. Detecta claves protegidas ausentes, adicionales o modificadas y una revisión de origen obsoleta, y devuelve códigos de problema estables. Coloca la validación del esquema y de los valores antes de esta ayuda, y dirige después el candidato estructuralmente válido a la revisión editorial.

function checkProtected(source, candidate) {
  const issues = [];
  if (candidate.sourceRevision !== source.sourceRevision) {
    issues.push({ code: "STALE_SOURCE", field: "sourceRevision" });
  }
  const keys = new Set([
    ...Object.keys(source.protected),
    ...Object.keys(candidate.protected),
  ]);
  for (const field of keys) {
    const hasSource = Object.prototype.hasOwnProperty.call(source.protected, field);
    const hasCandidate = Object.prototype.hasOwnProperty.call(candidate.protected, field);
    if (!hasSource || !hasCandidate ||
        !Object.is(source.protected[field], candidate.protected[field])) {
      issues.push({ code: "PROTECTED_FIELD_CHANGED", field });
    }
  }
  return issues;
}

Mantén separados el formato de números y los valores

Un número localizado puede verse diferente aunque represente la misma cantidad almacenada. MDN documenta Intl.NumberFormat para la presentación adaptada al locale. Aplica el formato después de seleccionar el valor autoritativo; no pidas a un modelo lingüístico que reconstruya un precio a partir de una cadena de moneda renderizada.

Define las unidades junto a los valores numéricos, incluida la unidad que corresponde a cada dimensión. Si se autoriza una conversión, usa una regla de conversión determinista y conserva la representación original. No compares solo los dígitos de una frase: dos números idénticos con unidades diferentes pueden describir productos distintos. Las unidades ausentes deben bloquear la aprobación hasta resolver la fuente.

Valida la multiplicidad de placeholders y el marcado

Usa el parser de plantillas de la aplicación para recopilar los tokens de placeholders de la fuente y del candidato. Compara las cantidades, no solo un conjunto de nombres; un token duplicado puede romper una frase o una aplicación aunque todos los tokens originales sigan apareciendo. Mantén las reglas de escape específicas del formato en el límite del destino.

La siguiente comprobación pequeña acepta tokens ya extraídos. No intenta crear una expresión regular universal para placeholders. Para HTML, analiza el fragmento de documento y compara por separado la estructura y los enlaces permitidos. La guía de escape de WordPress es relevante para el renderizado personalizado, pero el escape por sí solo no demuestra que el contenido conserve su significado previsto.

function samePlaceholderCounts(sourceTokens, candidateTokens) {
  const counts = new Map();
  for (const token of sourceTokens) {
    counts.set(token, (counts.get(token) ?? 0) + 1);
  }
  for (const token of candidateTokens) {
    if (!counts.has(token)) return false;
    counts.set(token, counts.get(token) - 1);
  }
  return [...counts.values()].every((count) => count === 0);
}

Caso: campos válidos, redacción que aún necesita corrección

Un agente de traducción configurado explícitamente para gpt-5.6-luna con razonamiento xhigh produjo 20 parches en japonés y 20 en alemán a partir de 20 productos sintéticos. Las comprobaciones deterministas de esquema, identidad y campos protegidos pasaron para las 40 filas ensambladas. El precio, la moneda, el material y las dimensiones se copiaron de la fuente; los parches generados solo podían cambiar title y description para el SKU y locale identificados.

Los parches japoneses intactos también superan el validador estructural. Sin embargo, la revisión de IA identificó los dos problemas de redacción de abajo y revisó sus descripciones. Esto explica por qué comprobar un campo protegido de material no puede demostrar que la prosa describa el material con precisión. Compara cada afirmación relevante con su fuente, incluso después de que todas las comprobaciones de esquema estén en verde.

Prueba la exportación de revisión además de la importación

OWASP describe la inyección de fórmulas en hojas de cálculo y señala que las transformaciones de seguridad difieren según el consumidor. Trata las celdas del proveedor y las generadas como entradas no confiables. Usa una política de serialización revisada para la herramienta de hojas de cálculo real e inspecciona el artefacto guardado, no solo una tabla en memoria.

Mantén separadas las importaciones automáticas de las hojas de revisión. Un prefijo añadido para una visualización humana segura no debe cambiar silenciosamente un identificador o una descripción pública durante la importación. Valida la codificación, el tratamiento de comillas y las identidades de fila esperadas con un parser. Conserva la fuente intacta para poder identificar y corregir los cambios introducidos por un editor de hojas de cálculo.

Vincula la aprobación al candidato exacto

Guarda una revisión o hash del candidato junto con la aprobación factual y la lingüística. Cualquier edición posterior debe invalidar la aprobación pertinente hasta revisarla. El publicador final también debe comparar la revisión de origen actual, porque una traducción sin cambios puede quedar obsoleta después de que cambie una especificación del producto.

En los artefactos del caso, los parches japoneses corregidos y los parches alemanes se ensamblan en filas marcadas como review_status: unreviewed. Ambos informes conservan translation_semantic_review: pending. La corrección asistida por IA es un paso de revisión, no la aprobación de un hablante nativo o comerciante. Conserva los candidatos originales y revisados, y pide al revisor adecuado que apruebe el texto exacto que entraría en un paquete de importación.

Reproduce las comprobaciones y mantén claro su alcance

La prueba del caso local ejercita la conservación de campos de origen, el SKU duplicado, el SKU ausente y una sobreescritura de precio prohibida. El reensamblado de solo lectura de los parches japoneses y alemanes guardados reproduce ambas salidas validadas. Para un catálogo más amplio, añade comprobaciones para tu propia gramática de placeholders, marcado y política de revisión; las ayudas ilustrativas anteriores son ejemplos separados, no el validador usado para estas 40 filas.

Este fue un caso local de traducción configurado con Luna, sin llamada a Astra o a un gateway y sin importación real en tienda. La herramienta no expuso uso de API, IDs de solicitud ni facturación; ambas salidas conservan uso y coste como null. Usa el resultado estructural para avanzar a la revisión semántica y prueba después el adaptador autorizado de la tienda por separado.

node --test examples/commerce-localization-case/case.test.mjs

Preguntas frecuentes