Contrôles qualité du contenu produit

Définissez le contrat qualité avant la génération

Écrivez les règles d'acceptation pour chaque champ. Les champs d'identité et de révision doivent correspondre à la source. Le texte modifiable doit utiliser la locale demandée, inclure les informations requises et respecter le format de destination. Les affirmations nécessitent des preuves. Une seule étiquette réussite ou échec est trop grossière pour expliquer quelle condition a bloqué un produit.

Gardez les défauts contrôlables par machine séparés des jugements éditoriaux. Le texte manquant et la dérive d'identifiant peuvent être localisés de manière déterministe. Déterminer si une traduction exagère un bénéfice exige du contexte et une revue qualifiée. Orientez chaque problème vers la personne ou le système capable de le résoudre et gardez le résultat attaché à la révision de la candidate.

Comparez les valeurs protégées après l'assemblage

Générez uniquement les champs textuels autorisés, puis assemblez l'enregistrement candidat à l'aide des valeurs protégées copiées depuis la source. Exécutez une seconde comparaison sur cet enregistrement assemblé. Elle détecte les erreurs de mapping comme les modifications accidentelles survenues pendant la revue.

L'exemple JavaScript illustratif attend des objets validés par schéma avec des valeurs protégées scalaires. Il détecte les clés protégées manquantes, supplémentaires ou modifiées ainsi qu'une révision source obsolète, en renvoyant des codes de problème stables. Placez la validation du schéma et des valeurs avant cet utilitaire et envoyez ensuite une candidate structurellement valide en revue éditoriale.

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;
}

Séparez le formatage des nombres des valeurs

Un nombre localisé peut sembler différent tout en représentant la même quantité stockée. MDN documente Intl.NumberFormat pour une présentation adaptée à la locale. Appliquez le formatage après la sélection de la valeur faisant autorité ; ne demandez pas à un modèle de langage de recréer un prix depuis une chaîne de devise rendue.

Définissez les unités à côté des valeurs numériques, y compris l'unité correspondant à chaque dimension. Si une conversion est autorisée, utilisez une règle déterministe et conservez la représentation originale. Ne comparez pas uniquement les chiffres d'une phrase : deux nombres identiques avec des unités différentes peuvent décrire des produits différents. Les unités manquantes doivent bloquer l'approbation jusqu'à résolution de la source.

Validez la multiplicité des placeholders et le markup

Utilisez le parseur de templates de l'application pour collecter les tokens placeholders de la source et de la candidate. Comparez les occurrences, pas seulement un ensemble de noms ; un token dupliqué peut casser une phrase ou une application même si chaque token original apparaît encore. Conservez les règles d'échappement propres au format à la frontière de destination.

Le petit contrôle suivant accepte des tokens déjà extraits. Il ne tente pas de fournir une expression régulière universelle pour les placeholders. Pour le HTML, analysez le fragment documentaire et comparez séparément la structure et les liens autorisés. Les conseils d'échappement de WordPress sont pertinents pour un rendu personnalisé, mais l'échappement seul ne peut pas prouver que le contenu a conservé son sens prévu.

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);
}

Cas : champs valides, formulation nécessitant encore une correction

Un agent de traduction explicitement configuré pour gpt-5.6-luna avec un raisonnement xhigh a produit 20 patches japonais et 20 patches allemands à partir de 20 produits synthétiques. Les contrôles déterministes du schéma, de l'identité et des champs protégés ont réussi pour les 40 lignes assemblées. Le prix, la devise, le matériau et les dimensions ont été copiés depuis la source ; les patches générés ne pouvaient modifier que title et description pour le SKU et la locale identifiés.

Les patches japonais intacts passent aussi le validateur structurel. La revue IA a néanmoins identifié les deux problèmes de formulation ci-dessous et révisé leurs descriptions. C'est pourquoi le contrôle d'un champ matériau protégé ne peut pas établir que la prose décrit correctement le matériau. Comparez chaque affirmation conséquente à sa source, même après que tous les contrôles de schéma sont au vert.

Testez l'export de revue ainsi que l'import

OWASP décrit l'injection de formules dans les tableurs et indique que les transformations de sécurité diffèrent selon les consommateurs. Traitez les cellules fournisseur et générées comme des entrées non fiables. Utilisez une politique de sérialisation relue pour l'outil tableur réel et inspectez l'artefact sauvegardé, pas seulement une table en mémoire.

Gardez les imports machine séparés des fichiers de revue. Un préfixe ajouté pour une visualisation humaine sûre ne doit pas modifier silencieusement un identifiant ou une description publique pendant l'import. Validez l'encodage, la gestion des guillemets et l'identité attendue des lignes avec un parseur. Conservez la source intacte afin d'identifier et de corriger les changements introduits par un éditeur de tableur.

Liez l'approbation à la candidate exacte

Stockez une révision ou un hash de candidate avec l'approbation factuelle et linguistique. Toute modification ultérieure doit invalider l'approbation concernée jusqu'à sa revue. Le publisher doit aussi comparer la révision source actuelle, car une traduction inchangée peut être obsolète après la modification d'une spécification produit.

Dans les artefacts du cas, les patches japonais corrigés et les patches allemands s'assemblent en lignes marquées review_status: unreviewed. Les deux rapports conservent translation_semantic_review: pending. Une correction assistée par l'IA est une étape de révision, et non une validation par locuteur natif ou marchand. Conservez les candidates brutes et révisées, puis demandez au relecteur approprié d'approuver le texte exact qui entrerait dans un paquet d'import.

Reproduisez les contrôles et clarifiez leur périmètre

Le test du cas local exerce la préservation des champs sources, le SKU en double, le SKU manquant et un remplacement de prix interdit. La ré-assemblage en lecture seule des patches japonais et allemands sauvegardés reproduit les deux sorties validées. Pour un catalogue plus large, ajoutez des contrôles pour votre propre grammaire de placeholders, votre markup et votre politique de révision ; les utilitaires illustratifs ci-dessus sont des exemples séparés, et non le validateur utilisé pour ces 40 lignes.

Il s'agissait d'un cas local de traduction configuré avec Luna, sans appel Astra ou passerelle et sans import réel en boutique. L'outil n'a exposé ni utilisation API, ni IDs de requête, ni facturation ; les deux sorties conservent une utilisation et un coût null. Utilisez le résultat structurel pour passer à la revue sémantique, puis testez séparément l'adaptateur boutique autorisé.

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

Questions fréquentes