Geschichte des Projektes

Damit das ganze wenigstens dokumentiert ist, schreibe ich hier die Vorgänge und Ideen geordnet nach Datum herein.
Diese Daten werden zur Zeit nur auf deutsch veröffentlicht.

16. Oktober 2005

Allgemeines:

Erstellen des Dokumentes. Forschen in den Erinnerungen. In den Kopfhörern läuft Mike Oldfield und eigentlich sollte noch etwas Nachtessen drin liegen. Es ist 19:50 Uhr, höchste Zeit also...
Unterdessen läuft die Dave-Band, leckere Teigwaren stehen auf dem Datenbankordner (Im Teller) und ich bin hochmotiviert, nach einer Woche Totalabstinenz durch eine christliche Kinderfreizeit. Ich hoffe, dass das Projekt bald so weit fortgeschritten ist, dass ich es öffentlich bekanntmachen kann. Jetzt in der Alpha-Phase gibt es noch diverse Abklärungen im Bezug auf die Datenbank zu treffen.
dict.leo.org hält sich bedeckt. Kein Wunder, die wissen ja nicht, was ich wirklich will. Es ist nur bekannt, dass sie keine DB einsetzen. Sollen sie. Bei diesem Projekt geht es nicht ohne. Ist auch etwas überheblich zu meinen, alle Sprachen irgendwie gesamthaft erfassen zu können, um sie online allen zur Verfügung zu stellen. Doch ohne Träume geht es eben nicht ;-).
Die Idee ist ja schon etwas älter, doch konkret habe ich mit ersten Vorbereitungen anscheinend im September 2004 begonnen. So zeigt es jedenfalls ein Dokument an. Sonst sind die meisten Schritte im Frühsommer 2005 vorbereitet worden. Mir gefällt Leo und Google mit den übersetzungen, doch eine Grammatik habe ich bis jetzt noch nicht gefunden. Klar, es gibt eine Kurzfassung beim WIKI, doch dies genügt professionellen Ansprüchen nicht und der Rest ist alles nur gegen Geld zu haben.
Ich denke aber, dass gerade so ein wichtiges Gebiet für jeden kostenlos erhältlich sein sollte. Ich hoffe nur, dass ich mit diesem Ansatz nicht zu spät komme und es läuft schon ein weiteres Projekt mit ähnlicher Zielrichtung, die aber weiter sind. Sonst schliesse ich meines und werde dort weiter arbeiten. Gibt nichts schlimmeres als ähnliche aber unkompatible Projekte auf diesem Gebiet.

Unklarheiten / Ideen:

Beim DB-Design ist es mir noch nicht klar, wie ich das gesamte nun genau aufteilen soll. Es existieren mehrere Aufzeichnungen, die aber einfach nicht in ein ER-Modell reinpassen wollen. Werde wohl einfach etwas implemntieren müssen und mich mittels Versuchen an eine mögliche Version herantasten. Wäre nicht so abwegig. Mache ich bei vielem anderen auch. Nur nicht zu viel Theorie :-)
Bei eventuellen Cookies in der DB könnte man noch vermerken, welche Sprache sich der User wünscht, dann müsste er dies nicht bei jedem aufsuchen ändern.
Soll dazu noch die Wortübersetzung mit der DB-Abfrage in eine Funktion ausgelagert werden, um sie einfach in jede Seite zu integrieren? Evtl. in den Header?
Wie sollen die Sprachen am besten abgekürzt werden? der 3stellige ISO-Code gefällt mir nicht, da es dort nicht einmal ein Kürzel für Schweizerdeutsch gibt, auch wenn dies in diverse Dialekte zerfalle würde. Wie soll es aber aufgebaut sein? Schliesslich wird das schriftdeutsch in mehreren Ländern verwendet. Ein Landspezifisches Kürzel ist also sinnlos. Höchstens als Verweis, wo die Sprache verwendet wird. Ich tendiere auf eine zwei- bis dreiteilige Bezeichnung wie de_ch_be (Hauptgruppe, Untergruppe, Spezialisierung). Es wäre hier der Schweizerdeutsche Dialekt Berndeutsch.
Die Hauptgruppe wäre wohl eine Sprachgruppe wie Deutsch. Die Untergruppe bezieht sich dann auf die Sprachregion und falls notwendig gibt es noch eine Spezialisierung.

Spezielles:

Alle Informationen in etwa einer Stunde aufgeschrieben ;-)
Unterdessen ist es etwas später. Die Uhrzeit nähert sich 22.30 Uhr. Zeit fü einen Break. Es geht weiter, Schritt um Schritt.

Änderungen / Fertiggestelltes

Habe das Variablenhandling auf Session umgestellt. Ist eigentlich recht einfach, wenn man es einmal gemacht hat. Wieso muss es nur immer so kompliziert oder unvollständig beschrieben sein? Nun, jetzt funktioniert es auf jeden Fall einmal bei mir ;-)
Dazu noch eine Routine zur Codierung des mailto eingebaut, falls die Routine mittels des Servers nicht funktioniert ;-)

18. Oktober 2005

Allgemeines:

Heute wollen die Seiten plötzlich nicht mehr mit den Sessionvariablen funktionieren. Keine Ahnung, wo das Problem liegt. Dazu muss man das Formular ja noch auswerten, was ja per Post-Befehl kommt. Da muss auch noch etwas gedreht werden.
Hoffe, die Seiten sind bald einmal so weit, dass ich mit der DB anfangen kann, weil der Rest funktioniert.

Unklarheiten / Ideen:

Die Formulardaten müssen übergeben werden. Fragt sich, ob man die Session-ID auch gleich so übernimmt, damit der Benutzer keine Cookies akzeptieren muss. Das würde dann über ein hidden-Feld gelöst.
Die Sessionvariablen dürfen anscheinend nicht gleich heissen, wie die Formularvariablen. Evtl. liegt da noch ein Fehler drin. Sonst kann man die Daten halt in die DB packen. Dann wird halt jedesmal auf diese zurückgegriffen, doch wenigstens funzt es dann hoffentlich. Will man eine Session explizit beenden, so benutzt man session_unset();

Spezielles:

Der Apache lässt sich mit folgendem Befehl testen. Dann wird die Seite 1000 Mal aufgerufen und so die Performance getestet. ab2 -n 1000 localhost/index.html

20. Oktober 2005

Allgemeines:

Endlich den Fehler gefunden. Danke des Internets. Scheint ein Fehler im Apache zu sein. Nach der Neuinstallation funktionierte alles wieder. Wie viel Zeit doch so etwas braucht.
Nun, den Aufbau des Headers etwas erweitert, so dass die Optionen des Formulars aus der DB kommen. Scheint bis jetzt aber noch keine Verbindung aufzubauen. Muss man wohl schauen, was da schief läuft.

11. November 2005

Allgemeines:

Es lief einiges in letzter Zeit. Habe daher nicht einmal alles notiert. Die Verbindung zur Datenbank funktioniert. Die Daten aus dem Formular werden nun ausgelesen und die Optionen dynamisch generiert.
In mysql die Tabellen begonnen vorzubereiten. Es gibt nun ein id-Feld zur Identifikation. Dazu wird der Text fonetisch dargestellt (irgend wann einmal). Es folgt der eigentliche Text und anschliessend ein Feld, das den Eintragstyp grammatikalisch beschreibt. Ist für eine erweiterte Suche gedacht. Dahinter folgen dann alle anderen Sprache mit einem Fremdschlüsseleintrag, der auf die entsprechende ID des Partnerwortes verweist.
Um nicht noch einmal das Rad neu zu erfinden, möchte ich möglichst viele öffentliche Dictionaries benutzen und einpassen. Zur Zeit ist jdictionary dran, das ich offline auseinandernehme.

Spezielles:

jdictionary ist javabasierend und bindet zur übersetzung Textdateien ein, bei denen ein Doppelpunkt zwischen Original und übersetzung trennt. Diese Dateien werden ausgelesen, mit Quanta von ISO8859 in UTF-8 konvertiert und danach in Openoffice aufgeteilt. Leider schafft es nur rund 65000 Einträge. Gibt mit der Aufteilung halt etwas mehr Aufwand, doch es funktioniert.
Leider muss immer noch ein Textbegrenzer rein, der danach halt in Kate wieder entfernt wird. Ist etwas umständlich, doch danach funktioniert der import mit:
load data infile '/srv/www/htdocs/sprachkurs/de/de_de2.csv' into table de_de (id,word);
ganz gut. Die Dateien speichere ich dazu im Sprachenordner, da sonst mysql keine Zugriffsberechtigung hat. Der Dateiimport ist nur root erlaubt.

Änderungen / Fertiggestelltes

Die id's müssen jetzt noch in die Gegentabelle, sonst ist das Grundgerüst deutsch, englisch fertig. Die anderen Tabellen werden nicht mehr so einfach gehen, da dann die Verknüpfungen nicht mehr direkt eingetragen werden können.

Unklarheiten / Ideen:

Evtl. die Daten exportieren und mit den bestehenden Tabellen vergleichen und danach die id's generieren lassen. Mal schauen, ob das möglich ist.

14. November 2005

Allgemeines:

Es geht weiter, auch wenn mysql nicht immer so will, wie ich das verstehe ;-)
Über Nacht lief eine Importschleife, die einfach hochzählen sollte und bei jedem Datensatz hinten eine Zahl setzen sollte. In 8 Stunden schaffte er knapp 40000 Einträge.
So scheint ein automatisches einfügen recht mühsam zu werden, da der set-Befehl anscheinend nicht mittels Limit abgebrochen werden kann und daher immer alle Einträge abläuft.

Unklarheiten / Ideen:

Ist es möglich, den set-Befehl ähnlich wie ein select zu limitieren?
Kann man mit einem load data from file Daten ergänzen (überschreiben)?
Einen Ausweg habe ich, auch wenn er völlig unprofessionell ist. Es wird einfach die Tabelle exportiert und im Openoffice um die zusätzliche Spalte ergänzt. Danach kann wieder importiert werden.
Bei Firmen, Organisationen, Plätzen kann hinten noch eine Webadresse angefügt werden. Diese sollte beim darstellen dann gleich als Link erscheinen (programmieren). Das speichern sollte mittels UTF8 in mysql geschehen und wenn nicht möglich als binäre Daten, da es sonst mit den Spezialzeichen schwierig wird.

Änderungen / Fertiggestelltes

Nun sind die Datensätze deutsch und englisch fertig erstellt. Die gegenseitigen IDs sind hinzugefügt worden und ein paar fehlerhafte Einträge wurden korrigiert und ergänzt.

04. Dezember 2005

Allgemeines:

Die Zeit vergeht wie im Fluge und am Projekt tut sich währenddessen wenig. Wenigstens spriessen die Gedanken und mit etwas Abstand sieht man manches klarer.

Änderungen / Fertiggestelltes

Unterdessen kommt bei den Tabellen noch ein Feld hinein, damit man sieht, wer bestimmte Einträge erstellt hat(first) und wer sie als letztes geändert hat (last).
Durch diese kleine History ist wenigstens ein bischen gewährleistet, dass man fundierte Übersetzungen erhält und "Scherzkekse" entfernt werden können.
Bei den Typen wurde etwas ergänzt von dict.leo.org (11 und 12). Dazu gibt es dort anscheinend keine Akronyme des Internets. Diese wurden daher sofort noch eingegeben als Nummer 13.
Es gibt nun noch ein kleines Logo. Die Sonderzeichen wurden entschärft und es sollte kein Script mehr bers Textfeld ausgeführt werden können. Evtl. macht Urlencode noch Probleme. Das muss noch getestet werden.
Die Ausgabe ist unterdessen etwas formatiert und bei zu viel Treffern wird dies noch mitgeteilt. Jetzt muss nur noch die Gruppierung erfolgen.

Unklarheiten / Ideen:

Bei der Abfrage muss nach dem Wort ein Space rein, sonst funktioniert das like nicht richtig (zu viele Treffer). Dazu funzt ein reiner Vergleich natrlich nicht, da etwa beim Deutschen noch ein Artikel folgt.
Trotz "one fine day" in den Boxen läuft die Abfrage etwas kompliziert. Ich habe bemerkt, dass es mit dem Sprachschlüssel und der Verkünpfung der Browsereinstellung Probleme gibt, die Sprache zu spezialisieren. Da es dort meist keine eindeutige Sprachenkrzel gibt, sondern nur gängige Type mit dem Zweizeichenkürzel.
Wird warsch. auf zusätzliche Variablen hinauslaufen, was der Benutzer in der Auswahl wirklich gewählt hat. Oder der Code wird umgewandelt in den Datenbankcode mit Spezialisierung.
Neue Idee. Die DB-Codes sind alle nur mit 2 Zeichen beschriftet. Dort werden von allen grösseren (bekannten) Sprachen die Wörter abgebildet. Landes- oder sprachspezifische Ausdrücke einer Sprachuntergruppe kommen in zusäzliche Tabellen. Diese kann man in der erweiterten Abfrage anschauen. Bei Wörtern, die nur in einem gewissen Teil vorkommen, oder anders verwendet werden, kann dies mit einem Kürzel gekennzeichnet werden wie etwa bei den deutschen Artikeln. Eine kleine Liste unterhalb der Ausgabe erklärt die jeweiligen Kürzel. Beim Parsen wird einfach darauf geachtet, ob es Teile drin hat, die in geschweiften Klammern stehen.
Abfragen mit Umlauten werden nicht korrekt verarbeitet. muss wohl noch nachgebessert werden.
Der Rahmen um die Felder in der Ausgabetabelle wird nicht mehr angezeigt. Muss mal schauen, welche Eigenschaft hier die Einfärbung verhindert.

Spezielles:

Für die Akronyme gibt es viele Seiten im Netz. Werden wohl noch ein paar verlinken. Die Seite von Martin Strcker mit den Internet-Abkürzungen fiel mir als erstes ins Auge. Können aber sicher noch ein paar mehr sein.
Habe heute noch dict.cc gefunden. Ist interessant, da sie Einträge testen und schauen, wie viele Wörter drin sind. So könnte man auch noch sortieren.
Nun das eigentlich spezielle von heute: Die erste Abfrage ist gelungen. Es werden die richtigen Worte gefunden und bersetzt. Nun kann darauf aufgebaut werden.

05. / 07. Dezember 2005

Allgemeines:

Jetzt sollte ich doch eigentlich wissen, wo ich die Textdateien zu jdictionary finde...such.../usr/share/jdictionary. So schnell sollte es immer gehen.
Ja, das umstellen auf utf-8 ist so eine Sache. Muss die Dokumente von Hand konvertieren. Mal schauen, das kann wohl noch etwas Zeit in Anspruch nehmen.

Spezielles:

Konvertieren in UTF-8 aus einem jar-Archiv heraus. Zuerst wird die Datei mit dem Konqueror geöffnet. Mittels Ark wird sie in ein gewähltes Verzeichnis gespeichert. Nun ist sie auf der Konsole mit vi etwa öffbar und wird auch mit den Sonderzeichen richtig dargestellt. Mit iconv -f ISO8859-1 -t UTF-8 original.txt > neu.txt kann man sich den Rest sparen und direkt mittels OOo den Text extrahieren. Dort sucht man einfach mittels regulären Ausdrucken und schneidet so jeweils die vordere oder hintere Sprache ab und kann daher gut aufteilen.
OOo hat anscheinend Mühe mit dem Import von grossen Text. Scheint jedenfalls seit mehreren Minuten stillzustehen. Daher ist der nachfolgende Beschrieb nicht ideal.
Die Sprache hinten schneidet man mit " :.+:" ab. Leerzeichen nicht vergessen. Das Leerzeichen vorne bekommt man mit "^.x" weg. Da am Anfang immer ein Leerzeichen steht, funktioniert dies. Man muss halt einfach für jeden Buchstaben durchgehen und mit x ersetzen. Geht evtl. in Calc besser, doch der Writer findet ein Leerzeichen am Anfang leider nicht.
Daher vor dem entfernen in Calc übernehmen als CVS. Trenner ist der Doppelpunkt. Danach kann man dann in die Sprachen splitten.
Es gibt eine leere Vorlage, so dass man die Indexzahlen nicht mehr aufzählen muss. Leider habe ich mehr den genauen Weg gefunden, so extrahiere ich jetzt einfach die Sprache und kopiere sie in ein bestehendes Dokument. Den Doppelpunkt am Ende bekommt man mit " :$" weg. Die Anweisung schaut nämlich nur am Absatzende. Die Sprache vorne wird mit ".+: " entfernt. So ist auch der lästige Space am Anfang weg.

08. Dezember 2005

Allgemeines:

Jetzt läuft es besser. Ungarisch ist extrahiert in einer Datei. Habe das Importproblem unterdessen herausgefunden. Die Dateiendung heisst nämlich "csv" und nicht "cvs".
OOo2.0 scheint noch ein kleines Problem beim Import zu haben. Jedenfalls gibt es immer ein nicht darstellbares Zeichen bei den hu.cvs. Bei Bedarf kläre ich dies.
Damit ich die Befehle für den mysql auch später noch weiss, sind sie unten drin.

Spezielles:

Der Tabellenaufbau (de und en noch nachtragen):
create table hu (id int(10) unsigned, phonetic varchar(100),word varchar(100), type tinyint(3) unsigned, first int(11), last int(11), de int(10), en int(10), nd int(10), es int(10));
Dies für die ersten Sprachen. Neue müssen halt einfach mit "alter" hinzugefügt werden.
Jetzt noch den Primary Key:
alter table hu add primary key (id);

Unklarheiten / Ideen:

Jetzt sind die Abfragen gefragt, um zu testen, ob bestimmte Wortverknüpfungen schon in der Tabelle vorhanden sind. Annahme: Die Sprachen de und en sind schon vorhanden und gegenseitig verknüpft. hu soll jetzt neu dazukommen. Dazu gibt es eine Tabelle, in der die Wortpaare en-hu vorhanden sind. Die Abfrage sollte also folgende sein:
Schaue in der neuen Wörterpaartabelle (etwa en-hu) nach und prüfe, ob dort bei en ein Eintrag ist, der noch nicht in der Tabelle vorhanden ist. Wenn ja, füge ihn hinzu. Ist er mehrmals neu, so kommen alle hinzu (limit bei der alten maxzahl), denn dann sind diese Verknüpfungen für die neue Sprache nötig. Es werden dann gleich alle Verweise auf die neue Sprache gesetzt und die Tabelle um die Einträge gekürzt.
Ist der Eintrag schon vorhanden, zähle, wie viele Male. Ist es gleich viel wie im neuen, so kann direkt der(die) Verweise gesetzt werden. In diesem Fall wird der Eintrag gleich aus der Tabelle entfernt, damit am Schluss möglichst wenige unaufgelöst bleiben. Sind schon mehr Einträge im Original, dann werden nur so viele auf die neue Sprache verlinkt wie notwendig. Die restlichen bleiben leer. Auch hier werden die Wortpaare gleich entfernt. Sind es weniger, so wird ergänzt um die notwendige Anzahl Einträge. Diese werden nur auf die neue Sprache verlinkt. Es sollte aber von einem Sprachkundigen getestet werden, ob die Verlinkungen auch in andere Sprachen äquivalent sind und einfach vergessen wurden.

10. Dezember 2005

Allgemeines:

Frisch gestärkt und ausgeschlafen nach dem Weihnachtsessen geht es weiter. Die Such- und Ersetzroutinen sollen geschrieben werden. Ich hoffe, dass dies mittels PHP gut möglich ist. sonst muss ich die Tabellen exportieren und mittels perl direkt bearbeiten als Textdatei, denn für so etwas gibt es eher Parser, auch wenn der eigene dafür wohl etwas ungeeignet, da zu gross ist.
So, bin nicht mehr viel weitergekommen. Mal schauen, ob morgen ein grösserer Schub drin liegt...

Unklarheiten / Ideen:

Der Header muss noch international ausgegeben werden. Kann evtl. über eine internationale Kennung geschehen in einer css Datei. Wird wohl aber über lokale Verzeichnisse gehen, dann kann man jede Sprache individuell anpassen.
Habe dazu entschieden, dass alle Administrationsseiten auf englisch gehalten werden und keine lokalisierung geschieht. Ist sonst nicht überschaubar und ausserdem kaum hilfreich.
Die Skripte für das übernehmen werden in der Datei integrate abgehandelt.

Spezielles:

Habe den Apache umgestellt, dass er die Dokumente nun in UTF-8 ausliefert. Schliesslich arbeite ich ja intern damit und so sollten auch die wenigsten Prbleme auftreten. Die zuständige Datei ist:
/etc/apache2/mod_mime-defaults.conf die sich je nach Installation auch unter /usr/local befinden kann. codiere die Umlaute aber trotzdem, damit keine älteren Browser Probleme mit der Umsetzung bekommen.

21. Dezember 2005

Allgemeines:

Nun musste die Mittagspause dran glauben. Um relevante (projektbezogene) Daten zentral zu sammeln, werden diese im Hauptverzeichnis beschrieben.

Unklarheiten / Ideen:

Jemanden fragen, der das Tabellendesign anpasst auf css?

Spezielles:

In der readme.txt stehen neu die Dateien drin, die zuletzt geändert wurden, damit man für den Datenaustausch die neuste Version benutzt.

22. Dezember 2005

Allgemeines:

Und schon wieder muss das Mittagsbrot die Zeit mit dem Computer teilen. Es wird Zeit, das Sessionhandling so zu vereinheitlichen, dass die Daten zentral gespeichert sind und der Benutzer diese nach Bedarf anpassen kann.
Auch die Rechte zum editieren der Übersetzungen müssen gespeichert werden. Dies muss dann aber so geschehen, dass das System nicht angegriffen werden kann und dadurch die falschen Leute Unheil anrichten (die richtigen tun dies schon von alleine ;-) ).

Unklarheiten / Ideen:

Es tellt sich die Frage, ob man die Seiten wo möglich an Wikipedia angleicht. Dies würde bedeuten, dass man die Seiten online editieren könnte. Dadurch könnten auch Leute ohne HTML etwas beitragen, doch es würde halt etwas komplizierter werden.
Im Gegensatz zur Wiki würde ich als Schutz integrieren, dass nicht angemeldete Leute zwar editieren können, doch kann dies von einem berechtigten Mitglied in einer bestimmten Zeit wieder rückgängig gemacht werden.

Spezielles:

In der readme.txt stehen neu die Dateien drin, die zuletzt geändert wurden, damit man für den Datenaustausch die neuste Version benutzt.

Änderungen / Fertiggestelltes

Die PHP-Seiten im Hauptverzeichnis so fertig gestellt, dass sie nur noch an die Realität angepasst werden müssen.

25. Dezember 2005

Allgemeines:

Weihnachten ist schon bald vorüber und es ist Zeit vorhanden, etwas weiter zu arbeiten. Das einzige Problem mit dem Dateiaustausch mit Window ist, dass das benutzte Textpad die Tabulatoren anscheinend nicht in Leerzeichnen umwandeln kann und so diese jeweils angepasst werden müssen.

Änderungen / Fertiggestelltes

Das Hauptverzeichnis so programmiert, dass es funktionieren sollte. Es ist jetzt die Projektinfoseite dort, die nur in englisch existiert. Von dort aus kann man in jedes Unterprojekt wechseln, das man möchte.
Eigentlich ist ja schon morgen, doch bevor ich es vergesse, schreibe ich es lieber auf. Die Benutzerverwaltung ist feritg. Es fehlt nur noch die Möglichkeit, die Rechte zu ändern und die Rechte auf die einzelnen Sprachen anzuwenden.

Unklarheiten / Ideen:

Das Icon im Titel sollte noch personalisiert werden. Bei der info.php ist noch der Link zu Openoffice.org drin.
Der Kommentar, zu was eine Datei ist, sollte überall eingefügt werden. Bei den englischen Dokumenten noch auf englisch umstellen. Vorlage ist sessionhelpers.
Die Datenverwaltungshauptseite muss komplett neu erstellt werden, da diese jetzt neue Funktionen enthält und auch von der Rechteverwaltung etwas komplizierter wird.

27. Dezember 2005

Allgemeines:

So, ausgeschlafen an die Arbeit. Heute muss die Benutzerverwaltung abgeschlossen werden. So nebenbei als Ziel ;-)
Ziel erfüllt. Dazu ist schon die Datenverwaltung dran. Doch dies morgen, das heisst, in ein paar Stunden :-)

Änderungen / Fertiggestelltes

Die Tabelle language erweitert, da die Länder in jeder Sprache unterschiedlich heissen. Nun heisst die Spalte land country_xx und die Spalte language language_xx.
Die Benutzerverwaltung ist unterdessen tazsächlich soweit abgeschlossen, dass damit gearbeitet werden kann. Die Tabelle users wurde leicht geändert. Bei allen Sprachen steht int default '0'. Dann wird das Recht gleich schön ausgegeben.
Auch die admin.php ist jetzt besser dran. Zwar erst das Gerüst, doch schliesslich muss diese Seite völlig neu erstellt werden.

Unklarheiten / Ideen:

Der DB-Aufruf sollte noch ausgelagert werden. Vor allem für Änderungen und die Sicherheit (Skripte auslesen) sollte dies zentral geschehen.
Die Routine zur Ausgabe der Sprache sollte noch optimiert werden.
Schauen, warum bei der Sprachwahl die erste Zeiel id_yes heisst und die anderen nur noch id.
Bei der Userverwaltung bei den Fehlerausgaben die Rückgabe bei allen mit bgcolor white, oder sonst wie als Titel der Navigation. Einfach halt zum kennzeichnen.
Evtl. alle Ausgaben, die sprachabhängig sind, aus der DB aufzählen lassen, damit man den php-code nicht nachträglich bei jeder neuen Sprache anpassen muss.
Die Benutzerverwaltung erweitern. Etwa dass man vor dem editieren die vorhandenen Werte sieht. Abfragebestätigungen usw.
bei der Datenverwaltung habe ich jetzt eine Routine drin, wie die Sprachen als Liste ausgegeben werden können. Sollte so bei allen implementiert werden. Als Liste wird die Tabelle language genommen. Diese sollte hoffentlich immer up to date sein. Dort sind die id verzeichnet und dann die Sprachen in jeder Sprache ;-)

28. Dezember 2005

Allgemeines:

Nun ist der Tag fast um, die ideale Zeit, um mit arbeiten zu beginnen.
Nachdem die Susereperatur gut zugeschlagen hatte und das grafische System wieder läuft, kann es gut losgehen.
Heute muss die Datenverwaltung dran glauben. Nach dem lesen von diversen Internetseiten scheine ich auf dem richtigen Weg zu sein mit dem puristischen Design.

Änderungen / Fertiggestelltes

Die Navigation so geändert, dass sie davon abhängt, ob man eingeloggt ist, oder nicht. So kann man sich einloggen, wenn man "quer" einsteigt.
Die DB-Aufrufe sind alle mittels Funktionsaufruf ausgelagert, so dass man sie nur noch zentral ändern muss.
Das anzeigen von Datensätzen funktioniert unterdessen fast richtig. Nur bei manchen Einträgen will es nicht funktionieren. Das erledigen wir aber später.

Unklarheiten / Ideen:

Beim Dataformular kann man nicht alle Sprachen einfach so in einer Liste ausgeben, dies wäre zu unübersichtlich. Daher sollte das Formular nur gerade die Original- und die Übersetzungssprache enthalten. Auf Wunsch werden die schon übersetzten Sprachen für das Wort mit den Zielsprachen angezeigt. Dies wird zwar manche unnötigen Doubles erzeugen, etwa wenn der Begriff zwar in drei Sprachen gleich heisst, doch jedes Mal neu neuer Eintrag erstellt wird. Dies bläht zwar die Tabelle auf, doch ich denke, dass man dies nach Aufwand von Leuten wieder korrigieren kann, die etwa 3 Sprachen sprechen und so die Doubles anpassen können.
Nachtrag: Der vorherige Absatz ist ungültig, da man ja immer nur die eigene Sprache editiert. Verweise erzeugen keine Doubles. Es kann höchstens passieren, dass ein Word mit Querverweisen gelöscht wird vom "Besitzer" eines Wortes. Die Doubles sind also notwendig, wenn etwa ein Wort in einer anderen Sprache eine komplett andere Bedeutung hat als in allen anderen Sprachen.
Evtl. ist mittels Diskussionsforum dies schon im vornherein klärbar.
Ein registrieren muss noch implementiert werden. Als Daten werden nur eine Mailadresse und ein Benutzername abgefregt ohne Verifikation der Mailadresse zur Zeit. Kann später eingerichtet werden bei Missbrauch. Der Rest ist für normale Benutzer Zusatz.
Bei allen Seiten noch die sessionhelpers integrieren. Schliesslich werden jetzt alle DB-Aufrufe darüber gelöst.
In die Datenabfrage einbauen, dass nachgefragt wird, falls andere Sprachen beim record betroffen sind.
Schauen, dass die id eines Eintrages erst bei 1 beginnt, dann haben die Querverweise nie Null drin, wenn sie gültig sind.

29. Dezember 2005

Allgemeines:

Nach langem Schlaf ging es heute nur schleppend voran. Wenigstens konnte das Problem von gestern mit geänderten Abfragen gelöst werden. Nun ist es zwar komplizierter, doch dafür funktioniert es in allen Fällen.

Änderungen / Fertiggestelltes

Die Hilfeseiten für die Administration soweit fertiggestellt, dass man sie benutzen kann. Dazu die Loginseiten so weit angepasst, dass sie einheitlich sind und sie auf die neuen Anforderungen erweitert.
Dazu die Mailseite erstellt, die selbstständig Mails verschickt nach der Eingabe im Formular. Nun muss der Benutzer auch kein Mailprogramm mehr verwenden. Dazu ist der Zugriff zentral geregelt und Änderungen daher schnell erledigt. Jetzt fehlt halt nur noch das CMS für die Grammatik :-)
Hoffe, ich kann das Datamangement bald abschliessen mit der Importdateiverarbeitung. Dies wird warsch. noch das grösste Stück Arbeit. Das entfernen aller Mailadressen und stattdessen ein Link auf mail.php ist dagegen ein Klacks.

30. Dezember 2005

Allgemeines:

Jeden Tag kommt eine neue Idee, die es zu berücksichtigen gilt, doch irgendwie logisch bei einem grossen Projekt ;-)

Änderungen / Fertiggestelltes

Nun hat jede Übersetzung noch einen Eintrag, der sagt, wer der Besitzer ist. Es ist dies derjenige, der den Eintrag zuletzt bearbeitet hat. So kann man bei Missbrauch auch gleich sehen, welcher Benutzer dies war.
Zusätzlich jetzt die Datenmanagementvariablen bei der Session registriert. Dies zusätzlich im index.php vom Admin, falls jemand dort einsteigt. Da muss er auf jeden Fall vorbei.
Dazu die Datei form.php erstellt, die das Datenformular auswertet und danach die notwendigen Dateien aufruft. So muss nicht alles im admin.php erledigt werden, was die Sache übersichtlicher macht. Vor allem, wenn später nur Teilfunktionen geändert werden müssen.
Die Registerseite begonnen, damit sich Benutzer verifizieren können. Diese Seite wird in jedem Verzeichnis gehalten, da Sie in jeder Sprache zur Verfügung stehen muss.

Spezielles:

session_register() ist nur benutzbar, wenn register_globals aktiviert ist, was es ja nicht sein soll. Daher immer Variablen die man weiterverwenden will in $_SESSION() hineinpacken. Die Daten aus Formularen natürlich auch. Will man diese gleich im Skript verwenden. so kann man sie direkt zuweisen, wie im form.php zu sehen bei choice.

02. Januar 2006

Allgemeines:

Neujahr ist gut überstanden, auch wenn morgen die Arbeit wieder beginnt. Es geht voran. Man kann sich unterdessen registrieren. Jetzt kommt die Seite mit den persönlichen Einstellungen dran. Ist diese bereit, so sollten die Grundlagen abgeschlossen sein und ein Betatest in deutsch könnte erfolgen.

Änderungen / Fertiggestelltes

register.php ist feritg.

Unklarheiten / Ideen:

Die variablen vereinheitlichen. newname ist eigentlich username. Soll dies angepasst werden?
Alle Variablen nicht nur in readme.txt sondern auch im info.php zur Verfügung stellen.
Alle Dateien sammeln, die angepasst werden müssen, falls neue Sprachen dazukommen. Am besten in info.php.

09. Januar 2006

Allgemeines:

Irgendwie lief nicht sehr viel in letzter Zeit, oder habe ich es einfach vergessen zu notieren? Ist eher der Fall. Daher hole ich es jetzt nach.
Unterdessen sind alle Administrationsseiten valide nach W3C und dazu funktioniert das Usermanagement richtig. Die Suchoptionen sind jetzt beschrieben und müssen nur noch richtig implementiert werden.

Änderungen / Fertiggestelltes

Neu wird mit dem Link eine Variable mitgegeben, so dass das Script sich ohne Formular selber aufrufen kann.

Unklarheiten / Ideen:

Die Suche soll exakt oder unscharf möglich sein. Der Stern ermöglicht eine Teilwortsuche und bdeutet, dass das like ohne Leerschlag erfolgt. Wird ein Wort in Anführungszeichen gesetzt, so gibt es ein =.
Die Sonderzeichen müssen natürlich ersetzt werden. Vor allem auch Kombinationen. Obwohl, die Suche mit den Anführungszeichen ist nicht brauchbar. Lass ich weg, bis der Wunsch dazu begründet ist.
Bei dict.leo.org wird einfach alles nach dem ersten Stern im Wort abgeschnitten. Erscheint mir sinnvoll. * und ** ergeben keine Resultate. Da kann man die Suche auch gleich weglassen. Spart DB-Zeit.

13. Januar 2006

Allgemeines:

Bemerke gerade, dass heute Freitag dr 13. ist. Kein Wunder musste ich heute meinen Geschäftsrechner 4 Mal aus dem Image wieder herstellen. Nein, das hatte andere Gründe, doch alles war erfolgreich. Dazu konnte ich nebenbei noch die Änderungen fertig implementieren.
Es läuft ganz erfolgreich. Gestern konnte jedenfalls die Datenbankabfrage sauber implementiert werden, so dass jetzt Suchen gut möglich sind und auch der Stern richtig funktioniert.

Änderungen / Fertiggestelltes

Die Datei test_functions.php wurde entfernt. Es ist jetzt alles im sessionhelpers integriert. Dazu auch das Variablenhandling. So ist dies zentral und Änderungen sind nicht an verschiedenen Stellen. Aus diesem Grund wurden auch die verschiedenen Seiten angepasst, so dass diese jetzt als Unterseiten in index.php eingebunden werden. Nur register und myheaven sind noch ausgelagert, doch auch dort überlege ich mir eine Integration.

15. Januar 2006

Allgemeines:

Immer wenn man denkt, etwas ist fertig, fängt die Arbeit erst an. Die Suchroutine in der Datenadministration musste komplett umgeschrieben werden. Dazu wurde das Registrieren erweitert, so dass man jetzt automatisch das Recht hat, Daten hinzuzufügen.

Änderungen / Fertiggestelltes

Die Ausgabe der Daten funktioniert nun zufriedenstellend. Das registrieren läuft sauber.

Unklarheiten / Ideen:

Die registrierten Benutzer haben kein Verfallsdatum. Dies sollte noch geändert werden. Ich denke an folgendes: Loggt sich die Person ein Jahr nicht mehr ein, so verfällt der Account.
Hat die Person allerdings Änderungen in der Datenbank durchgeführt, so verbleibt Sie, damit man immer nachvollziehen kann, wer welche Wörter bearbeitet hat. So gibt es auch kein Problem, falls ein neuer Benutzer Unfug treibt. Sonst könnten auch die Daten des alten Benutzers gelöscht werden.

21. Januar 2006

Allgemeines:

Weiterhin an der Routine fürs hinzufügen von Übersetzungen beschäftigt.

Unklarheiten / Ideen:

Die Suche mit anschliessenden Satzzeichen sollte auch ohne Stern Resultate geben.

24. Januar 2006

Allgemeines:

Nun sollte das hinzufügen richtig funktionieren. Unterdessen habe ich aber schon wieder Verbesserungen bemerkt, die es zu erledigen gibt.
Dazu ist die Seite jetzt einmal zu Testzwecken online abrufbar. Mal schauen, wie es sich entwickelt. Die Frage ist, ob man jetzt einmal das Design richtig fertigstellen soll, die kleinen Fehler ausmerzen, die Suchroutine optimieren, oder einmal alle Grundfunktionen der Administration fertig implementieren soll.
Nun, dies werde ich später regeln. Jetzt ist Zeit zum schlafen. Auch dies muss einmal sein.

Unklarheiten / Ideen:

Die Suche sollte bei Einzelwörtern die Eingabe parsen. Dann könnte man zuerst den gesamten Ausdruck suchen und falls es keine Einträge gibt, die Einzelwörter. Dies macht Leo auch so und erscheint mir sinnvoll. Die Frage ist nur, wie schnell so eine Suche ist. Der DB-Zugriff ist jetzt schon recht hoch, auch wenn er optimiert werden könnte.

30. Januar 2006

Allgemeines:

Nur damit etwas läuft, habe ich noch einen Zusatz eingefügt. Neu wird die Hauptdatei (evtl. auch die Unterdatei) zuoberst noch angezeigt.
Eigentlich könnte man noch ein favicon nehmen, doch da warte ich lieber noch, bis ein Logo da ist.

31. Januar 2006

Allgemeines:

Wer sucht, der findet, zum Beispiel auch die Lösung für die Satzzeichen. Dies wurde implementiert. Der Fall, dass vor dem Wort eine Klammer oder sonst ein Sonderzeichen steht, wird nicht abgefangen, doch dies kann man ja mittels Stern herausfinden.
Falls das Wort noch ein einzelnes zusätzliches Zeichen hat, so werden diese Wörter auch noch berücksichtigt, doch dies lässt sich gut verschmerzen, vor allem da dies meist Verben sind.

Unklarheiten / Ideen:

Wird im mysql Statement nach dem Ausdruck ein Underline mitgegeben, so wird nach einem beliebigen Zeichen gesucht. Dies sollte also auch für ein Satzzeichen gelten.

19. Februar 2006

Allgemeines:

Nun sind schon fast 3 Wochen vergangen und es hat sich viel getan, nur nicht auf der Webseite. Doch heute hatte ich endlich wieder Zeit und es ging schon wieder einen Schritt weiter. Etwa die unvollständige Suche, die jetzt alle notwendigen Datensätze findet.
Trotzdem gibt es immer noch Probleme mit den Umlauten, doch dies ist in Bearbeitung.

Unklarheiten / Ideen:

Alle Formulare sollten noch erweitert werden mit enctype="multipart/form-data" accept-charset="utf-8" damit die Daten sicher als utf-8 für die Datenbank vorliegen.

29. Oktober 2006

Allgemeines:

Nach längerer Pause geht es mit neuem Quanta wieder weiter. Vor einer Woche begann das Redesign auf css. Sieht in Mozilla mit den abgerundeten Ecken ganz annehmbar aus.
Dazu wurde der Header, Footer und die Navigation ausgelagert. So sind die Sprachteile extern eingebunden.
Natürlich gab es auch in der Administration Anpassungen. Alle Dateien werden jetzt zentral integriert, so dass auch dort nur der "Mainteil" noch ausgewechselt wird. Der Titel wird jetzt in der Administration über eine GET-Variable eingelesen. Mal schauen, ob dies sinnvoll ist.

Unklarheiten / Ideen:

Das Sprachauslagern muss jetzt nur noch im Adminteil geschehen, da dort alles nur auf englisch vorhanden ist.
Hat aber keine Priorität.
Evtl. muss der komplette Administrationsteil auch noch auf Sprachen aufgeteilt werden. Vorbereitet wäre das Ganze jedenfalls.

30. Oktober 2006

Allgemeines:

Test mit gftp, nachdem mit Konqueror Probleme beim ftp-Tranfer auf den Server auftraten. Funktionierte testweise sehr zufriedenstellend.

31. Oktober 2006

Unklarheiten / Ideen:

Hier noch etwas Konzept für die Zukunft:
Die Dateien sind alle entweder in Sprachverzeichnissen, oder die Sprachelemente werden aus einer Sprachdatei eingelesen. Die externe Datei wird angewandt bei zentralen Dateien, die in jeder Sprache gleich sein sollen, wie etwa der Header usw.
Die Administration wird auch mit Sprachdateien ausgeführt, da die ganzen Algorithmen sonst mehrfach geändert werden müssten bei einem Fehler.
Ziemlich sicher werden am Schluss auch die Sprachverzeichnisse so aufgebaut, doch dies ist noch nicht festgelegt.
Wird hier ein Standard vorgegeben, der in jeder Sprache gleich ist, so geht es, doch ich denke, dass man hier flexibler sein muss, da die Sprachen doch nicht alle auf das gleiche Schema aufbauen.

Hier in etwa der Dateiaufbau. Sprachen steht für die jeweiligen Sprachen und ist als Abkürzungen für alle Sprachverzeichnisse gedacht. Angaben ohne Dateiendung bedeutet Verzeichnis. Das ... bedeutet, dass noch weitere Dateien vorhanden sind, die aber für das Verständnis nicht notwendig sind.
Die Inhalte der Verzeichnisse common und common_admin sind von extern nicht aufrufbar.

index.php -> common   -> header.php
                        footer.php
                        navigation.php
                        register.php
                        myheaven.php
                        freelance.php
                        about.php
                        error.php
                        ...
                        lang   -> Sprachen -> header_de.php
                                              footer_de.php
                                              -------------
                                              footer_en.php
                                              ...
          -> admin    -> index.php
                      -> common_admin      -> header.php
                                              footer.php
                                              navigation.php
                                              add.php
                                              delete.php
                                              ...
                                              lang -> Sprachen -> header_de.php
                                                                  footer_de.php
                                                                  -------------
                                                                  add_en.php
                                                                  ...
          -> Sprachen -> index.php
                         story.php
                         ...
                         Sprache1_Sprache2 -> alphabet.php
                                              grammatik.php
    

Da wir gleich dabei sind, hier noch ein Aufbau, wie das ganze System mit Lastverteilung funktionieren soll, ohne dass ein zentraler Server wegen allen Anfragen zusammenbricht.
Dieses System ist natürlich nur möglich, wenn die Server weltweit zur Verfügung gestellt werden, wobei selten benutzte Sprachen natürlich auch zusammengefasst auf einem Server gelagert werden können.
User sind Anwender, die Daten vom Server holen, während Worker Daten bearbeiten.

        Worker ->   Rootserver<--->Backupserver
                        |
                        v
          -----------------------------
          |             |             |
          v             v             v
      Server-de     Server-en     Server-...
          ^             ^
          |             |
       ------           |
      |      |          |
    User1  User2      User3
    

Wie man sieht, greifen die Worker direkt auf den Rootserver zu. Dadurch wird einfach sichergestellt, dass die Daten konsistent sind. Die Anpassungen werden danach mittels cron-Job auf die Server mit Änderungen übermittelt. Auf dem de-Server befinden sich danach die Übersetzungen von de nach Sprache X. Greift jetzt ein Benutzer auf die Hauptseite zu, so wird er durch die Spracherkennung auf seinen lokalisierten Server geworfen. Loggt er sich ein, so wird je nachdem der Server gewechselt.
Damit der Hauptserver kein Flaschenhals wird, könnte man die Sprachserver so programmieren, dass die Anfragen an den gewünschten Server sprachbasiert direkt umgelenkt werden. Doch dies soll dann programmiert werden, wenn es so weit ist. Zur Zeit sollte das Konzept genügen.
Der Vorteil in der Sprachsplittung ist sicher auch von Vorteil, dass die riesige mysql-DB schneller durchsucht werden kann, wenn man nur eine Sprache in alle anderen auf einem Server hostet.

Allgemeines:

Die Zeit schreitet wieder einmal zu schnell voran. Muss jetzt das Konzept nur noch umsetzen und die Verzeichnisse mit der .htaccess-Datei schützen.
Lokaler Zugriff geht automatisch, doch von fern nur mit Passwort (für Upload, Test usw.)

01. November 2006

Allgemeines:

Kaum hat man ein Konzept, schon wird es geändert. Habe common_admin aufgelöst und benutze üder eine Variable den Header usw. doppelt. Ist einfach besser zu handhaben, wenn auch etwas komplzierter.
Die Sprachverzeichnisse sind unterdessen erstellt und angepasst, so dass alle Ausgaben in einem separaten Verzeichnis gespeichert sind und die Sache so schön übersichtlich bleibt (hoffe ich ;-) )).

20. November 2006

Allgemeines:

Unterdessen denke ich auch über die Integration der Texte über xml nach, doch dies hat noch Zeit, bis das Gerüst steht.
Heute wurden die nächsten Dateien angepasst. Bin immer noch am überlegen, welche Dateien ins common wandern sollen, damit es übersichtlich bleibt und doch einfach editierbar. Eigentlich sollte ja jedes Dokument, das sprachunabhängig ist, dort rein. Ok, dann tun wir es halt ;-)
So, erledigt. Die ganze Struktur über den Haufen geworfen, doch so ist wenigstens alles, das mit dem Projekt zu tun hat zentral. Jetzt müssen die Seiten nur noch so angepasst werden, dass die Textausgaben länderspezifisch sind. Doch dies hat noch etwas Zeit. Zuerst alle Seiten fertig im Grobgerüst erstellen. Evtl. wird das Konzept später wieder aufgetrennt, doch zur Zeit scheint es sinnvoll so ;-)

24. November 2006

Allgemeines:

Noch etwas weiter programmiert. Nun kann man sich einloggen und registrieren ohne Extraseiten.

Unklarheiten / Ideen:

Alle Sprachdateien, die an einbinden möchte, sollten noch auf ihre Existenz überprüft werden und sonst sollte die englische Datei geladen werden.
Ach ja, alle Sprachausgaben beginnen mit $text_ dies sollte als Konvention beachtet werden.

15. Dezember 2006

Allgemeines:

Nach einem Tipp von Steve Lawall kann man die Seiten schön skalieren. Danke noch. Dazu konnte ich gleich noch eine css-Infobox übernehmen, die statisch und ohne Javascript funktioniert.
Verschiedene Dateien weiter überarbeitet und die Sprache ausgelagert.
Mit den Dateien aufgeräumt. Doppelte und alte Dateien entfernt.

Unklarheiten / Ideen:

Diese Datei könnte man als rss einbinden. Das wäre doch eine schöne Programmierübung. Hat allerdings noch Zeit.

20. Dezember 2006

Allgemeines:

Die Weihnachtszeit rückt näher. Dieses Jahr ohne Geschenke für die anderen Leute. Werde es (warscheinlich) irgendwann im Jahr nachholen, um dem Kommerzgeschäft zur Zeit zu entflihen ;-)
Wieder ein Stück weiter gekommen. Bald sind alle Seiten mit einer extern eingebundenen Sprachdatei verknüpft, so dass nur diese angepasst werden muss, wenn eine neue Sprache hinzukommt.
Zur Zeit ist der "normale" Teil fertig. Jetzt muss nur noch die Suchroutine mit Umlauten richtig arbeiten, dann kommt alles gut und ich kann die Administration fertig stellen und danach zur Hauptarbeit, dem Sprachen lernen kommen.

Unklarheiten / Ideen:

Die Sprachdateien könnten zwar zusammengefasst werden, doch ich denke, dass dies dann die Übertragungszeit erhöhen würde. Jetzt werden nämlich nur die Daten geladen, die auch im jeweiligen Dokument benutzt werden.
Die Infoseite könnte mit per php erstellten Diagrammen gefüllt werden. Diese zeigen den Fortschritt der Seite an mit Balken, die dynamisch gezeichnet werden. Ist aber eine Spielerei und braucht Rechenzeit. Also nichts für jetzt. Da gibt es wichtigeres zu erledigen.

21. Dezember 2006

Allgemeines:

Die Menüs überarbeitet. Jetzt funktioniert auch dort das ausloggen und es sollte alles logischer gebündelt sein.
Die letzten Variablenprobleme mit den Sprachen behoben und dazu wird die Sprachdatei jetzt auch abgefragt, sonst kommt englisch, wenn nicht vorhanden.
Die Mailfunktion funktioniert nun wieder richtig. Dazu werden die Nachrichten besser gefiltert, so dass nicht gespamt werden können sollte ;-)

Unklarheiten / Ideen:

Die 404er sollten noch angelegt werden.

23. Dezember 2006

Allgemeines:

Die Seiten lokal nochmals überprft. Jetzt sind auch die letzten Initialisierungswarnungen weg und die Sprachseite ist bereit. Jetzt kann es an die Administration gehen.
Unterdessen müsste schon der 24. da stehen, denn es ist 02:09 Uhr. Dafür steht jetzt die Benutzerverwaltung richtig mit ausgelagerter Sprachdatei.

Unklarheiten / Ideen:

Bearbeiten aller vorher erstellten Ideen. Doch dies erst, wenn alles dringende erledigt ist.
Auf xhtml umstellen?
Die usermanagementdateien noch etwas anpassen. So dass die Textausgaben in der Tabelle schön angezeigt werden. Evtl. noch fett.

26. Dezember 2006

Allgemeines:

Ferien sind ccol, aber anstrengend. Vor allem, wenn die Wikipedia einem die ganze Nacht über nicht loslässt und man erst am Morgen ins Bett kommt ;-)
Nun, jetzt geht es dafür schon bald wieder in die Heia. Die Benutzerverwaltung funktioniert jetzt sogar mit Löschbestätigung. Jetzt gehts an die normale Administration.

Unklarheiten / Ideen:

Eine kleine Kommentarzeile wäre noch schön, die man ausfüllen kann bei jeder Benutzeraccountveränderung. So hat man einen kleinen Überblick. Dazu vielleicht auch noch die Flaggeschichte. Dann sieht man, wer man was geändert hat.
Dies ist aber Zusatz für später.

02. Januar 2007

Allgemeines:

Wieder kommt die Seite ein Schrittchen weiter. Das Problem mit den Umlauten ist eingegrenzter als vorher ;-) Gesendet wird als utf-8. Zurück kommt etwas abgeschnittenes (nur das 2. Byte). Schauen, ob dies wirklich immer so ist. Etwa bei häuschen geht c3 a4 weg. Schauen, ob ein einzelnes ä auch so weg geht, oder dort nur das a4, wie es mit whireshark den Eindruck macht (Hiess früher ethereal).
Dafür ist jetzt ein rss in Arbeit, der evtl. schon ab sofort arbeitet.
Dazu ist das 404er Dokument online. Funktioniert sauber.

Unklarheiten / Ideen:

Wo liegt das Problem? Evtl. Test mit dem Senden der utf-8 Header an mysql.

14. Januar 2007

Allgemeines:

Abfrage der Wörter überprüft und Hilfe angepasst, da immer mit einem Zeichen mehr gesucht wird wegen den Satzzeichen.
Das hinzufügen von Daten angepasst, so dass die Texte extern eingebunden werden.
Dazu die Abfrage korrigiert, da diese unvollständig war. Ist zwar noch nicht korrekt, doch wenigstens funktioniert der Zugriff auf mysql richtig.

Unklarheiten / Ideen:

Datei "zu erledigendes" und "Richtlinien" erstellen, vor allem aus dieser Datei, damit alles zentral sichtbar ist. am besten farbig.
Man könnte etwas ähnliches wie zur Zeit in der Admineinführung drin aufbauen.
Evtl. noch das Design etwas weniger aufdringlich (Farbsättigung herabsetzen).
Evtl. die Abfragen nur für die erste Sprache gültig machen. Wenn nur die 2. Sprache benutzt wird, diese ignorieren. Macht es zwar weniger luxuriös, doch übersichtlicher.
Die Ausgabe des type, die noch hardcodiert ist, auslagern. Warscheinlich sessionhelper.inc.php.

21. Januar 2007

Allgemeines:

Nun funktioniert auch der Datei Upload. Dazu ist auch myheaven ausgelagert und selten gebrauchte Funktionen werden über rarely.inc.php eingelesen. Der Header ist nun bei allen Dateien aktualisiert, damit man das Änderungsdatum sieht und die Funktion.
Die css-Datei wurde angepasst (Definitionen in englisch). Ich hoffe, dass alle betroffenen Dateien angepasst wurden. Sonst sieht man es dann.

Unklarheiten / Ideen:

Jetzt muss das Ganze nur noch angepasst werden, damit die alten Dateien gelöscht werden und die Daten korrekt in die DB übernommen werden.
Evtl. hat Google ja noch gute Datenbestände oder Übersetzungstipps. Wer weiss, evtl. bekommt man etwas.

08. April 2007

Allgemeines:

Ostersonntag ist es unterdessen. Heute war ein ruhiger Tag mit eindrucksvoller Osterpredigt. Unterdessen ist es Abend und es läuft auch wieder ewas mit der Homepage. Habe von KDE eine kleine Tabelle übernommen und angepasst, damit man den Übersetzungsstatus sieht. Dies eingebunden über eine Funktion. Dazu noch die Sprachdateien angepasst, damit alle Umlaute draussen sind, da ja schliesslich alles über utf-8 läuft.

Unklarheiten / Ideen:

Der Aufbau der Sprachdateien muss einheitlich sein. Es gibt keine Ersetzungen nur mit Zahlen, sondern text_titlename und text_bodyname_body1. So kann man die Texte auch richtig zuordnen. Die Dateien sind genau so aufgebaut wie die style.css, nämlich grammatikalisch in der richtigen Reihenfolge. So kann man nachträglich Texte einflechten ohne etwas schieben zu müssen. Es wird dann zwar nicht mehr so einfach, die Variable im Kontext zu finden, doch dafür ist die Sprachdatei sauber.
Dies muss natürlich noch gemacht werden, darum sollten noch auf der Mitarbeiterseite die offenen Jobs aufgelistet werden. Dazu gehört sicher ein Koordinator, der alle Aufgaben analysiert und auflistet, damit diese dann den Bereichsleitern übergeben werden können. Wichtig ist dabei auch eine Entflechtung von Programmierer, Designer und Sprachmitarbeiter. So wäre es schön, wenn die Sprachlernseiten mittels CMS einfach erstellt werden könnten, damit diese ähnlich wie bei Wikipedia einheitlich wirken und doch einfach zu warten sind.
So, Morgen ist Recktag fürs Kinderlager im Herbst. Das heisst, bald ist Bettzeit angesagt. Jetzt wo es doch mal laufen würde ;-)
Ach ja, kann sich jemand Gedanken um einen SVN-Server machen, damit man dezentral arbeiten könnte? Evtl. mit cron-Job für den Server.
Bei den Sprachdateien sollte darauf geachtet werden, dass die Variablen nach einem einheitlichen Muster aufgebaut werden, das öffentlich eingesehen werden kann. Dass es immer mit text_ beginnt ist klar, doch dann folgen je nach Einsatzort noch Angaben wie table_ usw. oder am Schluss _title. Evtl. kann dies mit einer schönen Logik auch einfach und trotzdem so kurz wie möglich implementiert werden.

09. April 2007

Allgemeines:

Nach dem Übersetzen der KDE-News wird es Zeit, sich der Sprachseite zu widmen, bevor wieder der Alltag startet und die Zeit knapp wird. Dazu bei allen Sprachdateien noch einen Header eingefügt und alle englischen Dateien aktualisiert.

Unklarheiten / Ideen:

Eine Seitennavigation wäre sicher noch hilfreich, damit sich die Leute zurechtfinden und dazu eine Fahne der Sprache. Dies ist aber mehr ein Gag und daher weniger wichtig.

22. April 2007

Allgemeines:

Nach der korrekten Schreibweise des Links sind die Seiten wieder html-konform. Dazu wurden aus den Dokumenten alle Umlaute richtig ersetzt, da diese mit utf-8 nicht mehr mit Entities ersetzt werden müssen.
Das Arbeiten mit neu 2 Bildschirmen gibt hoffentlich nicht nur Probleme, bis es endlich funktioniert hat, sondern ermöglicht Effizienz. Alte Karten sind hier nicht hilfreich, vor allem, wenn man trotzdem ruckelfrei DVD schauen möchte :-)

29. April 2007

Allgemeines:

Ja, so zwei Bildschirme sind was schönes. Jetzt muss man sich nur noch die Zeit nehmen, auch am Projekt zu arbeiten.
Der Dateiumbau für die Sprachen ist bei common unterdessen auf deutsch abgeschlossen. Die englischen Dateien sind zum Teil noch auf deutsch, doch sollte dies zu verkraften sein.

Das aktualisieren des Projektes mittels svn funktioniert noch nicht perfekt, doch sind erste Schritte dazu im Gang, damit das verteilte Entwickeln auch möglich wird.

Neues Favicon erstellt, mitdem des H von Heaven symbolisiert wird. Mal schauen, evtl. gibt es irgendwann etwas schöneres, doch fürs Prinzip genügt es ;-)
Dazu wurde der Header angepasst. Das Bild ist jetzt absolut und es braucht weniger Platz. Dadurch hat der Inhalt mehr Bedeutung.
Dazu noch eine Abfrage eingebaut, damit man die Suche auf 100 Resultate begrenzen kann, doch ist dies jetzt nicht mehr notwendig.

03. Juni 2007

Allgemeines:

Die Zeit schreitet voran. Leider lief in der letzten Zeit wenig am Projekt. Es stellt sich immer noch die Frage, ob ein eigener SVN-Server, der die geänderten Dateien selber verschickt, wohl machbar wäre, da es doch eine kleine Erleichterung bedeuten würde und vor allem könnten dann mehrere Personen gleichzeitig am Projekt arbeiten. Wo gibt es aber dazu eine einfache Erläuterung? Laut Mail scheint es keine grosse Sache zu sein. Wir werden sehen.

Unklarheiten / Ideen:

Wieder eine Idee, doch wer weiss, wann die Umsetzung erfolgt. Die Suchparameter werden im Eingabefeld mitgegeben. Natürlich können diese auch in einer externen Seite mit Erklärung erstellt werden. Ähnlich wie bei Google. Der Parser sollte folgendes berücksichtigen:
Die Anweisungen erfolgen mit =. Bp.: break=100 -> Abbruch nach 100 Resultaten. Die Parameter sind natürlich erweiterbar. Die Auswertung erfolgt dann im php. Dazu braucht es: both=true -> in beiden Sprachen suchen und exact=yes -> das Wort wird exakt gesucht. exact=case -> Exakte Suche mit Gross und Kleinbuchstaben unberücksichtigt. exact=inside -> Der Begriff wird innerhalb eines Wortes gesucht. Dann noch type=... Man gibt den Typ an wie Acronym, Werb usw.
Auch wenn es für die Benutzer schwieriger ist, werden die Parameter nur auf englisch akzeptiert, damit die Programmierarbeit nicht unermesslich wird. Man sieht das Chaos bei Microsoft VBA.

22. Juni 2007

Allgemeines:

Sollte nachher noch ein paar News für KDE übersetzen, doch dank dem Validator der Web Design Group habe ich noch ein paar Fehler gefunden. Es fragt sich jetzt, ob ich auf xhtml umsteigen soll, oder alle Tags die eigentlich selbst schliessend sind, wie br, wieder ohne schliessenden Slash schreiben soll.
Nun, es gibt wichtigeres.

Unklarheiten / Ideen:

Docbook lief mir gestern über den Weg. Ohne zu grüssen :-) Nun stellt sich die Frage, ob man die Sprachseiten anstatt in HTML im Docbookformat erstellt und anschliessend HTML generiert. Ob die Eingabe genügend einfach wird, dass dies jederman tun kann? Hätte jedenfalls den Vorteil, dass man einfach eine schriftliche Form oder PDF daraus erstellen könnte.