Aarnae
02Linguistic QA

Check the text where
it actually lives.

In-game linguistic quality assurance: context errors, truncation, variables, agreement and terminology consistency, documented in a report your team can act on directly.

What LQA checks

Text is read where it lives: in the game, at the exact place and moment a player meets it. That surfaces a class of errors no string file can reveal.

  • Context-dependent meaning errors
  • Truncation, overflow, overlapping text
  • Variables, plurals, gender agreement
  • Spelling, grammar, punctuation
  • Terminology and register consistency
  • Readability and natural-sounding dialogue

How a pass runs

I play the agreed routes with a coverage list in hand, logging every finding as it appears. Edge cases are triggered on purpose: long character names, quantities of zero and one, language switches, window resizing.

  • Routes and areas agreed up front
  • Deliberate display edge-case testing
  • Both languages checked when needed
  • Verification pass after fixes land

The bug report

Each finding is documented with a screenshot, a severity and a fix ready to paste in. The goal is that a developer can apply the correction without having to reconstruct the context.

  • Screenshot and string identifier
  • Severity and player-facing impact
  • Suggested fix, ready to integrate
  • Export in your tracker's format

Where LQA changes the review score

The most damaging criticism of a localized release is rarely a spectacular mistranslation: it is clipped buttons, shaky agreement and mechanical phrasing repeated a hundred times. An LQA pass before launch removes exactly that layer of friction.

Frequently asked

What exactly is LQA?
LQA (Linguistic Quality Assurance) means checking text inside the running game rather than in a spreadsheet. It catches what an out-of-context reviewer cannot see: a sentence that is correct but absurd in that moment, a truncated button, a variable printing “1 potions”, wrong gender agreement for the chosen character.
How is it different from proofreading?
Proofreading looks at the text alone. LQA looks at the text as it appears on screen: position, length, timing, and coherence with what the player is doing. They complement each other, but only LQA catches display and context bugs.
How are bugs reported?
As a structured report: string ID where available, screenshot, description, severity and a suggested fix. The format can follow your existing issue tracker.
When in development should LQA happen?
Ideally on a playable build before certification or before a major update, while there is still time to fix findings. An earlier pass over text-heavy areas is also useful.

Read next

“Text that is right in a spreadsheet can be wrong on screen.”

Request an LQA pass