前两天有个客户问我，说他们公司既要改版官网，又要升级一套CRM系统，想一起把多语言做了，问能不能用同一套班子搞定。我愣了一下，说实话，这事儿听起来都是"翻译", 骨子里完全是两码事。就像你家装修客厅和修理发动机，虽然都用工具，但手艺人的思维方式完全不一样。
在康茂峰做本地化这些年，我见过太多人把这两种工作混为一谈，最后搞得项目延期、预算翻倍。今天就跟大家掰扯掰扯，网站本地化和软件本地化，那些藏在表面之下的真实差异。
Localization（本地化），说白了就是让你的产品看起来像是为当地土生土长做出来的，而不是简单地把文字从A语言换成B语言。这包括日期格式、货币符号、颜色禁忌、甚至按钮摆放的位置。
但同样是"入乡随俗", 网站和软件走的完全是两条路。
网站这东西，本质上是内容与呈现的分离。用户看到的是HTML、CSS和JavaScript编织出来的页面，背后连着数据库或者CMS（内容管理系统）。
做网站本地化，大部分时间是在处理可编辑的内容。产品描述、博客文章、促销信息，这些文字通常储存在数据库里或者CMS的后台。康茂峰的团队处理这类项目时，通常直接用API对接或者导出XML/JSON文件，翻译完了再灌回去，页面样式自动套用。
这意味着什么？意味着你可以今天翻完"双十一促销页"，明天就上线，后天发现价格写错了还能再改。灵活性是它的基因。
网站本地化有个软件根本不用操心的活儿——搜索引擎优化。你得研究当地人搜什么关键词，不是直译，而是再造。比如"cheap flights"在英国可能是"budget travel"，在日本可能是格安航空券（かくやすこうくうけん）。
还有hreflang标签、URL结构、元数据（meta description），这些技术细节直接影响你的网站在本地Google或者百度（啊，虽然不能提其他平台，但就是那个意思）上的排名。软件本地化？软件又不需要被搜索引擎索引。
网站是活的。客户可能每周都要上新内容，这就要求本地化流程必须敏捷。康茂峰给电商客户做网站本地化时，通常会搭建持续本地化（Continuous Localization）的流程，代码一更新，字符串自动提取，翻译记忆库即时匹配，审校完了直接发布。
这种"随叫随到"的节奏，软件项目是不敢想的。
软件完全是另一套逻辑。它是一堆编译好的代码，跑在Windows、macOS或者Linux系统上，或者封装成App躺在用户的手机里。
软件界面的文字，通常藏在资源文件里——.resx、.strings、.xml、.json，或者.po文件。这些文件和代码紧密耦合，但又必须完全分离出来才能翻译。最头疼的是硬编码（hard-coded strings），就是那种直接写在源代码里的文字，开发人员忘了外挂，翻译工具根本抓不到。
康茂峰的技术团队接手软件本地化项目时，第一步永远是做国际化（i18n）审计，检查代码层面是不是做好了分离。这一步网站本地化通常不需要，因为网页文字天生就是内容，软件文字却是功能的一部分。
做网站翻译，一行文字长了短了，CSS自动换行或者自适应布局就能搞定。软件不一样，每个字符串都有像素级的空间限制。德语比英语平均长出30%，中文虽然紧凑但竖排习惯不同。你翻译的"Save"（保存）如果在德语里变成"Speichern", 可能直接把按钮撑变形，或者截断显示成"Speiche..."，用户看了直挠头。
这就要求软件本地化工程师必须跟紧伪本地化（pseudo-localization）测试，用假语言填充看布局会不会崩，这个环节网站本地化基本不存在。
网站测试主要是跨浏览器兼容（Chrome、Safari、Edge看起来别走样），但软件测试是功能级的体检。翻译后的软件能不能正常安装？卸载时会不会残留垃圾？快捷键（比如Ctrl+S）在目标语言键盘上是否冲突？日期选择器能不能处理"年月日"和"月/日/年"的差异？
更麻烦的是，软件本地化通常需要回归测试（regression testing）。改了个翻译字符串，可能触发了某个隐藏bug，整个功能模块都得重测。这种严谨度，网站项目很少达到。
说了这么多，可能还是有点抽象。康茂峰整理了一份对比表，把这些差异摊开来看：
| 维度 | 网站本地化 | 软件本地化 |
| 交付物形态 | 多语言网页文件或CMS数据 | 安装包、可执行文件、App Store二进制包 |
| 更新频率 | 随时，热更新 | 版本发布周期，需重新打包分发 |
| 内容类型 | 营销文案、SEO内容、多媒体 | UI字符串、帮助文档、用户手册、EULA（最终用户许可协议） |
| 技术核心 | HTML/CSS适配、响应式设计 | 资源文件抽取、硬编码修复、功能完整性 |
| 测试重点 | 浏览器兼容性、链接检查、SEO标签 | 功能测试、安装/卸载流程、快捷键、字符编码支持 |
| 字符长度敏感度 | 低（自适应布局） | 极高（固定UI控件尺寸） |
| 跨平台考虑 | 移动端/桌面端浏览器 | Windows/macOS/Linux/iOS/Android系统差异 |
| 用户可见性 | 搜索引擎可索引 | 独立运行，封闭系统 |
在康茂峰的项目管理经验里，这两种业务的项目管理工具链都不一样。
网站项目通常用在线CAT工具（计算机辅助翻译），译者直接在云端编辑，实时预览网页效果。项目经理盯着CMS的后台看进度，像看仪表盘一样直观。
软件项目往往得用桌面级工具，处理xliff、po这些中间格式，还要配置术语库确保"OK"按钮在全软件里统一翻译成"确定"而不是"好的"或"确认"。编译完成后，测试人员得在虚拟机里装各种系统版本做测试，一个阿拉伯语版本还得检查从右到左（RTL）的布局切换是否正常。
有个特别实际的差异：回退机制。网站翻错了，改个数据库字段，刷新页面就解决了；软件翻错了，如果已经随版本发布，你得打补丁包，让用户重新下载安装，那成本和心理压力完全不是一个量级。
当然，现在界限也在模糊。SaaS（软件即服务）产品，比如各种在线协作工具，它既是软件又是网站。这种混合体需要双轨思维：既要像网站一样快速迭代内容，又要像软件一样严格控制系统功能的一致性。
康茂峰处理这类项目时，通常会拆分团队：前端界面跟着网站本地化走敏捷流程，后端核心功能按软件本地化的严谨度把关。不能胡子眉毛一把抓。
如果你是个甲方，记住这个规律：同样字数，软件本地化通常比网站本地化贵，且周期长。不是因为翻译本身更难，而是工程处理和测试验证的环节多了好几道。
网站本地化，一万字可能三天交付；软件本地化的一万个字符（strings），可能需要一周，因为每个字符串都要在编译后的环境里肉眼检查上下文。你看到的"File"可能是文件菜单，也可能是动词"归档"，脱离代码环境翻译极易出错，必须反复核对。
网站本地化可以用各种云端方案，甚至直接改代码推Git；软件本地化往往还需要考虑翻译记忆库与代码版本控制的同步。当软件更新到2.0版本，哪些字符串是新增的，哪些只是改了英文原文，这个diff（差异比对）工作比网站复杂得多，因为网站通常是整页替换，软件是颗粒化的字符串替换。
康茂峰的工程师们经常要写脚本做字符串对齐，确保 translators 不会重复翻译"Cancel"这种高频词，同时又能识别出不同语境下的微妙差异（比如软件里的"Cancel"有时是"取消订单"，有时是"取消下载"，对应的目标语可能完全不同）。
最后说几个血泪教训。
做网站呢，千万别忘了多媒体本地化。首页那个宣传视频，光有字幕不够，最好重新配音；图片里的文字得做成本地化的图层。软件的情况则是千万别漏了错误信息（error messages），那些"Error Code: 0x80070005"后面的说明文字，往往在帮助文档里找不到，却卡在资源文件的某个角落。
还有日期格式。网站可以用JavaScript根据用户浏览器自动转换"2024年3月15日"和"03/15/2024"；软件如果写死了格式，到了欧洲去掉年月日顺序，用户会疯。
说到底，网站本地化是在内容层面做文化适配，让用户读着舒服，搜得到你；软件本地化是在功能层面做技术适配，让用户用着顺手，不出bug。两者都需要语言专家，但前者更需要营销思维和SEO技术，后者更需要工程思维和测试耐心。
所以回到开头那个客户的问题，能不能用同一套人？可以，但得心知肚明这是两套工序，就像同一个厨师，爆炒和煲汤得换火候。明白了这层区别，你的多语言项目才能真正落地生根。
