Localization of Ranorex XPaths

Question

Our application is available in German and English, other languages may follow. Given I have an XPath like /form/button[@text="Login"], is there a convenient way to have it translated?

At the moment I'm trying with SAP GUI like this:

I wonder whether there's a concept like .NET Resources where you can have a Resources.resx file and a Resources.de.resx file.

Of course I could use /form/button[@text="{0}"] and then use a string.Format() call, but that's absolutely inconvenient because the "Highlight element" feature gets broken.

I have tried:

• looking at the properties of the .rxrep file, but it does not have a property that is related to my issue.
• introducing a variable, which basically works. The XPath is then /form/button[@text=$Variable] but I could not find a way of translating the variables.

Answer 1

Sure there is you can use xpath wih logical OR and have all transaltions inside the XPath expression.

For example you can use

/form/button[@text="Login" or @text="Eingeben" or  @text="შესვლის"]

3rd is Georgian :c). Risk of choosing different functionality due to translation, is very low.

Update: using the contains(A,B) can move it to higher level. Usually contains is used as

/form/button[contains(@text,"Login")]

but can be used oppositely

/form/button[contains("Login | Eingeben | შესვლის",@text)]

where you are free to choose the delimiter. It would work even with comas, simple spaces, or whatever you like

"Login , Eingeben , შესვლის"
"Login # Eingeben # შესვლის"

and then it could be just copypasted from csv or generated to a text array.

#end of update

But I recommend to glue your tests to other parameters than texts if available. This will be then translation independent. Application under development can change texts rapidly.

If design of the application is already fixed, you can use simple numbers, as

/form/button[3]

is a 3rd button in the form. This is not possible to use when application is still under development.

Answer 2

Using text values to identify elements is not good practice for this very reason. (And because the text may be changed later in the development life cycle of your product)

The best way to solve this is to get your developers to assign a unique identifier to the control. The exact property to set will depend on platform/UI library. On Windows you might use the AutomationId or tag property, on Android it would be rId.

Assuming a change was made to your unit under test to add a proper identifier, your new XPath might look something like:

/form/text[@tag='signInText']