Localisation 5 August 2026
Localisation Team Roles: Who Does What on Your Project?
A localisation project has many roles beyond the translator. Knowing what the manager, the engineer, the terminologist, the tester and the in-country reviewer do lets you put the right question to the right person.
From the outside it is easy to take localisation for a one-person job: a file goes out, it is translated, it comes back. In real projects several kinds of expertise come into play, and the quality of the result depends on how well those roles are defined.
Contents
The literature groups the roles in the localisation ecosystem into six clusters: management, engineering, core localisation, quality control and testing, consultancy, and additional tasks (Jiménez-Crespo 2024, p. 62). The list is not a fixed one; it grows along with the industry.
Below we set out the roles in a localisation team, what each of them produces and which question you should put to whom. The aim is not to draw an organisation chart; it is to make sure you know who to turn to when something stalls on a project.
Why are there so many roles?
Localising a digital product cannot be done with a single skill. The person who writes the text and the person who edits the code, the person who tests the screen and the person who knows the habits of the target market all hold different expertise. The number of roles is not confusion; it is the natural division of the work.
The number of roles also varies with the project. A non-governmental organisation’s website can be localised by two people, whereas on a multilingual application an engineer, a manager, a translator and a tester all work at the same time (Jiménez-Crespo 2024, pp. 56-57). As a project grows, the roles separate out.
On small projects the roles merge, but they do not disappear. One person can be both manager and proofreader; the problem is when one of these jobs is given to nobody at all. In practice the job most often left without an owner is testing, and the price is paid after go-live.
The practical upshot for you is this: asking which roles are included in the price is really asking which jobs will be done. A quotation that looks cheap is usually a missing role.
The roles that manage the process
The account manager, or business manager, runs the relationship with you. They gather the requirements and negotiate the contract and the commercial terms. They do not go into technical detail, but they are responsible for passing your requests on to the team accurately.
The localisation manager, by contrast, sits at the centre of the work. They collect the assets to be localised, set up the workflow, prepare the localisation kit and document the requirements of the testing process (Jiménez-Crespo 2024, p. 62). If you are looking for a single point of contact on a project, this is usually the person.
On large projects this role is supported by coordinators. The coordinator handles the daily contact with translators, suppliers and the testing team, and checks that bug reports are understood correctly by the engineers. The communication load on the manager is spread out this way.
The engineering manager and the desktop publishing manager are responsible for narrower areas: one for the order of the technical processes, the other for the page layout and print preparation of the final product.
The roles on the engineering side
The localisation engineer is the technical owner of the project. Theirs is the side with the authority to change the code; they extract the content to be localised, put it back once translation is finished and fix the faults reported during testing (Jiménez-Crespo 2024, p. 63).
This role has another, less well known duty: supplying context to the translator. Taking screenshots, documenting where each piece of text appears and stating the character limits are the engineer’s job. Without that information, translation rests on guesswork.
Some projects also have tools and language engineers. Maintaining the translation memories, connecting machine translation engines and setting up automated checks fall to these people. On small projects this work collects on the localisation engineer.
The critical point in business terms is this: a localisation project without engineering support gets stuck once the translation is finished. Who holds this resource has to be settled before the project starts.
The roles in core localisation
The translator, or localisation specialist, is the person who produces most of the text. They may be in-house or freelance. Their job is not translation alone; giving an opinion on intercultural communication and checking subtitle and voice-over scripts also belong to this role.
The terminologist secures the consistency of terms across languages. Large technology companies prepare termbases for their products and open them up to their developers (Jiménez-Crespo 2024, pp. 70-71). On mid-sized projects this work usually falls to the translator.
The proofreader, or final reviewer, goes over the text before it is placed into the product. They catch language errors, deviations in style and inconsistencies in terminology. When this step is skipped, the errors carry through to the testing stage and cost more to put right.
The division of labour between these three roles is also an indicator of your quality expectations. A single-person process is fast and cheap; a process seen by two pairs of eyes lowers the error rate.
Testing and quality control roles
The tester checks whether the localised assets work correctly once they have been placed into the product. Do the buttons work, do the links go to the right page, does the text fit its box? The findings are passed on as bug reports.
The linguistic testing lead, for their part, checks consistency in each language. They verify whether the same function is called by the same name on different screens and whether the terms follow the equivalents agreed in the contract, and they compile the reports.
The quality control engineer is responsible for the final functional test. They answer the questions of whether the localised version of the product is technically sound and whether the installation and update flows work.
What these three roles have in common is that their output is invisible. When the work is done well nobody notices; when it is not done, the first to notice is the user.
For the testing team to be able to work, access to the product is needed. Without a working copy of the localised version, or at least screenshots, testing turns into a limited check carried out on spreadsheets. Who will grant that access, and when, is a detail that has to be discussed at the start of the project.
Consultancy, in-country review and other roles
The localisation consultant is someone with expertise in a particular market or field. Before the project begins, they give an opinion on the target market’s expectations, its competitive conditions and its legal requirements. They usually come in at the points of decision rather than throughout the project.
The in-country reviewer, on the other hand, is an expert living in the target market and often looks at matters of regulatory compliance. The definition most often quoted for this role is clear: review or validation is not the same thing as proofreading; reviewers should focus on technical consistency, completeness and the terms that have been agreed (Esselink 2000, p. 15).
On projects that carry audio content, sound engineers and voice artists join the team as well. Promotional videos, help content and voice assistants all call for these roles.
On projects that run on volunteer contributions, the role of community manager has emerged. This person organises the flow of volunteer translators, checks the quality of the contributions and keeps the community going.
Which roles should stay with you and which with the supplier?
You do not have to buy in every role. In practice, keeping two of them inside the company makes things easier: term approval and ownership of the brand’s language. The person with the last word on these two should be on your side, because both amount to commercial decisions.
Work such as translation, proofreading and linguistic testing, by contrast, is both cheaper and more flexible to buy in. These roles do not require permanent staff; when demand fluctuates, it is possible to scale up and down.
The grey area is engineering. Localisation engineering usually stays inside the company because it requires product knowledge, but it is common to take outside support on file formats and tool connections. What matters here is putting the limits of authority in writing.
You can use this test when deciding: a role that requires deep knowledge of your product works better inside, while a role that requires language and process expertise works better outside.
Roles, outputs and points of contact
The table below summarises the roles you will come across most often and which of them is in direct contact with you.
| Role | Output produced | Contact with you |
|---|---|---|
| Localisation manager | Plan, kit, schedule | Direct and continuous |
| Localisation engineer | Extracted and reinserted files | On technical questions |
| Translator | Localised text | Usually indirect |
| Terminologist | Term list and usage notes | At the approval stage |
| Tester | Bug report | Before delivery |
| In-country reviewer | Compliance and consistency report | In critical markets |
The question to ask as you look at the table is this: which of these rows is left unanswered in the quotation you have received? Every unanswered row is a job you will end up taking on yourself later.
The Türkiye context
A large share of the translation businesses in Türkiye work on a small scale, and the roles collect in a handful of people. The same person can be both project manager and proofreader. This is not necessarily a bad thing; but it does raise the risk that steps such as testing and in-country review are quietly skipped.
With documents that call for sworn translation, the picture changes. Under notarial legislation the signature of a translator holding a certificate of oath is required; this is a separate role with no counterpart in digital localisation projects. When you expect both processes from the same team, the scope has to be separated clearly.
When Turkish is the target language, the in-country review role proves more valuable than expected. Because of the agglutinative structure, only someone who uses the language daily can confirm that an expression sits naturally in an interface. The most common problem in Turkish text produced by teams abroad is not grammar but naturalness.
What does this mean for you?
Knowing the roles in a localisation team does not oblige you to manage the project; it lets you put the right question to the right person. The following steps will make your work easier:
- Name a single point of contact on the project and ask for every decision to pass through them.
- Settle who holds engineering support at the first meeting.
- Appoint someone on your own side to approve terminology.
- Put in writing who will carry out testing and in-country review.
You can see which roles fall within the scope of our service on our translation services page. If you would like to work out together which roles your project needs, you can reach us through our contact page.
Frequently asked questions
Are all these roles needed on a small project?
No. On small projects the roles merge; one person can be both manager and proofreader. What matters is not that the role sits with a particular person but that the job is not left without an owner. The job left without an owner is usually testing.
Are in-country review and proofreading the same thing?
No. Proofreading looks at errors of language and expression. In-country review focuses on points such as technical consistency, completeness and adherence to the terms that have been agreed, and is usually carried out by an expert working in the target market.
Does the terminologist have to be a separate person?
No. On small and mid-sized projects the translator can carry out the terminology work. On multilingual, multi-channel and long-running projects, however, giving terminology its own owner raises consistency markedly.
Who should my point of contact be on the project?
It should be a single person. That person is usually the localisation manager or the account manager. Multiplying the points of contact leads to the same question coming back with different answers and to decisions going unrecorded.
Sources
Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge, pp. 62-64. · Esselink, B. (2000). A Practical Guide to Localization. John Benjamins, p. 15. · Bernal-Merino, M. (2015). Translation and Localisation in Video Games. Routledge.