[sword-devel] suggestion for locales /abbrevs

[Daniel Glassey]

On Wed, 2004-05-05 at 19:33, Chris Little wrote: 
> Daniel Glassey wrote:
> > Hi,
> > 'Book' numbers are going to be moved around a bit with VerseKey2. The
> > current idea is for the extra OSIS books to go in between the Old and
> > New Testaments with a few spaces left for any other issues that may turn
> > up. This will leave Genesis as the start and Revelation as the end.
> 
> There are also a few (roughly 4, I'd guess) "extra" books that belong to 
> the NT.  Can we leave space at the end too?  Or does it really matter 
> since we can re-order books for presentation from their internal 
> ordering (I assume/hope).

I was originally thinking that all the new stuff should go at the end
but it gets kinda messy with the upper bound if there is a book with a
higher number than Revelation that may or may not be there. Do you know
if the "extra" bits generally go in the middle of the NT or are they
added after Revelation? As long as nothing goes after Revelation it
should be possible for the RefSys to specify an order for the books as
well as what is there - good point, need to look into reordering.
The frontends will have final say on presentation anyway.


> > The locales current map abbreviations to book numbers but this is
> > potentially buggy as it is an effort to check if the number is the book
> > that you think it is. What I'm suggesting is to use upper case OSIS id
> > book names instead of book numbers. VerseKey2 will have a static
> > function getOSISBookNum so that SWLocale can map these to book numbers
> > (this will need to be implemented for VerseKey as well).
> 
> Why upper case OSIS book abbreviations rather than mixed?  XML is case 
> sensitive, so the book abbreviations are case sensitive, so it's 
> POSSIBLE that a "GEN" book could be allocated in addition to "Gen". 
> Yes, I know we would almost certainly never ever ever do this, but... 
> what if.  It's mostly academic, but is there really any need to case 
> fold here?
> 
Good point, yep, no need, let's go with straight matches with mixed
case.

> > Does this make sense? I know it will be work to change all the locales,
> > but imho it will be easier than trying to get the number changes right.
> 
> It's entirely sensible to me, will decrease the potential for human 
> error in creating new localizations, and it should be really trivial to 
> update old locales to the new format.

:)
Daniel