เวิร์กโฟลว์ localization ของ product catalog

ตรึง source ก่อนแปล

Export catalog และเก็บ source snapshot ที่แก้ไม่ได้ บันทึก origin เวลา export และ revision หรือ file hash ให้ variant ทุกตัวมี identity ที่เสถียร และตรวจ identifier ที่หายหรือซ้ำก่อนสร้าง language job เก็บ manifest ของคู่ product-locale ที่ตั้งใจประมวลผล

แยกการเตรียม source ออกจาก translation แก้ measurement ที่ขัดกัน unit ที่หาย และ claim ที่ไม่มีหลักฐานกับ product owner ก่อน การ normalize supplier export อาจจำเป็น ให้บันทึกการแก้เหล่านั้นเป็น source change และให้ owner อนุมัติ baseline ที่ได้ก่อนเริ่มงานภาษา

แยก protected fact ออกจาก text ที่แก้ได้

สร้าง protected record สำหรับ SKU, price, currency, unit, variant relationship และค่าปฏิบัติการอื่น สร้างเฉพาะ text patch ตอนประกอบ ให้คัดลอก protected value โดยตรงจาก source แล้วเปรียบเทียบอีกครั้ง เพื่อไม่ให้โมเดลกลายเป็น authority ของ field ที่เห็นเพียงใน context

ทำให้ claim ติดตามได้ด้วย เก็บ approved assertion ที่เชื่อม evidence และสั่ง drafting step ให้ flag สิ่งที่ไม่มีหลักฐาน configuration ต่อไปนี้เป็น illustrative pipeline policy ไม่ใช่ไฟล์ import ที่ Shopify หรือ WooCommerce รับโดยตรง adapter ของคุณต้อง map ให้เข้ากับ destination contract จริง

{
  "identity": ["product_id", "variant_id", "locale"],
  "protected": ["sku", "price_minor", "currency", "unit", "parent_id"],
  "editable": ["title", "description", "care_text"],
  "revisionInputs": ["source", "glossary", "prompt"],
  "releaseRequires": ["field_checks", "fact_review", "language_review"],
  "destinationWrite": "separate_authorization"
}

แนบ glossary และ locale brief

locale brief ควรระบุผู้ชม tone terminology ที่อนุมัติ และกฎการนำเสนอ แยก product concept ออกจาก preferred spelling W3C ITS กำหนด terminology และ translation metadata ที่ช่วยออกแบบระบบ localization ที่สมบูรณ์ขึ้น workflow นี้ใช้ editorial record แบบ versioned ที่เรียบง่ายกว่า

แก้ term ที่กำกวมด้วยตัวอย่างจาก category จริง หาก glossary entry เปลี่ยน ให้ระบุ candidate ที่ได้รับผลกระทบ และตัดสินใจว่าจะ regenerate หรือแก้เฉพาะจุด ผูก locale แต่ละตัวกับ source ที่อนุมัติชุดเดียวกัน อย่าให้ translation version หนึ่งกลายเป็น source ขั้นกลางที่ยังไม่รีวิวให้เวอร์ชันที่เหลือ

เคส local: 20 product กับ 40 language patch

catalog ที่ตรึงไว้ของสินค้า synthetic 20 รายการถูกแปลเป็น Japanese patch 20 รายการและ German patch 20 รายการ โดย translation agent ที่ตั้งค่า gpt-5.6-luna พร้อม xhigh reasoning แต่ละ patch มีเฉพาะ sku, locale, title และ description assembler คัดลอก price, currency, material และ dimensions จาก source.json ดังนั้นการรักษา fact เหล่านี้เป็นคุณสมบัติของ pipeline ไม่ใช่งานคัดลอกที่มอบให้โมเดล

validated-ja.json และ validated-de.json ที่บันทึกไว้มีอย่างละ 20 row และ failures list ว่าง การประกอบซ้ำแบบ read-only ตรงกับ output ที่บันทึกไว้ทั้งสองชุด ใช้รูปแบบนี้กับ batch ของคุณ เก็บ source revision แยกภาษา patch และตรวจ coverage กับ field ที่อนุญาตก่อนประกอบ review package

รัน deterministic check ก่อน editorial review

ตรวจ output schema, allowed field, identifier mapping, source revision, required text และ protected value เปรียบเทียบ placeholder count ด้วย template grammar จริงของ application parse markup แทนการใช้ text substitution ทั่วไปกับ HTML พัก record ที่ malformed ไว้ แทนการขอให้ importer ซ่อม

สำหรับ review file แบบ spreadsheet OWASP อธิบายความเสี่ยง formula injection และการไม่มี CSV transformation ที่ปลอดภัยแบบสากล ใช้ export policy ที่ผ่านการรีวิวสำหรับ spreadsheet tool ที่เลือก และเก็บ artifact นั้นแยกจาก machine import การเติม escape prefix เพื่อการดูโดยมนุษย์ต้องไม่เปลี่ยน SKU ใน store payload โดยไม่ตั้งใจ

ผูกการตัดสินใจรีวิวกับ content revision

ให้ reviewer เห็น source fact, glossary context, candidate และ structured issue แยกการตัดสินใจด้าน fact กับภาษาออกจากกัน บันทึกว่าใครอนุมัติ content และเห็น revision ใด reviewer อาจยอมรับวลีที่แปลแล้ว แต่พัก claim ที่ยังต้องมี evidence record ควรแสดงความแตกต่างนี้

ในเคส local AI review แก้ Japanese DEMO-003 จากข้อความที่สื่อว่าเป็น corrugated cardboard ให้สอดคล้องกับ cardboard backing ใน source และทำให้ DEMO-010 ชัดเจนว่ามือจับรวมมี 2 อัน output เดิมยังอยู่ใน raw-ja.json ทั้งสองภาษาที่ประกอบแล้วมี review_status: unreviewed และ translation_semantic_review: pending อยู่ การแก้เหล่านี้ยังไม่ใช่การอนุมัติจาก native speaker หรือ merchant

ประกอบและตรวจ destination package

เลือก candidate ที่อนุมัติแล้วและ source ยังเป็นปัจจุบัน แล้ว transform เฉพาะ field ที่อนุญาต Shopify translation API ใช้ resource และ digest contract ส่วน WooCommerce deployment ต้องใช้ product mapping และเมื่อมีหลายภาษาให้ใช้ localization layer ที่ตรวจสอบแล้ว generic review package ไม่ใช่ universal store import

ทดสอบ authorized import ขนาดเล็กใน staging บันทึกผล importer อ่าน field เป้าหมายกลับ และตรวจพฤติกรรมของ product กับ locale กระทบยอด product set ที่วางแผนกับผลลัพธ์ที่จัดเก็บ แยก row ที่ล้มเหลวไว้ และเก็บค่าก่อนหน้าเพื่อ reversal ที่จำกัดขอบเขตหากจำเป็น

บันทึกผลลัพธ์และข้อจำกัด

manifest ที่เสร็จควรเชื่อม source, glossary, prompt, candidate, check, approval และ destination result บันทึก usage จริงของทุก attempt เมื่อมีหลักฐาน รวม retry ด้วย เก็บ usage ที่หายและผลรีวิวที่หายเป็น unknown อย่างชัดเจน ไฟล์ที่ parse ได้ไม่ใช่หลักฐานว่า shop ยอมรับ

สำหรับ local case ที่มีขอบเขต model ที่เลือกคือ Luna ไม่ใช่ Astra และไม่มี gateway call หรือ real store import API usage, request ID และ billing ไม่ได้เปิดเผย model_api_usage และ model_api_cost จึงยังเป็น null ไม่ใช่ zero ขั้นตอนถัดไปคือ semantic approval แล้วจึงทดสอบ destination แยกต่างหากโดยได้รับอนุญาต

คำถามที่พบบ่อย