LQA in-house or outsourced: how to set up your localization QA

The translations are delivered. Now somebody has to play the game in each language and find the places where the text is wrong, cut off, missing, or attached to the wrong thing. Who that somebody is — your own staff or an external team — is a separate decision from who did the translating, and in most studios it gets made by default rather than on purpose.

Localization QA is unusual as a QA discipline in three ways that together make the staffing question hard. The skill it needs is language-specific and cannot be substituted: no amount of testing experience lets someone judge Korean text if they do not read Korean. The workload is spiky, concentrated into the weeks before a milestone. And it can only happen on a real build, late, in the most contested window of the whole project.

This article compares the setups and offers a frame for deciding. It assumes you already know roughly what LQA covers and why it is not the same as reading the spreadsheet.

What the work actually requires

Before comparing models, it is worth being precise about what you are staffing for, because the requirements are not obvious from the outside and each one narrows the pool of people who can do it.

• A person who reads the target language at native level and can judge register and tone, not only accuracy
• Enough game literacy to reach the content: someone who cannot get past a boss fight cannot check any of the text behind it
• Bug reporting discipline — a reproducible report with a screenshot and the string key is actionable, while the Spanish looks strange is not
• Access to a build on the target platform, at a stage where the text is final enough that reporting on it is not wasted effort
• Test accounts, save files positioned near each area, and enough debug tooling to jump to content instead of replaying twelve hours to see one line
• A slot in the schedule after content lock and before submission, which is always the most contested window in the project

Two halves of the job that should be staffed differently

A large share of what gets reported in a first LQA pass is not linguistic at all. Missing or untranslated entries, broken placeholders, text overflowing its box, mojibake, unbalanced markup tags, and lines over a field's character limit are mechanical problems: they are true or false regardless of whether the wording is any good, and they can be detected without reading the language.

That distinction matters for staffing because those two halves have opposite cost curves. Mechanical problems can be found before the build exists, on the files themselves, at a cost that barely grows with volume. Linguistic judgement requires a qualified human playing the game, and its cost grows with content, platforms, and languages all at once.

Whichever staffing model you choose, run the mechanical layer first. Sending a native speaker into a build to discover that forty strings were never translated spends the scarcest resource you have on the cheapest possible finding, and it also buries the real linguistic feedback under noise. The in-house or outsource question is mostly a question about the second half.

The workload is spiky, and everyone's peaks coincide

LQA demand is not steady. For a project with two releases a year it is close to zero for months, then several full-time weeks per language in the run-up to each one. Every staffing model is really a way of dealing with that shape.

In-house means you carry the trough. A full-time tester for a language you ship in twice a year is capacity you pay for continuously and use in bursts, unless you can give them meaningful work in between — which usually means the role is not purely LQA, and that is a legitimate design rather than a compromise.

Outsourcing means you compete in the peak. Vendors staff against their own aggregate demand, and release seasons cluster hard around a few points in the year. Booking capacity late in a busy quarter can mean waiting, paying a rush premium, or accepting whichever linguists happen to be free rather than the ones who know your game.

The consequence is the same either way: the scarce resource is scheduled time, and it has to be booked before it is needed. Deciding to start LQA when the build is ready means starting later than that, because the people were not reserved.

When in-house works, and when a vendor works

In-house LQA earns its fixed cost when the work is continuous and concentrated in a small number of languages. A live title with a regular update cadence produces steady work; a home market plus one core language keeps the headcount defensible. The real payoff is not the hourly cost but the loop: an internal tester can resolve an ambiguity with the writer in minutes rather than in a next-day email thread, and they accumulate the institutional memory of past decisions, past fixes, and terminology arguments that a rotating external team never builds. Unreleased content also never leaves the building, which simplifies everything about a high-secrecy project.

A vendor earns its place when the shape is the opposite: many languages at once, especially at a simultaneous launch, or infrequent releases where the trough is longer than the peak. Vendors also carry things you would otherwise buy and maintain — hardware, dev kits, OS versions, device labs — and they cover languages you cannot realistically hire for locally. Teams that have run submissions for other titles also arrive knowing the checks platforms tend to fail people on, which is experience you cannot get by reading documentation.

Neither answer is about quality in the abstract. A committed external linguist who has covered your game across four releases will beat an internal hire who was moved onto LQA last month, and the reverse is equally true. What the model actually determines is continuity, response time, and how much of your schedule risk sits inside your own control.

The hybrid most teams converge on

In practice, teams that ship in many languages tend to land on the same arrangement: internal ownership with external capacity. The studio owns the process; the vendor supplies native passes when the peaks arrive.

Inside the studio: one named owner of the process rather than a responsibility diffused across the team, bug triage, the fix verification loop, regression checks between builds, and the mechanical checks that run automatically on every build. Outside: scoped, briefed native passes per language during the crunch weeks.

What makes a hybrid work is unglamorous. One bug tracker rather than a spreadsheet per vendor. One shared severity definition, so a critical from an external tester means the same thing as a critical from your own. One build distribution process. A written brief per pass stating what to cover, what is already known, and what is out of scope. And a named internal person reachable during the vendor's working hours, because a blocked tester with an unanswered question burns a day of paid capacity.

What breaks it is equally predictable: shipping an unbriefed build and expecting a useful report, treating vendor reports as final without triage, and skipping fix verification. That last one is the most common and the most expensive, because a bug that was fixed but never re-checked in a later build is not fixed — it is a hope, and it is exactly the kind of thing that reaches players in a language nobody at the studio reads.

Deciding per language, and the costs nobody plans for

Decide per language rather than for the project as a whole. Running one language internally and eight through a vendor is not indecision; it is the shape of the workload showing through the org chart.

Whichever way you go, a handful of costs are reliably missing from the first version of the plan, and they are the ones that make an LQA cycle overrun. Ramp-up recurs: an external team relearns your game every engagement unless you request the same people by name and they are available, so continuity is worth writing into the contract rather than hoping for. Build distribution, NDA paperwork, and account provisioning take real days at the start of each cycle. Triage on your side is a job in itself — somebody reads every incoming report, deduplicates it, and decides what is a bug versus a preference, and that person is usually the one with the least free time in the schedule.

Then there is the second pass. Fix verification is not a footnote on the first one; it is another build, another round of scheduling, and for a vendor engagement often another minimum charge. A team that budgets one LQA pass has budgeted half of what it will actually run.

Finally, time zones cut both ways. A twelve-hour offset can hand you overnight turnaround, where you ship a build at the end of your day and read the report at the start of the next. It can equally mean one unanswered question costs a full day of paid testing. Which of those you get is decided by whether someone on your side is reachable, not by geography.

With those costs on the table, the decision itself comes down to a short list of questions, answered separately for each language you ship.

Answer these for each language, not once for the project:

1. Frequency  : how many LQA passes per year for this language?
2. Volume     : hours per pass (content size x platforms x settings)
3. Criticality: is this a launch market or an added language?
4. Coverage   : can we hire this language at all, locally?
5. Platforms  : do we own the hardware and accounts needed to test on?
6. Turnaround : how fast must a fix be re-verified after we ship a build?
7. Secrecy    : can pre-release content leave the building under NDA?

  high frequency + few languages  -> in-house core
  low frequency + many languages  -> vendor
  anything in between             -> internal owner + vendor capacity