Controlli di qualità dei contenuti prodotto

Definisci il contratto di qualità prima della generazione

Scrivi le regole di accettazione per ogni campo. I campi di identità e revisione devono corrispondere alla fonte. Il testo modificabile deve usare il locale richiesto, includere le informazioni necessarie e rispettare il formato di destinazione. Le dichiarazioni richiedono evidenze di supporto. Un singolo esito pass/fail è troppo generico per spiegare quale condizione ha bloccato un prodotto.

Mantieni separati i difetti verificabili dalla macchina e i giudizi editoriali. Testo mancante e deriva degli identificativi possono essere localizzati in modo deterministico. Stabilire se una traduzione esagera un beneficio richiede contesto e una revisione qualificata. Indirizza ogni problema alla persona o al sistema che può risolverlo e mantieni il risultato associato alla revisione del candidato.

Confronta i valori protetti dopo l'assemblaggio

Genera solo i campi testuali consentiti, poi assembla il record candidato usando valori protetti copiati dalla fonte. Esegui un secondo confronto sul record assemblato. Questo rileva errori del mapper oltre a modifiche accidentali introdotte durante la revisione.

L'esempio JavaScript illustrativo si aspetta oggetti con schema validato e valori protetti scalari. Rileva chiavi protette mancanti, extra o cambiate e una revisione della fonte obsoleta, restituendo codici di problema stabili. Esegui validazione di schema e valori prima di questo helper e indirizza poi il candidato strutturalmente valido alla revisione editoriale.

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

Mantieni separata la formattazione dei numeri dai valori

Un numero localizzato può apparire diverso pur rappresentando la stessa quantità memorizzata. MDN documenta Intl.NumberFormat per una presentazione sensibile al locale. Applica la formattazione dopo aver selezionato il valore autorevole; non chiedere a un modello linguistico di ricreare un prezzo da una stringa di valuta formattata.

Definisci le unità insieme ai valori numerici, compresa l'unità appartenente a ogni dimensione. Se la conversione è autorizzata, usa una regola deterministica e conserva la rappresentazione originale. Non confrontare solo le cifre di una frase: due numeri identici con unità diverse possono descrivere prodotti diversi. Le unità mancanti devono bloccare l'approvazione finché la fonte non è risolta.

Valida molteplicità dei placeholder e markup

Usa il parser dei template dell'applicazione per raccogliere i token placeholder dalla fonte e dal candidato. Confronta i conteggi, non solo un insieme di nomi; un token duplicato può rompere una frase o un'applicazione anche quando ogni token originale compare ancora. Mantieni le regole di escaping specifiche del formato al confine della destinazione.

Il piccolo controllo seguente accetta token già estratti. Non tenta una regex universale per i placeholder. Per l'HTML, analizza il frammento del documento e confronta separatamente struttura e link consentiti. Le indicazioni di escaping di WordPress sono rilevanti per il rendering personalizzato, ma l'escaping da solo non dimostra che il contenuto abbia preservato il significato 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: campi validi, formulazione ancora da correggere

Un agente di traduzione configurato esplicitamente per gpt-5.6-luna con ragionamento xhigh ha prodotto 20 patch giapponesi e 20 tedesche da 20 prodotti sintetici. I controlli deterministici di schema, identità e campi protetti sono passati per tutte le 40 righe assemblate. Prezzo, valuta, materiale e dimensioni sono stati copiati dalla fonte; le patch generate potevano modificare solo title e description per lo SKU e il locale identificati.

Anche le patch giapponesi intatte superano il validatore strutturale. La revisione IA ha comunque individuato i due problemi di formulazione qui sotto e ne ha revisionato le descrizioni. Per questo il controllo di un campo materiale protetto non può stabilire che la prosa descriva accuratamente il materiale. Confronta ogni asserzione rilevante con la fonte, anche dopo che tutti i controlli di schema sono verdi.

Testa anche l'export di revisione, oltre all'import

OWASP descrive la formula injection nei fogli di calcolo e osserva che le trasformazioni di sicurezza differiscono tra i consumer. Tratta le celle del fornitore e quelle generate come non attendibili. Usa una policy di serializzazione revisionata per lo strumento effettivo e ispeziona l'artefatto salvato, non solo una tabella in memoria.

Mantieni separati gli import macchina dai file di revisione. Un prefisso aggiunto per una visualizzazione umana sicura non deve cambiare in silenzio un identificativo o una descrizione pubblica durante l'import. Valida codifica, gestione delle virgolette e identità attese delle righe con un parser. Conserva la fonte intatta, così puoi identificare e correggere modifiche introdotte da un editor di fogli di calcolo.

Vincola l'approvazione al candidato esatto

Memorizza una revisione o un hash del candidato insieme all'approvazione fattuale e linguistica. Qualsiasi modifica successiva dovrebbe invalidare l'approvazione pertinente finché non viene revisionata. Il publisher finale deve confrontare anche la revisione corrente della fonte, perché una traduzione invariata può essere obsoleta dopo un cambiamento della specifica prodotto.

Negli artefatti del caso, le patch giapponesi corrette e quelle tedesche vengono assemblate in righe marcate review_status: unreviewed. Entrambi i report conservano translation_semantic_review: pending. La correzione assistita dall'IA è una fase di revisione, non un'approvazione di madrelingua o merchant. Conserva candidati grezzi e revisionati, poi chiedi al revisore appropriato di approvare il testo esatto che entrerebbe nel pacchetto d'import.

Riproduci i controlli e mantieni chiaro il loro ambito

Il test del caso locale esercita preservazione dei campi fonte, SKU duplicato, SKU mancante e override di prezzo vietato. La riassemblatura in sola lettura delle patch giapponesi e tedesche salvate riproduce entrambi gli output validati. Per un catalogo più ampio, aggiungi controlli per la tua grammatica dei placeholder, il markup e la policy di revisione; gli helper illustrativi qui sopra sono esempi separati, non il validatore usato per queste 40 righe.

Questo era un caso locale di traduzione configurato per Luna, senza chiamata Astra o gateway e senza import reale nello store. Lo strumento non ha esposto utilizzo API, request ID o fatturazione; entrambi gli output conservano utilizzo e costo null. Usa il risultato strutturale per passare alla revisione semantica, poi testa separatamente l'adapter autorizzato dello store.

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

Domande frequenti