
上周三凌晨两点,我被客户的微信震醒。不是时差问题,是他们在做电子Patient Reported Outcome(ePRO)系统上线前的最后测试,结果发现西班牙语版本的量表在全屏模式下整个布局垮掉了——所有选项都挤成了乱码。那一刻我突然意识到,很多人以为电子量表翻译就是"把 word 里的文字粘贴到系统里",这个认知偏差大概是本地化行业最贵的学费之一。
所以咱们今天就掰开揉碎了聊聊,电子量表翻译到底有哪些格式上的硬杠杠。不是我吓唬你,这事儿比翻译一份纸质问卷复杂得多,但也绝非玄学。
咱们得先回到基础。什么是量表?就是那些带选项的问卷,比如"您今天感觉如何?1.很好 2.一般 3.很差"。纸质时代,翻译完排版打印,只要字不漏就行。但电子量表——这里指需要嵌入到EDC系统(电子数据采集系统)、eCOA平台或者手机App里的版本——它本质上是一段代码。
用费曼的方式说:纸质量表是画在纸上的画,电子量表是乐高积木搭的城堡。你改动任何一块积木(也就是一个字符),都可能让整座城堡的承重结构出问题。所以格式要求的核心,就是确保你的翻译在变成代码后,不会把系统搞崩。
康茂峰去年处理过一个案例,某国际多中心临床试验的SF-36健康调查简表要进日本市场。客户直接把日文译文丢给程序员,结果系统一跑,所有带浊音符号的平假名(比如"が"、"ぎ")全部显示为方块。查了三小时才发现,是字体库不支持UTF-8编码的扩展字符集。你看,这就是格式意识缺位造成的典型灾难。

聊格式肯定绕不开编码。我见过太多项目经理在这一点上翻车。简单说,UTF-8是电子量表翻译的通用语言,没有之一。别跟我提GB2312或者ANSI,那些是上个世纪的遗物。
但光是UTF-8还不够。你得考虑字节顺序标记(BOM)。有些系统要求带BOM的UTF-8,有些则严格禁止。康茂峰的标准操作是:先问清楚客户的系统架构,如果是基于Java的老系统,通常要保留BOM;如果是Python或Node.js的新架构,往往要去掉BOM。这个细节不会体现在译文质量上,但能让技术对接 smooth 得像抹了黄油。
还有换行符。听起来很 stupid 对吧?但Windows用的CRLF(\r\n)和Unix/Linux用的LF(\n)在字符串处理里完全是两码事。曾经有个项目,德语版本的量表在iOS端显示正常,到了Android端所有换行都变成了小方块,就是因为译文文件里混用了两种换行符。后来我们定了个铁律:所有电子量表译文必须用LF换行,且行尾不能留空格。
电子界面有个物理限制:屏幕宽度。纸质问卷里你可以写很长的句子,但手机屏幕上,德语或者俄语的译文可能比英语长出40%。这时候格式要求就严格起来了。
一般会要求字符长度限制。比如原英语问题"How severe was your pain today?"允许最大字符数是50。翻译成中文"您今天的疼痛程度如何?"才12个字,很轻松。但换成土耳其语"Bugün ağrınız ne kadar şiddetliydi?"就超标了。这时候格式规范要求你必须在译文里标注截断风险,或者提供缩写版本。
康茂峰的做法是给每个字符串加长度警示标签。在CAT工具里设置阈值,超过原文字符长度120%的自动标红。这不算翻译技巧,算是工程意识。毕竟你也不想看到用户在一个手机屏幕上横向滚动才能看完一个问题吧?
电子量表通常以XML或JSON格式交付。这意味着原文里会有大量占位符,比如%s、{0}、[[USERNAME]]。这是格式要求里最反人性的部分——译者看着是正常的句子,但中间插着这些代码标记。
比如原句:"User %s has completed the assessment on %s." 翻译成中文:"用户%s已于%s完成评估。" 看起来简单?但如果你把两个%s的顺序调换了(日语或德语的语法可能会要求这样做),系统就会崩溃——它会按顺序填入用户名和日期,结果变成"日期 已于 用户名 完成评估"。
所以严格的格式规范要求:占位符必须原封不动保留,包括大小写和顺序。如果实在需要调整语序,必须通过注释说明,让程序员在代码层处理变量映射。康茂峰的质检清单里第一条就是"Regex扫描占位符完整性",零容错。
还有XML标签的嵌套。比如原文是<bold>Please select</bold> one option. 你翻译成"<bold>请选择</bold>一项"。看起来没毛病?但如果你不小心把标签断开了,比如"<bold>请选择一项</bold>",虽然视觉上一样,但破坏了原文的标记结构。这种错误在Excel里很难发现,必须导回XML环境才能暴露。
这是最考验格式功力的部分。电子量表往往有复杂的表格布局,比如Likert量表那种五列或七列的选项对齐。

| 问题 | 完全不同意 | 不同意 | 中立 | 同意 | 完全同意 |
| Q1: 药物改善了您的症状 | 〇 | 〇 | 〇 | 〇 | 〇 |
纸质版你可以靠排版软件微调间距,但电子版这些选项是动态生成的。如果德语版的"Stimme voll und ganz zu"(完全同意)太长,把列宽撑大了,而前面中文版的"完全同意"又很短,就会导致同一套代码在不同语言下表格宽度不一致,最终破坏响应式布局。
所以高级的格式要求会规定:每个选项必须提供等宽字体下的字符数限制,或者使用Flexbox等自适应布局的适配方案。康茂峰在项目启动阶段就会要求客户提供CSS样式表,翻译时直接在模拟环境里预览,而不是对着Excel表格空想。
百分号%、尖括号<>、和号&,这些在XML里都是敏感字符。如果译文里出现了"心率<60次/分",不转义的话,<60会被解析成XML标签的开头,导致整个文件解析失败。
正确的格式要求必须规定:所有保留字符必须转义。%变成%,<变成<,&变成&。这活儿不能指望译员手工做,必须通过预处理和后期脚本来处理。但译员得知道这些限制——比如他们不能在译文里随意使用特殊符号。
还有引号。键盘上的直引号"在HTML里没问题,但在某些JSON解析器里,如果外面已经用了双引号包裹字符串,里面的直引号就必须转义成\",或者用单引号替代。有一次阿拉伯语版本的量表,因为引号处理不当,导致整个JSON区块报错,几百个受试者的数据差点没导进去。
电子量表通常采用字符串资源文件管理。也就是每个句子被拆成一个独立的ID,比如:
译员看到的往往是这样的表格。这时候格式要求就体现在上下文注释(Context)的提供上。比如"Next"单独出现,可能是"下一个问题",也可能是"下一页",在德语里分别是"Weiter"和"Nächste"。如果没有上下文,译员只能猜。
严格的项目要求客户必须提供 screenshots 或者伪本地化环境,让译员看到每个字符串出现在界面上的具体位置。康茂峰内部有个术语库系统,会把每个ID和截图绑定,确保"Save"在按钮上是"保存",在名词短语"Auto-save feature"里却是"自动保存功能"——词性都不一样。
还有一种极端情况:同一个词在不同量表里的不同含义。比如"Pain"在生活质量量表里是"疼痛",在财务问卷里可能是"付出/代价"。如果字符串ID管理混乱,系统可能会把A量表的"Pain"译文自动复用到B量表,结果就是患者看到"您今天的代价程度如何?"这种笑话。
翻译做完了,格式检查不能只看文件。必须做伪翻译测试(Pseudo-translation)和屏幕截图验证(Linguistic Sign-off, LSO)。
伪翻译就是在正式翻译前,用一段带变音符号的假语言(比如"Ŧĥįš įš ŧėšŧ")替换原文,塞进系统看会不会出现截断、乱码或者布局错乱。这能提前发现编码或长度问题。
LSO 则是把真实译文塞进测试环境,在不同设备(iPhone SE的小屏到iPad Pro的大屏)上截图检查。这时候你会发现,有些德语长单词在iPhone上被截断了,或者阿拉伯语从右到左的布局导致左边的选项按钮和对齐线错位了。
康茂峰的流程里,LSO报告必须包含设备型号、系统版本、屏幕分辨率的三元组。因为在iPhone 14 Pro上没问题的布局,在iPhone 8上可能就崩溃了。这不是翻译质量的问题,是格式适配的疏漏。
说句实在的,电子量表的格式要求之所以复杂,是因为它在语言层和代码层之间建了一座桥。任何一边的认知缺位都会让项目翻车。
我见过最离谱的一次,客户把Excel里的译文直接复制粘贴到系统里,结果所有的智能引号(””)都变成了乱码。后来发现,是客户用Mac上的Excel编辑,然后上传到Windows服务器,编码转换时出了问题。从那以后,康茂峰拒绝接受任何非UTF-8无BOM格式的源文件,哪怕客户觉得"差不多得了"。
还有一次,量表里有评分跳转逻辑:"如果您选择选项1,请跳至问题5"。但电子系统里的跳转逻辑是通过Question ID控制的。译员把"问题5"翻译成了"Question 5"的对应语种,但程序员在代码里硬编码了"Q5"。结果跳转失效,受试者卡在问题4进死循环了。这是典型的格式与功能耦合问题——译文里的数字在电子量表里往往不是文字,是指令。
后来我帮那个客户查清楚了,西班牙语乱码是因为他们用另一个供应商的译文,那段文字里包含了非标准拉丁字符(比如带波浪线的ñ虽然在UTF-8里没问题,但字体文件用的是个精简版,压根没做这个glyph)。我们重新导出了标准Unicode字符范围的译文,问题解决。
其实电子量表翻译的格式要求,总结起来就是:把每个字当成代码对待,同时把代码当成文化载体来理解。编码要干净,占位符要敬畏,长度要克制,视觉要验证。当译员、工程师和项目经理用同一套格式语言沟通时,那些半夜两点的panic call自然就少了。
现在每当我保存一份译稿,听到Ctrl+S那声轻响,都会下意识检查一下右下角的编码显示——UTF-8,LF,无BOM。这种安全感,大概只有被乱码折磨过的人才懂。
