一份 200 页的设备手册送出去做西班牙语翻译。译文回来，文笔通顺，版式没塌，术语也前后一致。然后马德里的审稿人打开规格表，看到这么一行：
Longitud máxima: 406.5 mm
每个词都是西班牙语，数字不是。在西班牙语和德语里，这个尺寸写作 406,5 mm——小数用逗号，千位用点号分组。英文原文写成 1,234.50 的数字，到这里应该是 1.234,50。
这不只是不好看
分隔符没转换，问题不在整洁。因为两套约定用的是同样两个字符、角色正好互换，同一串字符可以有两种读法，差一千倍。
设想扭矩规格里的 1.234。中文或英文读者读成一点二三四，德语技师读成一千二百三十四。字符本身给不出答案——唯一能消歧的，是读者对「这份文件遵循哪套约定」的假设；而一份混用了两套约定的文件，连这个假设也一并抽掉了。
放到技术、医疗和法规内容里，这就不再是风格问题。ISO 80000-1 和 SI 约定把小数标记当作语言和区域的属性，受监管行业的审稿人常常就为这一条退回交付物。它也是客户最容易当场发现的缺陷之一——一句译文都不用读就能看见。
为什么通用翻译工具不动数字
原始机器翻译是不一致，而不是错
多数机器翻译和大模型输出把数字当成要照搬的材料，而不是要转换的对象。作为默认行为这说得过去——反过来就有改坏料号的风险——但结果是数字进了目标文件，还是源语言的写法。
更麻烦的是转一半。大模型分段处理长文档时，可能把句子里的尺寸本地化了，把表格单元格里同一个尺寸留着没动，又在别处产出第三种形式。最后得到的文件里，同一项规格出现两三种记法，审稿人清理起来比整份都没转还费劲。
传统 CAT 工具把它当配置和审校来处理
这个问题在翻译行业里众所周知，成熟的 CAT 工具确实有对应功能。以 Trados Studio 为例，它提供数字和货币的自动本地化。值得一读的是它的文档对生效条件的说明。
首先得开：如果所选翻译记忆库没有启用对这些项目的识别，RWS 写道，自动本地化不会发生，这些内容会「被当作普通的可翻译词语」处理（"are treated as normal, translatable words"）。其次，用哪套分隔符本身就是配置——文档说自动替换时可选的格式「基于你的 Windows 区域设置」（"based on your Windows Regional Settings"），而默认格式之外的源端写法，得先加成自定义识别规则才会被看见。再者，当有翻译记忆匹配时，Studio 沿用的是那条匹配里存着的格式，而不是目标语言的默认格式。RWS 把这一点作为「与既有翻译单元保持一致」来介绍，这没错——但它同时意味着，用文档自己的话说，「同一个翻译文件里可以用到不同的可置换项格式」（"different placeable formats can be used in the same translation file"）。
源端识别也有自己的边界：文档举的例子是 x-xxx,xx 这样的写法会因为其中的千分位和小数分隔符，被识别成三个数字而不是一个。而校验结果又是另一个独立步骤，要走 QA Checker 的数字检查——它的文档里举的例子恰好就是本文的主题：英文 5,000 译成德文 50.000 算错，5.000 才算对。
这些都不是在挑工具的毛病。它说明的是，常规做法需要多少配置和人工审校——以及一个赶进度的项目有多容易把这些跳过去。
真正难自动化的地方
天真的做法是查找替换：把数字之间的点号统统换成逗号。这会把文件弄坏，因为不是每个数字都在表示量。很多数字是在标识某个东西，而标识必须逐字符活着穿过翻译：
- 章节号和条款号：
7.4.2 - 版本号和标准号：
DisplayPort 1.4、IEC 60204-1 - 螺纹、牌号和料号：
M5x40、316L - 日期、页码、电话号码、IP 地址
把这些转了，你就用一个事实错误换掉了一个观感缺陷——指向错误条款的引用，比风格不对的小数点严重得多。
这个区分光看字符往往定不下来。pH 7.0-7.8 表示量，该本地化；DisplayPort 1.4 是版本号，不该动。两者都是「数字、点号、数字」。写成尺寸链的 Ø30x1.5 mm 表示的也是量，分隔符要跟着走——而形似的 M30x1.5 是螺纹标记，保持原样。要判断对，需要理解这个数字在句子里承担什么角色，这正是纯模式匹配容易漏掉或者改坏的原因。
而且目标约定不是一回事
在你把要求写进规格书之前，还有一个坑值得知道。「小数用逗号」并没有告诉你这门语言怎么分千位。
西班牙语和德语用点号分组，得到 1.234,50。但法语、挪威语、瑞典语、芬兰语、波兰语和俄语用空格分组：同一个数字是 1 234,50，一万二千一百九十二写作 12 192，不是 12.192。逗号小数的语言大致一半落在这边、一半落在那边，而小数逗号本身给不出任何线索。小数标记对了、千分位错了，本地审稿人照样会挑出来。
SimplifyAI 在翻译时怎么处理数字
SimplifyAI 依据任务的目标语言来确定数字约定，用的是这门语言实际遵循的分隔符规则，而不是套用较常见的那几种欧洲语言的模式。当你没有指定源语言时，系统会分析文档，确认源文自身是按哪套约定书写的——这一点有用，因为德语原文译成西班牙语时，数字本来就已经是西班牙语的写法，完全不需要转换。
在此之上，数字要过两道而不是一道，因为这个问题的两半需要的东西不一样。
判断交给模型。 判定 pH 7.0-7.8 表示量、而 DisplayPort 1.4 是版本号，需要理解这个数字在句子里干什么，没有哪条规则能给出这个。所以翻译时会连同目标语言的约定和范例一起交给模型，要求它只对表示量的数字套用。
下限由确定性校验兜住。 让模型在长文档里通篇转换数字，它可靠但不够均匀——会出现句子里的尺寸转了、表格里同一个尺寸没转的情况。因此，仍留在源语言约定里的量值会在之后被统一过来；而在两种语言本来写法一致的情况下，模型擅自改动的分隔符会被还原回去。后面这种情形是多数工具从不考虑的：当源语言和目标语言的数字写法本就相同时，正确的动作是什么都不做，此时被悄悄改写的数字是新增的缺陷，不是修复。
落到交付文件上，意味着：
- 尺寸、计数、价格和百分比按目标语言的写法书写，包括那些独占一个表格单元格、周围没有句子可供参考的数字。
- 章节号、版本号、料号与螺纹标记、日期，以及其他标识类数字与源文完全一致。
- 受保护标记和代码占位符内部的数字绝不触碰。
- 每一位数字都保留。只有数字之间的字符可能变化，所以转换后的数字与源文同值。
- 同一项规格在全文中写法一致，不会出现表格里一种、引用它的段落里另一种。
有两条边界值得如实说明。第一，量值还是标识终究是个判断，专业领域里不常见的记法仍可能被读错——所以数字抽查应该留在你的审校环节里，尤其是某一类文档的第一次任务。第二，同一门语言内部还会按行业分化的千分位习惯（金融和科学写作里就有），可能需要你定一个内部规范，这是任何通用默认值都替你决定不了的。
放到工作流里
- 上传 InDesign、Word 或 PDF 源文件，选择目标语言。
- 系统分析文档并准备翻译，其中包括一份可供确认的术语方案。
- 翻译按目标语言的数字约定处理量值，结果在写回之前会对照这套约定校验一遍。
- 预览或导出结果，交付前抽查规格表。
数字格式是决定一份译文读起来像原生还是像翻译的细节之一。如果你在为欧洲市场出技术文档，可以传一份带规格表的源文件，看看数字回来是什么样。