<div dir="ltr"><div><div><div>> I would assume this requires a change to function signatures, so it's not going to appear in 1.7.x at all.<br><br></div>In your mouth it sound like that it going never appear in Sword. Patch only add parameter with default value to one public function. There is no problem to revert and make some work in private part of class so it will be absolutely abi compatible.<br>
<br>> I haven't looked at the code, but the idea of mapping between
versification systems (not versifications of particular translations but
versification systems, as we define them) is completely ridiculous.<br><br></div>I know that several translations could have different markup in some places even if they use same versification system in Sword, so it is impossible to provide perfect result on versification system level.<br>
<br>I just would like to highlight that there is no technical problem to make my solution to work on per translation level.<br></div><div><br>There is only one moment if you would like to pack with module only mapping data excluding versification data, it would be quite difficult because we need to add several exceptions in the code. In contrary if we pack versification data with mapping data in module we have uniform way that backend/frontend work with module whether it use built-in or module supplied versification.<br>
</div><div><br><div><br>P.S. Chris, your suggestions are always highly, very highly appreciated, let me know if you need more investigation or make other work, maybe i would help to advance this.<br><br></div><div><br>Blessings<br>
</div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014/1/16 Daniel Owens <span dir="ltr"><<a href="mailto:dcowens76@gmail.com" target="_blank">dcowens76@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
On 1/16/14, 3:50 PM, Chris Little wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 1/15/2014 3:51 PM, Daniel Owens wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I agree. From a strategic point of view, I think it makes sense to place<br>
a priority on mapping between KJV, NRSV, and Leningrad, but then LXX is<br>
important too. Even if it is only approximate, there are some places<br>
where it is very simple (most of the Psalms are offset by one chapter,<br>
for example), and when it can be done, accurate (though maybe not<br>
precise) parallel display should be sought after to make it easier for<br>
the user. It does not have to be perfect, and certainly such mapping<br>
does not need to reorder verses like the German Bible Society's Synopsis<br>
of the Gospels. The user just needs to see in a parallel display that<br>
the two Bibles are roughly lined up.<br>
</blockquote>
<br>
Sure, and the KJV, NRSV, and Leningrad can be mapped between with good accuracy. Furthermore, the data is readily available and there's no variability to account for or work around.<br>
<br>
Mapping between the LXX versification system and another versification is impossible because there's no single LXX versification. Specifically mapping between Rahlfs' LXX and a KJV/NRSV or MT/Leningrad versified translation will work fine (and the data for that is available). Applying the same mapping between Brenton's LXX translation and the KJV/NRSV or MT/Leningrad versified translation will fail spectacularly. The versifications of Rahlfs' and Brenton's LXXes, despite using the same versification system definition in Sword, have about as much in common as either of them and the KJV.<br>
<br>
So this reduces to the point I keep making: translation to translation mapping will work well-enough; system to system mapping (as they're defined in/by Sword) will not.<br>
<br>
The data for all the LXX editions & translations used to create Sword's LXX versification definition can be found at <a href="https://crosswire.org/svn/sword-tools/trunk/versification/lxx_v11ns/" target="_blank">https://crosswire.org/svn/<u></u>sword-tools/trunk/<u></u>versification/lxx_v11ns/</a> and everyone is welcome to do their own comparisons to see the wide variability of versifications among texts using the same versification definition.<br>
<br>
--Chris<br>
</blockquote></div></div>
I think in the flurry of emails I missed the distinction you were making between mapping between translations and mapping between systems. That is a useful distinction. I think I was hasty in reading you to be saying that all mappings were a ridiculous waste of time—who would want them? The answer many in the thread gave was, we all want them! I suspect we were talking about different things (though I could be wrong). I hope we can all agree that the end-user experience with parallel texts is something we want to improve.<br>
<br>
Having said that, mapping between the most important Bible modules is what I hope can happen. In my mind this means the ability to successfully read KJV/ESV-kind-of-texts in parallel with Leningrad and Rahlfs' LXX. Brenton's LXX is much less important. Perhaps what I missed is whether everyone else was advocating mapping between systems or mapping between texts. But I would think that if mapping works well between the four texts listed above, that would make a large number of the texts in the module repository work with them as well. And that would be a fantastic start.<span class="HOEnZb"><font color="#888888"><br>
<br>
Daniel</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/<u></u>mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page</div></div></blockquote></div><br></div>