Software and Game Localisation 5 August 2026
How Is Game Localisation Testing Done? From Alpha to Gold Build
The job is not over when the translation is. Game localisation testing measures how the text behaves inside the game: overflowing menus, missing audio, wrongly called strings and context errors are all caught here.
A game’s text being translated does not mean the job is finished. How that text behaves inside the game is a separate question, and it can only be answered on a playable build. Game localisation testing is precisely the stage that answers it.
Contents
The book defines this stage as the point at which the localised assets are integrated into the game and testing begins. All the assets working together without problems is essential to a high-quality final product and experience (Jiménez-Crespo 2024, p. 218).
In this article we look at how testing is set up, at the families of bugs, at the severity levels and at the names of the builds. For our other articles on quality, you can browse our knowledge centre.
When does testing begin?
Testing falls into two phases. The first phase comes before integration: linguistic quality is checked and corrected before the translated material is handed over to the game. This is a classic review carried out on the files, and it can be run without playing the game.
The second phase starts after integration. All the localised and reviewed assets are compiled back into the game code, and a preliminary build called the “alpha” or the “first playable alpha” is then produced. Bugs are hunted on this build (Jiménez-Crespo 2024, pp. 218–219).
This distinction matters a great deal in practice. A translation that looks flawless in the file can overflow inside the game, be cut off or appear on the wrong screen. Doing only the first phase and skipping the second means leaving localisation quality half-finished.
The scope of testing also has to be set from the outset. Playing the whole game from beginning to end in every language is not feasible on most projects. Critical paths are defined instead: the main story flow, the shop and settings screens, error messages and the interface elements that are seen most often. If the scope is not written down, testing is left to the tester’s intuition.
The four-stage bug cycle
The post-integration quality process follows a regular cycle. The book summarises that cycle in four steps, and each step has an output of its own (Jiménez-Crespo 2024, p. 219).
- Preparation: the test plan, the scope and the device and language matrix are settled.
- Bug finding: testers play the game and identify the problems.
- Bug reporting: findings are entered in the bug database with a screenshot and the string identifier.
- Bug regression: fixed bugs are retested, and those that do not close stay open.
The cycle does not end in a single round. After the alpha, testers also examine the “beta” build, and all findings are gathered in a bug database. The format of the database varies from supplier to supplier, but the purpose is the same: no finding should be lost.
The cycle calls for constant communication between the translation team and the developer. The book stresses that fixing bugs rests on collaboration with the developers and that progress is documented. After each round, new compilations known as “builds” are produced.
The quality of the report determines the speed of the cycle. A good record states where the bug was seen, how it can be reproduced and what the correct behaviour should be. A notice along the lines of “there is a bug in the menu” forces whoever has to make the fix to search out the same path from scratch.
Three families of bugs
Findings are collected into three main groups. Functionality bugs concern the mechanics of the game; unexpected crashes fall into this group. They are the responsibility of the development team rather than the language team, but they can surface in the localised build.
Compliance bugs concern the requirements of the platform, of the saga or of legal regulation. Terminology, set phrases and established rules are checked under this heading. A term that runs against the platform glossary is serious enough to block publication.
The third group is linguistic bugs, known in the industry as linguistic localisation quality analysis. The book gives this group as a detailed sub-list; that list is the de facto checklist that determines what linguistic testing will look at.
Keeping the families apart is useful for reporting too. A text overflow looks like a linguistic bug, but its origin may lie in the interface design. Filing the record under the right family sends the fix to the right team and prevents needless back and forth.
Linguistic bugs specific to games
The table below brings together the categories of linguistic bug listed in the book and the way each of them typically shows up inside the game. The categories go beyond standard translation errors; they also cover problems that arise from the technical structure of the game.
| Category | Typical appearance in the game |
|---|---|
| Mistranslation | A shift in meaning, or the wrong text being displayed |
| Missing translation | A string left in the source language, a missing placeholder |
| Game terminology | A term contrary to the glossary, internal inconsistency |
| Spelling and grammar | Spelling, punctuation and suffix errors |
| Font problems | Special characters appearing corrupted |
| Audio problems | Missing audio, cut-off, wrong language, timing |
| Context error | A rendering that is correct but sits in the wrong place |
| Text display | Overflow, overlap, truncation |
| Technical text | Corrupted text, a wrongly called string |
| Style | Loss of a character’s voice or of the tone |
Two rows of this list stand out for Turkish. Font problems arise where the characters ç, ğ, ı, ö, ş and ü are not supported. Text display problems, for their part, come from Turkish renderings running longer than the source.
The context error row is particularly insidious as well. The text is flawless grammatically and correct in dictionary terms; it simply does not suit the place it sits in. Findings of this kind are not caught by automated checking tools, but they are noticed by a tester who plays the game.
Severity levels and the priority decision
Not every bug carries the same weight. The book reports a four-level scale: “cannot be sold as it stands”, “playable but affects playability”, “noticeable but does not affect playability” and “barely visible” (Bernal-Merino 2020, cited in Jiménez-Crespo 2024, p. 219).
This scale determines where you spend limited time. As the release date approaches it may not be possible to close every finding. The book states plainly that some bugs which do not affect gameplay can remain in the final release candidate.
Visibility should be taken into account in the decision as well. A small spelling mistake seen in the first ten minutes of a game will be talked about more than a serious stylistic problem seen in the thirtieth hour. The priority list is built where severity and visibility intersect.
Whoever uses the scale has to be trained in it too. Two testers assigning different levels to the same finding makes the report unreliable. Reading a few examples together at the start of the project keeps the hundreds of records that follow classified consistently.
Alpha, beta, gold build, release candidate
The testing process has a vocabulary of its own, and these terms turn up in contracts. The alpha is the first playable build produced after integration. The beta is a more mature test build with wider coverage.
The compilations produced by successive rounds of testing and fixing are called “builds”. The final product is named the “pre-gold” or the “gold build” and is delivered to the client; in this scenario the client is usually the publisher (Jiménez-Crespo 2024, p. 219).
Once the game is ready to be published it is referred to as the “release candidate”. Approval from the age rating boards should also be complete by this stage; the book reminds us that in some markets sale is not possible without that approval.
Using these terms in the contract clarifies the delivery points. “Payment is made when the translation is delivered” and “payment is made when the gold build is approved” create very different obligations. What each party undertakes at which build should be written down from the outset.
Why is accessibility testing skipped?
The book points to a plain gap: quality testing could also verify game accessibility, but this is not common practice in the industry (Jiménez-Crespo 2024, p. 220). The accessibility features of the localised build are most often left unchecked.
Yet localisation affects those features directly. Subtitle size, time on screen and reading speed have to be recalculated when the language changes. A line that runs long in a Turkish subtitle can make a timing that was perfectly fine in the source language unreadable.
Adding accessibility testing to the plan is not a costly extra. Adding a few check items to the existing test round is usually enough: is the subtitle legible, do the audio cues have a written equivalent, can the text be scaled.
These checks do not only benefit players with disabilities. Legible subtitles, clear interface text and a scalable font improve the experience of every player. Seeing accessibility as part of the quality standard rather than as a separate act of goodwill also makes the budget discussion easier.
The Türkiye context
The test findings encountered most often in Turkish builds come from the structure of the language. Text expansion leads to overflow in menus, while the agglutinative structure produces run-together or incorrect suffixes in strings that contain variables. Neither of the two is visible in the file; both are visible only inside the game.
The second common finding comes from fonts. If the custom font chosen for the game does not contain the Turkish characters, the letters appear as boxes or in the wrong shape. If this problem is not solved during development, it is difficult and expensive to correct at the testing stage.
The third is the difficulty of finding Turkish testers. Testing has to be done by people who know the language, play the game and are able to write a bug report. In Türkiye the profile that combines all three of these is scarce, which is why testing is often left to the translation team itself. The ideal is for the person who translates and the person who tests to be different people.
What does this mean for you?
When you draw up a localisation budget, show testing as a separate line. An expectation of testing that has been absorbed into the translation price usually goes unmet in practice, and the problems reach the player.
- Prepare the test plan at the same time as the translation contract; write down the scope and the language matrix.
- Give the testers a playable build and a list containing the string identifiers.
- Make sure every record in the bug database carries its category, its severity and its string identifier.
- Turn the risks specific to Turkish into a separate checklist: fonts, text overflow, strings with variables.
- Retest the bugs that have been fixed; carry the records that have not closed over to the next build.
- Add the accessibility checks to the plan; do not defer them as a separate project.
These steps make the game localisation testing process predictable and reduce the chance of surprises on release day. If you would like to talk through the scope and the process options, you can use our quotation form and look over our fields of work on our services page.
Frequently asked questions
When does game localisation testing begin?
It begins when the translated and reviewed assets are compiled back into the game code. A linguistic check is carried out before integration; after integration, the bug-hunting process runs on a playable build.
How are bugs classified in game testing?
Three families are used: functionality bugs, compliance bugs and linguistic bugs. Linguistic bugs are further divided into mistranslation, missing translation, terminology problems, spelling, fonts, audio, context, text overflow, technical text and style.
How is bug severity graded in games?
A four-level scale is common: cannot be sold as it stands, playable but affects playability, noticeable but does not affect playability, barely visible. Priority starts from the level at the top.
What is the difference between the gold build and the release candidate?
The final product compiled as a result of the tests and fixes is delivered to the client as the gold build. Once the game is ready for release, it is referred to as the release candidate.
References
- Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge, pp. 218–220.
- Muñoz Sánchez, P. (2017). Localización de videojuegos. Síntesis.
- Game Accessibility Guidelines, gameaccessibilityguidelines.com.