摘要

  • 截至本文取证时点，ICANN Public Comment 索引仍把 IRP-IOT 程序列为待出报告，共收到九份意见，报告日期列为 2026 年 9 月 1 日；程序页的结果栏仍为空。
  • ICANN 章程规定 IRP 以英语为主要工作语言，同时必须为有需要的申请人提供翻译服务。
  • 2018 年临时 Rule 5B 允许申请人证明英语申请负担过重后，直接以非英语提交翻译服务申请。
  • 2024 年草案要求争议陈述与翻译服务申请都使用英语，申请还须说明首选语言、必要性和语言能力。
  • 草案也有实质改进：紧急裁定、ICANN 承担获准服务费用、时限调整，以及必要时使用非联合国官方语言。
  • 一个多语种的初步入站回执可以保住第一道入口，同时不改变英语工作语言，也不预判资格、时限或实体争议。

待出报告没有让草案自动生效

Independent Review Process 是 ICANN 的外部问责机制，用来审查某些董事会或员工行为是否违反 Articles of Incorporation 或章程。章程既要求这种审查“有意义、可负担、可接近”，也明确把英语设为主要工作语言。这两项要求并非彼此否定，难点在于如何把需要翻译的人带到能够作出决定的程序中。

IRP Implementation Oversight Team 在 2024 年把若干补充程序修改稿交付公开征询，范围包括小组成员选任、提交时限、翻译与第三方参与。ICANN 当前总索引显示九份提交，并在本文截止时把报告日期列为 9 月 1 日。单项程序页尚未公布 Outcome。

因此，本文分析的是一项尚未取代现行临时规则的方案。报告日期不能替代报告内容，更不能被当作董事会采纳。它只说明：在结果仍待公开时，这项入口设计值得被准确辨认。

现行规则把最窄的例外放在最需要的地方

临时 Rule 5B 不是任由申请人选择全程语言。IRP Panel 决定申请人是否确有翻译需要、哪些材料或听证受覆盖，以及使用哪种语言。未被认定有需要的人必须用英语提交材料。现行范围通常只包括英语与阿拉伯语、中文、法语、俄语和西班牙语。

但现行文本为翻译申请本身留出一个括号式例外：如果申请人证明用英语提出这项申请会造成过重负担，申请可以不用英语。

这个例外不等于受理争议，不证明 standing，不暂停任何法定或程序时钟，也不迫使 ICANN 承担全部翻译。它只解决顺序：先让有权决定的人看见语言障碍，再由其判断是否提供服务。

制度入口往往不是宏大的权利宣言，而是这样一句不起眼的程序句。

草案在入口之后提供了更完整的服务

拟议 Rule 5B 对翻译对象的列举更清楚：书面陈述、与争议实质相关的文件、听证记录、Panel 决定以及口头程序的传译，都可能纳入。申请人可以请求报销把初始争议陈述译成英语的费用，也可以要求把 ICANN 的答复译成首选语言。随初始陈述一并提交的翻译申请不占用主文页数。

如果完整 Panel 尚未组成而翻译问题又十分紧急，Emergency Panelist 可以先处理。获准的服务由 ICANN 的语言服务商协调，原则上作为行政成本由 ICANN 承担。Panel 还可以因翻译所需的合理时间调整文件与上诉期限。

语言范围也更合理。申请人若能用多种语言公平参与，其中包含一种联合国官方语言，则应尽可能选用该语言；但如果只有另一种语言能够保障公平参与，草案不再绝对排除它。

这些都是现行规则的重要升级。问题不是服务太少，而是服务启动得太晚。

在获得帮助之前，必须先产出两份英语材料

草案先要求书面争议陈述以英语提交，又要求翻译服务申请同样使用英语。后者要标明首选语言、说明为什么没有服务便无法公平参与、描述本人或代理人的语言能力，并控制在五页双倍行距之内。

草案已经意识到一个悖论：申请人能够交出英语材料，不得被反过来当作“不需要翻译”的证据。这条禁止不利推断的保护很有价值，尤其适用于先自费聘用律师或翻译的人。

然而，真正资源不足的人仍停在更早的位置。只有先找到英语代理、购买合格翻译或依赖非正式中间人，才能让公共援助机制看到申请。语言能力变成了获得语言能力评估的前置条件。

Non-Commercial Stakeholder Group 从知情角度提出了相邻问题。它支持 Rule 5B，却提醒仅靠当事人主动申请会使不知道这项权利的非英语使用者承担额外负担，因此建议 ICANN 在开始阶段主动告知并提供选项。

这份意见不是 ICANN 的结论，也不是所谓社区共识。现有资料没有证明某位申请人已因草案遭到排除。恰恰因为门槛位于正式决定之前，潜在后果可能是放弃、迟延、缩小主张或让中间人的措辞成为第一份权威版本，而不是一份可上诉的拒绝书。

把语言求助信号与完整争议陈述分开

解决办法不必是自动翻译每一页。那会忽视章程中的“需要”标准，也会增加成本和时间。任何语言的一则短消息也不应暗中被当作完成立案的争议陈述，更不能在规则没有规定时自动暂停所有期限。

更薄的一层足够有用：多语种初步入站请求。申请人先用系统能够识别的语言发送一段简短说明。ICANN 或 ICDR 记录精确时间，赋予中性编号，并尽可能以同一语言确认。回执必须清楚说明已经收到什么、尚未完成什么、哪些时限继续运行、是否存在临时保护，以及由谁决定翻译需要。

原文应与服务商制作或认证的英语版本并列保存。若申请人对译文有异议，修正记录应追加，而不是无痕覆盖。紧急路径、ICANN 主动同意与 Panel 命令也应成为不同状态，不能用一个“已处理”标签混在一起。

公共透明度无需披露案件隐私。按语言、处理方式、响应时间、译成英语所需时间、期限调整与成本发布汇总即可。某种语言零申请不代表零需求；它首先提示机构检查告知是否可见、入口是否可用。

这与 Heng Lu 对参与和授权的区分一致。收到初步请求不会让发送者赢得案件，也不会把其陈述变成机构决定。它只是确保由有权的 Panel 判断是否需要帮助，而不是让入口语言替 Panel 作决定。

扩大后端时，不应悄悄收窄前门

新旧文本不能简单打分。草案在服务范围、费用、紧急性和时间管理上更完整；现行临时规则在最初求助这一点上更可接近。最合理的做法是把两者的优点连接起来。

多语种初步回执不改变英语作为工作语言，不推定翻译需要，不证明资格，也不影响实体结果。它只把操作顺序调正：首先识别障碍，其次由有权者决定援助，最后建立程序需要的英语案卷。

问责机制不能要求一个人先独自克服障碍，才允许其说明障碍存在。2018 年规则已经用一项小例外承认了这一点。未来规则可以把它做得更清楚，而不是在扩大服务时把入口删掉。

来源

  1. ICANN Public Comment 索引
  2. IRP-IOT 补充程序修改征询
  3. 拟议规则净稿
  4. 附 IRP-IOT 理由的红线对照稿
  5. 2018 年临时补充程序
  6. NCSG 提交意见
  7. ICANN 章程第 4.3 条
  8. Heng Lu，《The Multi-Stakeholder Mirage》