Seven ways to master localisation QA in video games

It's an obvious truth that the vast majority of video games no longer cater to one specific country or language. They are universally beloved experiences with global launches.

Therefore it's crucial that their inevitable translation to multiple languages is tested rigorously, to ensure those experiences ring as true for English speakers as they do for those whose primary language is French or Russian (for example).

This is where the role of Localisation Quality Assurance, or LQA, comes in: where each language variant of a title is verified in terms of its assets (dialogue, text, UI, supporting materials) and that bugs arising out of translation are discovered, documented and resolved.

Having successful LQA means releasing a game that can be enjoyed by all players around the world, no matter what language they speak, and where their immersion is not hampered by a weak adaptation to the local market and gaming culture.

Here are seven best-practice methods for achieving successful LQA.

1. Integrate your LQA at the onset of development

First and foremost, engaging in the LQA process alongside your initial game design will vastly reduce the headache when it comes to going gold. It means you can reduce testing in and of itself, and free up resource for other activities and efficiencies.

For example, if UI and LQA are in sync when it comes to designing menus, HUD elements such as status bars and subtitles, they will not need to be redesigned to accommodate for languages that simply take up more space on the screen.

This may seem trivial but it can greatly affect the information a player receives in addition to the overall look and feel of a game. Nobody wants to have menus that can either take 30 seconds or three minutes to read dependent on the language and its UI integration.

The Three Ts ; If you fail to prepare to test, your game is prepared to fail

Pre-tests

A lot of developers do not consider enacting pre-testing or to have a testing strategy in place before they undertake QA. For myself and Keywords Studios, pre-testing is an essential component, not just for LQA but indeed all QA: it forms the overarching backbone of all QA once its in motion and thus you should seek to pre-test as much as feasibly possible.

A pre-testing phase would generally include the following:

- Planning a relevant progression path for the test team
- Getting familiar with debug tools available to QA and incorporating them in the overall test strategy
- Verifying a pseudo-localised build for localisation and QA readiness
- Setting up and documenting core processes around bug reporting and bug fixing

Increased pre-test time will effectively reduce the amount of time that the team will require to reach peak testing efficiency during the actual test pass.

Regression / Confirmation Testing

Games are constantly being developed and changed throughout their development life-cycle including the later stages when QA kicks in.

On top of this, when your LQA does raise bugs to be fixed, these changes can create additional issues as a consequence of the new code.

It is therefore crucial to perform regression and bug confirmation testing to ensure that test results remain relevant in new build versions and bugs are correctly addressed in a continuous development scenario.

Test-cases

Test-cases are self-contained areas of a game that go through QA. For example: Entire level slices that will encompass all the assets within that section (audio, textures etc.). These can be created by your QA outsourcer or by the main developer.

They are an integral part of the toolkit for any tester, allowing sign-off on entire areas with a pass/fail criteria.

For LQA, this benefit enables you to remove whole sections out of subsequent checks, rather than testing the game as a whole, revising errors along the way, and having to do an end-to-end second LQA run-through to make sure the changes you made did not affect anything else.

In short, test-cases enable effective progress and coverage tracking and also reduce the requirement for regression testing. They should be planned and created alongside your pre-tests to ensure a coherent LQA strategy.

3. Utilise Debug Tools

Using debug tools, i.e. 'cheats', are a LQA tester's hidden arsenal. A well-equipped repertoire of tools will allow you to greatly reduce playtime during testing, be it granting yourself God Mode or being able to move through walls via 'no-clipping', allowing you to test more frequently and with better results.

Collaborate with your QA partners so that you can share your toolset and further integrate your workflows together.

"If your LQA requires multiple languages then assigning it to one supplier will make your life easier."

4. Use a Glossary

Within game design, it is common for a glossary of important words to be made up by the localisation team; things like weapon names, lore and fictional languages. For LQA (who are the first to see the game in action after localisation) a glossary is essential. It ensures a definitive knowledge base and consistency in nomenclature, preventing translation errors and inconsistencies from breaking immersion and confusing players.

5. Multi-language teams

If your LQA requires multiple languages then assigning it to one supplier will make your life easier. Having a variety of native speakers in one team allows you to reduce bug counts and workload. For example, if an error is in English (i.e. the source language) it can be reported as one issue by your native speakers rather than as five from five different outsourcers/languages.

Collaboration within your multi-language team allows for consistent quality as the nature of a diverse team creates opportunities to spot errors that one team may not see.

6. Collaboration: game development is a co-op experience

As stated above, integration and collaboration mean faster and better results. Integrating your LQA with your localisation team is especially important within Games-as-a-Service for example, because it requires a continually evolving knowledge base. With continuous content being added through successive updates you need to know what you can pre-test off the back of your previous work.

Having this collaborative knowledge helps you test the next wave of content much faster and allows for quick turnarounds on smaller updates.

Within your multi-language teams also, collaboration fuels quality as the nature of a diverse team will create more opportunities to spot compound errors that a single-language team may not see.

7. Empower your testers

This harks back to collaboration and having multiple native speakers in your LQA team. Basic linguistic bugs (for example spelling, grammar or punctuation issues) will not need to be raised as a formal ticket if you are a native speaker and can simply fix the issue first hand.

Let your native speakers work to their own initiative and empower them with the ability to modify text themselves, which reduces the amount of low severity issues in the bug database and reduces the workload for the translation team.

Thomas Barth is Localisation QA Director at Keywords Studios. With over a decade of experience in QA and LQA he has worked across numerous platforms and with a myriad of clients from all sectors of the industry (developers, publishers, hardware manufacturers) to deliver equally immersive experiences for global audiences.

For more information on Keywords Studios. Click here.