So, my understanding from all the previous emails, is No we don't cope for
books with different orders of keys. However these do happen. Moreover, the
more general case of content from 1 verse switched with the content of
another is more prevalent.
So it's quite feasible to have a system that
Maybe the title should have included the phrase book order.
As is fairly well known, the book order for the Epistles is different in
Eastern Canon than in the Western Canon.
This is just one such peculiarity for the NT.
There is also that odd move of some verses to a different chapter in Romans
On 4 Jul 2013, at 14:01, Chris Little chris...@crosswire.org wrote:
Book ordering differences are a trivial case, already handled by
versification system definitions. E.g. the German and Luther versification
systems differ, in the NT, only in book order. If you query Heb-Rev in
German,
It uses QML, so it is part of Qt. I will bring this up to the others
and see what they think about it all.
It may be a good idea. Anyhow we are designing an interface at the
moment to get the features we want, using what capabilities QML has,
and designing it to be fully integrated with the
And (for example) if you wish to query the whole of the JPS module using book
names, it will not do to specify *Gen-Mal*.
You'd need to remember that in the Tanakh, the last book is *II Chronicles*.
--
View this message in context:
Hi guys. The questions that need answers in this thread are logically
complex and are one of the reasons we haven't finalized any additions to
the core SWORD library to support this-- though I greatly appreciate the
contributions made by Костя.
Take, for example our standard 4 Bible web
SWORD does not support out-of-numerical-order v11n systems, e.g., one
Bible might decide to number its verses 1,5,2,3,4,6,7. We do not plan
to have a facility to support this. The argument has been made on
threads-past which basically says: changing the logic of chapter/verse
from integer
We have a design in place which allows for the code example I previously
mentioned:
lxx-setKey(nasb-getKey())
The engine recognized that the versifications are different and calls a
facility to do the translation. We have not finalized on this facility
yet. As also mentioned, ? has
On Jul 4, 2013, at 12:01 PM, Troy A. Griffitts scr...@crosswire.org wrote:
We have a design in place which allows for the code example I previously
mentioned:
lxx-setKey(nasb-getKey())
What Chris might not realize in this simple statement: In SWORD a module has
the notion of current key.
Great!! I will post the git page (to the uBible Developers) if you want me
too, or you can head over to
https://github.com/uBible/uBible/issues/1
and post the info yourself if you want.
We have been discussing using Bible Time's backend because @Mark Trompell
suggested it.
You can e-mail me
STEP doesn't use any wrappers per say, but confines all the (J)Sword code
to as few places as possible (4-5 classes). The idea being any changes to
APIs are only in a few places. It also does mean that if for some reason
some other engine comes along with a different format of books, then we'd
be
On 07/04/2013 03:24 PM, Chris Burrell wrote:
I'm afraid, I'm not sure I follow. The screenshot looks ok,
In the LXX, there are roughly eighty verses between what is displayed as
3:23 and what is displayed as 3:24.
but then I don't read Greek or Hebrew so I don't really know.
The issue is not
12 matches
Mail list logo
