Update a Translated Series Bible: Reuse Aligned Segments—or Re-translate the Changed Passage?

A sentence comes back from the memory with a perfect score and the wrong person's name in it.

That is not the software malfunctioning. The memory was asked whether this exact source sentence had been translated before. It had. Nobody asked whether the sentence still belongs to the same character, still sits in the same argument, or still does what the show now needs it to do.

So the working rule for a bible update is narrow enough to actually follow: reuse an approved translation when the wording still does the same work in its new place. Where part of that work has changed, revise that part. Where structure, register or implication has moved, hand the passage back to a translator and let it be translated again. A match value describes retrieval conditions. It is not a judgment about meaning, and it is not approval.

The rest of this is about reaching that judgment without wasting the translator's week: keeping a baseline you can name, repairing the alignment before you trust anything it returns, reading each candidate match against both its old and new surroundings, and then reading the finished target as a document rather than a stack of accepted segments.

A note on the passage below. It is invented for teaching—a fictional series, The Ferry House, and a fictional character entry about a fictional ferry office. It has not been aligned, matched or reviewed in any tool, and no translator has seen it. The target-language side is shown as an English back-translation so the decisions stay legible to readers who don't share the pair; in a real update, that wording belongs to a translator competent in the language. What I can point to about software behaviour comes from memoQ's own documentation for version 12.5, checked in September 2026: the page on double-context matches and the page on the alignment editor. Those pages describe retrieval mechanisms. They say nothing about whether any particular translation should be reused.

Name the baseline before you align anything

Alignment will accept whatever two documents you hand it and present them as corresponding. Whether they correspond is your claim, not the tool's.

Four things belong in the record, written down where the next person can find them:

• Which source revision the approved target was made from.
• Who reviewed each side, and what that review covered. Sign-off on the episode outlines is not sign-off on the character entries; a story editor's pass on the source is not a target-language review.
• Anything changed in the target after that sign-off. A file with a corrected name or a fixed typo is no longer the file that was approved, even when the change was trivial. Record it rather than relitigate it in six months.
• The terminology decisions the pair depends on: character names, place names, forms of address, kinship terms.

The last item does the most work, because most of the difficult reuse decisions in a bible update turn on a term rather than a whole sentence. "Her uncle" becoming "her brother" is a one-word source edit with a long tail: it changes how two characters address each other, which words the target uses for relative age, and every synopsis line that repeated the old relationship. If the terminology list is thin, you will be making terminology decisions during the update, which is the worst possible moment to make them, because by then you'll be making them one segment at a time.

Repair the alignment before you rely on anything it returns

Here is the invented pair. The entry for Neve, as approved, four source paragraphs and their approved target:

Note two things the target does that the source doesn't. It names Neve where the source says "she," and it names Sandor where the source says "he," because the target language punishes ambiguity that English tolerates. And the target file runs 1, 2, 4, 3: the translator put the quotation before the ledger line, for the rhythm of the passage, and that order was approved.

Now run a positional alignment over those two files. Nothing about the pairing looks wrong, because each paragraph is a single sentence of similar length. The result is a clean four-link set with two links swapped:

Nothing has gone wrong in the software. The aligner had no way to know that the reordering was deliberate and approved, so it matched by position. The damage is that any memory built from these links now pairs the ledger sentence with the river quotation's target text—and pairs the quotation with the ledger line. The next person to revise the ledger sentence will be handed a 100% match containing a quotation about a river.

This is what the alignment editor is for. Paired documents can be aligned in LiveDocs, the links and the segment structure can be corrected by hand, and confirmed links can be exported to a translation memory. Two cautions follow. First, the alignment and the memory are not the same store: fixing links in LiveDocs does not silently fix a memory already exported from them. Second, and this is reasoning rather than documentation, a memory carries whatever the links said when it was built, so the correction should reach the memory you are actually querying before anyone treats its output as an approved pairing.

Insertions behave the same way. A target paragraph with no source counterpart leaves a gap, and every link after the gap shifts. That is not a small blemish to tidy later; it means the matches you are reviewing are answering a question about the wrong sentence.

Read the match beside the old context and the new one

The documentation distinguishes segment text from the context a match carries. Text-flow context means the neighbouring segments also matched. Identifier context means the segment or entity identifiers lined up. A plain exact match means the words are the same and the surroundings were not part of the match—and a segment can still come back as a match when context is missing entirely. None of these labels tests story meaning. A high value is a retrieval statistic, not a percentage of correctness, and not a permission.

So put the retrieved wording between its old neighbours and its new ones, and ask four questions before you ask anything about style.

Who is speaking, and who is being named. In the revised source, Neve's entry gains two lines near the end:

Neve takes the night desk alone in February. She keeps the night radio on until the last boat is in.

That second sentence is character-for-character what Maren's entry said in the approved source. It comes back as an exact match, and the approved target for it reads: Maren leaves the night radio on until the last boat comes in. Fluent, approved, and now attached to the wrong woman, because the target named her. This is the case that gives the article its opening line, and it is worth noticing how the trap is sprung: the target's habit of naming referents, which the translator adopted to prevent ambiguity, is exactly what makes the error visible. A reader catches it in one glance. A reviewer working through a match list at speed may not.

What the names and pronouns attach to now. The word "she" in Neve's entry currently has one antecedent. If a revision inserts a second woman into the paragraph, every reused "she" in the target needs re-reading, even where the source text is untouched.

Which fact changed. The source sentence She works for her brother, Sandor, who owns the boat is one word away from the approved version, so it scores as a high fuzzy match rather than an exact one. What comes back is the approved target: Neve works for Sandor, her mother's brother, who owns the boat. The translator had disambiguated a term the target language leaves open, and the revision has just falsified the disambiguation. Reuse here produces a confident sentence containing a relationship that no longer exists anywhere in the show—in a document whose entire job is to tell other people who these characters are to each other.

Whether the sentence still has the same job in the paragraph. A line that opened an entry may now close it. A line that set up a joke may now sit after the punchline. This is the question that catches moved blocks, and it cannot be answered from the match value at all.

Retain, revise or retranslate—and record which

Three outcomes, and the criteria can be stated plainly.

Retain when the segment text is unchanged, the referent is unchanged, and the sentence does its old job in its new position. Neve's first line qualifies.

Revise when one bounded element has changed and the consequences can be followed to the end. The kinship clause is the model case: the target's her mother's brother is replaced, the clause who owns the boat survives, and the translator checks whether the target's forms of address for Sandor elsewhere in the bible also assume an uncle and a niece rather than a brother and a sister. That check is not optional. In a language where address depends on relative age and kinship, the word Neve uses for Sandor is itself a decision, and the decision has just changed.

Retranslate when structure, register or implication has moved enough that repairing the old wording would preserve a shape the passage no longer has. The night-radio sentence is close to this: its tail survives, its subject does not, and the honest description of the work is "rebuilt," not "revised." Cases further along—a paragraph that has become dialogue, a formal synopsis line that has become a joke—should go to a translator with the old target visible and no expectation of salvage. Reuse exists to save needless repetition. It is not a pressure to keep an elegant line that has stopped fitting.

Then write the note. One or two lines per decision, in the file where the decision will be read:

2 — Source now "brother." Retrieved target still says "mother's brother." Replaced the kinship clause; kept "who owns the boat." Checked the address forms in the synopsis and outline, updated both. 6 — Exact match against Maren's line. Target names Maren. Rebuilt the subject clause for Neve; kept the closing phrase.

Notes like these are what make the next revision cheap. Six months from now, nobody will be able to reconstruct why a segment reads the way it does from a match value alone.

One more outcome deserves a name, because it is not a match result at all: reuse by editorial choice. The revised source gives Maren the river line as an echo of Sandor's—"The river keeps its own accounts," Maren says, and nobody writes it down. The quotation should probably use the approved target wording verbatim, because the echo is the point. That is a decision about the show, made by a person, and it should be recorded as a decision rather than as an accepted match.

Read the revised target as a continuous document

Segment-level acceptance does not add up to a reviewed passage. Assemble the entry and read it through.

Neve (revised target, back-translated)

1. Neve runs the ferry office all year, even in the weeks when nobody crosses. (retained)
2. Neve works for Sandor, her brother, who owns the boat. (revised)
3. "The river keeps its own accounts," Sandor says, and Neve writes the sentence down. (retained; third, as in the approved target)
4. Sandor keeps the accounts in a paper ledger; he does not trust the software. (retained after alignment repair)
5. Neve takes the night desk alone in February. (new)
6. Neve leaves the night radio on until the last boat comes in. (rebuilt)

Three things surface only at this level. Paragraphs 2 and 4 both name Sandor, and side by side the repetition reads flatter than it did in the separate paragraphs the translator originally wrote—so one of the two names probably comes out. The entry now closes on paragraphs 5 and 6 instead of the ledger line that ended the approved target, so the closing beat changes from Sandor's bookkeeping to Neve's night routine. And the echo in Maren's entry only works if the quotation matches word for word, which means the two entries have to be checked against each other rather than each against its own source.

Keep a version trace while you do this. Every changed passage in the revised target represents a particular source version, and if a source change lands after you've begun, the trace is how you find the segments that were built on the old one.

Then look outside the entry. If Sandor is Neve's brother, the change propagates into the synopsis, the character description and any episode outline that repeated the relationship—and into the target's term for brother wherever that term already appears. A shared altered fact has to read the same way in all the sections that carry it, which is a continuity job, not a retrieval job.

The record

Ordered by the revised source, with each passage's place in the revised target beside it.

Two of those six decisions came from a match value. Four came from reading the passage. The highest-scoring item in the list was also the one that would have put Maren's name into Neve's entry, and the only thing that caught it was a translator looking at what the sentence said.

That is the whole argument for keeping the alignment in good repair. Not that it will decide anything for you, but that when you decline a match you know exactly what you are declining, and when you accept one you know which approval you are borrowing and under what conditions it was granted.

Frequently asked questions

What does a high match score actually tell you?

It describes retrieval conditions, not meaning, correctness, or approval. A segment can come back as an exact match and still carry the wrong person's name, because the memory was asked only whether the source sentence had been translated before.

Why repair alignment before trusting matches?

Positional alignment can pair wrong segments when approved target paragraphs were reordered. A memory built from those links then carries the wrong pairing, and fixing links in LiveDocs does not silently fix a memory already exported from them. The correction must reach the memory being queried.

What baseline belongs in the record?

Which source revision the approved target came from; who reviewed each side and what that review covered; any target change after sign-off; and terminology decisions such as names, places, forms of address, and kinship terms. The terminology list does the most work, because many difficult reuse decisions turn on a term rather than a whole sentence.

When should a passage be retained, revised, or retranslated?

Retain when segment text, referent, and the sentence's job in its new position are unchanged. Revise when one bounded element changed and its consequences can be followed—for example, replacing a kinship clause and checking address forms elsewhere. Retranslate when structure, register, or implication has moved enough that repairing old wording would preserve a shape the passage no longer has.

Why read the revised target as a continuous document?

Segment-level acceptance does not add up to a reviewed passage. At document level, repeated names may read flat, a closing beat may have moved from Sandor's bookkeeping to Neve's night routine, and a cross-entry echo only works if the quotation matches word for word. It also reveals what a changed relationship propagates into synopsis, character description, and outlines.

Further reading

• Build a Searchable Script Concordance for a Series Bible — Read this when a changed term or relationship must be traced across synopsis, outlines, and character entries before you can trust the update.
• Write a Commercial That Can Travel Across Languages Without Losing the Idea — Read this when an approved line survives retrieval but not the target language's idiom, and you need to brief a local writer rather than freeze the sentence.
• A Film’s Joke Depends on Its Language. Translate the Words—or Rebuild the Joke? — Read this when a changed passage has become a joke or a language-dependent effect, to separate explaining the old scene from rebuilding it.