On Tue, May 14, 2013 at 5:40 PM, Peter von Kaehne <ref...@gmx.net <mailto:ref...@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.i...@gmail.com
   <mailto:gpl.programs.i...@gmail.com>
    > <mailto:gpl.programs.i...@gmail.com
   <mailto:gpl.programs.i...@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@crosswire.org
   <mailto:sword-devel@crosswire.org>
    > <mailto:sword-devel@crosswire.org <mailto:sword-devel@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@crosswire.org
   <mailto:sword-devel@crosswire.org>
    > <mailto:sword-devel@crosswire.org <mailto:sword-devel@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@crosswire.org
   <mailto:sword-devel@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@crosswire.org
   <mailto:sword-devel@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@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Reply via email to