Gestern bin ich auf einen recht spassigen Dienst gestoßen: TalkingText. TT kann geschriebenen Text durch Sprachsynthese in gesprochenen Text – Sprache – umwandeln. Überspitzt formuliert: TT macht aus einem Blog einen Podcast.

Der Text des Blogs wird an TT durch RSS übermittelt, dort in Sprache konvertiert und als mp3-File hinterlegt. Die mp3-Files werden über ein eigenes WordPress-Plugin in den Blog an passender Stelle mittels zweier Buttons (siehe unten) eingebunden. Nun können die letzten 8 Einträge des Blogs nicht nur gelesen, sondern auch angehört werden. Das kann entweder “live” auf der Webseite geschehen oder man kann sich die mp3-Datei herunterladen und auf den mp3-Player kopieren.

Ich halte das für eine ganz nette Technologie, da so auch Personen, denen Lesen nicht leicht fällt bzw. Personen mit einer Sehbehinderung Webseiten (leichter) “lesen” können – Stichwort: Barrierefreiheit. Solche Text-to-Speech-Geschichten werden daher mittlerweile von einigen Webseiten (z.B. Heise.de, einigen Banken oder Pediaphon) eingesetzt. (Ich frage mich allerdings, wieso die Abspiel-Buttons z.B. auf Heise.de so verdammt klein sind. Es gibt dort diese Funktion wohl schon längere Zeit, ich habe sie aber erst heute entdeckt, Winz-Buttons sei dank *gg*)

Momentan ist der TT noch im Beta-Stadium und daher kostenlos und ohne nur mit Eigen-Werbung. Später ist sicher mit gesprochener Werbung vor / während / nach dem eigentlichen Text zu rechnen.

Ach ja: Liebe TT-ler, falls jemand von euch das lesen (oder hören ) sollte: was bitte soll diese Fahrstuhlmusik im Hintergrund!?

Der Spaß geht weiter:

Das Archiv-Plugin (Extended Live Archive) funktioniert nicht mehr, da die Datenbankstruktur von WordPress grundlegend umgestrickt worden ist!

WordPress database error: [Table 'sammelsurium@1-blog.wp_categories' doesn't exist]
SELECT * from wp_categories

Als ich vorhin ein Upgrade auf WP Version 2.3 machen wollte, spuckte wp-admin/upgrade.php eine Fehlermeldung aus. Deren Wortlaut habe ich nicht mehr genau im Kopf. Die Aussage war aber, dass auf den Kilu.de Servern eine bestimmte Funktion (db_log() – oder so) deaktiviert ist. Die Deaktivierung dieser Funktion verursacht einen Fehler im upgrade-Skript und der wiederum lässt das Upgrade bzw. die Datenbank-Konvertierung scheitern.

Klasse: Die Datenbank ist nach diesem Upgrade-Versuch komplett hinüber! Hier zeigt sich mal wieder der wahre Sinn eines Backups: Das überlegene Lächeln dessen, der gerade seine Datenbank zerschossen hat, aber noch ein Backup hat und deswegen nicht wutschnaubend vor dem PC hockt.

Bleibt die Frage: wie zum Henker konvertiert man die Datenbank von 2.2.3 auf 2.3?

Idee 1: Exportiere die Daten vom WP 2.2.3 Blog als XML über Dashboard -> Verwalten -> Export und importiere das Gedöns auf gleichem Wege im WP 2.3 Blog über Dashboard -> Verwalten -> Import. Blöde Idee, das tut nicht. Warum? Keine Ahnung. Der Importer der XML-Datei verschluckt leider die Namen der Beiträge. Also eine schlechte Idee.

Idee 2: Setze erst ein WP 2.3 auf dem lokalen Rechner auf (dazu braucht man z.B. ein Xampp-Packet [siehe dazu auch hier, Schritt 1]), lösche dann dessen Datenbank, importiere dann das Datenbank-Dump des WP 2.2.3 Blogs und führe dann /wp-admin/upgrade.php aus. Jetzt hat man in der Datenbank des lokalen Rechners eine ins 2.3-Format konvertierte DB. Yeah.

Überschreibe dann die 2.2.3-er Dateien auf dem Webspace mit den 2.3er Dateien. Lösche dann die Datenbank auf dem Webspace und importiere schließlich das eben erzeugte Datenbank-Dump des lokalen Rechners.

Bei mir hat dieses herangehen recht gut funktioniert. Bin mal gespannt, was morgen alles beim aktivieren der Plugins schief laufen wird!

Falls irgendwas in nächster Zeit haken sollte, bin ich schuld. Ich mache gerade das Update auf WordPress 2.3. Please hold the Line.

Der Freehoster kilu.de bietet ein wirklich gutes Preis/Leistungsverhältnis an Null Euro, viele Features. Ein Feature wurde aber leider auf den Servern deaktiviert: mail(). D.h. Programme, wie z.B. WordPress oder ein Wiki, können nicht über PHP die Funktion mail() aufrufen und so über das lokale Sendmail elektrische Briefe senden.

Eine mir bekannte Abhilfe für WordPress schafft das Plugin Cimy Swift SMTP for WordPress. Statt mittels mail() verschickt das Blog über einen externen SMTP-Server Mals – in meinem Fall ist es der Server von GMX. Gmail soll auch funktionieren, ich habe das allerdings nicht hinbekommen.

Es gibt noch weitere SMTP-Plugins, z.B. dieses hier, aber das funktioniert nicht – weder mit GMX, noch mit Gmail.

Falls jemand weitere Lösungsmöglichkeiten weiß: Comment!

Vor einiger Zeit ist mir aufgefallen, dass Google-Suchergebnisse, die auf meinen Blog zeigen, ziemlich unschön aussahen.

Abgesehen davon, dass ich noch unbedingt aus “Sprach Tools” Sprachtools machen muss, kann ich sowas irgendwie überhaupt nicht sehen. Nach einiger Suche und Herumfragen im WordPress-Forum brachte mich Torsten auf die Idee mal den Validator zu bemühen und siehe da: Der Validator schrie laut auf, da ein Zeichen, das nicht im UTF-8 Zeichensatz zu hause ist, sich auf meinem Blog herumtreibt. Interessanterweise war dieses Zeichen aber partout nicht näher zu lokalisieren. An der angegebenen Stelle war im Grunde genommen alles okay. Zudem kam noch, dass abhängig von der validierten Seite, das Zeichen immer an einer andere( (!) Stelle, aber immer im Bereich der Sidebar-Widgets zu finden war. Sehr seltsam.

Nach anfänglichem ziellosem Stochern, habe ich dann alle Sidebar-Widgets ausgebaut und nacheinander wieder eingebaut. Und siehe da: ich konnte den Fehler finden. Die Spannung steigt: es war das RSS-Widget mit dem Picasa-Galerie-Feed.

Die Frage ist nun: ist es das Widget an sich oder der Feed? Es war der Google-Feed. Bindet man einen anderen Feed, z.B. der von der Tagesschau ein, taucht das ungültige Zeichen nicht auf.