Qualitätsprüfungen für Produktinhalte

Definieren Sie den Qualitätsvertrag vor der Generierung

Schreiben Sie für jedes Feld Abnahmeregeln. Identitäts- und Revisionsfelder sollten mit der Quelle übereinstimmen. Editierbarer Text sollte das angeforderte Locale verwenden, erforderliche Informationen enthalten und das Zielformat einhalten. Aussagen benötigen stützende Belege. Ein einzelnes Bestanden-oder-nicht-bestanden-Label ist zu grob, um zu erklären, welche Bedingung ein Produkt blockiert.

Halten Sie maschinenprüfbare Fehler getrennt von redaktionellen Urteilen. Fehlender Text und Drift von Kennungen können deterministisch lokalisiert werden. Ob eine Übersetzung einen Vorteil übertreibt, erfordert Kontext und qualifizierte Prüfung. Leiten Sie jedes Problem an die Person oder das System weiter, das es lösen kann, und hängen Sie das Ergebnis an die Kandidatenrevision.

Vergleichen Sie geschützte Werte nach dem Zusammenstellen

Generieren Sie nur zulässige Textfelder und stellen Sie anschließend den Kandidatendatensatz mit aus der Quelle kopierten geschützten Werten zusammen. Führen Sie einen zweiten Vergleich an diesem zusammengesetzten Datensatz aus. So erkennen Sie Mapperfehler ebenso wie versehentliche Änderungen während der Prüfung.

Das beispielhafte JavaScript erwartet schema-validierte Objekte mit geschützten Skalarwerten. Es erkennt fehlende, zusätzliche oder geänderte geschützte Schlüssel sowie eine veraltete Quellenrevision und gibt stabile Fehlercodes zurück. Stellen Sie Schema- und Wertvalidierung diesem Helfer voran und leiten Sie einen strukturell gültigen Kandidaten danach zur redaktionellen Prüfung weiter.

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

Halten Sie Zahlenformatierung getrennt von Werten

Eine lokalisierte Zahl kann anders aussehen und dennoch dieselbe gespeicherte Menge darstellen. MDN dokumentiert Intl.NumberFormat für locale-gerechte Darstellung. Wenden Sie Formatierung an, nachdem der maßgebliche Wert ausgewählt wurde. Bitten Sie kein Sprachmodell, einen Preis aus einer dargestellten Währungszeichenfolge neu zu erzeugen.

Definieren Sie Einheiten neben numerischen Werten einschließlich der Zuordnung jeder Einheit zu einer Dimension. Wenn eine Umrechnung autorisiert ist, verwenden Sie eine deterministische Umrechnungsregel und bewahren Sie die ursprüngliche Darstellung auf. Vergleichen Sie nicht nur Ziffern in einem Satz: Zwei identische Zahlen mit verschiedenen Einheiten können unterschiedliche Produkte beschreiben. Fehlende Einheiten sollten die Freigabe blockieren, bis die Quelle geklärt ist.

Validieren Sie Platzhalteranzahl und Markup

Verwenden Sie den Template-Parser der Anwendung, um Platzhalter-Tokens aus Quelle und Kandidat zu sammeln. Vergleichen Sie Anzahl und nicht nur eine Menge von Namen; ein doppeltes Token kann Satz oder Anwendung beschädigen, auch wenn jedes ursprüngliche Token weiterhin vorkommt. Halten Sie formatspezifische Escaping-Regeln an der Zielgrenze.

Der folgende kleine Check akzeptiert bereits extrahierte Tokens. Er versucht keine universelle Platzhalter-Regex. Parsen Sie bei HTML das Dokumentfragment und vergleichen Sie erlaubte Struktur und Links separat. Die Escaping-Hinweise von WordPress sind für benutzerdefiniertes Rendering relevant, aber Escaping allein belegt nicht, dass der Inhalt seine vorgesehene Bedeutung bewahrt.

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

Fall: gültige Felder, Formulierung weiterhin korrekturbedürftig

Ein Übersetzungsagent, der ausdrücklich für gpt-5.6-luna mit xhigh-Reasoning konfiguriert war, erzeugte aus 20 synthetischen Produkten 20 japanische und 20 deutsche Patches. Deterministische Schema-, Identitäts- und Prüfungen geschützter Felder bestanden für alle 40 zusammengesetzten Zeilen. Preis, Währung, Material und Abmessungen wurden aus der Quelle kopiert; generierte Patches konnten nur title und description für die identifizierte SKU und das Locale ändern.

Auch die unangetasteten japanischen Patches bestehen den Strukturvalidator. Die KI-Prüfung identifizierte dennoch die beiden unten stehenden Formulierungsprobleme und überarbeitete die Beschreibungen. Darum kann die Prüfung eines geschützten Materialfelds nicht belegen, dass Prosa das Material korrekt beschreibt. Vergleichen Sie jede wesentliche Aussage mit ihrer Quelle, auch wenn alle Schemachecks grün sind.

Testen Sie auch den Prüfexport und nicht nur den Import

OWASP beschreibt Formel-Injection in Tabellenkalkulationen und weist darauf hin, dass Sicherheitsumwandlungen zwischen Konsumenten variieren. Behandeln Sie Lieferanten- und generierte Zellen als nicht vertrauenswürdig. Verwenden Sie für das tatsächliche Tabellen-Tool eine geprüfte Serialisierungsregel und prüfen Sie das gespeicherte Artefakt und nicht nur eine Tabelle im Speicher.

Halten Sie Maschinenimporte getrennt von Prüfdateien. Ein für sichere menschliche Ansicht hinzugefügtes Präfix darf Kennung oder öffentliche Beschreibung beim Import nicht stillschweigend ändern. Validieren Sie Kodierung, Umgang mit Anführungszeichen und erwartete Zeilenidentitäten mit einem Parser. Bewahren Sie die unangetastete Quelle, damit von einem Tabelleneditor eingeführte Änderungen erkannt und korrigiert werden können.

Binden Sie die Freigabe an den exakten Kandidaten

Speichern Sie Kandidatenrevision oder Hash mit faktischer und sprachlicher Freigabe. Jede spätere Änderung sollte die betroffene Freigabe ungültig machen, bis sie geprüft wurde. Der finale Publisher muss auch die aktuelle Quellenrevision vergleichen, da eine unveränderte Übersetzung nach einer Änderung der Produktspezifikation veraltet sein kann.

In den Fallartefakten werden die korrigierten japanischen Patches und die deutschen Patches zu Zeilen mit review_status: unreviewed zusammengestellt. Beide Berichte behalten translation_semantic_review: pending. KI-gestützte Korrektur ist ein Revisionsschritt und keine Freigabe durch Muttersprachler oder Händler. Bewahren Sie rohe und überarbeitete Kandidaten auf und lassen Sie anschließend die exakte Import-Payload von einem passenden Prüfer freigeben.

Reproduzieren Sie die Checks und halten Sie ihren Umfang klar

Der Test des lokalen Falls prüft Erhalt von Quellfeldern, doppelte SKU, fehlende SKU und eine unzulässige Preisüberschreibung. Die schreibgeschützte erneute Zusammenstellung der gespeicherten japanischen und deutschen Patches reproduziert beide validierten Ausgaben. Für einen größeren Katalog ergänzen Sie Prüfungen für Ihre eigene Platzhaltergrammatik, Markup- und Revisionsrichtlinie; die beispielhaften Helfer oben sind getrennte Beispiele und nicht der für diese 40 Zeilen verwendete Validator.

Dies war ein lokal mit Luna konfigurierter Übersetzungsfall ohne Astra- oder Gateway-Aufruf und ohne echten Shop-Import. Das Tool legte keine API-Nutzung, Anfrage-IDs oder Abrechnung offen; beide Ausgaben behalten null bei Nutzung und Kosten. Verwenden Sie das strukturelle Ergebnis als Übergang zur semantischen Prüfung und testen Sie anschließend den autorisierten Shopadapter separat.

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

Häufige Fragen