Three Key Ws of LQA: WHAT, WHEN, and WHY

Picture this: you are working on your latest project, bound to be localized to spread in popularity across the globe. Maybe you are a Producer, or a Developer, or a Project Manager facing the challenge of game localization for the first time. No matter who you are in this scenario, there are a few questions haunting you: what is Linguistic Quality Assurance (LQA), when should LQA testing begin, and why is it a key element of the localization process?

While each project has its peculiarities, the process of video game localization can be simplified in three phases:

1. Localization of text strings: whether by external vendors or an in-house translation team, every player-facing string of your game must be translated – even recorded, if you intend to have localized voice-overs (VOs).

2. Implementation: translated text and VOs are implemented in your game builds.

3. LQA testing: a team of linguistic specialists reviews the localized version of the game and reports any issues affecting its quality and viability.

Depending on the size of your game, the number of supported languages, and the presence of recorded VOs, these three steps can take months or years, they can overlap, and repeat over several cycles.

The most common approach to Linguistic Quality Assurance is to schedule an LQA testing round when phase 1 is almost done and phase 2 has already started.

While in many cases that is a valid approach, there are benefits in worrying about linguistic quality in earlier phases of development as well. For instance, by asking your LQA team to run an Internationalization pass.

I18n testing

Internationalization, commonly known as i18n, is a process designed to adapt a product so that it can support being localized in different languages. (For more about localization acronyms, here is an article by The Localization Institute)

An LQA team running an i18n testing pass can spot future bugs in your game well before your translations are completed, potentially saving costs down the line. Depending on which languages your product is aiming to support, LQA testers can easily highlight a series of core issues, such as:

• Incorrect orientation and text-wrapping;
• Fonts damaging readability;
• Code writing style incompatible with target languages;
• Small UI text boxes.

These issues will impact core aspects of your game, which is why it is preferable to identify and address them soon. Fortunately, you only need a minimal amount of UI and translated, implemented text strings in game to run a useful i18n testing pass.

Is i18n testing strictly necessary?

The short answer is no, but it is strongly recommended. Of course, different projects require different approaches.

For a AAA game aiming to support several languages, an i18n testing round with LQA specialists is a must-have. It is a guaranteed long-term investment resulting in less major bugs and more efficient LQA testing rounds down the line.

However, when localizing a game with minimal UI, text and dialogues, intended to support only a few languages with a shared alphabet, skipping the i18n testing round is not as risky a choice.

If you are considering localizing an already released game, your i18n process will of course look different – but it will be nonetheless valuable and help your team assess which challenges lie ahead, possibly influencing whether to support a specific language or not.

In truth, there are too many variables to the localization process and games’ formats for a one-size-fits-all solution in LQA testing.

If forced to define an LQA timeline that would fit any game development process, this would be the most honest answer: a while before text lock and as long before code lock as possible.

Let’s review a few key factors that may influence LQA testing times.

Languages and content

Let’s start with the obvious: the bigger your game, the longer it will take to localize and complete LQA coverage. LQA testing is only phase three of the localization process we defined above: therefore, it is strictly dependent on how fast (and well) the entire content can be translated and implemented in game.

If the localization process starts at the same time for each target language, whether you are localizing a game into 4 or 8 languages will not make a huge difference. However, the type of localization and type of language can.

For instance, localizing from English to other European languages using a Latin alphabet is likely to present less LQA challenges than translating from English to Arabic or Chinese.

Similarly, if your game presents VOs to localize, they will require additional time and work than a game relying on translated subtitles for its dialogues. For the former, it is best to calculate additional time for audio validation and possible re-recording. 

Translation and implementation

Earlier we mentioned how i18n testing does not require a game to be in a very advanced phase of development nor fully translated. Unfortunately, this does not fully apply to regular LQA testing.

While an LQA team can start working well before the game is fully developed, it is best to launch testing when the translation phase is at least in progress and some of the UI is localized in game. This allows testers to have some valid content to analyze– and point out bugs if necessary. Otherwise, the risk is to lose valuable time testing a game without sufficient localized content to verify. 

Even if pseudo-localization is a key tool to support LQA while strings are still being translated or are not yet localized and implemented, linguistic testing is most efficient when done on sections of finalized, translated and implemented content.

But what is pseudolocalization?

If you are a localization veteran, you can skip this paragraph. For those who are new here, let me introduce you to one of LQA best friends: pseudolocalization.

The core idea behind pseudolocalization is to replace your source text with a made-up language. For instance, let’s say your source language is English, and your target is French. Your translations are not yet ready, but you have a pseudolocalized build for your LQA team. When launching the game in French, the “START” button string will be displayed as “àçôSTART”. 

While the made-up language might look random, it actually isn’t.

• The special characters used will highlight if your current font is unable to support special characters often specific to a target language.
• The number of random characters added emulates the average length of translation for each language, making potential cut-offs and overlaps visible before the localized content is implemented in game.
• Finally, a pseudolocalized game will show which strings are still hardcoded and, therefore, not included in the text files for translations.

Below an example of how pseudolocalization might have look on Diablo Immortal. The following string can be found in the character creation menu, under the hair tab. Localized into French, the English source text tends to be circa 20% longer (sometimes less, sometimes more). Pseudolocalization would have highlighted that the French version was most likely not going to fit within the allocated text box, consequently overlapping with some of the graphic elements.

And indeed, in the localized version of the game, we can observe the font is shrunk and split into two lines.

Pseudolocalization is particularly useful during i18n but also supports LQA during its regular testing rounds - especially at the start of testing and in case of implementation delays.

Game stability

LQA testing usually starts later compared to other QA departments. That is because a few additional prerequisites must be fulfilled for LQA testing to be efficient - ideally.

For starters, builds should (mostly) be testable. While a crashing game still offers testing ground for other QA teams, LQA work would be heavily limited on a product that is unstable or contains mostly areas not ready for testing. As noted above, a game presenting a decent amount of localized and testable content is a better place to start LQA (e.g. finalized main UI and settings or first 30 minutes of playthrough with minimal crashing).

If the UI and source text are still susceptible to structural changes, there is a risk of undoing LQA progress and causing testing to be less effective. For instance, the same, previously tested, localized strings implemented in a different UI could introduce new issues. Changes in the source will require translations to be updated and re-implemented, causing LQA testers to review previously verified content.

In a perfect scenario, LQA testing ends when the whole localized game has been tested, reviewed and is ready for release with no remaining issues. That is not always the case: even the best developed projects are susceptible to still contain a few linguistic issues when released to the public. LQA realistic objective is to get as many issues fixed as possible, with the goal of guaranteeing a pleasant user experience in each target language. Sometimes, that means letting a few minor issues slide to focus time and resources on more bothersome blockers.

It is clear by now that game size and target languages can influence your testing time: that is true for every type of QA testing, not just linguistic.

Depending on project budgets and needs, there are two main approaches to LQA.

Testing rounds

A product could rely on one or more LQA testing rounds to review its linguistic quality. In practice, an LQA team will be scheduled to work on a specific project over a limited, short-term amount of time, which can span from a few days to a few weeks. During this time, they will aim to review all the content available and report issues to fix. Commonly, the LQA team will be scheduled again later on, once the flagged issues have been fixed and/or new localized content has been added.

These rounds will continue for as long as required, with the LQA team working only when new content or fixes are available for testing.

This approach works well for:

• small to mid-size projects
• DLC patches
• studios hiring external LQA providers

Continuous testing

Another way of integrating LQA testing into game development is by scheduling a full-time team of testers as soon as a testable build is available and until the project is ready for shipping. Usually, this type of continuous LQA testing lasts for a few months and up to a couple years. Its main advantage is in the expertise the LQA team can provide by working regularly and exclusively on a specific game. Additionally, having one (or more) teams constantly scheduled allows them to pivot their testing focus and be more efficient in case of last-minute changes or emergency fixes. This approach works well for:

• mid-size to AAA (or Triple-I) games
• story-driven games
• products with regular, consecutive DLCs or content updates

LQA testing aims to correct and polish localized games, guaranteeing high standards of linguistic accuracy and user experience. Its timeline depends on the complexity of the game and the languages supported: LQA testing can last years, months, or weeks, it can be defined by shorter rounds of testing or continuous LQA coverage.

LQA testing is a key element of the localization process because it combines linguistic knowledge with understanding gamers’ experience and technical requirements. Running LQA testing at the start of localization, during its implementation, and towards the submission of a game will prevent and remove blockers in the way of a successful release.