Перевірки якості контенту товарів

Визначте контракт якості до генерації

Напишіть правила прийняття для кожного поля. Поля ідентичності та ревізії мають збігатися з джерелом. Редагований текст має використовувати потрібну локаль, містити обов’язкову інформацію та відповідати формату призначення. Твердження потребують підтверджувальних доказів. Одного ярлика пройдено або не пройдено недостатньо, щоб пояснити, яка умова заблокувала товар.

Машиноперевірювані дефекти відокремлюйте від редакційних суджень. Відсутній текст і зміщення ідентифікатора можна локалізувати детерміновано. Чи перебільшує переклад перевагу, потребує контексту та кваліфікованої перевірки. Передавайте кожну проблему людині або системі, яка може її розв’язати, і залишайте результат прив’язаним до ревізії кандидата.

Порівнюйте захищені значення після складання

Генеруйте лише дозволені текстові поля, а потім складіть запис кандидата, використовуючи захищені значення, скопійовані з джерела. Виконайте друге порівняння вже зібраного запису. Це виявляє помилки мапера та випадкові правки під час перевірки.

Ілюстративний приклад JavaScript очікує об’єкти, перевірені схемою, зі скалярними захищеними значеннями. Він виявляє відсутні, зайві або змінені захищені ключі та застарілу ревізію джерела, повертаючи стабільні коди проблем. Перевірку схеми й значень виконуйте до цього помічника, а структурно чинного кандидата після цього передавайте на редакційну перевірку.

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

Зберігайте форматування чисел окремо від значень

Локалізоване число може виглядати інакше, представляючи ту саму збережену кількість. MDN документує Intl.NumberFormat для відображення з урахуванням локалі. Застосовуйте форматування після вибору авторитетного значення; не просіть мовну модель відновлювати ціну з відображеного рядка валюти.

Визначайте одиниці поруч із числовими значеннями, включно з одиницею кожного виміру. Якщо конвертацію дозволено, використовуйте детерміноване правило й зберігайте початкове подання. Не порівнюйте лише цифри в реченні: два однакові числа з різними одиницями можуть описувати різні товари. Відсутні одиниці мають блокувати схвалення до розв’язання джерела.

Перевіряйте кратність заповнювачів і розмітку

Використовуйте парсер шаблонів програми, щоб зібрати токени заповнювачів із джерела та кандидата. Порівнюйте кількість, а не лише множину назв; дубльований токен може зламати речення або програму, навіть коли кожен початковий токен усе ще присутній. Правила екранування конкретного формату залишайте на межі призначення.

Наведена нижче невелика перевірка приймає вже витягнуті токени. Вона не намагається створити універсальний регулярний вираз заповнювача. Для HTML розберіть фрагмент документа й окремо порівняйте дозволену структуру та посилання. Рекомендації WordPress щодо екранування важливі для користувацького рендерингу, але самого екранування недостатньо, щоб довести збереження початкового значення контенту.

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

Кейс: поля чинні, але формулювання потребує виправлення

Агент перекладу, явно налаштований на gpt-5.6-luna з міркуванням xhigh, створив 20 японських і 20 німецьких патчів із 20 синтетичних товарів. Детерміновані перевірки схеми, ідентичності та захищених полів пройшли для всіх 40 зібраних рядків. Ціна, валюта, матеріал і розміри скопійовані з джерела; згенеровані патчі могли змінювати лише title і description для визначених SKU та локалі.

Недоторкані японські патчі також проходять структурний валідатор. Однак перевірка AI виявила наведені нижче два проблемні формулювання та переглянула їхні описи. Саме тому перевірка захищеного поля матеріалу не може встановити, що проза точно описує матеріал. Порівнюйте кожне істотне твердження з джерелом, навіть після того, як усі перевірки схеми стали зеленими.

Перевіряйте експорт перевірки так само, як імпорт

OWASP описує ін’єкцію формул у електронних таблицях і зазначає, що перетворення безпеки відрізняються між споживачами. Розглядайте клітинки постачальника та генерації як недовірені. Використовуйте перевірену політику серіалізації для фактичного інструмента таблиць і перевіряйте збережений артефакт, а не лише таблицю в пам’яті.

Машинні імпорти тримайте окремо від файлів перевірки. Префікс, доданий для безпечного перегляду людиною, не має мовчки змінювати ідентифікатор або публічний опис під час імпорту. Перевіряйте кодування, обробку лапок і очікувані ідентичності рядків парсером. Зберігайте недоторкане джерело, щоб зміни редактора електронної таблиці можна було виявити й виправити.

Прив’яжіть схвалення до точного кандидата

Зберігайте ревізію або хеш кандидата разом із фактичним і мовним схваленням. Будь-яка пізніша правка має недійснити відповідне схвалення до перевірки. Фінальний публікатор також має порівняти поточну ревізію джерела, оскільки незмінений переклад може застаріти після зміни специфікації товару.

В артефактах кейсу виправлені японські та німецькі патчі складаються в рядки з позначкою review_status: unreviewed. Обидва звіти зберігають translation_semantic_review: pending. Виправлення за допомогою AI є кроком ревізії, а не схваленням носія мови або продавця. Зберігайте початкових і переглянутих кандидатів, а потім доручіть відповідному рецензенту схвалити точний текст, який увійде до пакета імпорту.

Відтворюйте перевірки та чітко визначайте їхнє охоплення

Тест локального кейсу перевіряє збереження полів джерела, дубльований SKU, відсутній SKU та заборонене перевизначення ціни. Повторне складання лише для читання збережених японських і німецьких патчів відтворює обидва перевірені результати. Для ширшого каталогу додайте перевірки власної граматики заповнювачів, розмітки та політики ревізій; наведені вище ілюстративні помічники є окремими прикладами, а не валідатором цих 40 рядків.

Це був локальний кейс перекладу з конфігурацією Luna, без виклику Astra або шлюзу та без реального імпорту магазину. Інструмент не надав використання API, ID запитів або платіжних даних; обидва результати зберігають null для використання й вартості. Використайте структурний результат для переходу до семантичної перевірки, а потім окремо протестуйте авторизований адаптер магазину.

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

Поширені запитання