Sections

Find out how to kick start your games industry career

Get Your Free Ticket Today

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

Amber's John W. Park explains the subtleties of working with a Translation Memory database

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.

Departeding Switzerland in 2009 to establish a career in video games and creative industries in Montreal, John W. Park has spent the last ten years building knowledge in translation, localization, and AI. In 2020, he joined Amber to help build their new localization operation with an emphasis on custom solutions and consultancy.

Find out how to kick start your games industry career

Get Your Free Ticket Today

More stories

FIFA doesn't want an exclusive license deal

Longtime EA Sports licensing partner says "it is clear that this needs to be a space that is occupied by more than one party controlling all rights"

By Brendan Sinclair

Steam bans blockchain and NFT games

Age of Rust developer says Valve won't let it publish the game on Steam because NFTs have real-world value

By Brendan Sinclair

Latest comments (2)

Alfonso Sexto Pereyra Quality Assurance Manager, DACS Laboratories GmbH4 months ago
Nice article to read in the Morning. I started my career in the industry as a Localization tester, in fact. I would like to add a small opinion in this regard.

In my experience, I found the two biggest problems on localization on games to be:
1) The lack of context given to the translators when submitting the tests (via a sheet, Oasis or any other means)
2) regional differences often ignored.

On the first point, and taking Spanish as an example: there a lot of cases in which the same word means multiple things depending on the context and also the other way around; when a same word used in two different context is the same in English but different in Spanish.

To put an example on this: In Tecmo's "Fatal Frame" (Project Zero here in Europe), the "close shot" text, which appears on the screen when a ghost is photographed in the last second, was translated in Spanish as "disparo cierre".
"Close" in the context of proximity, in Spanish is "cercano". However, in the context of "to close a door" it is written "cerrar". Given that the translator wrote "cierre" (closure/lock) points at that he/she wanted to make the sentence consistent, but still failed because most likely was lacking context regarding in which situation this text string was used.
This is only one example of many. Probably the biggest exponential of this issue is the Spanish version of 1997's Final Fantasy VII. You can have a look here

Now, the second point is even worse, since in some occasions compromises game experience: Spanish language varies a lot from European Spanish to Argentinian, Bolivian or Peruvian. And when voice acting or "slang" is involved it's even worse.
Halo 3, for example, was released in Spain with a Mexican voice dub that for us felt "foreigner" and made it hard for some people to get into the game. Resident Evil 4 was the same case: It takes place in northern Spain and everybody Speaks in Mexican Spanish.
In both cases, using a lot of terms that Spanish people do not use ("Andale", "Pendejo", the use of "S" instead of "Z" in some words...)

Same case is true for South American players: A lot where upset when they got Dragon Age Origins with it's text translated only into European Spanish. Due to the more "medieval" writing of the game, a lot of words were used that are almost non-existant in the Spanish Speaking Americas. I could give examples, but it would take forever :)

Thanks again for this article.

Edited 1 times. Last edit by Alfonso Sexto Pereyra on 25th May 2021 8:58am

1Sign inorRegisterto rate and reply
John William Park Localization Manager, Amber Studio4 months ago
Hello Alfonso,

You are correct in highlighting these issues, although most providers now work with in-country translators that should be sufficiently familiar with the local colloquialisms.

For your second point, then, it's often a question of cost-effectiveness. Latin America isn't a monolith and nations that state Spanish as their main languages are nevertheless linguistically beautifully diverse. However, since it could be too expensive to localize for each country individually (often, projects will even limit themselves to Castilian Spanish), the recommendation is instead to strip the translation from slangs when possible. It's slightly less flavorful, but it helps players from these regions to feel included.

I'm going back to your first point, now. When it comes to the translation, often done in a CAT (Computer-assisted translation) tool to spare time & costs, linguists are often forced to go in blindly. This is especially problematic when context isn't self-evident (e.g. UI text, being shorter, requires more educated guesses), references are lacking or communicating with the Dev team is impractical (queries are being sent out, but they're time consuming on both end of the spectrum). But this is exactly why Loc QA is an important part of the process. To identify and correct these imperfections before they impact players.

At Amber, we try to go a step further: Loc QA testers helping translators with their questions by providing eyes on the game at all time, and relieving most of this burden from the dev team's shoulders. And hopefully, as an industry, we'll continue improving how we include player from newer markets, from Latin America or elsewhere.

Thank you for reading!
0Sign inorRegisterto rate and reply

Sign in to contribute

Need an account? Register now.