Skip to main content
Upcoming discountNext discount: 10% off — today 19:00.starts in--:--:--Get a quote →
Client Login
Home News Localisation or Translation? The Conceptual Boundary Debate

Localisation 5 August 2026

Localisation or Translation? The Conceptual Boundary Debate

Where does localisation end and translation begin? We examine why this conceptual boundary is blurred, what the prototype approach says and what follows from it in practice.

Is someone who carries a text over into another language doing “translation” or “localisation”? The question is harder than it looks. The conceptual boundary between localisation and translation is one of the most debated and still “unresolved” issues in the field.

Contents

Jiménez-Crespo (2024) treats this boundary not as a sharp line but as a “prototype”. Some jobs sit right at the centre of localisation; others stay out at the edge, close to translation. This article examines that blurred boundary, the prototype approach and the practical consequences of the debate.

Why is the boundary blurred?

It is accepted that there is an “unresolved conceptual boundary” between localisation and translation (O’Hagan and Mangiron 2013). A similar blurring exists between the “localiser” and the “localisation engineer” or “localisation manager”.

Most language service providers offer both “translation” and “localisation”. The difference between them often comes down to nothing more than whether the text belongs to an interactive digital genre. A text with no function or presentation of its own, one that is simply “read”, sits closer to translation; a text that is “used” sits closer to localisation.

This blurring is not a shortcoming but a consequence of the nature of the work. Digital products are so varied that no single sharp definition can cover them all.

What is the prototype approach?

The way to make sense of this blurring is the “prototype approach” (Halverson 1999, 2010). It defines a concept not by sharp boundaries but by typical examples. Say “bird” and a sparrow comes to mind, not a penguin, yet both are birds.

The same logic applies to localisation. Someone working on a complex flight simulator game stands at the centre of the “localiser” prototype. Someone translating content for a digital news site stands out at the edge, closer to the description “translator” or “linguist”.

As Shreve (2020) points out, work activities in today’s language industry “tend to expand in scope rather than remain definable and consistent”. That makes sharp boundaries impossible.

Centre and edge compared

The prototype approach positions jobs as “centre” or “edge”. The table below illustrates the two poles with examples.

PositionExample jobClosest description
CentreAdapting a game’s interface and assetsLocaliser
Close to the centreTranslating and testing software stringsLocaliser
Close to the edgeAdapting the structure of a websiteMixed
EdgeTranslating digital news contentTranslator / linguist

The table shows that the boundary is a spectrum rather than a line. Jobs sit at different points along that spectrum, and a binary “either translation or localisation” split does not reflect reality.

What does working with text alone mean?

A central question in the debate is this: is someone who works only with text strings doing “translation”? O’Hagan (2009) argues that where only the text is carried across, what fans do is “translation”.

Jiménez-Crespo (2024) takes a different view: professional localisation competence calls for broad knowledge of how digital products are developed, stored and rebuilt, even if you work with the text alone. An expert localiser is therefore not “a translator specialising in digital texts” but “a specialist in localisation”.

You can find these distinctions set out in more detail in our knowledge centre, and you can look at our translation services page for your organisation’s needs.

How do you manage the boundary in practice?

A blurred boundary need not be a problem in practice. On the contrary, it is what allows flexible teams to work across different roles. A clear definition is still needed for price and scope.

The following steps will help you position your job correctly:

  1. Work out where the job sits on the localisation spectrum.
  2. Clarify whether only the text is to be carried across, or structure and function as well.
  3. Set the level of expertise required according to that position.
  4. Define scope and price by the actual work, not by a blurred label.

These steps turn conceptual blur into practical clarity. Whatever the label, what matters is the content of the work.

Why is the conceptual boundary not erased altogether?

Blurred though it is, the conceptual boundary is not erased altogether, because the extremes can still be told apart. Translating a printed novel and localising a video game are plainly different jobs. The blur lies in the middle ground only, not at the poles.

That is why keeping the boundary is useful. If the two concepts are treated as identical, the real differences between them slip out of view. The existence of the boundary is a reminder of how much the technical and digital layer matters.

The prototype approach strikes exactly this balance. It neither imposes a sharp line nor erases every difference. Instead it places jobs along a spectrum and so preserves both flexibility and clarity.

The boundary between localiser and engineer

The blurred boundary is not confined to translation and localisation. A similar uncertainty runs between the “localiser” and the “localisation engineer” or “localisation manager”. The roles frequently overlap.

A localisation manager may, for example, correct translations in their own language pair or clear up linguistic errors. In that case the manager is also working as a localiser. The boundary shifts with the person and the project.

This flexibility is even more pronounced on small projects. One person may take on the translation, engineering and testing roles at once. The boundary between roles sharpens as the scale grows and blurs as it shrinks.

“Linguist” in the language of the industry

The industry has an interesting terminological preference: translators are very often called “linguists”. The usage describes specialists who work with text alone and stand at the edge of the prototype spectrum. The term implies how far the work lies from the digital frame.

This naming is the conceptual boundary reflected in language. Someone translating content for a digital news site may be referred to as a “linguist”, while someone adapting all the assets of a game becomes a “localiser”. The terms give the position away.

Knowing the language of the industry therefore helps you read what a job actually involves. Whether an advertisement says “linguist” or “localizer” is a clue to the competence expected. Words give the blurred boundary concrete form.

The conceptual basis of this blurring is the prototype approach. It defines a category not by sharp boundaries but by typical examples. Just as “bird” brings a sparrow to mind first rather than a penguin, “localiser” brings a particular profile to mind first. Someone adapting all the assets of a complex game stands at the centre of that prototype, while someone translating content for a news site stands at its edge. Both belong to the same family, but they stand at different distances.

This approach also explains why the boundary has remained unresolved. In today’s language industry, work activities tend to expand in scope rather than remain definable and consistent. A specialist’s remit does not fit into a single box; it takes in many roles and skills. That expansion makes sharp boundaries impossible. It is not a shortcoming, though, but a consequence of the flexible, dynamic nature of the field. The blurring of the boundary reflects the complexity of reality.

Managed well, this blurring turns into an advantage in practice. Flexible teams can move between roles, and on small projects one person can take on translation, engineering and testing together. What matters is to see the true nature of the work without getting stuck on the label. Even if a job is called “translation”, it should be planned with localisation logic when it involves technical and digital layers. Knowing the conceptual boundary is precisely what makes that accurate assessment possible.

The debate also contains a deeper question about the identity of the localiser. Is someone who works only with text strings a “translator” or a “localiser”? On one view the work is translation; yet professional localisation competence calls for broad knowledge even if you work with the text alone. Knowing how digital products are developed, stored and rebuilt is part of that competence. An expert localiser is therefore not “a translator specialising in digital texts” but “a specialist in localisation”.

In the end, the debate about the conceptual boundary is not an abstract academic detail. It bears directly on how a job is priced, what expertise it requires and which processes are applied to it. Buyer and supplier alike should therefore look at the real content of the work rather than at labels. Understanding the blurred boundary heads off pointless argument and directs energy towards the work itself. Clarity lies not in the concept but in how we apply it.

The Türkiye context

In Türkiye the terms “translation” and “localisation” are often used interchangeably. From the point of view of the prototype approach this is understandable, since the boundary is blurred in any case. In practice, though, the vagueness can lead to problems of pricing and scope. A client asking for “website translation” may in fact be expecting structural localisation.

The characteristics of Turkish often push a job from the edge towards the centre. Even a seemingly simple text translation can require technical intervention because of the text expansion produced by the agglutinative structure, or because of the dotted and dotless “i” problem. Jobs in Turkish that are taken for “pure translation”, in other words, frequently slide onto the localisation spectrum.

For the corporate buyer the conclusion is this: look at the true nature of the work, not at the label. When a Turkish digital product is being carried across, it is safer to assume from the outset that the job involves more technical layers than expected.

What does this mean for you?

If you are buying translation, the fact that the conceptual boundary is blurred should not worry you. What matters is not the label but what the work actually requires. Asking the right questions brings the right scope.

  1. Establish whether your job involves text alone or structure and function as well.
  2. Ask about the real scope without getting stuck on the “translation” label.
  3. Assume a technical layer from the outset with Turkish digital products.
  4. Judge the price by the content of the work, not by the label.

To work out together where your job sits on the spectrum, you can share the details through our quotation form. A clear scope is the basis of good collaboration.

Frequently asked questions

Why is the boundary between localisation and translation blurred?

Because the two are not divided by sharp lines. On the same project, someone carrying the text across may count as doing “translation” and someone dealing with structure and function as doing “localisation”. The boundary remains unresolved.

What is the prototype approach?

It is an approach that defines a concept by typical examples rather than by sharp boundaries. Some jobs stand at the centre of localisation, others at the edge, close to translation.

Is someone who only translates text a localiser?

It depends. On some views this is “translation”; yet professional localisation competence calls for broad knowledge even if you work with the text alone.

Is this blurring a problem?

Not necessarily. A blurred boundary is what allows flexible teams to work across different roles. A clear definition is still needed for price and scope, however.

References

  • Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge (Chs. 1-2).
  • Halverson, S. (1999). “Prototype effects in the ‘translation’ category.” In Translation and the (Re)location of Meaning.
  • O’Hagan, M. & Mangiron, C. (2013). Game Localization. John Benjamins.
Share

Document ready? See your price in minutes

Get an Instant Quote
See your price in 2 minutes Get an Instant Quote
Chat on WhatsApp