Current situation
The parallel view displays multiple Bible translations side by side,
verse by verse, using a single versification system (the 1st parallel
module's) to drive the display. The code itself acknowledges this
limitation with an explicit comment:
// frankly, we're faking it here.
// we have potentially variable v11n among the parallel modules.
// but we must validate a key in some vaguely consistent manner.
// arbitrarily, we have picked the 1st.
// it's consistent, but very possibly wrong for all but the 1st.
The problem
Some Bible translations follow different versification systems. A
concrete example: Jeremiah 30 in the Hebrew (MT) tradition (KJV,
FreCrampon, Vulgate...) corresponds to Jeremiah 37 in the Greek (LXX)
tradition (LXXNA28, FreLXXGiguet...). When displaying these side by
side, the parallel view shows Jeremiah 30 for both, which means the
LXX module displays the wrong chapter entirely.
This affects any pair of modules where versification differs, including:
- MT vs LXX (many chapters in Jeremiah, Ezekiel, Daniel, Psalms...)
- Protestant canon vs Catholic/Orthodox deuterocanonical books
- Any module using a non-standard versification system
SWORD already has the tools
SWORD's VerseKey class supports multiple versification systems and
provides mapToVersification() to convert a key from one system to
another. The versification name for each module is available via
SWModule::getConfigEntry("Versification").
Possible approaches
Approach 1 — Per-module key mapping (recommended)
For each module in the parallel display loop, convert the current key
from the control module's versification to the target module's
versification before fetching the text:
VerseKey mappedKey;
mappedKey.setVersificationSystem(target_v11n);
mappedKey.mapToVersification(&sourceKey, source_v11n);
backend_p->set_module_key(mod, mappedKey.getText());
This is the cleanest approach but requires:
- Detecting each module's versification at display time
- Handling the variable verse count per chapter across versifications
- Updating the chapter header to show the correct chapter number
per module
Approach 2 — Verse count driven by union of all versifications
Compute the maximum verse count across all parallel modules for the
current chapter/book, and for each module fetch whatever verse exists
at that position (or blank if none). This handles differing verse
counts but is more complex to implement.
Approach 3 — Optional mapping toggle
Add a user toggle in Preferences or in the parallel toolbar to enable
versification-aware display, defaulting to the current behavior for
backward compatibility.
Current situation
The parallel view displays multiple Bible translations side by side,
verse by verse, using a single versification system (the 1st parallel
module's) to drive the display. The code itself acknowledges this
limitation with an explicit comment:
The problem
Some Bible translations follow different versification systems. A
concrete example: Jeremiah 30 in the Hebrew (MT) tradition (KJV,
FreCrampon, Vulgate...) corresponds to Jeremiah 37 in the Greek (LXX)
tradition (LXXNA28, FreLXXGiguet...). When displaying these side by
side, the parallel view shows Jeremiah 30 for both, which means the
LXX module displays the wrong chapter entirely.
This affects any pair of modules where versification differs, including:
SWORD already has the tools
SWORD's
VerseKeyclass supports multiple versification systems andprovides
mapToVersification()to convert a key from one system toanother. The versification name for each module is available via
SWModule::getConfigEntry("Versification").Possible approaches
Approach 1 — Per-module key mapping (recommended)
For each module in the parallel display loop, convert the current key
from the control module's versification to the target module's
versification before fetching the text:
VerseKey mappedKey; mappedKey.setVersificationSystem(target_v11n); mappedKey.mapToVersification(&sourceKey, source_v11n); backend_p->set_module_key(mod, mappedKey.getText());This is the cleanest approach but requires:
per module
Approach 2 — Verse count driven by union of all versifications
Compute the maximum verse count across all parallel modules for the
current chapter/book, and for each module fetch whatever verse exists
at that position (or blank if none). This handles differing verse
counts but is more complex to implement.
Approach 3 — Optional mapping toggle
Add a user toggle in Preferences or in the parallel toolbar to enable
versification-aware display, defaulting to the current behavior for
backward compatibility.