Shopping has taken the e-route with new eCommerce sites showing their presence each day on the World Wide Web 🌐 Online credit card usage has gone beyond unimaginable proportions. Each company has a web presence, and when you add multi-language support to this mix, a true globalized website is there. It looks easy, but is it?
Website globalization is as complex as it gets and demands a significant investment of time and resources. Oftentimes however the planning is poor and the goals are not clearly defined. A wide range of technical hurdles and linguistic embarrassments easily stall website globalization.
The solutions are non-trivial. However, there are a number of “secrets” that may help you avoid some of the pitfalls of building and testing multilingual websites. Web globalization is still very much a practice one learns by doing. For many developers and businesses the thought of having multi-language support within their portals might never have crossed their minds.
They should however think of the benefits they will get from supporting multiple languages as this will likely lead to an increase in the rate of conversions, more user traffic, and a wider global reach. When a multilingual site is planned and created, there is much to consider, and it’s really all about localization and knowing the culture associated with the language.
The main focus
When we see a page containing an image in another language, the text on it still shows the English language. How do we plan for such scenarios? 💡 After a few tips for testing multilingual websites, I will explain a simple but effective mechanism to plan for such tests. While preparing for a testing strategy, focus on the following:
Know the cultural aspects
A simple but challenging aspect of testing multilingual websites is that each language might belong to a region that has a distinct culture. They may have a preference of color (Spanish people prefer orange), text direction (people in middle-east prefer right to left), the format of salutations and addresses, measures, currency, etc.. Apart from language translation, other elements of the user interface should also be correct.
The test environment is key for multilingual testing
It is not enough to simply change the default browser language and perform tests in both languages. Depending on how it is implemented, a website may identify the correct language for its interface from the browser language setting, the machine’s regional and language settings, or a configuration setting in the web application.
It is imperative that the website be tested from various machines, each having different operating systems written in a particular language. The browsers and operating systems should be the ones that the stakeholders have agreed upon during an initial product meeting.
Translations should be correct
Automated web translations always provide a good start and often translate correctly. However, nothing matches a native speaker of the language. The translation they bring to the table will be the best when compared with other technological translations. It is a good idea to compare automated translations from multiple sources before using them in the test.
Test labels first
Labels are the most static items on a web page. They are a great starting point for testing, as they tend to expand on translation. It is important to find any issues related to their truncation, overlay on/under other controls, wrong word wrapping, etc.. Once this has been done, another area to focus on is error messages.
The test should include generating all the error messages. If some text is not translated, three possibilities can exist. The text is missing, its English equivalent is present, or junk characters show up in its place.
Testing model for a multilingual websites environment
Let’s start with an example: We have an application with support for 5 languages. The automation suite is written in Java. The test framework uses different property files for each language. These files are in XML format to be used by Java code.
The challenge
The challenge is to obtain the translation, maintain the translated text and generate correct property files in the form of XML. We are not going to purchase any expensive tools, but have used tools like Google spreadsheets and a couple of spreadsheet functions to achieve the goal 🎯
Just by the use of a few simple spreadsheet tricks, we were able to generate properties files to be used with our automation suite. Manual translators are not available, hence we use Google translation service, which is the next best thing to manual translations.
Figure 1 shows what the Google Drive spreadsheet looked like:
All words, or keys, are written in one column. There are separate columns for each language. Each language has been given a code, as specified in ISO 639-2 Code. We have used the GoogleTranslate function within the Google Drive spreadsheet. Its syntax is GoogleTranslate (“text”, “source language”, “target language”). The source language here is English (en) and target languages are mentioned in each column.
Once this table is ready, our next step is to generate valid XML files, to be used by our automation code. Using simple concatenation formula, we develop the XML within a few seconds:
<?xml version="1.0" encoding="ISO-8859-1"?> <key-value> <name=Hello>¡Hola</name> <name=Advanced Search>Búsqueda Avanzada</name> <name=ISBN List>ISBN Lista</name> <name=Author List>Author</name> <name=Title List>Lista de títulos</name> <name=New & Used Textbooks>Libros Nuevos y Usados</name> <name=Bestselling Textbooks>Libros más vendidos</name> <name=Bestselling Authors>Autores más vendidos</name> <name=Bestselling Titles>Los títulos más vendidos</name> <name=Used Books>Libros Usados</name> <name=ISBN Search>ISBN Búsqueda</name> </key-value>
Then, it needs to be copied for each language, and once it does all of the required XML will be ready. Now, the automation script needs to be tweaked. The code needs to identify the control named “Advanced Search” and click on it. Whatever language you are on, the control’s internal name shall remain as it is, as shown in the XML. Hence, our script shall run fine on all pages, irrespective of what language the user has chosen.
So with a couple of Google functions and some basic coding skills, we can develop the data sets for each language. And, the framework developed to run our automation scripts is quick to recognize it. This will save all of us a lot of time in writing separate scripts for each language page ⌚
Conclusion
Although the practice of web production has matured rapidly over the years, the practice of web globalization is still very much in its infancy. With little examples to build upon, the web manager planning a multilingual site is often left with little direction and support. With the help of a simple Google spreadsheet and a couple of formulas, we can develop an effective test strategy to help us cater to our globalization testing needs ✅