Sending the Baby on the Right Path: Quality Assurance as it Relates to Localization of Apps

Let's just admit it: at first glance, "quality assurance" doesn’t have a particularly sexy ring. It might even sound dry and tedious and repetitive. 

But in the localization world, we think QA is anything but dry and tedious. Sure, it might be a wee bit repetitive, but this is the stage when the localized app finally comes to life for us. After all the time spent on internationalizing (which could easily be called kind of dry) and localizing (which is fun -- but, yeah, also a little tedious) we now actually see our baby for the first time. OK, it's actually your baby, but we get to see it before you do. 

And that makes us proud.

It’s true - our linguists have worked very hard to make everything sound and read right, but this is the first time they see all their translations through the eyes of the new end user. Our audio engineers have spent hours making the audio and video clips sound just perfect and transition seamlessly in the new language -- but only now will they hear whether it all fits together the way they had imagined. And our software engineerscan't wait to compare the overall experience using the localized app and the original.

But aside from feeling good, we actually get some things done when we perform quality assurance.

The first step actually already happened before we even asked our linguists to translate, and it’s called a "pseudo-translation." Though it’s technically a pre-QA step, it's an important component of testing the app. 

The pseudo-translation populates all the translatable strings with language-specific gobbledygook -- at least that's what it looks like. In reality, it’s a doubled-up version of the original strings that contains language-specific characters ("gobbledygook" might be "гоббледогоокгоббледогоок" in Russian, "गोब्ब्लेडीजूकगोब्ब्लेडीजूक" in Hindi, and "جوببليديجووكجوببليديجووك" in Arabic). 

This will help us to determine:

 a) whether the app can properly process non-Latin characters

 b) whether our app deals properly with right-to-left text -- as in the case of Arabic

c) where we might expect spacing issues (translated segments can expand up to 100%)

If a and b present problems, we'll fix it right then; if c appears to be a problem we might add some more space, but more importantly we know that there will be plenty of fixing waiting for us later in the QA phase.

But again, this is the part of the QA that's already done. Now that the app has been translated, we need to focus on functional and linguistic QA.

Here’s what we look at with functional QA:

- Text handling: How does text input work with different input locales? (For instance, can I type Hebrew in the Hebrew version of the app?) Is that text stored and processed correctly? Are the fonts for the target locale set right?

- Locale standards: Can time, date, currency, and numeric values be entered properly and are they processed correctly? What about other kinds of measurements, zip codes, telephone numbers, names, etc.? Is text sorted correctly according to the locale? 

- Display: Is text truncated due to length restrictions? (Yes, in most cases!) Does text look strangely lost because it shrunk? (This is often an issue in East Asian languages.) Does the display work well for the devices that are used in the locale? (Resolution and density of the typical device screen in the target locale might differ). Does the display work correctly on a small phone screen and a larger tablet screen (if that is intended)?

Testing can be carried out for Android apps on the Android Emulator and for iOS apps on Interface Builder, but we actually prefer to do our testing on actual devices. This not only works better when testing platform-independent apps (as in HTML5/JavaScript) but also gives us more flexibility to test a larger range of real-life scenarios, compatibility, and usability. And it should give our customers a lot more confidence as well.

We use native linguists for the linguistic QA - different from the original translator and reviser so we know we’re getting a fresh set of eyes and an unbiased opinion. They will also be experts in the subject matter so we can rely on their passion for and understanding of the app's genre. And just like the functional QA team, they'll be given a detailed QA protocol that will ensure they check and find potential issues like these:

- Translation accuracy

- Cultural appropriateness

 - Politically sensitive content

- Technologically appropriate content (like "tap" instead of "click")

- Typographical and punctuation errors

- Misallocated text

- Overall usability of the UI

-Copyright issues (can the term "Olympics" be used in a sports game or not?)

- Noun gender and declensions (especially important in morphologically rich languages like German or Finnish)

- Consistency and adherence to glossaries

- Appropriateness and accuracy of error messages (an often overlooked area)

Naturally some of the fixes will have an effect on the functionality of the app and vice versa, so the teams for the functional and linguistic QA need to rely on each other and stay in constant communication.

If you’re not completely convinced of the necessity of a thorough QA for your app, here's a thought. Unlike traditional software packages, the most important driver for an app’s success is not a professionally written review in a glossy magazine or a glitzy website. Instead, it’s peer reviews and social media. A few poorly worded strings or glitches in the localized app could easily result in a poor user review on its download page or the one negative tweet that gets retweeted dozens of times.

Do you really have the luxury to risk your baby's future?

We didn't think so.

If you would like to learn more about localizing your app, we are here at PTIGlobal to help. Feel free to drop in our Portland office for a local microbrew and a chat with an amiable audio localizer about how we can help. Or shoot us an email and we’ll be glad to give you a call back. Or simply call us yourself at 503-297-2165.