无头CMS能够满足工程部门的需求。一个内容源同时为网站、应用程序和所有其他渠道提供内容。而且,版本是通过 API 而不是发布队列来发布的。
遗憾的是,这种解耦使得本地化更加困难。译者失去了他们所依赖的页面级上下文,工程师们被拉入手动导出和导入的循环中,曾经只需一天就能完成的翻译交接,现在却会阻碍发布长达一周。
这些结果都不是不可避免的。通过正确的架构决策,可以解决无头CMS本地化问题。
本指南将逐步介绍如何通过 CMS API 实现翻译流程自动化,并恢复译员丢失的上下文,以便在初始集成后本地化能够自动运行,不再需要将开发人员、译员和发布计划拉入手动交接。
无头CMS本地化有何不同之处
内容和呈现方式是分离的,这意味着译者通常无法参考单个渲染页面。在设计模型中清晰易懂的字符串在原始内容字段中却显得含糊不清,布局中预设的字符长度假设也无法在文本中体现。
内容模型可在各个渠道重复使用。存储在 CMS 中的 CTA 字符串在运行时会在主页面、卡片和模态框中呈现,这意味着一个条目必须在翻译人员永远看不到的三种视觉环境中都有效。
发布是持续的、API驱动的,而不是批量发布的,因此翻译必须与你的发布节奏保持同步,而不是作为一个单独的项目运行。每周在 15 个市场推出新产品并不适合手动操作。
如果没有正确的设置,无头本地化就会失效。
手动导出和导入是第一个容易出错的地方。工程师编写脚本拉取内容,发送文件进行翻译,然后按语言、按版本将结果推送回去。每一步都需要工程设计,而且每次内容模型发生变化时,脚本都会出错。
第二个问题是缺乏上下文。翻译人员只能根据短字符串或组件字段进行工作,无法看到文本的渲染效果,这导致错误只有在发布后才会出现,而此时的修复方法是紧急修复而不是字符串编辑。
同步延迟是第三个问题。CMS 中的内容更改不会自动传播到翻译工作流程中,因此不同市场的暂存和生产环境会脱节。最终,有人注意到德国网站的版本比德国网站晚了一个版本。
无头CMS的灵活性对工程人员来说极具吸引力,但这恰恰是手动翻译过程的弊端所在。
构建自动化无头定位流程
该修复方案包含四个部分。基于 API 的连接器可自动同步内容,视觉上下文捕获可为翻译人员提供解耦架构所剥离的内容,持续本地化工作流程可在内容发布后立即对其进行路由,工作流程自动化可将每种内容类型分配到正确的审核级别。每一项都是只需做一次的集成决策。
基于 API 的连接器
连接器可以检测 CMS 中的新增或更改内容,将其发送进行翻译,并将翻译完成的内容写回,而无需导出或导入步骤。您只需在 CMS 层集成一次,之后每次发布都会通过同一管道进行,而无需为每个市场触发新一轮的文件交接。
Smartling 保持 为超过 50 个平台预构建的连接器包括 Contentful、Contentstack 和 Sanity 等无头 CMS 选项。
对于自定义内容管理系统或不受支持的系统, Smartling 的 REST API 处理授权、提交和交付,提供 Java、Python 和 PHP 的 SDK 以及用于文件管理的 CLI。文件、字符串和作业端点直接映射到手动管道脚本的操作,从而缩短了迁移路径。
Lyft 通过 Smartling 的 Contentful 集成进行翻译,几乎消除了本地化过程中的所有人工工作。这就是我们应该努力达到的模式。一旦连接器拥有了内容同步功能,添加语言就只是配置更改,而不是重新设计项目。
视觉上下文捕获
无头内容没有自然的页面可供预览,因此上下文捕获在这里比在传统 CMS 中更为重要。上下文工具会记录组件或字符串的实际渲染方式,因此翻译人员不会从字段名称推断含义。
捕获方法取决于前端的渲染方式。Smartling 支持 CMS 预览 API、JavaScript 上下文捕获库、静态 HTML 上传、屏幕截图和 Chrome 扩展程序,捕获的预览显示在翻译人员工作的 CAT 工具内部。
将捕获视为初始整合的一部分。将上下文捕获库连接到暂存构建是一个很小的、一次性的任务,它可以避免翻译人员在之后的每个作业中都根据字段名称重建页面。
对于短字符串来说,上下文最为重要。如果没有它,按钮、标签和行动号召最容易出错,因为两个单词的字符串根据其呈现位置的不同而具有不同的含义。
渲染预览还可以缩短审核周期,因为错误会在翻译过程中被捕获,此时修复方法是更改字符串而不是回滚。
连续本地化工作流程
持续本地化会在内容发布或更新时自动将其路由到翻译服务器,因此翻译作为后台进程与开发并行运行,而不是在发布前设置门槛。
在 Smartling 中, 工作岗位自动化规则 将内容分组到任务中,应用目标语言,并授权工作,而无需任何人每次发布都重新构建流程。
Coinbase 通过持续翻译而不是批量翻译,并通过 Contentful 集成和存储库连接器运行程序,在不到两个月的时间内将内容部署为 21 种语言。
Coinbase 也认为集中式术语表至关重要,因为只有当术语层与内容保持同步时,持续本地化才能奏效。
工作流自动化和路由
并非所有内容类型都应该受到同等对待。 工作流自动化 将新增或变更的内容路由到正确的层级,无论 AI 翻译根据内容类型和适用于整个平台的相同管理规则,进行 AI 人工翻译 (AIHT) 或全人工审核。
动态工作流程 在运行时评估字符串属性并自动分支,因此低风险字符串会通过自动化 AI 路径,而高可见性或受监管的内容则会路由到人工验证,无需对每个字符串进行人工分类。
Netskope一家企业安全公司通过以下方式路由大量内容 Smartling 的人工智能中心 将周转时间缩短约 95%,同时一年内节省数十万美元。
这种精细化的路由方式是多渠道内容可持续发展的关键。产品描述、宣传横幅和监管披露都进入同一个流程,并通过各自相应的翻译层级输出。
手动无头定位与自动化流程
两种方法都能生成翻译内容,但在对工程而言重要的各个方面,操作特性却截然不同。
|
因素 |
手动无头定位 |
自动化管道 |
|---|---|---|
|
内容同步 |
每个版本手动导出/导入 |
通过 API 连接器自动检测 |
|
译者背景 |
不相连的字段,没有视觉参考 |
已渲染内容的预览截图 |
|
拓展至新市场 |
每次都有新的脚本和流程 |
同样的流程也适用于新的语言 |
|
工程管理费用 |
持续进行,与每次发布相关 |
前期集成 |
|
出版时间到了 |
通过人工翻译交接 |
与开发并行进行 |
如果没有自动化流程会发生什么?
工程师成了翻译的瓶颈。本应用于产品开发的时间却被用于文件进出口,而且团队拓展的市场越多,这个比例就越糟糕。
由于手动同步步骤遗漏或延迟,内容会在不同市场之间发生漂移。测试环境和生产环境不再匹配,解决方法是对所有受影响的内容类型进行手动协调。
由于团队等待本应与开发同步进行的翻译交接,导致产品发布延期。无头 CMS 原本是为了加快发布速度,但现在每次发布都要经过一个与部署的代码无关的转换周期。
如果没有自动化,一旦涉及到本地化,无头 CMS 的速度优势就会消失。
按照您现有的发布方式,对无头内容进行本地化。
无头CMS本地化遵循与任何管道问题相同的模式。在 CMS 层集成一次,在源头捕获上下文,然后让路由规则处理其余部分。
首先 Smartling 的 API 文档 将文件、字符串和作业端点映射到您的内容模型,并在编写一行自定义代码之前,看看 CMS 的预构建连接器能为您带来多大的功能。
关于无头CMS本地化的常见问题