Why Long Translations Come Out Inconsistent — and How to Fix It

The first two pages are excellent. By page twelve a character's name is spelled two ways, the formal address has quietly become casual, and a technical term you care about has three different translations. Nothing errored. Here is what is actually happening, and what to do about it.

This is the single most common complaint about machine-translating anything longer than an email, and it is almost always diagnosed wrongly. People assume the model got tired, or that the later material was harder, or that they picked a bad tool. Usually none of that is true. The drift is a structural consequence of how long text gets translated, and once you see the mechanism the fixes are obvious.

The one thing you need to know: the model has no memory of page one

Every translation model has a fixed working memory — a maximum amount of text it can hold in view at any moment. Think of it as a desk. A generous desk, but a desk: it fits a few thousand words, not a book.

So a long document cannot be translated in one pass. It gets split into pieces, and each piece is translated as its own separate job. This happens whether you do the splitting by hand or a tool does it for you. The consequence is the part that surprises people:

When the model translates chapter seven, it has no idea that chapters one through six exist. It is not remembering your document and losing the thread. It is seeing a page of text for the first time, with no context, and making a fresh decision about every ambiguous word on it.

That reframing explains everything. The model did not "forget" that you decided to render a name a certain way — it was never told. Each piece is a first encounter. Any word with more than one reasonable translation is re-decided from scratch, every single time, and the decisions do not have to agree.

The five things that drift, in order of how much they annoy people

1. Names and proper nouns

The worst offender, especially between scripts. A surname might be transliterated phonetically in one chunk and left in the original alphabet in the next. Place names with both a local and an international form alternate. In fiction this is genuinely disorienting — readers lose track of who is in the scene.

2. Formality and how people address each other

Many languages force a choice English does not: German du versus Sie, French tu versus vous, and the layered politeness levels of Japanese and Korean. English "you" carries none of this information, so the model infers it from tone. Given a chunk of clipped dialogue it may infer informality; given the next chunk of longer sentences it may infer the opposite. Two colleagues can shift from formal to intimate address and back within a single scene.

3. Domain terminology

A word that has an ordinary meaning and a specific one in your field is a coin-flip in every chunk. In a legal document "consideration" is a term of art; without context it translates as "thoughtfulness." Software "libraries," financial "securities," medical "presentation" — each will be right sometimes and wrong the rest of the time, and the errors read as fluent, correct prose.

4. Tense and narrative voice

Languages differ in how they mark time and aspect. A passage that is unambiguous in a full chapter can be ambiguous in a 900-word slice, and the model resolves the ambiguity independently each time. The visible symptom is a narrative that slides between past and present at chunk boundaries.

5. Pronoun gender

Translating out of a language with gender-neutral pronouns — Chinese spoken forms, Turkish, Finnish, Hungarian — into one that demands gender means the model must guess. It guesses per chunk. A character can change gender halfway through a document, and if you cannot read the source fluently you will not catch it.

Where the split happens matters as much as the model

Here is the part that is genuinely under your control, and that most people never consider.

If a document is cut into pieces, the cut points determine how much each piece makes sense on its own. Cut in the middle of a sentence and you have handed the model half a thought and asked it to translate it. It will produce something — machine translation almost never refuses — but the first clause of the next piece will also be translated as though it began a sentence. Both halves come out subtly wrong and the seam between them is visible.

This is exactly what naive splitting does. "Break every 1,000 characters" will land mid-sentence the overwhelming majority of the time, because sentences do not politely end on round numbers.

A good split does two things: it lands on a real boundary — a sentence ending, a line break, a paragraph — and it keeps the pieces reasonably even, so no chunk is so short it lacks context or so long it strains the working memory. The practical rule is to aim for a target size but move the cut to the nearest genuine boundary, rather than cutting at the target exactly.

There is one more detail with outsized consequences. When pieces are cut apart and the translations joined back together, the joining has to be lossless. If the splitting step trims whitespace at each cut — a very natural-looking thing for a program to do — then every space and line break between pieces vanishes, and the reassembled document has paragraphs run together and sentences without spaces between them. A tool that does this looks fine on short text and quietly mangles long text.

Six fixes that work with any tool

1. Build a term list before you translate anything

Twenty minutes here saves hours later. Go through the document and list every proper noun, every term of art, and every recurring phrase whose translation you care about. Decide the target-language rendering for each one now, while you are thinking about the document as a whole. This list is the single highest-leverage artefact in the whole process, and it is useful whether you fix things by find-and-replace afterwards or feed it to a translator.

2. Fix terminology in one pass at the end, not as you read

Do not correct terms while reading through the translation — you will miss occurrences and lose your place. Finish the translation, then take your term list and do one find-and-replace pass per term across the whole document. This is mechanical, fast, and catches every instance including the ones in sections you have not read yet.

3. Translate whole sections, not arbitrary lengths

If you are splitting manually, split at chapter or section breaks even when that makes the pieces uneven. Semantic units drift far less than arbitrary ones, because the material inside them is internally consistent — the same characters, the same register, the same subject matter.

4. Decide formality once, then enforce it

Before starting, decide whether the whole document is formal or informal. After translating, search for the markers — the formal and informal pronouns, the polite verb endings — and check for a mix. This is a five-minute check that catches the most jarring category of drift, and if you do not read the target language, it is worth asking someone who does to do only this.

5. Read the seams first

If you only have time for a partial review, review the boundaries. Errors cluster at the joins between pieces — a repeated sentence, a dropped one, a paragraph that starts mid-thought, a register that changes at the exact same point. Skim the paragraph on either side of each transition and you will catch a disproportionate share of the problems in a fraction of the time.

6. Use a bigger model for prose, not for volume

Model size helps most where judgement matters: nuance, idiom, register, sustained voice. It helps least on straightforward informational text. So do not automatically reach for the largest, slowest option because the document is long — reach for it because the document is subtle. A 200-page technical manual is often better served by a faster model plus a solid term list than by a slower one alone.

A review checklist for a long translation

Run this in order. It takes well under an hour for a book chapter and catches most of what a reader would notice.

• Search each name from your term list. Confirm one spelling throughout.
• Search each technical term. Confirm one rendering throughout.
• Check formality markers for a mix of registers.
• Read one paragraph on each side of every section boundary.
• Check that numbers, dates and units survived — these are silently mangled surprisingly often.
• Confirm paragraph breaks still exist where the source had them.
• Spot-check pronoun gender for each character if translating out of a gender-neutral language.
• Read the first and last page properly. They are the ones people judge you on.

What a tool can do for you here

Most of the above is human work that no software removes. But two of these problems are the tool's job, and you should not be doing them by hand.

Splitting is the first. If you are manually cutting a document into pieces, pasting them one at a time, and stitching the results back together, you are doing something a program does better and without losing a chunk somewhere in the middle. Seam was built around this specific problem: you paste the entire document, and it cuts at sentence endings and line breaks near a target size, preferring a real boundary over an exact length. You never see the pieces. There is no long-document mode to switch on and no character limit to work around.

Interruption is the second. A long document takes real time, and a process that loses everything when you close your laptop forces you to sit and watch it. Seam commits each passage as it finishes, so an interrupted job resumes from the first unfinished passage rather than starting over — you can stop it, close it, come back tomorrow.

Everything else on this page — the term list, the formality decision, the review pass — is yours, and it is where the difference between a rough translation and a good one actually lives.

Common questions