[sword-devel] eBible xref

[Peter von Kaehne]

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 <Kahunapule at 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