<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
As I am working on the source for one of hundreds of Bible
translations that I have processed recently, I'm amazed at the
variations and spottiness of the scope of translations, especially
with respect to Old Testament portions. The number of variations is
almost as high as the number of translations, because of their
various states of incompleteness. They don't all come in nice, neat
ranges. Individual books may start late, have multiple holes in
them, and/or start early. It is all about where the translators
choose to spend their limited time. And sometimes, they have to quit
before they are done for a variety of reasons. Sometimes I'm working
with a translation in progress, and more will be done, but sometimes
there is nobody on the horizon to take over a translation project.
All of that to say this: my preferred way for a Bible study program
to act is to automatically adapt to display the verses that it
actually finds. If a conf entry describing the scope of the
translation is optional or required, it should be VERY flexible.<br>
<br>
I hope to be converting over 200 translations to Sword format, soon,
most of which are covered by a Creative Commons BY-ND-NC license
(with extra permission on the ND to change file formats without
changing the actual text or punctuation).<br>
<br>
Michael<br>
eBible.org<br>
<br>
<br>
On 02/14/2012 10:12 PM, Nic Carter wrote:
<blockquote cite="mid:8F817DF1-084D-4639-8FC5-E19A3EC6CE72@mac.com"
type="cite">
<div>My very late reply to this whole discussion:</div>
<div><br>
</div>
<div>I love the idea of a scope. As Ben points out, a user would
be able to tell before they install a module that a commentary
is only for specific books of the Bible or a Bible module is NT
or OT only. After that, we would easily be able to determine
which books to display for navigation purposes. If there was a
method in the engine, Troy points out that it can be very
optimised, which would be good for post-installation, but how
optimised will it be for running on handheld devices (which I
guess is the main scenario I am interested in!)?</div>
<div><br>
</div>
<div>I think I would rather that the scope was set manually in
each conf and wasn't something that maintainers had to run on
their repositories or anything like that. For a majority of
modules out there, an empty scope would be sufficient, as long
as we defined an empty or non-existant scope reverted to ALL
(based on the v11n) or something like that. :)</div>
<div><br>
</div>
<div><br>
</div>
<div>Thanks, ybic</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>nic...
:)</div>
</blockquote>
<br>
</body>
</html>