Why we built l10n
Crowdin/Weblate slowed our feedback loop. We wanted translations that behave like code.
在内容旁边添加 L10N.md 上下文文件。l10n 会追踪它们的依赖关系,当上下文或内容变更时,只有受影响的翻译才会重新生成。
选择一个模型来协调智能体会话,另一个负责精确翻译。支持任何 OpenAI 兼容端点、Vertex AI,或你自己托管的模型。
智能体可以使用内置的语法检查和你定义的自定义命令。每次翻译后它们会运行验证,出错时自动重试,确保输出在你审核之前就已正确。
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 上下文作为记忆来替代它:智能体读取并学习上下文文件,你的团队可以持续迭代这些文件。智能体不是去查找模糊匹配,而是理解你产品的语气、术语和惯例。就像开发者通过编译或 lint 验证代码变更一样,智能体使用你环境中相同的工具来验证翻译。无论在 CI 还是本地运行,智能体都会使用你的 linter、编译器和验证器来修正自己的输出。
是的。l10n 是一个 CLI 工具,不是托管服务。你需要指向任意 OpenAI 兼容端点、Vertex AI,或你自己的模型。成本、数据和质量都由你掌控。
目前,审核者通过 pull request 和 diff 查看翻译内容,需要时可以更新上下文文件来触发重新翻译。未来,我们预期他们会成为流程的一部分,在本地运行 l10n——就像开发者现在使用 Codex 等编码智能体一样。