Localisation 5 August 2026
Who Does What in a Localisation Team? The Industry’s Actors and Roles
Localisation is not a one-person job; it is a cycle that runs across professions. We explain what the localiser, the engineer, the project manager and the testing specialist each do, and where the roles overlap.
In a document translation the parties are obvious: you and the translator. In the localisation of software, an app, a website or a game, however, several kinds of expertise sit at the table, and some of them have had no training in languages at all. That makes the process complex, and it makes it just as hard to understand.
Contents
As the source book describes it, localisation is a broad, cross-professional cycle: localisers, localisation managers, localisation engineers and developers collaborate flexibly according to the type and scale of the project (Pym 2011, cited in Jiménez-Crespo 2024, p. 2).
This article takes the roles that make up a localisation team one by one, showing which decision belongs to whom and where the roles blur into one another. The aim is that, when you request a quote and when you run a project, you can put the right question to the right person.
Why is a localisation team so crowded?
Among the features that set localisation apart from other translation processes, the source book links two directly to the actors involved. The first is the management of large projects with many components and many languages. The second is collaboration on a scale not seen in other translation practices (Jiménez-Crespo 2024, p. 22).
The book also spells out who takes part in that collaboration: testing and quality evaluation specialists, localisation engineers and localisation managers. In other words, some of the people on the team never deal with the text at all; they work on the technical and procedural layer of the product.
The size of the team follows from the nature of the product. What is being localised is not a text but an interactive product used on a screen. Translating the text correctly is a necessary condition, but not a sufficient one: the product also has to be made to work in the target locale.
The localiser: the centre of the role
The source book uses the term “localiser” for participants who work on communicative, textual, cultural or accessibility-related matters within the localisation cycle (Jiménez-Crespo 2024, pp. 6-7). The definition is a broad one: someone who works only on game text falls under the heading, and so does someone who works on quality assurance and testing.
The book’s emphasis is this: an expert localiser is not simply a translator who specialises in digital text. Even when they deal only with textual assets, they are expected to know how digital products are developed, stored, rebuilt and retrieved.
To that is added a knowledge of how the team works internally. The localiser needs to know how to communicate with the other members of the team and who takes on which role. In Esselink’s 2022 formulation, the role is now a genuine profession, yet it is still not easy to explain to people outside the industry.
The localisation engineer: the owner of the technical layer
Localisation engineering is one of the earliest roles in the industry to separate out. In the early period, engineers and developers extracted the text strings embedded in the programming code into separate files and, once the translations came back, put them into the code again and tested them (Jiménez-Crespo 2024, p. 14).
Today much of this work is automated, but it has not disappeared. File format conversions, encoding problems, post-build errors and the display problems that arise in right-to-left languages all belong to this role. Even when the translation is flawless, a fault in this layer can render the product unusable.
How heavy the engineering load is depends on the type of localisation. According to the source book, web localisation calls for a lower level of technological and coding competence than software localisation does (Jiménez-Crespo 2024, p. 18). On the games side, audio and cinematic assets demand additional expertise.
The localisation manager: who keeps the cycle turning?
The localisation manager is responsible for planning projects with many components and many languages. Scheduling, budget, resource allocation and supplier coordination belong to this role. In the industry, translation and localisation providers mostly take on management, quality control and commercial work, while the translation itself is outsourced.
The role is not confined to coordination. The source book notes that an in-house localisation manager can make changes directly in their own language pair and can put linguistic errors right. The boundary between managing and doing, in other words, is porous as well.
The spread of cloud-based workflows has opened up the distance between management and translation. In the example the book gives, the management and engineering work for Spanish projects is carried out in the United States of America, while the translation may be done in Argentina, in Spain, or across a combination of several locations (Jiménez-Crespo 2024, p. 16).
The testing and quality assurance specialist
One of the features that separates localisation from translation is that it has quality assurance processes of its own. The industry calls this area localisation quality assurance, and it goes beyond the accuracy of the text: what is tested is whether the product works correctly in the target locale.
The questions the testing specialist asks are not linguistic ones. Does the text fit inside the button? Is the date format right? Does the interface layout break in a right-to-left language? Do the links go to the pages of the target locale? None of these questions can be answered by looking at the translation file.
In most projects the testing stage is the most underrated item of all. Yet some translation errors only become visible here, especially in the short strings that are worked on without context. Skipping testing means that the error is found by the user.
Another feature of this role is that it overlaps with the field of usability. The source book notes that usability specialists recommend conforming to the established conventions of the target locale, but that it remains open to debate whether usability testing alone is enough to establish which cultural conventions apply. This is the point at which the localiser’s knowledge of intercultural communication comes in.
Developers and the product team: the silent partner
Developers are the least discussed members of a localisation team. Yet internationalisation decisions, that is, making the product technically ready for localisation, are directly in their hands. Until those decisions have been taken, there is very little the localiser can do.
The source book leaves an open question here: if developers can only notice cultural problems after a localiser who is an expert in intercultural communication has identified them, should the localiser be counted as part of the development team?
In practice the answer to that question shows up in who is invited to the first meeting of the project. If the localiser is at the table while the architectural decisions are being made, a great many problems that would later be expensive to solve never arise at all. If they are brought into the meeting at the translation stage, the room they have to work in has already narrowed.
Another contribution of the product team lies in decisions about scope. Which content is separated out into source files, which screens are offered in which locale, and whether string notes are kept are all decisions made by this team. When they are made well, the cost of localisation falls noticeably.
Where do the roles blur into one another?
The source book accepts that there is an unresolved conceptual boundary between the “localiser” and the “localisation engineer” or the “localisation manager” as well. The lines are not sharp; the matter has to be thought through in terms of a prototype approach. Some professionals stand at the very centre of the definition, others at its edge.
There is a vagueness in the language of the industry too. The term “language specialist” is often used for translators; in job advertisements the same post is announced sometimes as translator, sometimes as localiser, sometimes as localisation specialist. This shows that role definitions vary from one organisation to another.
The table below summarises the core roles, their areas of responsibility and their decision-making authority.
| Role | Main responsibility | Typical output | When does it come in? |
|---|---|---|---|
| Localiser | Textual, cultural and accessibility decisions | Localised content | Once the source files are ready |
| Localisation engineer | Separating text from code, re-integration | A buildable localised version | At the start of the project and before delivery |
| Localisation manager | Planning, budget, supplier coordination | Project plan and delivery schedule | Throughout the process |
| Testing and quality specialist | Verification of the product in the target locale | Bug list and correction report | After integration |
| Developer / product team | Internationalisation and architectural decisions | A product ready for localisation | Before localisation begins |
The Türkiye context
In Türkiye, localisation roles are for the most part undifferentiated. In small and medium-sized software companies, engineering, management and testing all fall to the same person, and often to a software developer. It is a structure that works on small projects but seizes up as the scale grows.
The picture is similar on the education side. In translation studies programmes, localisation is usually taught as one heading within a translation technologies course, while engineering and testing competence is acquired in the industry after graduation. There is therefore a distance between the profile the industry looks for and the profile of the graduate.
The third point is the confusion of job titles. In job advertisements in Türkiye, the titles interpreter, translator, language specialist and localisation specialist are used interchangeably for the same post. It is safer to judge a job description by its list of responsibilities than by its title.
What does this mean for you?
When you buy a localisation service, knowing which roles the team in front of you covers is what makes quotes comparable. A provider that offers translation alone and a provider that also takes on engineering and testing are not describing the same job; the difference shows up not in the price but in the workload that stays with you.
- When you request a quote, set down in writing which roles will sit with the provider and which will stay with you.
- Name one person on your own side who is responsible for internationalisation.
- Write the testing stage into the contract as a separate deliverable.
- Agree from the outset on the channel through which linguistic errors will be reported.
- Even on small projects, appoint a single person to decide terminology and style.
These points close the gaps in responsibility before the project starts. We set out which roles we take on and to what extent on our services page, and we work out the team structure that suits your project with you through our quote form.
Frequently asked questions
Are the localiser and the translator the same person?
Not always. The source book states that there is an unresolved conceptual boundary between the two. Someone who deals only with transferring the text may be said to be translating; a localiser, however, must also know how the digital product is developed, stored and rebuilt. The term localiser covers this wider competence.
What does a localisation engineer do?
The localisation engineer runs the technical layer: separating text from the code and extracting it into source files, putting translated content back into the product, converting file formats and clearing post-build errors are all the work of this role. In the early period this work was done by hand, together with the developers.
What is the localisation manager’s job?
The localisation manager plans projects with many components and many languages, allocates resources and keeps track of the schedule and the budget. An in-house manager can make corrections directly in their own language pair or put linguistic errors right. The role, then, is not confined to coordination.
Are all the roles needed on a small project?
No. The source book states that collaboration is set up flexibly according to the type and scale of the project. Cloud-based solutions make it possible for a small website or game to be localised with the involvement of a single localiser. The roles do not disappear; they combine in one person.
References
- Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge, pp. 2, 6-8, 14, 16, 18, 22.
- Esselink, B. (2022). An assessment of the development of the localisation profession, cited in Jiménez-Crespo (2024).
- Gouadec, D. (2007). Translation as a Profession. John Benjamins.