internationalization - 使用 Appium 的 AccessibilityIDs 的多语言移动应用程序 - 糟糕的配方
问题描述
我的团队支持以多种语言提供的移动应用程序。我要求团队实现 AccessibilityID，以便我可以运行 Appium 测试，他们确实这样做了。（我为什么要问这个？因为 Appium 测试中的每个人都在传达这是最好的方法。）
后来 - 应用程序在现实世界的可访问性测试（使用辅助技术 - 又名对讲或屏幕阅读器）显示需要使用上下文信息。例如，如果按钮有文本“提交您的订单”，则辅助功能 ID 应该是“提交您的订单”，而不是类似于“form_page_submit_button”
团队集思广益，解决方案是为我们不打算支持的晦涩语言创建一个 lang 文件。我们选择了“pt-PT”，所以所有元素都可以有一个在一段时间内不太可能改变的可访问性 ID。
现在这已成为一个问题，因为我希望使用英语和法语进行可视化自动化测试，而不仅仅是葡萄牙语，并且我希望不必维护其中包含 OR 的 xpath。例如，//*[contains(text(),'Submit') or contains(text(),'Soumettre')]即英语和法语。
鉴于我的应用程序需要对用户进行访问，而不是需要对测试脚本进行访问，我正在评估建议继续使用哪种元素选择器策略。我准备推荐使用 ID 或名称来缓解这个问题，但想更多地了解其他人在这个领域所做的事情。
解决方案
如果您仍然喜欢使用可访问性 ID 并支持所有语言，我建议为每种语言创建界面以获取相关的可访问性定位器。这将很容易理解和维护，当然努力会少一些，但我认为这是值得的。