Automation of Internationalization

[Karthik M S]

Hello Guys,

My project web pages supports multiple languages and the requirement is need to test the translation of each text whether its translated to respective language or not. Manual testing has been completed, need to automate the same. Please help me how to automate internationalization testing.

It can be with Robot Framework or C# Selenium.

Thanks,

Karthik.

[Sumit Deshmukh]

You can create simple navigational test scripts with xpaths as the object identifiers.
Once you create a script successful, let's say for English you can run same script in your desired language and use get text method to get the text of your element in that language.
Then you can put a validation in the script for each of the elements text.
You can follow same approach for all you languages.


Hope that helps......

[Tatu Aalto]

Hi

It is a difficult question, where there is not a single correct answer. It all depends how your application is built and how things can be done.

I am assuming that you do not want to test are the translated texts are actually correct, because it is a really hard problem to solve with automation and is usually better done manually with translation agency or by some other people who are taking care of the actual translations (and actually understand the language they are translating.) 

Generally I prefer to test localisation as much as possible outside of the UI. In many cases, localisations are just plain text files (in one format or another), which usually contains some sort of ID where the translation belongs to and the actual translated text. One can think it as key value pairs. In this case, I would build a test which reads all localisation files and compares that for each language has the same amount of translations. In my product English the master language, and I would read all ID from the english language and then I would compare that all other languages have the same ID available. If some language has less (or more) ID than English, then it would indicate that something is wrong with that translation. You may want to take this also further, example some text may contain placeholders, like links or parts that are dynamically replaced with other content. Those placeholders can be parsed out of the translation files and verified that they are placed within correct language ID. This takes care of testing the localisations files are in correct format and can (and must be) done with any interaction in the UI. Basically once that is done, it is pretty safe to assume that if one translation works, other will work too (work is a relative term, which we will back later.)

Then, for the most of the time, it is time to look at the translated text in the UI. Instead of hard coding the language into the test or to variables, I would do something like this. I would build the UI by using the same ID that is available in the localisation files. Example if there is a button whose purpose is to save something in the UI, that button ID would always (example) be "ButtonSave". Both in the UI and localisation file. Also I would need an easy way (read -> an API) to ask from the application, which language it is displaying in the UI. Then I would build a library which parses the localisation files (this is mostly done in the previous task), takes in the language displayed in the UI, ID and the text seen in the UI. And it would fail or pass is the text in the UI does not match in the text seen in the translation file. In this way, it comes pretty easy to navigate though the UI, fetch all the required text and ask from the library is the translation correct. 

But if you have many languages, going through all of them is slow and can lead to unexpected errors. Instead of testing all the languages all the time, I would test only two or three different languages. One that is not English, but is still written (mostly) with the same letters. In my case, I would choose FInnish, because I am from Finland. For the second language, I would choose something which is perhaps written right to left and as third I would choose something which is important in your application market area. But this is difficult to choose and does not have any hard rules. 

Also exploratory testing is needed to support automation. Automation can easily verify that correct text is there, but it is hard to get automation to understand about styles and text placement. I would perhaps divide this in two phases. 1) Every time new translation files arrive (new language is supported or some wording are changed in some language), I would enhance the first verification (with only parsing file) to notify someone in the team to look at the changed text in the UI. Does the text still alling correctly and everything else right in the UI placement. 2) When doing code changes in UI level, I would reserve time also go through different and most complicated languages which causes most of the problems.

-Tatu 

--
You received this message because you are subscribed to the Google Groups "robotframework-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to robotframework-u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/robotframework-users/995e8906-ce43-4a3c-9c6e-2aeea3bc6be3o%40googlegroups.com.