Mga quality check ng product content

Tukuyin ang quality contract bago mag-generate

Sumulat ng acceptance rule para sa bawat field. Dapat tumugma ang identity at revision field sa source. Dapat gamitin ng editable text ang hiniling na locale, isama ang kinakailangang impormasyon, at igalang ang destination format. Kailangan ng supporting evidence ang claim. Masyadong malabo ang iisang pass o fail label para ipaliwanag kung aling kondisyon ang nagpahinto sa isang product.

Ihiwalay ang machine-checkable defect sa editorial judgment. Maaaring matukoy nang deterministic ang nawawalang text at identifier drift. Nangangailangan naman ng context at qualified review ang pag-alam kung sobra ang ipinahihiwatig na benefit ng translation. I-route ang bawat issue sa taong o system na kayang lutasin ito at panatilihing nakakabit ang resulta sa candidate revision.

Ihambing ang protected value pagkatapos ng assembly

I-generate lamang ang pinahihintulutang text field, saka buuin ang candidate record gamit ang protected value na kinopya mula sa source. Magpatakbo ng ikalawang comparison sa assembled record. Nahuhuli nito ang mapper mistake pati aksidenteng edit habang review.

Inaasahan ng halimbawang JavaScript ang schema-validated object na may scalar protected value. Tinutukoy nito ang nawawala, dagdag, o nagbagong protected key at stale source revision, at nagbabalik ng stable issue code. Ilagay muna bago ang helper na ito ang schema at value validation, saka i-route ang structurally valid candidate sa editorial review.

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

Ihiwalay ang number formatting sa value

Maaaring magmukhang iba ang localized number habang kumakatawan sa parehong nakaimbak na quantity. Dinodokumento ng MDN ang Intl.NumberFormat para sa locale-aware presentation. Ilapat ang formatting pagkatapos mapili ang authoritative value; huwag hilingin sa language model na buuing muli ang presyo mula sa rendered currency string.

Tukuyin ang unit kasama ng numeric value, kabilang kung aling unit ang nauukol sa bawat dimension. Kung awtorisado ang conversion, gumamit ng deterministic conversion rule at panatilihin ang orihinal na representation. Huwag ihambing ang digit lamang sa isang sentence: maaaring maglarawan ng magkaibang produkto ang dalawang magkaparehong numero na magkaiba ang unit. Dapat humarang sa approval ang nawawalang unit hanggang malutas ang source.

I-validate ang placeholder multiplicity at markup

Gamitin ang template parser ng application upang kolektahin ang placeholder token mula sa source at candidate. Ihambing ang count, hindi set ng pangalan lamang; maaaring makasira ng sentence o application ang duplicate token kahit naroon pa rin ang bawat orihinal na token. Panatilihin ang format-specific escaping rule sa destination boundary.

Tumatanggap ang sumusunod na maliit na check ng na-extract nang token. Hindi nito tinatangkang gumawa ng universal placeholder regular expression. Para sa HTML, i-parse ang document fragment at hiwalay na ihambing ang pinahihintulutang structure at link. May kaugnayan ang escaping guidance ng WordPress para sa custom rendering, ngunit hindi mapatutunayan ng escaping lamang na napanatili ng content ang nilalayong kahulugan.

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

Case: valid ang field ngunit kailangan pa ring itama ang wording

Gumawa ang translation agent na tahasang naka-configure para sa gpt-5.6-luna na may xhigh reasoning ng 20 Japanese at 20 German patch mula sa 20 synthetic product. Pumasa sa lahat ng 40 assembled row ang deterministic schema, identity, at protected-field check. Kinopya mula sa source ang presyo, currency, material, at dimension; title at description lamang para sa tinukoy na SKU at locale ang maaaring baguhin ng generated patch.

Pumapasa rin sa structural validator ang untouched Japanese patch. Gayunman, natukoy ng AI review ang dalawang wording issue sa ibaba at nirebisa ang description. Ito ang dahilan kung bakit hindi napapatunayan ng pag-check sa protected material field na tumpak na inilalarawan ng prose ang material. Ihambing ang bawat consequential assertion sa source, kahit green na ang lahat ng schema check.

Subukan ang review export pati ang import

Inilalarawan ng OWASP ang spreadsheet formula injection at sinasabing magkakaiba ang safety transformation sa bawat consumer. Ituring na untrusted ang supplier at generated cell. Gumamit ng nasuring serialization policy para sa aktuwal na spreadsheet tool at siyasatin ang saved artifact, hindi ang in-memory table lamang.

Ihiwalay ang machine import sa review file. Ang prefix na idinagdag para sa ligtas na human viewing ay hindi dapat tahimik na magbago ng identifier o public description habang nag-i-import. I-validate ang encoding, quote handling, at inaasahang row identity gamit ang parser. Panatilihin ang untouched source upang matukoy at maitama ang pagbabagong ipinakilala ng spreadsheet editor.

I-bind ang approval sa eksaktong candidate

Mag-save ng candidate revision o hash kasama ng factual approval at language approval. Dapat i-invalidate ng anumang kasunod na edit ang kaugnay na approval hanggang masuri ito. Dapat ikumpara rin ng final publisher ang kasalukuyang source revision, dahil maaaring maging stale ang hindi nagbagong translation matapos magbago ang product specification.

Sa case artifact, nag-assemble ang corrected Japanese patch at German patch sa row na may review_status: unreviewed. Parehong pinanatili ng report ang translation_semantic_review: pending. Revision step ang AI-assisted correction, hindi native-speaker o merchant sign-off. Panatilihin ang raw at revised candidate, saka ipa-approve sa angkop na reviewer ang eksaktong text na papasok sa import package.

I-reproduce ang check at gawing malinaw ang sakop nito

Sinusubukan ng test ng lokal na case ang source-field preservation, duplicate SKU, nawawalang SKU, at forbidden price override. Nire-reproduce ng read-only reassembly ng saved Japanese at German patch ang parehong validated output. Para sa mas malawak na catalog, magdagdag ng check para sa sarili mong placeholder grammar, markup, at revision policy; magkakahiwalay na example ang illustrative helper sa itaas, hindi ang validator na ginamit para sa 40 row na ito.

Luna-configured local translation case ito, walang Astra o gateway call at walang totoong store import. Walang API usage, request ID, o billing na inilantad ng tool; nananatiling null ang usage at cost ng parehong output. Gamitin ang structural result para umusad sa semantic review, saka hiwalay na subukan ang awtorisadong store adapter.

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

Mga madalas itanong