Localisation 5 August 2026
What Does a Localisation Project Manager Do? The Conductor of the Process
Taking a product into dozens of languages is not a one-person job. We look at the work of the localisation project manager, who ties the scope, the kit, the schedule and the team together.
Moving a piece of software, a mobile app or a website into dozens of languages at once is not the work of a single translator. Behind it stand engineers, linguists, terminologists and testers, and the person who brings them all onto the same schedule is the localisation project manager. This role is the invisible yet most decisive layer of translation: a well-managed project flows quietly, while a badly managed one falters even with the most gifted translator on it.
Contents
This article sets out what the role actually does, which stages it is responsible for, and how it works out in the practice of a single-office agency in the Türkiye market. Our source is the academic literature that describes the localisation process step by step; the framework we offer is unembellished and close to the work as it is really done. In defining the role we do not fix on one job title, because different companies call the same job by different names.
Who is the localisation project manager?
The localisation project manager is the person who plans a translation project from beginning to end, gathers the resources and sets up the workflow. The job is not to translate the text personally; it is to make sure the translation is completed smoothly and predictably. In Esselink’s classic formulation, every linguistic, technical and managerial step should be clearly defined before the project starts. The manager produces that definition and makes sure everyone is looking at the same scope.
This person usually stands between the technical and the linguistic. They are neither a pure translator nor a pure software developer. They talk to the client when the scope is being set, to the engineer when the files are being prepared, and to the linguist when terminology decisions are made. A good manager is someone who can see in advance how the presence, the absence or the partial completion of each step will affect the translator’s work.
The name of the role changes from company to company. In some places a “localisation manager” is responsible for collecting all translatable assets and setting up the workflow, while on game projects a “localisation coordinator” sits between the translators and the language service providers. Large organisations also have separate titles such as engineering manager, desktop publishing manager and account manager. What they have in common is that at some point the process is held together by a single responsible person; otherwise dozens of languages and files become tangled.
Before the project is accepted: scope and preparation
Every project begins with clarifying the scope with the client. Which sections will be translated, which languages will be targeted, what level of localisation is wanted? More often than not it is only the priority pages of a website, rather than the whole of it, that are taken into the target market. These decisions depend on the budget, on the expected return and on the size of the market. The manager closes off these uncertainties at the very start of the project.
The typical steps of the preparation stage follow one another, and skipping one proves expensive at later stages:
- Defining the scope and the requirements with the client.
- Setting up the localisation environment and preparing a management plan.
- Collecting the translatable assets (text, audio, images, source files).
- Identifying the adaptations needed for the target market.
- Analysing the text and producing cost and time estimates.
- Distributing the tasks across the team and drawing up the test plan.
Preparing the localisation kit
One of the manager’s concrete outputs is the localisation kit. It holds everything the linguist needs in order to work without losing sight of the context: source files, images, screenshots, instructions, delivery formats and, where necessary, proprietary software and earlier versions of the product. The quality of the kit feeds straight through into the quality of the translation, because a translator who cannot see the context is left to guess.
The style guide and the termbase go into the kit as well. That way the same term is used consistently in every corner of the project and the brand voice is preserved from language to language. How we build terminological consistency is something we deal with in a separate article; the point to underline here is that these documents need to be ready before the work is handed out, not afterwards.
Preparing the kit is also an exercise in foresight. Separating the text from the code, breaking images that contain embedded text into layers and marking the elements that are not to be translated all happen at this stage. The manager clears away in advance the technical traps that would otherwise confront the translator: placeholders, shortcut keys, narrow areas that carry a risk of text expansion. The better this groundwork is done, the fewer queries and corrections there are during the translation stage. A poorly prepared kit makes every error found later in the process more expensive.
Schedule, budget and resource planning
Text analysis is usually carried out by automated systems, and the cost estimate comes out of it. The manager plans time and budget by looking at the word count, the reusable matches and the number of languages. Translating the textual content is the most expensive step in the process, and where a large number of languages is involved that cost grows quickly. An error in planning turns into the most visible outcome a project can have: delay.
Resource planning covers not only who works when, but also which job goes to which specialist. A creative marketing text and a repetitive interface string are not entrusted to the same person or to the same method. Directing the right work to the right person is one of the manager’s most valuable contributions.
Budget planning is an area in which counting words is anything but simple. A password or a letter-and-digit combination may not count as a translatable word, whereas in technical texts abbreviations and code names are included in the count. In languages such as Chinese, Korean or Thai, where the word boundary has to be calculated in characters, invoicing becomes more complicated still. If the manager does not settle these distinctions at the outset, the argument about the invoice after delivery wears down both the client and the team.
A bridge between the roles in the team
The localisation ecosystem is a crowded one: account managers, engineers, linguists, terminologists, reviewers, testers and in-country reviewers. The project manager is the bridge that carries information between these roles. In game localisation the function is most often taken on by a localisation coordinator, who checks that bug reports are understood correctly by the engineers.
The bridge does not carry traffic in one direction only. A cultural problem noticed by the linguist has to reach the developer, and a technical constraint found by the engineer has to reach the translator. When this feedback loop is broken, the errors are left to the end of the process, the point at which putting them right costs most.
Among these roles there are also consultants and in-country reviewers. Consultants who specialise in a particular market or field brief the team on cultural and regulatory matters. In-country review is different from correction: it focuses on technical consistency, on completeness and on the agreed terminology. The manager plans at which point and with which question these specialists are brought into the process. A badly timed review causes both delay and unnecessary cost. A well-timed one catches the most critical risks before the product reaches the market.
Quality, delivery and automation
The manager is also the planner of the quality assurance (QA) process. It is the manager who sets the test schedule, the bug reporting tool and the quality framework to be used. After delivery, tasks such as setting up a continuous localisation repository, adapting promotional materials and preparing keywords for search engines come into play.
Some steps are being automated today; so-called lights-out autonomous project management even aims to generate content automatically on user demand. Even so, decisions such as scoping, cultural risk assessment and the client relationship remain with people. The table below summarises the responsibilities of the role at three main stages.
| Stage | The manager’s responsibility | Role worked with |
|---|---|---|
| Preparation | Scope, resource gathering, kit | Account manager, engineer |
| Core translation | Task allocation, terminology | Linguist, terminologist |
| Testing and delivery | QA plan, bug tracking | Tester, engineer |
The difference between managing waterfall and continuous flow
The shape of the management changes with the workflow of the project. In the waterfall model the stages follow one another: design finishes, development begins, then come localisation and testing. Here the manager is responsible for handing the output of one stage over to the next cleanly. If a problem is found at the end of the process, the fix is both expensive and slow, because the developers may already have moved on to other work.
In continuous and agile models, by contrast, the work never stops. Small pieces of content are sent to repositories, the translation system pulls them in, and the localised text is integrated into the product continuously. In this setting the manager runs a never-ending flow rather than a one-off delivery. The roles, the schedules and the quality checkpoints are designed accordingly. The same person may have to work with two different mindsets on the same project.
The Türkiye context
In Türkiye, localisation work is mostly carried out by small teams from a single office. In an agency such as ours in Ankara Kızılay, project management exists not as a separate department but as a discipline that holds the process together. Even on a small scale, defining the scope in writing, establishing terminological consistency from the outset and settling the delivery format are the habits that save the job.
The agglutinative structure of Turkish and its free word order make text length and placeholder behaviour unpredictable in interface strings. On projects that target Turkish it is therefore particularly important for the manager to give the translator context and screenshots. For content that falls under KVKK, how the source files and the client’s data will be handled must be planned from the start. This article is for general information and is not legal advice.
What does this mean for you?
If you are the party buying translation, a good project manager is invisible insurance for you. They lift your request out of scope ambiguity and bring the surprises to light at the beginning of the project. In practical terms, you can ask for the following steps:
- Set out in a written scope document which content will be translated.
- Ask whether there is a termbase and a style guide; if not, ask for them to be created.
- Agree the delivery schedule and the interim checkpoints in advance.
To put this framework in place on your next project, you can look at our localisation services and get in touch about scope and schedule through the quote form. Our aim is not to sell you something, but to make your work predictable.
Frequently asked questions
Is a localisation project manager a translator?
Not necessarily. The job is not to translate the text but to plan the translation process, gather the resources, set the schedule and coordinate the team. Knowing the languages is an advantage, but the real expertise is process management.
What does a localisation kit contain?
Source files, images, screenshots, the style guide, the termbase, instructions, the delivery format and, where necessary, earlier versions of the product. The aim is to let the linguist work with the context in view.
Is a project manager needed on a small project?
Where a small site is being handled by two people on a waterfall model, a separate manager may not be needed. As the number of languages and files grows, coordination becomes a speciality in its own right.
Will autonomous tools replace the project manager?
They automate some of the steps, but the decisions are still made by people. Work such as scoping, cultural risk assessment and client communication cannot easily be handed over to automation.
References
Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge (Chs. 3/4/5/9/12). · Esselink, B. (2000). A Practical Guide to Localization. John Benjamins.