also da wir mind zu 3. wohl an den xsl scripts rumfummeln mach ich hier mal nen sammel thread über sachen die auffalen auf damit das nich so verstreut in anderen threads ist bzw. über pm.

ich arbeite grad an detailed edict exports (gjiten mäsig also nicht 100% edict1 oder edict2 format)

eins das aber ins alte auch noch rein sollte wäre das links ignoriert werden oder anders ausgegeben ohne http das sieht nämlich doof aus:

漢字検定 (かんじけんてい) Kanji-Leistungstest (Abk.)http:; ; www.kanken.or.jp; ;

da die / zu "; " werden.
auserdem kenn ich auch kein edict viewer der klickbare links anzeigt.
daher hab ichs erstmal nur rausgehaun:

<xsl:template match="wd:link"/>

falls jemand einträge kennt bei dennen ohne link keine übersetzung existiert bitte melden, dann müsste man doch mit der replace template das http:// raus haun.

edit: änderungen die ich sonst noch zu edict hinzugefügt habe falls jemand was änliches braucht:

  <xsl:template match="wd:sense">
        <xsl:if test="count(preceding-sibling::wd:sense)=0">
            <xsl:text> </xsl:text>
        </xsl:if>
        <xsl:if test="count(../wd:sense)>1">
        <xsl:text>/[</xsl:text>
        <xsl:value-of select="count(preceding-sibling::wd:sense)+1"/>
        <xsl:text>]</xsl:text>
        </xsl:if>
        
        <xsl:apply-templates/>
    </xsl:template>

   <xsl:template match="wd:trans[@langdesc='scientific']">
        <xsl:text>/(wiss. N.:)</xsl:text>
        <xsl:value-of select="text()"/>
        <xsl:apply-templates/>
    </xsl:template>
    
    <xsl:template match="wd:usg[not(text()) and @reg='lit']">
            <xsl:text> /</xsl:text>
            <xsl:text>(schriftspr.)</xsl:text> 
    </xsl:template>

    <xsl:template match="wd:usg">
        <xsl:choose>
            <xsl:when test="@type='dom'">
                <xsl:text> /</xsl:text>
                <xsl:text>{</xsl:text>
                <xsl:value-of select="text()"/>
                <xsl:text>}</xsl:text>
            </xsl:when>
            <xsl:when test="@type='hint'">
                <xsl:text> /</xsl:text>
                <xsl:text>{</xsl:text>
                <xsl:value-of select="text()"/>
                <xsl:text>}</xsl:text>
            </xsl:when>
            <xsl:when test="@type='time'">
                <xsl:text> /</xsl:text>
                <xsl:text>(</xsl:text>
                <xsl:value-of select="text()"/>
                <xsl:text>)</xsl:text>
            </xsl:when>
        </xsl:choose>
    </xsl:template>

Ok, die Links fliegen aus dem Edict-Export raus.

Der zweite Teil sieht mir etwas umständlich aus, position() sollte da ausreichen.

<xsl:template match="wd:sense">
        <xsl:if test="position()=0">
            <xsl:text> </xsl:text>
        </xsl:if>
        <xsl:if test="count(../wd:sense)>1">
        <xsl:text>/[</xsl:text>
        <xsl:value-of select="position()"/>
        <xsl:text>]</xsl:text>
        </xsl:if>
        <xsl:apply-templates/>
    </xsl:template>

Die Regel not(text()) in Zeile 20 kannst du weglassen.

Und der letzte Teil lässt sich vereinfachen, obwohl eigentlich nur die dom in geschweiften Klammern gesetzt sind.

<xsl:template match="wd:usg[@type]">
        <xsl:choose>
            <xsl:when test="@type='time'">
                <xsl:text> /</xsl:text>
                <xsl:text>(</xsl:text>
                <xsl:value-of select="text()"/>
                <xsl:text>)</xsl:text>
            </xsl:when>
            <xsl:otherwise>
                <xsl:text> /</xsl:text>
                <xsl:text>{</xsl:text>
                <xsl:value-of select="text()"/>
                <xsl:text>}</xsl:text>
            </xsl:otherwise>
        </xsl:choose>
</xsl:template>

Oder so

Hmm, ich hatte die Tage mal angefangen ein Web-Basierendes Programm zum lernen von Grammatik und Vokabeln (inklusive Kanji usw usw) zu schreiben.

Der Gedanke entstand vor allem daraus, dass ich bisher keine geeigneten Angebote in Web gefunden hatte. So ist mir z.B. das lernen von Vokabeln in unterschiedlicher Schreibweise immer zu kurz gekommen. Oder aber, es gab keine Möglichkeit die Abfragen z.B. an das Lehrbuch anzupassen das man gerade benutzt. Oder gar an solche Sachen wie den N5 oder N4 Test.

Als Grundlage würde ich gern das Wadoku benutzen. Aaalllerdings habe ich da dieses lustige Formatproblem. Ich kann mir ja denken, dass es für einige Anwendungen Ideal ist. Allerdings hätte ich es doch gerne in etwas ähnlichem wie einen SQL Format. Oder vielleicht auch CSV. Oder einfach nur etwas weniger ausführlichem so das mich das schreiben eines kompletten Import Scripts weniger Zeit kostet, als die Daten einfach selber abzutippen ^^

Kurzum: Ich habe hier mal einige Threads gelesen. Ihr redet oft von euren Scripten usw. Ich frage nun einfach mal sehr direkt: Würde mir denn jemand einen SQL Dump überlassen? Oder ggf. auch ein CSV? Schließlich liegen sie ja hier auf der Homepage schon in einem entsprechendem Format vor. Nur leider nicht in der DL sektion :/

(sorry wenn dies ein Repost sein sollte. Die Suchfunktion brachte keine anderen Aktuellen Themen zum Vorschein)

hi, also ich schreibe mir gerade einen simplen converter in java,
der nutzt xslt um sich die informationen zu extrahieren die er will und geht entry per entry durch.

sich eine cvs oder db zu machen ist auch ziel davon als erstes eine simple sqlite file, ein tab-file für stardict conversion und ein gjiten file.

das ganze kann man auch per xsl selbst machen, xslt ist eine xml technik und eine sehr minimale "sprache" zum umwandeln der daten.

die ausgabe auf der website aus der datenbank entsteht auch per xslt aus xml daten die blos in einer db spalte sind also wird ein db dump nicht sehr hilfreich sein auser man will gecached output mti html durchsetzt.

also das schnellste ist sich die xsl files anzugucken das anzupassen und die wadoku xml datei + xsl file durch einen xslt parser zu schicken (das benötigt viel ram daher mach ich einen java converter der das xsl script nru immer auf 1. entry ausführt)

für alle die das mit dem xsl zu compliziert finden versuch ich eben meinensimplen javan converter zu machen, der intern xslt benutzt aber dann einfach eine Entry struktur mit den feldern

japanese, reading und translation

so ich hab mal meine "ultradollen" java converter auf github gepusht.
Der Hauptvorteil daran ist, das man sich nicht selbst um das xsl kümmern muss, es sei denn man will das es ganz anders ausgegeben werden soll und sich nicht per einfachen java replaceAll und regex zu realisieren ist.

Auserdem wird das xml geladen und dann jeder entry einzeln geparsed so das man nicht über 1GB RAM braucht um die wadoku.xml Datei zu parsen.
Das ganze ist dann noch OOP orientiert sodas man einfach neue Exporter und Importer schreiben kann.

Ein weiterer Vorteil ist das man direkt aus dem Java Code auch z.b. statt die Daten zu konvertierne sie auch direkt in eine Datenbank oder ähnliches stecken kann.

Es ist wirklich nichts besonderes und noch was hässlich da momentan eher alles hart kodiert ist, die main Methode ist noch nicht fertig und der IndexedSQLiteExporter auch nicht, nur ein pseudo TabfileExporter zum testen.

der JMdictImporter scheint recht gut zu laufen, beim WadokuImporter bin ich mir noch nicht sicher ob er bei der Deutschen Übersetzung alles richtig macht in dem wadoku_entry_german.xsl Script.


Auserdem musste ich komische Hacks im xsl Skript machen, da beim bearbeiten von den einzelnen entrys die Funktionen position() und last() Werte nicht immer stimmen und ich entweder eine Konstante abziehen musste:
<xsl:if test="count(../wd:sense)>1">
<xsl:text>[</xsl:text>
<xsl:value-of select="position()-2"/>
<xsl:text>]</xsl:text>

oder mit count() es manuell machen berechnen musste..

warum auch immer .... also die Ergebnisse sollten noch erstmal Überprüft und das xsl verschönert werden.

Der code soltle ein eclipse projekt ordner sein (hoffe alle eclipse file sind dabei die man braucht)

https://github.com/boscowitch/WajitenxsltConverter

Momentan kann man ein Import/Export so machen indem man einfach
sich den gewünschten Importer und Exporter erzeugt durch:

WadokuImporter in = new WadokuImporter("HIER/PFAD/ZUR/WADOKU/XML/DATEI");

TabfileExporter ex = new TabfileExporter();

(alternativ kann man hier auch eine export Datei angeben durch:
TabfileExporter ex = new TabfileExporter("PFAD/exported_tabfile.txt");

(wenn nicht gibt erst einfach in der Shell aus)

ex.export(in);


als nächstes wollte ich jetzt meine SQLexporter machen und noch ein Mulieplen exporter der in mehrere Formate auf einmal exportiert.

Natürlich fehlt noch eine schönere Main Methode damit man alles per Parameter übergeben kann.

EDIT:
Entschuldigung wegen dem zusammen kopierten Text,
habe ihn einmal grob verbessert hoffe das alle "nen" und "en" weg sind .

@Dan mit dem Projekt Dateien hast du recht, ich finde das auch nicht so gut,
Ich habe nur noch nie ein Java Projekt veröffentlicht oder gar ein ant script selbst erstellt. Das mit dem Maven klinkt interessant.

Ich hab nur kurz draufgeschaut, aber vielleicht ist es sinnvoller anstelle von Eclipse-spezifischen Daten (.project, .settings) ein Buildskript zu verwenden (Maven, Ant oder Ivy usw.). Meiner Meinung nach gehört sowas nicht mit ins Projekt (eher in .gitignore ), zumal man sich beispielsweise für ein Maven-Projekt ziemlich fix die Eclipse-Konfiguration generieren kann (mvn eclipse:eclipse wenn ich mich recht entsinne).

PS: Ist nicht böse gemeint, aber ehrlich gesagt, kann ich deinen geschriebenen Ausführungen teilweise sehr schwer folgen, was wohl vor allem an der Rechtschreibung und der fehlenden Gross- und Kleinschreibung sowie Zeichensetzung liegt. Deshalb wäre ich dir sehr dankbar, wenn du da ein bisschen mehr darauf achten würdest. Das macht es allen Lesern einfacher. Und zumal man bei einem Wörterbuch ja sehr sprachfixiert arbeiten. Wenn ich mir dann vorstelle, welche Probleme da vielleicht Nutzer mit Deutsch als Fremdsprache haben könnten, dann erscheint es mir doch sehr abschreckend.

ich versuche mich ein wenig an einer Umwandlung des July-XML-Dumps nach EPWING.

Wenn ich ein Sample von ein paar hundert Entrys aus dem XML-Dump extrahiere, kann ich auch schon etwas Brauchbares konvertieren

http://imageshack.us/photo/my-images/201/sampleb.png/

Das Layout ist natürlich noch verbesserungswürdig.
Als Basis habe ich das XSLT von github abgewandelt, was auf der Downloadseite verlinkt ist.
Leider habe ich das Problem, dass wenn ich den gesamten XML-Dump konvertieren möchte, die Konvertierung extrem langsam ist. Das gilt für mein abgewandeltes xslt, als auch für das Originale.

Speicher ist dabei nicht das Problem, sondern Zeit. Zuerst dachte ich, es liegt an der Standard-Java Library.
Aber auch xsltproc und saxon sind viel zu langsam, die Konvertierung würde so wahrscheinlich Tage dauern.

Hat jemand zufällig ein transform-Skript (Sprache/OS ist egal), bei dem ich quasi

./transform wadoku.xml processor.xslt > out.xml

eingeben kann, und < 1h warten muss?

Am Rechner kann es eigentlich nicht liegen
Wäre für so etwas sehr dankbar.

Soweit ich mich erinnere sind alle recht langsam. Wie hast du es den gemacht ? alles auf einmal parsen oder Eintrag für Eintrag wie in meinem alten Java Programm ?
Das Eintrag für Eintrag war wohl auch nicht super schnell aber unter Linux konnte ich etwas tricksen indem ich die Xml Datei und den Output komplett in ein im Arbeitspeicher liegendem Dateisystem kopiert hatte.

Unter Windows müsste man das halt in Java machen, und die komplette Datei erst einmal komplett in eine Buffer reinladen.
Dadurch muss er nicht dauernd auf die Festplatte zugreifen.

Wenn das einem immer noch zu langsam ist bleibt nur der Weg den ich ganz am anfang gehen wollte und zwar ganz auf Xslt verzichten und eine einfach einlese xml library zu verwenden, jedoch ist das der Code sehr schnell super kompliziert und man kann nur mit viel Aufwand Änderungen im Output hinzufügen. Aber als ich das mal ansatzweise in C (bzw. Vala) geschrieben hatte war ich im Minuten bereich für die ganze Xml Datei.

ich habe folgendes probiert:

1.)

try {

    TransformerFactory tFactory = TransformerFactory.newInstance();

    Transformer transformer =
      tFactory.newTransformer
         (new javax.xml.transform.stream.StreamSource
            ("trans.xslt"));

    transformer.transform
      (new javax.xml.transform.stream.StreamSource
            ("wadoku.xml"),
       new javax.xml.transform.stream.StreamResult
            ( new FileOutputStream("wad_converted.xml")));
    }
  catch (Exception e) {
    e.printStackTrace( );
    }
  

2.)./xsltproc -o wad_converted.xml trans.xslt wadoku.xml
3.) java -Xmx1024M -jar saxon.jar -o wad_converted.xml wadoku.xml trans.xslt

Die Datei wird in allen drei Fällen vollständig in den Speicher geladen. Das sind ca. 800 MB.
Danach läuft dann alles normal ab, es wird auch nicht geswappt nur halt alles schrecklich langsam.
Deswegen frage ich mich, ob ich wirklich entries step-by-step lesen muss. Denn ich ich habe ja kein Speicher,
sondern ein Performanceproblem.
Oder hängt das miteinander zusammen?

Naja, auf jeden Fall, auf der Downloadseite steht, daß das Mac-Wörterbuch mit dem xslt auf Github
transformiert wurde. Da mein xslt nicht so verschieden von dem ist, würde mich sehr interessieren,
wie das funktioniert hat, welcher XSLT-Prozessor verwendet wurde, und ob das Skript noch existiert.

PS: Aufgrund der Komplexität der Wadoku-XML Daten möchte ich nach Möglichkeit darauf verzichten, irgendein
XML-Processing händisch zu implementieren. Zudem ist ist das xslt für das Mac-Dictionary ziemlich gut finde ich. Es formatiert die
Einträge ansprechend, ohne gleich alle Informationen außer der Bedeutung wegzuwerfen. Ich möchte nach Möglichkeit
diese Konvertierung "richtig" machen, d.h. das ganze ähnlich ansprechend wie die 2008er EPWING Version zu machen -
nur diesmal mit allen Gaiji
Es hat mir sehr viel Arbeit bei der Konvertierung erspart, auf dem existierenden XSLT aufzubauen. Daher würde ich nach
Möglichkeit gern XSLT
benutzen.... Die Konvertierung des konvertierten XML-Files in EPWing bereitet allein schon genug Kopfzerbrechen

Also 800MB klingt ziemlich viel und dein Code ausschnitt sieht nicht nach einzel Entry bearbeitung aus nur nach einen Stream input.

In meinem Code habe ich wirklich das Xml file als String eingelesen und dem xsqlt parser immer nur ein Entry übergeben indem ich nach den <entry> tags gesucht habe.
So brauchte der Xslt Parser nicht viel vorarbeit leisten von Sachen die er für den aktuellen Eintrag gar nicht braucht.

Hier ist kannst ja mal mein ganzen Code angucken: https://github.com/boscowitch/WajitenxsltConverter

Ich erinnere mich leider nicht wie Performant es war aber schneller wird es wohl mit Xslt nicht gehen.

Die XSL-Transformation ist in der Tat sehr zeitintensiv, wenn man die Open-source Variante von Saxon benutzt. Die kommerzielle Version (Saxon-HE) ist um Magnituden schneller (ca. 1 Minute).

Für die Mac-Version geschieht die Umwandlung in zwei Schritten.
1. Umwandlung in das XML-Format, welches für das "Dictionary Development Kit" verständlich ist (mittels der Dateien auf github).
2. Umwandlung in das Mac-Dictionary-Format mittels dem bei XCode mitgelieferten Dictionary Development Kit. Hier sind im Wesentlichen nur ein paar Optionen anzugeben, Pfade anzupassen usw. Der Rest läuft dann eigentlich von allein.