สิ่งที่เปลี่ยนแปลง​

Quality Gate (การตรวจสอบ 5 ขั้นตอน)​

ขณะนี้การแปลทุกครั้งจะผ่านการตรวจสอบความถูกต้องที่กำหนดไว้ 5 ขั้นตอนก่อนที่จะถูกบันทึกลงดิสก์:

1. Empty/blank — โมเดลไม่ส่งค่าใดๆ กลับมา
2. Source echo — โมเดลส่งคืนข้อมูลภาษาอังกฤษที่เป็นต้นฉบับ
3. Hallucination loop — รูปแบบ trigram ที่ซ้ำซ้อนกัน
4. Length inflation — ผลลัพธ์มีความยาวมากกว่าต้นฉบับ 4 เท่าขึ้นไป
5. Script compliance — สคริปต์ไม่ถูกต้องสำหรับ locale นั้นๆ

จะไม่มีการบันทึกคำแปลใดๆ หากไม่ผ่านการตรวจสอบทั้ง 5 ขั้นตอนนี้ คำแปลที่ไม่ผ่านจะถูกบันทึกใน log และทำการลองใหม่ (retry)

Retry Cascade​

เมื่อ batch เกิดข้อผิดพลาด rosetta จะทำการลองใหม่โดยลดขนาด batch ลงเรื่อยๆ:

Full batch (30 keys) → parse error
  └→ Half batch (15 keys) → 2 failures
      └→ Individual keys (1 each) → isolates the problem keys

การยกระดับความปลอดภัย​

• Prototype pollution guard — คีย์ __proto__, constructor จะถูกปฏิเสธในขั้นตอนการ parse
• Path traversal guard — รหัส locale ที่ถูกสร้างขึ้นมาเพื่อโจมตีจะไม่สามารถเขียนข้อมูลออกนอกไดเรกทอรีที่กำหนดไว้ได้
• Response validation — ยอมรับเฉพาะคีย์ที่ถูกส่งไปเท่านั้นเมื่อได้รับข้อมูลกลับมา

โครงสร้างพื้นฐานการทดสอบ​

Prompt Caching​

ขณะนี้ข้อความระบบ (System messages) ถูกแยกออกจากข้อความผู้ใช้ (User messages) แล้ว ซึ่งช่วยให้สามารถใช้งาน prompt cache hits บนผู้ให้บริการอย่าง Anthropic และ Google ได้ สิ่งนี้ช่วยลดต้นทุน token สำหรับการซิงค์แบบหลาย batch (multi-batch syncs) ได้อย่างมาก

ดูรายละเอียดทางเทคนิคฉบับเต็มได้ที่ เอกสาร Quality Gate และ เอกสาร Security

การแปลแบบ Content-Aware​

เมื่อแปล Markdown คุณไม่สามารถส่งไฟล์ดิบไปยัง LLM ได้โดยตรง เนื่องจาก code blocks จะถูกแปล shortcodes จะเสียหาย และ Hugo template variables จะผิดเพี้ยนไป

Rosetta v3.1.0 แก้ปัญหานี้ด้วย Unicode sentinel shielding:

1. ก่อนการแปล structured blocks (code fences, shortcodes, inline code, HTML) จะถูกแทนที่ด้วย sentinel tokens ที่ไม่ซ้ำกัน
2. LLM จะได้รับเฉพาะข้อความที่สามารถแปลได้เท่านั้น
3. หลังจากการแปล sentinels จะถูกกู้คืนกลับเป็นเนื้อหาต้นฉบับ

LLM จะไม่เห็น code blocks ของคุณเลย จึงไม่สามารถทำให้ข้อมูลเหล่านั้นเสียหายได้

การรองรับ Front Matter​

รองรับ delimiters ของ front matter ทั้งแบบ YAML (---) และ TOML (+++) โดยค่าเริ่มต้น title, description, summary, subtitle, caption และ linkTitle จะถูกแปล ส่วนฟิลด์อื่นๆ ทั้งหมด (date, draft, tags, weight) จะถูกคงไว้ตามเดิม

การตั้งค่า​

{
  "contentDir": "./content"
}

npx i18n-rosetta sync   # now translates content too

ดูรายละเอียดเพิ่มเติมได้ที่ คู่มือ Content Translation

สิ่งที่เปลี่ยนแปลง​

เวอร์ชันก่อนหน้านี้ใช้วิธีการแปลแบบเดียวสำหรับทุกคู่ภาษา v3.0.0 ได้ยกเลิกข้อจำกัดดังกล่าว: แต่ละคู่ source→target สามารถใช้วิธีการ โมเดล และการตั้งค่าคุณภาพที่แตกต่างกันได้

{
  "version": 3,
  "pairs": {
    "en:fr": { "method": "google-translate" },
    "en:ja": { "method": "llm", "model": "google/gemini-2.5-pro" },
    "en:crk": { "methodPlugin": "crk-coached-v1" }
  }
}

ทำไมต้องเป็น Per-Pair?​

สถาปัตยกรรมนี้ถูกสร้างขึ้นเนื่องจากมีโปรเจกต์หนึ่งที่ต้องการใช้ Google Translate สำหรับภาษาฝรั่งเศส และ coached FST pipeline สำหรับภาษาชนพื้นเมือง ซึ่งทำงานควบคู่กันในคำสั่ง sync เดียวกัน

Google Translate รองรับประมาณ 130 ภาษา แต่บนโลกนี้มีมากกว่า 7,000 ภาษา ระบบ per-pair หมายความว่า rosetta สามารถขยายการรองรับไปสู่ภาษาใดก็ได้ — คุณเพียงแค่ต้องมีวิธีการที่เหมาะสมสำหรับคู่ภาษานั้น

ไฮไลต์อื่นๆ​

• Plugin system — ติดตั้งวิธีการแปลแบบ pre-packaged จาก eval harness
• Config version 3 — schema ใหม่ที่รองรับการแทนที่ค่า (overrides) ในระดับคู่ภาษา
• Quality tiers — Standard, High, Research, Verified — แสดงผลแยกตามคู่ภาษาใน status

ดู Architecture docs สำหรับรายละเอียดการออกแบบ ecosystem ทั้งหมด