[sword-devel] new morphology
chrislit at crosswire.org
Sun Jan 27 07:41:18 MST 2008
DM Smith wrote:
> Chris, given this I don't think that it serves much purpose to put
> this into a module.
> I see two advantages in encoding this:
> 1) It is straightforward, much simpler and much smaller. Which will
> translate into very fast (no I/O).
It's not entirely straightforward (in my experience). The individual
code parts can be of variable length. A particular letter could stand
for one thing in one context, another thing in another, or just be part
of a longer abbreviation in another context.
There's also the issue of our not currently having any facility for
virtual modules like this. I did some test code a while ago to produce a
virtual commentary module from the current Bible's notes (i.e. all of
the notes from the currently selected module show up in a special tab of
the commentary pane). But that was all BibleCS-specific and we would
need to re-implement something sensible in the API. (And we might want
to think about it a little before leaping right into implementation.)
Then again, a nice virtual module framework would finally let us do
things like virtual commentaries from Bible notes, wdiff modules, etc.
A module also has the advantage of being releasable today--as opposed to
whenever the next library rev goes out. But I do think library code is
easier to maintain than modules are.
A module also brings with it lots of nice features to which we are
presently accustomed. With a module, we can get a list of keys (since
it's a static, finite list). If we do this algorithmically, I don't know
how we would populate the key listboxes. With JSword, since I believe
there's not even a facility for key input with LD-type modules, I don't
see how this would work at all.
Modules also have the feature of key linking, with which we could go
ahead and build the TVM codes (currently present in some modules) into
the module. TVM codes couldn't even be decoded algorithmically, so
facilitating them would require a giant lookup table. (But TVM shouldn't
be a big factor, since I plan to phase them out, going forward.)
> 2) It can readily be internationalized. (Which in JSword would be via
> property files.)
> To me the second is the greater gain.
I had considered this, but to me it's really not of much benefit. It
produces a bit of extra burden for translators (and a burden that
requires somewhat specialized knowledge). But fundamentally, there are
very few English terms in a morphology module--mostly just ordinal
numbers (first, second, & third). And we could change those to numerals
(1st, 2nd, & 3rd) to make it a little more transparent to a
non-English-speaker. More importantly, if you can't understand the
morphology when explicated in English, you probably can't understand the
terms in your native language either.
It's not that there's no benefit to internationalizing the morphology.
It's just that I don't see there being much benefit.
If you like, I could just translate the whole thing back into Latin,
where it really belongs.
> My Hebrew is extremely rusty, but I hope that this would require very
> little addition to satisfy the language differences. Perhaps if one
> (i.e. you) could map the OT morph codes in the KJV to the appropriate
> entry in this new morphology, then one (i.e. me) could modify the
> KJV's OT to use these new codes.
Sorta. Hebrew has a vastly different morphological system from Greek.
(Afro-Asiatic and Indo-European, if related, split so long ago that
we're not really certain that they're related.)
I do have something in mind for a Hebrew morphology, but it's not quite
ready for sharing in public. I do want to address those TVM codes in the
OT... fear not.
> A third gain is that our (I know I said two) would be that it would be
> less likely to be taken by other projects. It seems that our modules
> find themselves in all sorts of projects. Maybe "they" get them from
> the same sources.....
Indeed... this one I've found in the most interesting places.... :) But
it does say it's public domain, and I'm not that concerned about people
stealing one of our most uninteresting modules.
> If you would provide a Perl parser, I would find it very easy to
> convert that into Java.
If only I still had it.... I wrote a Perl parser for the currently
released module, but that was years ago. Now I just have a Perl
generator that algorithmically determines all possible codes and
generates the code plus its explication simultaneously.
Do any of these points change your leanings? I'm really not convinced
either way--but keeping a (real) module sure does seem like the easy path.
More information about the sword-devel