One positive thing from the previous thread is the reminder of Kosta&#39;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&#39;t resolved, even if the resolution is &quot;we simply don&#39;t handle that, and what you&#39;ll see is X.&quot;<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.<br>
<br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.