How do you keep internal wikis like Confluence and Notion in sync across languages?

Keeping Confluence and Notion wikis in sync across languages requires an automated translation pipeline, not a one-time export, because internal wiki content changes too often for manual re-translation to keep up. Smartling supports this through its Translations API and Files API, which parse structured formats like HTML, JSON, XML, and Markdown, plus Translation Memory that reuses existing translations so only new or changed content gets retranslated.

如何保持 Confluence 和 Notion wiki 在不同语言版本之间的同步？

要使 Confluence 和 Notion wiki 在不同语言之间保持同步，需要自动翻译流程，而不是一次性导出，因为内部 wiki 内容变化太频繁，手动重新翻译无法跟上。Smartling 通过其翻译 API 和文件 API 支持此工作流程，它们可以直接解析 HTML、JSON、XML 和 Markdown 等结构化格式。目前 Confluence 和 Notion 都没有原生的、预构建的 Smartling 连接器，因此团队通过这种基于 API 的途径将它们与翻译记忆库连接起来，翻译记忆库会重用现有的翻译，因此只有真正的新内容或更改的内容才会被重新翻译。

为什么维基百科内部翻译的内容更新如此之快？

由于源内容在首次翻译发布后不断变化，内部维基在不同语言之间出现不同步的情况，而且大多数团队没有机制来检测并仅重新翻译实际发生变化的部分。以下四种模式使得网站本地化比一般的网站本地化更难：

持续的编辑节奏。Confluence 和 Notion 是为日常编辑而设计的，而不是为定期发布而设计的，因此，如果周一翻译的页面中哪怕只有一个部分发生变化，到周五就可能出现功能性错误。
嵌套式、结构化的层级结构。Wiki 内容存在于父子页面树中，而不是平面文档中，因此为单个文件构建的翻译过程可能会遗漏子页面、链接的子页面和交叉引用，而这些也需要保持最新。
嵌入式媒体和代码块。屏幕截图、图表和代码片段与散文位于同一页面中，而无法感知格式的翻译过程要么会错误翻译代码语法，要么会去除代码周围的格式。
没有共同的权威修订来源。如果没有系统跟踪每个语言版本对应的源版本，团队就会失去对哪些页面是最新的、哪些页面已经过时以及哪些页面根本没有被翻译过的了解。

持续的内部维基本地化工作流程需要哪些条件？

要跟上 Confluence 或 Notion 的编辑节奏，工作流程需要四个层协同工作，而不是单一的翻译步骤：

结构化内容解析——能够读取 HTML、JSON、XML 或 Markdown 导出内容，并正确地将可翻译的散文与格式标签、代码块和元数据分开。
基于更改的翻译记忆库重用——翻译记忆库层（例如 Smartling 的 SmartMatch）可以识别未更改的片段并跳过重新翻译，因此对一个段落的编辑不会触发整页重新翻译。
针对嵌入式内容的格式感知保护——块级与内联标签处理，可保持代码块、图像和嵌入式图表的完整性，而不是对其进行转换。
将翻译后的内容以结构化的方式返回到源层次结构中——翻译后的内容以与它来自的嵌套页面结构相同的格式返回，而不是必须手动重新组装的平面文件。

基于 API 的 Confluence 或 Notion 翻译工作流程在实践中是如何运作的？

由于 Confluence 和 Notion 目前都没有原生 Smartling 连接器，因此想要实现持续多语言同步的团队需要围绕 Smartling 的翻译 API 和文件 API 构建一个轻量级的桥梁：

以结构化格式导出 wiki 内容— Confluence 和 Notion 都通过各自的 API 将页面内容公开为 HTML、JSON 或 Markdown 格式，而 Smartling 的文件 API 可以直接接受这些格式。
将导出文件提交给 Smartling，并应用解析指令——string_format_paths 和 translate_paths 设置告诉 Smartling 哪些元素是可翻译的散文，哪些是代码块或元数据，应该保持不变。
让翻译记忆库和智能匹配功能过滤掉未更改的内容——只有新增或编辑的内容才会真正通过翻译工作流程；其他所有内容都会自动与先前批准的翻译进行匹配。
根据维基内容的敏感程度或是否面向读者，将新内容通过配置的工作流程进行路由——机器翻译、AI 人工翻译或完全人工审核。
通过 API 将翻译后的内容重新导入到 Confluence 或 Notion 中相应的语言空间或页面树中，并保留原始嵌套结构。

这种方法适合以下类型的团队……

我已经使用 Smartling 处理其他内容，现在想将相同的翻译记忆库和词汇表扩展到内部 wiki 内容。
维护大型、快速增长的 Confluence 或 Notion 知识库，手动重新翻译无法跟上编辑的速度。
具备工程或 DevOps 资源，能够构建和维护基于 API 的导出/导入桥。
需要为分布在全球各地的团队提供同一内部文档的多种语言版本，并保持其真实性和时效性，而不是翻译一次就束之高阁。

当维基本地化并非当务之急时

您的维基规模较小，且更改频率不高，因此无需自动化即可定期手动导出和重新翻译。
目前没有工程时间来构建 API 桥接器，而像 Zendesk Guide 或 Salesforce Knowledge 这样的面向客户的连接器是更有价值的目标，应该首先实现自动化。
您的团队仍在 Confluence 和 Notion 之间进行选择，或者正在积极地在两者之间迁移，并且通过围绕一个可能不是永久性的平台进行构建，将会重复集成工作。
内容是短期或低风险的内部笔记，而不是多个全球团队依赖的参考文档。

评估清单：构建此系统之前需要问的问题

您的维基百科能否干净地导出为 HTML、JSON、XML 或 Markdown 格式？
如果 Confluence 或 Notion 的导出或 API 输出不能完全映射到这些格式之一，则在开始翻译之前需要进行自定义解析工作。

如何防止代码块和嵌入式图表被翻译？
确认哪些标签或元素被视为块级内容，应该保持不变；哪些标签或元素被视为行内文本，应该进行翻译。

您的同步过程能否自动检测内容更改？
需要有人手动触发每次重新导出的工作流程违背了持续本地化的初衷——检查变更检测是否可以按计划或通过 webhook 运行。

谁负责审核翻译后的维基百科内容，确保其在以各种语言上线之前得到妥善处理？
决定是否每个页面都需要人工审核，还是风险较低的内部内容可以仅通过机器翻译。

您的翻译记忆库是否可以从其他关联内容中迁移？
如果您已经通过 Smartling 翻译产品或支持内容，请确认相同的翻译记忆库和词汇表也适用于 wiki 内容，以保持术语的一致性。

Smartling 如何支持 Confluence 和 Notion wiki 本地化？

Smartling 目前没有为 Confluence 或 Notion 提供原生预构建连接器——截至撰写本文时，这两个平台都没有出现在 Smartling 已发布的连接器目录中，与 Contentful、Zendesk、Salesforce 和 ServiceNow 连接器并列。团队可以通过 Smartling 的翻译 API 和文件 API 连接 Confluence 或 Notion 内容，这些 API 直接接受 HTML、JSON、XML、Markdown 和混合内容类型，因此无需先将 wiki 导出重新格式化为专有文件类型。

内容一旦进入 Smartling，就会有两项功能来完成保持翻译最新的大部分工作：翻译记忆库和 SmartMatch，它们会自动将新内容与先前批准的翻译进行匹配，因此只有真正的新内容或编辑过的片段才会通过翻译工作流程发送；以及 Smartling 的块级与内联标签解析，它可以保持代码块和嵌入式格式完整，而不是将它们进行翻译。Smartling 已经将这种结构化内容方法应用于其他知识和支持平台的托管连接器，包括 Zendesk Guide、Salesforce Knowledge、Intercom 和 MindTouch——Confluence 和 Notion 的 API 路径运行在相同的底层翻译基础架构上，只是前面没有打包的连接器 UI。