Papermark 如何用 Lingo.dev 自动化文档本地化

Papermark 是一个开源文档共享平台。当团队决定推进文档本地化时，他们遇到了一个让大多数开发者工具团队都会卡住的问题：在 Next.js 应用里把 i18n 正确跑起来，往往比翻译本身更难。

配置才是真正的难点#

Papermark 创始人 Iuliia Shnai 回忆道：“我几乎试遍了所有自动化包和自制工具。最大的问题甚至都不是翻译本身，而是怎么让 i18n 和我们的应用结构真正配合起来。”

这其实很常见。大多数本地化工具都默认 i18n 基础设施已经搭好。它们负责翻译，却不负责配置、文件结构、MDX 解析，或不同框架下那些各不相同的边界场景。对于一个小团队维护的开源项目来说，把工程时间花在本地化配置上，就是对产品开发的直接挤占。

而 MDX 文件——也就是用 Markdown 编写、同时嵌入 React 组件的文档——又把复杂度抬高了一层。标准 i18n 工具擅长处理 JSON 语言文件和简单字符串；但带有组件插值、frontmatter 和自定义标签的 MDX 内容，需要的是完全不同的处理方式。

改变从哪里开始#

Lingo.dev 创始人 Max 直接联系了 Papermark，并帮助他们完成了 Next.js 项目的配置。这套实现方案解决了团队此前一直卡住的关键边界场景：MDX 文件处理、next-intl 与应用文件结构之间的配合，以及从组件占比较高的文档中提取可翻译字符串。

Shnai 表示：“这套实现处理了很多我们之前根本没想到的边界场景。很明显，他们已经把本地化里的各种复杂问题都考虑得很透，尤其是 MDX 文件——那正是我们特别头疼的一块。”

第一天就完成了 80 个文档页面的翻译。这套本地化引擎接入了 Papermark 的产品术语，并连接到他们的代码仓库，自动处理了整套文档内容。

现在是怎么运作的#

Papermark 的本地化引擎会在每次代码推送时运行。新增文档或更新现有内容时，引擎都会自动翻译这些变更。工程师继续用英文撰写文档；本地化版本则无需任何额外步骤就会自动生成。

这里的关键在于“有状态”。由于这套本地化引擎会在每次请求之间持续保留 Papermark 的产品术语，因此像 “Data Room”、“Link tracking” 和 “NDA flow” 这样的产品专有名词，都能在所有语言里保持一致。无论是第一篇还是第一百篇通过引擎处理的文档页面，用的都是同一套产品词汇。

“翻译后续零工程投入”是可以量化的结果——而更底层的原因在于，本地化不再是一项反复执行的任务，而是成了基础设施的一部分。