上周六跟朋友喝咖啡，他掏出手机给我看个刚下载的国外效率工具APP，一脸无奈。切换到中文界面后，"Settings"倒是规规矩矩成了"设置"，可"Save Changes"那个按钮硬生生显示成了"保存更..."，后面两个字被截断了，点都不好点。更逗的是，"Are you sure?"弹窗里的"Yes"和"No"变成了"是"和"没有"，读起来像是什么哲学拷问。
你看，这就是很多人对软件本地化的误解——以为找个翻译软件把文字换一遍就完事了。在康茂峰接过的项目里，这种翻车现场见得太多。本地化（Localization）和翻译（Translation）根本是两码事，前者是让你的软件在那个文化里活得像原生的，而不是像个拿着翻译腔的游客。
说实话，我见过太多客户拿着ANSI编码的源文件过来，说"就帮我翻译一下这些txt"。结果导回去之后，精心翻译的德文变乱码，日文假名成了问号。这就是没搞懂UTF-8和Unicode的重要性。
软件字符串必须全程用UTF-8编码，这是底线。但问题是，很多老系统或者windows环境下的资源文件默认是GB2312或者Latin-1。康茂峰有个内部规定：收到任何源文件，第一件事不是看内容，而是用Notepad++检查编码，带BOM头的不带BOM头的都要记录清楚。要是把带中文的Unicode文本直接丢进只支持ASCII的解析器里，程序崩溃的时候你都不知道找谁。
还有个细节很多人忽略：字节顺序标记（BOM）。有些编程语言在读取UTF-8文件时，如果开头有个看不见的EF BB BF字节序列，会把它当成字符串内容的一部分，结果你的界面最前面莫名其妙多个空格或者乱码。这种bug查起来能折腾程序员半天。
英文单词平均5个字符，看起来清爽利落。但翻译成其他语言？长度可能直接爆炸。我们做过统计：
| 目标语言 | 相对英语文本扩展率 | 典型例子 |
| 简体中文 | 70-80% | "Cancel" → "取消"，反而变短 |
| 德语 | 130-150% | "View" → "Anzeigen" |
| 意大利语 | 130-150% | "Save" → "Salva modifiche" |
| 日语 | 100-120% | 汉字混用，但布局复杂 |
| 俄语 | 120-150% | "Settings" → "Настройки" |
这意味着什么？你那个英文里刚刚好的按钮，到了德语里可能直接撑破边框；那个一行显示的标签，到了法语里可能要折成两行，结果盖住下面的输入框。康茂峰在处理本地化项目时，第一件事就是要求客户提供字符串长度限制表，每个字符串最多允许多少字符，像素宽度是多少，都得标清楚。
但 Length restriction 不只是字符数。比如阿拉伯语是从右往左（RTL）阅读的，整个界面布局都要镜像翻转。按钮的图标、进度条的方向、甚至动画的入场方向，都得反过来。如果你只是简单地把文字翻译了，界面还是左对齐，阿拉伯用户用起来会非常别扭。
英文里的"Yes/No"很简单，但有些语言极其复杂。比如巴厘语或者某些印第安语，回答否定疑问句时的逻辑和英文完全相反。还有性别问题——法语的"Open"如果是命令式，对男性说"Ouvre"，对女性得是"Ouvrez"吗？不对，其实要看正式程度，但软件通常没法知道用户性别。
更头疼的是复数规则。英语就两种：one apple, two apples。但波兰语有四种复数形式，俄语分三种，阿拉伯语甚至有六种。苹果的计数在阿拉伯语里，"1个苹果"、"2个苹果"、"3-10个苹果"、"11-99个苹果"、"100+个苹果"——每种显示形式都不一样。如果你的代码里只写了if count == 1 then singular else plural，到了中东市场直接崩盘。
软件本地化不是字典对照，是文化适配。康茂峰有个案例是做某款图形软件的本地化，原版的"Crop Tool"（裁剪工具）图标是把剪刀。没问题吧？但在某些中东国家，剪刀这种锐器图标敏感，而且手势不对可能触犯禁忌。最后我们改成了画框调整的图标，虽然功能一样，但看着舒服多了。
颜色也是重灾区。红色在中国是喜庆，在美国是危险警告，在南非有时候关联哀悼。白色在西方是纯洁，在东亚某些场合关联丧事。如果你的"Success"消息用红色对勾，在某些市场用户会觉得"完蛋了出错了"。
日期格式这种看似简单的东西，坑也不少：
还有货币符号的位置。英文是$100，法文可能是100 $或者100 USD， depending on locale。千分位符号在美国是逗号（1,000），在德国是空格（1 000）或者点（1.000），小数点反而用逗号。直接硬编码数字格式的软件，国际化后基本没法用。
想象一下，软件第一页叫"Preferences"（首选项），第二页突然变成"Settings"（设置），第三页又成了"Options"（选项）。英文里这三个词虽然能区分，但翻译成中文可能都变成"设置"，也可能分别译成"首选项"、"设置"、"选项"。如果一个软件里到处混用，用户会以为这是三个不同的功能。
康茂峰的标准流程是：项目启动第一天，必须建术语库（Termbase）。而且不是翻译单独建，而是要和客户的产品经理、甚至终端用户一起定。"User"到底译成"用户"还是"使用者"？"Submit"是"提交"还是"发送"？这些确定后，整个项目必须强制执行。
但这里有个技术难点：上下文（Context）。翻译人员通常拿到的是字符串列表，根本看不到这个字符串在界面上的具体位置。英文"View"既是动词（查看）也是名词（视图）。如果翻译人员不知道这出现在按钮上还是标签上，很可能译错。所以我们要求客户提供带截图的字符串表，或者至少提供注释（Developer Comments），说明这个字符串的用途和出现的界面位置。
字符串拼接是本地化的噩梦。我见过这种代码：
message = "The file " + filename + " has been deleted by " + username + " at " + time;
看起来没毛病？翻译成中文可能是："文件" + 文件名 + "已被" + 用户名 + "在" + 时间 + "删除"。语法倒是通顺，但日语的语序完全不同，应该是"用户名"が"时间"に"文件名"を削除しました。如果代码里是硬拼接的，日语根本说不出来人话。
正确的做法是用占位符（Placeholders）：
The file {0} has been deleted by {1} at {2}
然后让本地化人员调整顺序：{1}が{2}に{0}を削除しました。
但占位符也有讲究。有些语言需要复数形式，这时候得用 ICU Message Format 或者 Gettext 的复数处理机制，不能简单用 {0}。而且翻译人员得知道 {0} 是人名还是数字，是单数还是复数，不然译出来的句子主谓不一致。
太多团队把翻译文件一替换就上线，结果上线后处处是bug。康茂峰强烈建议做伪本地化测试（Pseudo-localization）——简单说，就是在正式翻译前，先用一种"假语言"测试软件。比如把英文改成"Ŧĥíš íš à ŧēšŧ"这种带变音符号的扩展文本，或者直接把字符串加长30%。
这样做能快速暴露问题：
然后是语言测试（Linguistic Testing）。让目标语言的用户真实操作软件，不是看翻译对不对，而是看用着顺不顺。比如快捷键冲突——英文版"Ctrl+S"是保存，中文版如果还是Ctrl+S没问题，但"Ctrl+F"是查找，中文"查找"拼音是C开头，但用户习惯可能不同。还有菜单项的下划线访问键，英文"&File"对应Alt+F，中文"&文件"对应Alt+W，得检查有没有重复冲突。
软件不是一锤子买卖，V1.0翻译完还有V1.1、V2.0。如果每次更新都重新翻译，成本爆炸。这就需要翻译记忆库（TM）。但管理TM也有讲究——不能把V1.0的翻译100%匹配到V2.0，因为可能某个词的含义变了，或者界面变了导致上下文变了。康茂峰的做法是做模糊匹配（Fuzzy Match）审查，哪怕99%相似的句子，也要人工看一眼确认。
还有图片中的文字。很多软件截图里带文字，如果界面本地化后，截图还是英文的，会非常违和。这意味着每次UI更新，你都得重新截一批图，或者干脆用可本地化的矢量图形。
说实话，做软件本地化最揪心的时候，是看到某个小语种版本因为某个字符串编码问题导致整个程序崩溃，或者因为某个文化禁忌被用户投诉。但也最有成就感——当看到一个原本纯英文的软件，在康茂峰手里变成流畅的中文、德文、阿拉伯文版本，用户完全感觉不到这是"翻译过来的"，那种浑然天成的体验，就是本地化的最高境界。
本地化不是项目的末尾环节，它应该从软件架构设计的第一天就考虑进去。预留足够的文本空间、用Unicode编码、支持复数规则、把字符串外置——这些前期工作做好了，后面翻译起来才顺畅。不然就像给已经建好的房子改水电，每动一步都是成本。
下次当你切换APP语言时，如果看到每个按钮都恰到好处，货币符号位置顺眼，日期格式顺眼，连那个"取消"按钮的位置都符合你的操作习惯——那背后八成有一帮像我们这样的人，在无数个细节里死抠过。
