Hey, everybody! It’s been awhile since my last blog post. I’ve been busy with lots of stuff such as becoming a dad to a beautiful little girl (with another on-the-way!), learning more about testing, and actually testing stuff too! But I’ll try to come back and write more. update: It’s been a while since I wrote this that now I have 2 beautiful girls 1 and 3 year old.
For the past few months I have joined a few testing communities and have observed the same question being asked over-and-over
“I have an upcoming internationalization (a.k.a. i18n) project and I don’t know where to start, or what to test.”
Granted. I’m paraphrasing a bit. But that’s the gist of all these questions. Luckily, I have experience with such work – twice with two different SDLC approaches using my experience in two different languages (Spanish, my native tongue, and English, which I’m still learning).
With that being said, I’d like to go through some points I would consider important when testing an i18n effort.
- Become involved in the architecture process early on. Go to the meetings. Read all of the project documentation. You should try to develop a solid understanding of the development team’s approach. For example, In one of my projects they used POT and PO files for “in-house” translation. For the other project, the company used a third-party vendor that offered a translation platform.
- Identify the risks. In one approach, we sent to the translators the strings, then, after translation, once that was done the third-party would serve them to the end-users. In this situation, the company risked user experience if their servers went down.
- Become involved in the development of the translation process. For example, learn all of the steps that it takes for an English string to become a [insert your language here] string. Make sure that you ask the following questions: Are we using “in-house” translations? are we using third- parties? what happens if a string is poorly translated? Will the “poor” string go through the whole process again? How much time would it take to a string to go from submission to show up, translated, onto our site?
- After the translation effort kicks-off, your development team’s goal should be to send the source strings to the translators as soon as possible. You could potentially impact the release schedule if you need to wait for the translation process to become complete.
- Ensure that you know where and how the translated strings are delivered as well as how you can evaluate them. In one of my projects we couldn’t get the translations immediately; however, the third-party vendor used a language called “reversi” which would turn our strings backwards. This allowed us to verify that the strings were ingested, or passed correctly. For example, when the string “Something like this” was correctly ingested, “Gnihtemos ekil siht” would display. That way we could ensure strings were passed correctly, without having them translated yet.
- Identify design issues. Some languages like German, Portuguese, and Spanish are much longer than English which means they can break your design – especially in mobile platforms. Ask your product owners and whoever else provides copy for shortened versions of English strings so that the translators provide the shortened strings in the target languages.
- When testing the translations in the applications, ensure that you test every string. Sometimes everything can be translated, except for ONE string; it can be a button, a menu, an error modal box – anything.
- Remember that dates are formatted differently in different languages. In Spanish the day goes first, and then the month. Actually, just check for differences any time you reference any units.
- Understand the logic for how a user selects languages as well as how those languages are displayed. For web, at least, there is different things that you take into account; however, it can become tricky and convoluted really fast. For example, you could use the browser language, but you need take into account that, in Latin America, some computers are sold with the OS language in English – browsers would be installed using the same language despite the fact that the user may not prefer English. Always have tools available on your site to allow users to change the language setting. You could use the user IP or GPS, but, then again, an American could be traveling to Cancún, MX and may become confused when they use the application and it’s suddenly in Spanish. Always leave the final decision to the user. A good combination of IP+browser/OS language is your best bet!
- If you are testing on a Mac and need to switch the browser language, try to use Chrome less because you need to change the language of the whole OS in order for the change to appear in Chrome. The best option is to use Firefox because you can change the language from the browser’s preferences.
- If you are using location (IP) for your translations, then you can use a proxy tool like HMA or AdClarity to switch languages.
- If you are going to implement automation, then you will need help from your development team in order to avoid looking for strings. You need them to be specific and completely identify their setup, you need them to use classes, ids, tags, or other identifiers that you can take a language-agnostic approach when testing all of your target languages.
That’s all I’ve got for now… Do you have any other suggestions? let me know in the comments below. Happy 18n!