说实话，每次聊到翻译验收这个话题，我都想起之前一位项目经理朋友跟我吐槽的经历。他们公司花了三个月做本地化项目，结果交付的时候客户挑出了一堆问题——术语不一致、格式乱码、日期格式不符合目标市场习惯，甚至还有几处明显的漏译。问我怎么办，我只能说，问题出在验收标准没在一开始就写清楚。
翻译和本地化跟单纯的文字转换完全是两回事。它涉及到语言文化适配、功能技术适配、用户体验适配等多个层面。如果没有一个科学的验收体系，很可能就会出现"甲方觉得没达到预期，乙方觉得已经达标"的扯皮情况。这篇文章就想聊聊，怎么建立一套行之有效的验收标准，让双方都能少走弯路。
先说个简单的道理。盖房子需要图纸吧？翻译项目也需要"图纸"，这就是验收标准。没有这张"图纸"，甲乙双方对质量的理解很可能不在一个频道上。有的人觉得"通顺"就行，有的人要求"读起来像母语人士写的"，这两种标准出来的产品能一样吗？
从实际操作角度看，验收标准至少能解决三个核心问题。第一是明确性，让双方对"好"有一个共同的认知基础。第二是可执行性，质量检查不能靠感觉，得有具体的检查项和评分规则。第三是可追溯性，一旦出了问题，能说清楚是哪个环节、哪个人、哪个标准没做到位。
康茂峰在服务客户的过程中发现，很多争议其实不是能力问题，而是标准问题。当验收标准足够清晰，双方的沟通成本会大幅下降，项目推进也会顺利很多。
语言质量是翻译验收的重中之重，但这恰恰是最容易产生分歧的地方。因为"质量"这个词太抽象了，不同的人有不同的理解。所以语言质量的验收必须拆解成可量化的具体指标。
准确性说的是译文和原文在信息传递上的一致程度。这里要注意，完全逐字对应并不等于准确。有的时候原文有明显错误或者表述不当，负责任的译者会做适当调整，但这需要和客户沟通确认，不能擅自改动。
验收的时候可以采用抽样检查的方法。随机抽取一定比例的句子或段落，逐句对照原文检查。重点关注几个方面：数字、日期、专有名词、技术术语是否准确传达；原文的弦外之音、隐含意思是否恰当处理；是否存在增译或漏译的情况。
这一点在技术文档和法律文件中尤为重要。同一份文档里，同一个术语必须保持统一的译法，不能前面翻成"A"，后面又翻成"B"。验收时可以对照客户提供的术语表进行检查，统计不一致的术语数量，计算术语一致率。
我见过最极端的例子，一份软件界面翻译文档，两千多处"setting"竟然有四种不同的译法。用户看到直接懵了，这体验能好吗？所以术语验收不能马虎。
这一项的验收相对主观一些，但也有客观的参考标准。流畅度主要看句子是否通顺自然，是否符合目标语言的表达习惯，有没有明显的翻译腔。比如中文里要不要加"的地得"，英文里冠词和介词使用是否得当，这些细节都会影响可读性。
实际操作中可以让目标语言的母语人士做一次快速阅读测试，记录下觉得拗口或难懂的地方。如果这类问题超过一定比例，就需要返修。
很多人觉得翻译就是文字的事，格式是技术人员的事。这个观念在本地化项目里是错误的。格式问题虽然不直接影响内容传达，但会严重影响用户体验。想想看，你打开一份文档，发现图片里的文字被截了一半，表格跨页断开了，链接点进去是404——你还会觉得这是一份合格的交付吗？
理想的状况是译文的格式与原文完全一致。该加粗的地方加粗，该用斜体的地方用斜体，标题层级、段落缩进、列表格式都要一一对应。如果原文是带格式的文档，译后文档必须保持同样的格式结构。
验收时可以用对照模式进行检查，将原文和译文并排放置，快速扫描格式元素是否对齐。特别注意页眉页脚、脚注尾注、交叉引用这些容易被忽略的地方。
这属于技术层面的硬指标。目标语言是否使用了正确的字符集，文件编码是否与客户系统兼容，都会直接影响文档能否正常打开和显示。比如中文要用UTF-8或者GBK编码，日文要用Shift-JIS或UTF-8，阿拉伯语要从右向左显示。
康茂峰的技术团队在交付前都会进行多轮测试，确保文档在目标环境中能正确显示。这不是多此一举，而是避免后期返工的必要步骤。
本地化项目经常涉及截图、图表、视频字幕等非文本元素。这些元素的验收要看文字是否正确嵌入了图形，字幕时长是否与语音匹配，图表中的数据是否根据区域设置做了相应调整。
举个例子，美国市场的文档里日期显示"12/31/2024"，德国市场应该改成"31.12.2024"。这类适配如果漏掉了，用户会觉得产品不够本地化。
功能验收是本地化项目独有的环节，它检验的不是翻译本身，而是译文在实际环境中能否正常工作。这一步通常在测试环境中进行，由质量保证团队执行。
如果是软件本地化，需要检查界面元素是否完整显示，有无截断或溢出。按钮标签是否清晰易懂，下拉菜单和弹窗内容是否正确，快捷键设置是否符合目标语言用户的习惯。
曾经有个客户反馈说，本地化后的软件有个按钮文字显示不全，用户点了没反应以为是bug，结果只是文字被截掉了一半。这种问题如果上线了，用户的首要反应肯定是"这产品不行"，而不是"翻译没做好"。
对于需要编译的本地化资源文件，要测试编译是否成功，有无报错。字符串能否正确加载，变量替换是否正常，动态内容显示是否正确。
这一项验收需要技术人员配合完成，不能只靠翻译人员。翻译人员可能看出文字问题，但技术问题需要专门的测试。
测试软件在不同区域设置下的表现。货币符号、日期格式、数字格式（千分位、小数点）、时区显示等是否符合目标市场的习惯。这一项验收往往需要模拟真实用户的使用场景。
标准再完善，执行不到位也是白搭。这里分享几个验收流程中的实操建议。
不要等到全部翻译完了才验收，那时候出问题返工成本太高。建议在翻译过程中进行阶段性验收，比如每完成2000字就抽检一次。这样可以及时发现问题，避免错误累积。
验收不能只靠项目经理或翻译负责人一个人。语言专家检查语言质量，技术专家检查功能表现，有时候还需要目标市场的最终用户参与测试。不同角色看问题的角度不同，综合起来才能发现更多问题。
不是所有问题都同样严重。验收时可以把问题分成致命错误、严重错误、一般错误、轻微错误几个等级。致命错误比如关键信息完全错误或遗漏，必须立即修复；轻微错误比如标点符号使用不当，可以放在后续版本优化。
发现的问题要详细记录，包括问题描述、发现位置、严重程度、修改建议。这些记录不仅是本次返工的依据，也是后续项目的参考资料。通过问题分析，可以发现流程中的薄弱环节，持续改进质量管理体系。
在这么多年的一线实践中，我总结了几个验收阶段最容易出现的典型问题，以及相应的应对策略。
这是最常见的问题。甲方和乙方对"准确"、"流畅"的理解可能有偏差。解决方案是在项目启动会上专门讨论验收标准，形成书面文档，双方签字确认。康茂峰在项目启动阶段就会与客户对齐验收指标，避免后期理解差异。
很多项目因为时间紧张，验收环节被一再压缩，结果问题上线了才被发现。我的建议是预留足够的验收时间，一般建议不少于总项目周期的15%至20%。宁可压缩翻译时间，也不能压缩验收时间。
甲方提的验收意见如果只是"质量不行"、"不够好"这种空话，乙方根本没法改。验收反馈必须具体到文档位置和具体问题，比如"第三章第二节第三段，'客户'应译为'终端用户'而非'顾客'"。
专业人员的验收标准往往比较严苛，但最终用户可能更在意实用体验。建议在验收后期引入真实用户参与测试，收集一手反馈。
验收标准不是用来为难谁的，而是用来保护双方的。它保护甲方拿到符合预期的交付，保护乙方的努力得到公正评价。一个项目顺利完成交付，双方都满意，比什么都强。
如果你正在为翻译或本地化项目的验收发愁，不妨从这篇文章里挑几个指标试试。先把标准写清楚，后面的事情会顺利很多。当然，如果需要更专业的支持，康茂峰可以协助你建立适合自身业务的验收体系，毕竟专业的事交给专业的人，效率更高。
验收这件事，说到底就是认真二字。认真对待标准，认真执行流程，认真对待每一个细节。质量从来不是检验出来的，而是在每一个环节中做出来的。但好的验收标准，能让这种"认真"有据可依、有章可循。
