Internal Quality and External Quality: A Two-Layer View of Localisation

When the quality of a localised product is discussed, the two sides are often talking about two different things. The provider describes the accuracy of the text and the consistency of its terminology; the customer asks whether users can actually get their job done with the product. Both are right, because quality is not a single-layer concept.

Contents

Translation studies has already given this duality a name. According to the distinction found in the work of Gouadec and Jiménez-Crespo, localisation quality is examined on two layers, “internal quality” and “external quality” (Jiménez-Crespo 2024, p. 64). If your audit plan does not know which of these two layers it is measuring, then it is measuring incompletely.

This article looks at what the distinction between internal and external quality means, at the methods by which each layer is measured, and at how to decide when the two layers come into conflict.

Where does the distinction between internal and external quality come from?

The distinction arises from the question of where quality is to be sought. Do we look for the quality of a text within the text itself, or in the result the text produces out in the world? In translation studies these two views stood side by side for a long time; in localisation, using both at once has become unavoidable.

In Jiménez-Crespo’s scheme, the heading of external quality covers functionality, usability, playability, fitness for the job the client has commissioned, compliance with international standards, legal systems, user expectations and web accessibility (2024, p. 64). Internal quality, for its part, covers the textual, linguistic and pragmatic layer.

This scheme makes a useful checklist even on its own. Asking how many of these eight headings are audited on a localisation project exposes the gap in most quality plans within a few minutes.

That is also where the practical value of the distinction lies. The moment you name the two layers, the discussion moves from “is the work any good” to “which layer has the problem”. This both puts responsibility in the right place and allows the cost of correction to be estimated correctly.

Internal quality: consistency within the text itself

Internal quality describes the properties belonging to the localised text itself: the quality of the textual content, the coherence of all the terms in a software interface with one another, the correct construction of sentences in the target language (Jiménez-Crespo 2024, p. 64). In short, the properties you could see even if you lifted the text off the screen and read it on its own.

In industry practice, internal quality is usually expressed through three criteria. The first is the equivalence and consistency of the target text with the source text (Dunne 2009). The second is fluency, that is, how well the text is expressed in the target language. The third is accuracy, that is, the preservation of the meaning of the source text.

Internal quality is relatively easy to measure. Errors are counted, weighted and compared against a predetermined threshold. That ease is also a danger: the layer that is easy to measure tends to crowd out the layer that is hard to measure, and the report can look good while the product works badly.

Internal quality has one further limit. When a text is audited in fragments, individual segments may look correct while the consistency of the whole slips away. The same button being referred to by two different names on two different screens does not count as an error at segment level; for the user, however, it is a real problem.

External quality: fitness for purpose, for the user and for the law

External quality is concerned with the extent to which the localisation fulfils the purpose for which it was started, with how usable the product is, and with how far it meets the needs of the client and of the user (Jiménez-Crespo 2024, p. 64). The text may be accurate, but if it does not carry its purpose, external quality is low.

A concrete example: the Turkish version of a support page may be linguistically flawless. But if it describes a returns procedure that does not apply in the target country, the user cannot solve their problem. There is no language error here at all; the problem lies in the validity of the product in the target market.

Another component of external quality is accessibility. Whether the labels defined for visually impaired users have been localised, and whether the screen reader reads the text correctly, falls within the field of external quality and calls for a separate test.

That is also where the difficulty of measuring external quality comes from. Measurement requires a working version of the product, real users, or at the very least a reviewer who knows the target market. On many projects, therefore, external quality is never measured at all, and the problems only become visible after release, through user feedback.

Are usability and playability quality criteria?

Yes. The book reports that in game localisation “playability” can be used as a quality criterion in its own right (Bernal-Merino 2020, cited in Jiménez-Crespo 2024, p. 65). If the game can be played fluently, that on its own is an indicator of quality.

There are similar criteria on the web side. Whether a localised site leads more customers to buy, whether it draws more repeat visits, or whether an FAQ section reduces the number of calls reaching the call centre can all be used as quality criteria (2024, p. 65).

What these criteria have in common is that they work without counting errors. What is measured is the user’s behaviour, not the text. External quality measurement therefore usually rests on data held not by the localisation team but by the product and analytics teams.

Why do standards talk mainly about external quality?

Industry publications discuss external quality more, and that discussion is usually grounded in international standards such as ISO 9000 or the translation-specific EN 15038 (Jiménez-Crespo 2024, p. 64). These standards describe quality as the capacity to comply with criteria the client has defined in advance.

There is a price for this. Industry definitions do not define internal quality in its own right; they focus instead on procedural aspects. Rather than saying what counts as a quality product, they regulate the steps to be followed in order to reach quality (2024, p. 65).

The upshot is that you end up with process assurance, not product assurance. Even when you commission work from a provider holding a standards certificate, therefore, you still need an audit plan at product level.

What happens when the two layers conflict?

Conflict happens more often than people suppose. When you translate an interface string with word-for-word fidelity to the source, internal quality rises; but if the text will not fit the button, external quality falls. Conversely, when you shorten the text and make it flow, you move away from the source text and take a penalty in the internal quality measurement.

The functionalist approach puts external quality first in such cases: the product must reach its purpose. That preference, however, has to be written into the specification. If it is not, the reviewer takes fidelity to the source text as the basis and good decisions get recorded as errors.

In the quality model the book describes, there is a category at “zero” level for changes of this kind. The change made goes on the record, but no penalty score is applied (Jiménez-Crespo 2024, p. 71). This category is one of the practical ways of managing the tension between the two layers.

The other way to reduce conflict is to share the constraints before the translation stage. A localiser working with character limits, screenshots and a list of variables in hand can attend to both layers at once. When that information is withheld, a choice becomes unavoidable, and which layer gets sacrificed is decided by chance.

Measuring the two layers together

The table below summarises which questions the two layers seek to answer and by which method they are measured. In a quality plan, every row is expected to have a counterpart.

Layer	Question it asks	Typical measurement method
Internal quality	Is the text accurate, fluent and consistent?	Error counting and weighting
Internal quality	Are the terms coherent across the interface?	Termbase audit
External quality	Does the product reach its purpose?	Task-based user testing
External quality	Does it comply with the specification and the law?	Compliance checklist
External quality	Can it be used by everyone?	Accessibility testing

What the table shows is plain: no single method can measure both layers. Error counting does not see external quality, and user testing does not catch terminological inconsistencies. Neither takes the place of the other; they complete one another.

The Türkiye context

In Türkiye, localisation auditing is mostly confined to internal quality. The delivered file is read bilingually, terminological and spelling errors are corrected, and the job is closed. The moment at which the product meets the user in the target environment usually goes untested altogether.

Yet the formal features of Turkish make external quality problems highly visible. Because of its suffixing structure, labels grow longer and lines overflow in narrow columns; in sentences containing variables, case endings fall in the wrong place. These problems do not show up in the bilingual file; they emerge only in the running interface.

The regulatory side presents a similar picture. A site selling in Türkiye has to arrange its distance selling, returns and KVKK privacy notices in line with local requirements. A word-for-word translation of the source text may be linguistically flawless and still fail to meet those requirements. This article is for general information only and does not constitute legal advice.

What does this mean for you?

For the party buying localisation, the practical conclusion is this: plan the file audit and the product audit separately. The first measures the text, the second measures the experience, and the two cost different amounts.

1. Add a clause for testing on the product itself alongside linguistic review in the contract.
2. Set two or three measurable indicators for external quality: task completion, number of error reports, support requests.
3. Share the character limits for interface strings from the outset.
4. Budget accessibility testing as a separate line item.
5. Feed the test results back into the specification for the next release.

If you are not sure how to set this distinction up on your project, we collect the relevant articles in our knowledge centre. Once you have clarified the scope, you can price the two audit line items separately through our quotation page.

Frequently asked questions

What is the basic difference between internal and external quality?

Internal quality is concerned with properties within the text itself: accuracy, fluency, terminological consistency. External quality looks at whether the product reaches its purpose: usability, compliance with the client specification, user expectation and accessibility. The two are measured by different methods.

Why can a localisation that passes linguistic review still fail?

Because linguistic review measures internal quality only. Even when the text is accurate and fluent, it may overflow in the interface, it may not contain the information expected in the target market, or it may not be readable by a screen reader. These are external quality problems and they call for a separate test stage.

How is external quality measured?

Through user-focused criteria. In games, playability can count as an indicator of quality. On websites, the purchase rate, the number of repeat visits, or whether an FAQ section reduces the calls reaching the call centre can be used as criteria.

Is it necessary to audit both layers on a small project?

Usually yes, though the scale can be reduced. After linguistic review, using the product in its target environment with a few typical scenarios brings most external quality problems to the surface. On most projects this check takes less than an hour.

References

• Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge, pp. 64-65.
• Gouadec, D. (2010). Quality in Translation. Handbook of Translation Studies.
• Bernal-Merino, M. Á. (2020). The playability criterion in game localisation; cited in Jiménez-Crespo 2024, p. 65.
• ISO 9000 and EN 15038 quality definitions; cited in Jiménez-Crespo 2024, pp. 64-65.