Ältere Versionen der Quellen finden sich hier:

• Stand 2012-08-07

• Stand 2012-08-15

Alle weiteren neueren Versionen liegen ab sofort im svn-Repository, das mit folgendem Befehl ausgecheckt werden kann:

• svn co https://wiki.lugfrankfurt.de/progproject/svn (Passwort ist das wiki-passwort)

Weitere nützliche svn-Befehle:

• svn update (bitte jedesmal vor Beginn von Code-Bearbeitungen und auch nochmals unmittelbar vor dem commit ausführen)

• svn commit -m "Kommentar zwingend erforderlich!"

Interlinear-Baum

Um den aktuellen Stand der Interlinearversion eines Textes festzuhalten, soll er intern in Form eines Baumes dargestellt werden.

• An der Wurzel und damit auf oberster Hierarchiebene steht dabei das Dokument selbst.
• Die zweite Hierarchiebene bilden im folgenden als "Referenzen" bezeichnete Gliederungseinheiten des Textes. Dies können nach Wahl des Benutzers beispielsweise einzelne Sätze oder Absätze des zu interlinearisierenden Textes sein.
• Auf der dritten Hierarchieebene folgen dann die jeweils einem Knoten zugewiesenen Wörter des Ausgangstextes.

Beispiel

Hier anhand eine graphische Darstellung der oben genannten Entsprechungen zwischen der Interlinearversion eines Textes und zugehörigem Interlinearbaum.

Auf der linken Seite findet sich die Interlinearversion des Textes, auf der rechten der zugehörige Interlinearbaum.

Intern wird der Interlinearbaum derzeit durch Knoten der folgenden Struktur dargestellt:

• zu übersetzende Worte werden dabei als utf-8 Zeichenkette im Feld label gespeichert.

• das Feld data soll es später ermöglichen zusätzliche Daten mit einem bestimmten Konten des Interlinearbaumes zu verknüpfen, findet zur Zeit jedoch noch _Keine_ Verwendung.

• gedacht ist hierbei daran es zu erlauben während des Interlinearisierungsvorgangs beliebige JSON-Texte mit einem bestimmten Knoten des Interlinearbaums verknüpfen zu können.

   1 struct _ShsNode {
   2   ShsNode *next;
   3   ShsNode *prev;
   4   ShsNode *parent;
   5   ShsNode *children;
   6 
   7   const gchar   *label;
   8   gpointer data;
   9 }; 

Um gegebenenfalls einen späteren Austausch der verwendeten Datenstruktur zu erlauben sollte nach Möglichkeit _nicht_ direkt auf diese Struktur zugegriffen werden, sondern über die zur Verfügung stehenden Zugriffsfunktionen.

Zu Testzwecken ist ein direkter Zugriff auf die verwendete Struktur aktuell durch einbinden des Headers "shs-node.h" zwar noch möglich - die zugehörige Definition soll aber früher oder später von dort in "shs-node.c" verschoben werden um versehentlichen Zugriff auf die interne Struktur zu verhindern.

Knoten API

Hier eine übersicht der derzeit zur Verfügung stehenden Funktionen zur Bewegung im Interlinearbaum

Darstellung am Bildschirm

Die Darstellung der Interlinearversion eines Textes erfolgt derzeit so, dass jeweils die label sämtlicher Kinder eines Knotens bündig unter dem label des Knotens selbst dargestellt werden.

• zur Bestimmung der korrekten Ausrichtung und der korrekten Breite eines labels stehen derzeit Funktionen zur Berechnung von Breite (width) und Abstand vom Zeilenanfang (offset) zur Verfügung.

Einzelne Zeilen können derzeit mit der Funktion node_pretty_line_string () erstellt werden.

Darstellung mit Gtk

Zur Darstellung wird derzeit ein GtkTextView Widget verwendet.

Für jede Referenz (s.o.) der Interlinearversion wird dabei eine eigene Textmarke (GtkTextMark) in den zugehörigen Buffer (GtkTextBuffer) eingefügt.

• derzeit werden die GtkTextMark Marken lediglich über den im zugehörigen Referenzknoten abgelegten label identifiziert. Bei zwei identisch benannten Referenzen in ein und demselben Dokument wird dies zu Schwierigkeiten führen.

• Auch wenn zwei identisch benannte Referenzen nicht sehr sinnvoll erscheinen sollte hier eventuell ein 'gescheiterer' Ansatz gewählt werden.

Einfügen und Löschen des zugehörigen Textes ist derzeit mit Hilfe der beiden Funktionen insert_ref (), bzw. delete_ref () möglich.

• Falls ein Auslösen der selben nicht erwünscht ist sollte bei Verwendung beider Funktionen darauf geachtet werden, dass vor Verwendung die beiden Signalhandler "insert-text", bzw. "delete-range" blockiert werden.

Konsistenz

Um Bildschirmdarstellung und Interlinearbaum konsistenz zu halten ist es erforderlich den zugehörigen Interlinearbaum sowohl beim Einfügen, als auch beim Entfernen von Zeichen aus dem Textpuffer entsprechend anzupassen.

Dies sollte in den Signalhandlern "insert-text", bzw. "delete-range" möglich sein, ist derzeit aber noch _nicht_ implementiert.

Regeln

Um die Gestaltung der beim Interlinearisierungsvorgang verwendeten Regeln möglichst flexibel zu halten werden zur Verfügung stehende Regeln derzeit mit Hilfe folgender Struktur beschrieben:

   1 struct _RuleInfo {
   2   const gchar *id;
   3 
   4   Rule* (*create) (JsonNode *options);  
   5   void (*destroy) (Rule *rule);
   6   GList* (*apply) (Rule *rule, ShsConfig *config, ShsNode *node);
   7   JsonNode* (*export) (Rule *rule);
   8 
   9   GtkWidget* (*build_widget) (Rule *rule);
  10 };

Felder

• id ist ein eindeutigen Bezeichner für diese Regel.

Callbacks

• create (), bzw. destroy () werden einmalig beim Anlegen, bzw. beim Löschen einer Regel aufgerufen.

• export () exportiert die Regel in eine Beschreibung im JSON-Format.

• In einer Konfigurationsdatei abgelegt soll es beim späteren Einlesen möglich sein die Regel vollständig aus diesen Daten zu 'rekonstruieren'.

• Derzeit wird diese Beschreibung der Funktion create () übergeben - hier dürfte es allerdings vermutlich vernünftiger sein diese Operation in eine weitere Operation configure () auszulagern und eine Operation create () mit Argumentliste (void) lediglich eine Regel mit 'vernünftigen' Vorgabewerten erzeugen zu lassen.

• apply () verrichtet schließlich die eigentliche Arbeit, indem sie die zu einem Knoten des Interlinearbaums sämtliche Kandidaten für eine Übersetzung in Form einer Liste von JSON-Texten zurückgibt.

• derzeit _müssen_ die zurückgegebenen JSON-Texte zwingend von folgendem Format sein, dies soll sich zu einem späteren Zeitpunkt jedoch noch ändern.
  • Das erste Format dient der Übersezung eines Konten in einen einzigen anderen
  • Das zweite Format findet bei Übersetzung eines Knotens in mehrere andere Knoten Verwendung

   1  { "key" : "...", "value" : "...." }
   2  { "key" : "...", "value" : [ "...", "...", ... }

Regel API

Zur Registrierung neuer Regeln steht derezeit die Funktion register_rule () zur Verfügung.

Nach Registrierung einer Regel können Regeln dieses Typs dann mit der Funktioner rule_new () erzeugt werden.

rule_lookup () (offensichtlich nicht sehr konsistent benannt! ... diese führt nämlich die Operation apply aus), rule_export () und rule_free () ermöglichen einen Aufruf der in der zugehörigen RuleInfo hinterlegten callbacks.

Regeln

Weit von einem für die Praxis tauglichen Stand entfernt befinden sich derzeit folgende Regel-Prototypen:

• "simple-lookup" führt einen Lookup in einer in der Konfiguration hinterllegten Box durch

• "process" füttert den label eines zu übersetzenden Knotens an einen externen Prozess und liest dessen Übersetzungsvorschläge über eine Pipe zurück.

• "socket" übergibt den label des zu übersetzenden Knotens an einen TCP Socket und liest entsprechende Übersetzungsvorschläge von dort zurück.