意扣
Equalang 笔记

阿拉伯语等 RTL 文档翻译：从右到左排版、数字和表格怎么验收

意扣

导读

在 LTR 软件里处理阿拉伯语、希伯来语等双向文本（Bidi）时，段落方向、末尾标点、数字日期和表格列顺序极易错乱。本文为本地化团队梳理从底层方向属性到交付前复核的完整验收流程。

关键词：阿拉伯语文档翻译, RTL排版验收, 双向文本Bidi, 希伯来语排版, 本地化QA检查表

在默认的从左到右（LTR）软件环境里翻译阿拉伯语、希伯来语等从右到左（RTL）的文档时，最常见的交付事故不是漏译，而是排版方向失控：句号跑到行首、英文型号与阿拉伯语混排时语序颠倒、日期和带连字符的编号被拆散，或者整个表格的列顺序依然停留在从左往右。

处理这类双向文本（Bidirectional text，简称 Bidi）文档，不能只看“字面意思翻没翻对”，必须按照段落基础方向 → 行内混排与标点 → 数字与日期 → 表格与列表结构的顺序逐层验收。下面是给本地化团队的直接排查逻辑和交付前检查表。

为什么译文看起来“对”但顺序全乱了？

Unicode 双向算法（UBA）会根据字符自带的方向属性自动排列文字：阿拉伯语、希伯来语属于强 RTL 字符，拉丁字母属于强 LTR 字符，而数字、空格、连字符、括号和句末标点大多属于弱方向或中性字符。

当文档中没有明确设置段落的“基础方向（Base Direction）”时，排版引擎只能靠猜测。一旦一段阿拉伯语译文只是被加上了“右对齐（Right Align）”，而底层段落属性仍然是 LTR，所有中性字符（如句号、感叹号、括号）在行首或行尾以及与英文、数字交界处，就会按照 LTR 的逻辑回流，导致视觉顺序与阅读顺序完全脱节。

Chrome 中同一句含英文型号与日期的阿拉伯语在 LTR 右对齐与 RTL 段落方向下的渲染对比
自制订单确认示例在 Chrome 中的排版对比：图 A 仅设 LTR 右对齐，英文型号导致语句被拆且标点错位；图 B 设为 RTL 段落方向后语序才正常。

RTL 文档的四步验收顺序

为了避免返工时牵一发而动全身，建议在拿到翻译初稿后按以下四个层级依次排查。

第一步：验收段落基础方向（而非对齐方式）

打开文档后，先不要逐字改标点，第一步是确认全局和段落级的基础方向属性。

  1. 检查段落标记所在侧：在 Word 等软件中开启编辑标记，真正的 RTL 段落，其段落标记（¶）出现在行左端，光标在行首时位于最右侧。
  2. 区分“右对齐”与“从右到左”：在 LTR 段落上强行点“右对齐”，只会把文字推到右边，列表缩进、段首标点和跨行折行依然按从左到右计算。必须将段落方向属性显式设为 RTL（HTML/XML 中对应 dir="rtl"，Word 中对应“从右到左文本方向”按钮）。
  3. 检查列表与缩进：确认项目符号（Bullet）或编号位于文字右侧，且二级列表向左侧缩进。

第二步：验收中英/阿英混排与两端标点

根据 W3C 关于行内双向标记与 Unicode 控制字符的规范，当 RTL 句子里夹杂英文品牌名、产品型号、URL 或括号时，连续的 LTR 片段可能把相邻的中性符号“吸”过去。

  1. 句末标点位置：检查每一段末尾的句号、问号、冒号是否老老实实待在最左侧（RTL 的句尾），而不是跳到最右侧的行首。
  2. 成对括号与引号：检查包裹英文词或数字的圆括号 ()、方括号 [] 是否出现开口方向反置（例如右括号变成了左括号的视觉形态）。
  3. 连续两个 LTR 词夹阿拉伯语或标点：比如“型号 A-100 / B-200”嵌在阿拉伯语句子中，需核对阅读顺序是否是从右先读 A-100 再往左读 B-200。若发生反转，需通过行内标记或 Unicode 隔离控制符（如 RLI/LRI 与 PDI，或 RLM/LRM）修正边界，而不是手动把单词顺序倒过来敲。

第三步：验收数字、日期、电话与度量单位

阿拉伯语及希伯来语中的数字属于“从右到左句子里的从左到右孤岛”，这是最容易看走眼的重灾区：

  1. 数字本身的读写方向：无论是国际通用的阿拉伯数字（0-9）还是东阿拉伯文数字（٠-٩），数字位数本身都是从左往右读的（高位在左，低位在右），绝不能出现个十百位颠倒的情况。
  2. 日期与范围连字符：像 2026-10-26 或范围 10-20 这类包含连字符、斜杠的组合，在 RTL 环境中极易被拆成 26-10-2026 或左右颠倒。必须对照原文核对年月日的实际语义顺序。
  3. 带符号的数值与电话号码：带有国际区号的电话（如 +971 50 ...）、百分比（%）、货币符号和负号（-），在无方向控制时，加号或负号常会跑到数字右侧。需要逐一核实符号与数值的相对位置是否符合目标语区习惯。
Chrome 中 RTL 段落内阿拉伯语句子中未隔离与添加 LTR 隔离后的日期及电话排版对比
自制示例在 Chrome 中的渲染对比：图 A 未加隔离时日期颠倒为 26-10-2026 且电话各段反转，图 B 经 LTR 隔离后恢复正常顺序。

第四步：验收表格列序与阅读流向

在从左到右的文档里，表格的第 1 列在最左边；而在阿拉伯语和希伯来语文档里，读者的视线从右上角开始，第 1 列必须在最右边。

  1. 表头列序镜像：检查表格属性是否已切换为“从右到左”。正常的 RTL 表格中，“序号 / 名称 / 数量 / 备注”应当从右往左依次排列。
  2. 单元格内部方向：表格整体方向翻转后，还要抽查含纯英文代码、邮箱或公式的单元格，确保单元格内部没有因为继承 RTL 导致代码字符错位。
  3. 方向性图标与箭头：流程表或步骤说明里的“下一步”箭头（→），在 RTL 语境下应指向左侧（←），但代表增长趋势的折线图坐标轴需视行业惯例谨慎镜像。
Microsoft Word 中阿拉伯语译文表格在默认列序与手动切换为从右到左后的对比
自制示例在 Microsoft Word 中的对比：图 A 意扣译出的原表格列序未翻转，序号列仍在最左侧；图 B 需手动将表格方向设为「从右到左」，首列才排至最右。

翻译工具初稿与人工复核的边界

在实际本地化流程中，先用文档翻译工具生成保留基本层级与样式的初稿，能省去大量复制粘贴的工作。例如使用**意扣（Equalang）**进行文档翻译时，意扣（Equalang）在支持的文档格式中会尽量保留原有的标题、段落、列表和表格结构，方便团队直接拿到可读的双语或目标语底稿。

但必须明确工具的客观边界：包括意扣（Equalang）在内的自动文档翻译工具，都不承诺所有 RTL 排版能够自动完美呈现。原文件本身的样式不规范（比如用空格凑缩进、用软回车断行、表格套文本框）、复杂的混排公式以及特定字体的回退机制，都会在不同渲染引擎下产生差异。

因此，用意扣（Equalang）完成初稿后，绝不能仅凭网页端预览就直接交付。团队必须把译文导出，在**最终交付的目标阅读器（如 Adobe Acrobat）和原生 Office 环境（且已启用阿拉伯语/希伯来语编辑语言支持）**中打开，对照下表做一次完整的人工复核。

交付前 RTL 文档验收检查表

验收模块必查项目常见错误症状复核与修复方式
段落与布局段落基础方向（Base Direction）段落只是“右对齐”，但行尾句号跑到了行首（最右侧）在原生 Office 中全选正文样式，将段落方向显式设为 RTL
段落与布局列表符号与多级缩进圆点或序号依然贴在左边，文字在右边，中间留出大片空白检查列表样式是否绑定了 RTL 段落属性，重置缩进方向
行内混排RTL 句中夹杂英文、URL、型号连续两个英文词加上中间的斜杠或标点后，左右顺序对调使用 Unicode 双向隔离控制符或内联方向标记包裹独立片段
行内混排括号、书名号与引号配对括号开口朝向相反，或右括号贴到了句子另一端检查括号紧邻字符的强弱方向属性，必要时补充 RLM/LRM
数字与符号日期、时间段、编号范围2026/10/26 或 10-15 被翻转成相反顺序核对原文数值，将纯编码/日期片段设为独立 LTR 方向隔离
数字与符号负号、加号、货币与百分号+ 或 - 跑到数字另一侧，语义变成减号或后缀在目标阅读器中放大核对，按目标语区规范固定符号位置
表格与图表表格列顺序与表头流向文字翻成了阿拉伯语，但第 1 列（如“序号”）仍在最左侧在表格属性中将表格方向改为“从右到左”，再检查合并单元格
字体与导出阿拉伯语连字（Ligatures）与断行转成 PDF 后字母断开不连写，或方块乱码在原生 Office 中更换支持阿拉伯语字符集的字体后重新导出 PDF，并在目标阅读器复核

只要把“初稿生成”和“原生环境排版复核”拆成两个明确的工序，先由工具处理大面积的文本转换与基础结构，再由排版或质检人员按上述顺序过一遍段落方向、混排边界、数字和表格列序，就能在保证交付效率的同时，把绝大多数 RTL 排版事故拦在发给客户之前。

参考资料