Website Localisation Testing, Where Did You Start?


(Heather) #1

In the past, I’ve worked in companies that talked about expanding the global reach of our sites by having the site available in other languages. This filled me with fear for many reasons:

  • None of us knew the native language of many of these countries well enough to navigate and know that the site was translated correctly.
  • None of us knew people in the countries to be able to check the translations or in fact translate for us.
  • None of us really knew where to start with it.
  • I had no idea how I would test localisation.

I was wondering if people would share their experiences of website localisation testing. Where did you start? What resources did you find useful? What pitfalls did you encounter that you would warn others against?


(Robert) #2

Effective localisation is not just down to language, or date format, or phone number format or currency signifiers (the four commonest things that, amongst others, help identify spam e-mails!); there are a whole range of legal, cultural and other idiomatic issues that need to be taken into account. After all, Brits can usually spot a website originating from the US even though both are written in English. For example, US websites will often Capitalise Every Word In A Heading!


(gordon crawford) #3

This might be cheating a bit but our site is currently available in around 20 languages and we have an entire department whose job it is to provide the translations for the text we want to display on site. So the concern of being able to understand the text has been removed as they are responsible for the accuracy of the translations and when it gets to us then you are just concerned with checking displays when the translated text is significantly longer than the English, truncation, special character display…

Something i read recently on this topic which I thought was interesting was this post from Netflix about how they deal with these issues.


(Heather) #4

I posted this today on the testers.chat slack group and got some great replies:

Mike Ruttenberg shared (if the link doesn’t work, you need to allow adult content as Wonderproxy sometimes gets blocked by ISPs because people use Wonderproxy to bypass restrictions):

and said

I had Sitecore at my disposal, btw, which is great for localisation

I wouldn’t worry about the copy, it’s more about the visuals, ensuring nothing is hard-coded, and that accents render, and complex font characters, line spacing, correct text direction, text lengths don’t wrap awkwardly etc

@akazukin shared:

We used a VPN, and tested at least one valid country per continent, and one non-valid. Also tested those who were most important to work, and confirmed the languages.

@thatdamnqa shared:

Something I learnt from working on a German site is to make sure that page layout doesn’t break with long words, too. As German have longer word lengths.

@dominickua shared a blog post he wrote about this recently


and

Also make sure the page’s inputs work with the translations, Dropdowns, radio buttons etc can all be a bit different and if you have any level of auto complete, makes sure it doesn’t break your IME if you’re using that input method.

Some other great tips from folks in the chat:

check your translations work Cross-browser if your doing web - I’ve seen issues where font-files and extended char-sets were done in a way it broke in IE11
oohhh AND - I’ve also seen it where the translation being copied in was stored in UTF-8, destroying the extended chars! encoding becomes important

you’ve gotta out of scope language/translation stuff unless that’s been explicitly agreed and you have the people with the skills for that.


(Shey) #5

I’ve been on quite a few projects where the application or page is localised. There are some tips/rules I follow

  • learn the “idiosyncratic” differences between two similar languages (echoing @robertday). For example, on slot machine games you need to use Arrêtez instead of Stop for Canadian games, but no other French version.
  • German words can get very long so as @thatdamnqa said switch to this to confirm page layout
  • Where possible use a VPN (as mentioned by @akazukin) to confirm that language detection kicks in correctly and the user is presented with the correct version of the language (especially similar languages - again I use French Canadian and French as an example)
  • If you received a localised string in any Microsoft software to ingesting into your application always convert to a text format which removed the custom artefacts Microsoft add around non-standard characters
  • Blink tests are king when you don’t know the language you are testing
  • There are two main types of localisation, in-person and algorithmic. Algo localisation can come across to a native as very formal and staid. If you can get a native speaker to double check the output as it may not match with what people actually say
  • If you are testing legal documents, or testing in a regulated environment don’t certify localisation. Leave that to the team or service who do that as their job
  • Unless you are a native speaker, make sure your managers know you are not testing the content but the formatting of the language
  • And finally, if you do a lot of localisation verification/testing develop yourself a crib sheet of localisation differences and punctuation (eg double << >> for quotes in French)

(Kate) #6

Another trick if you don’t know the language - use two monitors side-by-side. Have one showing the page in your language and the other (whether VPN or not) showing it in the language being tested. That way you won’t have to memorize every button, dropdown, label etc.


(Olaf) #7

Get all your labels translated to whichever language/languages you need.

Ensure that all labels on the page are in resource files instead of hardcoded, then prefix and suffix each individual label with a clear character, e.g. [ and ]. Pad the labels out to whatever maximum you’re aware of plus a couple of spare characters.

All you need to do now is look that the page still looks good and making sure that the starter and ender characters are in place. To verify that it works for different resource files, use different starter/ender characters for different languages.


(Paul) #8

@katepaulk I love that trick with looking at things side by side. I use Spectacle on my mac to make it easy to make a window “left half of my screen”, and another “right half of my screen”. I think this might be built into Windows.


(Kate) #9

It is in Windows 10. Dragging a window to one side of the screen will size it to that half as soon as the mouse hits the correct place, the same as dragging to the top will make it full size. I have multiple monitors at work so I don’t need to use the left half/right half thing, but it’s almost as good as using multiple monitors if you’ve got a decent screen resolution.


(Vishal Dutt) #10

Localization testing is a type of testing wherein the focus is on verifying the localized/translated version of the application. So, in order to provide quality assurance services in these areas, a software tester should follow the the below mentioned points.:

  1. Update your machine’s date/time according to the targeted region.

  2. All the labels, page headers, text, validation/warning/error messages etc should be correctly translated to the target region’s locale.

  3. Postal Code, Phone numbers should be as per the region’s format and further currency (if used anywhere in the application) should be correctly converted.

  4. Various Colors schemes, symbols and icons that corresponds to that region should be kept in mind. Sensitive text, pictures and graphics of the region (esp religious/cultural/linguistic) etc should be interpreted correctly.

  5. Always make sure that your application is following the local country/state laws esp if your application involves business transactions.

  6. Always make sure that license text (if application have any EULA) is correctly translated and adhere to the region’s legal requirements.

  7. Always make sure that UI is not compromised in any way while accessing the localized version of the application on web/mobile platform.

  8. Verifying accessibility aspects of the application on localized version is also recommended.

  9. Region’s locale(alphabets, numbers, symbols or any other special characters etc) should be accepted by the application.

  10. Sorting, writing directions, calendar format etc should be correctly followed during translation.

Localization testing is also recommend to make sure that application resonates with the local culture. Hope this information is helpful for you.


(Michael) #11

When I was working at Blast Radius, we built the English template site for NIVEA using Sitecore v6. Then we added slowly but surely more languages, in the following order: Austria (always their first German-language testbed market), then other western European languages, then Cyrillic languages, then we did Chinese, Japanese and Korean, then Thai, then RTL languages (Arabic and Farsi), then Hebrew (we could do it but we didn’t have the content until much later). All of them involved inputting dummy language content and length checking to start with, and then seeing what did and didn’t work visually.

I recently wrote an article using things I learnt on the job. To me it was all fun playing with CMSes, seeing the breakages and retesting them having been (hopefully) fixed.

Here’s a link to the article, which you might find helpful: https://wonderproxy.com/blog/9-tips-on-localization-testing/

My biggest suggestion: Break up any CSS files into language groups, so when you “fix” one you don’t break another.