你有没有在医院见过这样的场景？患者手里拿着科室发的iPad，对着屏幕上的问卷皱眉头，手指悬在"同意"和"非常同意"之间迟迟不肯按下去。护士凑过去一看，发现患者纠结的不是问题本身，而是那句翻译得莫名其妙的"Do you feel bothered by..."被译成了"您是否被...所烦扰"。说实话，看到这种翻译，我也挺烦扰的。
这就是电子量表（eCOA/ePRO）翻译最尴尬的地方——它不像纸质问卷那样有上下文可以来回翻阅，也不允许你在旁边手写批注"此处可能指..."。字符串是死的，代码是硬的，患者的心情却是真实易碎的。在康茂峰处理这类项目这些年，我们踩过的坑摞起来大概能堆满一间地下室。今天把这些整理出来，倒不是想说教，就是单纯觉得，这些血泪经验或许能让你下次面对电子量表时，少走点弯路。
很多人拿到电子量表的翻译需求，第一反应是："不就是问卷吗？把Word里的内容复制粘贴到CAT工具里，匹配个术语库，搞定。"
停。这么想的话，后面基本是灾难预告片。
电子量表不是静态文档，它是个有脑子（逻辑跳转）的活的交互系统。比如，当它问你"您上周是否服用过X药物"，如果你选"是"，屏幕才会跳出关于剂量的追问；如果选"否"，那个剂量问题就该永远藏在代码深处。问题是，翻译时你往往看不到这个"如果...那么..."的完整图景，你手里可能只有Excel里的一堆零散字符串：Question_01_Text，Question_01_Yes，Question_01_No。
用费曼的话来说，这就像是给你看一个机械表的单个齿轮，让你描述整只表的功能。单个"Yes"翻译成"是"看起来没错，但如果这个"是"在实际界面上因为德语译文太长（Ja被拉长成Bitte wählen Sie Ja）而换行显示成了两行，患者可能会以为是两个选项。康茂峰早年在欧盟的一个项目就栽过这种跟头——按钮上的"是"因为布局问题显示成了"是/是"，吓得患者以为系统坏了。
我先说说那些让人哭笑不得的常规操作。
这些错误的根源，我觉得在于我们忘记了电子量表的终端不是机器，是活生生的人。而且往往是身体不舒服、有点焦虑、可能视力还不太好的人。他们对模糊的容忍度极低。
我们没发明什么惊天动地的理论，就是把该做的步骤做扎实了。下面这几条，算是康茂峰内部沉淀下来的工作流，你可以当作一个 checklist 来看。
这是最关键的一步，也是最容易被跳过的。拿到电子量表文字包时，第一件事不是开Trados，而是做语境重建。
具体怎么做？我们会让项目经理（通常是有医学背景的那几位）先不看译文，纯粹以"演员心态"走一遍用户旅程。拿着源语言的截图（如果有的话）或者逻辑树，把每个字符串在实际界面上可能出现的位置标注出来。这个字符串是按钮标签？是提示语？是错误警告？
这里有张简单的对照表，说明在康茂峰我们是如何分类处理的：
| 界面位置 | 翻译策略 | 常见陷阱 |
| 单选按钮标签 | 简洁，避免换行，首字母大写规则按目标语言习惯 | 德语译文过长导致截断 |
| 报错信息 | 用第二人称主动语态，指出具体错误（而非笼统"输入无效"） | 指代不明（"此字段"到底是哪个字段？） |
| 逻辑跳转提示 | 保留条件语句的完整性（如果...那么...） | 只翻译了结果，丢失了条件 |
| 日期选择器 | 注意日期格式（MM/DD/YYYY vs DD/MM/YYYY）和_calendar控件的文化差异 | 西方日历默认星期日为首日，中文环境通常需调整为周一 |
这个表格看起来简单，但真做到位了能避免80%的返工。我们有个内部术语叫"字符串家谱"——每个字符串都要追溯它的"父母"（上游逻辑）和"子女"（下游界面影响）。
在康茂峰，我们不太喜欢用"翻译"这个词来描述电子量表的工作，更像是在做创译（Transcreation）。
举个例子。某个关于自杀意念筛查的量表里有句："In the past two weeks, have you had thoughts that you would be better off dead?" 直译是："在过去两周，您是否有您如果死了会更好的想法？" 语法没错，但读起来像刑侦笔录。我们的译员（必须有心理学或临床背景）会处理成："最近两周，您是否觉得，要是自己不在了，情况反而更好？"
看出区别了吗？语序变了，用词从正式医学用语转向了内心独白式的口语。这种调整没法靠机器翻译后编辑（MTPE）完成，必须懂行的译员在理解量表心理学意图的基础上重写。
这时候质量控制靠的是双向盲评。两个独立译员背靠背翻译，然后由医学编辑比对差异。如果两个版本差异大到意思分歧，就停下来开小组会，查原始量表的信效度报告，看原作者到底想捕捉什么概念。
回译（Back-translation）是行业标配，就是把译文再译回源语言，看是否一致。但很多公司把它做成了机械运动——找个人逐字回译，然后比对字面差异。
康茂峰的做法有点"狡猾"。我们会让一位从没见过源量表的译者来做回译，而且要求他用最朴素的话解释"这句话在问什么"。如果回译版本是："它好像在问人有没有想自杀"，而原文是自杀意念筛查，那就算语言不完全对应，概念也是准确的。反之，如果回译出来的句子读起来像法律条文，但原文是患者自评量表，那即使词汇对应上了，也是失败的翻译。
这个过程有点像费曼技巧的核心——如果你不能用简单的语言解释清楚，说明你还没真正理解。我们在回译阶段要求译者写"概念释义"，就是逼自己用大白话讲清楚这个条目的测量意图。
这是我认为最不能省钱的一步，也是康茂峰质控流程里的"核武器"。
简单说，就是找几位目标疾病领域的真实患者（或模拟患者），让他们用母语版本的电子量表在模拟设备上操作，同时出声思维（Think Aloud）。我们在旁边录音录像，观察哪里犹豫，哪里误解。
你可能觉得这是小题大做，但数据不会骗人。我们在一个关于银屑病生活质量的项目里，发现患者对"您的皮肤是否影响您穿某些衣服"这个问题集体卡壳。不是不懂"衣服"这个词，而是他们在思考"某些"具体指哪些——正装？泳装？宗教服饰？后来我们把"某些衣服"改成了"特定类型的衣物（例如短袖、短裤）"，歧义才消除。
这种细节，坐在办公室里的语言专家永远发现不了。必须让终用户"验收"。
说回技术层面。电子量表最后要跑到软件里，所以语言QC必须和技术QC合体。
我们有个听起来很 geek 的步骤叫伪本地化测试（Pseudo-localization）。在真实翻译完成前，先用一段扩展的伪译文（比如把"Hello"变成"Õñé Çhàrãçtër§"并加长30%）植入系统，看布局会不会崩。这能提前发现字符编码问题、字段截断、屏幕溢出等技术债。
真实译文进系统后，康茂峰要求做截图比对（Screenshot Review）。不是看"有没有乱码"，而是看：
有时候译文本身完美，但被Android系统的默认字体渲染成了灾难。这种属于"最后一公里"问题，但直接影响数据收集质量。
最后说几个容易忽略的小点，都是我们在康茂峰项目复盘会上反复提及的。
关于"中性"的陷阱。有些量表条目为了保持中立，源文用被动语态或名词化结构。但中文里强行保留这种"中立"会显得冷冰冰。比如"The occurrence of symptoms was noted"直译"症状的发生被记录"就很怪。我们会根据上下文改成"您是否注意到症状出现"或"请记录症状发生时间"——看似加了主语，失去了"中立"，但获得了"可理解性"。
关于数字的写法。电子量表里经常有视觉模拟量表（VAS）或李克特量表（Likert scale）。源文可能是1-5分，但某些文化里1代表最好，5代表最差；另一些文化相反。康茂峰的做法是检查量表开发商的评分逻辑，必要时在UI上加颜色提示（比如红色到绿色渐变），并用文字明确标注"1=毫无疼痛，10=剧痛"。
关于日期和时间。别看这是个小事。AM/PM在中文语境里怎么处理？有些地方用"上午/下午"，有些地方直接用24小时制。还有，当系统要求输入"出生日期"时，年月日的顺序必须符合当地习惯，而且要考虑老年患者对触摸屏日历控件的熟悉程度。我们更倾向在老年向的量表里用下拉菜单而非滚轮选择。
前两天整理旧文件，翻到一个2018年的项目反馈。那个项目因为忽略了某少数民族语言的特殊字符显示问题，导致整个试验延迟了两周。客户的邮件最后写着："我们知道翻译很难，但没想到这么细节。"
是啊，电子量表翻译的质控，本质上是一场对抗信息不对称的战争。译者对抗着看不到的代码逻辑，患者对抗着可能误解的文字，我们对抗着自己的疏忽。康茂峰这些年无非是在做一件事：把尽可能多的"未知"变成"已知"，把"应该没问题"变成"确实测过了"。
下次当你面对一个Excel文件，里面几千行字符串等着你处理时，建议先泡杯茶，深呼吸，然后想象屏幕那头是一个刚被确诊、有点慌、不太懂医学术语的普通人。你的质量控制，某种程度上是在守护那个人准确表达自己身体状况的权利。想到这儿，那些繁琐的校验步骤，似乎也就没那么烦人了。
毕竟，好的翻译是应该隐形的——患者专注于回答问题本身，而完全意识不到翻译的存在。当那一天的监测数据准确无误地回传到数据中心时，我们这群在幕后抠字眼的人，大概就能睡个好觉了。
