BUG: error in sequence of processing Esther 1:1n

1. Enter NJB as highest priority Bible

2. Enter Esther 1:1n in Go Box

3. Note that it processes correctly as an equivalent for Gk Esther 12:2

4. Change highest priority Bible to NRSV, LES, NABRE, LEB ...

5. Enter Esther 1:1n

6. BUG: it processes incorrectly as Esther 1:1 i.e. the n is dropped as a partial verse prior to checking it there is a verse mapping for it. This is the only class of versification mapping that failed to match its verse map. Note that NJB Esther 2:1n to which it should have mapped works correctly.

Find more posts tagged with

Comments

Bradley Grainger (Logos)

This is an ambiguity between "Esther 1:1a" meaning the "first part" or "first half" of Esther 1:1 (context-dependent) and "Esther 1:1a" being a separate verse (in NJB).

The system defaults to the former unless it's explicit that the latter is meant. This is by design.

(You could argue that "1n" is obviously not the 14th part of a verse, but where's the cutoff? Do "1a", "1b", and "1c" get treated one way, but "1d" differently?)

MJ. Smith

(You could argue that "1n" is obviously not the 14th part of a verse, but where's the cutoff? Do "1a", "1b", and "1c" get treated one way, but "1d" differently?)

Thanks Bradley, you confirmed my assumption that the sequence of processing was wrong by design.[;)] Unfortunately my experience is in writing paychecks where the output not the design determines the correctness of a solution. [8-|]

I would not make such an inefficient argument as you suggest. Rather I would scan the verse map to verify my hunch that for the book of Esther/Greek Esther the processing sequence needs reversed ... depending upon the structure of the data and code, perhaps limiting it to specific chapters in the book. Seriously, I understand perfectly why it processes as it does but as I am attempting to document how to enter a Scripture reference, I am finding enough anomalies as to be problematic for an "average" user.