Why we built l10n
Crowdin/Weblate slowed our feedback loop. We wanted translations that behave like code.
在你的內容旁新增 L10N.md 脈絡檔案。l10n 會追蹤它們的依賴關係,當脈絡或內容變更時,只有受影響的翻譯會重新產生。
選擇一個模型來協調 agentic 工作階段,另一個模型來精準翻譯。可使用任何 OpenAI 相容的端點、Vertex AI,或你自己託管的模型。
Agent 可存取內建的語法檢查和你定義的自訂命令。它們在每次翻譯後執行驗證,遇到錯誤時重試,確保輸出在你審閱前就是正確的。
Agents use tools to automate verification after every translation.
Parse output to ensure it is valid before it is saved.
Guarantee critical tokens survive translation.
Bring your own validators with check_cmd and check_cmds.
Tool failures trigger retries until the output is valid.
在 TOML frontmatter 中定義翻譯來源、目標和輸出模式。
+++
[[translate]]
source = "site/src/_data/home.json"
targets = ["es", "de", "ko", "ja", "zh-Hans", "zh-Hant"]
output = "site/src/_data/i18n/{lang}/{basename}.{ext}"
+++
# Context for the translating agent...
翻譯、驗證,並追蹤需要更新的內容。
使用 --force 來重新翻譯所有內容。
當來源內容或上層 L10N.md 脈絡變更時,翻譯會自動更新。
JSON、YAML 和 PO 語法檢查,加上可選的外部 lint 命令。
分離的協調器和翻譯器模型,驗證錯誤時自動重試。
快速產生草稿,需要時再審閱,一切保存在 Git 中。
翻譯不必在第一天就完美。就像程式碼一樣,它們透過迭代來改進。
LLM 的初稿在結構上是正確的,但可能在語感、語調或領域特定表達上有所不足。這是刻意的設計。每個審閱週期 — 一條 pull request 評論、一次脈絡檔案更新、一處術語表修正 — 都會回饋到下一次翻譯執行中。品質透過多次迭代逐步收斂,而非一步到位。
LLM 基於你的脈絡檔案產生結構有效的初始版本。
團隊透過 pull request 標記問題,就像程式碼審閱一樣。
更新的脈絡和術語表修正回饋到下一次執行,縮小差距。
每個週期縮短與生產品質的距離。系統逐漸學習你產品的表達風格。
這遵循與製造業中的改善(Kaizen)、專業翻譯中的譯後編輯(PEMT)以及工程學中的逐次逼近相同的原則:從一個足夠好的基準線開始,透過將人類判斷納入迴圈來系統性地改進。
傳統工具依賴翻譯記憶庫,即透過相似度比對的過往翻譯靜態資料庫。l10n 將其替換為 LLM 脈絡即記憶:agent 讀取並學習的脈絡檔案,你的團隊可以隨時間迭代。Agent 不是查找模糊比對,而是理解你產品的語調、術語和慣例。就像開發者透過編譯或 lint 驗證程式碼變更一樣,agent 使用你環境中相同的工具來驗證翻譯。無論在 CI 或本地執行,agent 都會使用你的 linter、編譯器和驗證器來修正自己的輸出。
是的。l10n 是一個 CLI 工具,不是託管服務。你可以將它指向任何 OpenAI 相容的端點、Vertex AI,或你自己的模型。成本、資料和品質由你掌控。
目前,審閱者透過 pull request 和 diff 檢查翻譯內容,並可更新脈絡檔案以在需要時強制重新翻譯。未來,我們預期他們會成為流程的一部分,在本地執行 l10n,就像開發者已經在使用 Codex 等程式碼 agent 一樣。