Photo by Hans Benn on Pixabay
在全球化技术产品的竞争中，文档的本地化响应速度直接影响用户体验和市场拓展。
传统翻译模式往往需要数月时间，而 AI 翻译技术的成熟，让周级甚至更短周期的多语言支持成为可能。AI 正在改写技术文档本地化的游戏规则。
本文将分享一次 AI 驱动下的技术文档极速本地化实践，借助 AI 翻译引擎+轻量人工校验，平衡效率与质量，在短短数天内为产品文档支持了一种新语言，满足了客户需求。
本文结构如下：
需求场景 解决方案 质量控制 结语
需求场景
随着产品用户量的增长，我们收到了一些关键客户的反馈，希望能给一个产品提供中文文档，以便更好地理解和使用产品。
以往，该产品只提供了英文原版文档和日语机翻文档。对于不熟悉或不擅长英文的用户客户来说，确实存在一定门槛。
我们意识到，这不是一个有时间了再做的需求，而是越快越好的客户诉求。但传统的翻译方式，比如人工翻译 + 审校，不仅成本高，而且周期可能以“月”为单位，难以快速响应和发布上线。
解决方案
几乎没有任何迟疑，在明确需求后，我们立即决定采用 AI 翻译的方式推进中文文档的上线。
紧接着，进行了 AI 翻译测试，发现一些问题。然后，基于文档维护方式，针对两种具体实施方案进行了评估，在权衡效率、质量、未来维护成本之后迅速决策，选定了一种最简单的实施方案（即下面描述的方案一）。
我这里提到的“文档维护方式”是指将中、英文档维护在了两个独立的开源仓库里，是一个历史情况。或者说，多年后，会发现它是个“历史债”，再将中英仓库合并变得很麻烦且耗时耗力，投入产出比不高。
✅ 方案一：将 AI 翻译后的文档内容放在英文文档仓库的独立专用分支上。
优势： 当前可快速发布上线。 当前和未来都易于维护。 劣势： 无法复用原本用中文写的、适用于多个产品的文档。也就是说，即便有些文档起初就是用中文写的，但 AI 依然会基于英文版的文档翻译为中文。
对用户体验的影响是，假如用户在访问中文文档时，查看了不同产品的同一主题（标题）的文档，可能会发现表述上存在略微的差异。
考虑到英文文档往往比中文文档表达更精准（例如有明确的主谓宾），AI 从英文翻译过来的中文质量也不错，也难说比原本的中文就差。有的地方 AI 翻译的更好一点，有的地方原本的中文表述更合适。
这么一看，这个缺点完全可以接受，只是损失了点儿一致性，而且用户查看不同产品的同一文档页面的频率预计也不高。
⛔️ 方案二：将 AI 翻译后的文档内容放在中文文档仓库某个分支的目录下。
优势： 可以复用原本用中文写的、适用于多个产品的文档。当用户查看不同产品的同一主题时，看到的内容完全一致。 劣势： 难以快速发布，上线的周期较长。
需要解决发现的多个问题，有的问题只能手动解决且耗时内容量大。
例如，AI 翻译带来的空行丢失导致 Pull Request 的 CI 检查无法通过；需要检查 AI 翻译的新增文档里涉及的图片文件是否缺失并补全；AI 自动补全的 HTML 或 Markdown 结构导致重复；列表缩进错误等格式问题。
质量控制
AI 翻译并不是一键搞定的“黑箱”，要真正交付可用的文档，还需要人与 AI 协作。
在 AI 翻译完文档内容后，由不同角色审查了预览版的相应文档网站页面，这些角色包括技术文档工程师、前端工程师、客户干系人。我们将反馈的阅读体验和发现的问题进行记录，快速评估、优化和解决。
同时，我们在 AI 翻译的中文文档页面顶部加了个 AI 翻译的提示 banner，并提供了对应的英文原文页面链接。这样，用户可以在有困惑时轻松点击链接查看英文原文的描述。
当然，AI 首次翻译会有一定的局限性，需要后续优化 AI 处理逻辑或人工加以关注。例如，一些格式问题、完善术语对照表等。
结语
AI 翻译不是要完全取代人工，而是通过“规模自动化+人类精准干预”的组合，将文档本地化的周期大幅缩短。真正的敏捷，来自于对工具边界的清醒认知，以及人机协作的流程设计。
文档多语言支持从“重投入、高门槛”转变为“轻量级、快节奏”。现在用一周的时间，就可以完成过去可能需要几个月的工作量。以后如果要为产品文档支持新的语言版本，大概率也会优先考虑 AI 了。
如果你对我提到的 AI 自动翻译的文档效果感兴趣，可访问以下链接：
https://docs.pingcap.com/zh/tidbcloud/
