让审校先看改动：怎样做一份不误导的译文差异表

本文使用合成样本演示处理方法。代码已通过隔离环境中的示例检查；这不代表对所有真实文件或产品效果的保证。处理重要文件前，请保留原件，并按文中的边界与验收项复核。 一份英文译稿改了十次，让审校每次从头读，效率并不高。差异视图能把注意力集中到改动处，但有一个前提：比较的是同一种语言的两个修订版本，而不是把中文原文和英文译文逐字符做 diff，再拿红绿面积评价翻译质量。 差异是修改线索，不是质量分数 difflib 可以生成行级差异。它告诉你哪些文字发生变化，不会判断术语选择对不对，也不理解一句话的商业或技术后果。删掉一个否定词，差异可能很小，影响却很大；重排一个段落，差异可能很大，语义却基本不变。 先给审校一个稳定的单元，例如段落 ID 和译文行。若导出过程每次随机换行，差异就会被排版噪声淹没。源文档结构变化与译文修改应分别记录，不能混成一次“文字更新”。 一个明确包含语义风险的合成修订 import difflib import html before = ["Do not disconnect the cable.\n", "Wait for the green light.\n"] after = ["Disconnect the cable.\n", "Wait for the green light.\n"] delta = "".join(difflib.unified_diff(before, after, fromfile="revision-A", tofile="revision-B")) assert "-Do not disconnect" in delta assert "+Disconnect" in delta assert list(difflib.unified_diff(before, before)) == [] # 差异如需显示在网页中，按普通文本转义。 unsafe_line = "<script>alert(1)</script>" assert "<script>" not in html.escape(unsafe_line) print(delta) 这里不执行任何设备操作，只用两句合成文本说明：一个很短的编辑可能需要重点复核。示例输出是用于审校的文本差异，不是机器自动批准修改的依据。 怎样减少无意义的红绿块 可以统一行尾、保留稳定段落 ID，并对明确不影响意义的导出噪声做单独处理。但不要为了让 diff 好看就删除全部标点、数字或空格。代码、公式、表格和某些语言中的空白本身有意义，过度归一化会掩盖真正变化。 修改类型 差异视图能帮助什么 仍需人工判断什么 术语替换 找到全部修改位置 是否符合当前上下文 数字变化 暴露新旧值 修改是否有来源依据 否定词变化 提醒读者重点检查 是否改变指令含义 段落移动 显示大块删除与新增 是否只是位置调整 不把相似度包装成准确率 SequenceMatcher 一类比对工具的结果取决于输入切分与匹配规则。一个很高的字符串相似度，既可能是小改动，也可能是遗漏了最重要的几个字；很低的相似度，也可能只是表达方式重新组织。将它直接命名为“翻译准确率”，会误导使用报表的人。 差异审阅还应能回到对应原文。尤其在译稿修订时，不能只在两版译文之间选“更顺”的那句，而忘记它是否仍表达源文档的含义。 把工具用在正确的位置 可以先在 OmniDoc（产品入口） 提供的文档翻译入口生成待审译稿，再在自己的版本管理流程里比较审校前后变化。双语核对解决来源含义，修订 diff 解决改了什么；两者并用更清楚，不需要让其中一个假扮成另一个。 参考： Python difflib 。 - 1 -