<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Well said, Arnaud. It doesn't have to
be an either/or choice between presentation as the translators
intend and the ability to correlate matching content. Troy and I
could both enjoy our different use cases, which are actually not
unique just to Troy and me. It is worth the work to make both
cases available.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 2/20/24 05:09, Arnaud Vié wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CA+kNJPgRZGBc6g25MpijmGw+0ZAy=uaT1vaqH_-Oavcs4Zsesw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>Thank you for your interest and your time !</div>
<div>And thanks Troy for your valuable historical explanation.<br>
</div>
<div><br>
</div>
<div>However, I can't help but feel that you all are
underestimating the power of OSIS !<br>
Your are splitting the use cases of "rendering a bible mostly
as it was published" versus "making a bible searchable
accurately for bible study and research", as if we had to
choose one and neglect the other.<br>
</div>
<div>These use cases are both equally valid, but the good news
is that OSIS is already a (mostly) perfect format to handle
both at the same time.</div>
<div>That's part of the reason why I fell in love with the
format and believe it's worth maintaining.<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>In particular, some cases Michael mentions :</div>
<div><br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Chapter
and verse "numbers" aren't always pure numbers. Letters get
involved in the Deuterocanon/Apocrypha.</blockquote>
<div> </div>
<div>Here, OSIS already provides a distinction between :</div>
<div>
<ul>
<li>The OSIS ID, which is a "technical" ID supposed to be a
unique identifier for the book/verse/chapter. On this,
OSIS imposes a constrained format and structure because
applications will need to process it.<br>
</li>
<li>The published number (the verse or chapter's "n"
attribute) which is a free text, allowing to preserve the
numbering from the published document.<br>
</li>
</ul>
</div>
<div>In fact USFM provides a similar distinction between the "v"
and "vp", "c" and "cp" keywords.</div>
<div>You can check <a
href="http://crosswire.org/pipermail/sword-devel/2024-January/049928.html"
target="_blank" moz-do-not-send="true">the example in my
first email about the proposed Catholic3 versification</a>
for an example : it's perfectly fine to have an OSIS ID
"Esth.3.20" for a verse that is labelled as "13G" in the
published document, because the OSIS ID is technical.<br>
The OSIS ID should be used almost exclusively for this need of
referencing and mapping verses between different translations
; in an ideal world, the OSIS ID shouldn't even be visible to
end users (even though I know that's not currently the case).<br>
</div>
<div>The "n" attributes are what should be presented to the
users when reading a bible.<br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Verse
bridges (like verse 1-3 with everything from verses 1 through
3 but possibly rearranged and with no other verse markings
within them) are very common.</blockquote>
<div><br>
</div>
<div>OSIS already natively supports its, without any changes to
versifications : it allows several OSIS IDs on a single tag
explicitly for this purpose. (section "15.4. Grouping" of the
OSIS manual)<br>
</div>
<div>So it's perfectly valid to define verses 1,2,3 in the
versification, and then have one single "verse" element with
all of these IDs at once for this use case. This "verse" tag
can then provide an n="1-3" attribute to preserve the
published document notation.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>My proposal for a new way of defining versifications aims
purely at improving the mapping feature - the same one that
Troy relies on for bible study and research.</div>
<div>It has no impact on the "presentation" side of things -
because of these existing OSIS features I mentioned above
which already allow preserving the original text's numbering.<br>
</div>
<div>The "principle 1" of my proposal in the other thread is the
core of what a versification system should be : a
versification system should assign a unique ID to identify a
verse's contents (what I called the "meaning" of the verse in
my proposal), so that this ID can be used to reference or map
the equivalent or related text in other bibles.</div>
<div>That's where the current versification system is
problematic, because many bibles do not fit exactly into one
of the default versifications, and they have no way of
building a "custom" versification. That's the problem I'm
trying to solve.</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Le mar. 20 févr. 2024 à 14:54,
Peter von Kaehne <<a href="mailto:refdoc@gmx.net"
moz-do-not-send="true" class="moz-txt-link-freetext">refdoc@gmx.net</a>>
a écrit :<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div dir="ltr">
<div> </div>
<div>
<div dir="ltr">There are two aspects here:</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Historical developments which have been
by and large well explored by Chris and are mirrored
well in our various av11n system - with specific and
now largely known gaps - we have less clue on the
Roman catholic development of versification systems
and probably even less on a variety of autochthone
churches with their own historical development of
translations an versification. But these are well
defined tasks and e.g. the work of Dominique to bring
in the French systems documents well how we should
handle that side. </div>
<div dir="ltr"><br>
</div>
<div dir="ltr">The complications coming in due to modern
translation are actually very limited:</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">FWIW, most modern translations which play
about with versifications still actually follow an
underlying well known and documented plan. </div>
<div dir="ltr"><br>
</div>
<div dir="ltr">NRSV(A) eg seems to be all what UBS and
Wycliffe use - even when allowing for verse bridges,
reordering and more. </div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Which makes me think we should think more
about a presentation overlay which we have at the
moment very rudimentary only. OSIS certainly allows
for more than we incorporate right now. </div>
<div dir="ltr"><br>
</div>
<div dir="ltr">This could take eg in the engine the form
of a resorting filter where text is reordered and
marked up for user facing presentation based on
additional presentation info in modules. </div>
<div dir="ltr"><br>
</div>
<div dir="ltr">This would to my mind be a much better
solution than ever increasing further system of av11n
or indeed a complete rewrite. </div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Peter</div>
<div dir="ltr"><br>
</div>
<div
id="m_860571014849005652ms-outlook-mobile-signature">
<div><br>
</div>
Sent from <a href="https://aka.ms/o0ukef"
target="_blank" moz-do-not-send="true">Outlook for
iOS</a></div>
<div> </div>
<hr style="display:inline-block;width:98%">
<div id="m_860571014849005652divRplyFwdMsg" dir="ltr"><font
face="Calibri, sans-serif"><b>From:</b> sword-devel
<<a
href="mailto:sword-devel-bounces@crosswire.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">sword-devel-bounces@crosswire.org</a>>
on behalf of Troy A. Griffitts <<a
href="mailto:scribe@crosswire.org" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">scribe@crosswire.org</a>><br>
<b>Sent:</b> Tuesday, February 20, 2024 12:24 am<br>
<b>To:</b> <a
href="mailto:sword-devel@crosswire.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">sword-devel@crosswire.org</a>
<<a href="mailto:sword-devel@crosswire.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">sword-devel@crosswire.org</a>><br>
<b>Subject:</b> Re: [sword-devel] Catholic
versification / inter-versification mappings
<div> </div>
</font></div>
<p>Dear all,</p>
<p>These comments are a mix of background, history, and
thoughts:</p>
<p>1) VERSIFICATION (v11n):</p>
<p>Variation between reference systems sucks. Until you
get into the weeds of the details, it is normal to
assume the problems are not complex. SWORD tries to
implement a simple 90% solution.<br>
</p>
<p>SWORD and JSword support defined abstract
versification schemes with 3 simple dimensions:
[bookid : chapterMax][chapterNumber :
verseMax][verseNumber : verseEntry]<br>
</p>
<p>Conceptually we also operate on these assumptions
(I've skimmed the proposal by Arnaud which differs
here, but I haven't given it the thought it deserves
to comment yet): that book order is defined in the
v11n system; that chapter and verse numbers are
numeric and begin at 1 and increase to verseMax. We
also allocate a special slot '0' for: Module
Introduction; Testament Introduction; Book
Introduction; and Chapter Introduction (e.g., Matt.0.0
can hold an introduction to Matthew).<br>
</p>
<p>Those who have been exposed to many Bibles will
immediately think of places these assumption fall
short. But for >90% of our Bibles, these
assumption hold true, and these assumption make many
aspects of our work much simpler (abstract parsing of
verse lists and ranges, bookmark ordering, etc.).</p>
<p>Historically, SWORD previously supported dynamic, per
module, versification, with a 3 phase lookup:</p>
index file .bks[book number] = book offset in next
index;<br>
index file .cps[book offset + chapter number] = chapter
offset in next index;<br>
index file .vss[chapter offset + verse number] = verse
offset and entry size in data file.
<p>20 years or so, we made the decision to begin the
hard work to understand versification systems within
Bibles so we could begin to map them appropriately.
This let us remove the .bks, and .cps index files and
store that data in versification system definitions,
leaving only the final .vss index file which gave the
offsets and entry sizes into the data file.</p>
<p>Caring about versifications was a decision we made.
Our previous design let any Bible decide how many
books, how many chapters, and how many verses each
chapter contained. This had its merits because any
new versification could be defined in each module
without anyone caring what it was. But the drawback
was the same: any Bible could decide how many books,
how many chapters, and how many verses without anyone
knowing why or what they were.</p>
<p>Some have pushed for dynamic definitions of v11n
systems again, and I understand why. I am in favor of
moving forward with a hybrid approach: a set of
defined versification systems, which a module will
still need to choose from, to which it most closely
adheres, + the ability for that module to specify its
variation.<br>
</p>
<p>Toward 98%: We have tried to work around the cons of
this simple design and approach 100% support by
accounting for the most common types of problems, e.g.</p>
<ul>
<li>The engine allows common verse suffixes (e.g.
Matt.2.7b);</li>
<li>The engine skips verses in a Bible which are not
present-- this allows us to create v11n schemes
which are a superset of n number of closely related
v11n schemes, knowing that the engine will skip over
the verses that are not present in the module; We
also have tools which print out missing verses which
has proven a good QA check for our modules team.<br>
</li>
<li>When we run across a Bible which adds an odd verse
here or there or an out of order verse, our
workaround has been to append these to end of the
verse just before where they should appear, so the
text flows the same as the printed Bible, and we
include for the reader an inline visual separator
and marker showing the publisher's verse number.<br>
</li>
</ul>
<p><br>
</p>
<p>These work arounds get us pretty close to being able
to support 98% of our Bibles exactly as the publisher
wishes, and the remaining 2% is supported "well
enough" for no complaints by publishers. Could we
build a system which allowed out of order verses, or
which allowed any scheme a Bible wished to follow?
Sure, but the added complexity for various tasks
increases quite a bit for some of these allowances--
e.g., think index math for book chapter verse when we
cannot assume numeric sequence; think abstract
ordering of bookmarks not tied to any specific Bible,
search results across Bibles, etc.<br>
</p>
<p>Our vision with v11n definitions is that they will be
a few as possible allowing us to map between them most
easily; and as many as necessary to allow us to
represent well enough a published work.<br>
</p>
<p>Chris Little previously was our versification pumpkin
holder and did some amazing work researching all this
material. As a demonstration of his thorough work and
an example of the difficulties with v11n, see his work
on just the LXX tradition:</p>
<p><a
href="https://www.crosswire.org/svn/sword-tools/trunk/versification/lxx_v11ns/"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://www.crosswire.org/svn/sword-tools/trunk/versification/lxx_v11ns/</a></p>
<p>Chris has left our community after many years of
volunteering massive time and effort.</p>
<p>We haven't had anyone step up who is willing to
commit the time and effort necessary and who holds our
vision (as few as possible, as many as necessary).</p>
<p><br>
</p>
<p>2) MAPPINGS:</p>
<p>SWORD and JSword support v11n to v11n mappings.
Graciously, Костя Маслюк worked with us for over a
year to discuss the problems and implement a
versification mapping system which has been included
in the engine. He also added v11n mappings for
systems he was interested in supporting. If anyone is
interesting in the discussions, they can see the
archives, e.g.,</p>
<p><a
href="https://www.crosswire.org/pipermail/sword-devel/2013-July/040154.html"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://www.crosswire.org/pipermail/sword-devel/2013-July/040154.html</a></p>
<p>Historically, we called this topic alternate
versification, so if you see "av11n" in the archives,
you'll be aware.</p>
<p>Registering v11n systems and mappings in the engine
is straightforward in our versification manager, and
as you can see, loading these dynamically from a file
would be simple to implement:</p>
<p><a
href="https://www.crosswire.org/svn/sword/trunk/src/mgr/versificationmgr.cpp"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://www.crosswire.org/svn/sword/trunk/src/mgr/versificationmgr.cpp</a></p>
<p>During the development of the mapping infrastructure,
our proof of concept was to see if we could concisely
build a parallel Bible HTML display across
versification systems, letting a user specify any
number of Bibles, the first Bible v11n being the
primary ordering driver:</p>
<p><a
href="https://www.crosswire.org/svn/sword/trunk/examples/tasks/parallelBibles.cpp"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://www.crosswire.org/svn/sword/trunk/examples/tasks/parallelBibles.cpp</a></p>
<p>____<br>
</p>
<p>So, now to the issue with adding another Catholic
versification system. I would love to continue to
delegate ownership of v11n decisions! I trusted
Chris. He said "no" all the time, and only allowed
new versification definitions if we really couldn't
support a set of Bibles using an existing system with
our work arounds. He spent the time necessary to
understand the traditions, which published works would
use the proposed versification, he had excellent
skills clearly delineating systems-- generally he made
well informed decisions from many hours of research.<br>
</p>
<p>I don't understand the complex details nor have the
time to do the research for each individual request.
My first thought is, where is Chris?! Next, my
uninformed mind thinks: we have v11n definitions
"Catholic" and "Catholic2"! Why do we need an
additional Catholic versification system? Did we do a
bad job with the first two? Can we not follow our
principles and create a superset between 2 or more of
these? And of course, these are not proper responses.<br>
</p>
<p>So, if anyone is prayfully willing to take up this
pumpkin-- to put in the time necessary to research
Bible traditions and published works, to truly
understands both the pros and cons of the decisions
we've made to go down the path we are on, along with
our workarounds for the cons, and is willing to live
wholeheartedly with where we are now, but certainly
always open to improve, I would love for that person
to take ownership of versification.</p>
<p>I appreciate the pointers to the Paratext v11ns and
mappings, maybe we compare where we are now with what
they have.</p>
<p>Thank you all for being zealous to improve things.
Looking forward the conversation to follow,</p>
<p>Troy<br>
</p>
<p><br>
</p>
<p><br>
</p>
<p>On 1/26/24 06:10, Arnaud Vié wrote:</p>
<blockquote type="cite">
<div dir="ltr">
<div>Hello everyone,</div>
<div><br>
</div>
<div>I'm the person Cyrille mentioned, and I just
joined the mailing list as I thought I could maybe
explain a bit more what I'm trying to do with this
new versification.</div>
<div><br>
</div>
<div><b>1. Problem statement</b><br>
</div>
<div><br>
</div>
<div>Simply put, my objective is to be able to align
verse-by-verse the contents of two bibles that use
different versifications.</div>
<div>For example :</div>
<div>- I open Daniel 3 in a Catholic bible, it has
100 verses because the Prayer of Azariah is
included.</div>
<div>- I want to compare the translation verse by
verse with, for example, the KJVA. This means I
want to see the Daniel 3 from KJVA, with all
verses from PrAzar included in the corresponding
place.</div>
<div><br>
</div>
<div>There was already logic to perform such mapping
in jsword, and I recently included it to support
deuterocanonical contents (on the AndBible fork,
since that's the only one where I got answers from
the maintainer) : <a
href="https://github.com/AndBible/jsword/pull/13" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://github.com/AndBible/jsword/pull/13</a> </div>
<div><br>
</div>
<div>Now, the problem is to be able to do the same
with the deuterocanonical additions to the book of
Esther, because there are many different
"strategies" adopted by different bibles.</div>
<div>- Protestant bibles, when they have it, usually
have it a separate books (AddEsth in KJVA).</div>
<div>- Some catholic bibles have it as additional
chapters at the end of Esther, making Esther 16
chapters long : that's the existing "Catholic2"
versification, which maps to KJVA easily : <a
href="https://github.com/AndBible/jsword/blob/develop/src/main/resources/org/crosswire/jsword/versification/Catholic2.properties#L392"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://github.com/AndBible/jsword/blob/develop/src/main/resources/org/crosswire/jsword/versification/Catholic2.properties#L392</a>
<br>
</div>
<div>- Most catholic bibles actually have the
additions integrated directly within the original
text, using lettered verse numbers (13A, 13B,
etc., see here for example : <a
href="https://www.aelf.org/bible/Est/3"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://www.aelf.org/bible/Est/3</a>
)<br>
</div>
<div><br>
</div>
<div>Currently, these catholic bible with the text
integrated use the "Catholic" versification, and
ignore all the lettered verses (or include the
letters as raw text) : basically, Esther 3.13 with
these additions becomes one single very long
verse. This makes it impossible to map properly
with the AddEsth of KJVA.</div>
<div><br>
</div>
<div><b>2. Proposed solution (Catholic3
versification)</b><br>
</div>
<div><br>
</div>
<div>With the proposed Catholic3 versification
(except it needs a few adjustments compared to the
file proposed by Cyrille), what I'd like to
achieve is to give a unique verse number to each
of those.</div>
<div>For example, Esther 3 goes from 15 to 22
verses, with the OSIS IDs becoming :</div>
<div>- Esth.3.13 for verse 13</div>
<div>- Esth.3.14 for verse 13A...</div>
<div>- Esth.3.20 for verse 13G</div>
<div>- Esth.3.21 for verse 14<br>
</div>
<div>(Basically, the OSIS ID identifies the position
of the verse; the actual numbering from the bible
can be preserved separately with the OSIS "n"
attribute or the "\vp" USFM keyword.)</div>
<div><br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">would
your use-case be served if canon_catholic.h was<br>
modified to increase the verse counts in Esther to
39, 23, 22, 47, 29,<br>
14, 10, 41, 32, 14?</blockquote>
<div>Since my objective is to allow mapping verse by
verse, you'll understand that I need the verse
counts to be aligned with the actual usage. Having
the "versification" allow more verses than what's
actually used defeats the purpose.</div>
<div>In addition, I believe it's a very bad idea to
make big changes to already published
versifications : the point of versifications is to
give a unique ID to a verse. Updating a
versification will change all IDs for the verses
of already existing bibles that use this
versification.</div>
<div>I really believe the best solution for the time
being is to create a new Catholic3 versification,
as originally suggested.<br>
I can provide the full definition very soon
(though since I'm working with JSword it will be
in Java format first), and it should in theory be
aligned with Catholic and Catholic2 except for
these differences in Esther. (I'll check if there
are more differences I missed).</div>
<div><br>
</div>
<div><b>3. Modular versifications</b><br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I
think at some point it would be nice to have
per-book versifications<br>
or some other way to deal with bibles that don't
follow a "standard"<br>
versification</blockquote>
<div>Agreed.<br>
</div>
<div>If everyone is open to the idea, I'd like to
work in the next few months on an extension of the
OSIS standard to define "modular" versifications,
ie. versifications that can be built by composing
other versifications and applying a diff.</div>
<div>Then each bible could, in its document header,
not only reference a standard versification with
refSystem, but include its own specific changes
and how they map to the standard.<br>
</div>
<div><br>
</div>
<div>Before I spend time on the topic though, is
there anyone in particular I should ask to approve
the general idea, and who would be interested in
reviewing proposals on the topic ?<br>
</div>
<div><br>
</div>
<div>Thanks all and best regards,</div>
<div><br>
</div>
<div>Arnaud<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Le jeu. 25 janv.
2024 à 16:35, pinoaffe <<a
href="mailto:pinoaffe@gmail.com" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">pinoaffe@gmail.com</a>>
a écrit :<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Hello,<br>
<br>
I don't know much about catholic bibles or sword,
but just out of<br>
curiosity: would your use-case be served if
canon_catholic.h was<br>
modified to increase the verse counts in Esther to
39, 23, 22, 47, 29,<br>
14, 10, 41, 32, 14? Or would the decreases in
verse counts in other<br>
chapters of other books also be necessary?<br>
<br>
And would such a change be acceptable to others?<br>
<br>
The catholic bibles I've encountered "in the wild"
are the dutch<br>
Willibrordvertaling of 1975 and the neovulgate.
Both of these appear to<br>
follow canon_catholic3.h everywhere except in
Esther, where they have 16<br>
chapters<br>
<br>
I think at some point it would be nice to have
per-book versifications<br>
or some other way to deal with bibles that don't
follow a "standard"<br>
versification, but for now we'll have to make do
with what we got<br>
<br>
Kind regards,<br>
pinoaffe<br>
<br>
Fr Cyrille <<a
href="mailto:fr.cyrille@tiberiade.be"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">fr.cyrille@tiberiade.be</a>>
writes:<br>
> Hello,<br>
> Recently a person interested in the Catholic
bible in French told me<br>
> about the mapping problems between Catholic
versification and the kjva<br>
> concerning Esther. So I'm bringing up the
question of a new Catholic<br>
> versification that could better deal with
this kind of problem and at<br>
> the same time incorporate some of the errors
in current Catholic<br>
> versifications. I should mention that two
versifications for French<br>
> Bibles have been added since my proposal for
a new Catholic<br>
> versification, which was made long before
these versifications were<br>
> added, and which was not favorably received
at the time. In our case,<br>
> the number of Bibles that follow this
versification is simply<br>
> enormous, since the majority of Catholic
Bibles do. I would also add<br>
> that the LXX versification is not entirely
correct. There are no LXX<br>
> today that put 16 chapters to Esther. Ralph's
already uses letters to<br>
> integrate Greek passages into the text.<br>
> In fact, Catholic versification simply
follows Ralph's. So I suggest<br>
> that we seriously reopen this question with
concrete suggestions.<br>
> For my part, the suggestion is simple:
convert the numbers in the<br>
> Greek passages into verses and offset the
numbered verses in the same<br>
> chapters. I'll copy you on what that might
look like.<br>
><br>
> Br Cyrille<br>
><br>
> [2. text/x-chdr; canon_catholic3.h]...<br>
><br>
>
_______________________________________________<br>
> sword-devel mailing list: <a
href="mailto:sword-devel@crosswire.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">sword-devel@crosswire.org</a><br>
> <a
href="http://crosswire.org/mailman/listinfo/sword-devel"
rel="noreferrer" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">http://crosswire.org/mailman/listinfo/sword-devel</a><br>
> Instructions to unsubscribe/change your
settings at above page<br>
<br>
</blockquote>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">sword-devel@crosswire.org</a>
<a href="http://crosswire.org/mailman/listinfo/sword-devel"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">http://crosswire.org/mailman/listinfo/sword-devel</a>
Instructions to unsubscribe/change your settings at above page
</pre>
</blockquote>
</div>
</div>
</div>
_______________________________________________<br>
sword-devel mailing list: <a
href="mailto:sword-devel@crosswire.org" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">sword-devel@crosswire.org</a><br>
<a href="http://crosswire.org/mailman/listinfo/sword-devel"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">http://crosswire.org/mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br>
</blockquote>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
sword-devel mailing list: <a class="moz-txt-link-abbreviated" href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a>
<a class="moz-txt-link-freetext" href="http://crosswire.org/mailman/listinfo/sword-devel">http://crosswire.org/mailman/listinfo/sword-devel</a>
Instructions to unsubscribe/change your settings at above page
</pre>
</blockquote>
<p><br>
</p>
<div class="moz-signature">-- <br>
<meta http-equiv="CONTENT-TYPE" content="text/html; charset=UTF-8">
<title>signature</title>
<p><font color="#000000">Aloha,<br>
<b><big><i>Michael Johnson</i></big></b></font><b><br>
<font color="#000070">
26 HIWALANI LOOP • MAKAWAO HI 96768-8747</font></b><font
color="#000070"> • USA<br>
<a href="https://mljohnson.org/">mljohnson.org</a> • <a
href="https://eBible.org">eBible.org</a> • <a
href="https://WorldEnglish.Bible">WorldEnglish.Bible</a> • <a
href="https://PNG.Bible">PNG.Bible</a><br>
Signal/Telegram/WhatsApp/Telephone: +1 808-333-6921<br>
Skype: kahunapule • Telegram/Twitter: @kahunapule • <a
href="https://www.facebook.com/kahunapule">Facebook:
fb.me/kahunapule</a></font></p>
</div>
</body>
</html>