Localization Bugs: Finding Them and Squashing Them

News Article

Time to read: 7 minutes

Article Contents

What is localization testing?
Getting ready for testing
The tester’s toolbox
How localization testing is performed
Three, two, one… launch!

A well-localized product is kind of like a chameleon. The translation merges so well with the original, gamers just become immersed in the game and can’t even tell the difference. They’re in their native element. They have access to the full range of meaning and emotion inherent in the gameplay. It may never occur to them that they’re playing a translation.

That’s the ideal. But, unfortunately, it doesn’t always happen that way. Sometimes players end up seeing how the sausage gets made.

And even if a game gets checked and rechecked during every stage of the localization process, there’s still no guarantee an Alienese letter won’t end up hidden in a tiny UI window somewhere. Or a couple of typos won’t sneak into a patchnote. Mistakes can turn up in the most unlikely of places. The worst-case scenario is when these mistakes get discovered by the players themselves. Fortunately, this kind of mishap can be avoided by using localization testing. So what is it, and how does it work?

Localization Bugs

What is localization testing?

Localization testing is a comprehensive check of the localized version of a product to make sure it corresponds to the cultural, linguistic, legal, and other norms of the target country. Here’s what localization testing evaluates:

The way localized text, graphics, and UI elements are displayed
Text translation, including primary content, system messages, HUD elements, etc.

Localization testing is a kind of “housecleaning” that takes place after the translators, voice actors, sound engineers, and audio directors are done. But is it worth spending your time and money on? Or should you just rely on your localizers — they’ll tidy things up on their own, right? Every developer of multilingual games has to deal with these questions. But before we answer them, let’s take a closer look at the process from the inside.

We’ll assume we’ve made our decision, and we’re going to test our game. What happens next?

Getting ready for testing

The first thing we need to do is send the testers materials that allow them to quickly get their bearing in the new game. These could include:

A walkthrough or design document describing levels, quests, missions, and core game mechanics
A glossary and text base
Screenshots and videos
Test cases and detailed instructions on launching the game and activating cheat codes

When it comes to large projects, the developers might even send special testing equipment. In some cases, since this is an early version of the game and all the information is confidential, the developers give the testers access on a closed server. Or they might connect and configure special programs.

Needless to say, the more materials the testers have, the easier it will be for them to figure out what’s going on and find bugs. But it’s also not uncommon for testers to have to evaluate a game using the “black box” method, i.e. without any hints or guidance, as though they were ordinary players.

However, if you’re only testing voiceover, the testers don’t really need to play the game at all. They just need audio and video files so they can evaluate sound quality, lip sync, and character acting and identify any potential noise or poorly-synced lines.

Things are even simpler when it comes to mobile apps, software, and websites. In this case, testers can get by just fine with screenshots of the interface.

Localization Bugs

The tester’s toolbox

A tester’s goal is to find bugs in the localized version of the software. Their primary tool is a bug tracker. This is a program that generates reports on all bugs that have been found. The resulting bug reports, which are sent directly to the developers, need to succinctly answer three questions:

What isn’t working properly?
Where was the bug found?
When or under what circumstances does it occur?

Additional information may also include:

The version of the product being tested; the platforms or devices the bug was found on
Priority: low, medium, high, or highest. This depends on how critical the defect is. Bugs of the “highest” priority need to be fixed right away.

Bug trackers from various companies differ to some degree, but the idea behind them is always the same: the tester needs to list the steps that cause the bug as succinctly as possible. They also take a screenshot or video of the problem. The “life cycle” of a bug, from discovery to elimination, is reflected in the status of the task.

How localization testing is performed

Searching for localization bugs is a special kind of evaluation. There are basically two kinds of evaluations.

The first is a cosmetic evaluation of the translated text. The text should be in the right place, displayed correctly, legible, and consistent with the game’s glossary.

Is there a Spanish word in the English localization? That’s a bug. Does it say “Closer” instead of “Closed?” That’s a bug. Are there a bunch of weird symbols where the text should be? That’s a bug. Is the font so tiny, you need a magnifying glass to read it? That’s a bummer… it’s not quite a bug, but it should still go in the report. Then either the designers can change the font or the editors can shorter the translation.

There are also mobile games where long English words need to fit inside tiny windows. And any change to the design can lead to unexpected results.

The second is an evaluation of the game from a linguistic perspective — this involves carefully proofreading all the text in the game. The testers focus on typos, missing punctuation and spaces, missing or distorted translations, incorrect capitalization or abbreviations, punctuation mistakes, and stylistic mismatches.

Localization Bugs

It’s also important to keep in mind that translators don’t always have access to the necessary context. When this happens, testers are the only ones who can evaluate the results. For example, let’s say a child says, “It happened when I was a kid." Ideally, the translator would have been given information about the characters and their ages beforehand. But in reality, this doesn’t always happen.

This kind of bug is far from rare. Here are a few of the most common kinds of bugs:

Untranslated text. This one is pretty obvious. A chunk of Russian text might show up in the English version. Or you might get a Spanish sentence in the Arabic translation.
Overlap. One section of text overlaps another.
Truncation. A word or phrase gets cut off by an interface element, icon, or the edge of the screen.
Misalignment. A chunk of text might be displayed in the wrong place or hard to understand, or it might interfere with gameplay.
Missing text. There’s supposed to be text somewhere, but it isn’t there.

If the tester has access to the text base or sound editor, they make corrections on their own. For example, they might find a grammatical or punctuation error, an inaccurate translation, or unwanted sounds in audio files. But this all needs to be coordinated with the editors and sound engineers.

More general suggestions and preferences are sent to the project manager, who acts as a liaison between everyone involved in the testing process. Efficient teamwork is vital on all levels.

Localization Bugs

Three, two, one… launch!

It might seem like localization testing is an unambiguously useful step. But sometimes developers skip it because they don’t have the time or money, or for other reasons. In this case, the localized product ends up being “tested” by the players themselves.

But, unfortunately, not all users are willing to forgive mistakes. Even a couple of seemingly insignificant gaffes could annoy a player so much they stop playing.

You might have a team of real professionals with lots of experience working on a translation. But since the localization was never tested, a couple of less-then-pleasant issues end up creeping into the final version. Sure, it’s just a couple of little bugs… but then the forums light up with comments like “I want my money back!” or “yet another crummy localization…”

Think of localization testing like checking a space shuttle prior to launch. They’ve got the best of the best working on that thing, but everyone agrees that all the systems need to be checked one last time before it gets launched into space. It’s just that important.

Sure, a video game isn’t a space shuttle, but it isn’t paper airplane either. When you launch it into the world, you want to be sure none of the bolts comes loose, and all your hopes and dreams for the future don’t go up in smoke on the launchpad.

This is what localization testing is all about: it’s a little extra insurance when you need it the most.