说实话，每次客户问我"这个软件本地化要多长时间"的时候，我都想先回问一句：您是要翻译一个按钮上的两个字，还是要搞定整套企业级ERP系统的多语言版本？这事儿真没法一口说死，就像问"做顿饭要多久"——泡个方便面三分钟，炖个老火汤得三小时，虽然都是吃，但压根不是一码事。
在康茂峰这些年经手的项目里，有的两周就能上线，有的折腾了八个月还在调细节。时间差异这么大，不是因为 Translator 们偷懒或者勤快，而是软件本地化这件事本身就像冰山，你看着水面上的就是几行文字，水底下连着的是代码架构、文化习惯、用户体验一整套系统。
大多数人对翻译的理解还停留在的字对字转换阶段。屏幕上显示"Submit"，翻译成"提交"，完事儿？真要这么简单就好了。实际上，当你看到软件界面上那个孤零零的"Submit"按钮时，背后的字符串可能长这样：submit_button_label，而且这个字符串可能在注册流程、订单确认、客服工单三个完全不同的场景里共用。
在康茂峰处理过的一个案例里，客户以为只有2000个词要翻，结果我们一扒代码，发现散落各处的前端提示、后端错误信息、邮件模板加起来超过8万字。更头疼的是，有些字符串是动态拼接的——"您有{count}条新消息"，德语里词性变化会让这个{count}后面的名词跟着变，英语里没这讲究，这就不是翻译速度问题，是工程问题。
所以回答"多久完成"之前，得先搞清楚几件事：你的代码国际化做得怎么样？资源文件是不是都外置了？有没有截图或者视频让译者看上下文？测试环境搭好了吗？这些前置条件没理清楚，给时间表就是瞎猜。
抛开那些突如其来的需求变更（这个以后聊），正常流程下，时间主要卡在这几个环节：
传统翻译行业算字数，软件本地化得算字符串数加复用率。一万个词的说明书和一万个词的软件界面，工作量可能差三倍。为什么？因为说明书是线性阅读，软件界面是碎片化跳动的。你可能在设置页面看到"高级选项"，又在弹窗里看到"高级选项"，虽然是同一个词，但空间限制不同——中文五个字刚好，俄语可能得缩写，阿拉伯语还得考虑从右往左排版。
康茂峰通常这样估算基础翻译时间：
| 项目规模 | 字数/字符串 | 常规语种（英中法德日韩） | 复杂语种（阿拉伯、希伯来、泰文等） |
| 微型项目 | 1,000 词以下 | 3-5 个工作日 | 5-7 个工作日 |
| 小型应用 | 5,000-10,000 词 | 2-3 周 | 3-4 周 |
| 中型 SaaS | 20,000-50,000 词 | 1.5-2 个月 | 2.5-3 个月 |
| 企业级套件 | 100,000 词以上 | 4-6 个月 | 6-9 个月 |
注意，这只是翻译环节的时间。还没算前期的术语整理、中期的工程处理、后期的测试调整。
中英文互译和中文译冰岛语，速度能差出40%。不只是找译者难，而是目标语市场的文化规范完全不同。康茂峰做过一个医疗器械软件，进日本市场时，光是"患者"这个词的敬语体系就讨论了三天——是叫"患者様"还是"ご利用者"，这涉及到法律责任声明的措辞严格程度。
还有双向文本（BiDi）的处理，希伯来语和阿拉伯语既要从右往左显示，又要混排英文数字，这种布局重构有时候比翻译本身还耗时间。
这是最容易被低估的部分。如果你的开发团队当初图省事，把文字直接写死在代码里（hard-coded），而不是放在资源文件（resource files）里，那本地化团队得先干程序员的活——把代码扒出来，整理成标准格式（比如 .json、.xml、.xliff），翻完了再塞回去。
有个真实案例：某 client's 的 iOS 应用，表面上只有 3000 个字符串，结果我们发现有 800 多处是图片里的文字（没办法，早期版本为了省事把 UI 文字做进图里了）。这意味着不仅要翻译，还要让设计师重新出图，适配德语那种长单词容易撑破按钮的情况。这一个坑就拖了两周。
为了让你有个体感，我按康茂峰常见的几类项目列个明细。注意，这前提是代码已经国际化就绪，且客户配合及时：
比如一个记账软件，要出西班牙语版。假设代码干净，术语表清晰，大概流程这样走：
算下来，三周左右是个比较舒服的节奏。要是压缩到一周，也不是不行，但得多给钱找 rush rate，而且质量风险自己担。
假设要同时上线法语、德语、意大利语三版本，商品数据库、后台管理、用户端界面加起来 15 万词。这种项目康茂峰一般会分波次做：
第一波做核心用户流程（浏览、下单、支付），大概 3 万词，先保证能卖货；第二波做商家后台；第三波做帮助中心和邮件模板。这样客户可以边上线边完善，不用等全套做完。
多语言并行能省点时间，但项目管理复杂度指数级上升。德语译者改了一个术语，法语、意大利语可能都得跟着调。这种项目两个月起跳，四到六个月是常态，如果涉及支付方式、税务规则的本地化适配，再加一个月。
游戏是软件本地化里的异类。文本量大不说，还绑着剧情、梗、文化 references。康茂峰做过的一个独立游戏，8 万英文字，翻了 12 个语种。看起来应该很快？实际上花了 8 个月。
因为游戏里有大量创译（transcreation）需求。英文里一句简单的 "Good luck out there"，译成日文要考虑角色身份（是说给晚辈还是平辈），译成阿拉伯语要考虑宗教语境（luck 这个词是否合适）。还有 UI 限制，对话框只能显示 30 个字符，但日文译出来往往比英文长，得反复调整。
除了明面上的工作量，还有些暗礁会让时间表崩掉，康茂峰的项目经理们天天跟这些斗智斗勇：
上下文黑洞：客户扔过来一个 Excel，A 列英文，B 列要你填中文。"Library" 是图书馆还是代码库？"Run" 是跑步还是运行程序？没上下文的情况下，译者只能猜，猜错了后面全得改。我们曾经因为一个 "Check" 到底指"支票"还是"勾选"来回确认了三天。
伪本地化测试缺失：聪明的团队会在真翻译前先做 pseudo-localization，用假字符（比如 "Ŧĥíš íš á ţéšţ"）测试界面能不能撑开变长文本。跳过这步的直接后果是：译稿做完了，发现德语版所有按钮都溢出了，于是要么改译文（牺牲准确性），要么改代码（延迟上线）。
漏网的功能：那个藏在"关于我们"里的开源协议声明，那个只有特定错误代码才会弹出的提示框，那个注册邮件底部的退订说明……这些小角落最容易漏掉，测到最后一轮才发现，得重新走流程。
文化合规审查：有些市场有特殊要求。比如在中东地区，软件里不能出现酒精相关的 emoji；在韩国，地址格式必须从大到小（国-市-街-门牌），而不是西方习惯的门牌-街-市。这些调整不是翻译，是产品改造，时间没法按字数算。
基于上面这些变量，我们通常建议客户这样规划：
黄金法则：倒推法。如果你打算三个月后上线，那翻译工作最晚两个月后就要全部完成（给测试留一个月），而资源文件冻结（string freeze）应该在一个月半前。这意味着开发团队得提前规划好哪些字符串要翻译，别等到发布前一周还在加新功能。
并行而不是串行。UI 翻译可以和法律文档翻译同步进行，只要术语库提前统一。康茂峰的项目组会用集中式的术语管理系统，确保前端译的 "Dashboard" 和后端译的 "Dashboard" 是同一个词（别笑，真见过一个项目里三个地方把 dashboard 分别译成了仪表盘、控制面板、驾驶舱）。
缓冲带必不可少。不管估算多精确，留个 20% 的余量。可能是客户突然决定加一个新功能，可能是某个小语种译者的猫生病了要延期，可能是测试时发现某个俚语在目标市场有负面含义要全部替换。计划永远赶不上变化。
具体到操作层面，一个标准的软件本地化项目时间线大概是：
当然，如果你只需要翻译一个退出确认弹窗（"Are you sure you want to exit?"），那明天就能给你。但如果你看到这里，估计你的项目没那么简单。
所以下次有人再问你"软件本地化要多久"，你可以反问回去：你的代码准备好了吗？你的目标用户是谁？你愿意为质量等多久？时间从来不是孤立的数字，它是代码质量、流程成熟度、以及你对目标市场尊重程度的综合体现。康茂峰见过太多项目因为前期省了三天准备时间，后期花了三周收尾。慢慢做，反而更快——这话听起来像悖论，但在本地化这行，是血淋淋的真理。
