语言区域回退可能会掩盖本地化债务

语言区域回退是多语言 CMS 中最有用的安全网之一。

当某个字段在请求的语言区域中没有值时，Contentful 可以返回另一个语言区域中的值。这样页面仍然完整，编辑者可以避免空组件，而市场也能在每个可选字段都完成翻译之前上线。

但完整的页面并不总是本地化后的页面。

回退会改变“缺失”的表现形式

如果没有回退，未翻译的内容非常明显：值是空的。有了回退后，即使目标语言区域本身没有值，字段看起来也像是已填充的。

随着内容经过 API、预览和前端渲染，这一区别可能会消失。翻译仪表板可能看到已解析的英语值，并得出法语字段已经完成的结论。编辑者也可能在审阅一个完整的法语页面时，没有意识到其中几个部分仍然是英语。

回退解决的是交付连续性问题，并不能解决翻译完整性问题。

跟踪值的来源，而不仅仅是值是否存在

一个可靠的本地化视图应当为每个字段回答两个问题：

1. 访客会收到什么值？
2. 这个值由哪个语言区域提供？

第二个答案能揭示该字段是被显式本地化了、通过回退继承而来，还是确实为空。

这种来源信息应当在内容发现和翻译规划过程中保留下来。如果集成过早地把已解析的值扁平化，后续阶段就无法区分翻译后的内容与借用来的内容。

决定在哪些地方可以接受回退

并不是每一个继承来的值都会产生相同的影响。

法律免责声明、结账说明或活动标题，可能要求在上线前必须具有目标语言区域的值。产品代码、内部标签或专有名称，则可能可以安全地继承。团队应当按内容类型和字段来定义策略，而不是套用一个全局的完整性规则。

一个实用的策略可以将字段分类为：

• 在每个已启用语言区域中都必须提供
• 允许暂时回退
• 有意在多个语言区域之间共享
• 排除在本地化之外

这样就能把回退从一种无形的意外，转变为一种编辑决策。

让预览反映真实情况

预览应该是让回退债务变得可见的地方。

渲染后的页面仍然很重要，因为它能暴露布局和上下文，但编辑者还需要一个微妙的覆盖层或报告，用来标记继承来的值。目标不是让预览变得难以阅读，而是要展示哪些看似完整的部分实际上尚未由目标语言区域真正拥有。

当源语言和目标语言看起来很相似，或者一些细小的界面标签很容易被忽略时，这些信息尤其有价值。

在不阻塞每次发布的情况下报告债务

本地化完整性应当与页面可用性分开衡量。

某个市场页面也许 100% 可渲染，但只有 82% 是被显式本地化的。这两个数字都很有用。前者反映运营可用性；后者反映剩余的本地化工作。

这样，团队就可以为关键字段设置发布门槛，同时允许其他地方存在已知的回退债务。报告应列出继承的字段及其存在时长，以免临时例外默认变成永久状态。

保护现有的目标值

回退还可能让写入变得混乱。已解析的源值可能出现在目标字段实际上为空的位置，而显式的目标值则可能被某种预览配置隐藏起来。

在推送翻译之前，应检查原始语言区域映射，而不是已解析的回退响应。只写入预期的目标语言区域，并保留其他每个语言区域的值。

要点

回退是一种交付策略，并不是本地化已完成的证明。

要让每个值都附带其来源语言区域，定义哪些字段可以继承，在预览中揭示回退，并将本地化覆盖率与页面完整性分开报告。只要有意识地使用，回退就能让发布保持韧性，同时避免翻译债务在众目睽睽之下悄然消失。