[sword-devel] Parallel display of modules with varying v11ns
chris at burrell.me.uk
Wed Feb 26 12:21:25 MST 2014
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.
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
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
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.
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.
Hope that helps
On 26 February 2014 19:00, Troy A. Griffitts <scribe at crosswire.org> wrote:
> One positive thing from the previous thread is the reminder of Kosta's
> proposed implementation for translation between modules of varying v11n.
> 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.
> To sum up:
> 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:
> The question still on the table is: how useful is this for the primary use
> case of displaying in parallel modules with varying v11ns?
> 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.
> 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.
> 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."
> I know the STEP tools have a parallel display implementation. I have no
> idea if its behavior in corner cases is acceptable to most.
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> sword-devel mailing list: sword-devel at crosswire.org
> Instructions to unsubscribe/change your settings at above page
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the sword-devel