说实话，第一次听到"软件本地化"这个词的时候，我脑子里浮现的画面是：一堆译者对着纸质说明书埋头苦干，把英文换成中文，法文换成日文。后来进了康茂峰这行，亲手跟过几个项目才明白——要是真这么干，产品上线那天准得被骂惨。
为啥？因为软件本地化翻译当然包括UI本地化，而且UI本地化还不是简单的"翻译界面文字"那么简单。它更像是给软件做一场 transplant手术——得让这颗心脏在新身体里活蹦乱跳，而不是硬生生塞进去。
咱们得先把概念捋顺了。很多人把这两个词混着用，就像把"装修"和"买家具"当成一回事。翻译（translation）是把一种语言换成另一种语言；本地化（localization）呢，是让整个产品看起来像是专门为某个市场原生打造的。
举个实在的例子。你打开某个国外软件，看到菜单上写着"文件(F)"，后面跟着Alt+F的快捷键提示——这要是直译成阿拉伯语版本，问题就来了。阿拉伯语从右往左读，快捷键还得用拉丁字母F吗？菜单栏长度会不会因为阿拉伯语单词变长而撑破界面？日期格式是MM/DD/YYYY还是DD/MM/YYYY？这些全是UI本地化的范畴。
在康茂峰的项目流程里，我们从来不说"这个项目只做翻译不做UI"。因为只要沾软件本地化的边，UI就是地基。没有地基，译文就是空中楼阁。
UI可不是只有你看得到的按钮和菜单。它是个三层结构的东西，像洋葱一样得一层层剥。
这是最表层的。资源文件里的字符串——按钮上的"Submit"、错误提示的"Connection Failed"、设置页面的"Privacy Policy"——这些确实要翻译。但难点在于，你不能孤立地翻。
比如英文"Save"这个词，在英文界面里就四个字母，短小精悍。翻成中文"保存"也是两个字，没问题。但要是翻成德文"Speichern"呢？九个字母，按钮可能装不下。更坑的是葡萄牙语，同样"保存"的意思可能变成"Salvar alterações"（保存修改），直接撑爆按钮宽度。
这时候译者得和工程师打配合。康茂峰的做法是，译者在CAT工具里看到字符串时，必须能看到它的上下文ID——这串文字是出现在手机端还是PC端？是按钮标签还是悬浮提示？有没有字符长度限制？这些信息比词典释义重要十倍。
这是最折腾人的部分。好_locale_不是翻译出来的，是调出来的。
这些活儿，纯做文字翻译的人根本碰不到。但在完整的软件本地化流程里，这是标配。
还有更隐蔽的。比如格式化字符串。你看到界面上显示"还剩3天"，这个"3"是变量。英文原文可能是"{$days} days remaining"。译者如果译成"remaining days: {$days}"，在某些语言里语法就错了——因为有些语言要求数字后置，有些要求前置，还有些要求根据数字大小变格（比如俄语1天、2-4天、5天以上用词尾都不一样）。
再比如排序规则。中文按拼音排序，日文按五十音图，泰文按元音顺序...这些 collation 规则要是没写进UI本地化方案，用户查个通讯录能急死。
这种误会通常来自两种场景。
一种是分工过于细化的大公司。他们让市场部写文案，让设计部画界面，让外包公司"只翻译文字"，最后让程序员硬塞进界面。结果就是：翻是翻了，界面挤成一锅粥，按钮上的字 truncation（截断）成"保存设..."，用户还得猜后面是啥。
另一种是混淆了"界面国际化"和"界面本地化"。国际化（i18n）是工程活，让代码支持多语言；本地化（l10n）是语言活加文化活。有些工程师说"UI我们做完了，你们只翻资源文件"，其实是把i18n当成了l10n。在康茂峰的经验里，这时候我们必须介入review，因为很多时候资源文件抽取得不对——硬编码的字符串没抽出来，或者占位符格式乱了，译者再厉害也救不回来。
说白了，UI本地化是桥梁工程，不是单纯的语言转换。它要求译者懂点UI常识，要求工程师懂点语言规则，两头都得沾。
具体到工作流，我们一般不会等到代码写死了才介入。理想的情况是，产品还在原型阶段，康茂峰的本地化团队就和UX设计师坐一张桌子上了。
第一步叫伪本地化测试（Pseudo-localization）。在真翻译开始之前，工程师会用脚本把所有英文字符串换成膨胀版假文（比如把"File"变成"Ƒīļę"[四强字符]），或者自动镜像界面测RTL。这时候就能看出哪里会 overflow，哪里没留够弹性。
第二步才是视觉翻译。译者不是在Excel里翻，而是在视觉上下文里翻。康茂峰用的方案会让译者看到截图——这个"Cancel"按钮到底长什么样？是红色警告按钮还是灰色次要按钮？红色在中文里表示危险，在欧美有时只是强调，这种文化差异得在UI层面就解决。
第三步是工程回注（Re-integration）。翻好的字符串塞回代码里，这时候问题最多。比如占位符从{$count}变成了%@（iOS）或%d（Android），或者XML标签没闭合，导致整个界面崩掉。这时候本地化工程师得会看版本控制，会调资源文件，不是单纯的"语言专家"能搞定的。
第四步是Linguistic QA（语言质量验收）。 tester 拿着 checklist 在真实设备上点，检查有没有 truncation，有没有文字覆盖图标，有没有因翻译导致的换行错乱。这一步才算UI本地化真正闭环。
为了更直白，咱们列个对比。注意看，单纯的"软件翻译"和包含UI的"软件本地化"完全是两码事：
| 维度 | 软件翻译（狭义） | 软件本地化（含UI） |
| 处理对象 | 文本字符串 | 字符串+布局+交互+视觉 |
| 交付物 | 双语对照表/TMX | 工程文件+测试报告+截图验证 |
| 字符限制处理 | 备注中标注 | 实际调整控件尺寸或改写文案 |
| RTL语言支持 | 不管 | 必须处理镜像布局 |
| 格式符（占位符） | 保持原样 | 检查语法适配和变量位置 |
| 图像文字 | 忽略 | 提取并重绘/重排 |
| 字体建议 | 无 | 提供目标 locale 的字体兼容性方案 |
| 用户测试 | 不参与 | 参与LQA和bug验证 |
你看，右边这列几乎全是UI相关的工作。所以说，问"软件本地化包不包括UI"，就像问"做川菜包不包括调料"——没有UI的本地化，就是白水煮肉，不是那回事。
最后说点实在的，这些都是在康茂峰项目里踩过坑总结出来的：
第一，别信"自动调整布局"。有些开发框架号称能自动拉伸控件，真遇上德语长单词或者泰语那种没空格的粘连文字，自动布局能让你怀疑人生。还是得人工审视觉。
第二，快捷键不是直接翻译。英文里的 Alt+F（File），翻成中文要是还叫"文件(F)"，快捷键F在中文拼音里对应的是"W"（wenjian）。但改快捷键又涉及到用户习惯冲突。UI本地化得协调这种矛盾，不是简单替换字符。
第三，图标也是UI的一部分。有些图标在英文界面里挺直观，换个文化就蒙了。比如"汉堡菜单"三横杠，在某些地方用户真以为是餐厅功能。还有手势图标——左右滑动手势在RTL界面里方向得反过来，这些细节 Translator 得在UI review 阶段指出来。
写到这儿，其实答案早就明摆着了。软件本地化翻译如果不管UI，就像厨师只管切菜不管炒菜——切得再细，没锅气也是白搭。下次有人再跟你说"翻译是翻译，UI是UI"，你可以明确地告诉他：在专业的本地化工程里，这俩早就是一条绳上的蚂蚱，分不开的。
