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:
lxx.setKey(KJV.getKey());
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@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
