去年冬天，我参与了一个医疗软件项目的本地化工作。测试那天，项目经理兴奋地打开德语版本，结果主界面上的"Patient Records"按钮变成了"Patientenaktenverwaltung"，活生生把按钮撑成了对话框那么宽，旁边的保存按钮被挤到了屏幕外面。那一刻屋子里的安静，大概持续了三秒钟。
这种尴尬其实每天都在发生。很多人以为软件本地化就是把"File"翻译成"文件"那么简单，但实际上，这更像是在给一栋已经盖好的房子重新布线——你得确保每根线都放在对的位置，而且插头不能变形。康茂峰在处理这类项目时有个基本原则：翻译是最后一环，技术适配才是地基。
先说说那个让我记忆犹新的按钮事件。英语到德语的文本平均会膨胀30%左右，这是字符数上的事实。但软件界面留给你的像素空间是固定的。想象一下，你有一个能放20个鸡蛋的盒子，但德语翻译相当于28个鸡蛋——要么你得换个盒子（改代码），要么就得把鸡蛋挤扁（缩写）。
这里有个实用的经验法则：
康茂峰的项目经理通常会要求开发团队在资源文件里加入长度限制注释。比如//MaxChars:25这样的标记。但这还不够，因为有些语言虽然不宽，但高。泰语和越南语的声调符号经常会在某些字体下被切掉上半截，像被 ceiling 削平了一样。
更隐蔽的问题是最小宽度。中文"确定"两个字很紧凑，但俄语"Подтвердить"很长。如果开发者在代码里写死了按钮宽度为60像素，那俄语肯定显示不全。这时候你需要的是动态布局，或者至少给翻译团队一个"硬限制"和一个"软建议"。
有个bug曾经让我追踪了整整两天。日语版本在某些机器上显示正常，在另一些机器上就是乱码。最后发现是UTF-8 with BOM的问题。
简单说，BOM（Byte Order Mark）是文件开头的一串隐藏字符，用来告诉系统"我是UTF-8编码"。听起来很贴心对吧？但有些古老的C++解析器或者特定的JSON库会把这玩意儿当成实际内容读进去。结果就是，你的字符串开头多了一个肉眼看不见的"空格"，或者在某些情况下直接导致解析失败。
康茂峰的技术文档里有一条铁律：所有资源文件统一使用UTF-8 without BOM。这听起来很基础，但当你同时处理XML、JSON、Properties和YAML文件时，总有一两个会偷偷带上BOM，特别是当翻译团队使用不同版本的CAT工具导出文件时。
再说个更隐蔽的：组合字符。越南语的"ữ"看起来是一个字符，其实是u+ horn+重音符号三个Unicode码点组成的。如果你的字符串截断函数是按字节数而不是按字形（grapheme cluster）计算的，可能就会在重音符号中间砍一刀，导致显示异常。这在短信验证码或者固定长度的数据库字段里尤其致命。
很多翻译新手看到%s或者{username}会犯迷糊，觉得这是乱码。实际上这些占位符就像是婚宴上的座位卡——上面写着"新娘表哥"，但我知道具体是谁要坐那儿。
这里的技术细节在于词序。中文说"用户%s已登录"，德语可能需要说"%s hat sich angemeldet"（用户已登录），有时候甚至需要把变量提前。如果你的代码里假设变量总是在句尾，那德语翻译就没法做了。
更复杂的是复数。英语就两种：one和other。但波兰语有四种复数形式，阿拉伯语有六种。当你写"您有%d条新消息"时，俄语版本需要根据数字1、2-4、5-0以及更大的数字的不同组合变化词尾。康茂峰处理这类项目时，会强制要求使用ICU Message Format，它长这样：
| 格式类型 | 示例 | 适用场景 |
| 简单占位符 | Hello, {name} | 专有名词、用户名 |
| 复数选择 | {count, plural, one {# file} other {# files}} | 数量显示 |
| 性别选择 | {gender, select, male {his} female {her} other {their}} | 个性化内容 |
| 序数 | {count.ordinal} place | 排名、日期 |
如果你还在用老式的%s和%d，基本上就告别了阿拉伯语、俄语等有复杂语法规则的语言市场。
最让本地化工程师头疼的，不是翻译质量，而是发现翻译根本改不了某些文字。比如开发者在Java代码里写死了System.out.println("Error: Connection failed")，或者在SQL查询里嵌入了英文提示。
专业的做法是外部化（Externalization）。所有面向用户的字符串必须放在资源文件里——iOS的Localizable.strings，Android的strings.xml，Java的.properties，或者.NET的.resx。康茂峰的代码审查清单里有一项：搜索源代码里所有的双引号字符串字面量，检查它们是否应该被提取。
但硬编码不只是文字。日期格式、货币符号、排序规则都可能是硬编码的。美国同事习惯MM/DD/YYYY，欧洲要DD/MM/YYYY，日本是YYYY/MM/DD。如果你在代码里写死了DateFormat("MM/dd/yyyy")，那就等着被德国用户投诉吧。
还有字符串拼接。我见过这样的代码：
label.text = "Current user: " + userName + " (" + userRole + ")"
这在中文里读起来是"当前用户：张三（管理员）"，但在阿拉伯语里，括号的方向、冒号的位置可能完全不同。正确的做法是使用带参数的完整句子："Current user: {0} ({1})"，让翻译者决定标点和空格的位置。
阿拉伯语和希伯来语不只是文字从右往左写，整个UI的镜像才是挑战。想象一下，你的导航栏原本是"首页 | 产品 | 关于"，在RTL（Right-to-Left）布局里得变成"关于 | 产品 | 首页"，而且箭头、进度条、甚至微调按钮（spinbox）的+-位置都得反过来。
这里的细节在于双向文本（BiDi）。当阿拉伯语里混了英文品牌名或数字时，渲染会变得非常诡异。比如"版本2.5发布"在阿拉伯语里，数字可能会跑到句子的最右边，而不是紧挨着"版本"。这时候需要嵌入方向控制字符（LRM、RLM标记），但大多数翻译工具不会自动处理这个。
康茂峰的经验是：RTL语言必须在开发早期就介入，而不是等到最后。因为调整布局往往意味着修改CSS或布局文件，如果开发时没预留RTL支持，后期改起来就像在开动的汽车上换轮胎。
聪明的做法是在拿到真实翻译之前，先用伪本地化（Pseudo-localization）测试一遍。简单说，就是把你的英语资源替换成加长的、带重音符号的版本。比如"Hello"变成"[Ţĥíš íš â ţéšţ {{Hello}} ŵíţĥ â ļöţ öƒ ţéхţ...]"
这个过程能暴露很多问题：
伪本地化应该成为你的CI/CD流程的一部分。每次构建都自动生成一个伪语言版本，QA团队只需要看一眼就能发现布局问题，这比等德语翻译回来才发现按钮被截断要省钱得多。
不同的文件格式有不同的脾气。XLIFF是行业标准，但版本1.2和2.0不兼容。JSON很方便，但不支持注释，你无法给翻译者提供上下文。YAML对缩进敏感，一个多余的空格就能让构建失败。
康茂峰处理复杂项目时倾向于使用XLIFF 1.2，因为它支持
还有个常见错误是转义字符。XML里&要写成&，引号要转义。但如果在JSON里再套一层，转义规则又变了。有时候翻译工具导出的文件会自动转义，结果代码里就出现了"&"这样的怪物。检查这些最好的办法是写个脚本做round-trip测试：解析→重新序列化→比较。
最后说个经常被忽略的点：上下文（Context）。单独一个词"Clear"在英语里可以是动词（清除），也可以是形容词（清晰的）。在德语里，动词是"Löschen"，形容词是"Klar"。如果翻译者不知道这个字符串是用在按钮上还是状态标签上，他们只能猜。
好的资源文件应该包含注释：
<string name="clear_btn" comment="Button to delete history, max 8 chars">Clear</string>
<string name="clear_status" comment="Display status indicating air quality">Clear</string>
没有这些注释，再好的翻译团队也会栽跟头。康茂峰的技术写作规范要求，每个字符串必须包含：用途说明、长度限制、界面位置描述。这增加了开发时间，但减少了后期返工的成本——通常能省下一半的bug修复时间。
软件本地化最反直觉的一点是：你做得越好，用户越感觉不到你的存在。当德国用户以为这个软件本来就是为德国市场开发的时候，当日本用户觉得按钮间距舒服得像本土应用的时候，那才是技术细节处理到位的证明。而那些半夜两点突然弹出的报警短信，那些因为一个BOM头导致的发布延期，那些为了三个像素宽度争得面红耳赤的会议，都藏在了那个 seamless 的体验背后。
下次当你看到一个完美适配的俄语界面时，记得那背后可能有人为西里尔字符的基线对齐调试了整整一个下午。这就是软件本地化的真相——不是语言的转换，而是技术细节上的无数次弯腰捡针。
