本地化 QA：pseudo-localization 一次查漏三种病

背景与问题

多语言铺开（欧州带策略见 c-poland-market 等）后，翻译文字变长 30-40% 导致 UI 破版、硬编码漏翻、RTL 布局未镜像——三类病都上线后才被发现。pseudo-localization（伪本地化）能在写代码阶段一次查完。

发现

（来源访问日期均为 2026-09-17）

• 事实（行业通识做法，Apple 官方国际化文档 / Android 开发者文档）：两平台都内置伪本地化/展开式区域设置（如 en_XA：字符加倍+装饰括号）——文本扩展、截断、硬编码字符串在普通语言下不可见，伪本地化下全部显形。
• 事实（Android pseudo locale）：Android 提供 en-XA（重音+扩展）与 ar-XB（假 RTL）两种调试区域——RTL 病也能在无真翻译时预演。
• 事实（结构原则）：只要 UI 全部经字符串资源（iOS Text/Android strings.xml）输出，伪本地化即可覆盖；绕过资源系统的硬编码字符串会保持原样——一眼识别漏网点。
• 推测：solo 的本地化病根不在翻译质量而在「改动后不复测」——新功能加了硬编码文案、旧布局被长文本撑破。伪本地化做成回归检查项后，这三类病从「上线后用户报告」提前到「提交前自查」。

结论

1. 工作流：新 UI 完成后切 en-XA（+iOS 双倍长度预览）过一遍主流程 → 全部文案显示为「!!装饰字符!!」=无硬编码 → 溢出即改布局 → 提交。10 分钟/次。
2. 三病对照：①文字变长破版 → en-XA 扩展字符直接暴露 ②硬编码漏翻 → 未变形的原文字符串即漏点 ③RTL 破版 → ar-XB 预演（c-israel-market 的 RTL 前置成本由此降一档）。
3. 与翻译流程的衔接：pseudo 通过后再送翻（c-localization-transcreation 的创译只对营销页）——把创译预算留给 listing，工程文案机翻+pseudo 自查。
4. 每次发版前在 opc-release-precheck-5min 加一项「pseudo 走查通过」。

待办 / 下次继续

• 主力产品切 en-XA 走查一次主流程（预计发现 3-5 处漏点）。
  
• ar-XB 预演留档截图（未来 RTL 化的基线）。
  

关联

c-poland-market c-israel-market c-localization-transcreation opc-release-precheck-5min