合约只会报一个数字，人话由谁翻译：ERC-1444 的本地化文案接口

你在钱包里看到的“余额不足”四个字，其实不是合约写的。合约最多抛出一个字节、一个枚举值，或者一段 revert 数据。ERC-1444 想把中间这一层标准化：状态码留在链上，文案搬到链下的翻译合约里查。这份标准创建于 2018 年 9 月 23 日，仓库状态是 Stagnant，但“机器码与人类文案分离”的思路在今天的错误提示与可读签名里到处都在用，值得把原文读一遍。

两段式：状态码合约与翻译合约

标准的正文把系统拆成两种合约。业务合约在自己的状态转换点上发出一串语义化标识，原文建议用 ERC-1066 那类十六进制状态码，也可以用字节常量；翻译合约则实现一个查询函数，正文给出的接口是 textFor(bytes32 _code)，输入状态码，返回一段字符串。有的示例里这个函数返回两个值，第一个是布尔，说明有没有查到，第二个才是文案。

为什么要分开？原文明确说过理由：硬编码一句英文提示只服务了很小一部分用户，而语言是无穷的，链上程序不可能预先内置所有语种。把文案抽出去之后，同一份合约代码可以被任意语言的社区翻译，不必因为“提示语需要改一个字”就升级合约。这是当年少见的、以文化多样性为动机的接口设计。

谁来写翻译，标准其实没有规定

原文的写法是让用户创建、分享并使用本地化文本，构成一个去中心化的翻译集合，但并没有规定一个全局注册表，也没规定冲突时以哪份翻译为准。这是这份标准停留在概念层面的核心原因之一：状态码的语义由发码方定义，翻译却可以由任何人写，两句对同一状态码的不同解释在链上无法裁决。真实产品后来都做了同一个选择——把翻译表放在官方控制的域名或应用包里，把权威性的问题交回给中心化的一方。

把这条经验用到今天，你会在好几个地方看见 ERC-1444 的骨架。ERC-4430 让合约自己写一句人类可读的签名提示；ERC-7730 定义可读签名的格式；ERC-3224 甚至提供了两个 JSON-RPC 方法，让钱包在弹窗里先展示一句描述串。它们比 ERC-1444 前进了一步，都是让代码的来源和文案的来源尽量归到同一方，减少“提示语被人改写”的攻击面。

读错误提示时的现实核对

这条演进史对普通用户有一条直接可用的结论：错误提示和签名提示一样，是一个可被替换的信息层，不是链上事实本身。看到一段顺理成章的中文提示时，值得问一句它来自哪里。如果它是合约通过标准接口返回的，那么至少合约地址能告诉你谁在说话；如果是钱包或前端自己拼的字符串，它表达的是应用作者对该状态码的理解，可能与合约实际状态有距离。

从这份草稿里能带走的三条判断法

第一条，看权威来源是否可追溯。合约给出的状态码本身是确定的，但提示文案的来源决定了你能信它几分：来自合约返回值的文案，至少能对应到一个可查的合约地址；来自前端字库的文案，只能对应到某个项目的产品经理。第二条，看是否有版本。同一份合约在不同时期可能给同一个码赋予不同含义，译本没有版本号的代价就是过期解释会长期流传。第三条，看有没有降级路径。合约 revert 时如果没有携带任何编码，再完善的翻译表也无能为力，这时钱包只能展示一句通用的失败提示。把这三条合起来，你其实是在给一条链上消息做来源鉴定，而不是在挑一种语言。 还有一个容易被忽略的边界：链上没有任何机制保证翻译与代码语义同步。合约改了某个状态码的触发条件，翻译表不会自动更新。于是同一个码，在不同时期、不同译本下可能对应完全不同的含义。把提示当线索而不是结论，先在区块浏览器里核对事件和 revert 的原始数据，再去看人话解释——这个顺序在 NFT 铸造失败、授权被拒、领取超额这些场景里都成立。

本文为机制说明，不构成任何投资建议。