What Is a Localisation Level? How Do You Decide What Gets Translated?

“Translating” a website or an app looks like a single job. In practice, though, almost every project brings us up against the same question: what gets translated. The home page, or every page? The interface buttons, or the help documentation as well? Are error messages included?

Contents

The industry calls the answer to that question the localisation level. In the definition given by the source book, the concept expresses the extent to which an entire digital text is localised, and it is largely determined by constraints (Jiménez-Crespo 2024, p. 18). It is a strategic decision, then, not a technical one.

This article looks at what the notion of level means, which constraints narrow the scope, which layers come first and which come later, and what consequences partial localisation has on the user’s side. The aim is to let you draw the scope with your own hand before you ask for a quotation.

What is a localisation level?

The localisation level is the measure that shows how much of a digital product has been prepared for the target locale. The two examples the book gives make the point clear. A software localisation project may focus only on the user interface and leave the help pages in the source language. A web localisation may cover only the home page and the contact page, with the rest of the site left unlocalised (Jiménez-Crespo 2024, p. 18).

Note that what is being described here is not a quality problem. A partially localised product may be flawless as far as the translated parts go. Level describes not how well the translation was done but how much of it was done. Confusing these two measures is one of the commonest mistakes made in evaluating quotations.

Level is also a quantity that can change over time. A product can launch with a narrow scope and widen that scope as demand appears. Mature teams manage scope not as a fixed decision but as a variable tied to measurement.

The three sets of constraints that set the scope

The source book defines localisation as a process driven by the expectations of the target audience and bounded by technological, development-related and economic factors, with return on investment singled out among the economic ones (Jiménez-Crespo 2024, pp. 17-18). This trio frames the discussion of scope.

Technological constraints are the most concrete. If the text is embedded in the code, if a content type cannot be separated out into resource files, or if the system does not support a particular writing system, the scope narrows of its own accord. Obstacles of this kind are cleared by the development schedule, not by the translation budget.

Development-related constraints have to do with the release tempo. On a product updated every two weeks, localising every layer in every version may not be sustainable for the team. Economic constraints ride on top of that: the revenue expected from the target region directly determines the scope allocated to it.

Screen space: an invisible but binding limit

One of the most concrete constraints that separates localisation from print translation is the spatial limit. As the source book puts it, localisation is limited by the size of the interactive screen on which the digital text is displayed (Jiménez-Crespo 2024, p. 18). The length of a button label is a technical constraint, not a matter of style.

Visual tools focused on screen space have been developed to deal with this problem. The book gives Alchemy Catalyst and Passolo as examples, along with some cloud-based solutions. These tools allow the localiser to work in environments where the result is directly visible, so that whether all the elements fit the screen space can be checked during translation.

The spatial constraint also affects the scope decision. On mobile interfaces where screen space is tight, short labels are preferred to long explanatory text, and the detail is moved into the help layer. That makes it all the more critical whether the help layer is localised or not.

Layers: which comes first?

The most practical way to make the scope decision manageable is to break the product down into layers. Each layer has a different effect on the user and a different localisation cost. The table below shows a typical order of priority; the order can vary by sector and by product.

Layer	Example content	Effect if not localised	Typical priority
User interface	Menus, buttons, form labels	The product becomes unusable	Very high
Transaction flows	Payment, registration, cancellation steps	Conversion falls, trust is lost	Very high
Error and system messages	Warnings, validation text	The user is left stuck where they are	High
Help and documentation	Frequently asked questions, guides	The support load rises	Medium
Marketing content	Campaign pages, blog	Reach and visibility are limited	Variable
Legal texts	Terms of use, privacy	Compliance risk can arise	Depends on legislation

The order in the table is not absolute. In a regulated sector the legal texts can move to the top; on a product that grows through content marketing the blog layer can rank equally with the interface. What matters is that the ordering is done deliberately.

What does partial localisation do on the user’s side?

A user who meets an unlocalised layer reacts in one of two ways: either they carry on in the source language, or they abandon the process at that point. Which reaction dominates depends on the user’s command of the source language and on how critical that layer is.

The risk has less to do with a gap in language knowledge than with the perception of trust. Coming across English text at the payment step while moving through a Turkish interface leaves the user with the impression that “this part was not prepared for me”. That impression can lower conversion regardless of the quality of the translation.

This is why it is safer to take the scope decision by the user journey rather than by the number of pages. The path a user follows from entering the product to completing a transaction should be in the same language from start to finish; secondary content can be added later.

The interactive nature of digital texts magnifies this risk. Users do not read a text from beginning to end; they draw their own paths and move around the screen. It is therefore hard to predict at which point and in which order an unlocalised layer will be met. This unpredictability has to be taken into account when the scope list is drawn up.

Who takes the level decision?

The scope decision is not one person’s job. The product team knows what is technically separable, the marketing side knows which content brings a return, and the legal department knows which texts are mandatory. The localisation supplier, for its part, supplies the cost and the time attached to each layer.

As the book stresses, localisation is an interprofessional cycle in which different actors collaborate flexibly. The scope decision is the first joint decision in that cycle. Taken unilaterally, the layer left out is usually the layer noticed last.

A practical method is to set the scope down as a written list and to put the responsible unit against each line. This list makes it easier to obtain quotations and heads off the mid-project arguments about whether something was included.

How do you raise the level over time?

Starting with a narrow scope is not a shortcoming but a measurable beginning, provided the plan for widening it is set up from the outset. For that, the usage data of the layers localised first is monitored. Which page the target-language users cluster on, and at which point they abandon the process, shows which layer should come next.

The second condition is technical readiness. If the layers to be added later have been separated out into resource files, expansion is reduced to a translation job. If that separation has not been made, every step of expansion requires fresh development and the increase in scope costs more than expected.

The third is consistency. As the scope widens, unity of terminology and style with the earlier layers has to be maintained. If a translation memory and a termbase have been set up from the first stage, this unity comes about of its own accord; if not, a full alignment exercise is needed at the second stage.

The Türkiye context

The picture seen most often on foreign products entering the Turkish market is a Turkish interface with the support documentation left in English. When users run into a problem they have to switch language, and the support request goes straight to the call centre. This is the saving made on the localisation budget shifting onto the support cost.

On the legal layer the position is more binding. In Türkiye, the distance sales contracts, pre-contractual information forms and privacy notices presented to consumers are prepared in Turkish. In personal data processing activities, the duty to inform under the KVKK also requires a Turkish text. Leaving this layer out of scope is not a matter of choice.

The third point concerns the structure of the language. The agglutinative structure of Turkish tends to lengthen interface labels relative to the English source. Even where the scope is kept narrow and only the interface is localised, screen testing has to be planned as a separate line item.

What does this mean for you?

Setting the localisation level in advance is what makes a comparison of quotations meaningful. Most of the difference between two quotations for the same product usually arises not from pricing policy but from a difference in assumed scope. If you define the scope, the comparison is fair.

Break your product into layers and produce a separate word volume for each layer.
Mark the steps in the user journey that must not be interrupted.
Gather the texts that have to be in Turkish by law under a separate heading.
Set a review date for the layers left out of scope.
Budget the screen testing separately from the translation line item.

These five steps turn the scope into a document. You can find our service descriptions arranged by layer on our services page, and reach us with your own scope list through our quotation form.

This article is for general information only and does not constitute legal advice.

Frequently asked questions

What does localisation level mean?

The localisation level shows how much of an entire digital text has been localised. On a software project, only the user interface may be carried into the target language while the help pages are left in the source language. On a web project, only the home page and the contact page may be localised, with the rest of the site left in the source language.

Which factors determine the scope?

Three groups of constraint are decisive: technological constraints, development-related constraints, and economic constraints, chief among them return on investment. To these are added spatial limits such as screen space and the expectations of the target audience. The scope decision is the resultant of these factors; it is not a linguistic decision on its own.

What does the screen space constraint mean?

Localisation is limited by the size of the interactive screen on which the digital text is displayed. When the translation comes out longer than the source text, buttons or menus overflow. In the industry, visual tools such as Alchemy Catalyst and Passolo, along with some cloud solutions, allow the localiser to work in environments where the result is visible and to check that the elements fit the screen.

Does partial localisation do harm?

It depends. If the user commands the source language and the unlocalised layer holds secondary information, the effect stays limited. But if critical flows such as purchase, payment, privacy and cancellation are left in the source language, there is a risk both of lost trust and of being misunderstood. The scope decision should be taken by giving these flows priority.

Sources

Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge, pp. 17-18.
Consumer Protection Law No. 6502 and the Regulation on Distance Contracts, pre-contractual information obligations.
Personal Data Protection Law (No. 6698), provisions on the duty to inform.