Java multilingual App and PageFactory Locators

Support
1

Hi all,
I’m trying to automate a third party app, and many times you have no IDs or other than xpath with the field Text. I mean, you have to reach the element by a text that changes depending on the language. For example:
New
Nuevo
Nuovo

So, you have to write 3 locators each time you need to reach by text:

public final String EN_TXT = "New";
public final String ES_TXT = "Nuevo";
public final String IT_TXT = "Nuovo";
@HowToUseLocators(androidAutomation = ALL_POSSIBLE) 
@AndroidFindBy(xpath = ("//*[contains(text(), 'EN_TXT')]"))
@AndroidFindBy(xpath = ("//*[contains(text(), 'ES_TXT')]"))
@AndroidFindBy(xpath = ("//*[contains(text(), 'IT_TXT')]"))
MobileElement someElement;

Doing something like this is not possible because of Java annotations nature now allowing to use Variable values on Runtime:

@AndroidFindBy(xpath = ("//*[contains(text(), '" + someValueFromPropertiesFileDependingOnSelectedLanguage + "')]"))
MobileElement someElement;

So, the question is… how do you do it in a simple way? Do I have to write a locator strategy for every language? I found 2 solutions online but I think (hope) should be a easy way

https://medium.com/@harshitj.qa/localization-testing-with-appium-grid-ef7dadb09fa2
https://webelement.click/en/parameterized_findby_annotation_in_selenium_page_object_java

Thanks in advance and regards

2

xpath supports more complicated queries using logical operators. See https://stackoverflow.com/questions/12152890/xpath-contains-one-of-multiple-values for example

Although, for this particular case I would rather consider adding unique element identifiers to each element, which should look the same independently of the selected language.

3

thanks for your reply. This can be a solution if there are no more specific implementations around to solve the multilingual stuff.

As for the unique identifiers, I have no access to the code or developers of the app so I have to adapt the automation to what I have, unfortunately.

Thanks again

4

I don’t know about Android, but for iOS there are localization files inside the .ipa file. We extract the localization files and then pull them into a hash. The English ones will look like this:

"Next" = "Next"

and Spanish, for example, will look like this:

"Next" = "Próximo"

If you’ve coded for the next button, and you have a setting for Spanish, it’s pretty easy to substitute the value of the second since the key for both languages is the same.

I think there are similar files in the .apk that you can use for Android.

5

btw, Appium has a dedicated API for extracting .app or .apk strings from resources. For example, in Java client check https://github.com/appium/java-client/blob/master/src/main/java/io/appium/java_client/HasAppStrings.java interface

6

Thanks, but we never did it that way. I make a copy of the ipa file and rename to .zip and then unzip with decompression tools. We actually take a look at a lot of info that is going to be published in the RC and compare with the most recent version. Whole different discussion.