Kontrole jakości treści produktów

Zdefiniuj kontrakt jakości przed generowaniem

Zapisz reguły akceptacji dla każdego pola. Pola tożsamości i rewizji powinny odpowiadać źródłu. Edytowalny tekst powinien używać żądanego locale, zawierać wymagane informacje i respektować format celu. Twierdzenia potrzebują wspierających dowodów. Pojedyncza etykieta przejścia lub odrzucenia jest zbyt ogólna, aby wyjaśnić, który warunek zablokował produkt.

Wady możliwe do sprawdzenia maszynowo trzymaj osobno od ocen redakcyjnych. Brakujący tekst i przesunięcie identyfikatora można zlokalizować deterministycznie. To, czy tłumaczenie wyolbrzymia korzyść, wymaga kontekstu i kwalifikowanego przeglądu. Każdy problem kieruj do osoby lub systemu, który może go rozwiązać, i utrzymuj wynik przy rewizji kandydata.

Porównuj chronione wartości po złożeniu

Generuj wyłącznie dozwolone pola tekstowe, a następnie złóż rekord kandydata z użyciem chronionych wartości skopiowanych ze źródła. Uruchom drugie porównanie na tym złożonym rekordzie. Wychwytuje ono zarówno błędy mapera, jak i przypadkowe edycje wprowadzone podczas przeglądu.

Przykład JavaScript oczekuje obiektów zweryfikowanych według schematu z chronionymi wartościami skalarnymi. Wykrywa brakujące, dodatkowe lub zmienione chronione klucze oraz nieaktualną rewizję źródła, zwracając stabilne kody problemów. Walidację schematu i wartości umieść przed tym helperem, a strukturalnie poprawnego kandydata skieruj później do przeglądu redakcyjnego.

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

Oddziel formatowanie liczb od wartości

Zlokalizowana liczba może wyglądać inaczej, choć oznacza tę samą zapisaną ilość. MDN dokumentuje Intl.NumberFormat do prezentacji zależnej od locale. Formatuj dopiero po wybraniu autorytatywnej wartości; nie proś modelu językowego o odtworzenie ceny z wyrenderowanego ciągu waluty.

Jednostki definiuj obok wartości liczbowych, także wskazując jednostkę każdej miary. Jeśli konwersja jest autoryzowana, użyj deterministycznej reguły i zachowaj oryginalną reprezentację. Nie porównuj wyłącznie cyfr w zdaniu: dwie identyczne liczby z innymi jednostkami mogą opisywać różne produkty. Brakujące jednostki powinny blokować akceptację do czasu wyjaśnienia źródła.

Waliduj liczność placeholderów i znaczniki

Użyj parsera szablonów aplikacji, aby zebrać tokeny placeholderów ze źródła i kandydata. Porównuj liczności, a nie tylko zbiór nazw; zduplikowany token może zepsuć zdanie lub aplikację, nawet gdy każdy pierwotny token nadal występuje. Reguły ucieczki właściwe dla formatu utrzymuj na granicy celu.

Poniższa mała kontrola przyjmuje już wyodrębnione tokeny. Nie próbuje tworzyć uniwersalnego wyrażenia regularnego dla placeholderów. Dla HTML sparsuj fragment dokumentu i osobno porównaj dozwoloną strukturę oraz linki. Wskazówki WordPress dotyczące ucieczki są istotne przy własnym renderowaniu, ale sama ucieczka nie dowodzi zachowania zamierzonego znaczenia treści.

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

Przypadek: poprawne pola, lecz sformułowanie wymaga korekty

Agent tłumaczeniowy jawnie skonfigurowany dla gpt-5.6-luna z rozumowaniem xhigh utworzył 20 japońskich i 20 niemieckich patchy z 20 syntetycznych produktów. Deterministyczne kontrole schematu, tożsamości i chronionych pól przeszły dla wszystkich 40 złożonych wierszy. Cena, waluta, materiał i wymiary zostały skopiowane ze źródła; wygenerowane patche mogły zmieniać tylko title i description dla wskazanego SKU i locale.

Nienaruszone japońskie patche również przechodzą walidator strukturalny. Mimo to przegląd AI wskazał dwa problemy brzmieniowe poniżej i zmienił ich opisy. Dlatego kontrola chronionego pola materiału nie może dowieść, że proza dokładnie opisuje materiał. Każde istotne twierdzenie porównuj ze źródłem, nawet gdy wszystkie kontrole schematu są zielone.

Testuj eksport przeglądowy tak samo jak import

OWASP opisuje wstrzyknięcie formuł w arkuszach i zauważa, że transformacje bezpieczeństwa różnią się między odbiorcami. Komórki dostawcy i wygenerowane komórki traktuj jak niezaufane. Użyj przejrzanej polityki serializacji dla rzeczywistego narzędzia arkuszowego i przejrzyj zapisany artefakt, a nie tylko tabelę w pamięci.

Importy maszynowe trzymaj osobno od plików przeglądowych. Prefiks dodany do bezpiecznego widoku człowieka nie może po cichu zmienić identyfikatora ani publicznego opisu podczas importu. Waliduj kodowanie, obsługę cudzysłowów i oczekiwane tożsamości wierszy parserem. Zachowaj nietknięte źródło, aby można było wskazać i skorygować zmiany wprowadzone przez edytor arkusza.

Powiąż akceptację z dokładnym kandydatem

Przechowuj rewizję lub hash kandydata wraz z akceptacją faktów i języka. Każda późniejsza edycja powinna unieważniać odpowiednią akceptację do czasu ponownego przeglądu. Końcowy publikujący musi także porównać aktualną rewizję źródła, ponieważ niezmienione tłumaczenie może stać się nieaktualne po zmianie specyfikacji produktu.

W artefaktach przypadku poprawione japońskie patche i niemieckie patche składają się w wiersze oznaczone review_status: unreviewed. Oba raporty zachowują translation_semantic_review: pending. Korekta wsparta przez AI jest krokiem rewizji, a nie akceptacją rodzimego użytkownika języka ani sprzedawcy. Zachowaj kandydatów surowych i poprawionych, a następnie niech właściwy recenzent zaakceptuje dokładny tekst, który trafi do pakietu importu.

Powtarzaj kontrole i jasno zachowaj ich zakres

Test lokalnego przypadku obejmuje zachowanie pól źródłowych, zduplikowane SKU, brakujące SKU i niedozwolone nadpisanie ceny. Ponowne składanie zapisanych patchy japońskich i niemieckich tylko do odczytu odtwarza oba zweryfikowane wyniki. Dla większego katalogu dodaj kontrole własnej gramatyki placeholderów, znaczników i polityki rewizji; powyższe przykładowe helpery są osobnymi przykładami, a nie walidatorem użytym dla tych 40 wierszy.

Był to lokalny przypadek tłumaczenia skonfigurowany dla Luny, bez Astry, wywołania gatewaya i rzeczywistego importu sklepu. Narzędzie nie udostępniło użycia API, identyfikatorów żądań ani rozliczeń; oba wyniki zachowują null dla użycia i kosztu. Użyj wyniku strukturalnego do przejścia do przeglądu semantycznego, a następnie osobno przetestuj autoryzowany adapter sklepu.

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

Częste pytania