Am besten sammeln, und dann mal an geeigneter Stelle (evtl. im Wiki) die IDs posten. Sortiert nach Problem wäre toll. Einiges sind Fehler durch die alte Beta-Version. Einiges sind falsch konvertiert, wo man nochmals den Tag2XmlConverter rüberjagen müsste. Bei einigen sind die Ausgangsdaten schon falsch, usw. Es gibt da genug Ursachen.

Bei den Links müsste ich mal schauen, warum die nicht einheitlich sind. Ein paar Bilder haben wir auch schon zu einigen Einträgen, allerdings bin ich noch nicht dazu gekommen das ordentlich einzupflegen. Da ist noch einiges an Arbeit zu tun.

Das ist ein Problem unterschiedlicher Apostrophen, wenn ich die mal so nennen darf.

Ich bin mir nicht sicher, welche Variante die korrekte ist. Deswegen wurde das bisher so belassen. Ich meine, das ist dann eher in den Daten zu korrigieren bzw. zu vereinheitlichen, bevor man da was am Code ändert.

Aktuell ist das hier http://www.wadoku.de/wiki/display/WAD/DaRomajiBearbLesung

Apostroph trennt Silben, die sich auf unterschiedliche Kanji beziehen

Ein fehlerhafter Eintrag, der fehlerhaft geparst wurde, und deshalb fehlerhaft angezeigt wird. Weitere Fragen?
So wäre es richtiger.

<entry version="1.1" id="9243926" xmlns="http://www.wadoku.de/xml/entry">
    <form>
        <orth midashigo="true">
            <text>△雷</text>
        </orth>
        <orth>
            <text>いかずち</text>
        </orth>
        <orth irr="true">
            <text>雷</text>
        </orth>
        <pron>
            <text>いかずち</text>
        </pron>
        <pron type="hatsuon">
            <text>いかずち</text>
        </pron>
    </form>
    <gramGrp>
        <pos type="N"/>
    </gramGrp>
    <usg reg="lit"></usg>
    <usg type="time">obsol.</usg>
    <sense>
        <trans>
            <tr>
                <token type="N" genus="m">Donner</token>
            </tr>
        </trans>
        <trans>
            <tr>
                <token type="N" genus="m">Donnerschlag</token>
            </tr>
        </trans>
    </sense>
</entry>

Viele solcher Datenfehler sind schon durch die automatisierte Bearbeitung und der damit einhergehenden mehr oder weniger expliziten Validierung aufgefallen und weitestgehend behoben. Deshalb wundert es mich nicht, wenn du auf weitere stößt. Das Beste ist, wenn du die sammelst, damit man die mal korrigieren kann.
Es gibt leider nicht nur syntaktische Inkonsistenzen in der Auszeichnung der Daten sondern auch semantische. Z.B. das "obsol." wird mal als <LangNiv.: obsol.> und mal als <Usage.: obsol.> gekennzeichnet.

Zurzeit wird der Einfachheit halber die eingebaute XSLT-Engine genutzt, weiß gerade nicht, welche das ist.
Es ist möglich, dass andere schneller sind, du kannst da ja mal nachforschen, wenn du Zeit hast

Programmtechnisch erschien es einfacher das <text/>-Element einzuführen, auch wenn es unnötig erscheint. Aber das ist ne andere Geschichte.

Das XML ist sozusagen das Backend, daraus werden der Suchindex (derzeit per Java, per XSL wäre aber eine Option) und die ganzen Daten zur Anzeige (per XSL) generiert. Die generierten Anzeigedaten werden aus Performancegründen noch in der DB gespeichert. Eine Generierung on-the-fly wird in Spezialfällen genutzt, bei einem stärkeren System ist der generelle Einsatz denkbar.

boscowitch wrote:achja eine frage gäbes da noch, die
[1] [2] [3] welchem tag ensprechen die,

<sense/>

und in der lesung gabs die ja auch bzw auch in der jap schreibweise,
welche bedeutung hatten die da eigentlich ? und bekomm ich die aus einem entry parsing auch raus oder muss ich da mehrere beachten ?

Die dienten der Kennzeichnung von Homophonen bzw. Homographen (siehe Wiki). Das kannst du ignorieren, da es im XML nicht mehr gepflegt wird.

boscowitch wrote:
aber mit was gjiten auch umgehen kann ist mit mehereren wörtern am anfang also allen schreibweisen und nich nur eine, ich weis niich inwiweit das dem EDICT standard entspricht kann halt sein das gar nicht ^^.

Wenn es das ist, was ich denke, dann nennt sich das EDICT2 :o

Na wie auch immer, ich würde es eben besser finden, wenn man die ganzen Konvertiergeschichten gebündelt angeht, dann kann man auch gewisse Mängel an den Daten angehen. Und wenn XSL eben zu komplex wird, oder nicht mächtig genug erscheint, kann man immer noch Algorithmen in anderen Sprachen drüberjagen.

Da man die Konvertierung nicht dauernd macht, ist der Unterschied eher vernachlässigbar, so dass ich da portablen Formaten eher den Vorzug gebe.

Aber mal ne Frage zu dem gjiten. Für mich sieht das so aus, als ob das ziemlich genau dem EDICT-Format entspricht, oder? Da gibt es schon ein XSL mit dem ja der aktuelle EDICT-Export erstellt wurde. Deshalb mal die Frage, warum du da das Rad neu erfinden möchtest? Und sei es nur aus akademischen Gründen Du sprichst ja auch von Aufwand, und ich sage mal, in den bestehenden XSL-Dateien stecken schon ein paar Jahre Entwicklung.

XSL ist ziemlich performant, wenn man nicht unnötig komplexe Regeln einbaut

Mit der oben von mir geposteten Transformation über den gesamten Datenbestand geht das auf einem Core Duo mit 1,6 GHz noch recht fix.

localhost:~ dan$ time ./dictransform.pl ../wadoku-top/webapp/src/main/webapp/xsl/entry_export_macdic.xslt wadoku.xml > /dev/null
real	3m35.808s
user	3m32.094s
sys	0m1.252s

Das Bauen des Mac-Dictionary hingegen braucht schon fast ne Stunde

Wenn du Speicherprobleme bekommst, solltest du bedenken, dass es meist nie eine gute Idee ist, das gesamte XML-Dokument im Speicher zu halten. Um den Speicherverbrauch im Rahmen zu halten, hab ich nen kleines Perl-skript, das jeweils nur einen <entry/> an libxslt übergibt. Etwa so

while ($record = <FILE>) {
        if ($record =~ /^<entry /) {
                $source = XML::LibXML->load_xml(string => $record);
                $results = $stylesheet->transform($source);
                $res = $stylesheet->output_as_bytes($results);
                $res =~ s/ xmlns:d="http:\/\/www.apple.com\/DTDs\/DictionaryService-1.0.rng" xmlns="http:\/\/www.w3.org\/1999\/xhtml" xmlns:wd="http:\/\/www.wadoku.de\/xml\/entry"//g;
                print $res;
                print "\n";
        }
}

Warum das Ganze nicht einfach per XSL? Ich hab hier mal fix was gebastelt (https://gist.github.com/813338), das sieht auf den ersten Blick schon recht gut aus (siehe Bild), wie ich finde. Natürlich sind noch einige Macken drin, die ausgebügelt werden müssen. Die bisherigen Exports (Edict) werden auch per XSL realisiert, deshalb würde ich es begrüssen, wenn ihr vielleicht daran mitarbeiten könntet.

Ich war so frei, die Version von system auf dem Server hier zu spiegeln (http://www.wadoku.de:81/downloads/Wadoku.dictionary.dmg). Hat mich einige Mühen gekostet, das überhaupt erstmal von Rapidshare auf den Server zu kriegen :/

Einige Gestaltungselemente wurden in die CSS ausgelagert, haben IDs bekommen usw., vielleicht kannst du nochmal drüberschauen.

Die Markierungen zu entfernen ist wohl erstmal nur durch Javascript möglich. Ich bin noch unschlüssig, ob eine andere Auszeichnung sinnvoller ist. Und wenn, kommt das wohl etwas später, da dann auch die Auszeichnung im XML entsprechend geändert werden.

Das CSS werde ich noch etwas bearbeiten und dann mit einbauen. Ein paar Elemente bekommen noch eine ID oder Klasse zugeordnet, um einige eher unschöne Selektoren zu vermeiden

Ja, der Login sollte weiterhin zugänglich sein.
Das feste Leerzeichen vor den Genusangaben wird demnächst per CSS gesetzt werden, und kann dann einfacher weggelassen werden.

Beabsichtigt sicher nicht.
Warum soll man diese Diskussionen vermeiden wollen? Ein Projekt lebt von der Diskussion um Verbesserungen usw., wenn es sich entwickeln soll. Deswegen bin ich immer recht glücklich, wenn Feedback kommt und solche Punkte angesprochen werden. Auch wenn sich Probleme eleganter vorbringen lassen, als durch, ich möchte hier keinem zu nahe treten, mir kindisch anmutende Trotzreaktionen. Vielmehr könnte man doch eher darüber nachdenken, wie man Dinge verbessern kann, entweder einfach durch Hinweise oder anderweitige Unterstützung.

Jeder Nutzer hat ein anderes Anforderungsprofil, andere Sehgewohnheiten usw. Man kann es somit gar nicht allen recht machen, man muss Kompromisse finden. Das heisst auch, dass mal etwas umgesetzt wird, was bei einigen auf Widerstand stösst, aber man kann ja über alles reden. Und ich finde, in diesem Thread haben wir so schon gute Fortschritte erzielt, mein Dank an dieser Stelle an alle Beteiligten.
Also was ich eigentlich sagen wollte ist, dass man schon etwas aktiv werden muss, wenn etwas verändern möchte.

Nur kurz noch zur alten Version: Ich persönlich komme nicht mit der Farbgestaltung klar, die ist für mich einfach zu grell. Die anderen Funktionen werden noch nachgerüstet.

Hehe, so hab ich mir das vorgestellt
Wenn sich ein paar Stimmen dafür finden, spricht eigentlich nichts dagegen, das mit in die Themenauswahl aufzunehmen.