衡量本地化交付周期，而不只是字数

字数很容易衡量，也有助于估算翻译量。

但它无法告诉你，一个本地化营销活动是否能按时上线。

一个五百词的页面，可能在队列中等待六天，几分钟内完成翻译，然后再等待两天进入审核。发布过程中代价最高的部分，往往不是字数本身，而是决策之间损失的时间。

衡量完整的请求生命周期

本地化交付周期始于内容准备好进入翻译之时，终于目标语言版本到达其预期目标之时。

这个目标可能是已批准的草稿、成功推送到 CMS，或已发布的页面。请明确选择终点，并分别报告各个阶段：

1. 等待翻译
2. 生成草稿
3. 等待审核
4. 主动审核中
5. 等待推送
6. 等待发布

阶段拆分能够显示工作实际在哪些地方变慢。

排队时间是一个产品信号

如果请求的大部分生命周期都花在等待上，那么更快的模型也不会实质性改善交付。

过长的排队时间可能意味着批次过大、责任归属不清、通知没有发送给正确的审核人，或者低优先级工作阻塞了发布关键页面。这些都是字数无法暴露的工作流问题。

跟踪中位数和高百分位的等待时间。平均值可能会掩盖那些反复错过发布时间的少量请求。

将机器时间与人工时间分开

生成耗时对交互式工作很重要，但审核往往主导整个日历周期。

要将主动审核时间与等待审核人的时间分开衡量。如果主动审核本身很慢，团队可能需要更好的源文上下文、术语、预览链接，或更小粒度的字段级变更。如果等待时间很慢，答案更可能在于路由、产能或优先级。

相同的总交付周期，可能指向完全不同的改进方向。

衡量返工循环

如果一个初稿需要被打回审核三次，那么再快也不算成功。

跟踪请求被重新生成、在批准后被重新打开，或在 CMS 推送后被修改的频率。将这些事件与原因对应起来，例如源文变更、术语问题、格式问题或市场反馈。

返工率为速度补充了质量维度。它帮助团队避免只优化首次通过指标，却只是把工作量转移到下游。

在可比条件下比较

交付周期会随内容风险和工作流策略而变化。

需要两次审批的法务页面，不应与可自动发布的简短产品标签进行基准比较。应按内容类型、目标语言、优先级和预期终点进行分组报告。

还要区分首次本地化与更新。翻译一个新页面和修订一个已变更段落，即使最终字数相同，其工作范围也不同。

把这个指标变成一种运营习惯

一个有用的每周视图可以保持简洁：

• 从准备完成到翻译完成的中位时间
• 等待审核的中位时间
• 从批准到发布的中位时间
• 在要求截止日期前完成的百分比
• 被重新打开或重新生成的请求
• 按优先级划分的最旧活动请求

不仅要看趋势线，也要复盘异常情况。一个反复受阻的语言版本，往往能比季度报告更早暴露出负责人缺失或权限缺失的问题。

要点

字数衡量的是内容体量，交付周期衡量的是团队交付上线的能力。

跟踪完整生命周期，将等待与主动工作分开，纳入返工情况，并比较风险相近的请求。目标不是让每一次翻译都瞬间完成，而是建立一个时间可预测的工作流，使多语言发布能够与源内容遵循同一份路线图。