Những thay đổi​

Quality Gate (5 bước kiểm tra)​

Mỗi bản dịch giờ đây sẽ đi qua năm bước kiểm tra xác thực tất định trước khi được ghi vào ổ đĩa:

1. Empty/blank — Model không trả về gì cả
2. Source echo — Model trả về đầu vào tiếng Anh
3. Hallucination loop — Các mẫu trigram lặp lại
4. Length inflation — Đầu ra dài gấp 4 lần trở lên so với bản gốc
5. Script compliance — Sai hệ thống chữ viết (script) cho locale

Không có bản dịch nào được ghi lại nếu không vượt qua cả năm bước kiểm tra. Các bản dịch thất bại sẽ được ghi log và thử lại.

Retry Cascade​

Khi một batch thất bại, rosetta sẽ thử lại với các batch nhỏ dần:

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

Tăng cường bảo mật​

• Prototype pollution guard — Các key __proto__, constructor bị từ chối tại thời điểm phân tích cú pháp (parse time)
• Path traversal guard — Các mã locale bị thao túng không thể ghi ra ngoài các thư mục đã cấu hình
• Response validation — Chỉ những key đã được gửi đi mới được chấp nhận trả về

Cơ sở hạ tầng kiểm tra​

Prompt Caching​

Các system message hiện đã được tách khỏi user message, cho phép tận dụng prompt cache trên các nhà cung cấp như Anthropic và Google. Điều này giúp giảm đáng kể chi phí token cho các quá trình đồng bộ đa batch.

Xem tài liệu về Quality Gate và tài liệu về Bảo mật để biết đầy đủ chi tiết kỹ thuật.

Dịch thuật nhận biết nội dung​

Khi dịch Markdown, bạn không thể chỉ gửi tệp thô cho một LLM. Các khối mã sẽ bị dịch. Các shortcode sẽ bị hỏng. Các biến mẫu Hugo sẽ bị xáo trộn.

Rosetta v3.1.0 giải quyết vấn đề này bằng cơ chế bảo vệ Unicode sentinel:

1. Trước khi dịch, các khối có cấu trúc (khối mã, shortcode, mã nội tuyến, HTML) được thay thế bằng các token sentinel duy nhất
2. LLM chỉ nhận được văn bản có thể dịch
3. Sau khi dịch, các sentinel được khôi phục lại với nội dung gốc

LLM không bao giờ nhìn thấy các khối mã của bạn. Nó không thể làm hỏng chúng.

Hỗ trợ Front Matter​

Cả dấu phân cách front matter YAML (---) và TOML (+++) đều được hỗ trợ. Theo mặc định, title, description, summary, subtitle, caption, và linkTitle sẽ được dịch. Tất cả các trường khác (date, draft, tags, weight) đều được giữ nguyên.

Thiết lập​

{
  "contentDir": "./content"
}

npx i18n-rosetta sync   # now translates content too

Xem Hướng dẫn dịch nội dung để biết thêm chi tiết.

Những thay đổi​

Các phiên bản trước sử dụng một phương pháp dịch duy nhất cho tất cả các cặp ngôn ngữ. v3.0.0 loại bỏ sự ràng buộc đó: mỗi cặp nguồn→đích có thể sử dụng một phương pháp, mô hình và cấu hình chất lượng khác nhau.

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

Tại sao lại theo từng cặp?​

Kiến trúc này ra đời vì một dự án cần dùng Google Translate cho tiếng Pháp và một pipeline FST được huấn luyện cho một ngôn ngữ bản địa, chạy song song trong cùng một lệnh sync.

Google Translate hỗ trợ ~130 ngôn ngữ. Trên thế giới có hơn 7.000 ngôn ngữ. Hệ thống theo từng cặp đồng nghĩa với việc rosetta có thể mở rộng để hỗ trợ bất kỳ ngôn ngữ nào — bạn chỉ cần một phương pháp hoạt động hiệu quả cho cặp ngôn ngữ đó.

Các điểm nổi bật khác​

• Hệ thống plugin — Cài đặt các phương pháp dịch được đóng gói sẵn từ eval harness
• Config version 3 — Schema mới với khả năng ghi đè ở cấp độ cặp
• Các cấp độ chất lượng — Standard, High, Research, Verified — được hiển thị theo từng cặp trong status

Xem Tài liệu kiến trúc để biết thiết kế của toàn bộ hệ sinh thái.