[sword-devel] Re: sword-devel Digest, Vol 14, Issue 16

[Chris Little]

DM Smith wrote:

> There are a few that I left as it was not obvious to me where they 
> belonged. Here is what remains and my thought behind each:
> 
> API-31 On Dictionary Lookup "0" appears in front of Greek number on 
> StrongsGreek window
>     I think that this can be moved to modules or closed as a duplicate. 
> We have already discussed that the better form is to have a G or H 
> preceding the number and for the Greek and Hebrew Strongs to be merged 
> into one. There is a feature request already in Modules for this.

Not a bug, marked as duplicate & closed. The whole leading-0 idea was a 
bad idea carried over from antiquated software.

> API-33 In the KJV John 1:1 is the same as John 1:0 (Not sure this is a bug)
>     According to prior threads, 0 is used to lookup intros. What should 
> happen if there is no intro? My guess is that the module is encoded to 
> return the first verse, instead of nothing. If so this would move to 
> "Modules".

Not a bug. I'm not even clear what behavior you are expecting to see 
that isn't happening.

Closed & moved to BibleCS.

> API-41 With HebModern and Transliteration set to Basic Latin only verse 
> numbers appear in the window
>     Don't know where transliteration is done. So I left it alone. It 
> raises an interesting point to me: If a rtl is transliterated to a ltr, 
> then the direction needs to be changed.

Not sure. It works correctly for me, so I would file this under some 
variety of user error (lacking correct ICU dlls, for example?). But it 
stands that if I can't repeat the error, I can't fix it.

Marked as unrepeatable, but left open.

> API-44 The word "CAESAR" is not found in Webster's Dictionary since "AE" 
> is considered one letter in Webster's
>     I think this is both a API and a module problem. AE (like OE) is 
> often a single letter. Problem is that people don't see it that way. 
> This is a more general issue in how to represent searching for things 
> that are not represented as ascii. For example, often in German a o or u 
> with an umlaut is rendered as oe or ue respectively and one could 
> reasonably expect to use either in a search to find the other.

Not a bug. Changed to Trivial priority, New Feature.

There are different ways we could handle this, basically all of which 
require a lot of processing. There is no error in the module, so it's 
not a module issue. The issue is with input methods, which I do not 
consider to be our responsibility. We could do something to translate ae 
-> æ (ae-ligature) if we really want--either in frontends or in the API. 
The problem is that this issue quickly grows from something very simple 
(like the above single example) to a very large complete solution. The 
letter æ can be transliterated as either ae or e in English (thus cæsar 
vs. caesar vs. cesar). The letters þ and ð are both transliterated th 
(in English and every other language I can think of that uses them). And 
the transliteration of ö is oe in German, but o in English--so the 
problem varies across locales.

My assessment is that it is not a big problem, but the solution is very 
difficult. Someone else can decide whether we want to address this at all.

> API-45 Add Bible Atlas to Modules so a place will link to a map
>     Is this a new feature request?

It can stay in API, even though it is, of course, a module request also. 
But it will need some API-side work if we do more than just show images.

> API-54 Josephus seems to load very slowly compared with MHC, Pilgrim, 
> GerAugustinus
>     I was not sure if this was a problem with rendering (i.e. BibleCS) 
> or with getting the material (i.e. SwordAPI) or with the module 
> representation. Performance problems are often a combination problem.

Moved to BibleCS. The bug description's assessment of the problem is 
exactly the opposite of correct. The slow-down is caused by the 
construction of the treeview from the index. The larger/finer the index, 
the longer it takes to construct the treeview. BibleCS does this when 
the module is accessed for the first time during a session.

--Chris