医疗软件本地化：UI翻译与合规落地的工程实践
医疗软件本地化不是简单的软件翻译。从IEC 62304到EU MDR，UI翻译错误可能触发召回。本文分享应用本地化中界面字符串管理、法规映射与验证测试的实战经验。
医疗软件本地化：别让一个按钮翻译毁掉整份技术文档
去年帮一家做输液泵嵌入式软件的客户做本地化审计。他们的中文版界面把“Occlusion”译成了“堵塞”。临床护士反馈：看到“堵塞”第一反应是管路被异物堵死，直接按了报警静音。实际只是管路受压导致的暂时性闭塞。一个词的偏差，差点变成不良事件报告。
医疗软件本地化跟普通软件翻译根本不在一个风险量级。普通App把“Settings”翻成“设置”没人会告你。医疗设备的软件界面翻译，背后拴着IEC 62304的软件生命周期要求、EU MDR 2017/745的附录I第23条（标签与说明书语言要求），以及FDA 510(k)审评中对用户界面本地化验证的预期。
法规对软件界面翻译到底管到什么程度
很多人以为MDR只约束纸质IFU。翻到附录I 23.4条：制造商应确保软件界面以目标市场官方语言呈现，且界面语言切换不得影响安全相关功能的可用性。公告机构在技术文档评审时，会抽查UI翻译的验证记录。
IEC 62304把软件界面文本归为“软件项”。翻译变更触发配置管理流程，版本号要动，追溯矩阵要更新。这不是翻译公司交个Word文件就能闭环的事。
实操中我们按这个矩阵做法规映射：
| 法规/标准 | 对UI翻译的具体要求 | 交付物 |
|---|---|---|
| EU MDR 2017/745 附录I 23.4 | 界面语言为目标国官方语言；语言切换不影响安全功能 | 语言可用性测试报告 |
| IEC 62304:2006+A1:2015 | 界面文本作为软件项纳入配置管理与追溯 | 需求追溯矩阵更新记录 |
| FDA 510(k) 软件指南 | 人因工程验证需覆盖本地化界面 | 形成性/总结性可用性测试记录 |
| ISO 14155 临床试验 | 受试者界面语言需经伦理委员会确认 | 伦理批件与翻译声明 |
软件翻译阶段最容易踩的三个坑
字符串截断。 德语“Geschwindigkeit”塞不进为英文“Rate”设计的12px按钮。医疗设备屏幕尺寸固定，UI翻译必须做伪本地化（pseudo-localization）膨胀测试。德语按+30%膨胀，俄语+25%，中文反而缩水但字高变化影响行距。
术语一致性断裂。 “Alarm”在报警系统里是“报警”，在设置菜单里被译成“警报”，临床培训时护士以为两个不同功能。我们给医疗客户建术语库时强制锁定安全相关术语，任何偏离走变更评审。
上下文缺失。 “Lead”在心电图界面是“导联”，在设备维护界面是“导线”。给翻译团队的字符串表必须带UI截图和字符串ID，光给Excel等于埋雷。
应用本地化验证：翻译完了不算完
医疗软件本地化交付前必须过语言验证（linguistic validation）。我们的流程：
- 双语临床背景审校——不是语言专业学生，得有护理或临床工程背景
- 界面走查——在真实设备或模拟器上逐屏核对，记录截断与语义歧义
- 反向翻译抽查——安全相关字符串100%回译比对
- 可用性测试——至少5名目标市场临床用户完成关键任务
某次走查发现呼吸机中文界面把“Apnea”译成“呼吸暂停”，但报警优先级标注被压缩后视觉上跟“窒息”混淆。改回“呼吸暂停（Apnea）”加括号原文，公告机构评审时反而认可这种保守处理。
软件本地化供应商怎么选
看三样东西：有没有ISO 17100认证的翻译流程、能不能对接你的字符串管理系统（TMS/Crowdin/Phrase）、审校团队里有没有临床背景的人。价格排最后。医疗软件界面翻译按字计价本身就荒谬——一个“OK”按钮的翻译风险跟一段报警文本能一样吗？
需要评估现有医疗软件本地化流程的合规缺口，可以把字符串清单和法规市场列表发过来，我们做一轮差距分析。
分享这篇文章
