该问题源于原本为西方 拉丁 字母架构的遗留企业应用程序的全球化，在扩展到 中东 或 亚洲 市场时，关于文本方向性、字符编码和固定宽度布局的假设导致了系统性故障。早期的国际化工作往往将本地化视为单纯的翻译，忽视了 RTL（从右到左）脚本需要镜像布局，像 日语 这样的复杂脚本则需要考虑竖排文本，而排序序列在不同文化中有显著差异。
手动 QA 面临的挑战是验证不可见的编码层（UTF-8 与 UTF-16）、检测当 LTR 产品名称嵌入 RTL 界面时微妙的 BiDi（双向）算法故障，并验证区域感知函数（日期解析、货币舍入、地址格式）是否遵守 CLDR 标准，而不打破遗留业务逻辑。缺少自动化视觉回归工具更加加重了这一点，要求测试人员手动识别一个显示 "٢٠٢٤/٠٥/١٥" 而非 "2024/05/15" 的 DatePicker 并非仅是外观问题，而是指示错误的 伊斯兰日历 回退逻辑。
解决方案实施了一种 Locale Matrix Testing 方法，利用 伪本地化 作为早期的烟雾测试，随后对 Unicode 范围进行 边界值分析（例如 阿拉伯语 0600-06FF，中文 4E00-9FFF），并配合母语者的 文化接受测试。这涉及创建测试数据以运行 BiDi 控制字符（LRE、RLE、PDF），验证 ICU（国际组件用于 Unicode）库的数字格式实现，并利用 浏览器开发工具 强制设置 document.dir 属性，同时手动检查 flexbox/grid 布局的镜像完整性。
一款处理 B2B 采购的遗留 Java Spring 单体应用在进入 沙特阿拉伯 和 日本 时，原本只为 英语 和 法语（LTR）设计的界面需要引入 阿拉伯语（RTL）和 日语（汉字 + 假名 脚本）。该应用使用服务器端的 JSP 渲染与客户端的 jQuery，而数据库层依赖于默认的 ASCII 排序设置的 PostgreSQL。业务利益相关者要求手动测试阶段在三周内完成，而不购买额外的 SaaS 本地化测试工具，从而对测试方法论造成了约束。
关键缺陷在采购订单确认屏幕上体现：当买家输入同时包含 阿拉伯 数字（١, ٢, ٣）和 拉丁 字符（SKU 代码）的产品名称时，BiDi 算法导致 CSS flexbox 布局视觉上打乱了数量和价格字段。此外，PostgreSQL 数据库在使用 ASCII 字节值而不是 Unicode 排序算法（UCA）标准对 日语 产品名称进行排序时，导致搜索结果在用户看来呈现字母随机。这些问题在自动化单元测试中是不可见的，因为 HTML 在 DOM 中正确渲染；只有视觉检查才能发现 RTL 镜像逆转了成本和数量字段之间的数学关系。
首先，逐个区域的测试涉及在开始 日语 之前彻底验证 阿拉伯语，这提供了深度文化聚焦和简化缺陷隔离的优势，而不需要语言切换的额外负担。然而，这种方法未能发现不同区域之间的干扰，在用户会话中切换语言时，阿拉伯 会话 Cookie 干扰了 日语 的 UTF-8 编码，并使测试所需的日历时间翻倍。特定区域 CSS 文件之间可能缺失的集成缺陷风险超过了逐个区域聚焦的好处，尤其是在三周的紧迫截止日期下。
其次，提议使用自动化 Selenium 视觉回归来捕获跨 BrowserStack 设备的屏幕截图，并比较 LTR 和 RTL 布局之间的像素差异。尽管这提供了速度和一致性来检测 CSS 边距的变化，但遗留 JSP 前端使用绝对定位和动态生成的 CSS 类名在构建之间发生变化，使得像素比较工具在没有大量维护开销的情况下变得不可靠。此外，Selenium 只能验证 BiDi 逻辑顺序或 Unicode 排序的正确性，只能检查外观，无法满足功能要求。
第三，设计了一个 Locale Pairwise Testing 矩阵，选择高风险组合：在 Windows/Chrome 上的 阿拉伯语、在 macOS/Safari 上的 日语 以及使用嵌入了 LRE、RLE 和 PDF 控制字符的 BiDi 压力测试字符串的混合内容场景。此方法优先考虑统计上最具问题的环境组合，并允许测试人员手动检查不同 LCID 设置下的 ICU 库输出的日期格式和货币符号的放置。虽然在测试人员知识上的资源消耗较高，但它在前端 JavaScript 和后端 Java 控制器之间提供了对 UTF-8 编码握手的全面覆盖，而无需自动脚本维护。
团队选择了第三种方法，因为它在严格限制下平衡了全面性，具体是在 LTR 低峰时段测试 RTL 布局以最大化 DevTools 检查时间。测试人员手动注入 ZWSP（零宽空格）字符和 RLM（从右到左标记）到产品描述中，以强制生成边界条件，并利用 浏览器 的区域设置覆盖来同时模拟 沙特 和 东京 时区。这一决定将检测 BiDi 算法故障和 Unicode 归一化错误置于纯 UI 像素完美之上，与采购订单中数据损坏的业务风险保持一致。
最终结果识别出十四个 P1 缺陷，包括当 Unicode 归一化在数据库驱动层将复合 日语 字符转换为单引号时暴露出的关键 SQL 注入漏洞。部署后，沙特 用户在运营的第一个月报告零排版错误，而 日本 客户的搜索准确度在实施 UCA 兼容的排序序列后提高了 340%。手动测试方法成功防止了由于采购订单错误而导致的收入损失，同时为未来的 韩语 和 希伯来语 扩展建立了可重用的 i18n 测试数据库。
如何在既不理解语言又含有 RTL 内容的情况下检测嵌入其中的 LTR 文本（如 URL 或产品 SKU）时的 BiDi（双向）算法故障？
候选人通常仅依赖视觉检查，忽视了 BiDi 需要检查逻辑顺序与视觉顺序。正确的方法是将可疑文本复制到禁用 Bidi 渲染的 纯文本 编辑器（如 Notepad++）中，以查看潜在的存储顺序；如果 "ABC123" 在数据库中显示为 "123CBA" 但在屏幕上显示为 "ABC123"，那么 BiDi 算法错误地应用了 LTR 覆盖。测试人员应构建 "伪本地化" 字符串，结合 阿拉伯 字母、希伯来 标点和 英语 数字（例如 "מוצר_ABC_123_تجربة"），然后验证选取高亮（点击并拖动）遵循逻辑而非视觉顺序。此外，检查 HTML 源代码中的 dir="auto" 与显式 dir="rtl" 可以揭示浏览器是否在猜测方向性，当用户生成的内容缺失 RTL 标记时，这种方法会失效。
什么是 阿拉伯 文字排版中的 Shaping，为什么它在手动测试中造成的功能缺陷超出了外观问题？
阿拉伯 Shaping（或 Glyph 组合）指的是字符根据其在单词中的位置（开头、中间、结尾、孤立）而改变形式。候选人通常忽视这影响功能性测试的事实，因为相同的 Unicode 代码点可以根据字体的 连字 支持而以不同的形式呈现。例如，Lam-Alef 连字（ﻻ）是表示两个字符的单个字形；如果搜索功能索引原始 Unicode（两个单独的代码点），但用户输入方法将其组合为连字（一个代码点），则由于视觉上的相同，搜索返回零结果。适当的手动测试需要将文本从 UI 复制回十六进制编辑器或 Python repr() 输出，以验证代码点序列是否匹配，并使用明确禁用 连字 的字体（如 Courier New）进行测试，以揭示潜在的字符存储问题。
如何验证不懂的语言的正确性，如验证 瑞典语 将 'Å' 视为在 'Z' 之后的不同字母，而不是 'A' 的变体？
测试人员常常假设 ASCII 排序或数据库默认排序就足够了。解决方案涉及 参考数据验证：获取官方政府或学术单词列表（例如 瑞典语 Språkrådet 词典）并将其作为 CSV 测试数据导入，然后将应用程序输出与预期序列进行比较，使用 diff 工具。在 不区分大小写 的匹配中，验证 土耳其语 的 'İ'（带点的大写 I）是否正确映射到小写字母 'i'，而 英语 的 'I' 映射到 'i'，同时使用 土耳其语 区域（tr-TR）设置在 浏览器 偏好中。手动测试人员还应执行 边界测试，使用双音节组合（Ch 在 西班牙语 中、LL 在传统 威尔士语 中）确保它们作为单个单位进行排序，而不是单独字母，必要时根据 CLDR（通用区域数据存储库）图表进行验证。