SWORD-, MySword- og e-Sword-modulformater: hva dokumentasjonen tar feil om

Kort svar: Hvis du bygger en bibelmodul, er tre mye gjentatte påstander feil. e-Sword har ikke noe .bbl-format. En modul for Det nye testamente må beholde boknummereringen for hele Bibelen. Og en SWORD zText-indeks teller plasser, ikke vers. Hver feil gir en modul som installeres uten feilmeldinger, men leses feil — som er den verste måten å ta feil på.

Vi skrev modulbyggere for SWORD, MySword og e-Sword i ren Go, uten noen ekstern verktøykjede, for å levere de gratis bibelmodulene bak Tringine. Hvert skjema og hver byte-oppbygning nedenfor ble lest ut fra faktiske, publiserte moduler med en hekseditor og sqlite3, ikke fra en artikkel. Dette er alt vi lærte, inkludert den ene kontrollen vi nå kjører ved hver bygging fordi det ikke holdt å bare lese kildekoden.

Hvorfor finnes det ingen .bbl-fil for e-Sword?

Fordi den ikke eksisterer. Søk etter modulformatet for e-Sword-bibler gir stadig treff på .bbl, og .bbl er en filendelse for LaTeX-bibliografier — det er derfor jakten på en spesifikasjon ender i tomme og forvirrende resultater.

De virkelige formatene er .bblx for e-Sword 9 og 10, der versteksten er RTF, og .bbli for versjon 11 og nyere, der versteksten er HTML. Versjonene 11 til og med 13 leser begge, så det å levere kun .bblx dekker e-Sword 9 til 13. Hvis du skal bygge ett format, bygg det.

Hvorfor nummererer en NT-modul fortsatt bøker fra 40 til 66?

Fordi alle tre formatene adresserer vers mot en fast versifisering — den kanoniske listen over bøker, kapitler og versantall en leser bruker for å finne et vers, KJV som standard — og nummereringen er absolutt snarere enn relativ til hva utgaven din inneholder. Å omnummerere et nytt testamente fra 1 til 27 plasserer Matteus nøyaktig der 1. Mosebok hører hjemme, og alt etter det forskyves.

Vi bekreftet dette mot to faktiske moduler som kun inneholder NT, i stedet for å stole på resonnementet: begge starter på bok 40 og begge setter OT=0. Det samme prinsippet slår inn internt i et testamente — en bok utgaven din mangler opptar fortsatt plassene sine, tomme. Hopper du over den for å spare plass, vil leseren vise Markustekst under Matteus-referanser, lydløst, for hver eneste bok etter oppholdet.

Hvor mange poster hører hjemme i en zText-indeks?

Dette er feilen som korrumperer en modul i det stille, fordi en indeks med feil lengde fortsatt parses.

Et SWORD-testamente består av tre filer. Gjennomgående little-endian, målt fra CrossWires ASV- og Byzantine-moduler:

Det er i oppregningen det går galt. Plassene fordeler seg slik: plass 0 er moduloverskriften, plass 1 er testamenteoverskriften, deretter per bok én bokoverskrift, deretter per kapittel én kapitteloverskrift, og deretter én plass per vers. Postantallet er altså 2 + books + chapters + verses — ikke versantallet alene.

For Det nye testamente under KJV-versifisering gir det 2 + 27 + 260 + 7,957 = 8 246 poster, så nt.bzv er nøyaktig 82 460 byte. For Det gamle testamente gir det 2 + 39 + 929 + 23,145 = 24 115 poster, eller 241 150 byte.

Dette kan kontrolleres med én enkelt kommando, som er hele poenget med å skrive det ned: de offisielle ASV- og Byzantine-modulene har begge en nt.bzv på nøyaktig 82 460 byte. Hvis din avviker, er oppregningen din feil, og du vil oppdage det fra en forvirret leser fremfor fra et krasj.

En struktur til det er verdt å kopiere: en ren NT-modul leverer fortsatt en ot.bzv — i full størrelse, fylt med nuller — med ot.bzs og ot.bzz med lengde null. Det er nøyaktig hva den offisielle Byzantine-modulen gjør, byte for byte.

Hva krever SQLite-formatene egentlig?

MySword (.bbl.mybible): page_size=32768, UTF-8, og bibelindeksen er UNIQUE. Verstekst er taggpar i theWord-stil, ikke HTML — fotnoter skrives <RF>…<Rf>. Details.Language krever en kode på tre bokstaver, og hvilke tre bokstaver er ikke opplagt: ISO 639-2 har en bibliografisk og en terminologisk kode for rundt tjue språk, og publiserte moduler følger ingen av dem konsekvent (tyske og tsjekkiske moduler bruker deu og ces; franske, albanske og greske bruker fre, alb og gre; omtrent en tredjedel utelater kolonnen helt). Vi avgjorde vårt valg ved å åpne faktiske moduler heller enn å lese standarden — begge publiserte norske moduler har nor, så vår gjør det også. Der vi ikke kunne tilordne et språk med sikkerhet, skriver vi fortsatt NULL i stedet for å gjette, for en feil språkkode er verre enn ingen.

e-Sword (.bblx): page_size=1024, enkle anførselstegn rundt identifikatorer, og indeksen er ikke unik. To feller her. Details.Version er en INT som angir formatgenerasjonen — 2 for .bblx, 4 for .bbli — og ikke utgaveversjonen din, som hører hjemme i Comments. Og tre faktiske moduler vi undersøkte, er uenige om databasens egen koding: én UTF-16LE, to UTF-8. Man kan altså ikke stole på at kolonnens tegnkoding håndterer et tamilsk eller telugu-tegn.

Løsningen er å skrive hvert ikke-ASCII-tegn som en RTF \uN?-sekvens, med fortegn for 16-bit og surrogatpar over BMP. Det er uavhengig av tegnkoding, og det er hva de virkelige modulene gjør. Skal du levere et ikke-latinsk skriftspråk til e-Sword, er dette den ene detaljen som avgjør om noen kan lese det.

Bolske verdier er 1/0 i begge SQLite-formater. (.bbli bruker Delphis -1, som er en god grunn til ikke å generere .bbli uten videre.)

Sjekk den ferdige .conf-filen, ikke datastrukturen

Metadata er den delen av en modul som leses av en katalog og potensielt av en domstol, og det er den delen en testsuite har minst sannsynlighet for å kontrollere. Vår gjorde ikke det i starten: et lisensfelt som var riktig i Go-strukturen, ble gjengitt som noe annet i .conf-filen, og vi oppdaget det ved å lese filen, ikke ved å kjøre testene. Det ble rettet og hver modul bygget på nytt samme dag; filene i hyllen vår i dag sier Copyright=Public Domain for de tamilske tekstene fra 1868 og telugu-tekstene fra 1880, oppgir ingen rettighetshaver, og krediterer kun Publifye som utgavens tilrettelegger i TextSource.

To forhold må holdes adskilt i den filen. Tekstens lisens er et faktum ved oversettelsen og ikke opp til deg å velge: en bibel i det frie domene er i det frie domene i modulen din også, og ingen DistributionNotes-linje kan begrense det. Vilkårene for distribusjonstjenesten din — registrering, logging — styrer serverne dine og ingenting annet. Blander du de to, vil du enten begrense det som er fritt, eller frigi det som ikke er det.

Testen som sikrer dette nå, sjekker den ferdige .conf-filen. Den feiler i samme øyeblikk en tekst i det frie domene blir tildelt en rettighetshaver eller en begrensende merknad, og like fullt i det øyeblikk vår egen oversettelse i det stille nedgraderes til fritt domene. Begge veier, for en for tillatende feil er fortsatt en feil. Alle som leverer bibelmoduler, bør lese filen de faktisk leverer, ikke koden som skrev den.

Hvordan vi verifiserte det

Ikke ved å lese spesifikasjonen tilbake til oss selv:

• En fullstendig modul for Det nye testamente — 7 957 vers — ble bygget og lest tilbake med libswords egen diatheke i en Debian-container. Den vises i modulelist, slår opp Matt 1:1, Joh 3:16, 1 Kor 13:13 og Åp 22:21 på riktige adresser, returnerer ingenting for 1. Mosebok 1:1 slik en ren NT-modul skal, og søker korrekt.
• Den samme sjekken på en modul for hele Bibelen, 31 102 vers over begge testamenter: 1. Mosebok 1:1 og Salme 119:176 lest tilbake på tamil og Åpenbaringen 22:21 på telugu, hver på sin adresse, med en faktisk ot.bzv på nøyaktig 241 150 byte ved siden av en nt.bzv på 82 460 byte.
• xmllint validerer at OSIS-koden er velformet, med rettighetserklæringen på plass.
• SQLite-filene åpnes med sqlite3 med nøyaktig de radantallene planen rapporterte — 7 957 rader over bøkene 40 til 66 for NT-modulen, 31 102 over bøkene 1 til 66 for hele Bibelen.

To av våre egne feil ble fanget opp av denne direkte testingen fremfor av testsuiten. Det forholdstallet er normalt, og det er et argument for å teste mot den faktiske leseren fremfor mot din egen forståelse av den.

Ofte stilte spørsmål

Hvilket format bør jeg bygge først for e-Sword?

.bblx. Versjonene 11 til og med 13 leser det side om side med det nyere .bbli, så én fil dekker e-Sword 9 til 13.

Hvorfor viser modulen min teksten til feil bok?

Nesten alltid oppregningen. Enten ble bøker omnummerert fra 1 til 27 for et nytt testamente, eller så ble en bok utgaven mangler hoppet over i stedet for å stå igjen som tomme plasser. Sjekk bytelengden på din nt.bzv mot 82 460 først.

Trenger jeg en ot-fil i en modul for Det nye testamente?

Ja. En ot.bzv i full størrelse, fylt med bare nuller, med ot.bzs og ot.bzz med lengde null.

Hvordan får jeg tekst på tamil, telugu eller andre ikke-latinske skrifter inn i .bblx?

Skriv hvert ikke-ASCII-tegn som en RTF \uN?-sekvens heller enn å stole på kolonnens tegnkoding, som er inkonsistent på tvers av faktiske moduler.

Kan jeg bruke modulene deres?

Ja. Modulene i det frie domene har ingen restriksjoner fra vår side overhodet — utgaven er vårt arbeid, ordene tilhører alle. Vår egen oversettelse, Bibelen Anno 2026, er gratis for ikke-kommersiell distribusjon.

---

Vil du ha modulene fremfor formatet? Hvordan installere gratis bibelmoduler i AndBible, MySword og e-Sword går gjennom hver enkelt app. Hver modul på tringine.publifye.com/modules leveres med OSIS-kildekoden slik at du kan bygge på nytt eller ettergå arbeidet vårt. Nedlasting krever en gratis konto, som er et vilkår for tjenesten vår og ikke et krav på tekstene — lisenssiden sier det i klartekst.

Skrevet av Jørn André Halseth, grunnlegger av Publifye AS — ti år med publisering av bibler og bygging av pressene de kjører på, og forfatteren av Tringine, Darash, Junifye og Lexifye. Om oss · Kontakt