Translation rework is the cost that does not show up on the localization budget line. It shows up in sprint velocity, in translator throughput, in localization PM hours that look like overhead, and in user-facing quality that degrades when the rework cycle slips. Most teams undercount it by at least half, because they are counting completed translation units and not counting the units that were translated once, went stale, and were translated again.
The Rework Cycle
The rework cycle starts with a familiar sequence. A string is changed in code and submitted for translation. The translator picks up the job and produces an approved translation. Before that translation ships, a developer makes a follow-up change to the same string. The translation is now stale. The localization PM queues the string for re-translation. The translator handles it again.
In a manual localization workflow, this cycle is invisible. The TMS shows "submitted" and "completed" counts. It does not break out re-translations as a separate category unless you specifically instrument for it. So the cost accumulates without being measured.
The teams in our early-access program who instrumented for re-translation consistently found rates between 18% and 35% of completed translation units. That is 18-35% of your translation budget spent on strings that were already translated -- not improving quality, not covering new copy, but covering ground that was already covered.
Where the Cost Lands
The rework cost distributes across three parties, and each absorbs it differently:
Translators
Translators are paid per word or per unit in most arrangements. Re-translations count as new work. The translator sees a string, translates it, submits it. Three days later, the same string comes back with a slightly different source text. They translate it again. They may or may not be aware it was already translated -- TMS queue views do not always surface that history prominently.
Beyond the direct cost, frequent re-touch erodes translator engagement. Translators who repeatedly encounter strings they already handled -- strings where the change was minor and felt unnecessary -- develop a pattern of reducing attention to each unit. The rework cycle is one of the contributors to translation quality drift in agile products.
Localization PM
The localization PM absorbs the coordination overhead. They notice the stale translation, re-queue it, route it to the translator, review the result, and close the loop. For a small team this is a few messages and tasks. For a product with ten languages and an active development cycle, it is a sustained operational load that grows proportionally with development velocity.
This is the "localization PM as bottleneck" phenomenon. It is often attributed to process or resourcing problems, but in many cases the root cause is rework volume. The PM is not slow -- they are handling a volume of re-queue tasks that should not exist.
Release Quality
When rework volume is high and the localization pipeline is under time pressure, some re-translations do not happen before the release. The sprint ships. The English string has the updated copy. The German string has the version from before the follow-up change. The German user sees text that does not match what the English user sees, because the re-translation was not complete when the release cut.
This is the translation sprint gap that costs user trust. The cost is not visible on the localization budget. It is visible in the experience of the 40% of your users who are not reading English.
What Drives Rework Rate
Rework rate is a function of two variables: how often source strings change after they have been submitted for translation, and how long the translation cycle takes. If translation is fast (same-day), changes after submission are rare. If translation is slow (3-5 days), more changes land in the window before the translation completes.
The leverage is in reducing the translation window, not in asking developers to freeze copy earlier. Asking developers not to change strings after they are queued is asking them to stop doing normal development work. Reducing the window from 3-5 days to same-day or next-day means there is less time for changes to accumulate and less re-translation as a result.
The secondary lever is in queuing strategy. Under a batch queuing model -- queue strings at the end of the sprint, translate them all at once -- the window is the full sprint. Every string queued at day 1 has 10 days of exposure to follow-up changes. Under a continuous queuing model, strings are queued as soon as they are committed. A string committed on day 10 of the sprint has a one-day window.
Measuring Your Rework Rate
If you want to measure your current rework rate, the calculation is:
Count the number of translation units that were submitted, completed, and then re-submitted within the same sprint cycle. Divide by total completed translation units in the same period. That ratio is your rework rate.
If your TMS does not surface this directly, you can approximate it by querying translation history: units where the same key + locale combination appears more than once in a rolling 30-day window, with at least one "completed" state between appearances.
A rework rate above 15% is high enough to investigate. Above 25% indicates a structural problem in the translation queuing workflow that is worth fixing rather than accepting as normal.
The Structural Fix
The rework rate problem does not have a partial solution. You can reduce it incrementally with queuing discipline, but the structural fix requires treating localization as a continuous process rather than a batch process. Strings are queued immediately on commit. Translation cycles are as short as possible. Stale detection fires before the release cut, not after.
When those conditions are true, the window for source changes to land after a string is queued is narrow, the re-translation rate drops, the localization PM's coordination load decreases, and the release ships with current translations in all languages. The rework budget is freed up for new copy rather than old copy re-done.