בדיקות איכות לתוכן מוצר

הגדירו חוזה איכות לפני יצירה

כתבו כללי קבלה לכל שדה. שדות זהות ו-revision צריכים להתאים למקור. טקסט שניתן לעריכה צריך להשתמש ב-locale שהתבקש, לכלול מידע נדרש ולכבד את פורמט היעד. טענות זקוקות לראיות תומכות. תווית מעבר או כשל יחידה גסה מדי מכדי להסביר איזה תנאי חסם מוצר.

שמרו פגמים שניתנים לבדיקה מכנית נפרדים משיפוטים עריכתיים. טקסט חסר וסטיית מזהים אפשר למקם באופן דטרמיניסטי. השאלה אם תרגום מגזים בתועלת דורשת הקשר ובדיקה מוסמכת. נתבו כל בעיה לאדם או למערכת שיכולים לפתור אותה ושמרו את התוצאה מחוברת ל-revision המועמד.

השוו ערכים מוגנים לאחר הרכבה

צרו רק שדות טקסט מותרים, ואז הרכיבו את רשומת המועמד באמצעות ערכים מוגנים שהועתקו מהמקור. הריצו השוואה שנייה על הרשומה המורכבת. כך אפשר לתפוס טעויות mapper וגם עריכות מקריות שנעשו במהלך הבדיקה.

דוגמת JavaScript להמחשה מצפה לאובייקטים שעברו אימות סכמה עם ערכים מוגנים scalar. היא מזהה מפתחות מוגנים חסרים, עודפים או שהשתנו ו-revision מקור ישן. הפעילו אימות סכמה וערכים לפני העוזר הזה ונתבו מועמד תקין מבנית לבדיקה עריכתית לאחר מכן.

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 להצגה המותאמת ל-locale. החילו עיצוב לאחר בחירת הערך המוסמך; אל תבקשו ממודל שפה לשחזר מחיר ממחרוזת מטבע מרונדרת.

הגדירו יחידות לצד ערכים מספריים, כולל איזו יחידה שייכת לכל ממד. אם המרה מאושרת, השתמשו בכלל המרה דטרמיניסטי ושמרו את הייצוג המקורי. אל תשוו רק את הספרות במשפט: שני מספרים זהים עם יחידות שונות יכולים לתאר מוצרים שונים. יחידות חסרות צריכות לחסום אישור עד שהמקור ייפתר.

אמתו ריבוי מצייני מקום ו-markup

השתמשו ב-parser התבניות של היישום כדי לאסוף אסימוני מצייני מקום מהמקור ומהמועמד. השוו ספירות, לא רק קבוצת שמות; אסימון כפול יכול לשבור משפט או יישום גם כאשר כל אסימון מקורי עדיין מופיע. שמרו כללי escaping ספציפיים לפורמט בגבול היעד.

הבדיקה הקטנה שלהלן מקבלת אסימונים שכבר חולצו. היא אינה מנסה regex אוניברסלי למצייני מקום. עבור HTML פענחו את מקטע המסמך והשוו מבנה מותר וקישורים בנפרד. הנחיות escaping של WordPress רלוונטיות לרינדור מותאם, אך escaping לבדו אינו מוכיח שהתוכן שמר על משמעותו המיועדת.

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 עם reasoning מסוג xhigh יצר 20 תיקוני יפנית ו-20 תיקוני גרמנית מ-20 מוצרים סינתטיים. בדיקות סכמה, זהות ושדות מוגנים דטרמיניסטיות עברו לכל 40 השורות המורכבות. מחיר, מטבע, חומר ומידות הועתקו מהמקור; תיקונים שנוצרו יכלו לשנות רק title ו-description עבור ה-SKU וה-locale שזוהו.

גם תיקוני היפנית שלא נגעו בהם עוברים את המאמת המבני. עם זאת, בדיקת AI זיהתה את שתי בעיות הניסוח שלהלן ותיקנה את התיאורים שלהן. לכן בדיקת שדה חומר מוגן אינה יכולה לבסס שהפרוזה מתארת את החומר במדויק. השוו כל טענה בעלת השלכה למקור שלה, גם לאחר שכל בדיקת סכמה ירוקה.

בדקו את ייצוא הבדיקה לצד הייבוא

OWASP מתאר formula injection בגיליונות ומציין שטרנספורמציות בטיחות שונות בין צרכנים. התייחסו לתאי ספק ולתאים שנוצרו כאל קלטים לא מהימנים. השתמשו במדיניות serialization שנבדקה עבור כלי הגיליון בפועל ובדקו את ה-artifact שנשמר, לא רק טבלה בזיכרון.

שמרו ייבוא מכני נפרד מקובצי בדיקה. Prefix שנוסף לצפייה אנושית בטוחה לא צריך לשנות בשקט מזהה או תיאור ציבורי במהלך הייבוא. אמתו קידוד, טיפול במרכאות וזהויות שורה צפויות באמצעות parser. שמרו את המקור שלא נגעו בו כדי שאפשר יהיה לזהות ולתקן שינויים שהכניס עורך גיליון.

קשרו אישור למועמד המדויק

שמרו revision או hash של מועמד עם אישור עובדתי ואישור שפה. כל עריכה מאוחרת צריכה לפסול את האישור הרלוונטי עד לבדיקה. המפרסם הסופי חייב להשוות גם את revision המקור הנוכחי, מפני שתרגום שלא השתנה עשוי להיות ישן לאחר שינוי במפרט המוצר.

ב-artifacts של המקרה, תיקוני היפנית המתוקנים ותיקוני הגרמנית מורכבים לשורות שמסומנות review_status: unreviewed. שני הדוחות שומרים translation_semantic_review: pending. תיקון בסיוע AI הוא שלב revision, לא חתימת דובר שפת אם או סוחר. שמרו מועמדים גולמיים ומתוקנים, ואז בקשו מהבודק המתאים לאשר את הטקסט המדויק שייכנס לחבילת ייבוא.

שחזרו את הבדיקות ושמרו על היקפן ברור

הבדיקה של המקרה המקומי מפעילה שמירת שדות מקור, SKU כפול, SKU חסר ועקיפת מחיר אסורה. הרכבה מחדש לקריאה בלבד של תיקוני היפנית והגרמנית השמורים משחזרת את שני הפלטים המאומתים. לקטלוג רחב יותר הוסיפו בדיקות לדקדוק מצייני המקום, markup ומדיניות revisions שלכם; העוזרים להמחשה לעיל הם דוגמאות נפרדות ולא המאמת ששימש ל-40 השורות האלה.

זה היה מקרה תרגום מקומי שהוגדר ל-Luna, ללא קריאת Astra או gateway וללא ייבוא חנות אמיתי. הכלי לא חשף usage של API, מזהי בקשות או חיוב; שני הפלטים שומרים usage ועלות null. השתמשו בתוצאה המבנית כדי לעבור לבדיקה סמנטית, ואז בדקו את מתאם החנות המורשה בנפרד.

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

שאלות נפוצות