[sword-devel] Synodal versification & IBT modules?

John Austin gpl.programs.info at gmail.com
Wed May 15 18:55:37 MST 2013




On Tue, May 14, 2013 at 5:40 PM, Peter von Kaehne <refdoc at gmx.net 
<mailto:refdoc at gmx.net>> wrote:

    A decent "Scope" implementation has advantages for partial Bibles,
    of which we have some and will get more. The mapping could be
    directed in a conf entry - Syn2KJV, SynP2KJV etc.


Yes, by adding another .conf entry, the mapping could be correctly 
distinguished. But then lastChapterPresent() and lastVersePresent() 
would need to be provided and used by front-ends in order to build 
correct chapter and verse lists etc.

I just did some research and Paratext does provide two Synodal verse 
systems: Orthodox, and Protestant. I wrote a script which tabulates and 
compares all Paratext and SWORD verse systems. Book order between the 
two Synodals is identical. The differences between the two Synodals are 
what's already been mentioned and are due to the excluded Orthodox 
deuterocanonical material:

Paratext Synodal Orthodox vs Paratext Synodal Protestant:

lastchapter-Dan: 14 != 12
lastchapter-Ps: 151 != 150

lastverse-Josh-24: 36 != 33
lastverse-Prov-4: 29 != 27
lastverse-Prov-13: 26 != 25
lastverse-Prov-18: 25 != 24
lastverse-Dan-3: 100 != 33

lastchapter-2Chr: 37 != 36 <-- SWORD Synodal follows Paratext Protestant 
here
lastverse-Ps-114: 8 != 9 <-- SWORD Synodal follows Paratext Protestant here

IBT's Synodal texts are all following Paratext Synodal Protestant.

John

    Peter

    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
    done.

    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.

    John

     >
     >
     > 2013/5/13 John Austin <gpl.programs.info at gmail.com
    <mailto:gpl.programs.info at gmail.com>
     > <mailto: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>
     > <mailto: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>
     > <mailto: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
     > 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
    Instructions to unsubscribe/change your settings at above page





More information about the sword-devel mailing list