TMS 是瓶颈：为什么翻译仍然感觉很难

发布日期被圈定，源文案到位，一切看起来都在掌控中。然后翻译需求发出，日程就开始被拉长。等到审批落地，冲刺周期已经继续往前了。翻译失败并不是因为团队粗心。失败是因为工作流在步骤之间持续流失时间。

真正的工作藏在步骤之间

我们看到一个小型 Contentful 团队把该做的都做对了。他们发布了英文内容，导出了字符串，写了细致的需求说明，然后等待。一周后修改返回了，但一半上下文已经丢失。传统 TMS 交接会把内容背后的故事剥离掉，于是译者在黑暗中工作，再把猜测结果发回 CMS。团队修补缺口、对齐字符串，然后再次开始循环。每一次交接都说得过去。这个循环却不行。

时间泄漏就发生在这里。不是发生在翻译这个动作本身，而是发生在工具之间那些安静的缝隙里：等待、返工、本不该存在的第二版需求。这些缝隙在时间线上看不见，却塑造了每一次发布。

可预期的结果就是：发布延迟、本地化不完整、每进入一个新市场都像是在申请增加人手。

为什么它比应该的更难

这个团队不需要投入更多努力。他们需要的是让工作更贴近内容所在的位置。

• 内容一离开 CMS，上下文就会淡化。
• 当责任归属散落在邮件线程里，审核就会变慢。
• 批量工作被跳过，于是团队一次只翻译一个页面。
• 品牌语调会漂移，因为反馈回路太长。

每一项看起来都可控。真正沉重的是累积效应。这里快速核对一次供应商，那里更新一次表格，再来一轮审批，突然之间团队就盯着一个无法自信全球发布的版本。

这与人才无关。这是工作流设计问题。每一个额外步骤都会叠加阻力。

当翻译变得简单，会发生什么变化

想象同一个团队在六个月后。他们打开条目，就地翻译，在上下文中审核，然后发布。突然之间，全球发布变成了发布周期中很正常的一部分。速度只是解锁的一部分。更大的收益是信心。

差异不只在工具。更在于姿态。团队不再围绕翻译来规划，而是围绕他们想讲述的故事来规划。他们可以在一个地方看到完整页面、完整活动和完整市场 rollout。

这就是我们通过 Inverb 追求的标准：一种和最初撰写源内容一样干净利落的工作流。

当前的循环增加交接。Inverb 的循环把翻译留在 CMS 内部。

接下来是什么

接下来的几周里，我们会分享那套我们曾经希望拥有的工作流——当时我们正用小团队和紧张时间线发布全球内容。如果这个故事让你感到熟悉，我们很想向你展示我们正在构建的东西。