[sword-devel] Verse number markers

refdoc at gmx.net refdoc at gmx.net
Sat Nov 24 01:02:51 MST 2018


This is a proposal which I think I can largely do at the library end myself, but as it reflects a significant change I would like to have some input and discussion. 

I want to introduce verse number markers as a element separate from the verse tag. By default these should not be shown, but showing them in parts or all can solve all kind of vexing issues. 

1) reversified verses. We have plenty texts were at least some verses will need recertification. This is unsightly and confusing for the reader. By adding verse markers we can reduce the ghastliness. We do add new versifications probably for a while longer but there are clear limits how many we want to maintain. And unless we allow and provide the infrastructure for dynamic av11n this will stay so. Note that I am not by necessity convinced by dynamic av11n

2) reordered translations. Every so often I encounter texts where the translator has in order to improve understanding reordered verses. This is usually captured currently in a verse range, which will then loose the link to the source text somewhat. By providing verse number markers we can reduce the divergence from the print. Underlying the text will still be an OSIS range, but the reordered marker tags will make this more slightly

3) alphanumeric verse and consequential  numbers. Esther has this a lot and it is a mess. We could have a numeric counter underneath and whatever above it. 

4) ad hoc module maker fixes. To deal with our limitations as described above module makers have produced all kinds of inconsistent "fixes", dropping bracketed numbers or similar in the text. By using a set of agreed and consistent tags we can sort this. 

In short the verse number mark tag shall have no structural meaning, it shall be simply a tag somewhere which says, if you want you can _present_ here a specific and given verse number. It will carry a number of attributes which will allow ingrained CSS and possibly conf file option etc control and switching on or off.

The changes this requires are limited and I think I can already more or less see them. I think they should be possible to do that they have no or only limited front-end implications and in particular do not block or duplicate front-end ordinary verse numbering. The changes should also be non disruptive in terms of coexistence of old and new modules. 

The disadvantages are all about user expectation, a request for a particular verse may still produce a verse range in cases of reversification blobs or reordered ranges. In Greek Esther even more so. But to be frank, what we do now is not less messy.

What do you think?

Peter



Sent from my mobile. Please forgive shortness, typos and weird autocorrects.


More information about the sword-devel mailing list