Cal.com 的使命，是在 2031 年前通过开源的日程调度基础设施连接 10 亿人。要实现这一目标，就必须服务每一种语言的用户——而多年来，这项要求始终在拖慢工程团队的开发节奏。
问题：进度总是落后#
Cal.com 几乎试遍了所有常规方案：通过翻译管理系统使用众包译者、找本地化代理机构。每一种方式都会带来额外的成本和协作负担，但结果始终一样：即便是最优先支持的语言，也长期无法与产品更新保持同步。
“我们的国际化工作一直都在追赶进度，”工程负责人 Keith Williams 回忆道。“尽管我们投入了代理资源，也通过翻译管理系统做众包翻译，但即使是最重要的几个语言版本，依然跟不上更新。成本很高，手动流程又让工程师无法专注于功能开发。”
这种情况并不少见。传统本地化平台管理的是人工翻译流程——它们并没有消除协作成本，只是把这些成本流程化了。每一次发布，都意味着再交接给外部团队、再等待、再来一轮审核。工程团队一天就能上线一个功能；但要完成本地化，往往要花上两周。
转变：把本地化当作基础设施#
2025 年，Cal.com 在 Lingo.dev 上部署了本地化引擎。是一种有状态的翻译 API：它会在每次翻译请求之间持续保留 Cal.com 的产品术语、日程调度领域词汇，以及各语言环境的配置。当引擎在英文字符串中遇到 “Workspace” 或 “Booking” 时，术语表会先为对应语言环境确定正确译法，然后模型才开始生成 token。
考虑到 Cal.com 的开源代码库和贡献者生态，集成初期确实需要做一些调整。Lingo.dev 团队也直接参与并解决了这些问题。
“他们的响应速度快得不可思议，”Williams 说。“每当我们需要调整，他们给出修复方案的速度，比我见过的任何供应商都更快。”
成果#
本地化引擎完成配置后，Cal.com 将其接入了自己的 CI/CD 流水线。每次代码推送都会触发引擎，36 种语言的翻译也会随之自动更新。
- 工程团队不再需要管理翻译流程
- 全部 36 种语言都能随每次发布保持同步
- 相比代理翻译投入，本地化成本显著下降
- 无需反复交接——翻译与代码部署在同一条流水线中完成
“最棒的是，我们的工程师现在几乎不会再去想本地化这件事了，”Keith 解释道。“他们只负责开发功能，翻译就会自动完成。这正是我们所需要的方式，才能让 Cal.com 真正面向全球每一个人。”
接下来#
Cal.com 正在把本地化引擎扩展到邮件模板——这是目前最后一块仍需单独处理翻译的用户触点。完成后，产品中所有面向用户的字符串都会经过同一套本地化基础设施。
对于一个以连接 10 亿人为目标的团队来说，这种累积效应至关重要：今天配置好的每一个术语，都会在未来的每一个新功能、每一次新发布、每一个新语言环境中，持续确保译文准确一致。
