[sword-devel] Parallel display mappings from an UI perspective (was: Module release: LXX)

[Jaak Ristioja]

Hi,

Thank you for the background info, Troy! Getting the mappings right is a 
very difficult problem (at minimum) and I admire all you experts on 
this. I'm not one, and my connection with versifications and mappings is 
more from the perspective of a programmer. As multiple parallel display 
issues have also been reported to BibleTime, this has led me to spend 
some time studying the respective parts of source code in BibleTime and 
LibSword and to reflect on this.

According to my current limited understanding of the related problems it 
seems that there is a fair possibility that some of these (parallel 
display) issues may be unsolvable by just having better mappings between 
different versification systems in LibSword. The mappings do help a lot, 
of course. But even in case of perfect mappings the user might still be 
confused by different numbering, empty verses, books reordered or 
renamed etc. Some users might not even be aware that different 
versifications exist and expect things to "just work".

So on one hand, hiding the mapping complexity from the end user is 
desirable for usability reasons. But on the other hand simplifying too 
coarsely leads to loss of detail and more imperfection. The BibleTime UI 
does not currently communicate to the user that different versifications 
exist, or that the automatic mapping or reconciliation of texts in 
parallel displays comes with caveats. I believe this has also led to 
some bug reports.

To alleviate this I've thought about making things more explicit (and 
slightly more complex) to the end user, e.g. by allowing the user to 
explicitly select a "primary" module as the basis for displaying and 
ordering the parallel texts, and to provide visual clues where verses 
don't match one-to-one, are hidden or reordered. Or to also provide an 
UI for the user to define their own custom mappings or reconciliation 
rules. To brainstorm some more, in theory these mappings or rules could 
also be shared online or even bundled with modules.

Have any other frontends had similar issues with parallel displays? What 
approaches or workarounds would you recommend for consideration? Please 
feel free to comment.


Best regards,
J


PS: Thank you in advance for correcting me if I'm mistaken or don't know 
what I'm talking about at this late hour!

On 01.09.22 16:58, Troy A. Griffitts wrote:
> Sorry lots of typos in the last email from my phone. Some corrections below:
> 
> On September 1, 2022 2:41:57 PM GMT+02:00, "Troy A. Griffitts" <scribe at crosswire.org> wrote:
>> So, LXX is hard. Chris Little did a bit of research a while back on editions of the Greek OT. Some of his hard work is available here:
>>
>> https://crosswire.org/svn/sword-tools/trunk/versification/lxx_v11ns/
>>
>> There are all kinds of crazy things in there, including out of order verse numbers (SWORD doesn't currently support), more than one text tradition of the same book:
>>
>> https://crosswire.org/study/bookdisplay.jsp?mod=LXXM
>>
>> Notice in the index along the left JoshB and JoshA, JudgB and JudgA, etc.
>>
>> In the end, we decided the least of all evils was simply to settle on a superset LXX v11n that contains a place for everything.  The downside of this is that you may find empty verses (as David has found).  Another downside is that we allow the same content to be versified in different ways IN THE SAME V11N depending on how the edition versifies it-- this makes it very hard to build a map file to show a true parallel display in the future.  The upside is that we can show most LXX editions the way they were published, and that outweighed the downsides.  If we ever actually improve our mapping data to show, among others, LXX next to Masoretic versification, we can consider breaking out the LXX into multiple v11ns or some other solution (v11n exceptions in the .conf file has been a consideration), but this hasn't seen anyone really step up to do all this mapling data work-- except for the hard work from Костя for initial design and implementation of v11n mappings support and a few initial mappings.
>>
>> Anyway, that's the background and problems, with the path to where we are today,
>>
>> Troy