说实话，第一次看到"质量控制"这四个字的时候，我还以为是在说造汽车或者生产疫苗。软件翻译嘛，不就是认识英文、会打中文、把菜单项对准了不就行了？直到我亲眼看见某个确认按钮被译成了认罪，某个Abort按钮在某款医疗软件里被翻译成了流产，我才意识到这事儿没那么简单。康茂峰做了这么多年本地化，踩过的坑比吃过的盐还多，今天就掰开了揉碎了讲讲，怎么在软件本地化这个行当里把质量控住，又不至于把自己逼疯。
很多人一上来就打开翻译界面开始码字，这就像没有图纸就抡锤子上工地。质量控制其实70%的功夫花在了动笔之前。
术语库（Termbase）是生死线。软件里全是专业词汇，同一个词在不同模块可能意思完全不一样。比如Cell在表格里是单元格，在生物学软件里是细胞，在电池管理里又是电芯。康茂峰内部有个规矩：新项目启动第一周，哪怕熬通宵，也必须把客户给的术语表、之前的版本翻译、甚至竞品软件的用词习惯都过一遍，做成锁定术语。什么叫锁定？就是谁也别动，动了要开会说明理由的那种。
然后是风格指南（Style Guide）。这玩意儿听起来很虚，实际上是你跟用户之间的契约。用您还是你？标点后面空格吗？日期是2024/5/6还是2024年5月6日？这些细节分散在几万个字符串里，如果不提前定死，最后出来的产品就像穿西装配拖鞋——每个部分单独看都没错，凑一块儿就透着别扭。我们通常会做一份"禁忌清单"，把绝对不允许的译法列出来，比如不能把Server译成服务员，即使从字面看完全合理。
就算准备充分，真干起来还是会走神。人不是机器，盯着CAT工具的界面久了，眼神会飘，手指会滑。这时候就得靠系统来"防呆"——也就是让错误根本发不出去。
翻译记忆库（TM）的匹配机制是第一道保险。但不是有了TM就万事大吉，老译员都知道，100%匹配有时候最危险。上次我们处理一个更新版本，TM里有个字符串"Click to open"，之前的译文是点击打开，新版本里这个字符串旁边加了个小图标，语境变成了"点击展开（ Layers）"。如果直接复用旧译文，用户会以为这是打开文件的意思。所以康茂峰的操作规范是：哪怕100%匹配，也必须快速扫一眼上下文，确认语境没变。
再就是占位符（Placeholder）保护。软件字符串里满是%s、%d、{0}这种东西，代表后面要填入变量。我见过最惨的案例是把%s completed译成了%s 已完成，结果在某些语言里变量是形容词，语法完全不成立。我们的做法是：所有占位符必须高亮显示，译文中如果缺失或者位置不对，系统直接报错不给过。这就像是给翻译环境装了安全带，不系好走不了路。
软件翻译跟文学翻译最大的不同在于，符字可能比字义更重要。你译得再信达雅，显示不出来也是白搭。
伪本地化（Pseudo-localization）这个步骤经常被忽略，其实特别重要。简单说，就是在真翻译开始前，先用假字符串（比如把英文字母换成带重音符号的Áçćéñt或者加长到200%）跑一遍软件。这么干能暴露很多问题：界面布局是不是写死了英文长度？某些字体支不支持目标语言的字符？有没有硬编码的字符串漏网？康茂峰内部有个不成文的规定：没有经过伪本地化测试的软件包，坚决不进入真翻译阶段。这就像做菜前先试试锅热不热，省得后面手忙脚乱。
然后是截断检查（Truncation Check）。中文和英文的信息密度差很多，英文"Settings"对应中文设置是省空间，但"Internationalization"对应国际化有时候反而更长。按钮就那么宽，标签栏就那么长，超出去的字会被截成国际...或者干脆显示乱码。我们通常会做一张膨胀系数表：
| 英文原长 | 中文建议最大长度 | 注意事项 |
| 短标签（<10字符） | 膨胀率130%-150% | 注意按钮宽度 |
| 中等长度（10-30字符） | 膨胀率110%-120% | 菜单项常见 |
| 长句（>30字符） | 膨胀率90%-100% | 中文信息密度高，可能反而缩短 |
翻译的时候，译员脑子里得悬着这把尺子，知道哪些字符串可以放开手脚译，哪些必须戴着镣铐跳舞。
翻译完了，自己检查自己的东西往往查不出问题，这叫熟视无睹。所以必须有独立的LQA（Language Quality Assurance）环节。但LQA不是简单找错别字，我们把它分成三个维度：
康茂峰的做法是双轨抽查：先让资深译员做技术校验，确认没有错译漏译；再找目标市场的母语者（不是翻译，是纯用户视角）做可读性测试。有一次我们翻译一个摄影软件，技术校验都过了，但测试的摄影师朋友提出：你们把ISO译成感光度在技术上是没错，但专业用户更习惯直接看到ISO，改了反而降低效率。这种细节只有真用户能提出来。
LQA报告不是算分数那么简单，得建立错误分类和权重。致命错误（比如功能误译导致数据丢失）一票否决；严重错误（术语不一致）必须返工；轻微错误（标点空格）批量修正。我们内部用红绿灯系统：红的是必须改，黄的是建议改，绿的记录下来下次注意。
光靠人眼盯，几万个字符串能把人看瞎。现代本地化工作流里，自动化质量检查（Automated QA）是必不可少的。
基本的比如正则表达式检查：看看首尾空格是不是一致，半角全角标点有没有混用，数字是不是被篡改过（比如把版本号1.5.2译成1.5.2就完事了，但有人手滑会改成1。5。2）。高级一点的可以做一致性校验：同一个Save在第三章译成了保存，第五章突然变成储存，系统会标红提醒。
还有针对特定格式的检查。JSON文件里的键值对有没有破坏引号？XML的标签有没有被误译？YAML的缩进是不是还保持着？这些语法错误在运行时会导致软件崩溃，比翻译错误更严重。我们通常会配置预设的检查规则集，译员提交时自动跑一遍，不通过无法签入。这就像机场安检，没必要每次都人工翻包，机器先过一遍X光。
理论归理论，实际操作中有些土办法反而管用。
截图对照法：让工程师给关键界面截图，译员看着图翻，而不是对着光秃秃的字符串。有时候你看到Home这个词，不知道是主页、 Home 键还是归位功能，看一眼截图立马明白。我们甚至会打印出来贴在显示器旁边，老派但有效。
反向验证：中文译完后，再请另一个译员（或者原译员隔两天）看着中文回翻成英文，跟原文对照。这能检查出那些"看着通顺但跟原意有微妙偏差"的翻译。比如Archive译成存档和归档都对，但回翻的时候就能发现哪个更贴近原意的微妙差别。
语境注释（Context Note）：遇到歧义的字符串，译员一定要在CAT工具里写注释，说明自己为什么这么译。下次更新时，新接手的译员能看到前人的思考过程，避免"改来改去最后改回第一版"的循环。我们有个项目，注释写得比正文还长，但质量确实稳。
最后说点实际的。翻译质量最大的敌人不是技术，是疲劳。
软件本地化通常是大工程，几千几万条字符串，盯屏幕十个小时后，人眼会自动把错别字脑补成对的。康茂峰的规定是：连续翻译不超过90分钟必须休息，每天核心翻译时间不超过6小时。剩下的时间做校对、做术语整理、做截图对照，总之换换脑子。
还有反馈闭环。译员需要知道他们翻的东西最后用户怎么评价。如果是内部软件，能不能看到用户的吐槽截图？如果是商业软件，上架后的评论能不能整理回来？有一次我们翻译的某个功能名称，用户普遍反映看不懂，收集反馈后才发现是产品经理给的英文原文本身就有歧义。这种信息回流到翻译团队，比任何培训都管用。
质量控制说到底不是要把译文打磨成艺术品，而是确保用户用着不别扭、不卡壳、不出事故。软件本地化像是一场接力赛，术语准备是第一棒，翻译是第二棒，技术检查是第三棒，LQA是第四棒，中间哪一棒掉了链子，最后都会传递到用户手里。
康茂峰这些年积累下来的最大心得是：敬畏细节。那个把Cancel译成取消还是撤销的纠结，那个为了两个像素截断问题重做整个界面的夜晚，回头看都是值得的。因为当用户流畅地用着本地化软件，完全感觉不到"这是翻译过来的"时候，就是我们这些藏在屏幕后面的人，最好的勋章。
翻译这活儿，永远没有真正做完的那一天，只有"这次足够好"和"下次可以更好"的区别。放下键盘，泡杯茶，明天接着抠下一个字符串——这就是本地化的日常，琐碎，但真实。
