有些内容应当保持源语言——产品名、受监管标识符、与代码耦合的字符串。这类错误不是翻译质量问题，是范围界定问题；而它们的代价，往往在出事之后才被看见。
不译清单能避免哪些错误
让译员翻译一切，他就会翻译一切——包括那些从来就不该动的东西。产品名被本地化成了一个普通名词。受监管的物质标识符被「热心地」译了出来。一条与软件中硬编码值相匹配的界面文字被翻译了，于是按钮失灵。
这些都不是翻译质量的失败；它们是范围界定的失败。而范围界定发生在动手翻译之前——等到审校阶段，错误已经进了产品。多数团队都是在第一次出事之后，才知道自己需要一份不译清单。
难点不在列清单，在每一类的分寸
「哪些东西不该翻译」这个问题听起来简单，真正难的是每一类里的例外。
品牌与产品名。看似最该保留，实际最需要逐市场判断——有些名称在中文、日文这类文字体系中按惯例音译，有些则必须整个改掉，因为原名在当地含义不佳。而「不要翻译」和「不要改动」是两条不同的指令，混用会得到两种都不对的结果。
受监管标识符。型号、标准编号（ISO 10218、21 CFR 820 这类）、UDI 码是键值不是文字，翻译会破坏可追溯性。难点在边界：同一个物质名称，在标签上可能必须译，在申报表的字段里可能必须不译。
与代码耦合的字符串。这一类语言人员根本无从判断——某条字符串是否在软件别处被与固定值比对，只有工程侧知道。识别它需要的是跨职能协作，不是语言能力。
第三方引文与法条引用。往往须逐字复制，有时是保留原文另附译文，而不是用译文取代原文。哪一种取决于引用它的文件本身受什么约束。
| 类别 | 为什么在清单上 | 分寸难在哪 |
|---|---|---|
| 品牌与产品名 | 看似最该原样保留 | 实际最需要逐市场判断：有些名称在中文、日文这类文字体系中按惯例音译，有些则必须整个改掉，因为原名在当地含义不佳。而「不要翻译」和「不要改动」是两条不同的指令，混用会得到两种都不对的结果 |
| 受监管标识符 （型号 · ISO 10218 · 21 CFR 820 · UDI 码） | 是键值不是文字，翻译会破坏可追溯性 | 边界：同一个物质名称，在标签上可能必须译，在申报表的字段里可能必须不译 |
| 与代码耦合的字符串 | 翻了，按钮就失灵 | 语言人员根本无从判断——某条字符串是否在软件别处被与固定值比对，只有工程侧知道。识别它需要的是跨职能协作，不是语言能力 |
| 第三方引文与法条引用 | 往往须逐字复制 | 是保留原文另附译文，还是用译文取代原文，取决于引用它的那份文件本身受什么约束 |
这些都不是翻译质量的失败，是范围界定的失败——而范围界定发生在动手翻译之前。等到审校阶段，错误已经进了产品。
能落地的不译清单，和写得出来的不是一回事
我们审核过的不译清单，失效原因高度重复。停留在邮件或说明文档里的清单，靠的是每位译员自己记得翻看，总有人漏看；只写「保留英文」不写理由的条目，交接一次就会被当成莫名其妙的遗留项删掉；产品命名和受监管术语会变，一份发布时对、此后没人碰过的清单，一年后会同时发生两件事——保护着已经作废的术语，又漏掉了真正要紧的新增项；而哪些字符串与代码耦合，语言团队自己判断不出来，往往只有工程侧才知道。
我们交付的不译清单是能被工具强制执行的数据，不是一段说明文字；每条附带理由与责任人；随产品与法规变化定期复审；编制阶段就把工程拉进来，处理耦合字符串这类问题。
相关项目，查看实际文件范围
术语释义与指南供项目沟通参考；具体用词、适用要求和交付范围需结合文件用途确认。
读完后，您可能还想确认
不译清单和术语表是一回事吗？
不是。术语表说明一个术语该怎么译；不译清单说明它根本不该译。两者并存但职责不同——混为一谈会导致已批准术语被锁死，或者受保护字符串被当作普通词汇「翻译」掉。
产品名是不是永远该保持源语言？
通常是，但不能自动如此。某些文字体系中音译是常规做法，偶尔也会因为名称在当地读起来不佳而改名。这类判断需要逐市场做，而且要留下记录——否则每位译员都会各自猜测。
与代码耦合的字符串该由谁标出？
工程团队。语言人员没有办法知道某条字符串在软件别处被与固定值比对，这是「翻译把构建搞坏了」这类事故最常见的来源，只能从代码侧预防。手上已有清单的话，看工程侧有没有参与编制，就能判断这一类是否被覆盖到。