What Is Localisation Literacy? The New Competence of the Digital Age

Digital products are everywhere today, from smartphones to games consoles, from news sites to banking applications. Making those products work in different languages and cultures, however, is an invisible, technical and many-layered process. Localisation literacy is the ability to understand, name and manage that invisible process.

Contents

The concept grows out of the translation scholar Miguel A. Jiménez-Crespo’s (2024) effort to make the field “familiar” to a broad readership. Like the “machine translation literacy” that has been discussed in recent years, localisation literacy sets out to establish a common language for specialists and for the people buying the work alike. In this article we look at what the concept is, where it comes from and whom it serves.

What is localisation literacy?

Localisation literacy is the level at which someone understands the basic concepts, stages and actors of the process by which a digital product is made usable in another language and cultural region. Being a translator is not enough; you also have to grasp how the text is separated from the code, what file format it is stored in, why it overflows on screen and who takes on which role.

This literacy is different from memorising individual tools. As Jiménez-Crespo (2024) stresses, because technologies change rapidly the real skill is “learning how to learn”. This year’s version of a localisation tool may be different two years from now; but fundamental principles such as the separation of text from function, the problem of context or the logic of quality assurance are lasting.

The concept is therefore less a field of expertise than a point of view: being able to see the process as a whole. Whether you are a translator working on a single string or a manager running a portal staffed by a hundred people, that view lets you do your job more accurately.

Where does the concept come from?

The term rests on an observation by Bert Esselink, one of the pioneers of localisation training. Esselink (2022) writes that the localiser has by now become “a real profession”, but that explaining the role to people outside the industry is still not easy. That “difficulty of explanation” points to precisely the need for a literacy.

Jiménez-Crespo (2024) deliberately likens the concept to the debate on “machine translation literacy” in order to fill this gap. Bowker and Buitrago Ciro (2019) had argued that using machine translation consciously is a social skill. When the same logic is carried across to localisation, it becomes clear that the process is a subject that needs to be understood not only by technical teams but by a wide circle of people.

In short, the concept is not a new technology; it is an effort to make a practice that has been going on for decades more accessible. Localisation was born in the software industry in the 1980s, but for a long time it remained a “black box” understood only from inside the industry.

Why is localisation “not familiar”?

Localisation works very differently from translation for print. A printed text is translated sentence by sentence, in linear fashion. The texts of a piece of software, by contrast, sit scattered through source files as strings; the user navigates by choosing their own path. This is why the process stays “invisible” to anyone looking in from outside: the finished product runs smoothly and the labour behind it goes unnoticed.

Another difficulty is that the work involves many actors. Translators, localisation engineers, project managers, testers and developers work together on a project. The boundaries between these roles are often blurred. Someone looking in from outside struggles to see the difference between “translation” and “localisation”.

The scale varies enormously as well. One person can set up the small website of a restaurant in a tourist area, while large portals such as Amazon or Google involve hundreds of participants. This diversity makes a single “correct” definition hard to arrive at and makes the literacy all the more necessary.

The core components of the literacy

Localisation literacy is not a single piece of knowledge but several layers that complete one another. The table below summarises those layers and what each of them is good for.

Component	What does it cover?	Why is it needed?
Conceptual	Localisation, locale, GILT, internationalisation	Establishes a common language and reduces misunderstanding
Technical	Source files, the text-code separation, the problem of context	Distinguishes what is to be translated from what must not be touched
Procedural	Workflow, stages, quality assurance, testing	Makes the schedule and the budget realistic
Cultural	Adaptation, target audience expectations	Makes the product feel right to the local user

These layers work together. Someone equipped with technical knowledge alone falls into cultural traps; someone who knows only the culture cannot work out why the file has broken. Literacy means seeing all four layers well enough and being able to connect them.

Who needs it?

The audience for the concept is not translators alone. Usability specialists cannot know which cultural conventions apply in the target region without consulting localisers. Developers notice a cultural problem only once a localiser has pointed it out. Product managers, for their part, need this literacy in order to understand where the process is getting stuck.

The buyer of translation is on the list too. A buyer who understands the process delivers the right source file, sets a realistic deadline and defines the quality expectation clearly. That brings down both the cost and the rate of rework.

To understand the different service needs at organisational level you can look at our translation services page, and for detailed explanations of the concepts you can browse our knowledge centre.

Its relationship with machine translation literacy

The two concepts are related but not the same. Machine translation literacy focuses on knowing when, how and with what risks to use neural translation engines. Localisation literacy takes in machine translation but deals with the whole adaptation cycle, which is a great deal broader than that.

Esselink (2022) notes that the biggest change in localisation processes over the past twenty years has been the move to machine translation post-editing (MTPE). Cloud-based continuous localisation and the arrival of large language models have since been added to it. The two literacies are consequently becoming more and more intertwined; each feeds the other.

Even so, the order of priority is clear: using the tool correctly is part of understanding the process as a whole, not the whole of it. Knowing where the text an engine produces will sit is possible only through localisation literacy.

How is localisation literacy acquired?

This skill is acquired step by step rather than in a day. The sequence below offers a practical framework for someone starting from scratch.

1. Learn the basic concepts: tell localisation, locale, internationalisation and the GILT chain apart.
2. Examine how the text of a digital product is separated from the code, working through a sample source file.
3. Practise on a small project: contribute to the translation of an open-source application.
4. Observe the quality and testing stages; see how a defect is reported.
5. Get to know the team roles and map each actor’s place in the process.

These steps give substance to the principle of “learning how to learn”. The aim is not to memorise every tool but to lay a foundation that lets you grasp a new one quickly when you meet it.

Common misconceptions

A few widespread misconceptions surround this concept. The first is to equate localisation literacy with “knowing how to program”. The aim, though, is not to write code but to grasp the relationship between text and code and the process as a whole. A localiser is not expected to know as much about programming as a developer; but they are expected to understand the technical constraints.

The second misconception is to suppose that this literacy is useful only to large companies. In reality, someone running a small business’s website single-handed needs the same basic concepts. Literacy does not become unnecessary as the scale shrinks; only the way it is applied becomes simpler.

The third misconception is to take the subject for something that can be learned once and then finished with. Because technologies keep changing, the literacy too is a skill that has to be kept up to date. A solution that works today may be out of date within a few years; learning therefore has to be continuous.

The Türkiye context

In Türkiye, localisation literacy is a young field for the industry and for institutions alike. Translation departments have added localisation courses to their curricula relatively recently; there is therefore a marked difference among graduates between those who have a firm grasp of the conceptual framework and those whose experience is limited to translation alone.

The features of the Turkish language make this literacy more important still. Its agglutinative structure causes words to grow longer in translation, and text overflow in interfaces is common. Turkish is also a relatively low-resource language compared with resource-rich languages such as English or Spanish, which means machine translation output has to be checked more carefully. A team that understands the process anticipates these risks from the outset.

On the corporate side, regulations such as KVKK add a legal layer to the localisation process. Which cloud service user data is processed on is a question a buyer who grasps the process should be asking from the start. This article is for general information and is not legal advice.

What does this mean for you?

If you are on the buying side of translation or localisation, understanding the process comes straight back to you as a saving. Knowing what will be translated, which file will be delivered and how quality will be measured reduces both surprises and rework.

1. Keep your project’s source files ready and in order; scattered text pushes the cost up.
2. Decide in advance which sections are to be localised; translating everything is not always necessary.
3. Ask your supplier to set out not only the translation but the quality assurance and testing steps as well.
4. Allow for the fact that the process has many stages when you draw up a realistic schedule.

If you would like to plan a project along these lines, you can tell us what you need through our quote form and work through scope and budget with us in an advisory role. The aim is not to sell to you but to help you ask the right questions.

Frequently asked questions

Does localisation literacy require a certificate?

No. It is not a certificate but a level of understanding of concepts and processes. It develops step by step through courses, guides and hands-on projects.

Are localisation literacy and machine translation literacy the same thing?

No. Machine translation literacy focuses on using a tool correctly; localisation literacy is a broader framework covering the entire adaptation cycle of a digital product.

Does a company that buys translation need this concept?

Yes. A buyer who understands the process sets a realistic budget and schedule, delivers the right file and defines the quality expectation clearly; this brings the rate of rework down.

Is localisation literacy only for translators?

No. Developers, product managers, marketers and usability specialists also produce fewer errors once they understand the process, and communication between teams becomes easier.

Sources

• Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge (Chs. 1-2).
• Esselink, B. (2022). “Localization: A profession in transition.” Multilingual/industry publication.
• Bowker, L. & Buitrago Ciro, J. (2019). Machine Translation and Global Research. Emerald Publishing.