OSIS Konverter

Spannend!

Die Kapitelseiten sind alle ungecacht, um die Möglichkeit von Hervorhebungen bei der Bibelstelle-Aufschlagen-Funktion zu haben. Deshalb wird ein Herunterladen aller Inhalte tatsächlich den Server belasten, ich weiß aber nicht, wie stark.

Bringt es Dir was, wenn ich Dir einen Export aller Wiki-Seiten als XML-Datei schicke?

Momentan konvertiere ich nur 2 Bücher mit insgesamt 7 Kapiteln, zum testen reicht das. Ist halt die Frage ob das immer noch zu viel ist.

Für einen kompletten Download (wenn ich denn mal ein Modul mit allen Büchern machen will), wäre die XML aber tatsächlich eine Alternative. Ein komlettes Modul mit allen Büchern ist aber erst interessant wenn der Konverter ein brauchbares Modul produziert und das tut er momentan noch nicht. Also die XML hat noch Zeit. :-)
 

Hi Patrick,

die 7 Kapitel sind sicherlich kein Problem.

Übrigens würde ich gerne Deine Meinung zur einer verwandten technischen Frage hören: Zur Zeit machen wir ja alles mit Mediawiki-Anpassungen. Ich bin mir aber nicht sicher, ob das langfristig der beste Weg ist. Es gibt nämlich mehrere Dinge, die mit einer Speicherung der Übersetzung in einer spezialisierteren Datenbank vielleicht einfacher wären:

1. Es wäre super, Lesefassung, Studienfassung und Urtext auf Wunsch spaltenweise anzeigen zu können.

2. Es gibt die Idee, dass wir angemeldeten Benutzern erlauben könnten, Ihre eigenen Fassungen und Bearbeitungen einzustellen. Auch hier wäre es super, die Fassungen nebeneinander sehen zu können.

3. Eine Zuordnung von deutschen Wörtern zu den griechischen Wörtern im Urtext wäre echt sehr hilfreich für die Funktionalität in Bibelprogrammen, oder für eine Offene-Bibel-Version meiner Online-Synopse mit Farbmarkierungen. Im Idealfall könnte man beim Korrekturlesen einer fertigen Übersetzung einfach die deutschen und griechischen Wörter abwechselnd anklicken und diese Zuordnung dann abspeichern. Das sprengt aber die Bearbeitung als Wikiseite endgültig.

4. Auch sonst frage ich mich, ob es nicht praktisch wäre, den Bibeltext dem Bearbeiten der Studienfassung einzublenden, und die Studienfassung beim Bearbeiten der Lesefassung.

5. Wenn wir die Bibeltexte eh in einer separaten Datenbank haben, dann könnten wir dafür einen OSIS-Export einbauen.

Im Moment sehe ich noch überhaupt nicht, wie ich jemals die Zeit finden könnte, ein so komplexes System zu programmieren. Andererseits traue ich mir durchaus das Programmieren einer Wiki-Funktion zu, die beim Abspeichern einer jeden Kapitelseite gleich eine zusätzliche Datenbank aktualisiert. Damit wäre zumindest der Grundstein gelegt, und es ist dann nicht mehr nötig, alle zukünftigen Ideen zwingend in Mediawiki zu programmieren.

Was denkst Du dazu zu diesen Thema?

Und dann habe ich noch eine zweite Frage: Wie siehst das in OSIS mit Absatzmarkierungen aus? Die Versnummern können ja mitten im Absatz stehen. Und gibt es sonst irgendwelche Einschränkungen bei OSIS, die die Formatierung der Offenen Bibel begrenzen?

Patrick, ich wollt nur schnell sagen, ich find es super, dass du daran arbeitest. Das ist eines der Dinge, die wir in den nächsten Monaten brauchen werden! Bleib dran! 

Hallo,
Entschuldigung für die späte Antwort, ich hatte ein ziemlich volles (und gutes :-) Wochendende...

Das Kernproblem der separaten Speicherung ist glaube ich das Format.

Wird das Wikiformat selbst verwendet (oder ein leicht ge-parsed-es Format), könnte man auf die separate Datenbank verzichten und direkt die Wiki als Datenquelle nutzen.

Wird ein spezielles Format genutzt muss man die Seiten konvertieren. Entweder der Übersetzer kann eine Seite nur dann abspeichern wenn sie sich erfolgreich konvertieren lässt (das könnte viele Übersetzer abschrecken, wenn sie ihre Übersetzungen einfach nicht abspeichern können), oder es gibt einen roten Button oder so, der anzeigt ob ein Text konvertierbar ist oder nicht. Dann könnten Übersetzer auch so speichern und jemand der weis wie's geht kann dann später den Text wieder konvertierbar machen (ganz im Sinne einer Wiki). Auch so eine Konvertierung könnte man immer bei Bedarf neu machen, wenn es dabei ein Resourcenproblem gibt (es dauert zu lange bei jeder Anfrage den Wikitext neu zu konvertieren) Caching einführen.

Aufgaben die die Wiki momentan übernimmt und bei einer separaten Datenbank dupliziert werden müssten wären: Textformat, Datenbanklayout, Versionierung und das Frontend. Ich glaube der Arbeitsaufwand eine separate Datenbank und das drumherum einzurichten und zu verwalten ist ziemlich hoch. Dewegen denke ich ist es vorerst sinnvoller das Wiki Backend als einzige Datenhaltung zu behalten und bei Bedarf via API zu verwenden anstatt die Daten zu duplizieren.

Das OSIS Format ist zwar XML, hat aber eine (etwas unschöne) Lösung für das XML Verbot von Tag-Überlappungen (<a><b></a></b>). Viele Tags können in OSIS ge"milestoned" werden. Das heißt Anfangs- und Endtag werden in zwei einzelne Tags aufgeteilt:

<verse sID="Gen.1.1"/>Am (im) Anfang erschuf (brachte hervor) Gott den Himmel (die Himmel) und die Erde.<verse eID="Gen.1.1"/>

Dadurch ist es möglich den Text gleichzeitig auf mehrere Weisen zu strukturieren. Klassischerweise wird zwischen "Document structure (BSP)" und "verse structure (BCV)" unterschieden. Also ist es kein Problem Verse und Absätze, Anmerkungen, usw. zu durchmischen.

OSIS bietet eine ganze Reihe von Möglichkeiten Text zu erweitern und zu formatieren. Momentan direkt für die Offene Bibel interessant sind Übersetzungsalternativen ( ) und Einfügungen/Weglassungen [ ]. Laut OSIS Spezifikation kann man für Alternativen das <rdg> Tag verwenden und für Weglassungen <transChange>. Ob Sword diese Tags unterstützt müsste man mal recherchieren oder austesten. Alternativ könnte man die ( ) und [ ] auch erstmal einfach so stehen lassen.

Für Wortzuordnungen zum Urtext hat OSIS auch eine Möglichkeit mit dem <w> Tag. Die Strong Nummern werden damit gemacht, Bibletime kann die per Hoverover anzeigen (eigendlich ein ziemlich cooles Feature, wenn auch nur extrem wenig Bibeln Strongnummern haben). Das funktioniert so, dass man in einem separaten Lexikonmodul die Wörterbucheinträge aufführt und mit dem <w> Tag referenziert.

Das große Problem bei OSIS ist glaube ich die Unterstützung von Sword. Sword versteht nämlich nicht den kompletten OSIS Funktionsumfang. Im Zweifelsfall muss man immer testen.

Ich würde das Format der Offenen Bibel auf keinen Fall von OSIS einschränken lassen, wenn OSIS eine Eigenschaft vom Offenen Bibel Format nicht kann, dann ist das halt so. Wenn OSIS nicht kann was die OffBi braucht, dann ist das Format nicht flexibel genug, kein Grund deswegen die OffBi zu beschneiden.

Lieben Gruß,
Patrick

Ich habe schon ein bisschen mit Texten in OSIS gearbeitet. Im Wesentlichen sollte es kein Problem sein, die Offene Bibel in SWORD zu bekommen, wenn man (wie ich nicht) alles umwandeln kann. Wir haben eigentlich keine Funktion, die nicht schon anderen Bibeln vorkommen würde, einschließlich Fußnoten und Parallelstellen. Ich weiß noch nicht, ob die Alternativ-Funktion nötig sein wird, da Klammern sich ja einfach als Fließtext integrieren lassen. Andererseits wäre es sicher interessant, die Alternativen nach Bedarf auszublenden.

Fallls es doch mal Probleme geben sollte, gibt es mindestens zwei deutsche SWORD-Developer, von denen ich mit einem schon mehrmals Kontakt hatte und der auch schon seine Hilfe angeboten hat, falls wir irgendwelche Probleme haben (er hat allerdings bisher nicht angeboten, das Modul zu machen. Ich schätze, dazu hat er zu viele Texte in der Warteschleife ;-) ). Und es gibt eine aktive Mailing-Liste.

Ich bin ein bisschen weiter. :-) Inzwischen werden Studien und Lesefassung exportiert, das Unicodeproblem ist auch gelöst. Als nächstes dran:

Überschriften und Kommentare

Patrick

Weiter so! :-)

Klasse! Das sind sehr gute Nachrichten.

Ist das ein direkter Export als dem Wiki (über dessen XML-Export-Funktion), geht das über die Api oder müssen die Texte noch händisch rauskopiert werden?

Der Konverter nutzt die Wiki API direkt, man muss garnichts händisch machen.

Inzwischen gehen Überschriften und Footnotes.

Als nächstes: [ ] und ( ).

Heute hab ich mein 3-Vers-Demo-Modul zum ersten Mal produktiv nutzen können. Das macht Lust auf mehr! Wie sieht es aus, hast du schon irgendein Testmodul, das man sich installieren könnte, einfach um den Coolness-Faktor Offene Bibel in seinem Bibelprogramm zu haben? Und wie steht es allgemein mit der Arbeit? 

Mein bestehender Konverter tut ganz gut. Also wenn das Interesse da ist, kann ich mal alle existierenden Seiten durchparsen und ein Modul bauen.

Auf die Frage wie der momentane Stand aussieht gibt es eine lange und eine kurze Fassung.

Kurze Fassung:

Ich werde, wenn ich denn mal wieder etwas Zeit finde, den Konverter neu schreiben.

Lange Fassung:

Mein bisheriger Ansatz stößt an seine Grenzen, weil ich bisher nur auf Patternmatching gesetzt habe um den Text umzuwandeln. Es gibt ein paar Konstrukte, die sich so aber nicht konvertieren lassen (Klammern bedeuten in Kommentaren was anderes als im Text, Klammern können verschachtelt sein, usw.).

Deswegen habe ich überlegt ob ich den Konverter neu schreiben sollte und einen Parsergenerator (ANTLR) benutzen soll. Das Endergebnis wäre ziemlich gut wartbar und ließe sich für noch einiges andere benutzen (z.B. ein Syntaxcheck).

Momentan fehlt's an der Zeit. Das sieht die nächsten 2 Monate nicht besser aus, aber ich hoffe, mich zwischendrin mal wieder dran setzen zu können.

Ich habe riesiges Interesse. Beim Offene Bibel-Stand auf dem Kirchentag haben sich auch die Leute (auch das Standpersonal) um mich geschart, als ich ihnen den exportierten ePub-Text zeigen wollte. Insofern bin mit Sicherheit nicht nur ich gespannt.

Hi,

ich habe zwei Module gebaut (Lese- und Studienfassung). ftp://zakweb.de/pub/offbiModule.tgz
Zum Benutzen die Inhalte der beiden Ordner in das ~/.sword Verzeichnis kopieren.

Da mein Script nicht sehr tolerant ist, fehlt hier und da ein Stück vom Text. Im Großen und Ganzen sollte aber alles drin sein.

Patrick

Super, funktioniert in Bibletime ohne Probleme! Danke für deine bisherige Arbeit.

Ich hab mir die .conf-Datei angeschaut. Welche "versification" hast du benutzt? Ich hab nicht wirklich eine gefunden, die den Urtext widerspiegelt. Manche Frontends könnten einen Eintrag dazu brauchen, um das Modul richtig anzuzeigen.

Ich schreib mal einen Artikel für die Startseite, wenn Wolfgang mir nicht zuvorkommt. :-) Sollte da noch irgendeine bestimmte Information über das Modul rein? 

Ich glaub ich hab kein Verssystem eingestellt und Standard ist KJV.

Du kannst dazuschreiben, dass ich das Modul in dieser Form nicht weiterpflegen werde, weil ich den Konverter, wie schon angekündigt, neuschreiben will. Und noch dass man nicht zu viel erwarten sollte. Teils fehlen komplette Kapitel oder Verse wenn der Parser die Syntax nicht verstanden hat.

Ich wollte mal auf eine Diskussion hinweisen, die gerade auf der SWORD-Mailingliste geführt wird. Es geht darum, inwiefern man das Modulmachen für Laien vereinfachen kann. Jemand hatte als Beispiel genannt, dass man mit Logos 4.3 neuerdings Word-Dokumente präparieren und als native Module importieren kann, was natürlich großes Potenzial hat. Daraufhin sagten einige, dass ein solches Vorhaben für SWORD mit den gängigen Text-Formaten eine unheimlich komplexe Aufgabe wäre, und ein anderer schlug vor, stattdessen doch ein einfaches Markup - wie das von Mediawiki - vorzugeben und die Leute so ihre eigenen OSIS-Dokumente erstellen zu lassen. Daraufhin habe ich auf diesen Thread und Patricks Vorhaben hingewiesen. Gehört nicht ganz zum Thema, aber halte ich für eine interessante Entwicklung! 

Hi Patrick,
ich bin begeistert. Das Modul funktioniert wunderbar. Ich weiß nicht, ob du es verfolgt hast, aber es gibt mittlerweile eine feste Integration deiner Arbeit in ein Bibelprogramm für WebOS und es ist erfolgreich auf einem Android- und einem iPhone getestet worden. In diesem Sinne nochmal herzlichen Dank!

Hi.

Ich habe inzwischen eine Grammatik geschrieben (doch nicht mit ANTLR, sondern parboiled eine andere Parserbibliothek), die das Offene Bibel Markup versteht. Naja, zumindest kann sie Psalm 23 erfolgreich parsen.

Jetzt ist meine Frage: Was ist wichtiger, sauberes Fehlerreporting (könnte man benutzen um die Kapitel auf Syntaxfehler hin zu überprüfen), oder der Konverter? Je nachdem würde ich zuerst gutes Errorhandling einbauen oder eben den Konverter wieder zum laufen bringen.

Gruß,
Patrick

Da wir auch andere Exportemöglichkeiten nutzen (wollen) würde ich eher zum Errorhandling tendieren, da es allen Exporten zugute kommt. Ich bin mir allerdings nicht hundertprozentig sicher, ob nicht Olaf eine automatische Syntaxprüfung als Wiki-Extension bauen wollte.

Ich bin immer wieder begeistert von deinem Einsatz! Danke!

 Hi Patrick, 

das klingt ja vielversprechend! Welchen Parser verwendest Du?

Langfristig möchte ich so einen Parser gerne auf dem Webserver laufen lassen,  um die jeweils aktuellste Version in eine Datenbank importieren zu können. Damit wären dann neue Funktionen möglich, die als MediaWiki-Erweiterung selbst nicht umsetzbar sind. Ob es für PHP geeignete Parserbibliotheken gibt, weiß ich nicht. Viele andere Serversprachen wären natürlich ebenfalls möglich.

Olaf

Hey,

ich hab jetzt den parboiled benutzt (https://github.com/sirthias/parboiled/wiki), nachdem ich's mit ANTLR aufgegeben habe. Der parboiled ist eine Javabibliothek. Und der Parser selbst ist dann auch ein einfaches Java Programm. Sollte sich auf einem Server verwenden lassen.

Meinst du es wäre tatsächlich sinnvoll den Parser für mehr als nur Konvertierung zu OSIS zu nutzen? Wenn ja, was genau? Wäre wichtig zu wissen damit ich entsprechend programmieren kann.

Welches Format bräuchtest du für die Datenbank? Vermutlich werde ich im Parser erst ein Haufen Java Objekte erzeugen die den Text repräsentieren und erst anschließend das endgültige Format erzeugen. Aber das ist noch unsicher, da muss ich mich zuerst noch mehr in parboiled einlesen wie man das da am saubersten macht.

Patrick

Wenn wir die Übersetzungen in einer Datenbank haben, dann können wir leichter einige Ideen umsetzen, die wir langfristig haben, wie z.B.:

• Versweise Gegenüberstellung der Fassungen (Lesefassung, Studienfassung, Urtext, zukünftig auch Fassung in leichter Sprache und Benutzer-Fassungen mit persönlichem Profil)
• Zuordnung der Worte zwischen Übersetzung und Urtext (Strong-Codes / Reverse Interlineary)

Zum Datenbank-Format habe ich noch nichts entschieden. Das hängt auch vom Parsing ab.

Olaf

Hey,

kurze Frage. Welche Buchstaben sind denn alles in normalem Bibeltext (also nicht in den Hebräisch Tags) erlaubt?

Ich frage weil ich meinen Konverter bisher ziemlich restriktiv bezüglich der erlaubten Buchstaben ist. Aber jetzt finde ich in Genesis 2 Vers 11 "Hawịla". Mit einem nicht ascii "i". Was ist das für ein "i", mit was für Buchstaben muss ich sonst noch rechnen und welche Unicodepage ist das dann eigendlich?

Btw. Der Konverter ist (noch ohne besondere Features) wieder am Start. Diesmal hab ich ihn auf Gitorious gestellt. Den zum laufen zu bekommen ist aber vermutlich nicht so einfach weil parboiled nicht ganz einfach zu installieren ist.

Edit:

Ich habe ein Teil der Antwort schon selbst gefunden: Latin Extended Additional, http://www.unicode.org/charts/PDF/U1E00.pdf
Dank: www.fileformat.info

Gruß,
Patrick

Hi Patrick,

freut mich, dass du Fortschritte machst! Ich hab mal ne Frage (vielleicht auch in die Runde).

Wie unterschiedlich sind OSIS und docx? Ich hab ja keine Ahnung, aber beide sind ja XML (was natürlich gar nichts heißen muss, da XML keine Tags vorgibt). Der Hintergrund der Frage ist die Tatsache, dass man in Logos 4 Module aus docx-Dateien importieren kann. Und da ich Logos habe und darin irgendwann auch gerne mal meine Offene Bibel, wäre das doch sicher mal ein Weg für die Zukunft. Und es gibt sicher noch andee, die sich auch darüber freuen würden.

Frohes Schaffen noch! 

Noch vier Fragen:

Soll sowohl {{hebr}} als auch {{Hebr}} erlaubt sein oder besser nur {{Hebr}} (wird in den allermeisten Fällen verwendet)?

Soll "=" im Bibeltext erlaubt sein (Josua 1)?

Sollte verschachtelte Rede mit '' oder mit »« gemacht werden? Was wenn dreimal verschachtelt wird (kommt das vor?)?

Gibt es wörtliche Rede die Kapitelgrenzen überschreitet? Ist es dann sinnvollerweise erlaubt ein „ mit fehlendem “ einzufügen?

Patrick

Hey,

großer Unterschied zwischen OSIS und docx ist, dass man in OSIS vorgibt was bestimmte Dinge bedeuten ("das ist eine Notiz, das ist eine Einfügung, ..."), und in docx das Format vorgibt ("das ist fett gedruckt, das ist kursiv, das ist rot, ..."). Und dann ist docx viel viel viel komplexer als OSIS. Also wenn ich nach docx exportieren müsste würde ich warscheinlich nicht den direkten Weg über das XML Format nehmen, sondern eine Bibliothek zum modifizieren von docx dokumenten (POI oder sowas). Aber wenn Logos noch andere Import Formate hat würde ich besser einen anderen Weg wählen, weil docx eben Markup und nicht Inhalt beschreibt und damit kein gutes Konvertierungsformat ist.

Gruß,
Patrick

@Olaf:

Mein Konverter parsed inzwischen von Genesis bis Josua alles. Manuell jeden Parsingfehler zu finden (manchmal im Parser, manchmal im Text) ist ziemlich mühsam. Ich hab deswegen einen Validator geschrieben, der eine Wikiseite als Datei bekommt und je nachdem wie er es schafft alle Fehler in dieser Datei ausgibt oder eben sagt dass die Datei ok ist.

Das könnte auch so schon ganz interessant sein um Seiten direkt nach Editierung zu validieren. Momentan gibt's den Konverter und Validator nur als Source Code (Eclipseprojekt). Wie müsste das aussehen, damit du das benutzen kannst, falls du willst? Bekommst du ein Eclipseprojekt auf? Brauchst du eine .jar Datei?

Gruß,
Patrick

Danke für die Info wegen docx. Leider ist das die einzige Möglichkeit, Module in Logos zu erstellen. Aber vielleicht gibt es da einen direkteren Weg als durch das XML.

Von wegen der typographischen Zeichen. Wörtliche Rede soll grundsätzlich echte Anführungszeichen erhalten, allerdings erhält die Studienfassung keine Anführungszeichen für wörtliche Rede. In der Studienfassung kommen Anführungszeichen nur zur Markierung von Zitaten und Bezeichnungen vor, das ist zumindest der aktuelle Stand. Dazu in Zitaten oder Bezeichnungen in den Fußnoten.

Istgleichzeichen wollten wir eigentlich nicht verwenden (so zumindest ein Konsens im Forum vor einigen Monaten). Die Stellen, wo das verwendet wurde, kannst du also ausbessern, wenn ich mich nicht ganz täusche.

Es gibt mit großer Sicherheit irgendwo in der Bibel wörtliche Rede, die Kapitelgrenzen überschreitet. Lang genügende Reden gibt es ja etliche. Da wäre es schon sinnvoll, wenn die Möglichkeit dazu vorhanden wäre.

Zu den anderen Fragen können sicherlich andere besser Stellung nehmen. Zu der Verschachtelung von Anführungszeichen und den {{Hebr}}-Tags ({{par|Buch|Kap|Vers}} bzw. {{Par... wäre ein ähnlicher Fall) haben wir noch keine einheitliche Lösung.

Wird es mit deinem Parser eigentlich möglich sein, gezielt Kapitel oder Teile für die Veröffentlichung auszuwählen? Ich glaube, unsere Gedanken gingen bisher v.a. in die Richtung, zunächst mal die schon fertigen Teile zur Verfügung zu stellen.

Danke für dein Engagement! :-)

Nur bestimmte Kapitel für den Export zu benutzen und den Rest zu ignorieren ist einfach.

Dafür muss ich nur das Kriterium kennen.

Psalm 90 Studienfassung Vers 14 hat einen Klammerfehler, aber ich weis nicht sicher wie die Übersetzung gedacht ist. Da das Kapitel als "fast gut" markiert ist, lass ich mal lieber die Finger weg. Kann das jemand korrigieren? Danke. :-)

Ist erledigt.

Ich kann dir übrigens gerne einen Bot-Benutzer freischalten, falls die Programmierarbeit die Handarbeit aufwiegt. Es gibt sogar schon einen fertigen Mediawiki-Bot mit dem du nach Strings suchen kannst und dann direkt im Bott verändern kannst (entweder automatisch oder händisch).

Noch ein komischer Text wo ich nicht genau weis wie die Übersetzung gedacht ist: Kohelet 11,5 <die Knochen>. die < > sollten vermutlich ( ) sein, bin mir aber unsicher.

Und noch einer: Amos 3: "{{Vorlage:Vers unvollständig übersetzt|Vers 5 und 6}}" was macht das "Vorlage:" da? Hat das eine Bedeutung oder ist das da ausversehen reingerutscht?

Du hast bei beiden Kapitel richtig vermutet. Habe es gegengecheckt und verbessert.

Und nochmal. Diesmal in Epheser 1 Vers 1: <a> <b> <c> <d>.

Keine Ahnung was das da soll oder ob das ein Copy-Pasta Fehler ist. Kann da mal wer gucken?

Das waren mal Fußnoten.Die überflüssigen Markierungen habe ich entfernt. Das Problem ist bei Epheser 1, dass wir 2 Studienfassungen haben, von denen eine als Lesefassung markeirt ist. Das müssen wir dringend mal in Angriff nehmen.

So, mein Konverter liest hiermit die komplette Offene Bibel erfolgreich ein. Modul Erstellung klappt auch. Es fehlt noch ein bisschen polieren (duch die neue Struktur aber sehr wenig Arbeit), aber ich hab schon zwei sehr brauchbare Module.

Leider habe ich keinen Server mehr zur Verfügung. Jetzt brauch ich einen Platz wo ich die Module irgendwie hochladen kann. Geht das auf dem offene-bibel Server oder habt ihr eine andere Idee?

Wow, klasse! Ich kann es gar nicht erwarten, eine Blick drauf zu werfen.

Wenn die Daten kleiner sind als jeweils 2 MB,  kannst einfach ein neues Forenthema aufmachen und sie da hochladen. Vielleicht wäre aber ein Blog eher ein Ort dafür. Denn ab jetzt geht es ja eher um Fehlersuche und Rückmeldung zu einzelnen Versionen. Ich habe dich einfach mal dafür freigeschaltet (siehe Menüpunkt "Inhalt erstellen" ).

Wenn die Daten größer sind, dann schick sie einfach an info [ätt] offene-bibel.de Für die Zukunft können wir uns dann mal ein besseres Verfahren überlegen.

Im Forum sind keine .zip oder ähnliches erlaubt. Hochladen geht deshalb nicht.

Ach Mist, ich hab's geändert. Ich habe auch noch ein paar Endungen für Linuxzipper erlaubt.