[sword-devel] Alternate Versification
dmsmith at crosswire.org
Sun May 3 20:00:43 MST 2009
On May 3, 2009, at 5:46 PM, Chris Little wrote:
> In general, I'm planning for the addition of versification systems
> to progress slowly and conservatively. So I've recommended to Troy
> that we release 1.6.0 with the current set (KJV(A), NRSV(A)
> supersets, Leningrad, & MT).
> The main reason for this is that a v11n definition must remain
> stable across releases or we will end up invalidating deployed
> content. Core versification systems have proven extremely difficult
> to identify and define. We could release an LXX v11n that matches
> Rahlfs' text, ignoring discontinuous chapters, sub-verses, chapters
> not beginning with verse 1, and all of the other ugliness. But that
> v11n definition wouldn't match the versification of translations of
> the LXX which we think of as using the LXX versification. The story
> is basically the same for the Vulgate, except that it's difficult to
> even identify which "Vulgate" represents the Vulgate v11n best since
> different editions have different v11ns.
> In defining v11ns, I want a minimum of two independent sources who
> define the same v11n (or I want to be able to identify which of the
> two is erroneous and how). (The exception to this is the Leningrad
> v11n, which for obvious reasons is defined from a single
> authoritative document.) The NRSV & NRSVA were defined from 3
> electronic sources and compared against the printed text. The KJVA
> was defined from 2 electronic sources and compared against 2 printed
> sources and the NRSVA v11n definition.
> Especially in a stable branch, we can't be defining and deploying
> untested data, so the addition of more v11ns is probably out of the
> question for 1.6.0. That's not to say that we couldn't release a
> 1.7.x or even a 1.6.1 with additional v11ns a couple weeks from now.
> Producing LXX-like, Vulgate-like, Original-like, and Russian Synodal
> v11n definitions are all priorities (in no particular order), just
> not for this release.
> With respect to the Russian v11n present in MK, I don't think it
> will be a candidate for inclusion. I would assume that the chapter &
> verse counts for the OT & NT books that it includes are correct, but
> it omits all books outside of the 66-book Protestant canon and those
> books it includes are in the Protestant order, rather than that of
> the Russian Synodal Bible. When we release a complete Russian v11n,
> it will be trivial for the MK developer to re-import his data and
> have it be usable (with the additional benefit of the book order
> being what more advanced users expect). I have two fairly reliable
> sources for the Russian v11n system and can verify against the canon
> definition from MK, so we can probably expect this in the next
> unstable release.
> Does that all sound reasonable?
I think so.
Just a thought, *based on too little knowledge*, and not for 1.6 but
later. Would it be of benefit to separate the v11n of the OT and the
NT and allow them to be combined via the conf?
Where the OT is KJVA and the NT is NSRV
Or even break out the apocrypha as a with a +:
Meaning the OT has the KJV OT verification, but with Vul additions.
I.e. Books in Vul OT, but not in KJV OT are appended to KJV OT.
Thanks for all your work on this!
> David Haslam wrote:
>> Bible translations for Central Asia generally follow the same
>> scheme as the Russian Synodal Translation (RST), as is exemplified
>> in the
>> SWORD based Holy Bible program (MK) developed for the Institute of
>> Translation (IBT) for Russia/CIS. Moreover, most Slavic language
>> translations (as used in Eastern Europe) follow the same
>> I would like to make a strong plea that the first set of alternate
>> versifications to be bundled should include this scheme.
>> This would demonstrate our support for the work of IBT, and show
>> that we are
>> moving in the direction of co-operation and collaboration in the
>> work of
>> bringing the Gospel to the region of Central Asia and other
>> countries that
>> were once part of the former Soviet Union and its hegemony.
>> MK already supports both RST and KJV versifications (seamlessly)
>> but is not
>> easily scalable to more than two schemes.
>> For further information about MK, see
>> The MK source code is available on-line at the same site. -- David
> sword-devel mailing list: sword-devel at crosswire.org
> Instructions to unsubscribe/change your settings at above page
More information about the sword-devel