<p dir="ltr">Oh, i just get what you meant about speed and size of translation. What you would like to achieve beyond i have implemented? It is optimized in speed and is very lightweight in size.</p>
<p dir="ltr">As a bonus it can be used in per translation versification concept.</p>
<p dir="ltr">The only thing i would like to change is to slightly increase size, adding one byte per rule to store rule type, so it can handle difficult cases in future with backward compatibility.<br>
</p>
<div class="gmail_quote">26.02.2014 23:00 пользователь "Troy A. Griffitts" <<a href="mailto:scribe@crosswire.org">scribe@crosswire.org</a>> написал:<br type="attribution"><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.<br>
<br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.<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>