Localisation 5 August 2026
The TEP Process: Why the Print Translation Model Did Not Fit Digital
The TEP process is the classic translation model designed for print publications. We examine why this model did not fit digital products and how it gave rise to localisation.
Before digital products appeared, the translation industry had a long-established workflow. The TEP process, that is the Translate-Edit-Publish model, was for decades the standard method governing the translation of print publications. Once it met digital products, however, the model proved inadequate.
Contents
According to Jiménez-Crespo (2024), the fact that the TEP process could not readily be applied to digital products is one of the main reasons why localisation emerged as a separate mode of translation. This article examines what TEP is, why it did not fit digital and what came in its place.
What is the TEP process?
The TEP process consists of three consecutive steps: translation, editing and publishing. A text is first translated, then reviewed by a second specialist, and finally prepared for publication. This flow rests on a logic that has been at work for centuries in the translation of printed books, magazines and documents.
The basic assumption of TEP is that the text is linear. The text is read from beginning to end; the translator sees every sentence within its context. The publishing step means freezing the translated text in a fixed form: a book, a brochure.
In its own context this model is extremely efficient. The trouble is that digital products bear no resemblance at all to that linear, fixed structure.
Why are digital products different?
The digital revolution that came with the personal computer, the Internet and the Web gave rise to genres such as software, websites, video games and mobile applications. The way these genres are produced, developed and used is fundamentally different from print publications.
The text elements in a piece of software or a game do not sit sentence by sentence in a linear structure. They are mostly stored in resource files or embedded in the code. The user, for their part, does not read the text from beginning to end; they choose their own path, clicking and interacting as they go.
These three differences bring down the basic assumption of TEP. A text that is non-linear, scattered and interactive cannot be processed with a linear workflow.
Comparing TEP with the localisation workflow
Seeing the difference between the two models explains why localisation is a separate mode. The table below summarises the main differences.
| Dimension | TEP process | Localisation workflow |
|---|---|---|
| Text structure | Linear, sentence by sentence | Scattered strings, resource files |
| Direction of flow | One-way, sequential | Cyclical, parallel |
| Context | Visible within the text | Often missing, tested afterwards |
| Outcome | A fixed publication | A digital product that keeps being updated |
As the table shows, the two models belong to different worlds. Localisation runs steps such as preparation, engineering, translation, quality assurance and testing inside one another.
The problems created by the separation
In the early days, companies treated programming and translation as two separate consecutive steps. This was the logic of TEP carried across to the digital world, and it was problematic. The translated text could turn out longer than the space on screen, and culture-bound elements broke.
These problems produced two solutions: separating the text from the code into resource files, and planning localisation from the very beginning. This second principle laid the foundation of the GILT process.
You can find the conceptual background to this shift in our knowledge centre, and you are welcome to look at our translation services page for your corporate projects.
Is TEP still valid today?
TEP has not been abandoned altogether. For linear texts produced to be read, it is still the most suitable method. The translation of a report, a book or a legal document proceeds on TEP logic today as well.
The following steps help in establishing which model is the right one:
- Establish whether the text is linear or interactive.
- Check whether the text sits whole in one file or scattered in the form of strings.
- Anticipate whether the user will read the text or use it.
- Choose TEP if it is linear and the localisation workflow if it is interactive.
This distinction ensures that the right process is applied to the right job. The wrong model raises both the cost and the error rate.
The role of segmentation
One factor that deepens the difference between TEP and localisation is how the text is broken up. In print translation the text moves in its natural sentence flow, whereas in localisation the content is broken into strings. This fragmentation makes it harder for the translator to see the text as a whole.
Strings often appear far apart from one another on screen. A button label, an error message and a heading may sit side by side in the same file, yet the user meets them in different contexts. This does not square with the linear logic of TEP.
Localisation therefore needs extra tools and testing stages to bring the fragmented text back together. TEP has no such need, because the text is whole to begin with.
The problem of context loss
The greatest price of a non-linear structure is the loss of context. In the TEP process the translator sees what comes before and after a sentence, and builds the meaning within that context. In localisation the translator most often sees only a string cut off from everything around it.
This loss of context prepares the ground for errors. A word standing on its own, for instance, may offer the translator more than one meaning; which of them is right becomes clear only when its place on screen is seen. Such uncertainty is rare in TEP.
To make good the loss of context, localisation uses screenshots, explanatory notes and visual test environments. This extra layer is one of the fundamental differences between TEP and localisation.
Hybrid workflows
Real projects usually call for a mixture of the two models. A digital product may contain both linear texts (help pages, blog posts) and interactive elements (the interface, buttons). TEP and localisation then run side by side.
This hybrid approach requires the process that suits each content type to be applied to it. Linear content is handled on TEP logic, interactive content through the localisation workflow. Keeping the two apart raises efficiency as well as quality.
A good supplier therefore plans from the outset which part of a project falls under which model. Forcing a single model onto every kind of content usually leads to error.
The needs created by TEP’s failure to fit digital became clearer still with cloud-based workflows. From Web 2.0 onwards, content came to be produced and updated without interruption. Dynamic websites are refreshed regularly, and this requires localisation to run as a cyclical and continuous process. TEP’s logic of “translate, edit, publish and be done” cannot be squared with this never-ending flow of content. Continuous localisation is the answer to that new reality.
These cyclical models can also take in machine translation and crowdsourced contribution. Some large platforms, for example, keep adding content with volunteer participants and feed the translations back into the site. This works in an entirely different way from the one-directional, linear structure of TEP. The cloud makes it possible for clients, managers and translators in different countries to work remotely and at the same time. The process now moves through a distributed network rather than around a single desk.
Even so, it would be wrong to think that TEP has become entirely invalid. Print publications, legal documents and long texts produced to be read are still handled best on TEP logic. The problem is not that TEP is bad but that it is applied in the wrong place. The right tool is valuable when it is applied to the right job. Handling a digital product with TEP is as mistaken as forcing a book through a localisation workflow is unnecessary.
Getting this distinction right saves both time and money. Defining the nature of the job at the outset determines the rest of the process. Is it a linear, fixed text or a dynamic, interactive product? The answer to that question settles which model is applied. A good decision at the start makes the whole project more predictable.
The contrast between TEP and the localisation workflow in fact represents a major rupture in the history of translation. A profession that had worked for centuries on the linear logic of printed text came face to face with an entirely different structure within a few decades. That rupture explains why localisation was born as a separate mode of translation. A new medium demanded a new process.
This historical view also throws light on the decisions of today. Treating a digital product like a printed document means applying the logic of TEP in the wrong place. Conversely, pushing a simple document through a complex localisation workflow creates needless cost. The right approach is to apply to each piece of content the process that suits its own nature. That awareness protects efficiency and quality alike.
The Türkiye context
In Türkiye a great deal of translation work is still planned on TEP logic, which is natural in a market dominated by document translation. When digital products are involved, however, applying TEP logic directly to a piece of software or an application is a frequent mistake. Once website “translation” is handled like a document, the menu structure and the technical layer are overlooked.
The structure of Turkish sharpens the difference. Because the language is agglutinative, the translated text grows longer; in TEP this problem can be corrected at the publishing stage, whereas in an interactive interface text overflow is caught only by testing in context. In other words, for Turkish TEP’s editing step does not take the place of the testing step in the localisation workflow.
For the corporate buyer the practical upshot is this: defining the type of work correctly brings with it the right process and the right budget. Pricing a digital, interactive product as if it were document translation leads to both delay and rework later on.
What does this mean for you?
If you are buying translation, knowing whether your job calls for TEP or for a localisation workflow lets you set the right expectations. The distinction bears directly on delivery time and on quality.
- Determine whether your text is linear or interactive.
- For digital products, ask for a testing step and not translation alone.
- Know that TEP is enough for document translation; do not add needless process.
- Plan a schedule and a budget that suit the type of work.
If you are not sure which process your requirement calls for, share the details through our quote page and we will settle on the right model together.
Frequently asked questions
What is the TEP process?
TEP is the classic translation workflow designed for print publications, made up of the Translate-Edit-Publish steps. The text is processed linearly.
Why did TEP not fit digital?
Because the text of software and games is not laid out sentence by sentence in a linear structure. The strings are spread across resource files and the user chooses their own reading path.
Has TEP been abandoned altogether?
No. For linear texts produced to be read, TEP logic still holds. Interactive digital products, however, require a localisation workflow.
How does the localisation workflow differ from TEP?
Localisation involves parallel and cyclical steps such as preparation, engineering, translation, quality assurance and testing. TEP, by contrast, is linear and one-directional.
References
- Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge (Chs. 1-2).
- Dunne, K. J. (2006). Perspectives on Localization. John Benjamins.
- Esselink, B. (2000). A Practical Guide to Localization. John Benjamins.