Post-localization includes all the tasks performed after translating and reviewing the target files. It consists mainly of the following two stages:

1. Integration

An engineer or team of engineers integrate the translated files, the audio and art assets, and the image files into the game code and produce a functional and usable version of the localized product, known as the "first playable alpha".

2. Debugging and quality assurance (QA)

Once the first playable alpha has been integrated, the debugging and QA process begins in order to detect bugs, that is, errors in the game. A team of testers (from the developer’s company in the in-house model, the translation vendor or a specialized QA vendor in the outsourcing model) play the beta version of the game, exploring all possible options, searching for errors and entering them into a bug database daily. In the in-house model, localizers are usually also involved in the QA or debugging process. As bugs are found and corrected, new versions of the game are integrated and released, known

as "builds". Once the game is very stable and most of the bugs have been fixed, the pre-master version is ready. At this stage only serious bugs are fixed, in order to avoid new complications. Once the pre-master version has been tested and any issues detected have been fixed, the release candidate (RC) is made available.

The amount of time devoted to testing varies from title to title, from a few weeks to a few months in the case of AAA titles such as the Final Fantasy series. In addition, testing for low-budget or casual games sometimes does not start until the RC is ready. Usually game developers for PC and online games also conduct public beta testing. An open call is made for this kind of testing, and game fans happily do it for the thrill of being able to play a new game before it is officially released. This kind of testing usually takes place once the first playable alpha is available. Players can then play the game as they wish and report any detected errors and malfunctions to the developers, so that these bugs can be fixed before releasing the final version; developers may also be provided with more general feedback about the game.

It is important to note that quality assurance in localization usually consists of two stages: the editing and the QA. Most other types of translation only involve a review in the form of a self-check by the translator and/or by a separate editor or the client, but in localization there is another type of check after the editing has been finalized. This is due to the nature of localization, namely that: (a) the TT is embedded in electronic form; (b) the ST is often unstable; (c) sometimes there is no access to the original game and no contextual information, and (d) several translators and reviewers participate in the localization process (although this is not unique to localization). The QA is the stage in the localization process when translators and reviewers can view those isolated strings they translated in context for the first time. This allows them to detect errors caused by the lack of contextual information at the earlier translation stage and improve the quality of the target version. For this reason, the QA process of localized products is given paramount importance by developers and it can be as lengthy as, or lengthier than, the translation process itself. In relation to the type of errors detected in a localized console game, those most commonly found relate to the following three main areas: