[sword-devel] Synodal versification & IBT modules?

John Austin gpl.programs.info at gmail.com
Tue May 14 03:44:27 MST 2013

On 05/13/2013 06:41 PM, Костя Маслюк wrote:
> Prov.13.26 Prov.18.25 Dan.3.34-100 - is not correct, but i also got
> mistaken: Dan.3.24-3.90 *Prov.13.14* Prov.18.8

Thanks Kostya for pointing this important discrepancy out. I looked into 
this and have learned something new that has serious implications to 
verse mapping, and to our discussion about the SynodalP v11n:

You are right about which verses are considered deuterocanonical 
according to the Russian Synodal translation. However, the new 
translations which use the Synodal verse system, all of which exclude 
its deuterocanonical material, simply pull out the deuterocanonical 
verses and then renumber the verses in consecutive order. This makes 
these chapters versified just like KJV. So this is totally reasonable 
and to be expected, and is what IBT's translations which I checked have 

But, this also means that those new translations which utilize the 
Synodal verse system, but which exclude the Russian Synodal's 
deuterocanonical material, REQUIRE A DIFFERENT MAP than the Synodal map. 
You are right that this may have important implications as to the need 
for a SynodalP v11n.

Here's an example. These are the two maps for the book of Daniel (all 
chapters which are not listed are identical in both left and right v11ns):

KJV <=> Russian Synodal MAPPING
Dan 3:1-23   = Dan 3:1-23
non-existant = Dan 3:24-90
Dan 3:24-30  = Dan 3:91-97
Dan 4:1-3    = Dan 3:98-100
Dan 4:4-37   = Dan 4:1-34

KJV <=> Russian Synodal Protestant MAPPING
Dan 3:1-30 = Dan 3:1-30
Dan 4:1-3  = Dan 3:31-33
Dan 4:4-37 = Dan 4:1-34

IBT is currently using the second mapping above for ALL its Synodal 
texts. This means that IBT's mapping is incorrect when it is used on the 
Russian Synodal text in Prov.13, Prov.18, and Dan.3, Dan.4.

This need for TWO MAPS for a single v11n (Synodal) is news to me. This 
would complicate future v11n mapping strategies, because it seems we 
would need to somehow identify each Synodal module as needing either the 
"Russian Synodal" map or the "SynodalP" map.

OR... would it be simpler and more correct to do away with what I 
previously proposed for lastChapterPresent() and lastVersePresent() and 
instead create a second v11n for Synodal?

I'm thinking that these complications are indicating that a second 
Synodal is the right answer in the end. Although this v11n may be used 
by more than "Protestants", so perhaps Synodal2 would be more correct? 
Actually I believe that this is exactly the approach that Paratext 
offers- different Synodal verse systems to choose from.


> 2013/5/13 John Austin <gpl.programs.info at gmail.com
> <mailto:gpl.programs.info at gmail.com>>
>     On 05/13/2013 05:34 PM, Костя Маслюк wrote:
>         No need to introduce new functions because last chapter would be
>         always
>         calculated via getChapterMax().
>     I think that getChapterMax returns the maximum chapter in the verse
>     system. But we still need something like lastChapterPresent to
>     return the maximum chapter present in the module (which may be less
>     than what getChapterMax returns).
>         Here is list of *difficult cases* of deuterocanonical content in
>         Synodal
>         v11n
>         Dan.3.24-3.90 Prov.14.13 Prov.18.8
>         Here deuterocanonical text is inside of chapter... In text without
>         deuterocaninical content we would have a hole, if we fill hole
>         we got
>         v11n mappings mismatch until the rest of chapter.
>         + i didn't checked last verses across the Bible, such cases
>         exists at
>         least in Proverbs, but those are easy to process.
>         Deuterocanonical Chapters
>         Dan.13 Dan.14 Ps.151
>     Besides the deuterocanonical books, the following should be the
>     compete list of all that is considered deuterocanonical in the
>     Synodal v11n. All these verse segments represent either entire
>     chapters which are located at the end of their book, or else are the
>     end portion of a chapter.
>     <div type="x-Synodal-non-canonical"__><verse
>     sID="Josh.24.34-36"/><verse eID="Josh.24.34-36"/></div>
>     <div type="x-Synodal-non-canonical"__><chapter
>     osisID="Ps.151"><verse sID="Ps.151.1-7"/><verse
>     eID="Ps.151.1-7"/></chapter></__div>
>     <div type="x-Synodal-non-canonical"__><verse
>     sID="Prov.4.28-29"/><verse eID="Prov.4.28-29"/></div>
>     <div type="x-Synodal-non-canonical"__><verse
>     sID="Prov.13.26"/><verse eID="Prov.13.26"/></div>
>     <div type="x-Synodal-non-canonical"__><verse
>     sID="Prov.18.25"/><verse eID="Prov.18.25"/></div>
>     <div type="x-Synodal-non-canonical"__><verse
>     sID="Dan.3.34-100"/><verse eID="Dan.3.34-100"/></div>
>     <div type="x-Synodal-non-canonical"__><chapter
>     osisID="Dan.13"><verse sID="Dan.13.1-64"/><verse
>     eID="Dan.13.1-64"/></chapter><__/div>
>     <div type="x-Synodal-non-canonical"__><chapter
>     osisID="Dan.14"><verse sID="Dan.14.1-42"/><verse
>     eID="Dan.14.1-42"/></chapter><__/div>
>         *Correct amount of verses*
>         Frontend should always show correct amount of verses and
>         chapters, so i
>         should always check existence of chapters/verses before display
>         selection dialog. Another thing, that BibleTime Mini use
>         Model-View-Controller pattern and i need to know exactly how many
>         entries module contain. If it is ok to iterate with hasEntry()
>         across a
>         chapter, iterate across the module will be slow. Scope-feature
>         would be
>         good thing here, or alternative new Synodal v11n that consist of
>         canonical content only. And third solution module-supplied-v11n
>         feature
>         - that was discussed earlier.
>         *Need canonical only Russian module*
>         As here was said in Russia deuterocaonical material is not
>         considered as
>         Godly-inspired, but useful for reading. And most of Russian
>         Bibles (more
>         than 90%) published without this material. I really would like
>         to avoid
>         new readers from this material to avoid confusion.
>         Blessings
>         _________________________________________________
>         sword-devel mailing list: sword-devel at crosswire.org
>         <mailto:sword-devel at crosswire.org>
>         http://www.crosswire.org/__mailman/listinfo/sword-devel
>         <http://www.crosswire.org/mailman/listinfo/sword-devel>
>         Instructions to unsubscribe/change your settings at above page
>     _________________________________________________
>     sword-devel mailing list: sword-devel at crosswire.org
>     <mailto:sword-devel at crosswire.org>
>     http://www.crosswire.org/__mailman/listinfo/sword-devel
>     <http://www.crosswire.org/mailman/listinfo/sword-devel>
>     Instructions to unsubscribe/change your settings at above page
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

More information about the sword-devel mailing list