Chris Little wrote:
Daniel Owens wrote:
The other MAJOR problem is that the dictionary keys are always
capitalized, which makes it really awkward to use for Greek. Can I
lobby again for a change in that? How many Greek students are used to
looking up words in capitals? I was taught using lower case letters,
and many of the capitals are really fuzzy. When reading I can work
them out based on context sometimes because I have the rest of the
word to clue me in. Capitals also make accent marks look strange. Then
there is the issue of sort order again...
I quite agree. No casing language uses capital forms primarily. Capital
letters are less recognizable and slow reading speed.
That said, I don't quite know how we ought to solve the issue. We can't
simply lowercase the existing keys, since many would actually need to
incorporate capitals (e.g. personal & place names). And we'll need to do
some kind of case folding when we do key lookups.
Making keys be cased and doing case folding at runtime handles part of
the issue. However, key sorting becomes more difficult and we have to
guard against the possibility of keys that are identical except for
casing (e.g. "a" and "A").
Would it be possible to have a display key that is distinct from the
actual sort key? What I mean is there could be parts of the compiled
module that the engine and front-ends use for different purposes. One
could be for sort order (using numbers?), one for lookup (in caps), and
one for display (original n).
What I am hearing from Eeli and Jonathan is a move toward lemma as the
key for dictionaries but a recognition that multiple keys could be
useful. Is there is a way to encode TEI dictionaries to have multiple
key options using n, key, and sortKey? I mean, why not encode
dictionaries with each entry assigned a Strong's number (n?) and a
StrongLemma (sortKey?)?
For TEI P5 documents, you can set any number of key values within the n
attribute, separated by |. For example n="a|aa|123" would put the entry
in "a" but link the keys "aa" and "123" to the main entry. This is
implemented in tei2mod, however I believe there are bugs in libsword
preventing correct encoding of entry links in modules.
--Chris
Excellent, thanks for the tip. I guessed you knew, but I couldn't figure
it out myself from the TEI P5 documentation online.
Daniel
_______________________________________________
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
_______________________________________________
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
