LQA stands for localization/linguistic quality assurance.

By Jennifer O’Donnell, with assistance and checks from Yesica Terceros, Marina Ilari, Alexis Biro, Alexander Skazchenko, Maurizio Massari.

 

LQA stands for localization/linguistic quality assurance. Simply put, it’s when native speakers of a language check the localized text in its in-game context. Not so simply put…well, you’ll have to read on.

 

The LQA Process

LQA happens after translation, editing, and proofreading (TEP) a game’s text into another language. It’s a process that’s entirely separate from the TEP stage of localization and requires its own set of skills and workflow.

LQA is essentially QA for localization, but it isn’t just having a native speaker play through a game and then calling it done.

Besides checking the text displays correctly, LQA testers also check;

• for grammatical errors,
• that sentences make sense in context,
• that characterization and terminology are consistent,
• the flow of the text is smooth and the logic is clear for players,
• that fonts and text in graphics and UI are appropriate/make sense,
• there are no images, sounds, gestures, or other issues which could be problematic in the target culture,
• that system specific terminology (TRC) is correct in their target language.

 

How well a tester can handle issues depends on how much time they have and the quality of the text they get. If faced with a particularly bad translation full of direct translations or awkward syntax, and if not given much time, then they can only fix so much.

 

The LQA Workflow

Developers need to be aware of the LQA workflow so they can provide the staff and support for LQA to do their job properly, and so they get the best quality localization.

If you’re making text changes to the source while LQA is happening, then those changes need to be reflected in other languages and then the LQA testers need to re-check them in game. This can cause mayhem with version control and cause your schedule to quickly balloon. So be careful!

 

One way to avoid this is to QA your source language(s) before the other languages start their LQA. Then freeze/lock the source text while LQA do their thing. If you do need to make changes during LQA try and keep to them only the first or second round of LQA, and make sure you mark all changed strings as “to be checked” so nothing slips through the cracks—there’s nothing worse than a stupid spelling or UI mistake coming out in the final game because of an unchecked last-minute edit.

 

Effective LQA (just like effective QA) will take a few rounds to make sure all the text was seen, all the audio was heard, and that any fixes were implemented correctly.

ROMs (the digital copy of a game) may fail, or other bugs might cause delays, so make sure you add an extra “safety” round and additional buffer time. (See “How Long Will LQA Take?” below for more on this.)

 

Some Things to Be Aware of with LQA

LQA is best done in collaboration

When the developers and marketing teams are working in collaboration with LQA, that’s when you get the best results. Putting aside the man-power, time, and budget to address all issues LQA flags will only result in a better quality game and avoid problems on an international level.

 

There will always be linguistic “bugs”

Unless you provide your translators with a working ROM (which is very rare), the vast majority of the game text will have been translated blind. You can add comments and reference materials to help curb this (see “High Quality Localization? Help Loc Help You!”), but even then, no text will work perfectly in the game first try. (Which is why LQA is SO important!)

After all, how many times did you edit the source text after seeing it in-game?

As such, be ready for LQA to flag issues and provide updated to the text. This doesn’t mean the translation is “bad”, it often just means that an edit will work better in-context now someone has seen the text in-game.

 

Be ready for LQA to flag non-text related issues

As mentioned above, LQA doesn’t just test for text issues, but font, graphic, UI, sounds, gestures, character design, etc.

Font is a big one that many developers aren’t aware of. Not all fonts support all characters in other languages. Such as Simplified Chinese fonts which are used for Traditional Chinese text—this makes the game look sloppy to Chinese players and they are often missing common letters in Traditional Chinese. Or many European fonts don’t support some Polish punctuation or diacritics.

Another one is cultural problems. LQA testers might flag issues with the use of certain images or symbols in background graphics, character gestures, or the word for a key term which might be considered offensive or problematic in some countries.

 

LQA testers’ experience can vary widely

LQA testers normally need to a) be native-level speakers of the languages your game is in and b) be in the country of the testing company. This means that depending on the company, some native speakers might be easier to find than others.

For example, let’s say you’re testing your game with a European LQA company. It might be a lot easier for them to get experienced testers in European French, German, European Spanish and Italian, but not so easy for Mexican Spanish, Korean, Chinese, Japanese, etc.

When a testing company is asked to LQA a game they try to source people from their current staff, but sometimes they need to find someone urgently, whether they have experience playing games or not.

This means the experience of individual testers can vary widely. You might be lucky and have an agency full of long-term testers who are experienced gamers. Or you might be unlucky and get someone who’s never worked in game dev before.

There’s no way to tell beforehand, though, which is another reason why it’s best to make sure the localized text is in the best condition possible before you start testing and you have plenty of time to LQA the game.

 

LQA testers are NOT translators, nor are they editors

It’s rare that someone in LQA will have translation, writing, or editing experience. Yet developers often ask them to translate or edit new text.

Testers might have linguistic backgrounds and be able to translate new text for you, but it’s not normally in their scope to do so. It’s always better in the long run to ask the original translator to translate anything new, and then the tester can check it in-game.

 

Translators are NOT LQA testers

Some companies think it would be best to have the translators LQA their own work. This is not always the best course of action.

Just like any position in game dev, localization testing has its own set of skills. Translators might be great at translating, but that doesn’t mean they know how to test. The vast majority of freelance translators don’t have any testing experience (as I mentioned they often translate without even seeing the game!), and so might be unsure how to handle localization testing without guidance.

There are, however, some translators who have experience testing and some small agencies who have their translators test the game too. But even if your translator can also test your game, it’s always a good idea to have a second person LQA the game because it’s often hard to spot your own mistakes.

As mentioned above, an ideal situation is when you have the LQA team and translation/editing team all working together and communicating changes with one-another.

 

There are different approaches to LQA

I mentioned that LQA covers grammatical errors, characterization and terminology consistency, etc., but not all testing companies will cover all of these.

There are different kinds of testing practices based on the company, including LQA companies who;

• just check text implementation (no grammar/logic/consistency check),
• check implementation and basic grammar errors,
• check implementation, text in context, word flow and game logic, culture checks.

(All game LQA companies should check TRC.)

Ask the LQA companies you’re looking into what their base testing practice is like and if they are OK to test for other things.

Make it incredibly clear in writing what you want LQA to look for.

 

What LQA Is and Is Not

LQA is not QA (but it does run tangent)

QA is mostly about finding bugs and errors in the code to improve the overall quality of the game. LQA is about finding bugs and errors in the language—not just spelling mistakes but context issues (e.g. a character is written as male but they’re actually female in-game), and UI/text problems.

LQA shouldn’t be reporting non-text related bugs (unless they’re bugs that impact the language, such as problems with the audio or UI.)

To avoid this, it’s best to make sure you have at least one round of LQA towards the end of QA when the game is mostly stable. (See “When Should We Do LQA?” below.)

 

LQA is polishing the game for a foreign audience

Just like QA serves to help you polish the game and work out the kinks, LQA is there for your target audience. The best-selling global games have polished localizations, and that’s only achievable through LQA.

 

LQA is not editing

LQA is polishing but it shouldn’t be the first time someone edits the text. In a perfect world the text should be translated, edited, and proofread (by different people) before the text is implemented for LQA. Testers need to focus on the text in context, catching other issues—not spending their whole testing time editing the text.

 

LQA is its own process in game development

You can’t send your ROM to the translators and ask them “to do a quick check of the game”. As mentioned above, the vast majority of freelance translators aren’t testers. And as shown below in “How Can Devs Help?”, LQA is a multi-step process that requires professional care to get right. Developers shouldn’t treat LQA as a part of translation services, but a separate service that requires its own set of skills.

 

How Long Will LQA Take?

How long LQA takes depends on how long your game is and how far along in development it is.

You want to make sure everything that LQA needs to check is in the game—text, UI elements, graphics, voice, etc., but also that all the elements of the game where they can find the text is available to them—side quests/extra levels/mini-games, items/weapons, DLC, pop-up messages and notifications, etc. If a feature isn’t implemented, how is LQA supposed to know if the text is correct in context?

Once you have everything implemented, how long will it take to finish your game? Double that then add buffer.

For example, if it takes 10 hours to play your game prepare 20 hours for one round of testing, plus another 4-5 hours buffer. This gives the testers plenty of time to check all the text, report bugs/issues, regress any changes, etc.

Plan for time at the start for familiarization and multiple rounds of LQA to make sure everything is checked in-game, all bugs are reported and fixed, and all changes/fixes are regressed.

(See “How Long Will It Take to Localize My Game?” for more advice on localization scheduling.)

 

When Should We Do LQA?

Normally LQA is conducted towards the tail end of the project around the same time as QA. You need to carefully consider exactly when LQA should be handled on your project.

I would strongly advise against conducting LQA after or before QA. If you try to do LQA before, there might be game-breaking bugs that impact testing. If you do it after, you might not have the budget or time to fix issues related to other languages. Some developers might be reluctant to fix LQA issues after QA has finished in case they break something else in the game. But not fixing LQA issues (such as UI, region specific problems, or cultural problems) can reduce the quality of your game in other countries.

I am personally a fan on having LQA run from early QA to the end of QA so any changes made during QA can be checked by LQA. There might be times when someone moves some text or a voiced line during QA which—although works in the source language—breaks the meaning or context in another language. LQA conducted throughout QA can pick up on these issues. The only problem with this is on-going long-term LQA can cost a lot, so plan your LQA wisely.

 

How Devs Can Help

There are a few things developers can do to help LQA run as smoothly as possible.

1. Have a kick-off meeting – Make sure you have at least one (maybe two) kick-off meetings with your LQA company. Use it as a chance to go over the LQA process and workflow, the schedule, what you expect from them, and any questions you might have for each other. This helps get everyone on the same page and better prepares the LQA project managers.

2. Prepare the ROM before LQA starts – If you start burning the ROM on the first day of LQA then you’re going to waste a lot of time and money as your testers sit around twiddling their thumbs waiting to get started. Burn the ROM a few days in advance so your LQA team/agency can check the ROM works beforehand and hit the ground running when testing begins.

3. Have regular meetings – Regular meetings allow you to keep abreast of potential delays, and solve management issues as they arise.

4. Provide a debug guide/cheat codes – LQA is just like QA in that they need a guide for the debug systems to do their jobs. If you can include useful debugs for linguistic testing, all the better! This doesn’t just mean displaying text, but jumping to sections of the game, access to items, triggering pop-up messages and important notifications, etc.

5. Provide a game breakdown guide – Testers have never seen your game before, so it can be hard to know where to look for sections of the game. Story/chapters/section summaries are useful, and general guides on what strings can be found where, etc., are crucial to performing effective LQA.

6. Provide a list of all strings – LQA need to know what they’re testing, so don’t forget to provide a list of all the strings you want them to check—including their unique string IDs, the source text, translated text, and string’s location (see below). This allows them to create checklists which helps keep track of progress and bugs.

7. Provide string path information – Similar to the translator comments (see Help Loc Help You), having updated information on how to find/trigger each string makes LQA run a lot smoother—especially for system messages, popups, notifications, and error messages.

8. Allow testers to familiarize first – Give the testers time at the start of testing to play the game naturally. This can help them familiarize themselves with the game and improve testing efficiency.

9. Provide a way for project managers to send questions – Sometimes even when you provide information on string locations, a tester might not be able to find it. Maybe it’s a bug or maybe someone else removed some text but didn’t tell anyone. Allow space for a Q&A to improve LQA efficiency.

10. Plan how to track and implement text changes – You need to know exactly how all linguistic changes will be tracked and implemented into the game—and prepare for it in advance!
    LQA agencies will often create their own checklist to track what strings were checked in what languages. But you want a way for the testers to update these text changes (or suggest changes to the translators/editors).
    You also want a system in place that takes these changes and efficiently adds them to the game. This will vary depending on how you implement text into your game. (Please don’t have an intern manually copy and paste all changes for all languages directly into the game—that way only leads to madness!)

11. Provide LQA with a place to report and track bugs – This is probably par for the course, but testers need a space they can post bugs. You can use the same program you use for the main QA, such as Jira, Trello, Monday, Hansoft, etc.
    You also need to set up a workflow for LQA bugs. How will these bugs be handled? Who will pass the issues onto the appropriate person? Etc.
    Make sure there’s a way for testers to know if a bug will be fixed or waived, when a bug is fixed, how it will be fixed, in which build the fix can be regressed. Let the testers regress the fix themselves and include a workflow for them to return it if there are any further issues.

12. Run suggested linguistic changes by the translators/editors – Depending on your project’s structure, it might be beneficial to run any changes by the translators and editors, rather than making the changes blind. As mentioned earlier, testers aren’t translators. There might be a specific reason why a translator wrote a line a certain way, which a tester might unknowingly overlook. Decide in advance who will have the final say over the translated text in each language, and make sure all changes are run by them first.

13. Prepare your staff for LQA – Inform your internal staff when LQA is happening and make sure you have the people power to fix issues brought up by LQA. Especially problems with UI and graphics!

14. Communicate clearly – Make sure you specify what you want from your LQA company in advance (do this while looking for a company to ensure they fit your needs.)

• Native speakers of a language—including the region (e.g. Mexican Spanish testers shouldn’t test European Spanish text and vice versa. Same with US/UK English and EU/Canadian French, Egypt/Saudi Arabian Arabic etc.)
• Scope of testing – logic, grammar, graphics, culture, etc.

15. Tell LQA if you change something – Not just the text itself, but text location, game features, etc. If you don’t tell them and the implementation is different from what they’re expecting they’ll report it as a bug. Or worse, it might be missed and the change breaks that part of the game in another language! Even a simple change can have a big impact on other languages.

 

Important Information to Keep in Mind

Testers won’t be as familiar with your game as you are. They don’t know the back-end shortcuts or the debug inside and out. Testers will have a checklist of every, single string in the game that they need to check. If you don’t provide them with how to find or trigger those strings, then LQA can take a lot longer as they waste time searching for them.

Testers should ideally familiarize themselves with the game and debug systems before they start. If they start testing blind, they might erroneously flag strings as OK because they’re not yet familiar with the game’s story or setting.

Any issues testers report need to be fixed during the LQA period. If something isn’t fixed by the time LQA finishes, then you either need to pay for more LQA, or have someone on the dev side check it—which risks further bugs slipping through!

Similarly, just like UI bugs are fixed by the UI team, any linguistic bugs should be fixed by the translation team. Any linguistic edits should be run by the lead translator or editor of a language. This is particularly important if you have a story-driven game with a lot of text. The person who has the most knowledge of the overall game, story, and characters should have final say over the translation.

 

Localization testers, just like all members of a development team, want to create the best game possible. They also fulfil a specific and important task—making your game playable by an international audience. And equipping them with the tools they need benefits everyone.

 

Best Practices for LQA Summary (for Developers and Localization Testing Agencies)

• Hold kick-off and regular meetings between the dev team’s localization manager and the LQA project managers.
• Provide ROMs, string lists, and supplementary documents well before LQA starts.
• Provide testers with a useful debug command list.
• Provide testers with details on how to trigger strings (especially system messages and notifications).
• Give testers time to familiarize with the game (ideally play it through naturally).
• Credit testers (not just the testing agency or PMs).
• Translators translate, editors edit, testers test.
• Translators/editors double check changes flagged by testers.

 

 

Cover image by pch.vector