说实话，刚入行那会儿，我也以为软件本地化就是把英文菜单翻译成中文，或者把中文帮助文档改成日语那么简单——找个翻译公司，丢过去一堆Word文档，等两周收回来贴上去就完事了。但在康茂峰做了这几年本地化工程之后，我才发现自己当初天真得可笑。软件本地化这活儿，本质上是在技术架构、语言逻辑和用户体验这三板斧之间走钢丝，稍不留神就是一个生产事故。
今天就想跟你唠唠，那些在项目里真实发生过的技术难点。不是什么高大上的理论，就是实打实的坑，以及我们是怎么（有时候是狼狈地）爬出来的。
先说说最经典的坑——硬编码（Hard-coded Strings）。很多开发团队一开始根本没考虑过国际化这事儿，字符串直接写在代码里，跟业务逻辑缠得死死的。比如你在某段Java代码里看到：
System.out.println("User not found");
看起来没问题对吧？但到了本地化环节，这就成了一个噩梦。我们得翻遍几万行代码，把这些散落在各个角落的字符串一个个挖出来，塞进资源文件（Resource Files）里——可能是.properties、.json、.xml或者.xliff格式。这个过程叫国际化（i18n）预处理。
在康茂峰处理一个企业级ERP系统的本地化时，我们遇到过更离谱的情况：某个关键错误提示是动态拼接的——前半段在A文件的第120行，后半段在B文件的第450行，中间还夹着一个从数据库里捞出来的变量。翻译人员拿到CAT工具（计算机辅助翻译工具）里一看，只有两个孤立的片段，完全不知道上下文是什么。这怎么翻？"用户"还是"用户们"？过去时还是现在时？
所以啊，好的i18n实践要求开发阶段就必须把字符串完全外置，而且要带注释（Context Comments）。但现实中，你总能遇到那种"先上线再说"的项目，这时候本地化工程师就得化身代码考古学家，拿着IDE的地质锤一点点敲。
解决了代码层面的问题，UI层面还有更大的麻烦等着。我们内部有个半开玩笑的说法："英语是压缩包，其他语言是解压后的文件"。来看一组真实的数据对比：
| 原文（英语） | 译文（德语） | 膨胀率 |
|---|---|---|
| Save | Speichern | +100% |
| Install Now | Jetzt installieren | |
| Copyright Information | Urheberrechtsinformationen | +300% |
你看，一个简简单单的"Save"，德语直接翻倍。这在UI设计上意味着什么？意味着你那个精心设计的80像素宽的按钮，在德语环境下文字会直接溢出，或者被截断成"Speicher..."（用户看了直挠头：这是要存什么？冰箱吗？）。
康茂峰在处理移动端App本地化时，经常要搞伪本地化测试（Pseudo-localization）——就是在开发阶段用一串拉长的假文字（比如把"ABC"变成"ÃÂÇ"再重复三遍）来模拟最恶劣的文本膨胀情况。如果这时候UI不崩，那真到了德语、俄语阶段就相对安全。
但这还没完，还有更棘手的双向文本（Bi-directional Text，简称BiDi）。阿拉伯语和希伯来语是从右往左读的（RTL），但里面的数字和英文术语又要从左往右读（LTR）。这就意味着你的整个页面布局要镜像翻转，连图标里的箭头方向都得改。想象一下，一个原本左对齐的导航栏，到了阿拉伯语版本突然右对齐，但里面的用户名显示成了"张三 -> 欢迎"（实际上应该是"欢迎 <- 张三"），这种细节如果没有RTL测试环境，上线就是灾难。
现代软件离不开动态内容——用户名、数量、日期、文件路径，这些东西都是运行时填充的。开发通常用占位符表示，比如%s、{0}、{{username}}或者%1$d（这个数字表示这是第一个整数参数）。
问题就出在不同的语言语法结构完全不同。英语里的"User %s has uploaded %d files"，到了日语可能需要变成"%sユーザーが%d個のファイルをアップロードしました"（主语和宾语的位置变了）。更麻烦的是复数形式——英语就单复数两种，但波兰语有三种复数形式（one, few, many, other，取决于具体数字），俄语、捷克语也有类似的复杂规则。
如果开发用的i18n框架不支持复数规则本地化（比如gettext的msgid_plural机制，或者ICU Message Format），翻译人员只能通过注释告诉开发"这里要判断数字是不是1、2-4、还是5以上"，但人工传递这种逻辑，出错率是百分之百。
还有那种字符串拼接的骚操作。我见过有系统把句子切成三段："您有"、"3"、"个新消息"。这在中文里勉强能读，但到了法语，"3"后面跟的词要根据数字变成"nouveau message"（单数）或"nouveaux messages"（复数），而且"您有"在法语里要根据用户性别变化（"Vous avez"不变还好，但如果是"他/她有"就麻烦了）。康茂峰的技术团队遇到这种案子，通常会建议客户重构代码，改用完整的句子模板，而不是碎片化拼接。
虽然现在已经是2024年了，但你永远无法低估编码问题的杀伤力。UTF-8基本已经是标配了，但总有一些遗留系统还在用Latin-1或者GBK，或者更糟——混合编码。
最隐蔽的是UTF-8的BOM头（Byte Order Mark）。有些编辑器（对，说的就是某些版本的Windows记事本）保存UTF-8文件时会偷偷在文件开头加上三个字节（EF BB BF）。这在文本编辑里看不见，但程序读取时如果没想到要去处理BOM，可能会把这三个字节当成字符串的一部分，导致配置文件解析失败、JSON校验错误，或者更玄学的是——编译通过了，但运行时某个关键判断逻辑一直走不通，因为那个字符串开头其实有三个不可见的"鬼字符"。
还有组合字符的问题。越南语里的"ể"可以是一个单独的字符（U+1EC3），也可以是"e"（U+0065）加上上声调（U+0302）和重音（U+0300）组合而成。这两种方式在视觉上完全一样，但在计算机眼里是完全不同的字节序列。如果你的字符串匹配、搜索或者排序逻辑没考虑到Unicode规范化（Normalization），就会出现"看起来一样却搜不到"的灵异事件。
更别提Emoji了。现在连B2B软件都得支持
