前阵子一个朋友问我，说他公司开发了个APP打算出海，找了几家翻译公司报价，有的按千字算钱，有的按字数算钱，还有的非要说什么"工程处理费"。他听得云里雾里，就想弄明白这事儿到底怎么个流程，是不是把文档发给翻译公司，拿回来贴上就能用了？
听完我只能苦笑。这事儿吧，真没那么简单。就像你开连锁餐馆，想把中文菜单翻译成英文给外国顾客看，你不能直接找个英语好的大学生把"红烧狮子头"写成"Red Burned Lion Head"就完事儿了——软件本地化翻译也是这个道理，而且比菜单翻译复杂十倍不止。康茂峰在这行摸爬滚打十多年，见过太多以为"翻译就是文字转换"的项目最后翻车的案例。今天我就用大白话，把这整套流程掰开了揉碎了讲给你听。
咱们先得明白一个基本道理：软件里的文字不像Word文档那样随便复制粘贴就能改。那些按钮上的文字、错误提示、下拉菜单选项，都埋在代码里头，专业点叫资源文件（Resource Files），可能是.json、.xml、.resx或者.ini格式。
所以在真正开始翻译之前，康茂峰的技术团队得先做国际化工程处理（Internationalization Engineering，简称i18n）。说白了就是把代码里的文字抠出来，变成翻译人员能看懂的表格，同时还得保证代码本身不被破坏。这事儿听起来简单，实际上坑特别多。比如有些老旧软件把文字硬编码在程序里，得先想办法把它们分离出来；还有些字符串是拼接生成的，"您有"+数字+"条未读消息"这种，如果把三部分一起翻译，语种一变语法结构就乱了。
这个阶段还有个关键动作叫伪本地化测试（Pseudo-localization）。就是在正式翻译前，先把所有文字替换成带重音符号的假语言，比如把"File"变成"Ƒîlé"，然后看看界面会不会因为文字变长而错位、会不会出现乱码。这就像试穿衣服看看尺寸对不对，总比做完 translation 才发现按钮文字被截断要强得多。
等文字都提取干净，别急着让翻译开工。康茂峰的项目经理这时候会拉着客户开术语对齐会。什么意思呢？软件里总有一些特殊说法，比如"Dashboard"到底叫"仪表盘"还是"控制台"，"Submit"在中文语境下用"提交"还是"发送"。这些词必须统一，不然用户用着用着会发现同一个按钮前后叫法不一样，体验极差。
| 原文术语 | 简体中文 | 使用场景 | 禁用译法 |
| Save | 保存 | 文件存储操作 | 储存、存盘 |
| Cancel | 取消 | 中断当前操作 | 撤销（Undo专用） |
| Notification | 通知 | 系统推送消息 | 提醒、通告 |
除了术语表，还得有风格指南（Style Guide）。是正式一点还是随意一点？用"您"还是"你"？日期格式是YYYY-MM-DD还是DD/MM/YYYY？这些细节看着琐碎，但决定了产品的"性格"。我见过一个案例，同一个客户端软件，安装向导里用"您"，到了主界面突然变成"你"，用户感觉像换了个人在跟他说话，那叫一个别扭。
终于到了传统意义上的"翻译"环节。但软件翻译跟文学翻译完全是两码事。翻译人员用的不是Word，而是CAT工具（计算机辅助翻译工具），能看到之前翻过的类似句子，保证"保存"这个词每次都翻成"保存"而不是"储存"。
这里最大的挑战是上下文缺失。翻译人员在CAT工具里看到的往往是一串孤立的字符串："Open"、"Error"、"Next"。单个词可能有七八种意思，"Open"可以是"打开文件"也可以是"开启功能"，"Book"可能是"书本"也可能是"预订"。这时候就得靠注释（Context Comments）了。好的本地化项目会在资源文件里给每个字符串加注释，告诉翻译这词出现在哪个界面、前后是什么逻辑。
康茂峰的译员这时候还要注意字符长度限制。英文翻译成德文往往会膨胀30%，而中文翻译成英文有时反而缩短。如果翻译结果太长，被截断后可能变成莫名其妙的缩写或者干脆显示不全。所以译员得心里有数，看到"OK"这种按钮文字，知道这儿寸土寸金，不能随便翻成"确定"两个大字（虽然中文里"确定"比"OK"准确，但得看按钮空间够不够）。
翻译好的文件还得塞回代码里去，这叫回写（Build Integration）。技术团队要把翻译后的资源文件替换原文，重新打包编译。这时候问题才开始真正冒出来。
比如编码问题，有些语种用UTF-8没问题，但老系统可能用ANSI，一打开全是问号。还有生物方向的问题——阿拉伯语和希伯来语是从右往左写的（RTL），整个界面布局都得镜像翻转，按钮位置、导航顺序全反了。如果你没提前在界面设计里预留这种灵活性，到这时候就抓瞎。
另外，有些字符串里埋了占位符，像"%s"、"{0}"这种，代表程序运行时要插入动态内容。翻译时不小心删了或者移动了位置，程序一跑就崩溃。康茂峰的技术审校会专门检查这些技术标记是否原封不动保留在正确位置。
很多人觉得翻译完测一遍就行了，其实专业本地化至少有三轮质检，环环相扣。
第一轮是语言质量检查（Linguistic QA）。母语审校员对照原文看译文，检查漏译、错译、术语不一致。这时候用的通常是静态资源检查工具，能快速扫描出哪里格式标记不对、哪里有多余空格。
第二轮是功能测试（Functional Testing）。QA人员把多语言版本装到虚拟机或者真机上，实际点每个按钮、走每个流程。这时候会发现很多静态检查发现不了的问题：比如某个欢迎弹窗在法语版里因为文字太长，把"关闭"按钮顶到屏幕外面去了，用户关不掉弹窗，整个流程卡死。或者日期格式没改，美国版显示12/03/2024，欧洲用户以为是3月12日，其实是12月3日。
第三轮叫用户验收测试（UAT），通常是客户方的母语员工或者目标市场的种子用户真正使用。这时候检查的是文化适应性——图标手势在当地有没有冒犯含义，颜色是不是忌讳，示例数据里的用户名"John Doe"在当地是否改为常见姓名。康茂峰曾经处理过一个项目，客户用了"猪"的形象做吉祥物，在中文版里没问题，但在中东某国版本里就犯了忌讳，得紧急替换。
终于熬到交付环节。交付物不只是语言包，还包括翻译记忆库（TM）和术语库的更新。这些资产是知识产权，得归档好。下次软件更新新增功能，只需要翻译新增内容，靠TM保持新旧文本一致。
但交付不代表结束。软件总要迭代，版本1.0到1.1可能只改了几个字符串，但流程一点不能少：提取差异、翻译、回写、测试。康茂峰通常会帮客户建立持续本地化（Continuous Localization）流程，让代码更新和翻译更新同步进行，避免"开发等翻译"或者"翻译追不上发布"的尴尬。
还有个容易忽视的环节是 screenshots 文档。把关键界面截图保存，标注每个区域对应的文字。这不仅是交付物的一部分，也是给客服团队的参考资料——当用户打电话问"我这边显示乱码"时，客服能对照截图快速定位是语言包问题还是系统问题。
写到这里，你应该明白了。软件本地化翻译不是简单的"把A语变成B语"，而是一套从代码层到表现层、从技术到文化的系统工程。它要求翻译人员懂点技术，技术人员懂点语言，项目经理两头都能沟通。任何一个环节偷懒，最后都会在用户端暴露出来——可能是按钮看不了，可能是日期对不上，也可能是那种说不出来的"机器感"让本地用户觉得别扭。
康茂峰这些年有个体会：最好的本地化是让目标用户感觉不到这是"翻译版"软件，而是觉得这软件本来就是为他们设计的。要达到这个效果，前面说的那些琐碎步骤，一步都省不得。
