[sword-devel] Bibledit Sword module generation?

[Chris Little]

Jonathan Morgan wrote:
> On Fri, Aug 21, 2009 at 5:12 PM, Kahunapule Michael
> Johnson<Kahunapule_Johnson at sil.org> wrote:
>> Matthew Talbert wrote:
>>
>> Is there any hope of getting Bibledit's Sword module generator working
>> with Sword well enough that it actually works in the near future?
>>
>>
>> Are you trying to generate a module within Bibledit or using the
>> usfm2osis.pl script, then osis2mod? I believe everyone is assuming
>> you're aware of the latter method, which is the only way this works,
>> afaik, but perhaps you're not?
>>
>>
>> I was trying to generate a module within Bibledit. I have a usfm2osis.pl
>> script, but it may not be the same one you are speaking of. It does not
>> convert all necessary USFM markup, and drops sections of Scripture. I
>> consider that to be a bad thing. More later...
> 
> I understand you are more interested in the Bibledit route.  If it
> works, that is good.  However, if it doesn't then the definitive Wiki
> page on USFM is
> http://www.crosswire.org/wiki/Converting_SFM_Bibles_to_OSIS.  It
> recommends using SFMToOSIS, and from memory I've got better results
> from it than from usfm2osis.
> 
> Jon

The Wiki doesn't exactly recommend one tool or the other, but I'll 
adjust it to make it more clear that usfm2osis.pl is recommended. I 
really do strongly recommend usfm2osis.pl over the released version of 
SFMToOSIS at this point. If a new version of the latter is released that 
makes its use easier I might change my mind, but for now I think 
usfm2osis.pl is better (and use it exclusively for my SFM to OSIS 
conversion needs).

The advantage to SFMToOSIS is that (I believe) it will definitely output 
well formed XML. It might even be able to guarantee schema validated 
OSIS. Those might seem like great advantages over usfm2osis.pl, since 
the latter really just sees a text stream and tries its best to produce 
valid OSIS from that, but can potentially fail, but I wouldn't guarantee 
that SFMToOSIS will actually do the right thing for each sf tag it 
encounters.

Advantages of usfm2osis.pl include that it is much easier to set up and 
run. (It requires Perl, but that's all. Some people have had difficulty 
setting up a Python environment for SFMToOSIS.) It doesn't require 
Paratext project files, like SFMToOSIS does. (If you already have them, 
that's not an issue, but most USFM that we've been given has come 
without project files.) And, usfm2osis.pl is still maintained. I'm not 
sure what the state of maintenance of SFMToOSIS is, but bugs in 
usfm2osis.pl will be addressed if they are reported.

usfm2osis.pl was originally written for some sfm files from ABS, but has 
since been adjusted to handle USFM files form Wycliffe and other groups.

Maybe most significantly for a task of converting USFM to OSIS for use 
in Sword is that usfm2osis.pl has been written to generate OSIS that 
Sword and the Sword importers will recognize. Generally this shouldn't 
even be an issue, but if there there are any issues of interpretation of 
the OSIS spec, usfm2osis.pl will at least interpret the spec in the same 
way as Sword does.

Both can be run from the command line and so are quite scriptable. And 
if you have the time and inclination, you can certainly try both to see 
which fares better. (And please report any failings you notice in 
usfm2osis.pl.)

--Chris