[sword-devel] OSHB module

Fri Mar 15 13:50:03 EDT 2024

Then I propose that we

Le 15/03/2024 à 14:31, Daniel Owens a écrit :
>
> I am responsible for the OSHB module. If an official solution is 
> reached, I am happy to update the source files and submit for a module 
> update. I just did what worked best in the greatest number of 
> front-ends. It was a pragmatic decision. Unfortunately, Xiphos got 
> left out.
>

I suggest we decide. I think that if the solution that works with xiphos 
works with the others, then let's adopt this pragmatic solution and 
stick to it. Maybe we can document it on the wiki.
If the frontend managers can react in such a way that we propose an 
update to the module as soon as possible.
Karl for xiphos,
Michael for pocket sword,
Troy for Bishop,
Tuomas for andbible,
Tobias for Ezra,
Garry for Bibletime.
>
> Daniel
>
> On 3/14/24 7:03 PM, Kahunapule Michael Johnson wrote:
>> Right now, all modules on eBible.org force Strong's numbers to be G 
>> or H followed by 4 or 5 digits, with leading zeroes as necessary to 
>> make 4 digits. The reason for this is that Paratext and the DBL 
>> software choke on any other format. The decision was forced on me, 
>> really.
>>
>> Ideally, I would consider the Real Solution to be that any process 
>> that READS Strong's numbers should tolerate the presence or absence 
>> of leading zeroes. Indeed, the G or H, if missing, should be inferred 
>> from the Testament in which it is found. (Tagging of the longer 
>> Esther and Daniel should require an explicit G or H.) But if you 
>> write Strong's numbers, maximum compatibility would come from 
>> sticking to the Paratext/DBL pattern. Maximum encoding efficiency, of 
>> course, would be in the other direction, stripping out the redundant 
>> leading zeroes and implied G or H would save space, but at this 
>> point, I think maximum compatibility is more important.
>>
>> Right now, asking for all modules to be rebuilt one way or another is 
>> a really big ask. It is probably easier to preprocess all Strong's 
>> numbers to make the format consistent within the back end. That way a 
>> string comparison in the search should work just fine. We would just 
>> have to decide what the search format should be. G or H should be 
>> supplied to disambiguate when necessary, and leading zeroes either 
>> supplied or stripped. Make sense?
>>
>> Of course, if a strong consensus on Strong's number formatting could 
>> be obtained and manifested in code in all relevant Sword Project 
>> front and back end software, I could go either way. My Bible 
>> translation source would still have the Paratext/DBL format, but 
>> stripping out leading zeroes in writing OSIS files is not hard. For 
>> now, though, I must agree with Karl about the probability of his 
>> trademarked Real Solution coming to pass. Sigh.
>>
>> On 3/14/24 11:23, Karl Kleinpaste wrote:
>>> Quite honestly, the Real Solution™ to this problem is to bite the 
>>> bullet, make a concrete decision that Strong's numbers are to be 
>>> encoded in exactly one way, and re-work all existing modules to 
>>> conform to that standard. Personally, I advocate that such a 
>>> standard would stipulate Strong's numbers to be encoded in minimal 
>>> (natural) digits: Encoding an OT reference as "1" means a Heb 
>>> Strong's dictionary key of "00001" and an NT "1401" means a Grk 
>>> Strong's dictionary key of "01401", that is, zeroes to create 
>>> dictionary module keys are prepended to natural numbers to fill 
>>> exactly 5 digits.
>>>
>>> I've never bothered to attempt a final fix to this problem in Xiphos 
>>> for exactly the reason that, no matter which direction I might take, 
>>> it will be an unreliable hack; that in turn is because the very 
>>> concept of a leading '0' as a weak discriminant between Heb and Grk 
>>> Strong's numbers is itself an unreliable hack. Whenever the 
>>> subsequent conceptual change came along, to distinguish Heb/Grk 
>>> numbers according to a leading H or G (that is, lucene search using 
>>> e.g. "lemma:G1401"), /that/ was the point at which the 
>>> leading-zero-encoding nonsense should have been forced into the 
>>> trash bin.
>>>
>>> It was not, and here we are.
>>>
>>> Probability of the Real Solution™ coming to pass: Vanishingly close 
>>> to zero.
>>>
>>> _______________________________________________
>>> sword-devel mailing list:sword-devel at crosswire.org
>>> http://crosswire.org/mailman/listinfo/sword-devel
>>> Instructions to unsubscribe/change your settings at above page
>>
>>
>> -- 
>> signature
>>
>> Aloha,
>> */Michael Johnson/**
>> 26 HIWALANI LOOP • MAKAWAO HI 96768-8747*• USA
>> mljohnson.org <https://mljohnson.org/> • eBible.org 
>> <https://eBible.org> • WorldEnglish.Bible 
>> <https://WorldEnglish.Bible> • PNG.Bible <https://PNG.Bible>
>> Signal/Telegram/WhatsApp/Telephone: +1 808-333-6921
>> Skype: kahunapule • Telegram/Twitter: @kahunapule • Facebook: 
>> fb.me/kahunapule <https://www.facebook.com/kahunapule>
>>
>>
>> _______________________________________________
>> sword-devel mailing list:sword-devel at crosswire.org
>> http://crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>
> _______________________________________________
> sword-devel mailing list:sword-devel at crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

-- 
Vous aimez la Bible ? Vous êtes étudiant en théologie ? Utilisez 
l'application libre Xiphos <https://xiphos.org/> ou Andbible 
<https://andbible.github.io/> et accédez aux textes sources, à des 
commentaires, des dictionnaires et beaucoup d'autres fonctionnalités... 
Me contacter pour des traductions en français.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://crosswire.org/pipermail/sword-devel/attachments/20240315/60b6801f/attachment.htm>