Didn't we already fix this? Why you keep seeing the same bugs in localization QA

A friend of mine recently came to me with an issue: his video game kept seeing the same localization bug time and again, sometimes long after fixing it. "It's driving me mad," he said.

Localizing your video game serves many purposes, from a surge in sales in targeted markets to higher markings in app stores.

Whether you are targeting the usual EFIGS languages (English, French, Italian, German and Spanish), expanding further internationally (Latin American Spanish, Brazilian Portuguese, Simplified & Traditional Chinese, Japanese, Korean and Russian) or targeting hot new markets (Arabic, Turkish, Hindi, Indonesian, Polish and Dutch), there is no doubt that localizing your game comes now with huge upsides that can dramatically boost your game's commercial success. Did you know that simplified Chinese was the most popular language on Steam in 2020?

Despite its undeniable benefits, however, video game localization can be a particularly strenuous process

Despite its undeniable benefits, however, video game localization can be a particularly strenuous process. Whether it's managed indirectly (using a specialized provider) or directly through web of international professionals, the workflow is typically as such:

1. The localization team, made of professional linguists, handles the translation and quality control (editing and proofreading)
2. The localization QA (Loc QA) team, made of native speakers, tests the build to check the integrated content

Used wisely, this ensures that issues are filtered out at every stage. But because this process involves multiple steps, and time is of the essence, it becomes imperative that the flow does not circle back endlessly. So why are these issues coming back?

A flawed memory

Imagine having an alarm clock connected to the Internet. After you arrive late for your train one morning, you understand it is off by ten minutes. So, when you get home, you advance the time until it matches the correct hour. The next day, however, you are ten minutes late again. How can that be? Well, it is because every night, unbeknownst to you, the clock is reset to its standard factory time.

In the localization pipeline, this "factory time" would be the Translation Memory (aka, the TM). It is the database that remembers your project has been translated in the past, pairing your text with past results depending on how closely they match. It is one of the most powerful tools a translator can use, essential to the consistency of your game, and a big time and money saver. But it was not originally created with video game localization in mind.

Because games are iterative, their content faces a constant stream of changes that makes the curation of multiple databases especially complex. And since the Translation Memory is typically not in the hands of the development team, it becomes easy to overlook what it remembers.

Let's say that, following a bug report, you've shortened a few lines of dialogue in German because they were bleeding out of a text box. Later, as you add content to your game, you abbreviate some of those lines in English (the only version the devs handle directly) then send them to your localization provider, who runs it through its TM before they are entrusted to the German translator.

For each sentence, the TM's database checks the English text to see if it has translated it before. If not, it tries to suggest something similar. But while it accurately tracks the changes in your original text, the database assumes every translation it remembers is correct by default.

There is no substitute for the Translation Memory and attempting to localize a game without it would lead to even more issues

In this example, the TM will not know you have shortened the German translations. Instead, it will look at the English source and tell the translator: "It's 95% the same sentence as last time, only the character name has changed." As translators have rarely much visibility on the game itself, they will not know their earlier work was fixed by the QA team. They'll only get the TM's suggestion of the abridged English version, which won't be shorter in German, unknowingly propagating a mistake, just like that alarm clock at the beginning of this story.

It is important to note that there is no substitute for the Translation Memory and attempting to localize a game without it would lead to even more issues. The key is rather to maintain it properly, so what it remembers matches accurately your game's content. But whose job it is to maintain it?

The management solution

• Your team uses a localization provider who handles the Translation Memory

We have seen that fixing a Loc QA bug in the build will only work as a temporary solution, if not fixed at the root. Thankfully, this should not mean more work on your team's behalf if you:

1. State your intentions with your localization provider, so a proper workflow can be established.
2. Once Loc QA is done, before any new translation, communicate a multilingual Excel change log with all the updated strings (i.e. the newly edited text from the original source language) to your localization provider so they can update their database.

Always indicate clearly what content is meant for translation and what is there to add context

Alternatively, you can also send the entire loc file, that contains all the text content from the game, to your localization provider and let them sort it out. However, you will need to make it clear that the translations have been updated so they do not get overwritten by mistake. Always indicate clearly what content is meant for translation and what is there to add context. For that, I suggest adding a column (easier to filter) with statuses depending on your needs (for instance: for localization, locked as already approved, and so on), though color-coded highlights are also an option.

That's it? Almost, but not quite. Beyond the technical hurdles, another memory is worth mentioning: the localization team's collective knowledge.

Because localization and Loc QA are two distinct steps, performed by different people with distinct linguistic abilities, you will need both teams to share what they know about your game, from past issues to linguistic solutions found along the way.

While it may sound beneficial to use different providers for localization and Loc QA (to assess the quality output), the best solution is to have both teams consolidated into a single provider, so all the information is properly shared. But even then, you must be mindful of inter-departmental logistic barriers that would prevent the flow of information to circulate. Always feel free to ask your provider about their workflow, how references are stored and shared, and how Loc QA corrections are escalated internally.

By working hand in hand, translators will provide their linguistic expertise, while Loc QA testers will assist with contextual awareness and game knowledge. A good localization for your game requires both.

The technical solution

• Your team has ownership over the Translation Memory

If you are directly handling the Translation Memory, you will need to update it yourself. No matter the software you use (typically, a CAT tool like MemoQ, Trados, Memsource), there are two ways to do this:

1. Update the master TM by importing a multilingual Excel file with the edited translations
2. Create a second, distinct TM that contains the Loc QA changes or a finalized version of your loc file

Both options are valid but serve different purposes. In the first scenario, the most recent version will be applied automatically, whether it originates from your translators or Loc QA. The downside is that the TM will contain different results, from people with different linguistic backgrounds and abilities; this could lead to a turf war between reviewers.

No matter your preferred solution, your main objective should be to make it painless for your dev team

⇨ Use this option if you want to enable the translators to regularly review the Loc QA's changes.

In the second scenario, you will need to set up the priority order correctly, so the text that has undergone the Loc QA team's review is suggested rather than the outdated version. This will also ensure the integrity of the Loc QA TM, apart from the one used during translation; but it will also prevent translators, more experienced linguistically, to make their own adjustments.

⇨ Use this option if you want to make all Loc QA's changes final.

In essence, you are asking yourself one question: "Do I want changes from Loc QA to be final?", even though testers aren't professional linguists like translators. If 'no', then option 1 is better. The newest version always takes priority over the oldest, no matter who wrote it.

If 'yes', then option 2 is better. The Loc QA version (similar as what should currently be in your game) is set in stone, and translators will have to abide by it. Both options work, but you'll need to identify which suits your game and workflow the best.

By making sure corrections are exhaustively applied to all databases and linguists are properly informed of all changes, you will have taken the necessary steps to durably eradicate your localization bugs.

But in the grand scheme of things, localization is only a small part of a video game's production cycle. No matter your preferred solution, your main objective should be to make it painless for your dev team. Features will change, and the text along with it, so any localization process that requires too much minutiae will become unsustainable.

Going back to the alarm clock, rather than setting the time daily, my advice would be to call the factory and have it fixed once and for all. Because no matter what they do behind the scenes, you are fine as long as you catch your train.