This sounds like a good conversion for the USFM \vp and/or \va markers. On 11/23/18 10:02 PM, ref...@gmx.net wrote: > 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. > _______________________________________________ > 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
-- signature Aloha, */Michael Johnson/** PO BOX 881143 • PUKALANI HI 96788-1143*• USA mljohnson.org <http://mljohnson.org> • Phone: +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
