自动化测试的第一波几乎没有涉及本地化（i18n）检查，因为主要市场集中在英语界面上。然而，随着应用程序的全球化，对本地化质量的要求上升：界面必须在所有支持的语言中正确显示，而文本资源和格式化字符串必须根据所选区域正确加载。
主要问题是手动检查非常耗费时间，而自动测试由于格式的多样性、上下文、语言的特殊性（例如，从右到左或语法特征）而复杂。可能缺少片段的翻译、格式错误、排版问题。
解决方案包括为每种本地化工作测试数据、使用快照测试、将UI元素与基准进行比较、按照“关键-值”原则实现资源文件的检查工具、通过API接口自动提取和比较字符串，以及定期运行资源文件上的linter。
关键特点：
可以使用一个脚本验证任何本地化的通用测试吗？
部分可以，但语言的细节（词尾、性别、输入方向）常常需要手动调整或在这些测试中添加额外条件。100% 的通用性是不可能的。
如果翻译文件存在且成功加载，这是否意味着i18n测试通过了？
不。文件可能在应用程序的一侧链接不正确，可能在关键点上出错，翻译的使用上下文可能被破坏，可能还有未考虑的特殊符号等。
对于用户少于1%的语言，自动化本地化测试是否有意义？
是的，如果即便一个用户的商业重要性很高，例如，在履行合同义务或在有特殊要求的市场中。自动化显著节省了与手动检查相比的资源。
团队在将.po文件中的关键与原始英文文本进行比较时实施了自动测试，认为这就足够了。他们没有编写UI测试 — 在阿拉伯版的发布中，发现所有文本都超出了按钮范围，一些字符串由于错误的关键根本没有被翻译。
优点：
缺点：
实现了资源linting与自动测试的结合，这些测试可以对所有语言的界面进行旋转，截图并与基准布局进行比较。发现RTL/LTR元素混合后，团队找出了根本原因并在发布前解决了它。
优点：
缺点：