I believe there are a lot of important things missing from Sword that should be addressed before we move to 1.6.0. I feel they are sufficiently important that we should address them immediately rather than waiting some number of years until we start working on 1.7. And they will require significant changes to the API, so they should not be done during 1.6.
I get the impression that our users and front end authors would appreciate a 1.5.3 release to be sooner rather than later, in which case I think we ought to plan on a 1.5.4 release. The alternative (in my opinion) would be to postpone the 1.5.3 release for a few months or however long it takes to complete the tasks I will list as important (in my opinion) to 1.6+. Troy had said he planned to begin 1.6 immediately after 1.5.3. And that seemed like a good idea to me, so I passed that information on to others. Now I think that's not a good idea, having thought about 1.5.3 does not currently have that I would really like to have before we hit 1.6. :) Anyone who is interested in working on one/some of these tasks, please chime in. :) Tasks I think are important for 1.5.3: 1) i18n We need to internationalize the whole Sword API. We i18n support for the books, but need the rest of the messages to be separated into resource files. My opinion is that we should implement our own i18n system similar to the current system for book names. We could use ICU, but I think that would be overkill for our needs, and adds unnecessary complexity & dependency on ICU. I18n includes not only translated messages but also formats, such as using commas instead of colons as chapter/verse separators. 2) general book support I think this is relatively important. It is the single most noticeable feature that is missing from Sword but present in almost every other Bible software package (OLB, Logos, e-Sword, ...). Until we have this, we're no better than BibleWorks. Okay, bad example. :) Troy & I (mostly Troy) worked on a scheme for storing & indexing general books that should work very well. It's based on a single hierarchy and uses "TreeKeys" similar to the way a filesystem directory structure works. It will work very well for XML structured books (e.g. OSIS & ThML texts). I believe it is very important to also make a utility to index ThML documents such that they can be easily used in Sword, without modifying the document at all. Compression should be handled also, but should be a relatively straightforward port of VerseKey based compression to TreeKey based compression. 3) expanded ciphering support Ciphering support works on uncompressed Bibles & commentaries. We need to expand cipher support to work with compressed Bibles/commenatries, LD modules, compressed LD modules, general book modules, and compressed general book modules. If some of these already work, we still need conversion utilities, such as RawLD->ciphered RawLD (or ciphered zLD). 4) apocrypha support We just plain need it. I'm not advocating that we handle multiple versifications yet. (If Troy wants to advocate that, I'll happily go along with it, but I suspect he'll prefer to postpone that until 1.7.) This is a pretty simple task, simply requiring additions to canon.h & VerseKey, I believe. The only real decisions are which versification to choose (KJV? NRSV? XYZ?) and how to handle verses in the additions to Daniel & Esther that have two names (one in the apocryphal additions, one in the Greek canonical book). 5) UTF-8 regex support We can probably use Perl's regex code in place of the GNU regex stuff we currently have. This would also release us completely from needing to follow GPL; all other borrowed code is BSD or similar licensed. So we can pretty much license Sword as we please (and create binary-only releases if necessary). 6) bookmark interface There was a bit of talk about this a while back but I think it's been somewhat forgotten. A common bookmark format for all the front ends, accessible through the Sword API, should be decided upon. I don't know much about this, but I understand BibleCS already has a bookmark format that uses the SWConfig classes, so we could simply work on pushing any generalizable bookmark stuff in BibleCS back into the libarary. 7) swtext++ Bible modules should advance to the next unique verse when they are ++'d, like commentaries do, incases of linked verses. If the next verse is blank, it should advance to that verse to address issues of omitted verses. All blank verses should be considered unique so that two consecutive blank verses will both be iterated over. This lets us add Bibles that have single text units that span verses (e.g. where "Mt 1:1-5" is a single unit or where verses are not identified, only chapters). This is a pretty simple problem and can probably be handled by 1.5.3. 8) search on (currently) stripped items Currently, Strong's numbers, morph tags, etc. are stripped out for searches. There are of course circumstances where a person would explicitly want to search for a given morph tag or Strong's number, so we should make sure a facility for this exists. Add to the list if you think there are any other items that are important to have in Sword BEFORE 1.6. --Chris
