Continuous Localisation or the Waterfall Model? A Comparison of Two Workflows

Localisation runs to one of two basic rhythms. Either the stages advance in sequence, each one beginning as the previous one ends, or the work flows without interruption alongside the product. The first is called the waterfall model, the second agile or continuous localisation.

Contents

This choice is not merely a matter of how your supplier organises its own work. The model you work with determines how long updates take to go live, how you are invoiced and where quality control is carried out.

Below we compare the two models in terms of how they operate, what they cost and what they risk. The right answer ultimately depends on how fast your product changes; both models have their advantages when used in the right place.

How does the waterfall model work?

In the waterfall model the stages follow one another: planning, core localisation, integration, testing and post-localisation. No stage begins before the previous one is complete (Jiménez-Crespo 2024, p. 57). The structure is a scaled-up version of the translation-revision-publication sequence familiar from the translation industry.

The model’s greatest strength is predictability. The scope is known from the outset, the cost is calculated in one go and the delivery date is set clearly. In organisations where approval processes move slowly, that clarity is a significant advantage.

The model also makes quality control easier. You have the whole text in front of you at once, so you can assess consistency, register and terminology as a single body. With content that arrives piece by piece, that vantage point is hard to keep.

This is why the waterfall model is still the most efficient method for one-off jobs with clear boundaries. Localising a user manual, an annual report or a promotional catalogue calls for no other model. If the content does not change once it has gone live, setting up a continuous flow brings no return either.

The weak point of the waterfall model

The fundamental problem with this model is that errors are noticed late. If a problem only surfaces once it has travelled some way down the process, fixing it is both expensive and slow, and the fact that the developers have moved on to other work makes matters harder still (Jiménez-Crespo 2024, pp. 57-58).

The second problem is speed. If your product is updated several times a week, running a process that starts from scratch for every update is unsustainable. The localised version falls permanently behind and the user is left with the feeling of looking at two different products.

Third, if the source text changes while the process is under way, part of the work done is wasted. The waterfall model assumes that the source stays fixed; with digital products that assumption often fails to hold.

These weaknesses share a single cause: the model makes going back expensive. A problem found at the end of the chain has to be fixed by retreating several stages, and every date in the schedule slips while that happens. This is why the time set aside for preparation in the waterfall model, however wasted it may look, is the most profitable investment of all.

Simultaneous release and post-release localisation

The waterfall approach can be applied on two different timings. In the first, localisation is carried out while the product is being developed and all language versions go live at the same time as the original. The industry refers to this approach as “simultaneous release”.

In the second, localisation begins only after the original version has been completed and released. In software this approach is known as post-release localisation, and on the games side as post-gold localisation (Jiménez-Crespo 2024, p. 58).

The choice is a commercial one. Simultaneous release gives you an advantage in entering the market, but it means dealing with texts that change during development. Post-release localisation proceeds more calmly, at the price of appearing late in the target market.

Post-release localisation carries one further risk: because the product was finished with a single language in mind, technical obstacles are likely. When a right-to-left language is requested, or when text fields have been left at a fixed width, the job turns into redevelopment before it can become translation.

What is continuous localisation?

Agile and continuous approaches are methods in which solutions are developed iteratively and incrementally through the collaboration of self-organising teams (Bernal-Merino 2015, cited in Jiménez-Crespo 2024, p. 58). Localisation falls in with that rhythm as well.

In the agile model the work is done in short periods of fixed duration. In these periods, which may be a week, a day or even a few hours, a set amount of content is localised and delivered.

Continuous localisation is a subset of this and rests on the logic of continuous integration and continuous delivery. Small updates are localised, added to the product and released without pause, and the cycle can repeat several times a day.

In practice the distinction between the two approaches is a fine one. In the agile model a round of localisation follows a given development period; in the continuous model there is no separate round at all, and content flows as soon as it is ready. From a business point of view the difference lies in whether the project has a beginning and an end.

How does continuous flow work technically?

Broadly, it works like this: developers push new code and new text to the version repository. The translation management system watches that repository through links known as connectors and pulls in the new content (Jiménez-Crespo 2024, p. 59).

The content pulled in is first compared with the existing translation memory. Parts that have been translated before are filled in automatically and only the new text goes to the translator. In some workflows machine translation also comes into play, completed by human post-editing.

Once the translation is finished, the content is written back to the repository, placed into the product and released. The user sees this as an update. When the whole chain is set up to run automatically, human intervention is confined to the translation and approval steps.

The most fragile link in this chain is the connectors. When your content management system is updated or your file structure changes, the link can break silently and new content may never reach translation at all. The flow therefore has to be monitored regularly and to have someone responsible for it.

The two models compared

The table below compares the two models under the headings that matter from a business point of view.

Criterion	Waterfall	Continuous
Delivery rhythm	One delivery, planned	Continuous, small packages
Cost forecast	Clear from the outset	Periodic and variable
Fixing errors	Late and expensive	Early and cheap
Whole-text quality control	Straightforward	Has to be planned separately
Infrastructure required	Limited	Repository, connectors, management system
Content it suits	Documents, campaigns, reports	Apps, websites, software

The point to watch when reading the table is this: in none of the rows does one model beat the other outright. The choice comes down to which weakness you can live with.

The hidden costs of the continuous model

Continuous localisation has a price that does not show. The work revolves around small volumes, large numbers of files, a growing range of content types and urgent requests. That structure demands flexibility, and not every supplier is suited to the rhythm.

The second cost is loss of context. The translator receives a fifty-word package and has no idea which screen it will appear on. Where no contextual information is supplied, the risk of inconsistency rises markedly compared with the waterfall model.

The third is the management burden. If it is not defined at the outset who approves what in a continuous flow, an approval traffic builds up that repeats several times a day. The way to lighten that burden is to set automatic approval rules for low-risk content.

The fourth is the problem of measurement. In a continuous flow quality is formed over time rather than in a single delivery, so regular sampling is needed in place of the classic pre-delivery check. Reviewing randomly selected screens once a month is the most practical way of spotting problems before they grow.

Which one suits your project?

The decision turns less on the type of product than on how fast it changes. The following questions make the choice easier:

1. How many times a month does your content change?
2. Does the localised version have to be updated at the same time as the original?
3. Are your texts held in a structure that keeps them separate from the code?
4. Is the person who gives approval reachable every day?
5. Does invoicing small packages create problems on the accounting side?

A mixed route is possible too. Running interface texts through a continuous flow while handling marketing and legal content in planned rounds is a common and well-balanced solution.

Even if your answers point to the continuous model, you do not have to make the switch in a single step. Trying it first in one language and on a limited set of content, to see whether the flow really works, is a safer route than moving every language to the new arrangement at once.

The Türkiye context

A large share of corporate buyers in Türkiye still work on a one-off order logic: a file is sent, a delivery is received, an invoice is issued. Continuous localisation does not fit that habit; it calls for a different contractual structure, such as a monthly service fee or a periodic package.

Invoicing small packages is a separate matter. Since issuing a separate invoice for a fifty-word update is impractical, agreeing at the outset on periodic bulk invoicing and a minimum volume threshold puts both sides at ease.

The structure of Turkish also calls for extra care in the continuous model. Because suffix agreement and word order depend on context in texts that arrive as short packages, unnatural phrasing appears whenever the translator is not told which screen the text belongs to. Whole-text reviews at regular intervals make up for this.

What does this mean for you?

The workflow model is a decision that comes before translation quality. Choose the wrong model and even the best translator will be working late or without context. These steps make the choice easier:

1. Count your content updates over the past six months; establish your rhythm from data rather than guesswork.
2. If you are moving to a continuous flow, concentrate approval authority in a single person.
3. Have the invoicing arrangement written into the contract separately.
4. Plan a whole-text review round once every three months.

You will find our periodic and one-off ways of working on our pricing page. If you would like to assess together which model suits you, simply tell us how often you update on our quote page.

Frequently asked questions

Is continuous localisation necessary for every product?

No. Setting up a continuous flow for a catalogue site that is updated once or twice a year creates needless complexity. The model earns its keep in proportion to update frequency; if content changes several times a week, the benefit is clear.

Is the waterfall model no longer in use?

It is. For documents, campaign copy, annual reports and one-off product launches it is still the clearest model. The problem lies not in the model itself but in applying it, mistakenly, to a product that changes constantly.

Does quality drop in continuous localisation?

Not automatically, but the risk rises. Because the text arrives in small pieces, the translator cannot see the whole. The way to reduce that risk is to supply contextual information, keep the term list up to date and carry out whole-text reviews at regular intervals.

What infrastructure is needed to move to this model?

Texts held separately from the code, a version repository and a link to a translation management system are enough. The real difficulty is organisational rather than technical: it has to be defined at the outset who will give approval and when.

References

Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge, pp. 57-59. · Bernal-Merino, M. (2015). Translation and Localisation in Video Games. Routledge, p. 279. · Beck, K. et al. (2001). Agile Manifesto, agilemanifesto.org.