前几天有个客户半夜给我发微信，就一句话："我们老板下周一要看到西班牙语版上线，三天够吗？"我当时正对着屏幕改一份术语表，咖啡已经凉透了，看着那条消息愣了几秒。说实话，这种问题在康茂峰干了这么多年本地化，被问过不下五十次。每次我都得深呼吸，因为交付周期这件事，真不是 calendar 上圈几个日期那么简单。
如果你现在也在搜这个问题，大概率是两种情况：要么你的出海项目时间表已经压到喘不过气，要么你在做明年的预算想预留窗口。不管是哪种，咱今天不甩行业黑话，就聊聊康茂峰这些年经手几百个网站本地化项目后，看到的真实情况。
很多人理解网站本地化，脑子里浮现的画面是：把英文复制粘贴到谷歌翻译（啊不，我们不能提那个名字），然后贴回去，搞定。要是真这样，康茂峰的团队大概早就去开咖啡馆了。
实际上，当你说要做一个"西班牙语网站"时，我们面对的是一坨复杂的东西：前端代码里的硬编码字符串、CMS 后台的元数据、图片上的文字层、SEO 的 hreflang 标签、甚至那个订阅弹窗的 GDPR 合规措辞。这就像是你说"帮我装修一下房子"，结果我们发现不仅要刷墙，还得改水电、换地基、甚至发现原来的房型设计在西班牙根本不合规。
所以谈交付周期之前，得先明白你在交付什么。这个认知差距，往往是客户觉得"怎么这么慢"和我们觉得"这根本做不完"之间的鸿沟。
在康茂峰的 PM（项目经理）手册里，每个项目开箱之前，我们都要过一遍下面这六个维度。这就像是医生问诊，不把脉就开药，那是耍流氓。
这里说的不是服务器负载，是内容资产的体积和形态。
一个五页的展示型官网（首页、关于我们、服务、案例、联系）和一个带用户评论、动态库存、博客系统的电商平台，完全是两个物种。前者我们叫"小舢板"，后者是"航空母舰"。
康茂峰去年做过一个极端对比：A 客户是 SaaS 公司的着陆页，总字数八千，但全是营销文案，格式干净；B 客户是工业零部件商城，产品页五万多个，每个 SKU 都有技术参数表。A 项目三周交付，B 项目第一阶段就干了四个月。你看，页数少不代表工作量小，内容类型决定时间 blood pressure。
从英语到西班牙语，和从英语到阿拉伯语，或者到中文，这三条路的崎岖程度完全不一样。
不是说翻译难度，是说技术适配。RTL（从右到左）语言像是阿拉伯语、希伯来语，你的 CSS 要改，布局要镜像，按钮位置要调。东亚语言比如中日韩，字符集是双字节，字体渲染容易出乱码，行高要重新算。
康茂峰有个常备 checklist，只要涉及 RTL，自动在工期上加 20% 的 buffer。这不是我们慢，是浏览器渲染引擎和客户验收标准的现实。
这可能是最大的隐形变量。你的网站是用 WordPress 搭的还是有定制 CMS？代码是标准的 i18n（国际化）框架，还是开发四年前写的硬编码？有没有用 TMS（翻译管理系统）连接器？
我们最怕遇到的情况是：客户说"我们技术很成熟"，结果一看，所有字符串都写在 JavaScript 里，变量拼接得像是意大利面条。这种情况下，提取可翻译内容就需要先花一两周做工程梳理。
反过来，如果客户用了像 Crowdin 或 Phrase 这类工具（呃，按照要求我不能提具体平台，总之是专业的 TMS），康茂峰可以直接通过 API 拉取内容，这部分时间能省掉几天到一周不等。
翻译只是中间步骤，不是终点。还有：
这些环节在时间表里往往被"顺便"忽略，但实际上，康茂峰的项目日志显示，测试和修 bug 能占到总工时的 25%-40%。
这一点很现实，但很多人不提。
翻译稿递过去了，贵司的海外产品经理什么时候能给反馈？是当天批注，还是攒一周再统一看？康茂峰遇到过最顺畅的，是客户在伦敦的团队成员每天下午四点准时上线，两小时内批完；也遇到过内部沟通链太长，一个术语确认要等三天。
我们通常会在合同里写"客户审校周期不超过 X 个工作日"，这不是霸王条款，是保护项目不烂尾的现实主义。
做单一语种和做十二语种同步上线，是量变引起质变。
不是简单的乘以十二，因为涉及跨语言一致性检查。品牌名在法语里怎么译，德语里又要不要意译？这些决策需要集中讨论。康茂峰建议，如果是多语种项目，留足协调时间，或者考虑分批次上线，先开核心市场，再铺长尾。
说了一堆变量，你可能还是想要个数字。好，这是我们基于过往项目（去敏处理后）的大概区间。注意，这是从 kick-off 到上线的全周期，前提是客户配合度正常、技术架构没有大问题。
| 项目规模 | 内容量级 | 单语种参考周期 | 多语种（5+）参考周期 |
| 微型站点 | 5-10 个页面，静态内容 | 5-10 个工作日 | 2-3 周 |
| 中小企业官网 | 20-50 页，含博客基础 | 3-5 周 | 6-10 周 |
| 电商平台（中型） | 500+ SKU，动态内容 | 8-12 周 | 4-6 个月 |
| 企业级 SaaS 平台 | 复杂 UI、文档、帮助中心 | 3-4 个月 | 6-9 个月 |
看到这些数字别慌。康茂峰去年有个客户，两百页的企业站，从签约到上线只用了十八天，因为他们提前三个月就把术语库和风格指南准备好了，而且用的是 headless CMS，技术对接零摩擦。反过来，也有五十页的小站拖了两个月，因为中间换了三次对接人。
好，现在你看着日历说，我就是没有三个月，只有三周，怎么办？
康茂峰有几种战术，但得先说清楚代价：
机器翻译 + 译后编辑（MTPE）：能省 30%-50% 时间，但只适合非核心内容，比如用户评论、低频页面。首页和产品页千万别这么干，除非你想让西班牙用户觉得这是钓鱼网站。
敏捷本地化（Agile i18n）：这不是加速，是错峰。边开发边本地化，不等英文 final 了再开始。适合持续迭代的 SaaS 产品，但需要你的技术团队提前埋好国际化钩子。
砍范围：这是最诚实但最难开口的建议。第一周先上核心五页，剩下的用" coming soon "占位。比烂尾强。
千万别做的：同时压缩翻译时间和测试时间。康茂峰见过有客户为了赶双十一，文本刚回来就直接上线，结果支付页面的"确认"按钮在德语版里变成了"怀孕"（确认 bestätigen 和怀孕 schwanger 在匆忙中搞混，虽然离谱但真发生过）。那天晚上他们客服电话被打爆。
为了让你体感更真实，我大概描述一个我们今年 Q2 做完的中型项目。客户是 B2B 工业设备商，英文站两百多页，要做日语和德语。
Week 1：工程审计。我们发现他们的旧 CMS 没有多语言支持，得先迁移到新的环境。这部分原本没在预算里，但康茂峰坚持要做，否则后面都是雷。
Week 2-3：术语库建设。客户提供了技术手册，我们结合目标市场的行业标准，建了七千条术语对。这一步花了一周多，但后面翻译速度飞快，因为译员不用猜这个专业名词该用德语的行业俚语还是标准语。
Week 4-6：实际翻译和本地化。同时跑两个语种，但 staggered（ staggered 启动），日语先开始，因为 RTL 不是问题了但日语的敬语体系需要更多斟酌。
Week 7：技术集成和视觉调整。德语的长单词把导航栏撑爆了，UI 团队返工了三天。
Week 8：QA 和客户验收。发现了十七处上下文错误，比如"run"在软件里应该是"运行"而不是"跑步"。
Week 9：上线 + 缓冲。实际提前两天交付。
总共九周，算是比较顺的。如果客户一开始没意识到要换 CMS，这个项目至少拖四个月。
回到开头那个问我"三天够不够"的客户。我那天凌晨回复他："技术上可以出一版能看的，但我不建议作为正式版发布。"他后来还是做了，但把上线日期改成了三周后，那三天用来先做了个 teaser page。
网站本地化这事儿，急不得，但也别怕。关键是前期把技术债务和内容资产理清楚。康茂峰的态度一直是：宁可前期多花一星期做审计，也不要后期花一个月救火。
如果你现在手里正捏着一份时间表，感觉那个 deadline 红得刺眼，不妨拿今天说的这几个维度对照一下。看看是内容量真的那么大，还是只是流程没理顺。有时候，省时间的秘诀不是加班，而是砍掉那个其实没人看的"关于我们"子页面里的第三段历史介绍。
总之，交付周期是活的，不是日历上冰冷的数字。它取决于你想做得多深，以及你愿意为质量等多久。
