LQA

Today, we’re going to discuss an interesting topic – Linguistic Quality Assurance, or LQA, in game development.

Unfortunately, far too many of the people think localization and translation is the same process. They see localization as a simple three-step process:

  • Throw the text file to a translator, or translators.
  • Wait (usually not long enough for a quality translation).
  • Get the file back and quickly insert it into the game. Done!

In other words, they see localization as a Pandora’s Box in which you plug in game text files and get a perfect, error-free translation.

But that misconception has nothing to do with reality unless you’re extremely lucky or your file contains only a title and a few UI lines. In most cases, this approach results in bad reviews in game stores, pain and suffering, and searching for answers to the most important questions of all time: Who’s to blame?” and “What should I do?”

Therefore, the notion that localization is a mere translation of in-game texts is naïve.

You don’t want the cozy Steam page for your game (a game into which you poured a lot of time, money, blood, sweat and tears) to be riddled with dislikes and negative comments by indignant French users, do you?

So, to ensure good reviews and satisfied French gamers, let’s go over the above three-stage localization algorithm.

In this article, we will focus on “LQA” – a mysterious and even weird abbreviation. 🙂

We’re going to do this in FAQ form, with short questions from an imaginary developer and long answers by actual localizers.

Let’s go.

Q: I don’t understand the difference between translation and localization. What am I doing wrong?

A: If you ask Google what localization is, the answer will most likely be “the process of adapting a product linguistically and culturally for international users.” And that’s true.

If you need to localize a game based on a Russian comedy, correctly translating the texts won’t be enough. Mr. Smith from Colorado won’t understand a single joke about Russian retirement problems, and he will quickly delete your new game from his smartphone.

To increase the odds that Mr. Smith will play your game on his smartphone, you must at least replace Russian specifics with American ones (characters, city names, social problems and so on). Or, better yet, rewrite all the text because these two cultures differ greatly.

Thus, translation is one step of the localization process, not a synonym for localization.

Q: Then what is localization? And what steps should game preparation include (to avoid future shame and suffering)?

A: In general, the localization of an average indie project looks like this:

Localization = Translation + Editing + Non-text adaptation + LQA

Each of these four components has its own specifics and substeps. But this is a translation testing article, not a detailed manual covering everything from glossaries and CAT-software to lip sync and Asian fonts.

However, we still need to say a couple of words about these processes:

  • Translation is the primary conversion of in-game texts from one language to another. It should be done by a translator who’s familiar with the background of the game (playing a beta is preferred, but in some cases, watching gameplay videos is sufficient). The translator must also be a native speaker of the target language (native = from birth). Sometimes, game developers will, for example, engage a line manager who’s lived in California for one, three, five or 10 years (and perhaps passed the TOEFL) to translate in-game texts, assuming they know English as well as a native speaker. But they don’t. This is the Holy War topic of localization – and we might return to it next time.

It should be noted that native speakers differ, too. For example, Gerardo, who has worked in the Acapulco market for half of his life, is unlikely to provide a high-quality translation of your fantasy strategy game into Spanish, complete with all the appropriate allegories and Easter eggs. Finally, the translator should have at least five to six successful projects in his or her portfolio. If these projects correspond to yours in terms of genre, concept and scale – great!

  • After translation, the text is passed to another specialist who checks language, style, spelling, punctuation and other things that fall under the jurisdiction of the grammar police. He or she should also be a native speaker and be more experienced than the translator. Sometimes two editors are involved. This step is VERY important. The full TEP process (Translation + Editing + Proofreading) will be discussed in detail next time.
  • Non-text adaptation involves working with artwork, fonts, textures with inscriptions (which need to be redrawn for each locale), voiceovers, lip syncing and so on. But this article won’t cover that topic.
  • LQA is the reason why we’ve gathered here today. 🙂 The idea is simple: before the game’s release, when numerous Japanese, Germans and Arabs initiate thread crap, a team of experienced Japanese, Germans and Arabs is recruited to thoughtfully play the game several times. This is simple and highly efficient. It’s also classic QA in the localization world and the best way to ensure the Korean version of the game will be acceptable in the eyes of a Korean. By the way, the team of “experienced Japanese” I mentioned above shouldn’t consist of the Japanese who translated and edited the game. Unfortunately, 40-50 percent of the game studios with which I communicate believe LQA is an optional step. Their thinking isn’t always based on saving money. It’s a simple misunderstanding: why should we spend money and time on this? Meanwhile, translation testing of a game is often the only way to find specific, contextual text bugs that couldn’t be detected by the most meticulous editors. Launching a multilanguage story-driven project of 50,000-100,000 words without linguistic testing is the same as releasing it without standard QA. In other words, you will fail.

Q: What mistakes can be found only through LQA? Why can’t careful proofreading solve these problems?

A: As a rule, this is connected to implementing the finished translation.

  • Layout problems such as these:

  • Pieces of code in the text:

  • Hard coding. If you prefer to bury strings of code within your beloved native language when using strings.xml, localized versions of the game won’t be displayed but the source language will be. Thankfully, such bugs can be traced during functional QA without engaging foreign specialists.
  • Contextual linguistic bugs. The best example is the incorrect gender of characters in the dialog. Many developers don’t provide good localization kits complete with screenshots and gender notes in the dialog, yet they like to invent cunning names for their characters. Even experienced translators can make mistakes in such situations. We once worked on a game in which the main hero was named Alex. The studio didn’t provide the game, screenshots or any descriptions of the heroes in advance. Of course, we translated all of Alex’s lines as though Alex was male. Only LQA revealed that Alex was a girl.
  • Once the Japanese version of the game was released without testing, half the Japanese symbols weren’t displayed at all. (This is a true story!)

And, of course, both translators and editors can make punctuation mistakes and classic typpos. (See what we did there?) Moreover, LQA often allows the users to discover functional bugs.

Q: What role does the studio play in this?

A: In addition to providing time and money, the studio should do two things:

  • Provide special builds for LQA.

In general, these are ordinary builds with cheat codes to facilitate ease of gameplay. But since the purpose of linguistic testing is to check the maximum amount of in-game texts (100 percent in a perfect world), find bugs and quickly fix them, you have options.

You can make an APK with just text in textboxes and cutscenes.

If your project is tiny, you can snap screenshots of the ENTIRE game. We’ve done this! 🙂

You can make a video, but this option isn’t convenient and should be considered a last resort.

  • Fix any bugs that are found (which requires developer’s help).

Q: Does such testing guarantee complete elimination of language bugs?

A: Nothing can provide a full guarantee. If you go to Steam and play the latest AAA games by Bethesda, Paradox and 2K, you’ll find linguistic bugs. Note that these guys take a highly professional approach to localization – they have in-house translators, editors and testers and outsourcing teams – yet localization mistakes happen.

Though LQA doesn’t guarantee the complete absence of localization bugs, testing helps to reduce them to a minimum. If the game doesn’t contain a huge amount of text (a few hundred or a few thousand words), LQA will most likely remove all the bugs.

What can you do with single localization bugs? The same thing you do with regular bugs like memory leaks and CTD – fix them.

Q: How much does LQA cost?

A: It depends on various factors.

In general, LQA is charged by the hour. Professional studios and translation agencies charge from $15-$40 per hour. This money buys the services of a native speaker and linguist with many years of experience in this area. Just think: There’s a chance your game will be tested by the same person who tested (or is testing) games for EA or Blizzard.

If you prefer to hire freelancers, you might find friendlier rates. Of course, you risk hiring another Gerardo of Acapulco.

Q: What’s the probability of localization troubles if I still don’t want to perform LQA?

A: High.

You might get lucky: The texts were easy to deal with, both the translator and editor did a great job, the technical implementation was perfect, the stars aligned and the players were too lazy to write negative comments…

Or, the translator turned out to be a bad guy who took your money and sent you a machine translation. This is particularly true for those who prefer to work with freelancers while foregoing editing. And then you find out through comments on Steam that your Korean translator failed you.

Let’s say the translation was perfect but your team couldn’t fully integrate the custom Thai font and half the letters in the game are absent. Since there was no testing, you’ll once again find out from the players on the day of the game’s release. Of course, the Thai language looks like ตัวอักษรไทยที่กำหนดเอง, and the developer simply can’t understand what’s wrong with these squiggles.

To recap, we can say that releasing localized games without linguistic testing is like playing Russian roulette. Remember that the cost of failure can be much higher than the cost of LQA.

Q: I still don’t want to perform LQA but really want to reduce the risk of issues occurring. What can I do?

A: Always proofread translated texts. Never assign this task to those who translated the texts.

Compare several passages from the finished translation to the Google Translate version. A match is a bad sign.

Have your own forces or QA department play the localized game, checking the layout and looking for source code as they proceed.

Prepare detailed lockits with descriptions, comments and screenshots.

And THINK AGAIN about linguistic testing. It’s important!

If this article didn’t tell you anything you didn’t already know, good! 🙂 You’re already an expert. But if you gained some insight into the importance of quality localization, we hope you’ll remember it when it comes to your game.