You can fix this relatively straightforwardly by making use of the sword engine. It provides you with a reference parser which does all the required. I use it with reasonable success when making modules. Human input variations clearly can make this a messy affair though.
I agree absence of a fix should not stop making use of the repo. Sent from my phone. Apologies for brevity and typos.On 22 Sep 2015 02:37, Kahunapule Michael Johnson <kahunap...@ebible.org> wrote: > > On 09/21/2015 02:11 PM, DM Smith wrote: >> >> I found the following in eBible’s kud2008eb. The following is Matt.1.1. >> >> >> >> <div type="x-milestone" subType="x-preverse" sID="pv1"/><div sID="gen5" >> type="section"/><title canonical="false" type="sub">Yeisu Besinana ana >> mumugao </title><title type="parallel">(<reference osisRef="Luke.3.23">Luke >> 3:23-38</reference>) </title><div sID="gen6" type="x-p"/> <div >> type="x-milestone" subType="x-preverse" eID="pv1"/>Laulele teina Besinana >> Yeisu ana mumugao vehabadi. Yeisu tubuna Deivida, na Deivida tubuna >> mugamugaina Abelaham. >> >> >> >> The problem is that the osisRef is incomplete. It should be >> osisRef="Luke.3.23-Luke.3.38”. >> >> >> >> The impact is that clicking on the reference in Bible Desktop, it only shows >> Luke 3:23. > > > This is a known artifact of the current conversion from human-readable > references to machine readable references. USFM doesn't directly handle > reference links, so I synthesize them on conversion to USFX, which is then > converted to OSIS. This will probably be fixed eventually, but don't hold > your breath waiting for it. It probably involves rewriting the code that does > that, which is currently a set of 7 XSLT processes. I have a lot of higher > priorities on my work list. If you prefer, I could inhibit such osisRef > entries altogether until such time as I might possibly get around to > improving the reference reading process. (It is kind of complicated, since > "human readable" actually means "human readable in any of about 7,000 > languages".) The alternative of getting all of the translators (or anyone > else) to go back and manually enter machine-readable references probably > won't happen during this century. > >> The following is just extra. It is in addition to the bug mentioned above. >> >> >> >> It is also really odd that there is a second title that contains a >> parenthesized, inlined reference. >> >> >> >> The type="sub” is meant to give a sub part of a title. Since there is no >> prior title, it shouldn’t be sub. As a plain title, it doesn’t need an >> attribute. > > > That "sub" in the title probably came from \s (section title), which could be > (but isn't always) under \ms (main section title). It does no harm, as far as > I can tell, and having it there covers the case where \s follows \ms. Let's > not move the goal posts any more than we have to. > >> Also, the type=“parallel” is inappropriate. The OSIS manual gives that >> parallel is meant to provide the title in another language. The type sub is >> probably more appropriate. Or even type="continued” which means that this >> title continues the last. > > > Page Appendix F, page 138 of the OSIS User Manual seems to disagree with you > about the proper conversion of the USFM \r tag. > >> Note that canonical=“false” is redundant. All titles by default are >> canonical=“false”. > > > Yes, it is. That is certainly not the only redundancy. It is not harmful. > -- > > Aloha, > Kahunapule Michael Johnson > > MICHAEL JOHNSON > PO BOX 881143 > PUKALANI HI 96788-1143 > USA > eBible.org > MLJohnson.org > Mobile: +1 808-333-6921 > Skype: kahunapule _______________________________________________ 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
