<div dir="ltr"><div>JSword now has a fairly maintainable human-readable set of mapping files. I personally haven't come across a use case that we have been unable to cater for yet. We have seen various issues related to performance, but some of these have been fixed and others are in the process of. They were partly due to the lack of an fast OSIS reference parser and therefore relying on a fairly heavy use of a a the default Key resolver (which allowed for internationalisation among other things). DM can expand on this. The other was totally internal to JSword, where I hadn't fully grasped the benefits of our various implementations of Passages. I know AndBible has suffered a hit in performance and Martin was the instigator of one of the performance fixes (using better/more appropriate implementations of Passage) which had a good impact. DM has fixed a few other things that I believe would speed up AndBible further, but have yet to be tested.</div>
<div><br></div><div>In terms of whether it's adequate enough, we know of some issues, but these so far have been due to incomplete/erroneous mapping files that we have. Other than that, scholars in Tyndale House seem happy enough to use what's there.</div>
<div></div><div><div><br></div><div>The parallel display implementations for STEP have two variants. One is actually displaying whole texts in parallel. (i.e. comparing a verse against another verse, line by line). For this, we modified JSword to do translations behind the scene, similar to what you're suggesting I'm guessing. In considering parallel displays, there are two edge cases we cope for. For a translation from An->Bn verse by verse, you may omit some verses from B (because they don't match anything that exists in A), or you may duplicate B. For both of these, the JSword engine adds some markup such that a frontend can decide whether to display a warning to the user (either inline/globally).</div>
<div><br></div><div>The other version of parallel display is interlinears which matches up words based on strongs and displays words in columns. For this we exposed the translation API such that frontends can use it. So for each verse, STEP calls the API to work out the matching verse, then analyses it and builds up the interlinear that way.</div>
<div><br></div><div>Also, it is worth noting that STEP and AndBible use the translation API differently. AndBible maps the first verse of a passage and then displays something to the user based on that first verse. STEP maps a whole passage to another passage.</div>
<div><br></div><div>Hope that helps</div><div>Chris</div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 26 February 2014 19:00, Troy A. Griffitts <span dir="ltr"><<a href="mailto:scribe@crosswire.org" target="_blank">scribe@crosswire.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">One positive thing from the previous thread is the reminder of Kosta's proposed implementation for translation between modules of varying v11n.<br>
<br>
The accusation of irresponsibility is warranted, not for delaying the patch submission, but for delaying the discussion toward a resolution and buyin by a consensus of frontends.<br>
<br>
To sum up:<br>
<br>
We have refactored and isolated translation to a single point within the engine. Basically, when you set the value of one VerseKey from a VerseKey with differing v11n, translation will happen. This propogates naturally to many places in the engine. For example it will allow one to set the LXX module from a key obtained from the KJV module:<br>
<br>
lxx.setKey(KJV.getKey());<br>
<br>
<br>
The question still on the table is: how useful is this for the primary use case of displaying in parallel modules with varying v11ns?<br>
<br>
A secondary question is how can we optimize, in both speed and size, the translation. The JSword team is beginning to implement their own mechanism and I would like to hear about their experience.<br>
<br>
There are open threads on this with many of my, and others, thoughts and concerns. I would appreciate it if commenters might consider searching the list history before commenting. <br>
<br>
My theoretical question is, what logic do we want to use to create a parallel display? There are many hard cases we haven't resolved, even if the resolution is "we simply don't handle that, and what you'll see is X."<br>
<br>
I know the STEP tools have a parallel display implementation. I have no idea if its behavior in corner cases is acceptable to most.<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.</font></span><br>_______________________________________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br></blockquote></div><br></div>