References into Apocrypha partially broken

[xiphos-bug-inhaler]

I have a module with a crossreference represented thusly in ThML:

2 Macc. 7:37f. Two things are flaky about this display. First off, the Commentary view only displays the text "Macc. 7:37f." The "2 " is missing. Secondly, when I click the link "2ma 7:37" appears in the reference list on the left, but when I click on that reference I am transported to Revelation 1:1 instead of 2 Maccabees 7:37 (this is with the KJVA from CrossWire experimental open as my Bible - the link works properly in BibleTime). However, when I have selected "2ma 7:37" in the verse list, the preview window in the left displays the proper text, even though the reference displayed is a bit ugly (it reads "[KJVA] 2ma 7:37" instead of making it pretty the way other references are). Reported by: greg-hellings Original Ticket: [gnomesword/bugs/417](https://sourceforge.net/p/gnomesword/bugs/417)

[xiphos-bug-inhaler]

Here you see the application open to Revelation 1:1. At the top right, the link to Maccabees, and the left the reference from clicking on the link.

Original comment by: greg-hellings

[xiphos-bug-inhaler]

We don't really claim to support av11n at this point, so I'm not sure that we should address this until we have basic support in place.

Original comment by: ransom1982

[xiphos-bug-inhaler]

i can't explain why the full display content "2Macc. 7:37f" isn't displayed, but it's a certainty that it's an engine issue, because xiphos has no say (indeed, no opinion) about the content that comes back from the engine when it requests that sort of thing. a strong guess is that the engine isn't happy with # references. i wonder what diatheke does when asked to return html results.

having "2ma 7:37" is simply the result of getting that single textual link (the "passage" content) out of the encoded internal url and into the verse list. that the result of clicking it gives you Rev.1.1 is an artifact of [a] xiphos doesn't yet understand av11n and [b] given its kjv-only context, the engine's ParseVerseList method attempts to parse it appropriately, fails contextually, and punts to Rev.1.1. it does this for anything it doesn't understand. is this an engine bug? i don't know. perhaps it should return something known to be just plain bad.

in summary:

• display lacking initial "2" is clearly an engine problem because xiphos doesn't care what's there and happily displays whatever the engine supplies.
• xiphos doesn't yet do av11n so any interpretation of apocrypha is at best a good guess and generally universally wrong.

sorry. av11n is coming, honest. closing this for now, as av11n needs are covered elsewhere.

Original comment by: karlkleinpaste