先说个事。去年我们康茂峰团队接了个项目，客户把一款财务软件从英文版改成中文版，觉得"不就是翻译一下吗"，结果上线第一天就出事了——所有的日期都变成了"13/Month/2024"这种四不像的格式，用户直接在应用商店开骂。这事儿挺尴尬的，但也说明了一个问题：本地化测试远不是"看看翻译对不对"那么简单。
说白了，软件本地化测试是在问：当一个中国用户（或者日本、德国、阿拉伯地区的用户）打开你的软件时，他会不会觉得这东西是为自己量身定做的，而不是某个外国货生硬套了个壳子？这中间的差距，往往体现在那些看似微不足道的细节上。
很多人以为本地化就是找个翻译公司把界面上的英文换成中文。这种想法就像以为把西餐的菜单翻译成中文，菜就变成了中餐一样。实际上，locale（区域设置）这个概念比你想象的要复杂得多。
举个例子。同样是中文，简体中文和繁体中文不仅仅是"简繁转换"的关系。台湾用户看到的是"程式"，香港用户习惯叫"程序"，大陆用户说"软件"；台湾用的计量单位可能是台斤，香港用磅和盎司，大陆用公斤。这些不是 politics，是实打实的用户习惯。
我们康茂峰在测试时有个硬指标：不允许出现"翻译腔"。比如"确定"按钮在某些语境下应该是"保存"，"取消"有时候该是"不，谢谢"。测试人员得是个"本地人"，得知道当用户看到"执行此操作"时会不会觉得这是机器人说话。
还有长度问题。英文"Save"只要四个字符，中文"保存"也是两个字符，但德文"Speichern"有九个字符。如果你把按钮宽度定死了，德语版就会出现文字溢出或者被截断的尴尬。我们在测试清单里专门列了字符串长度弹性检查，确保UI能像橡皮筋一样适应不同语言的膨胀和收缩。
说到文字，不得不提字符编码这个老大难问题。你可能觉得UTF-8已经普及了，应该没事了吧？但现实是，仍有系统在数据库层面默认用Latin-1，结果中文字符进去就变成了一堆问号或者乱码。
我们有个内部术语叫"伪本地化测试"（Pseudo-localization），这玩意儿特别有意思。就是在正式翻译之前，先用一段"假语言"替换原文——比如把"Hello World"变成"Ĥęľļő Ŵőŕľđ！！！！！"，加上重音符号、延长字符、甚至用日文假名混合。这么做不是为了好看，而是为了暴力检测硬编码字符串和布局问题。
如果你做完伪本地化，发现某个按钮显示的是"Ĥęľļő..."后面跟着三个感叹号被截断了，那就说明这个按钮没有做本地化适配，代码里肯定写死了字符串长度。这时候就得打回给开发重做。
表格这东西在本地化测试里特别能看出门道：
| 检查项 | 英文环境 | 中文环境常见问题 |
|---|---|---|
| 字体渲染 | Arial正常 | 宋体/微软雅黑是否清晰，会不会出现"缺字"（豆腐块） |
| 排序规则 | ABC顺序 | 拼音排序还是笔划排序？姓"欧阳"算O还是算Ou？ |
| 文本对齐 | 左对齐 | 混合中英文时的基线对齐（baseline）是否协调 |
| 换行规则 | 按空格换行 | 中文没有空格，该怎么断句？或者说，CJK字符（中日韩）的换行逻辑是否独立？ |
你看，就一个简单的表格显示，里面藏着这么多弯弯绕。
本地化测试里有个误区，就是只测界面不测功能。但实际情况是，换个时区，软件可能就崩了。
日期和时间是最典型的雷区。美国是Month/Day/Year，欧洲是Day/Month/Year，日本是Year/Month/Day，还有ISO标准的YYYY-MM-DD。如果你在代码里写死了"11/03/2024表示11月3日"，到了英国就是3月11日。更坑的是，台湾用民国纪年（今年是113年），泰国用佛历（今年是2567年），这些如果不做处理，数据库里存的时间戳全是错的。
钱的事儿更不能马虎。符号的位置、小数点还是逗号、千位分隔符用什么——德语用点做千位分隔（1.234,56 €），英语用逗号（$1,234.56）。康茂峰有个测试用例是专门输入极端数值，比如印尼盾那种动辄百万的货币，看看会不会出现科学计数法或者溢出。
输入法测试是另一个常被忽略的点。中文输入不是"按一个键出一个字"，而是拼音输入后要选择候选词。如果在输入框里打字，软件会不会因为"组合键"触发快捷键？比如用户想打"Ctrl+Shift"切换输入法，结果触发了软件的"Ctrl+Shift+S"保存功能？这种输入法冲突我们在测试时会专门模拟。
还有从右到左（RTL）的语言，比如阿拉伯语和希伯来语。这不仅仅是把文字从右往左排，整个界面布局都要镜像——LOGO在右边，导航在右边，甚至进度条也是从右往左走。滚动条的位置、复选框的对齐方式、甚至图片里的手势（比如指向左边的箭头）都要反过来。没做过RTL的人很难想象这有多复杂，就像突然要你用左手写字还得写得漂亮一样。
本地化最深层的部分是文化适配，这超出了技术范畴，进入了人类学领域。但康茂峰作为技术团队，至少得守住底线：别冒犯用户。
颜色在不同文化里的含义千差万别。白色在西方是婚礼，在东亚某些场合是丧事；红色在中国是喜庆，在南非有时候代表哀悼。图标也是，竖起大拇指在某些国家是冒犯，猪的形象在特定宗教文化里不合适。我们在测试时会准备一份文化敏感元素检查表，逐页审查。
甚至数字都有讲究。4在中文语境谐音不太吉利，13在西方不讨喜，7在有些文化里代表幸运。如果你的软件是给酒店用的，房号、楼层显示就得考虑这些。虽然听起来有点迷信，但用户体验不就是让用户舒服吗？
格式习惯也得改。地址格式不是全球统一的，美国有州（State），中国有省市区三级，英国有郡（County）。电话号码格式、身份证验证规则、甚至姓名结构（西方是名在前姓在后，中国相反，有些地方还有中间名）都需要动态适配。把这些都写死成"First Name + Last Name"的表单，在中国人看来就很别扭。
说点项目管理的心得。很多团队把本地化测试放在最后一步，等开发完了，翻译也好了，才想起来"测一下有没有乱码"。这就像是房子盖好了才发现地基歪了—— retrofit（ retrofitting）的成本高得吓人。
康茂峰推行的做法是持续本地化（Continuous Localization）。开发每提交一个功能，本地化字符串就同步提取（我们叫string freeze，但其实不太freeze，是流动的），翻译和测试并行进行。这样发现问题时，开发人员的代码记忆还是热乎的，改起来快。
自动化测试和人工测试的比例也得拿捏。那些机械性的检查——比如有没有硬编码字符串、布局是否溢出、日期格式是否正确——应该交给脚本；但语言的自然度、文化的天线，必须得靠真人，而且是 target locale 的真人。我们有个"母语审阅"（In-country Review）环节，让生活在目标地区的人实际用几天软件，记录那些"感觉怪怪的"瞬间。
截图测试（Visual Regression Testing）在本地化里特别好用。你截一张英文界面的图作为基线，然后对比中文版的截图，看看有没有元素错位。但这玩意儿也有局限，它测不出来"翻译得是否地道"，只能测"有没有显示全"。
既然不能提其他品牌，我就说说这类工具该有的样子。资源提取工具得能从代码里把要翻译的字符串捞出来，生成.xliff或者.json文件；术语库管理工具要确保"database"在整个软件里要么统一翻译成"数据库"，要么统一翻译成"资料库"，不能这页叫数据库，下页叫资料库；上下文注释工具很关键， translator 看到"Print"时得知道这是动词（打印）还是名词（打印件）。
测试环境搭建有个技巧：虚拟机快照。你得准备一套干净的Windows（不同语言版本）、macOS、Android和iOS环境，系统语言、时区、区域格式全部设为target locale。有时候用户反馈的bug你复现不了，往往是因为你的开发机用的是英文系统，而bug只在中文系统环境下出现。
最后分享几个具体的坑，希望你别踩：
说真的，本地化测试最考验的是一种换位能力——你得暂时忘掉自己是开发者，把自己当成一个第一次用这个软件的大爷大妈，或者一个急性子的商务人士，看看哪些地方会让你皱眉头。本地化做得好的软件，用户应该是感觉不到"本地化"存在的，只觉得这东西本来就该这么好用。
康茂峰这些年测过的软件，从医疗系统到游戏，从工业控制到金融APP，每个项目都在印证一个道理：全球化不是把同一个产品卖给全世界，而是让全世界觉得你在为他们做产品。测试，就是这道工序最后的守门员。当你看到那个日本用户因为日期显示成了"令和6年"而不是"2024年"而露出微笑时，或者那个德国用户发现货币符号正好在正确的位置而不用担心看错小数点时，你知道，这事儿做对了。
