Um zu igerman98 beizutragen und Erweiterungen zu machen, sollte man sich mit den verwendeten "Affix-Regeln", den sog. "Flags", die den Worteintraegen der Datein im dicts/-Verzeichnis von igerman98 anhaengen, vertraut machen. Diese Regeln ändern sich eigentlich nicht und können als stabil angesehen werden. Lediglich die Flags, die für die Komposita-Bildung zustaendig sind, aendern sich teils sehr stark, was aber auch kein Problem ist, da diese Komposita-Flags im Build-Prozess des Woerterbuchs automatisch generiert werden. An welche Wörter im Build-Prozess welche Flags angehängt werden hängt von der Kathegorisierung der Wörter ab und kathegorisiert sind die Wortlisten nach Dateinamen: Wortlisten, deren Dateinamen - auf "*-xx*" matchen werden im Build-Prozess optimiert und nach Möglichkeit "weggekürzt". Hier sind vor allem die "zusammen..." Dateien zu nennen, die die meisten Komposita enthalten, die durch Komposita-Bildung automatisch erzeugt werden könnten und keinen extra Eintrag im (Hunspell-)Wörterbuch brauchen. Das funktioniert so, dass erst ein kleines Wörterbuch ohne die *-xx* Dateien erzeugt wird, dann geguckt wird ob aus den Affix-expandierten Wortlisten der *-xx* Dateien Wörter nicht vom kleinen Wörterbuch erkannt werden und nur die Einträge, die nicht erkannte Wörter generieren, werden in das endgültige Hunspell-Wörterbuch übernommen. Wird z.B. Autobahn/P aus zusammen-gross-xx-de_all.txt "Autobahn" und "Autobahnen" generiert, so wird im Buildprozess erkannt, dass beide Formen durch die Komposita-Bildungsregeln erzeugt würden und "Autobahn/P" nicht ins Hunspell-Wörterbuch aufgenommen werden muss. Würde theoretisch in zusammen-gross-xx-de_all.txt "Autobahn/PJ" stehen, so würde das ja zu "Autobahn" "Autobahnen" "Autobahnung" und "Autobahnungen" expanieren. Die letzen beiden Formen würden dann nicht durch Komposita-Bildungsregeln erzeugt werden und somit würde "Autobahn/PJ" ins Hunspell-Wörterbuch aufgenommen werden. - auf "*-x*" matchende Wortlisten (das schließt die "*-xx*" auch ein!) werden nicht als Endworte zur Komposita-Bildung herangezogen. Alle groß geschriebenen Wörter, die nicht in einer auf "*-x*" matchenden Wortliste sind, können Komposita-Endwörter sein. Steht z.B. "Dschihad" in worte-x-de_all.txt, so kann kein "Autodschihad" erzeugt werden. Stünde "Dschihad" in worte-de_all.txt, so wäre "Autodschihad" korrekt. - auf "*-de_all*" matchende Wortlisten gelten für alle Deutschen Wörterbuch-Varianten. Entsprechend gelten auf "*-de_DE*", "*-de_AT*" und "*-de_CH*" matchende Wortlisten nur für diese jeweiligen Wörterbuch-Varianten. Helvetismen stehen daher z.B. alle in *-de_CH* Dateien. - positiv-Wortlisten enden alle auf .txt - negativ-Wortlisten (blacklists) enden nicht auf .txt und fangen mit "blacklist" an. - konservative (aber korrekte Schreibweisen) wie Delphin (vs. Delfin) stehen in Wortlisten die auf "*-a-*" (wie alt) matchen, die Neuschreib-Versionen (Delfin etc.) stehen im entsprechenden Gegenstück, was auf "*-n-*" (wie neu) matcht. - komponierbare Wörter, die in einem symbolischen "abc"-Kompositum die Stellen a und b einnehmen können, stehen in compound-* Dateien. - komponierbare Wörter, die in einem symbolischen "abc"-Kompositum an Stelle b stehen können, stehen in "middle-compound*" Wortlisten Das was noch nicht mögich ist, ist das Erzeugen von adjtikivischen Komosita, wie "verletzungsbedingt/A" etc. Damit aber für den Tag, an dem das mal funktionieren wird, die Wortlisten entsprechend vorbereitet sind, sollten solche klein geschriebenen Komposita ebenfalls in eine *-xx* datei, auch wenn das bis jetzt noch keinen Effekt hat. Wenn es soweit ist, wird dann auch so ein Wort wie "verletzungsbedingt" wegoptimiert werden. Die compound-Listen sind inzwischen schon recht gut gefüllt und meist ist bei noch unbekannten Kompositas es inzwischen besser, die Komposita in die "*-xx*"-Dateien aufzunehmen, weil es zu wenig Komosita mit dem noch nicht bekannten komponierbaren Wort gibt oder die Aufnahme des komponierbaren Begriffs zu häufig zu seltenen Falschvorschlägen kommen würde. Ich würde vorschlagen, dass *compound*-Dateien daher eher nicht erwqeitert werden, sondern statt dessen Komposita in -xx Datein eingetragen werden. Wichtig ist noch, dass der "Zeichensatz" der Wortlisten recht spezell ist, das hat historische Gründe, weil Ispell und Unix mit nicht-ASCII-Zeichen nicht immer so umgehen konnten wie heute. Ä Ö Ü ä ö ü werden A" O" U" a" o" u" und ß wird sS geschrieben in den Wortlisten. Andere Zeichen, die benutzt werden können, dann in iso8859-1-kodiert, sind: à â ç Ç é ë ê ï ñ. An Stellen, wo eine Ligatur aufgetrennt werden müsste (wie bei Auf|finden), wird ein "qq" eingefügt, was für "rmligs", was von igerman98 gebaut werden kann benötigt wird. Da müsst ihr euch aber eigentlich nicht mit befassen, das würde ich dann selbst beim Übernehmen von Worten machen. Ja, das ist eigentlich schon alles, was man beachten muss. Wie ihr seht gibt es hier keine fest vorgegebenen Dateinamen, nur Teilstrings auf die die Dateinamen matchen müssen. Es ist daher auch nicht notwendig, dass irgendwelche Dateien gelockt werden oder ähnliches. Jeder kann also "seine" Wortlisten, die er unabhäängig beisteuern will in seine eigenen Dateien einpflegen. Wenn du Adjektive hinzufügen willst, reicht es z.B "einadjektiv/A" in adjektive-de_all-deinpersoenlicheskuerzel.txt hinzuzufügen. Es ist wichtig, dass hier ein eindeutiges persoenliches Kuerzel mit im Dateinamen steht, damit nicht andere Dateien ueberschrieben werden. Wenn diese Datei dann im dicts-Verzeichnis liegt und z.B. ein "make hunspell/de_DE.dic" gemacht wird wird das automatisch berücksichtigt. Entsprechend würde auch eine Liste von Komposita, die du in eine Datei "deine_komposita-xx-de_all.txt" packst automatisch optimiert gekürzt, also um überflüssige Einträge erleichtert und dann das entsprechende Hunspell-Wörterbuch erzeugt. Durch das unabhängige Arbeiten, was hiermit möglich ist, kann ich auch weiterhin so penibel sein, wie zuvor und jeden Eintrag, den ich in meine Wortlisten aufnehme selbst von Hand prüfen. Ein Hunspell-Wörterbuch mit -Erweiterungen" könnte man sich dann einfach so erstellen, indem man das aktuelle igerman98 nimmt, dazu ein solches Erweiterungs-Addon von im dicts-Verzeichnis auspackt und make "hunspell/..." aufruft. Welche Erweiterungen Projekte wie OpenOffice.org, Mozilla oder die Linux-Distributoren dann letztlich zusaätzlich einbinden, können sie selbst entscheiden. Nach diesem Baukastenprinzip kann ich fast so weiterarbeiten wie zuvor (mit einer gewissen Abneigung gegen kurzzeitgeschichtliche Eigennamen und allzu ungebräuchliche Wörter) und die Erweiterungen von anderen könnten dann auch ohne Verluste und ohne Auseinanderdriften der Arbeiten deutlich effektiver zum Wörterbuch beitragen. Wie sollte letztlich so ein Addon-Paket für igerman98 geschnürt werden? Es sollte natürlich ohne Fehler mit igerman98 bauen, die Zeilenenden sollten im Unix-Stil nur mit einem Newline enden (kein ^M oder Caridgereturn). Es sollte direkt im Archiv ein README.deinkuerzel mit Informationen zur Herkunft etc. liegen, die Wörterbuch-Dateien sollten in einem Unterverzeichnis dicts/ liegen. Das Archiv sollte im .tar.gz-Format gepackt sein. Wenn man das fertig hat, kann man es mir schicken (bjoern at j3e.de), ich sammel die Addons dann hier im contrib-Verzeichnis. Björn Stand: 2008-01-25