Ok, then if I understand well, we work on the "full" text, and then with
some scripts we remove some parts of the full text.
Can you list this parts?
Le 25/04/2023 à 21:57, David Haslam a écrit :
To answer your question briefly.
Please note that such XML files having ".full" as part of the filename
contain [informational] elements that are removed before making a module.
ie. The processed source files for the KJV project have more parts to
the filename.
Aside: Although DM had his own method for removing these elements, I
made a simple /bespoke/ TextPipe filter solely for this purpose.
Best regards,
David
Sent with Proton Mail <https://proton.me/> secure email.
------- Original Message -------
On Tuesday, April 25th, 2023 at 8:21 PM, Fr Cyrille
<fr.cyri...@tiberiade.be> wrote:
Sincerely thank you David for all this information.
I will now put all this on git, and open issues for what you suggest.
On the Kjv2.9 we have the kjv.xml and the kjvfull.xml? Which one is
the right one?
I can see also the kjv2.10a version. This version does not matter?
Le 25/04/2023 à 15:01, David Haslam a écrit :
Dear Fr. Cyrille, dear Troy,
As regards, the KJV source text managed by DM, it's no secret that
he stored all of them in his personal area
<https://www.crosswire.org/~dmsmith/> on the CrossWire server.
The files used for KJV release 2.9 that preceded Troy's emergency
update (2.10.2) are stored here:
https://www.crosswire.org/~dmsmith/kjv2011/kjv2.9/
cf. From the latest kjv.conf
Version=2.10.2
History_2.10.2=Fixed errant article Strong's markup (2021-04-04)
History_2.9=Added markup to notes. Improved markup of Selah.
(2016-01-21)
NB. The verse where Troy fixed the Strong's markup error is Romans 3:36
Aside: IIRC, the Strong's markup error in Romans 3:36 had already
been corrected (evidently it was in the pipeline for the next
release by DM, even before Troy took action).
There's a lot more that could be said, and a lot of subsequent
exchanges took place between myself and DM from January 2016 to June
2021, but none of them resulted in preparing a new release from the
OSIS XML that I had been processing by means of various /bespoke/
TextPipe filters.
Throughout that period, I had continued to work on enhancing the KJV
source file, testing it in-house using Xiphos on my old Windows 7
x64 PC as eXperimental module KJVX.
NB. Last July, I discovered multiple implementation bugs in my
change to render pilcrows as normal black text even when these are
within text marked for red letters as words of Jesus. See the
following line in the table for *Version 2.11* being prepared.
Changed red ¶ to black (i.e. within text marked as "words of
Jesus")[2] <https://wiki.crosswire.org/CrossWire_KJV#cite_note-57>
Notes on various thoughts and ideas are recorded in DM's wiki user page:
https://wiki.crosswire.org/User:Dmsmith/KJV_2.6
Last updated 2016-02-20
Many more proposals and a detailed revision history are recorded in
this wiki page:
https://wiki.crosswire.org/CrossWire_KJV
Last updated 2022-07-28
NB. My old Win7 PC is currently in a state of non-use, as I started
to see hard drive errors reported first in August 2022 with the
result that I've not taken it out of sleep mode since last
September. I've not begun to formulate a plan to tackle this
problem, though it's worth recording that it's one of the PCs in my
Carbonite account that has online backup using Carbonite Safe
(albeit it's shown as "out-of-date" in every backup status email I
receive monthlyfrom Carbonite).
Since my wife died in October 2020, I've not found it so easy to
maintain the same level of technical activities as a CrossWire
volunteer that I had attained during the years preceding.
I trust that this reply helps to clarify the state of art for going
forward with future updates to our flagship KJV module. It's not
ideal in regard to modern systems for version control, but the KJV
project began well before GitHub was a gleam in anyone's eyes.
Best regards,
David
Sent with Proton Mail <https://proton.me/> secure email.
------- Original Message -------
On Tuesday, April 25th, 2023 at 12:33 PM, Fr Cyrille
<fr.cyri...@tiberiade.be> wrote:
Le 25/04/2023 à 12:03, David Haslam a écrit :
NB. Troy’s emergency update to the KJV was made using IMP2VS after
exporting the text using MOD2IMP.
It’s not the OSIS XML source text that DM Smith was managing.
Okay David, we're not going to redo the discussion, we had agreed
to provide the community with a text, it seemed to be Troy's
because it's the last one that had modifications. It could be
another one, but then we'll have to know what modifications Troy
made to it.I hope we can get this project moving forward before
we're all dead 😂
How much energy have we spent in endless discussion just to be able
to contribute to this module.
I’m still in contact with DM.
Glad to hear it, even if he doesn't seem to be in touch with us
anymore.
David
Sent from Proton Mail for iOS
On Tue, Apr 25, 2023 at 10:40, Fr Cyrille <fr.cyri...@tiberiade.be
<mailto:On Tue, Apr 25, 2023 at 10:40, Fr Cyrille <<a href=>> wrote:
Le 24/04/2023 à 21:11, Troy A. Griffitts a écrit :
Hi guys. The NASB is done. I have the scripts checked in and the
source data from Lockman on our server. The problem I have had
is that I haven't had time to figure out how to insert my
scripts to run to convert the data into your wonderful module
team automation.
Just to restate my position on module data processing, and not
to squelch the wonderful work you guys are doing.
My position is that I hold that checking in the results of
source data converted to OSIS files is very bad practice.
In my mind, the only thing we should be checking in is the
script to convert the data from the source to the intermediate
OSIS. We should never check-in the OSIS. EVER. It is an
intermediate step between the source data and a SWORD module.
All the module work ends with a process which takes publisher
data converts to OSIS and results in a SWORD module.
The conversion process can be reproduced automatically.
The steps taken for the conversion are all clearly defined in
the script-- it is not a mystery how the conversion happened.
I believe we lose these two very important things in the way we
currently work.
One more negative aspect in checking in our converted OSIS data
is that we appear to be a source for other software, when it
would be better that other software go to the actual source for
that data and bypass any conversion errors we introduced.
Anyway, my point is not to mandate this automated flow from
source data to module; only to interject that I believe this is
the ideal to work toward.
I have done the extra work to make this happen with the modules
I have done, NA28, NASB, LXXM, etc., and I would at least like
the automation pipeline you have to give me the option to call
out to a script to produce the OSIS, instead of download it from
some location.
Troy
Thank you Troy for all this informations. I understand your point
of view very well and it seems relevant. Now as long as it
remains a goal to wait for, I validate it. But if you take into
account the real thing, it's a lot of work. First of all, on my
side, in the case where we have access to a source, my scripts
are damn tinkered that I would be ashamed to share them! But it's
one of my project.
As for the sources you say we seem to offer, I take
responsibility for them. Firstly because it's much less work for
me once the source is either lost or no longer maintained to make
corrections when a problem is detected. Look at the complication
it has made since Chris left to find acceptable sources for a
multitude of modules. I only do this in cases where the source is
really hard to find or is in a state that is too complicated for
conversion. The case of the BYZ and TR module is an example. I
take care of the text, since nobody else does it anymore and I
have made some pretty serious corrections.
If you're worried about it, you don't have to assume it's
Crosswire, but me.
As for NASB, as you don't have time, could you in this case share
the osis file, at least to allow us to have a nice updated text,
and when you are ready or someone can help you then add the
options you ask for to the module production script.
Isn't it more important to have a bible with a corrected text?
You don't mention the KJV, could you send me your corrected file
so we can work on it? An user has sent several errors to be
corrected to the sword list, I am afraid that it gets lost in the
messages...
Thanks for the great work.
On April 24, 2023 11:35:01 AM MST, Fr Cyrille
<fr.cyri...@tiberiade.be> wrote:
>
>
>
>-------- Message transféré --------
>Sujet : [sword-devel] KJV and NASB updates
>Date : Mon, 17 Apr 2023 00:36:25 +0200
>De : Fr Cyrille <fr.cyri...@tiberiade.be>
>Répondre à : SWORD Developers' Collaboration Forum
<sword-devel@crosswire.org>
>Pour : SWORD Developers' Collaboration Forum
<sword-devel@crosswire.org>
>
>
>
>Hello Troy,
>2 things we could make progress on, which I would like to
remind you of:
>
> * NASB update still pending
> * Moving KJV to our gitlab (you have the latest version)
>
>
>Would this be possible?
>
>Br Cyrille
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
modules mailing list
modu...@crosswire.org
http://www.crosswire.org/mailman/listinfo/modules
_______________________________________________
modules mailing list
modu...@crosswire.org
http://www.crosswire.org/mailman/listinfo/modules
_______________________________________________
modules mailing list
modu...@crosswire.org
http://www.crosswire.org/mailman/listinfo/modules
_______________________________________________
modules mailing list
modu...@crosswire.org
http://www.crosswire.org/mailman/listinfo/modules
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
