کنترل‌های کیفیت محتوای محصول

پیش از تولید قرارداد کیفیت را تعریف کنید

برای هر فیلد قواعد پذیرش بنویسید. فیلدهای هویت و revision باید با منبع مطابقت داشته باشند. متن قابل‌ویرایش باید locale خواسته‌شده را داشته باشد، اطلاعات لازم را شامل شود و قالب مقصد را رعایت کند. ادعاها به شواهد پشتیبان نیاز دارند. یک برچسب واحد قبول یا رد برای توضیح اینکه کدام شرط محصول را متوقف کرده کافی نیست.

عیب‌های قابل‌بررسی ماشینی را از قضاوت‌های ویراستاری جدا نگه دارید. متن مفقود و انحراف شناسه را می‌توان قطعی و محلی تشخیص داد. اینکه ترجمه مزیتی را بیش‌ازحد بیان می‌کند به زمینه و بازبینی واجدشرایط نیاز دارد. هر مسئله را به شخص یا سامانه‌ای بفرستید که می‌تواند آن را حل کند و نتیجه را به revision نامزد متصل نگه دارید.

مقادیر محافظت‌شده را پس از assemble مقایسه کنید

فقط فیلدهای متنی مجاز را تولید و سپس رکورد نامزد را با مقادیر محافظت‌شده کپی‌شده از منبع assemble کنید. روی رکورد assembled مقایسه دوم اجرا کنید. این کار هم اشتباه mapper و هم ویرایش تصادفی حین بازبینی را می‌گیرد.

نمونه JavaScript نمونه objectهای اعتبارسنجی‌شده از نظر schema را با مقدارهای scalar محافظت‌شده انتظار دارد. کلید محافظت‌شده مفقود، اضافی یا تغییرکرده و revision منبع قدیمی را با کدهای پایدار مسئله تشخیص می‌دهد. اعتبارسنجی schema و مقدار را پیش از این helper بگذارید و نامزد ساختاری معتبر را بعداً به بازبینی ویراستاری بفرستید.

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 برای نمایش وابسته به locale، Intl.NumberFormat را مستند می‌کند. قالب‌بندی را پس از انتخاب مقدار معتبر انجام دهید و از مدل زبانی نخواهید قیمت را از رشته ارز renderشده بازسازی کند.

واحدها را کنار مقدارهای عددی، از جمله واحد هر بُعد، تعریف کنید. اگر تبدیل مجاز است، قاعده تبدیل قطعی را به‌کار ببرید و نمایش اصلی را نگه دارید. فقط رقم‌های جمله را مقایسه نکنید: دو عدد یکسان با واحدهای متفاوت می‌توانند محصولات متفاوتی را توصیف کنند. واحد مفقود باید تا حل منبع تأیید را متوقف کند.

تعداد placeholder و markup را اعتبارسنجی کنید

از parser template برنامه برای جمع‌آوری tokenهای placeholder از منبع و نامزد استفاده کنید. تعداد را مقایسه کنید، نه فقط مجموعه نام‌ها را؛ token تکراری می‌تواند جمله یا برنامه را خراب کند حتی وقتی همه tokenهای اصلی هنوز ظاهر می‌شوند. قواعد escape ویژه قالب را در مرز مقصد نگه دارید.

کنترل کوچک زیر tokenهای ازقبل‌استخراج‌شده را می‌پذیرد. تلاش نمی‌کند یک regular expression عمومی placeholder بسازد. برای HTML، fragment سند را parse و ساختار و پیوندهای مجاز را جدا مقایسه کنید. راهنمای escape WordPress برای render سفارشی مرتبط است، اما escape به‌تنهایی حفظ معنای موردنظر محتوا را ثابت نمی‌کند.

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 patch ژاپنی و 20 patch آلمانی ساخت. کنترل قطعی schema، هویت و فیلد محافظت‌شده برای همه 40 ردیف assembled موفق بود. قیمت، ارز، ماده و ابعاد از منبع کپی شدند؛ patchهای تولیدشده فقط می‌توانستند title و description مربوط به SKU و locale شناسایی‌شده را تغییر دهند.

patchهای ژاپنی دست‌نخورده هم validator ساختاری را پشت سر می‌گذارند. بااین‌حال بازبینی AI دو مسئله عبارت‌بندی زیر را پیدا و توضیح‌هایشان را اصلاح کرد. به همین دلیل کنترل فیلد محافظت‌شده ماده ثابت نمی‌کند نثر ماده را درست توصیف می‌کند. هر ادعای مهم را با منبع مقایسه کنید، حتی وقتی همه کنترل‌های schema سبز هستند.

خروجی بازبینی را در کنار import آزمایش کنید

OWASP تزریق formula در spreadsheet را توضیح می‌دهد و می‌گوید تبدیل‌های ایمنی بین مصرف‌کننده‌ها متفاوت است. سلول‌های تأمین‌کننده و تولیدشده را نامطمئن بدانید. برای ابزار spreadsheet واقعی policy serialization بازبینی‌شده داشته و artifact ذخیره‌شده را بررسی کنید، نه فقط جدول داخل حافظه را.

import ماشین را از فایل بازبینی جدا نگه دارید. prefix افزوده‌شده برای نمایش انسانی نباید هنگام import بی‌صدا شناسه یا توضیح عمومی را تغییر دهد. encoding، quote handling و هویت ردیف مورد انتظار را با parser اعتبارسنجی کنید. منبع دست‌نخورده را نگه دارید تا تغییرهای editor spreadsheet قابل‌شناسایی و اصلاح باشند.

تأیید را به نامزد دقیق ببندید

revision یا hash نامزد را همراه تأیید واقعی و زبانی ذخیره کنید. هر ویرایش بعدی باید تا بازبینی دوباره تأیید مربوط را نامعتبر کند. publisher نهایی باید revision جاری منبع را هم مقایسه کند، چون پس از تغییر مشخصات محصول ترجمه بدون تغییر ممکن است قدیمی شده باشد.

در artifactهای مورد، patchهای اصلاح‌شده ژاپنی و patchهای آلمانی به ردیف‌هایی با review_status: unreviewed assemble می‌شوند. هر دو گزارش translation_semantic_review: pending را حفظ می‌کنند. اصلاح با کمک AI مرحله بازنگری است، نه تأیید گویشور بومی یا تاجر. نامزد خام و اصلاح‌شده را حفظ و سپس از بازبین مناسب بخواهید دقیقاً متنی را تأیید کند که وارد بسته import می‌شود.

کنترل‌ها را بازتولید و دامنه‌شان را روشن نگه دارید

آزمون مورد محلی حفظ فیلد منبع، SKU تکراری، SKU مفقود و override قیمت ممنوع را اجرا می‌کند. بازسازی فقط‌خواندنی patchهای ژاپنی و آلمانی ذخیره‌شده هر دو خروجی اعتبارسنجی‌شده را بازتولید می‌کند. برای کاتالوگ بزرگ‌تر کنترل‌های grammar placeholder، markup و policy revision خود را اضافه کنید؛ helperهای نمونه بالا مثال‌های جدا هستند و validator این 40 ردیف نیستند.

این مورد ترجمه محلی با پیکربندی Luna بود؛ هیچ Astra یا gateway call و هیچ import واقعی فروشگاه وجود نداشت. ابزار مصرف API، ID درخواست یا صورتحساب نشان نداد؛ هر دو خروجی usage و cost تهی را نگه می‌دارند. از نتیجه ساختاری به بازبینی معنایی بروید و سپس آداپتور مجاز فروشگاه را جدا آزمایش کنید.

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

پرسش‌های پرتکرار