Skip to content
Digital Scholarly Editions

To build a parallel-text edition, transcribe each text independently, segment both into comparable units (usually sentences or verses) with stable xml:ids, then record the correspondence between segments as standoff links in TEI — a <linkGrp> of <link> elements, kept separate from the texts themselves. Get a machine-assisted first-pass alignment, correct it by hand where the texts diverge, and render the result as linked side-by-side columns. The alignment, not the transcription, is the scholarly heart of this kind of edition.

What problem does a parallel-text edition solve?

It lets a reader see two related texts in correspondence: an original beside its translation, a Latin source beside a vernacular gloss, or two recensions of the same work. The value is not in the texts individually — those may exist already — but in the explicit, verifiable mapping between their parts. A good parallel-text edition turns "these are related" into "this sentence corresponds to that one", which is a citable scholarly claim.

How do I structure the source files?

Keep each text whole and self-contained, then express alignment as a separate layer. This standoff approach means you can revise the alignment without touching either transcription:

xml
<!-- text A, segmented -->
<seg xml:id="a1">In the beginning was the Word.</seg>
<seg xml:id="a2">And the Word was with God.</seg>

<!-- text B, segmented -->
<seg xml:id="b1">Im Anfang war das Wort.</seg>
<seg xml:id="b2">Und das Wort war bei Gott.</seg>

Every segment that might be compared gets an xml:id. That id is the anchor the alignment links to.

How do I record the alignment?

Use a <linkGrp> of <link> elements. Each <link> joins two (or more) segment ids with its @target:

xml
<linkGrp type="translation">
  <link target="#a1 #b1"/>
  <link target="#a2 #b2"/>
</linkGrp>

Because the links are standoff, you can store them in a third file pointing into both texts. This keeps a clean separation: text A, text B, and the editorial alignment between them are three independent, individually-revisable assets.

What alignment granularity should I choose?

This decision governs both effort and usefulness. Match it to what your readers actually compare.

GranularityEffortBest for
ParagraphLowQuick reading comparison
Sentence/verseMediumMost translation editions
ClauseHighClose stylistic analysis
WordVery highLinguistic/lexical study

Sentence or verse level is the workhorse default: fine enough to be genuinely useful, coarse enough to finish.

Can I automate the first pass?

Yes — for translations especially, a sentence aligner gets you most of the way, then you correct it. Tools like hunalign or LF Aligner take two plain-text files and emit aligned pairs:

bash
# LF Aligner-style: produce a sentence-aligned TSV, then review by hand
lf_aligner textA.txt textB.txt --lang1 la --lang2 de > aligned.tsv
# columns: segmentA <tab> segmentB ; fix merges/splits manually

Treat the output as a draft. The aligner will misjudge non-literal passages, omissions, and reordered clauses — exactly the places where your editorial judgement adds value. Convert the corrected TSV into <link> elements with a short script.

How do I handle texts that do not line up?

Translators merge, split, omit, and reorder. Standoff links absorb this gracefully because a single <link> can connect one segment to several:

xml
<!-- one source sentence rendered as two in translation -->
<link target="#a5 #b7 #b8"/>
<!-- a source sentence with no counterpart -->
<link target="#a9"/>

Encoding the mismatch honestly is better than forcing a tidy one-to-one map. The interface can then show a one-to-many highlight, telling the reader the truth about how the texts relate.

How should it look to a reader?

Render the two texts in side-by-side columns and let the <link> data drive interaction: hovering or clicking a segment highlights its counterpart across the gutter. A modest XSLT-to-HTML build plus a few lines of JavaScript reading the link targets gives you synchronised highlighting and scrolling. Keep it static where you can — the alignment is precomputed, so no server is required to deliver a responsive comparison view.

Key Takeaways

  • A parallel-text edition's scholarly value is the explicit alignment between texts.
  • Transcribe each text independently; segment both with stable xml:ids.
  • Record correspondence as standoff <linkGrp>/<link>, separate from the texts.
  • Choose alignment granularity (sentence/verse is the usual default) by research need.
  • Use sentence aligners (hunalign, LF Aligner) for a first pass, then correct by hand.
  • Handle divergence with one-to-many links rather than forcing one-to-one maps.
  • Deliver as static, linked side-by-side columns with synchronised highlighting.

Frequently Asked Questions

What is a parallel-text edition?

A parallel-text edition presents two or more related texts side by side — typically an original and a translation, or two versions — aligned so readers can compare corresponding passages directly. The alignment between segments is the core scholarly contribution.

How are the two texts aligned in TEI?

Each segment is given an xml:id, and the correspondence is recorded with a <linkGrp> of <link> elements (or the @corresp attribute) connecting matching segments. The alignment data is separate from the text, so you can change it without re-editing either side.

What granularity should I align at?

Align at the smallest unit your readers compare — usually the sentence or verse, sometimes the clause. Word-level alignment is powerful for linguistic study but costly; paragraph-level is cheap but coarse. Match the granularity to the research question.

Can alignment be automated?

Partly. Sentence aligners like hunalign or LF Aligner produce a first pass for translations, and you correct it by hand. Automation saves time on bulk text but never replaces editorial judgement at difficult or non-literal passages.

How do I display a parallel-text edition?

Render the two texts in side-by-side columns with linked highlighting, so selecting a segment on one side highlights its counterpart. The <link> correspondences drive this interaction, usually via XSLT or a JavaScript viewer.

What if the texts diverge in structure?

Use one-to-many and many-to-one links. A <link> can connect one segment on one side to several on the other, handling cases where a translator merges or splits sentences. Standoff linking keeps these mismatches manageable.