Localisation 6 August 2026
What Is LQA? The Four Stages of the Localisation Quality Analysis Process
Localisation quality analysis runs in four stages: planning, preparation before testing, testing and applying the fixes. We set out what each stage produces and the mistakes made most often.
In localisation projects the argument about quality usually begins after delivery. Yet most of the decisions that determine quality are taken before the first word is translated. If it is not settled at the outset which errors are unacceptable, who will carry out the testing and how findings will be recorded, the review stage turns into a dispute.
Contents
In the industry this work goes by the name LQA. So what is LQA? Miguel A. Jiménez-Crespo notes that the process of checking the quality of a localised product is called testing, quality assurance or localisation quality assurance, and writes that the process aims to ensure the product works properly and is usable and accessible (2024, p. 61).
This article sets out the four stages of the LQA process, what each stage produces in concrete terms, and the points at which the buyer needs to step in.
What is LQA and what does it cover?
LQA is the collective name for every operation carried out to verify that a localised product has the qualities expected of it. Its scope is not limited to reading the text: whether the product works, whether it appears correctly on screen and whether it can be used by everyone, users with disabilities included, all fall within this frame.
The process varies with the type of localisation and the type of content. The book stresses that there is no one-size-fits-all approach in the industry and that practice differs according to content type, quality strategy and the quality framework chosen (Jiménez-Crespo 2024, p. 61).
The person running the process is usually a quality or testing manager. They plan the stages, put them on a schedule and coordinate testers working in different languages. On small projects the project manager takes this role on; but where the role is left undefined, the stages run into one another and responsibility ends up with no one.
LQA should not be thought of as a one-off check. The stages can be run in sequence or iteratively, they can be carried out by different evaluators, and part of them can be handed over to automated tools. The process is set up as a flexible framework that contracts or expands according to the size of the project and how critical the content is.
Stage 1: Planning and quality design
The first stage is also called “quality design”, and it covers the careful documentation of quality requirements. Dunne’s proposal for a client-focused LQA gives particular weight to the importance of this stage (cited in Jiménez-Crespo 2024, p. 67). Every item skipped here produces compounding cost at the stages that follow.
The areas that need to be documented fall under three headings: linguistic requirements, terminological requirements and visual requirements. In addition, the types of quality assurance and quality control process to be applied are also written down.
The planning stage also defines the test schedule, the error type classification to be used, the bug reporting tool and the quality framework chosen. Taking these four decisions at the start of the job is what makes the review report comparable.
Planning has one further function that tends to be overlooked: aligning expectations with constraints. Once budget, delivery date and available staff are put on the table at this stage, it also becomes clear which level of quality is realistic. Most of the disappointment that comes later stems from this alignment never having been done at all.
Stage 2: Preparation before testing
At the second stage the testers in each language receive the instructions, the localisation kits and the style guides. Testing carried out without these documents goes no further than measuring the reviewer’s personal preferences; when two reviewers read the same file, two different reports come out.
Instructions can sometimes be very concrete. The book reports that in game localisation the instructions may even state how many hours are to be played or how many levels have to be completed (Jiménez-Crespo 2024, p. 67). Quantification of this kind makes the scope of the test measurable.
The style guide is the most valuable document of this stage. Mozilla’s openly available localisation style guide is a good example of how headings such as tone, forms of address, and number and date formats are documented, and it can be used as a template when you are preparing your own guide.
The contents of the localisation kit also become clear at this stage: source files, term list, screenshots, character limits and, where there is one, the translation memory from the previous version. Sending this package out incomplete is the real cause of a significant share of the errors found at the testing stage.
Stage 3: Running the test
The test proper covers the review of the localised content. This review can be done bilingually, through localisation and translation tools, or directly on the target version. Which one is chosen depends on the type of localisation.
Not all the errors found are handled in the same way. Errors of a linguistic nature can be corrected directly; functional or visual errors are logged in bug reporting mechanisms, because fixing them requires a change to the code or to the layout. In game localisation, linguistic problems are entered into the bug report as well (Jiménez-Crespo 2024, p. 67).
Automated tests can take on part of this stage. Checks such as tag integrity, number consistency, empty segments and term compliance can be done by machine. But automated checking only catches formal problems; decisions about meaning and appropriateness remain with the human.
Stage 4: Applying the fixes and keeping records
At the final stage the fixes are applied using bug reporting and tracking tools, and the actions taken are documented. This documentation produces its value not at the close of the project but in the planning of the next one.
The error data recorded is kept in order to analyse how the localisation and testing processes can be improved. The book stresses that this feedback improves future LQA planning and quality design (Jiménez-Crespo 2024, p. 67).
This is the stage skipped most often in practice. The errors are corrected, the file is delivered, the data is lost. And yet a team that looks at its error records after three projects can usually see clearly where recurring problems are coming from. Whether the source is the source text, the style guide or the tool configuration only becomes apparent through this accumulated record.
The difference between QA and QC
These two abbreviations are frequently confused. Quality assurance aims to establish procedures before, during and after the process so that predefined requirements are met and failure is prevented.
Quality control, by contrast, aims to examine the finished product, identify the failures that have occurred and stop them reaching the client. It is applied across the whole cycle, from the preparation of the source text through to delivery, and is regarded as a subset of quality assurance (Jiménez-Crespo 2024, p. 68).
In practice the difference comes down to this: a project that does only quality control, without quality assurance, catches the same errors again every time. Because the source of the errors is never dried up, the cost recurs with every release and the review budget swells over time.
Quality control is usually carried out with standardised criteria, on the basis of error analysis. That is, errors are counted, weighted and compared against a threshold. The strength of this method is that it produces comparable results; its limit is that it can see only the problems that can be counted, and cannot measure user experience directly.
How does the cycle work in continuous localisation?
The stages can be applied one after another, but in continuous localisation environments they can also be run iteratively. In such environments content flows in small packages at frequent intervals, and setting aside a conventional testing period is not possible.
- The quality requirements are written once and reused for every release.
- The testers stay the same, so that contextual knowledge accumulates.
- Automated checks are applied to every package, and human review is done on a sample.
- Bug reports are collected in a single system.
- At set intervals the records are examined and the specification is updated.
The table below summarises what each of the four stages produces and who is responsible for it. If the entries on these rows are blank on a project, that stage is not in fact being carried out.
| Stage | Concrete output | Typically responsible |
|---|---|---|
| Planning | Quality requirements document | Quality manager and client |
| Preparation | Style guide and localisation kit | Project manager |
| Testing | Error list and bug reports | Tester |
| Implementation | Corrected version and records | Localiser and developer |
The Türkiye context
In Türkiye a large share of localisation projects runs through agencies, and the LQA stages are usually squeezed into a single “proofreading” line item. Because the planning and record-keeping stages are invisible, the same terminology error can surface again and again across different projects.
The absence of a style guide is a particular problem here. In Turkish, if decisions such as forms of address, date and time notation, the decimal separator, how units are written and whether brand names take suffixes are not written into a guide, every translator applies their own preference. The result is a text that is correct but inconsistent.
In public tenders, specifications generally define the output rather than the process. Because no quality design document is asked for, the scope of testing is left to the provider. Adding the test method and the error classification to the tender specification, in a single clause, markedly increases how comparable the results are.
What does this mean for you?
If you are buying localisation, LQA is a process for which you carry responsibility too. Most of the inputs to the planning stage sit with you: the purpose of the product, the target user, terminology preferences and interface constraints.
Ask your provider explicitly which stages are included. If testing is not priced as a line item, it is probably not being done. You can compare which service scope includes which checks on our translation services page, and share your project details through our contact page.
Finally, ask for the error records. A corrected file on its own is an output; an error record is an asset that lowers the cost of the next project. After two or three releases these records will tell you themselves which checks to invest in for which type of content.
Frequently asked questions
What is LQA, defined briefly?
LQA stands for localisation quality analysis or localisation quality assurance. It covers all the processes carried out to verify that a localised product works properly, is usable and accessible, and contains no visible errors.
What is the difference between QA and QC?
QA is the set of procedures put in place before, during and after the process so that errors never arise in the first place. QC aims to check the finished product and catch the errors that have occurred before they reach the client. QC is regarded as a subset of QA and is usually carried out with criteria based on error analysis.
Is every error found at the testing stage handled in the same way?
No. Errors of a linguistic nature can usually be corrected directly. Functional or visual errors are logged in the bug reporting system, because fixing them requires a change to the code or the layout. In game localisation, linguistic problems are entered into bug reports as well.
Are these four stages necessary on a small website project?
The stages scale. On a small project, planning can come down to a one-page document, preparation to a link to a style guide, and testing to a review before going live. The point is not to skip the stages but to fit their size to the job.
Sources
- Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge, pp. 61, 67-68.
- Dunne, K. J. (2011). Proposal for a client-focused LQA process; cited in Jiménez-Crespo 2024, p. 67.
- Mozilla Localization Style Guide, mozilla-l10n.github.io/styleguides/mozilla_general/
- Esselink, B. (2000). A Practical Guide to Localization. John Benjamins.