• Per E-Mail-Abo (sofern angeboten)?
  Ja, das ist meine präferierte Version, da ich nichts tun muss, sondern der Kommentar zu mir kommt. Ärgerlich ist dabei, wenn nicht der Inhalt geschickt wird, sondern nur die Information, dass ein Kommentar abgegeben wurde (beim Blogsystem Serenity z.B.). Es gab schon einige Male Aktionen von Bloggern, bei denen angedroht wurde, sie würden in Blogs ohne Kommentarabo nicht mehr kommentieren oder überhaupt lesen. Das halte ich für übertrieben, aber immerhin wird so Aufmerksamkeit auf das Problem gelenkt. Für selbst hostende WordPress-Blogger gibt es ein Plugin mit Double-Opt-In-Verfahren, so dass man auf der sicheren Seite ist. Für wordpress.com-Blogger gibt es ebenfalls seit letztem Jahr die Möglichkeit, wobei hier jedes Mal das Abo bestätigt werden muss, was ein bisschen aufwändiger ist.
• Per RSS-Feed?
  Habe ich eine zeitlang gemacht in einem speziellen Ordner comments für Beiträge, wo ich kommentiert habe. Mittlerweile ist mir das zu blöd, die Abos alle paar Wochen oder Monate auszusortieren und so habe ich diese Variante wieder verworfen. Es gehen mir dadurch zwar einige Kommentare durch die Lappen, aber das kann ich verschmerzen. Außerdem ist es je nach Blogsoftware nicht immer möglich, die Kommentare zu einem bestimmten Beitrag zu abonnieren und man muss mühsam danach suchen (außer bei WP, wo einfach ein “/feed” an die Beitrags-URL angehängt wird).
• Bookmarks/Favoriten im Browser?
  Diese Variante hat die Kommentarabos abgelöst. Ich habe jetzt einen Ordner comments in der Lesezeichen-Symbolleiste, wo ich Beiträge ablege, bei denen ich kommentiert habe. Die rufe ich dann zwei bis drei Tage immer wieder auf und prüfe, ob neue Kommentare eingetroffen sind und dann wird das Lesezeichen gelöscht. Was danach an Kommentaren abgegeben wird, hat mich nicht mehr zu interessieren.
• Online-/Social-Bookmark-Dienste à la Delicious, Mr Wong, ReadItLater etc.?
  Nein, diese Dienste nutze ich ausschließlich für Beiträge, die ich mir merken (Delicious) bzw. noch lesen (ReadItLater) möchte. Beides sind völlig andere Nutzungsarten und das soll alles schön getrennt bleiben, damit ich nicht durcheinander komme.
• Gar nicht…?
  Nein, das kommt nicht in Frage, denn ich ich möchte ja wissen, was noch an Kommentaren kommt und außerdem erwarte ich, dass auf meinen Kommentar reagiert wird. Letzteres mag harsch klingen, aber ich schreibe nie einfach nur “Super!” o.ä., sondern etwas mehr und oft eine Frage oder Aussage, die hoffentlich etwas zur Diskussion beitragen. Ansonsten kann man sich den Kommentar ja auch sparen.

Dann möchte cimddwc noch folgendes wissen:

• Nur bei den Beiträgen, bei denen ihr selber kommentiert, oder alle Kommentare eines Blogs (wofür i.d.R. auch ein Feed angeboten wird)?
  Nein, nur beim jeweiligen Beitrag, was schon durch meine präferierte Methode vorgegeben ist. Alle Kommentare eines Blogs wären mir erstens zu viel und zweitens wüsste ich in den meisten Fällen nicht mehr, was genau im Beitrag stand. Kommentare zu einem einzelnen Beitrag zu abonnieren, bei dem ich nicht selber kommentiert habe, habe ich noch nie gemacht. Wenn mich die Antworten interessieren, kann ich auch “schnell” was schreiben und das Kommentarabo mitnehmen.
• Mal dieses, mal jenes – abhängig wovon?
  Bei manchen Blogs wäre es vielleicht interessant oder amüsant, alle Kommentare zu lesen, aber diesen Luxus leiste ich mir einfach nicht.
• Wann hört ihr auf, Kommentare zu einem Beitrag zu verfolgen?
  Das ist eigentlich noch nie vorgekommen. Zu viele und häufige Kommentare gibt es ja eigentlich nur bei Gewinnspielbeiträgen und da abonniere ich erst gar nicht, weil ich um das Problem weiß.

Wer ebenfalls seine Meinung zu Kommentarverfolgung abgeben möchte, hat dazu noch bis 22. August Zeit. Da bin ich echt mal auf die Auswertung gespannt. Und in der Zwischenzeit hoffe ich auf viele Kommentare und Kommentarabos…

Manchmal aber bauen die einzelnen Beiträge aufeinander auf oder man möchte den Service anbieten, alle Teile nacheinander lesen zu können. Hier kommt das In Series-Plugin für WordPress zum Einsatz. Dies erstellt ein Inhaltsverzeichnis und fügt automatisch Links zum vorherigen und nächsten Beitrag ein. Wo diese Links auftauchen, kann in den Einstellungen festgelegt werden (oben oder unten, überall oder nur im Einzelbeitrag) und ob erster und letzter Beitrag extra. Die Einstellungen gibt es in einfacher und ausführlicher Form. So sehen die einfachen aus:

In Aktion erleben kann man das z.B. bei meinem letzten Artikel über Englisch Lernen mit TV-Serien. Auf der Startseite sieht man das Inhaltsverzeichnis nicht, weil – wie oben in den Einstellungen zu sehen – das nur auf den Einzelbeitragsseiten erscheinen soll. Die jeweiligen Elemente sind mit CSS-Klassen versehen und ich habe z.B. das Inhaltsverzeichnis mit grauem Hintergrund versehen und auf ein Drittel der Spaltenbreite gesetzt.

Des Weiteren werden zwei Widgets angeboten: die Serienliste, das eine bestimmte Anzahl Beitragsserien anzeigt und das Inhaltsverzeichnis, wenn man sich auf einer Beitragsseite befindet. Ich nutze diese Widgets nicht, da ersteres 35 Datenbankabfragen erfordert und letzteres bei mir nicht nötig ist.

Die deutsche Übersetzung des Plugins stammt übrigens von mir und deswegen ärgert mich ein kleiner Fehler in der Einstellungenseite. Wer das Plugin einsetzt und eine korrigierte Version möchte, melde sich und ich schicke die geänderte Sprachdatei per Mail. Dass oben die ersten zwei Zeilen in englisch sind, liegt daran, dass diese Zeilen nicht für die Übersetzung markiert wurden.

Der Einsatz des Plugins ist denkbar einfach, denn beim Schreiben eines Beitrags wählt man im Editor unten aus, ob man den aktuellen Beitrag zu einer existieren Serie hinzufügen möchte (am Anfang oder Ende) oder zu einer neuen Serie:

Wer das Plugin mal ausprobieren möchte, findet hier mehr Infos und kann hier die aktuelle 3.1.0 beta 5 herunterladen. Diese Betaversion habe ich seit zwei Jahren im Einsatz, da der Autor das Plugin leider nicht mehr weiterentwickelt. Das Plugin hat jedoch alle Eigenschaften, die ich mir wünsche und es ist einfach praktisch, dass ich nicht händisch die Links zu anderen Beiträgen hinzufügen muss, sondern das dem Plugin überlassen kann.

Wer Fragen zum Plugin hat, kann sich entweder an den Autor wenden oder an mich, da ich mich mittlerweile ganz gut damit auskenne.

Zum Abschluss folgt noch der Hinweis, dass dies mein Beitrag zu Konnas Blogseminar #6[1] ist.

Die Hauptaufgabe lautete, dass man eine Artikelserie starten soll. Nun, da ich fast nur Beitragsserien hier laufen habe (offizielle wie Englisch Lernen mit UK- und US-Serien, Chartspunkte, MediaMonkey vs. iTunes und inoffizielle wie das Liedzeilen-Quiz, Projekt 52, Projekt Hörsturz und meine Gastbeitragsserie über Doctor Who), fange ich keine neue an.

Die Bonusaufgabe lautete, einen Artikel über einen Aspekt des Bloggens zu schreiben und das habe ich somit durch diesen Beitrag über Artikelserien getan. In den Beispielen habe ich meine Serie über MediaMonkey erwähnt und das sind bis heute meine meistgelesenen Beiträge – es lohnt sich also, ein gutes Thema zu finden und darüber ausführlich zu schreiben.

1. Das ist eine regelmäßige Aktion von Konna bei dem die Teilnehmer einige Aufgaben zur Verbesserung ihres Blogs erfüllen sollen/können/dürfen. Die Aufgaben kommen aus den Bereichen SEO, Content, Design und Optimierung. Mehr Infos gibt es auf der Projektseite.

Die neue WordPress Version 2.8 wurde schon vor “längerer” Zeit veröffentlicht, aber ich habe die Aktualisierung nicht vornehmen können, da mein Theme K2 sich nicht damit vertrug. Ursprünglich hatte ich K2 angefangen zu verwenden, da es immer noch die flexiblen Sidebar Module statt der starren WordPress-Widgets verwendete. Leider wurde die Unterstützung für das Plugin vor einiger Zeit eingestellt und so war klar, dass ich irgendwann auf Widgets umsteigen muss.

Wäre eine formschöne Sidebar das einzige Problem gewesen, hätte es nur einen großen Kraftakt benötigt, um meinen Blog auf den aktuellen Stand zu bringen[1]. Aber da ich so viel am Layout rumgebastelt hatte (sowohl CSS als auch PHP), bedeutete das noch größeren und vor allem viel frickeligeren Aufwand. Dass es sich lohnen würde, war durch die Einführung von sogenannten Child Themes (Anleitung für K2), die es ermöglichen, dass man sein Theme anpasst und dennoch das ursprüngliche Theme behält. Das ist wichtig bei Aktualisierungen und die wiederum sind wichtig, wenn WordPress aktualisiert wird.

Nach einigen Anlaufschwierigkeiten habe ich also ein Child Theme von K2 angelegt und es so abgewandelt, dass es (ungefähr) wieder so aussieht, wie ich das haben wollte. Es sind nicht alle Kleinigkeiten wie vorher, entweder weil das noch kommt oder weil es genauso gut aussieht. Könnte auch sein, dass ich manche Anpassungen schlicht vergessen habe, weil ich nicht die Geduld hatte, den gesamten alten und neuen Quellcode auf Änderungen zu überprüfen.

Diesmal habe ich auch die ganzen JavaScript-Spielereien von K2 dringelassen und so gibt es jetzt eine Livesuche und Rolling Archives, d.h. es werden schon beim Tippen ins Suchfeld die Ergebnisse angezeigt (JS muss natürlich aktiviert sein) und das Archiv kann per Slider durchsucht werden:

Nachteil ist, dass durch das JS und das Child Theme die Ladezeit erhöht wird. Wem das zu lange dauert oder wer gar auf unüberbrückbare Hindernisse stößt, möge das bitte mitteilen und vielleicht entferne ich das doch wieder komplett. Auch bitte ich um Hinweise auf lieb gewonnene Kleinigkeiten, die ich vergessen oder geändert habe.

1. An einer Stelle in der Sidebar hat mich der Frust übermannt. Wer findet die verräterischen Zeilen?

Nach diesem Plädoyer für Feeds und Feedreader allgemein, wende ich mich dem eigentlichen Thema zu und verkünde, dass ich Vollfeeds bevorzuge und zwar aus vielerlei Gründen. Frank Bültge (der das Thema ins Rollen brachte) führt in seinem Artikel Short Feeds: Es stinkt mir an, dass er vor allem wegen dem Offline-Lesen Vollfeeds haben möchte. Ist ein gutes Argument, das allerdings nicht auf alle Feedleser zutreffen dürfte.

Gehen wir mal von privaten oder semiprivaten Blogs aus, d.h. nicht von großen Firmen/Magazinen, die auch einen Feed anbieten (Bsp: heise, tagesschau, taz, NME, …). Die bieten fast ausnahmslos ultrakurze Feeds an (nur die Überschrift und evtl. noch eine Zeile) und können sich das auch leisten. Doch auf die will ich hier gar nicht hinaus. Mir geht es um die engagierten Hobbyblogger, die ich selber hauptsächlich lese und die wohl die große Masse der Blogger ausmachen. Die haben wenige Dutzend bis mehrere Tausend Besucher am Tag und die wollen erst mal gehalten werden. Am einfachsten geht das, indem die Besucher zu Stammlesern werden und das geht am einfachsten wenn diese den Feed abonnieren.

Eines der wertvollsten Güter sind die Kommentare, denn die vermitteln einen Eindruck darüber, ob und wie stark der Blog wahrgenommen wird. Die meisten Kommentierer sind regelmäßige Leser und wie werden die am leichtesten gewonnen? Richtig, durch ein Feedabo. Und wie kann der Abonnent am leichtesten einschätzen, ob ein Beitrag kommentierenswert ist? Richtig, durch einen Vollfeed. Ich habe einige hundert Feeds abonniert, darunter einige Dutzend Blogs, bei denen ich kommentiere und wenn nur ein paar nichtssagende Worte im Teaser stehen, kann ich in den wenigsten Fällen einschätzen, ob sich das Lesen lohnt und aus Zeitgründen wird dann einfach der nächste Beitrag angeklickt.

Immer mal wieder haben Blogger angekündigt, dass gekürzte Feeds aus ihrem Reader rausfliegen (zuletzt Cowboy of Bottrop). Ganz so radikal sehe ich das nicht, aber es ist dennoch ein Minuspunkt. Wer sich bewusst gegen einen Vollfeed entscheidet, muss schon durchgängig sehr guten Inhalt bieten, damit ich weiter Abonnent bleibe. Einige Blogger wissen evtl. nichts davon, doch dagegen hilft eine Anfrage (z.B. per E-Mail) und so habe ich schon einige zum Vollfeed bewegen können. Oder man startet eine Kampagne , zu der es ein schickes Logo gibt (von Cindy) und eine Anleitung zum Umstellen und Schützen des Feeds.

Beim Stichwort “Schützen” sind wir schon bei den Gegenargumenten, die da lauten Contentklau, geringerer Traffic und fehlende Werbeeinnahmen. Doch alle drei sind Blödsinn:

• Klar ist Contentklau ein Problem und ärgerlich. Aber für den unwahrscheinlichen Fall, dass es dazu kommen sollte[1], gibt es Möglichkeiten dagegen vorzugehen (s.o.) und dann kann man immer noch den Feed kürzen, aber bis dahin nicht die Stammleser verärgern.
• Den meisten Traffic generieren doch die Stammleser, die immer wieder kommen und kommentieren, oder? Und wie hält man die am besten? Mit Vollfeeds!
• Stammleser klicken nie und nimmer auf Werbung und sind entweder blind dafür oder haben Blocker eingeschaltet. Durch die Stammleser gehen keine Werbeeinnahmen verloren! Eher im Gegenteil, denn die Klickrate wird dadurch verringert, also sollte man dafür sorgen, dass die Stammleser erst gar keine Werbung sehen, z.B. mit Who Sees Ads? oder Landing Sites.

1. herausfinden lässt sich sowas z.B. mit Franks @Feed-Plugin

Ein Nachteil bisher war, dass auch Entwürfe angezeigt wurden, was in den meisten Fällen nicht erwünscht ist. Die Funktionalität ist laut den Konfigurationsmöglichkeiten verfügbar, doch die entsprechenden Optionen werden nicht abgefragt. Dabei ist das relativ einfach zu beheben. Wer also auf der Suche nach einer Lösung ist, muss in zwei Dateien einige Zeilen einfügen (ohne die Zeilennummern natürlich).

Datei recents-posts.php (Ordner recent-posts):

$show_drafts = ($options['show_drafts']  !== 'false');

if ($show_drafts) $where[] = where_show_drafts();

Datei common-functions.php (Ordner post-plugin-library[2]):

function where_show_drafts() {
  return "post_status != 'draft'";
}

Die Dateien speichern und sich darüber freuen, dass endlich keine Entwürfe mehr in der Liste der neuesten Beiträge angezeigt werden!

1. Vom selben Autor gibt es die ähnlich konfigurierbaren Plugins Recent Comments, Random Posts, Similar Posts und eine Reihe weiterer.
2. Das ist ein Hilfsplugin des Autors um die gemeinsamen Funktionen alle beisammen zu haben.

Realisiert habe ich das mit der Anleitung von Frank Bültge und den Conditional Tags von WordPress.

Das FRS ist somit nur noch direkt über das FRS-Kategorie-Archiv erreichbar, das ich oben rechts in der Navigation verlinkt habe. Außerdem wird ein evtl. laufendes FRS in der Sidebar unter “Ankündigungen und Wegweiser” verlinkt sein – sowohl vorher (mit Countdown) als auch bis zwei Stunden nach Beginn.

Auf diese Weise hoffe ich, dass sowohl den Rätselnden als auch den Nicht-Interessierten das Lesen hier angenehmer gestaltet wird. Haltet Ihr das für eine gute Idee oder ist das überflüssig? Oder sollte ich weitere Dinge beachten?

1. Ob das mit dem Nichterscheinen im Feed tatsächlich klappt, wird sich am Montag zeigen.

Wie meine Umfrage zeigte, hätte die Mehrheit das Plugin aber trotz der Abmahngefahr weiterhin eingesetzt:

Wer nicht weiß, worum es geht: Die Vorgeschichte und Links zu weiteren Beiträgen gibt es im Umfragebeitrag.

Die E-Mail-Adresse wird im Vorfeld nicht überprüft und bestätigt, jeder Nutzer kann im Feld “E-Mail” jede beliebige Adresse angeben. Mögliches Szenario: Dieses Feature wird missbraucht, indem eine fremde Mailadresse angegeben wird und die Benachrichtigungen über neue Kommentare landen dann bei jemandem, der sie nicht bestellt hat. Das klingt für manche sicher harmlos, aber genau diese Lücke im System ist der mögliche Auslöser einer Abmahnung.

Denn habe ich den Fall, dass mein Blog “gewerblich” ist, könnten solche unerwünschten E-Mails als Spam ausgelegt werden. Ob und wann mein Blog gewerblich ist und ob die verschickten Nachrichten Werbung sind – das ist Auslegungssache.[...]

Jan schlägt vor, dass das Plugin um eine Funktionalität erweitert werden könnte, dass erst die Kommentarbenachrichtigung durch eine E-Mail mit einem Bestätigungslink geschickt wird.

Das Dilemma ist nun, dass für viele Kommentierer das Vorhandensein des Plugins eine Voraussetzung ist (evtl. sogar zum Abonnieren des gesamten Blogs). Einige Blogger haben allerdings schon die Konsequenz gezogen und das Plugin deaktiviert (Conny, Neri, Krötengrün, Prinzzess) oder machen sich Gedanken (Caschy, Frank Helmschrott). Ich halte es wie Gilly und werde es (vorerst) nicht deaktivieren, da ich es einfach für viel zu nützlich halte (z.B. beim Liedzeilen-Quiz). Doch was haltet Ihr davon?

Ursprünglich entwickelt wurde es für Werbeanzeigen, wo Start- und/oder Endzeitpunkt angegeben wird (bis auf die Minute genau, oder nur der Tag). Ich habe schon lange nach einer Lösung gesucht, wo ich bei meinem Liedzeilen-Quiz den nächsten Tipp automatisch anzeigen lassen kann und ab nächster Woche wird das ausprobiert.

Ein kleiner Test mit mehreren Bausteinen:
[wpsleep end="10.10.2008 11:00"]Es ist noch vor 11 Uhr am 10. Oktober.[/wpsleep]
[wpsleep start="10.10.2008 11:00" end="10.10.2008 14:00"]Es ist jetzt zwischen 11 und 14 Uhr am 10. Oktober.[/wpsleep]
[wpsleep start="10.10.2008 14:00" "]Es ist mittlerweile nach 14 Uhr am 10. Oktober.[/wpsleep]
Hm, mehrere Start- und Entzeitpunkte scheinen verwirrend zu sein.

(via)

• Wie viele Blogs lest ihr regelmäßig?
  Damit sind die Feeds gemeint? Ich würde schätzen so um die 200, wo auch einige Karteileichen dabei sind, die ich der Durchsuchbarkeit halber noch abonniert habe. Die Regelmäßigkeit hängt stark vom Blog selber ab und variiert. Eine dreistellige Anzahl Feeds ist nicht so ungewöhnlich, wie z.B. die Umfrage bei Chikatze gezeigt hat.[2]
• Wie lange nehmt ihr euch jeden Tag dafür Zeit?
  Das variiert von Tag zu Tag, und hängt davon ab, wie viele Beiträge erschienen sind und wieviel Zeit ich habe. Am Wochenende lese ich die langen Beiträge, die die Woche über aufgelaufen sind und deswegen schwankt die Zeit so zwischen einer halben Stunde und zwei Stunden täglich.
• Wie verwaltet ihr eure Feeds?
  Das geht mit dem GoogleReader wunderbar durch die Tags und die Tastenkombinationen. Ich habe verschiedenen Prioritäten und Themenbereiche (Musik, Fotografie, Nachrichten). Mein System basiert weitestgehend auf dem von Marcel Weiß, das er im Beitrag Wie ich über 300 Feeds lese vorgestellt hat. Mittlerweile kann man die Tags im GoogleReader auch durch Verschieben beliebig anordnen, so dass ich nur mit der Leertaste alles durchsehen kann.
  Außerdem nutze ich öfter den Button Mark all as read, z.B. wenn sich mehr als 50 Nachrichtenbeiträge angesammelt haben. Das Überfliegen der Überschriften bietet genauso viel Information wie das Anschauen eines jeden Beitrags (wo meist nur ein Satz steht) und es dauert nur Sekunden.
• Wo sind die Vorteile dieser Art?
  Es geht schnell und man sieht gleich, was los ist. Ich habe z.B. die abonnierten Blogs unterteilt in solche, wo ich kommentiere und solche, die ich nur lese. Letztere können auch mal ein paar Tage oder sogar komplett ungelesen bleiben.
• Wo liegen die Nachteile?
  Sehe ich eigentlich keine, außer dass man vielleicht glaubt, noch ein paar mehr Feeds lassen sich locker verwalten.
• Habt ihr von anderen Alternativen gehört die ihr mal testen wollt?
  Bisher bin ich sehr zufrieden mit dem GoogleReader, den ich nutze, weil ich einen rechnerunabhänigen Feedreader benötige und weil man mit den Tastenkombinationen wahnsinnig bequem und schnell navigieren kann.
  Doch in beetFreeQs Beitrag sprach er GreatNews an, den man vom USB-Stick betreiben kann. Der hörte sich sehr interessant an und besonders die einstellbaren Abrufintervalle finde ich gut. Werde ich mir vielleicht mal in einer ruhigen Stunde ansehen.

Zum Thema Feeds habe ich mich übrigens schon öfter ausgelassen und mehr Details findet der interessierte Leser in den Beiträgen Blog-Parade: Feed-Reader, Feedst du schon? (Oder besuchst du noch live?) und Freitägliche, Faserige Feed-Fragen.

So, Sascha, hoffentlich waren einige hilfreiche Tipps dabei und hoffentlich machst du eine schöne Auswertung! Die Blog-Parade läuft noch bis 10. September.

1. Nach eigener Aussage erst seit einem Monat dabei. Beweist sich aber durch die Verwendung von blog-parade.de und das Trackback-Angebot als informierter Anfänger. Lobenswert!
2. Das Umfrage-Plugin ist gerade nicht aktiviert, deswegen ist das Ergebnis nicht sichtbar. Soweit ich mich erinnere, haben mehr als die Hälfte eine dreistellige Anzahl Feeds abonniert.

Der Vorteil der Module wird jedoch durch den Nachteil einer möglicherweise auftretenden Fehlermeldung getrübt. Bei Verwendung des K2-Themes mit Sidebar Modules kann es zur folgenden Fehlermeldung im Dashboard kommen:

Warning: array_keys() [function.array-keys]: The first argument should be an array in /path/to/wordpress/installation/wp-includes/widgets.php on line 676

Warning: Invalid argument supplied for foreach() in /path/to/wordpress/installation/wp-includes/widgets.php on line 676

Die Fehlermeldung tritt auch bei anderen Themes auf, doch dafür gibt es eine bekannte Lösung (via). Bei mir jedoch verschwand die Fehlermeldung nicht, auch nicht wenn alle Plugins deaktiviert waren, bei Verwendung des Standard-Themes, bei erneutem Kopieren aller Dateien per FTP und bei Aktualisierung auf WP-Version 2.6 und den neuesten K2 Nightly Build. Das besonders Nervige an der Geschichte war, dass bei Aufruf der Dashboard-URL eine weitere Fehlermeldung erschien, die verhinderte, dass man sich einloggen kann. Doch ich habe durch Zufall entdeckt, wie die Fehlermeldung verschwindet:

1. Sidebar Modules durch Widgets ersetzen (Deaktivierung des Plugins K2 Disable Widgets),
2. mindestens ein Widget erstellen (die Anzahl wird im Dashboard angezeigt, sollte vorher 0 gewesen sein),
3. Sidebar Modules wieder aktivieren.
4. [optional: Widgets wieder entfernen]

Auf diese Weise sollte die Fehlermeldung verschwinden.

Der Nachteil ist jedoch, dass dadurch manche Widgets von Plugins nicht verfügbar sind (z.B. Recent Comments, WP-Stats). Um die Verwirrung perfekt zu machen, stehen manche Widgets eben doch zur Verfügung (z.B. A Year Before, Countdown Timer). Ich vermute es liegt daran, dass es mehrere (und verschieden aktuelle) Möglichkeiten gibt, die Widgets “anzumelden”. Bisherige Versuche meinerseits, per Kopieren, Einfügen und Anpassen die fehlenden Widgets zu erzeugen, sind gescheitert. Und bei einer Aktualisierung der problematischen Plugins würden diese Änderungen wieder zunichte gemacht würden.

Hat vielleicht jemand Ähnliches erlebt oder kennt sich mit Widgets in WordPress oder kann sonst einen hilfreichen Kommentar abgeben? Ansonsten wollte ich nur bemerkt haben, dass ich sowas echt deprimierend finde!

1. Hach ja, immer diese Selbstreferenzialität!
2. Die Sidebar Modules gab es ursprünglich als Plugin, das aber aufgrund des tiefen Eingriffs in die WP-Funktionalität bei jedem Versionssprung angepasst werden musste und mit Version 2.5 endgültig nicht mehr einsatzfähig war. Es hieß wiederholt, dass die Module die Widgets in WordPress ersetzen sollen, aber auch bei der diese Woche erschienenen Version 2.6 ist dies nicht der Fall.

Vielleicht ist es einigen Besuchern in den letzten Tagen schon aufgefallen, dass hier im Blog eine Zeitanzeige zu sehen war, die auf den Download Day hinwies, d.h. der Weltrekordversuch für den Firefox 3. Auf der Startseite gab es einen Zähler, der erst den gestrigen Start um 19:00 ankündigte und momentan bis zum heutigen Ende um 19:00 runterzählt.

Dies ist aber nur ein einmaliges Ereignis und deswegen alleine würde sich die Installation des Plugins nicht lohnen. Doch wer öfter auf (den Start) wichtige(r) Ereignisse hinweisen oder an wiederkehrende Ereignisse erinnern möchte, für den ist der Countdown Timer optimal. Bei mir ist dies z.B. das mein Liedzeilen-Quiz, das Donnerstags um 16 Uhr beginnt. Der Zähler dient somit einerseits als Erinnerung für regelmäßige Besucher, die auf meinen Blog kommen, teilnehmen möchten und auf diese Weise hoffentlich den Zeitpunkt nicht verpassen. Anderseits ist es ein Hinweis für neue Besucher, dass sie auf das Quiz aufmerksam werden und vielleicht beim nächsten Termin teilnehmen möchten.

Das Plugin funktioniert mit WordPress-Versionen 2.5.* und das Einrichten von Ereignissen ist sehr einfach per Maske möglich. Zu jedem Termin kann man einen Link angeben. Außerdem kann das Ereignis optional noch eine bestimmte Zeit nach Ablauf der Frist angezeigt werden. Beim Beispiel Liedzeilen-Quiz habe ich die Frist auf zwei Stunden gesetzt, um anzuzeigen, dass es gerade läuft.

Die Optionen zur Personalisierung der Anzeige sind vorbildlich, z.B. die HTML-Tags für die Ereignisanzeige (Standard: unnummerierte Liste), CSS-Angaben und das Aussehen des Zeitformats.

Die Anzeige selber ist ebenfalls einfach, entweder per Widget oder per Einfügen einer Zeile PHP-Code. Die Beschreibung dazu findet sich auf der Einstellungsseite des Plugins und der Schnipsel kann einfach an die entsprechende Stelle im Code kopiert werden. Auf diese Weise ist es auch möglich durch Übergabe einer direkten Zeitangabe ein einzelnes Ereignis anzuzeigen.

Jedenfalls stimmte nach dem Update die Angabe der Feed-Adresse bei FeedBurner nicht mehr. Mein Original-Feed, der von WordPress erzeugt wird, wird an FeedBurner weitergeleitet und dafür muss die Feed-Adresse angegeben werden. Bisher war da

http://49suns.de/wp-rss2.php

angegeben, was ich irgendwo mal gelesen habe. Doch damit war der Feed leer[2]. Ersetzen der Adresse mit

http://49suns.de/feed

behob das Problem und die Feed-Vorschau enthielt wieder alle Beiträge.

Gleiches galt für den Kommentarfeed, wo durch Ersetzen von

http://49suns.de/wp-commentsrss2.php

durch

http://49suns.de/comments/feed

wieder alles läuft.

1. Ich konnte es genau lokalisieren mit Kommentarfeed, denn der letzte, der ankam war um kurz nach 10 Uhr und der nächste um kurz vor 11 dann nicht mehr. Und mithilfe eines Kommentars bei Alex
2. Bei FeedBurner ist es möglich, eine Vorschau seines Feed zu sehen.

Das hätte mir auffallen müssen, denn wenn man eingeloggt ist, wird dies beim Kommentieren auf einem anderen wordpress.com-Blog angezeigt und die Felder für Name, E-Mail-Adresse und Website werden automatisch mit den im Profil angegebenen Daten ausgefüllt. Das ist möglich, da man sich immer noch auf derselben Website befindet[1]. Ohne eigenen Blog können diese Daten beliebig sein, da sie irrelevant sind[2].

Aufgefallen war das Versehen, als Andi fragte, wie man denn den Hauptblog einstellt. Danke, Andi, dass dir das aufgefallen ist und auch, dass du die Lösung rausgefunden hast!

Wer also auch die Kommentarverfolgung trotz sel(bstge|f-)hosted (???) Blog nutzen möchte, geht folgendermaßen vor:

• Ohne WordPress-Account: Registriere einen neuen Blog
  Achtung: Nutzername und Blogname können nicht mehr geändert werden! Der Nutzername wird beim Kommentieren angezeigt, d.h. er identifiziert dich. Ist dein regulärer Nickname schon vergeben, wähle einen ähnlichen. Wenn du den Blog nicht öffentlich nutzen willst, wähle einen entsprechenden Namen. Empfehlenswert ist der Titel deines regulären Blogs. Damit nimmst du niemandem den Namen weg und umgekehrt kann niemand deinen Blognamen nutzen.
• Mit bestehendem WordPress-Account: Einloggen und Blog erstellen[3]
  Bei der Auswahl des Blognamens gelten die gleichen Überlegungen wie im vorherigen Punkt.
• Nach dem Erstellen des Blogs, muss der reguläre Blog registriert werden, was auf der wp.com-Startseite mit dem gleichnamigen Link möglich sein sollte, wenn man eingeloggt ist (siehe Screenshot).
• Ist der Blog registriert, muss er als Hauptblog eingestellt werden. Das geht sowohl auf der wp.com-Profil-Seite oder auf der Profil-Seite des wp.com-Blogs (Link “Mein Profil” oben rechts im Adminbereich).
• Nachtrag: (Danke, Pas): wenn der gewünschte Nutzername nicht dein regulärer Nickname ist, kannst du den gewünschten Namen im Profil angeben und auswählen welcher Name öffentlich angezeigt werden soll. Im Dropdownmenü unten sollte der Nutzername und der Nickname auswählbar sein. (siehe Screenshot)

1. Beachte den Unterschied zwischen WebSITE (= ganzes Projekt) und WebSEITE (= einzelne Seite des Projekts)!
2. Eine gültige E-Mail-Adresse ist nur wichtig, wenn man Kommentarbenachrichtigungen empfangen möchte.
3. Ist das die richtige Seite? Da ich schon einen wordpress.com-Blog habe, kann ich das nicht mehr nachvollziehen.

Vielleicht sind die folgenden Tipps schon lange bekannt[2] und ich war einfach nur sehr lange Zeit sehr blind. Aber vielleicht sind die folgenden Informationen für manche doch ganz hilfreich. Laut der Blog-Paraden-Auswertung vom Webmaster Watchblog nutzen 85% der Blogger WordPress als Software. Die Verteilung von eigenen Blog vs. Blog bei wordpress.com geht daraus nicht hervor, obwohl das herauszufinden gewesen wäre[3].

Spamabwehr: Akismet

Das Anti-Spam-Plugin, das schon bei der Standardinstallation von WordPress dabei ist, kennt sicherlich jeder. Doch damit es läuft, benötigt man einen API-Key, den man nur bekommt, wenn man besagten WordPress.com-Account hat.

Das war auch bei mir der Grund, warum ich diesen nie genutzten Account hatte. Mittlerweile nutze ich Akismet nicht mehr, sondern Defensio, das ähnlich funktioniert[4].

Ausgelagerte Statistiken: WP-Stats

Den API-Key benötigt man auch für dieses Statistik-Plugin, das Statistiken erfasst und zwar extern bei WordPress. Das hat den Vorteil, dass der eigene Server bzw. die eigene Datenbank nicht belastet wird.

Die erfassten Statistiken sind nicht sehr umfangreich, aber die wichtigsten Zahlen sind dabei. Gezählt werden die Besucherzahlen (in einer Kurve mit Tages-, Wochen- oder Monatsansicht), die meist gelesenen Beiträge, häufigsten Referrer, ausgehende Klicks und Suchbegriffe vom heutigen und gestrigen Tag. Für jeden Beitrag kann die Kurve auch einzeln aufgerufen werden:

Dieses Plugin verwende ich erst seit Kurzem, denn beim ersten Ausprobieren letztes Jahr funktionierte es nicht wie gewünscht. Es hieß, dass die ersten Zahlen nach 20 Minuten verfügbar sind, aber es wurden keine Besucher aufgezeichnet. Dieses Mal hatte ich mehr Geduld und am nächsten Tag (nach 20 Stunden?) wurde dann gezählt. (zuerst gelesen bei Caschy und dann bei Alexander)

Kommentare verfolgen

Dieses Feature ist überhaupt der Grund für diesen Beitrag und warum ich einen WordPress.com-Account für Selbsthoster empfehle. Im Reiter Meine Kommentare sieht man bei welchen Beiträgen man Kommentare abgegeben hat und dazu noch ein paar vorherige und nachfolgende Kommentare. Das ist eine sehr sinnvolle Funktion, die mich auch dazu animiert, mehr oder überhaupt Kommentare bei Blogs abzugeben, die bei wordpress.com laufen[5]. Vorher war es mühsam, den Überblick zu behalten bzw. zeitaufwändig, alle Blogs aufzurufen und nachzusehen, ob es neue Kommentare gibt. Deswegen habe ich das Kommentieren meist gleich sein lassen[6]. Aber jetzt sehe ich das alles bequem in meinem Adminbereich: Screenshot verlinkt auf den zugehörigen Beitrag

Daneben gibt es noch den Schnellzugriff auf einige Adminseiten, wenn man sich auf worpress.com aufhält, wie z.B. den globalen Tellerrand, meine Kommentare und Beitrag schreiben. Die Bezeichnungen sind allerdings alle auf englisch; habe ich da eine Einstellung übersehen?

Gibt es überhaupt noch mehr schöne Funktionen, die ein WordPress.com-Account bietet, die hier fehlen? Erleuchtet mich!

1. Selbst gehostet ist ein ganz schlimmer denglischer Ausdruck, aber mir fällt in richtigem Deutsch nichts ein, das genau das ausdrückt. Vorschläge bitte in die Kommentare.
2. So lange gibt es diese Features noch nicht, oder? Kann da jemand genaueres sagen? Links?
3. Doch ich will nicht meckern. Die Auswertung von 100 Teilnehmerbeiträgen war an sich schon aufwändig, ohne dass noch extra Ansprüche gestellt wurden.
4. Für Defensio benötigt man ebenfalls einen API-Key und die Erfolgsrate beim Einordnen ist ok. Es ist etwas strenger bei der Beurteilung, weshalb einige gute Kommentare erstmal in der Moderation landen.
5. z.B. Katja, Basti und Roman
6. Obwohl ich die drei angesprochenen schon recht lange lesend verfolge

Ich habe das am Wochenende durchgeführt und gebe hier noch ein paar Tipps, für diejenigen, die es mir gleichtun möchten.

1. Angefangen wird natürlich mit einem Datenbank-Backup. Alles andere wäre grobe Fahrlässigkeit. In diesem Zusammenhang empfehle ich die Plugins WordPress Database Backup und WP-DB-Manager
2. Das Plugin wurde eigentlich für WP-Version 2.2 geschrieben. Wer wie ich die aktuelle Version 2.3.2 verwendet, wird deshalb nach Aufruf der Plugin-Seite im Admin-Bereich mit folgender Meldung begrüßt:

WARNING
VERSION NOT SUPPORTED

This plugin has been developed and successfully tested under WordPress 2.2.x and 2.1.x
We cannot assure that it will work in any other minor or major release.
If you still want to use it after this warning proceed with the next and final step.

Also this warning may show if you change the version value “wp_version” inside the file “/wp-includes/version.php”, so if you have changed this value and you know that you have supported version of WordPress… Ignore this warning and continue to the next and final step.

Diese und die nächste Warnung kann man ignorieren, denn es sollte auch mit der aktuellen WordPress-Version funktionieren. Hat es zumindest bei mir. Für den Negativfall gibt es das Backup.

3. Nach der Konvertierung in Unicode werden die in der Datenbank stehenden kryptischen Zeichen im Blog in die richtigen Umlaute und Sonderzeichen umgewandelt. Wenn allerdings in der Datei wp-config.php die Zeile

   define('DB_CHARSET', 'utf8');

   steht (was empfehlenswert ist), dann werden die kryptischen Zeichen so wie sie sind im Blog dargestellt. Deshalb müssen diese durch die richtigen Zeichen ersetzt werden, was relativ schnell mit Suchen und Ersetzen geschieht[2].

Jetzt kann WP 2.5 kommen. Dauert zwar noch genau zwei Monate, aber besser früh als gar nicht (oder so ähnlich). Ein besonders schöner Nebeneffekt der Konvertierung ist übrigens, dass jetzt endlich auch bei der Anzeige der letzten Kommentare Umlaute und Sonderzeichen funktionieren:

1. Insofern ist dieser Beitrag nur für Blogger interessant, die mit WordPress bloggen und dies auf eigenen Webspace tun.
2. Wenn ich einige übersehen habe, bitte ich um Rückmeldung.

1. Welche Blogsoftware verwendet ihr bzw. bei welchen Bloganbieter seid ihr angemeldet?
   Wie der Großteil der Gemeinde bin ich WordPress zugetan. Keine große Überraschung an dieser Stelle.
2. Wie seid ihr auf die Blogsoftware/den Anbieter gestoßen?
   Das weiß ich gar nicht mehr genau. Bevor ich angefangen habe zu bloggen, habe ich lange nur Blogs gelesen und hatte dann irgendwann spontan den Entschluss gefasst, dass ich das auch machen möchte. Ausgesucht hatte ich mir MovableType als Blogsoftware, doch mein Hoster erfüllte die Vorgaben nicht und so habe ich was gesucht, das passt und bin bei WordPress gelandet[1].
3. Welche Vorteile hat ihre Blogsoftware/ihr Anbieter?
   Natürlich die große Verbreitung, denn deswegen gibt es fast sicher für jedes Problem irgendwo eine Lösung. Das betrifft sowohl die Erweiterbarkeit (Plugins, Themes) als auch die Fehlerbehebung.
4. Welche Nachteile sind euch aufgefallen?
   Es wurden im Rahmen dieser Parade öfter mal die häufigen Updates genannt und dem kann ich bedingt zustimmen. Updates sind prinzipiell ok und natürlich auch wichtig wegen Bugfixes und neuen Funktionen. Das Nervige sind die großen Umstellungen, die nur schwer zu bewältigen sind, wenn man nicht die absoluten Standardeinstellungen in seinem Blog hat.
5. Wie viel Zeit investiert ihr ins Bloggen pro Tag?
   Schwer zu sagen und sehr variabel. Es können schon mal mehrere Stunden sein (z.B. am Wochenende und/oder wenn ein längerer Beitrag ansteht) und dann wieder fast gar nichts. Im Durchschnitt werden es so anderthalb bis zwei Stunden sein.
6. Wie viele Besucher habt ihr pro Tag durchschnittlich?
   Da sind sich meine Statistiktools nicht einig, vermutlich 200-250 oder 300-400 eindeutige Besucher/Tag.
7. Wie viel verdient ihr pro Monat mit eurem Blog? (freiwillige Angabe)
   Wenn man die Hostingkosten (und die Portokosten für meine CD-Verlosungen) abzieht, gebe ich mehr aus, als ich einnehme. Das Einkommen war bisher relativ lächerlich (ein paar Dollar von AdSense). Seit letztem Monat habe ich endlich meine Linkplätze vermietet und hoffe den Januar zumindest ohne Verluste abschließen zu können.

Nachtrag nach Beendigung der Parade: Die Teilnehmerliste 100 (!) Teilnehmern werde ich hier nicht aufführen. Stattdessen empfehle ich die schöne Auswertung von Webmaster Paul.

1. WordPress wird mit einem großen P geschrieben. Immer drauf achten!

Bildquelle: Coppermine Logo Competition

Das Problem betrifft wahrscheinlich nicht viele Nutzer, aber es soll noch Leute geben, die nicht auf einer Foto-Community-Seite (engl. Photo Sharing) ihre Fotos hochladen und ausstellen, sondern auf dem eigenen Server eine Galerie betreiben, so wie meiner einer. Eines der verbreitetsten und beliebtesten Programme dafür ist Coppermine. Jedenfalls gibt es sicherlich einige WordPress-Nutzer, die diese Galerie verwenden und vielleicht auch noch einige zufällige Bilder in der Sidebar anzeigen lassen wollen.

Bei der Gelegenheit habe ich übrigens auch das Galerie-Theme an das geänderte Blog-Theme angepasst. Das war etwas fitzelig, bis alles so aussah, wie ich wollte[1] und bis es validierte. Nun aber zum eigentlichen Thema dieses Beitrags.

Klassisch mit dem Coppermine-Plugin für WordPress

Bevor wir zur eigentlichen Methode kommen, noch eine kurze Vorgeschichte. Die Entwicklung des ursprünglichen Plugin wurde irgendwann letztes Jahr eingestellt[2], aber bis zur WordPress-Version 2.3 war das egal, da es trotzdem weiterhin funktionierte. Irgendwann habe ich es auch aufgegeben, an den entsprechenden Stellen nach Aktualisierungen zu suchen und habe damit verpasst, dass seit Mai doch weiter entwickelt wird (Altenativversion) und es neue Features gibt[3]. Und mittlerweile ist es auch für WP 2.3 verfügbar.

Das Plugin kann sehr viel mehr, als nur einfach Bilder in der Sidebar anzeigen. Es bietet eine echte Verbindung der zwei Programme, so dass z.B. beim Schreiben eines Beitrags in WordPress mehrere Felder von Coppermine angezeigt werden, mit denen man Bilder aus der Galerie einfügen kann (bei mir hier tauchen ja ab und zu solche Bilder auf).

Um nun damit zufällige Bilder in der Sidebar anzeigen zu lassen, (muss zunächst einmal das Plugin installiert und eingerichtet sein (Anleitung bei MrsBumblebee), aber das setze ich jetzt voraus) wird an entsprechender Stelle, d.h. in der sidebar.php oder in einem Widget die folgende Funktion aufgerufen[4]:

cpg_random_images($num, $owner_id=0,$style=array());

Von den Optionen ist eigentlich nur $num wichtig, d.h. wie viele Bilder angezeigt werden (standardmäßig: 0). Mit owner_id können die Bilder eines bestimmten Nutzers angezeigt werden (standardmäßig: von allen) und mit $style=array() kann das Aussehen des Links und des Bildes angeglichen werden (standardmäßig: Bild zentriert, Link zur Einzelbildansicht).

Die Anzeige rechts in der Sidebar mit drei Bildern wurde also realisiert mit

cpg_random_images(3);

Diese Lösung ist also optimal für jemanden, der generell eine Einbindung von Coppermine in WordPress möchte und sich soweit mit den Gegebenheiten auskennt, dass er das Plugin richtig installieren und konfigurieren kann[5] und die Templatedateien anpassen kann bzw. ein PHP-Widget erstellen kann.

Ein Bild mit dem Coppermine-Widget

Es gibt ein Widget zur Anzeige (eines) zufälligen Bildes, das auf das obige Plugin zurückgreift. Meines Wissens funktioniert das allerdings nicht mehr. Bei wem das nicht der Fall sein sollte, der kann natürlich damit ganz einfach ein Zufallsbild anzeigen lassen.

Vorteil ist hier, dass man nicht viel machen muss, da das Widget das andere Plugin nutzt. Man muss natürlich ein Theme haben, dass Widgets unterstützt. Ein Nachteil ist, dass man nicht viel einstellen kann und nur durch Bearbeiten der Plugindatei das Aussehen ein wenig anpassen kann. Möchte man z.B. drei statt ein Bild angezeigt bekommen, so sucht man die Zeile, in der die Funktion aufgerufen wird mit cpg_random_images(1); und ändert die 1 in eine 3.

Bastelei mit dem CpmFetch-Plugin für Coppermine

CpmFetch ist ein Plugin für Coppermine (nicht für WordPress!), mit dem man so tolle Sachen machen kann wie

• Display tables of images from your gallery.
• Display statistics from your gallery.
• Retrieve data to format as you wish.
• Extend the CpmFetch object.
• Generate RSS Feeds.

Das ist ja genau das, was hier verlangt wird. Das Problem ist nur, dass das etwas fitzelig werden könnte. Aber die Dokumentation hilft da weiter. So habe ich mir ein PHP-Widget gebastelt, das folgenden Inhalt hat

  include "/home/user/www/cpg/cpmfetch/cpmfetch.php";
  $objCpm = new cpm("/home/user/www/cpg/cpmfetch/cpmfetch_config.php");
  $opti = array('imagewidth' => 180);
  $opti = array('imagelink' => int);
  $objCpm->cpm_viewRandomMedia (3,1,$opti);    // 
  $objCpm->cpm_close();

Hier wird einmal das CpmFetch-Plugin von Coppermine eingebunden und dann ein neues Cpm-Objekt ($objCpm) erzeugt, das dann mit cpm_viewRandomMedia (3,1,$opti); die zufälligen Bilder (3 Zeilen, 1 Spalte) aufruft. Die nötigen Parameter habe ich mir aus der Dokumentation zusammengesucht.

Wichtig zu erwähnen ist vielleicht noch, dass die beiden Pfadangaben hier ausnahmsweise absolut sind, da ich den Blog und die Galerie unter verschiedenen URLs betreibe. Ansonsten hätte man auch einen relativen Pfad verwenden können (wie z.B. ../cpg/cpmfetch/cpmfetch.php).

Dies ist sicherlich die Methode, bei der man am meisten anpassen kann. Allerdings nur, wenn man weiß, wie es geht. Ich habe die richtigen Optionen durch Probieren rausgefunden und ganz so, wie ich es wollte, habe ich es doch nicht hinbekommen.

Einfach und komfortabel mit dem CpmFetch-Widget

Da das Basteln mit den Parametern nicht jedermanns Sache ist, gibt es natürlich auch ein komfortables Widget. Damit können die obigen Parameter per Eingabe bestimmt werden und außerdem können noch die neuesten und die am häufigsten angesehenen Bilder angezeigt werden.

Das ist bei Weitem die einfachste Methode, die am wenigsten Kenntnisse voraussetzt. Man muss nur das CpmFetch-Plugin für Coppermine und das CpmFetch-Widget für WordPress installieren und schon kann es losgehen. Naja, nicht ganz, denn auch hier schlug wieder das Pfadproblem zu. Der Autor des Plugins hat zwar Hinweise zur Lösung des Problems gegeben, aber es war nicht ganz einfach, die richtigen Stellen anzupassen. Sollte jemand das gleiche Problem haben, der kann sich gerne an mich wenden, denn ich weiß jetzt, wo was angepasst werden muss.

Fazit: Für jeden, der Coppermine verwendet und seine Bilder in WordPress einbinden möchte, sollte es mit einer der vier Möglichkeiten machbar sein. Ich habe drei davon erfolgreich ausprobiert und mich schließlich für die erste Variante entschieden.

Wer jetzt auf den Geschmack gekommen ist, kann das ja mal ausprobieren. Bei Fragen stehe ich gerne zur Verfügung bzw. vielleicht gibt es bei den Originalautoren der entsprechenden Plugins schon eine Lösung.

1. Falls jemandem, der mit dem IE 6 unterwegs ist, auffällt, dass die Sidebar ganz unten ist: das weiß ich, das liegt daran, dass der IE overflow:visible nicht richtig interpretiert.
2. Mittlerweile existiert auch die Seite des Programmierers nicht mehr.
3. Ein dickes Dankeschön an den Entwickler an dieser Stelle!
4. PHP-Code kann in Widgets mithilfe des Plugins PHP Exec ausgeführt werden.
5. Die Datenbankverbindung muss hergestellt werden und die Nutzer von Galerie und Blog müssen eingestellt werden.

Mögliche Ursache: PHP5. Ist PHP5 auf dem Server installiert? Schnell mal nachprüfen! Wer nicht weiß, wie das geht (z.B. mit phpinfo() oder phpversion()), dem sei das Plugin Phpinfo empfohlen.

Die PHP-Version hat zwar nur indirekt etwas mit der Problemursache zu tun, aber es tritt nicht bei PHP4 auf. Wer ganz schnell das Problem beheben will, der bearbeite die Datei wp-includes/gettext.php und ersetze die Zeilen

if ($magic == ($MAGIC1 & 0xFFFFFFFF) || $magic == ($MAGIC3 & 0xFFFFFFFF)) {
// to make sure it works for 64-bit platforms
  $this->BYTEORDER = 0;
} elseif ($magic == ($MAGIC2 & 0xFFFFFFFF)) {

durch

if ($magic == $MAGIC1 || $magic == $MAGIC3) {
  $this->BYTEORDER = 0;
} elseif ($magic == $MAGIC2) {

Das müssten aktuell die Zeilen 117-119 sein. Der Kommentar (eingeleitet durch “//”) kann natürlich drin bleiben, aber der wäre dann falsch an dieser Stelle.

Diese Lösung habe ich im offiziellen WordPress-Forum gefunden, wo auf den ursprünglichen Beitrag in einem dänischen WP-Forum verwiesen wurde.

Wer jetzt noch wissen möchte, wieso das so ist, dem kann ich nicht wirklich weiterhelfen. Denn warum sich die Kombination von PHP5, 64-Bit-Plattform-Absicherung und GNU-gettext[1] so seltsam auswirkt, das weiß ich nicht. Wer sich aber für das Grundprinzip der Lokalisierung interessiert, den verweise ich auf meinen langen Beitrag über Lokalisierung.

1. GNU-gettext ist eine Bibliothek, die genutzt wird, um ein Programm, wie z.B. WordPress, in mehreren Sprachen anzubieten.

Doch mit dem Wechsel zum Theme K2 hoffte ich, dass ich endlich ELA nutzen kann, da es von K2 ebenfalls schon von Haus aus unterstützt wird. Doch leider funktioniert das Plugin mit der neuen WP-Version nicht mehr[1] und deshalb wird es in K2 nur verwendet, wenn man eine ältere Version von WP am Laufen hat. Zum Glück gibt es aber einen Patch und K2 kann ganz einfach “überredet” werden, das Plugin zu verwenden.

Extended Live Archives mit WordPress 2.3 verwenden

Wem die Präsentation des Plugins gefällt und es trotz WP 2.3 nutzen möchte, für den gibt es hier eine kurze Anleitung.

1. ELA von der offiziellen Seite runterladen (neueste Version 0.10 beta R18),
2. Patch für WP 2.3 runterladen,
3. beide Archive entpacken und die entsprechenden Dateien des Plugins durch die des Patches ersetzen,
4. im K2-Theme-Ordner in der Datei page-archives.php die Zeile 36 ändern von

   if (function_exists('af_ela_super_archive') && !($wp_version > 2.2)) {

   zu

   if (function_exists('af_ela_super_archive')) {

5. und dann endlich das Plugin aktivieren, initialisieren und anpassen.

Und nun viel Erfolg mit dem Plugin. Das gilt natürlich auch für alle Nicht-K2- und Nicht-WP-2.3-Nutzer, die wie ich das ELA einfach praktisch und cool finden.

Prinzipielles zum Archiv

Wer eine Archivseite für seinen Blog hat (meiner Meinung nach sollte das jeder), dem sind vielfältige Möglichkeiten geboten, die Beiträge seines Blogs zu präsentieren. Es gibt unzählige Plugins, die noch mehr Darstellungsvarianten bieten. Man kann die Kategorien und Tags präsentieren, eine datumsorientierte Auflistung, oder wichtige bzw. beliebte Beiträge, oder, oder, oder. Das schöne an ELA ist, dass es alle drei Möglichkeiten anbietet und auf geschickte Weise präsentiert.

Warum sind mehrere Archiv-Varianten überhaupt nötig? Weil je nach Suchverhalten bzw. Vorlieben verschiedene Wege zum Ziel, d.h. zum gewünschten Beitrag führen. Den ersten und wichtigsten Einstieg sollte die die Sidebar bieten und auch hier gibt es (hoffentlich) eine übersichtliche und einfache Navigation ins/durchs Archiv. Für die Kategoriewolke und die kompakte Monatsansicht nutze ich zwei Plugins (Category Cloud und Compact Monthly Archive), die beide vielfältige Einstellungsmöglichkeiten bieten und meiner Meinung nach besser als die WP-Standardauflistungen von Kategorien und Monaten sind. Die Tag-Wolke ist bei WordPress mittlerweile (Version 2.3) standardmäßig verfügbar.

Neben diesen platzsparenden Archiveinstiegen gibt meine Archivseite eine ausführlichere Übersicht darüber, was man sich hier so alles ansehen und durchlesen kann. Momentan ist die Seite wegen dem Themewechsel noch im Um- und Aufbau begriffen, aber es gibt noch einige weitere Arten, das Archiv zu durchstöbern.

Welche Plugins bzw. Archivanischten nutzt Ihr denn und welche haltet Ihr für die Wichtigsten?

1. Einige Datenbanktabellen wurden geändert bzw. die Kategorientabellen werden nicht mehr genutzt und dafür gibt es neue Tabellen für Tags.

Kurze Vorgeschichte: ich plane in den nächsten Tagen, das Update auf 2.3 vorzunehmen und probiere deswegen auf einem Testblog, ob es im Ernstfall problemlos ablaufen wird. Heute habe ich mich genauer mit den Tags befasst. Da die WP-eigene Tag-Funktionalität sehr rudimentär ist, habe ich mich entschlossen, weiterhin das Simple Tagging-Plugin zu verwenden. Für die WP-Version 2.3 wurde es umbenannt in Simple Tags. Es bietet u.a. folgende Vorteile

• Autovervollständigung
• Vorschläge für relevante Tags
• Tagverwaltung (Umbenennen, Löschen, Zusammenfügen, Suche, Hinzufügen, Bearbeiten der Tag-ID)
• Liste nicht getaggter Inhalte (Beiträge und Seiten)
• Masseneditiermodus
• Verwandte Tags und Beiträge

Mehr zum Plugin und WordPress 2.3 im Software Guide.

Erfreulich war, dass das Update, der Import der Simple Tags in WP und das anschließende Installieren des Simple Tag-Plugins problemlos verlief. Aber dann fiel mir auf, dass die Links zu Tags mit Umlauten nicht funktionierten, d.h. anstatt Nervensägen wurde nervensa%c2%a4gen in der URL angezeigt. Eine Suche ergab, dass auch Andere vor dem Problem standen.

Hier kommt jetzt das Plugin ins Spiel. Denn die Tagverwaltung bietet die Möglichkeit, die Tag-Rohlinge zu bearbeiten. Was genau sind Rohlinge bzw. Slugs? Hier hilft das WordPress-Glossar:

A slug is a few words that describe a post or a page. Slugs are usually a URL friendly version of the post title (which has been automatically generated by WordPress), but a slug can be anything you like.

Ein bisschen Handarbeit ist nötig, um die Tag-Rohlinge umzubennen. Dazu ruft man die Tagverwaltung auf und klickt auf alle Tags, die Umlaute enthalten. Das ist ein weiteres Feature von Simple Tags, denn beim Anklicken des Tags wird es automatisch in den Bearbeitungsfeldern eingefügt. Das letzte Bearbeitungsfeld ist das, welches wir hier benötigen:

Ich habe einfach die Liste im oberen Feld kopiert, unten eingefügt und alle Umlaute geändert (und Großbuchstaben in Kleinbuchstaben und Leerzeichen in Bindestriche). Ein Klick auf Bearbeiten und das Problem ist behoben!

Wow, eine ganze Menge, oder? Auch ich trage mich schon seit längerem mit der Idee, ein neues Theme zu verwenden. Das hat mehrere Gründe. Es macht es mir einfach Spaß zu basteln, ein etwas helleres Theme ist vielleicht besser (einen Trend dazu meine ich zu erkennen) und ich kann noch einmal von vorne anfangen (im positiven Sinne). Ein indirekter Grund dafür ist das letzte WordPress-Update, das ich immer noch nicht getätigt habe, da einige Plugins wohl nicht mehr funktionieren werden. Mittlerweile scheinen die meisten Probleme (vor allem im Zusammenhang mit der neuen Tag-Funktionalität) ausgemerzt zu sein und ich möchte es wagen.

Zur Vorbereitung habe ich einen Testblog installiert, wo dann alles soweit angepasst wird, damit hier die Umstellung reibungslos ablaufen kann. Wie gesagt, es wird ein neues Theme geben und da ich den Sidebar Modules treu bleiben möchte, gibt es eigentlich nur ein Theme, das in Frage kommt.

Worüber ich mir noch nicht im Klaren bin, ist die Reihenfolge der Aktualisierung. Soll ich schon alles möglichst perfekt vorbereiten und dann mühsam übertragen oder mit einer funktionierende Basisversion starten und dann nach und nach anpassen? Und welche Seiten und Plugins soll ich “zurücklassen”, d.h. nicht mehr verwenden? Bzw. was fehlt hier? Vorschläge sind herzlich willkommen, ehrliche Kritik ist ausdrücklich gewünscht!

Wer keinen Unterschied außer den Bullet-Zeichen sehen kann: die Worte Vorteile und Nachteile erscheinen nur im Feed.

Wie habe ich das gemacht? Und warum? Nun, die im Stylesheet angegebenen Formatierungen bestimmen das Aussehen im Blog, während im Feed nur direkte Formatierungen Auswirkungen haben. Ansonsten bestimmt der Feedreader, wie eine Aufzählungsliste aussieht.

Im Blog haben nun die Plus- und Minuszeichen verdeutlicht, was Vor- und was Nachteil ist. Im Feed jedoch geht diese “Information” verloren. Also musste eine Möglichkeit gefunden werden, wie man trotzdem Vor- und Nachteile unterscheiden kann.

Hier kommen die Template Tags [siehe Kommentar von Frank] die Conditional Tags von WordPress ins Spiel und zwar die Abfrage is_feed().

Um diese Abfrage im Beitrag ausführen zu können, ist das Plugin Exec-PPH nötig. Anderenfalls würde die Anweisung als regulärer Text interpretiert und nicht als PHP-Code[1]

Nun aber zur Anweisung selber. Obige Ansicht des Feeds wurde mit folgenden zwei If-Abfragen erreicht. Am Anfang steht

<?php if(is_feed()) : ?>

<strong>Vorteile</strong>

<?php endif; ?>

und zwischen den beiden Listen steht

<?php if(is_feed()) : ?>

<strong>Nachteile</strong>

<?php endif; ?>

In diesem Fall hätte man sicherlich auch mit direkter Formatierung arbeiten können, aber ich wollte einmal das is_feed-Template Tag ausprobieren und es gibt Beispiele, wo es tatsächlich sinnvoll oder die einzige Möglichkeit ist, wie z.B. wenn man am Ende eines Beitrags die Aufforderung zum Abonnieren des Feeds einfügt. Der soll natürlich bei denjenigen, die den Feed lesen nicht mehr angezeigt werden. Das geht mit der Negierung

<?php if(!is_feed()) : ?>

<span>Hat dir dieser Beitrag gefallen? Dann abonniere meinen <a title="Beiträge als Feed" rel="alternate"
type="application/rss+xml" href="

<?php bloginfo('rss2_url'); ?>

" >RSS-Feed</a></span>

<?php endif; ?>

Wichtiger Hinweis: die spitze Klammer (>) nach href=" gehört da nicht hin. Aber hier musste ich sie einfügen, da sonst einiges durcheinander kommt und die Seite nicht richtig dargestellt wird.

Welche Anwendungsmöglichkeiten gibt es noch? Viel Spaß beim Ausprobieren!

1. In der neuesten Version 3.4 werden auch Text-Widgets unterstützt, eine Funktion, für die bisher entweder ein weiteres Plugin nötig war oder aber das Nutzen von Sidebar Modules statt Widgets.

Heute möchte ich ein wenig näher auf die Arbeit mit poEdit eingehen. Wer mal eben Plugins “auf die Schnelle” übersetzen bzw. lokalisieren möchte, muss einige Dinge beachten. Deshalb hier ein paar Tipps zur Vermeidung von typischen Stolperfallen. Und auch wenn es in der Überschrift “Plugins” heißt, gelten die meisten Dinge auch für die allgemeine WordPress-Sprachdatei. Ein kurzer Überblick, was es in diesem Beitrag zu lesen gibt:

• Nochmal zum Prinzip
• Überblick behalten: Katalogverwaltung
• Fehlersuche wenn es doch nicht funktioniert
  • 1. Plugin-Dateien für die Lokalisierung vorbereitet?
  • 2. poEdit richtig eingerichtet?
  • 2a. Pfadangaben richtig gesetzt?
  • 2b. Schlüsselwörter richtig angegeben?
  • 3. Plugin-Domain registriert und vorhanden?
  • 4. Formular- und Buttontexte
  • 5. Besonderheit Einzahl/Mehrzahl

Nochmal zum Prinzip

Wer jetzt nicht den langen Einführungsartikel lesen, sondern einfach nur Dateien bearbeiten möchte, dem sei kurz das Prinzip erklärt. Wichtig sind zwei Dateien:

• Die po-Datei (= Sprachdatei) ist eigentlich eine Textdatei in einem bestimmten Format (einfach mal mit einem Texteditor ansehen) und enthält die Original- und die übersetzten Zeichenketten. Dies ist die menschenlesbare und mit poEdit bearbeitbare Datei, aus der die von WordPress lesbare mo-Datei erstellt wird.
• Die mo-Datei wird von WordPress verarbeitet, d.h. dort wird nachgeschaut, ob eine Übersetzung vorliegt und dann an der entsprechenden Stelle eingefügt. Nur diese Datei muss auf dem Server vorhanden sein.

Die aktuelle deutsche Sprachdatei für die Grundinstallation von WordPress kann man auf der offiziellen Seite runterladen. Bei vielen Plugins ist schon eine po-Datei (oder pot-Datei) mitgeliefert. Manche bieten auch eine ganze Reihe verschiedener Übersetzungen. Die kann man als Ausgangspunkt für seine Übersetzung verwenden.

Überblick behalten: Katalogverwaltung

poEdit bietet die Möglichkeit, alle Kataloge auf einen Blick zu verwalten. Ruft man diese mit Datei > Katalogverwaltung auf, öffnet sich ein neues Fenster. Nun muss man ein neues Projekt anlegen mit dem ersten Button links (Tooltip: Erstelle neues Übersetzungsprojekt). Man vergibt einen Namen (z.B. wordpress) und erstellt einen Pfad. Ich habe den Ordner angegeben, in dem die WordPress-Installation und die Plugins zu finden sind. Nach Klick auf OK wird der Ordner (und alle Unterordner) durchsucht und alle gefundenen po-Dateien werden aufgelistet. Und auch zusätzliche Informationen wie Anzahl aller Zeichenketten, unübersetzte, unklare, ungültige Zeichenketten und Datum der letzten Änderung. Aufgrund dieser Informationen erhält jede Datei ein grünes, gelbes oder rotes Icon (grün: alles übersetzt, gelb: fast alles übersetzt, kaum unklare, rot: überwiegend unklare oder unübersetzte Zeichenketten). Siehe auch den Screenshot links (Klick für Vergrößerung).

Natürlich kann man auch eine andere Organisation vornehmen, andere Pfade angeben, mehrere Projekte anlegen – wie immer man es am liebsten mag. Ich habe diese Struktur gewählt, weil ich so alles auf einen Blick sehe und die einzelnen Sprachdateien von hier aus aufrufen kann. Es gibt die Option Öffne die Katalogverwaltung beim poEdit Start (zu finden unter Datei > Einstellungen), dann kann man die Katalogverwaltung als Ausgangspunkt für alle Bearbeitungen verwenden.

Hinweis zur Aktualisierung: Mit dem Button ganz rechts (Aktualisiere alle Kataloge des Projekts) werden alle Kataloge auf neue und veraltete zu übersetzende Zeichenketten untersucht. Bevor man dies ausführt, sollte man sicherstellen, dass alle Pfadangaben und Schlüsselwörter richtig gesetzt sind (s.u.), denn sonst gehen evtl. Übersetzungen verloren und das ist ärgerlich.

Fehlersuche wenn es doch nicht funktioniert

Du weißt eigentlich, wie das Prinzip der Lokalisierung funktioniert und du glaubst, dass alle Voraussetzungen erfüllt sind und trotzdem funktioniert es nicht? Hier ein paar Vorschläge, woran es liegen könnte (Troubleshooting):

1. Plugin-Dateien für die Lokalisierung vorbereitet?

In den php-Dateien des Plugins müssen die Stellen, die übersetzt werden sollen, markiert sein (siehe die Abschnitte Grundprinzip der Lokalisierung und Besonderheit bei Plugins im Einführungsartikel). Sollte das nicht der Fall sein, muss das nachgeholt werden.

Da dies oft mit viel Arbeit verbunden ist, kann man anschließend dem Plugin-Autor einen Kommentar hinterlassen oder eine E-Mail schicken, mit dem Hinweis, dass man sein Plugin für die Lokalisierung vorbereitet hat (und anbieten, die geänderte Datei zu schicken). Viele freuen sich darüber, denn dann müssen sie sich nicht mehr die Arbeit machen und sie können einen zusätzlichen Service anbieten.

2. poEdit richtig eingerichtet?

Damit poEdit die richtigen Dateien nach zu übersetzenden Stellen durchsucht (*.php in diesem Fall), muss das Programm dafür entsprechend eingerichtet sein. Dies gilt für die allgemeinen Einstellungen unter Datei > Einstellungen als auch für jeden einzelnen Katalog unter Katalog > Optionen.

2a. Pfadangaben richtig gesetzt?

Wenn man eine vorhandene Sprachdatei bearbeitet, ist es unwahrscheinlich, dass die gleichen Pfadangaben wie beim Original-Übersetzer gelten. Ich finde es am bequemsten und unkompliziertesten, wenn die WP-Sprachdatei im Verzeichnis über der Installation liegt und die Plugin-Sprachdatei im Verzeichnis des zugehörigen Plugins (oder in einem Unterordner languages) liegt. Auch wenn das Plugin nur aus einer einzelnen Datei besteht, sollte für die Übersetzung ein eigener Pluginordner (z.B. gleicher Name wie das Plugin) angelegt werden. Dann reicht als Basispfad ein einfacher Punkt (bzw. ../ im Falle des Unterordners) und es reicht ein Pfad aus einem Punkt (der Eintrag MUSS da sein; fehlt er, kann dies die Fehlerursache sein). Falls Unterordner existieren, gibt es für jeden einen zusätzlichen Pfad.

Nachfolgend zwei Screenshots der beiden Einstellungen, die unter Katalog > Optionen zu finden sind (Klick für Vergrößerung). Links sind die Pfade für die WP-Installation (im Verzeichnis wordpress = Basispfad; der wp-plugins-Ordner wird hier NICHT aufgeführt) und rechts die beiden “Punkt”-Pfade für ein Plugin.

2b. Schlüsselwörter richtig angegeben?

Zusätzlich müssen die richtigen Schlüsselwörter angegeben sein (__ und _e), damit poEdit die Stellen findet, die in den Plugin-Dateien entsprechend markiert sind. Die Einstellungen dazu findet man in obigem Dialog im nächsten Tab.

3. Plugin-Domain registriert und vorhanden?

Bei Plugins gibt es eine Besonderheit, die sog. Domäne, die sicherstellt, dass die Sprachdatei nur für das Plugin gilt[2]. Das bedeutet, dass im Plugin nicht nur die Schlüsselwörter vorhanden sind, sondern dass auch der zweite Parameter in der Schlüsselwortfunktion angegeben sein muss. Ansonsten “weiß” WordPress ja gar nicht, dass es in einer anderen Sprachdatei suchen muss.

4. Formular- und Buttontexte

Ich habe die Erfahrung gemacht, dass manche Textstellen (speziell in Formularen oder Beschriftungen von Buttons) zwar von poEdit erkannt werden, aber nicht von WordPress übersetzt werden[3]. Woran das liegt, kann ich nicht sagen. In diesem Fall muss man die Übersetzung direkt in der Plugin-Datei vornehmen. Änderungen vermerken, damit sie bei einem Plugin-Update wieder ausgeführt werden können!

5. Besonderheit Einzahl/Mehrzahl

Der Plural im Englischen wird durch einfaches Anhängen von “s” gebildet. Es gibt nur wenige Ausnahmen, wo auch der Wortstamm verändert wird (1 wife, 2 wives), doch im Deutschen wird erstens der Plural auf verschiedene Weisen gebildet und zweitens kommt es häufig vor, dass der Wortstamm verändert wird (1 Vater, 2 Väter).

Da es im Englischen so einfach ist, wird oft eine Abfrage gemacht, ob die Anzahl ungleich eins ist (!= 1) und in diesem Fall ein “s” angehängt. Im Deutschen dagegen heißt es dann z.B. “4 Buchs gelesen” und das ist ärgerlich. In diesem Fall bleibt einem nichts anderes übrig, als ein wenig die Plugin-Datei zu bearbeiten (wieder gilt: Änderungen vermerken, damit sie bei einem Plugin-Update wieder ausgeführt werden können!)

Beispiel Now-Reading-Plugin

In der Datei template-functions in den Funktionen books_read_since und total_books ändere

echo "$num book".($num != 1 ? 's' : '');

zu

echo $num . ($num != 1 ? __(' books', NRTD) : __(' book', NRTD));

und in der Funktion average_books ändere

printf(__('an average of %s book%s each %s', NRTD), $average, 
($average != 1 ? 's' : ''), $time_period);

zu

printf(__('an average of %s %s each %s', NRTD), $average, 
($average != 1 ? __('books', NRTD) : __('book', NRTD)), $time_period);

1. Herzlichen Dank dafür
2. Die WordPress-weite Sprachdatei (meist de_DE.po) liegt im Ordner wp-includes\languages und hat nichts mit den Plugin-Sprachdateien zu tun
3. Es kann auch sein, dass das Problem mittlerweile behoben ist, denn es ist mir in letzter Zeit nicht mehr aufgefallen

Dieser Beitrag richtet sich eher an WordPress-Nutzer, die sich praktisch noch gar nicht mit der Materie beschäftigt haben und wissen möchten, was es damit auf sich hat. Aber auch für Fortgeschrittene mag sich der eine oder andere Tipp hier verbergen. Das meiste stammt aus einem älteren Beitrag, der mir mittlerweile zu kompliziert erscheint und an dem ich mich deshalb noch einmal versuchen möchte.

Der Beitrag ist recht lang und deshalb in mehrere Abschnitte unterteilt. Wer sich schon auskennt, kann sich an der Zusammenfassung versuchen oder einzelne Abschnitte überspringen.

1. Voraussetzungen
2. Grundprinzip der Lokalisierung
3. Besonderheit bei Plugins
4. Einrichten von poEdit
5. Erstellen/Bearbeiten einer Sprachdatei
6. Bedienung von poEdit
7. Zusammenfassung

Voraussetzungen

Folgende Voraussetzungen werden benötigt für die eigentliche Übersetzungsarbeit und das anschließende ungefährliche Testen. Wer live auf seinem Blog testen möchte, überspringt den ersten Punkt.

1. ENTWEDER eine lokale Installation (Anleitung im Mediengestalter-Blog) ODER eine Testinstallation auf einem entfernten Server parallel zur bestehenden. Vorgehen für die zweite Variante:[1]
   • Kopie des WordPress-Ordners (z.B. wordpress-test) auf dem Server erstellen,
   • in wp-config die Zeile

     $table_prefix  = 'wp_';

     ändern zu

     $table_prefix  = 'wp_test_';

   • WordPress installieren,
   • Sichtbarkeit des Blogs deaktivieren (in Einstellungen » Privatshäre),
   • für beide Varianten gilt: URL anpassen (Anleitung bei frische-zitronen.de)
2. Die Software poEdit (erhältlich für Windows und Linux) zum Editieren der Sprachdatei.
3. Auf dem lokalen Rechner ein Ordner (z.B. wp) mit zwei Unterordnern zur getrennten Lokalisierung von Theme und Plugins:
   • wordpress-test, der der eigentlichen WordPress-Installation entspricht, aber OHNE den Ordner wp-content/plugins und nur das gewünschte Theme im Ordner wp-content/themes,
   • wordpress-test-plugins für die zusätzlichen Plugins,
   • für jedes Plugin einen eigenen Ordner (auch wenn es nur eine Datei ist – der Ordner heißt dann wie das Plugin).
4. Prüfen: In der Datei wp-config steht die Zeile

   define ('WPLANG', 'de_DE');

   und im Ordner wp-includes/languages gibt es die Datei de_DE.mo.[2] Der Dateiname kann auch anders lauten, er sollte nur mit der in WPLANG definierten Variable übereinstimmen.

Grundprinzip der Lokalisierung

← zum vorherigen Abschnitt – ↑ Inhaltsverzeichnis – → zum nächsten Abschnitt

Laut WordPress-Codex (Localizing WordPress) ist dies ein zweistufiger Prozess. Im ersten Schritt ist der Entwickler gefragt, der im Quelltext die Möglichkeiten bereitstellt, damit später sein Theme bzw. Plugin übersetzt werden kann. Und im zweiten Schritt erfolgt dann die tatsächliche Übersetzung (hier per poEdit).

Das Ganze basiert auf dem GNU gettext Framework, dem Standard für modulare Übersetzung. Laut der deutschen WordPress-Doku (Bearbeitung der Sprachdatei), sind für gettext zwei Dateien wichtig. Der Ablauf ist folgendermaßen:

1. Gettext liest Zeichenfolgen im Quelltext ein, die in der PO-Datei gespeichert werden.
2. Die Übersetzung erfolgt durch Bearbeiten der PO-Datei.
3. Die übersetzten Zeichenfolgen werden in der MO-Datei gespeichert.
4. Beim Aufruf einer Seite wird die MO-Datei von WordPress ausgelesen und es wird die Übersetzung angezeigt.

Die einzelnen Zeichenfolgen müssen im Quelltext markiert werden für die Übersetzung. Dies erfolgt über zwei PHP-Funktionen, __() und _e(). Zur Erklärung heißt es (meine Übersetzung des Originaltextes):

__($message)

(zwei Unterstriche) Durchsucht das Lokalisierungsmodul nach der Übersetzung von $message und übergibt die Übersetzung als Rückgabewert (return statement). Wenn keine Übersetzung für $message gefunden wird, wird einfach $message zurückgegeben.

_e($message)

(Unterstrich und e) Durchsucht das Lokalisierungsmodul nach $message und übergibt die Übersetzung als Ausgabewert (echo statement). Wenn keine Übersetzung für $message gefunden wird, wird einfach $message ausgegeben.

Die Markierungen dienen als Schlüsselwörter beim Einlesen. In den PHP-Dateien sollte dann also nicht

echo 'gib mich aus'

stehen, sondern

_e('gib mich aus');

bzw. nicht

'gib mich zurück'

sondern

__('gib mich zurück')

Gut: Das Theme bzw. Plugin ist schon auf diese Weise vorbereitet, d.h. gettextet. Man erspart sich die Fleißarbeit, alle Zeichenfolgen zu ersetzen.

Schlecht: Ist das nicht der Fall, muss man die Dateien selber gettexten und an den entsprechenden Stellen __() und _e() einfügen. Dabei die Anführungszeichen nicht vergessen! Man kann sowohl einfache (‘) als auch doppelte (“) verwenden, es sollten nur die gleichen öffnenden und schließenden sein.

Besonderheit bei Plugins

← zum vorherigen Abschnitt – ↑ Inhaltsverzeichnis – → zum nächsten Abschnitt

Hier gibt es einen zusätzlichen Parameter, die sog. Domäne, also lautet die Funktion

__($message, $domain)

Damit kann für jedes Plugin (bzw. jede Domäne) eine eigene Sprachdatei erstellt werden. Häufig ist es so, dass die Autoren der Plugins das schon getan haben. Dann findet sich im Quelltext eine Zeile, die etwa so aussehen sollte:

load_plugin_textdomain('plugin-name');

oder

load_plugin_textdomain('plugin-name','wp-content/plugins/pfad/zur/sprachdatei');

Die Domäne impliziert, dass die Übersetzungen in der Sprachdatei wp-content/plugins/$domain-de_DE.mo statt in wp-includes/languages/de_DE.mo zu suchen sind. Der zweite Parameter kann genutzt werden, um einen speziellen Ordner anzugeben. Nachzulesen ist das Ganze im Abschnitt Localizing Plugins.

Vorteil: Die eigentliche Installation und die Zusatzfunktionen werden getrennt übersetzt. Die Haupt-Sprachdatei wird nicht unnötig aufgebläht.

Nachteil: Man muss für jedes Plugin (bzw. jede Domäne) eine eigene Sprachdatei erstellen und verwalten.

Möchte man Ordnung halten und alle Plugin-Sprachdateien in einem bestimmten Verzeichnis speichern, z.B. wp-content/plugins/languages, muss dieses Verzeichnis bei jedem Plugin in der obigen Funktion eingetragen werden.

Achtung: Angenommen, man möchte keine getrennte Lokalisierung der Plugins vornehmen, sondern die Übersetzungen in der Hauptsprachdatei speichern. Dann muss der zusätzliche Parameter entfernt werden, wenn der Plugin-Autor diesen eingefügt hat. Ansonsten ignoriert WordPress diese Zeichenketten bei der Übersetzung, weil nach der Domänen-Sprachdatei gesucht wird.

Einrichten von poEdit

← zum vorherigen Abschnitt – ↑ Inhaltsverzeichnis – → zum nächsten Abschnitt

Im Beitrag Erstellen der Sprachdatei mit poEdit ist vor allem der Abschnitt Konfiguration von poEdit – Allgemeine Programmeinstellungen wichtig. Dort heißt es

Deshalb starten wir poEdit und rufen die Programmeinstellungen (Datei > Einstellungen) auf. Auf der ersten Registerkarte trägst du jetzt deinen Vor- und Nachnamen ein. Auf der Editor-Registerkarte entfernst du das Häkchen vor der Option CR/LF-Konvertierung > Behalte Format existierender Kategorie bei. Dann wechselst du auf die Karteikarte Parser und klickst auf Neu.
In den Feldern trägst du jetzt von oben nach unten ein:

1. PHP
2. *.php
3. xgettext –output=%o %K –language=php %F
4. –keyword=%k
5. %f

Das letzte Feld bleibt frei. Jetzt klickst du zweimal auf OK. Damit ist poEdit fertig für das Parsen von PHP-Dateien.

Neben diesen allgemeinen Einstellungen gibt es noch Einstellungen für die Katalogverwaltung. Die folgenden weichen von den “offiziellen” von WordPress ab, weil hier in einer anderen Ordnerstruktur gearbeitet wird.

1. Aufrufen der Katalogverwaltung mit Datei > Katalogverwaltung
2. Neues Übersetzungsprojekt anlegen durch Klick auf den ersten Button ganz links (Tooltip: Erstelle neues Übersetzungsprojekt)
3. Name kann beliebig gewählt werden
4. wichtigste Einstellung: absoluter Pfad zum Projekt (Der schon vorgegebene Pfad kann durch Klick auf den Bearbeiten-Button (a|e) angepasst werden. Ist kein Pfad vorgegeben, durch Klick auf den Neu-Button einen neuen erstellen. Hier den Pfad zum oben angelegten Ordner (wp) angeben.)
5. Fertigstellen des Übersetzungsprojektes durch Klick auf OK

Damit sind alle allgemeingültigen Einstellungen abgeschlossen. Die folgenden Einstellungen sind katalogspezifisch.

Erstellen/Bearbeiten einer Sprachdatei

← zum vorherigen Abschnitt – ↑ Inhaltsverzeichnis – → zum nächsten Abschnitt

Zunächst gehe ich von dem Fall aus, dass bereits eine Sprachdatei existiert, die aktualisiert werden soll. Für die deutsche Version von WordPress, kann man sich die aktuelle PO-Datei herunterladen. Diese ist ein guter Ausgangspunkt für das Übersetzen. poEdit bietet nämlich einen sogenannten Übersetzungsspeicher (Translation Memory, abgekürzt tm), der aufgrund ähnlicher Formulierungen die wahrscheinlichste Übersetzung rät.

Die Sprachdatei de_DE.po im Verzeichnis wp speichern (d.h. in dem Ordner ÜBER der WordPress-Installation) und mit poEdit öffnen. Damit poEdit die richtigen Textstellen zum Übersetzen findet, müssen einige Einstellungen vorgenommen werden.

1. Katalogoptionen öffnen (Katalog > Optionen),
2. in der Registerkarte Projektinfo sollte schon alles Wichtige eingetragen sein, vor allem sollte UTF-8 als Zeichensatz gewählt sein,
3. in der Registerkarte Pfade als Basispfad ./wordpress-test (Punkt Slash und der oben gewählte Ordnername für die WordPress-Installation) eingeben,
4. zusätzliche folgende Pfade durch Klick auf den Neu-Button eintragen:
   • . [das ist ein Punkt]
   • wp-includes
   • wp-admin
   • wp-content\themes [hier Backslash verwenden]
5. in der Registerkarte Schlüsselwörter zwei neue Einträge anlegen mit __ und _e (den oben erwähnten Schlüsselwörtern),
6. Klick auf OK.

Der Klick auf Ok sollte ein Durchsuchen des Quelltextes zur Folge haben. Wenn Fehler kommen, kann es evtl. daran liegen, dass man sich beim Eingeben der Pfade vertan hat. Dann Rückgängig wählen und erneut die Daten eingeben. Das Ergebnis sollte ungefähr so aussehen, wie das Bild rechts (Anklicken für volle Größe). Erst einmal SPEICHERN (zweiter Button von links).

Möchte man eine neue Sprachdatei erstellen, öffnet man poEdit und wählt Datei > Neuer Katalog. Es erscheint wieder der Dialog Katalogoptionen, nur diesmal völlig leer. Die Einstellungen für die Registerkarten Pfade und Schlüsselwörter sind die gleichen wie oben. In der Registerkarte Projektinfo trägt man in den ersten drei Feldern die entsprechenden Infos ein. In die nächsten drei Felder sollten german, germany, utf-8 eingetragen werden. Der Rest bleibt leer. Nach klick auf OK wird man aufgefordert die Datei zu speichern. Als Speicherort den wp-Ordner wählen und als Dateiname die Variable bei WPLANG, z.B. de_DE.po.

Für eine Plugin-Sprachdatei gibt es zwei Abweichungen. Bei den Pfaden besteht der Basispfad und der Pfad zum Plugin im einfachsten Fall jeweils aus einem Punkt (= gleiches Verzeichnis wie die Sprachdatei). Gespeichert wird die Datei im Ordner des Plugins unter dem Namen $domain-de_DE.po, wobei $domain meist der Name des Plugins ist (siehe oben genannte Besonderheit).

Gibt es bereits eine Sprachdatei, die sich in einem Unterordner des Plugins (z.B. languages) befindet, wird der Basispfad zu ../ (= eine Ebene über der Sprachdatei). Enthält der Plugin-Ordner Unterordner mit zu übersetzenden Dateien, werden diese als zusätzliche Pfade eingetragen.

Bedienung von poEdit

← zum vorherigen Abschnitt – ↑ Inhaltsverzeichnis – → zum nächsten Abschnitt

Zur Bedienung von poEdit wird man bei WordPress auf die Programm-eigene Hilfe verwiesen. Die ist jedoch lückenhaft, teilweise veraltet, schwer verständlich und bezieht sich nur allgemein auf gettext-Techniken. Deshalb hier eine kurze Einführung.

Die bunten Zeilen bekommt man, wenn im Ansicht-Menü die Option “Gefärbte Übersetzungsliste” angekreuzt ist. Die Farben haben folgende Bedeutung:

• hellblau = unübersetzt
• gelb/beige = unklar
• weiß = übersetzt/alles ok

Am Anfang jeder Zeile können verschiedene Icons auftauchen. Die Beschreibung ist in der Hilfe nicht auf dem neuesten Stand. Hat man in der aktuellen Sitzung eine Zeile verändert, sieht man einen gelben Stern. Die Hilfe gibt an, dass es sich um einen grünen Punkt handeln soll. Wurde ein Eintrag von der tm übersetzt, so sieht man ein Computer-Icon. Besitzt ein Eintrag einen Kommentar, so soll ein Bleistift-Icon erscheinen. Tatsächlich handelt es sich aber um eine Sprechblase.

In der Statuszeile unten stehen die Anzahlen der Zeichenketten (gesamt, unklar, ungültig, unübersetzt). So behält man den Überblick darüber, was noch gemacht werden muss. Alle unklaren Übersetzungen werden von WordPress bei der Anzeige ignoriert, d.h. sie werden so wie nicht übersetzte Zeichenketten behandelt.

Ein schnelles Durcharbeiten ist möglich, da man mit Tab und den Cursor-Tasten bequem durch die Zeichenketten navigieren kann. Es gibt die Short-Cuts Alt-U zum Bestätigen einer unklaren Übersetzung und Alt-C zum Kopieren des Originals in die Übersetzung.

Achtung ist geboten, wenn Platzhalter im Originaltext vorkommen. Diese sind mit einem % gekennzeichnet. Die Anzahlen sollten beim Original und in der Übersetzung übereinstimmen, sonst wird die Übersetzung ungültig.[3] Wenn mehrere Platzhalter vorkommen, sollten diese unterschiedliche Bezeichnungen haben. Oft werden aber alle Platzhalter in einer Zeichenkette mit %s bezeichnet. Das ist ok, solange im Original und der Übersetzung die gleiche Reihenfolge eingehalten wird. Leider ist das aber beim Übersetzen vom Englischen ins Deutsche nicht in allen Fällen möglich. Oder man wählt absichtlich eine Formulierung, die eine andere Reihenfolge der Platzhalter erfordert.

In diesem Fall muss der Quelltext bearbeitet werden. Das geht aber nicht direkt in poEdit, sondern nur in einem externen Editor. Wo die Zeichenkette auftaucht, mit Dateiname und Zeilennummer, erfährt man durch einen Rechtsklick auf die Zeichenkette (siehe Screenshot). Klick auf den Eintrag im Kontextmenü öffnet den Editor an dieser Textstelle[4]. Nun kann man die Platzhalter durchnummerieren mit %1$s, %2$s, .... Datei speichern nicht vergessen.

Nach jeder Änderung der Originaltexte oder Hinzufügen von Dateien, muss der Katalog aktualisiert werden, d.h mit den Quellen synchronisiert werden. Dazu einfach den Update-Button klicken (dritter Button von links). Nach dem Aktualisieren und Speichern werden die Icons und Farben angepasst.

Das Kontextmenü gibt außerdem Informationen über die Übersetzungsvorschläge an (wenn es denn welche gibt) und man kann sich den besten aussuchen oder selber eine bessere Übersetzung eingeben.

Am Ende der Bearbeitung den Katalog speichern. Damit wird automatisch auch die MO-Datei erstellt. Wenn nicht, unter Datei > Einstellungen, Registerkarte Editor ganz oben diese Option ankreuzen.

Zusammenfassung

Um immer wieder seine WordPress-Installation bzw. neue Plugins zu übersetzen geht man folgendermaßen vor.

1. Synchronisation der Test-WordPress-Installation mit dem wp-Ordner, mit dem Unterschied, dass die Plugins separat abgespeichert werden (Was ist damit gemeint?),
2. bei einem neuen Theme oder Plugin:
   1. Textstellen auf gettext-Zustand prüfen, d.h. ob überhaupt gettextet, ob mit __($message) oder mit __($message, $domain) (letzteres gilt nur für Plugins),
   2. wenn nötig, Textstellen anpassen (Was ist damit gemeint?),
   3. bei Plugins, Anpassen an individuelle Vorzüge (Was ist damit gemeint?),
   4. geänderte Dateien zur Test-WordPress-Installation kopieren.
3. Öffnen/Erstellen der PO-Datei in poEdit (Wie geht das?),
4. Ändern, Aktualisieren und Speichern der PO-Datei bis zum gewünschten Ergebnis (Wie geht das?),
5. Kopieren der erstellen MO-Datei in das entsprechende Verzeichnis der Test-WordPress-Installation (wp-includes/languages für die Haupt-Sprachdatei, und wp-content/plugins bzw. wp-content/plugins/languages,
6. Aufruf der Seite, auf der der übersetzte Text auftauchen soll, um zu prüfen, dass man die richtigen Stelle erwischt hat,
7. gegebenenfalls diese Schritte wiederholen, bis das gewünschte Ergebnis erreicht ist,
8. Wenn dies dann endlich der Fall ist, kann man die Dateien endlich zur “realen” WordPress-Installation kopieren (d.h. alle neuen und geänderten Dateien – bloß keine vergessen!)

Das war es auch schon. Verbesserungsvorschläge, Anregungen, Kritik oder sonstige Anmerkungen?

Nachtrag: verständliche und Schritt-für-Schritt-Anleitung bei Texto.de

1. Eine parallele Installation ist weniger aufwändig und man testet auf dem Server, auf dem die eigentliche WP-Installation ist. Die benötigten Zugriffsrechte auf die entfernten Daten per FTP sollten gegeben sein.
2. Dies sollte der Fall sein, wenn man die DE-Version von WordPress installiert hat. Ansonsten muss man nachträglich die deutsche Sprachdatei installieren.
3. Wenn es ungültige Fehlerketten gibt, lässt sich der Katalog manchmal nicht mehr speichern. Es gibt dann eine Fehlermeldung mit Details. Abhilfe schafft die Bearbeitung der PO-Datei in einem Texteditor. Die Zeile(n) suchen, die in der Fehlermeldung angegeben ist/sind und alles zwischen den Anführungszeichen bei msgstr löschen.
4. Sollte das nicht funktionieren, stimmen die Einstellungen zum externen Editor nicht. Diese findet man unter Datei > Einstellungen, Registerkarte Editor. Im Feld Editor EXE-Datei sollte z.B. notepad %f stehen. Das Ankreuzfeld darunter sollte ein Häkchen haben. Funktionert es immer noch nicht, kann man die Datei auch manuell im Editor öffnen.

Parser error ———-
Line:2
Reason:Verweis auf eine nicht definierte Entität ‘ouml’.

habe ich beschlossen, dem auf den Grund zu gehen. Es kann ja nicht angehen, dass es mit einigen Feedreadern funktioniert und mit anderen nicht. Diejenigen, mit denen ich meinen Feed überprüft habe (Google Reader, Opera, RSSOwl) haben nicht gemeckert. Doch der Feedreader Feedreader gab diesen Fehler aus (Benedikt benutzt den und brachte mich darauf).

Schnell konnte ich den Fehler auf Umlaute in den Kategorienamen zurückführen (ouml steht für o Umlaut, d.h. ö). Das Seltsame an der Geschichte war allerdings, dass nicht alle Kategorien mit Umlauten dieses Verhalten verursachten.

Was unterschied also die Kategorien? Ich habe mir die Tabelle wp_categories mit phpMyAdmin angesehen (gibt es übrigens auch als WordPress-Plugin, um direkt im Admin-Bereich auf die Tabelle zugreifen zu können) und fand schnell den Fehler:

Die Kategorien, die Probleme bereiten, waren tatsächlich mit den ASCII-Zeichen für die Umlaute kodiert (ö mit ö usw.). Bei den problemlosen Kategorien standen die kryptischen Zeichen (siehe Bild). Also habe ich alle Umlaute angepasst und hoffe nun, dass Beiträge, die unter diesen Kategorien abgelegt wurden, im Feedreader dargestellt werden.

Wenn immer noch Probleme auftreten (auch bei anderen Feedreadern oder Kategorien), bitte ich um kurze Rückmeldung.

Noch ein Hinweis, warum es überhaupt dazu kommen konnte. Vor kurzem habe ich den Provider gewechselt und da gab es kurzfristig Probleme mit den Umlauten in den Kategorien und bei einigen habe ich versucht, das per Hand zu lösen (mit ASCII-Zeichen), bevor ich eine allgemeine Lösung gefunden habe. Doch genau diese Änderungen verursachen jetzt die unerwünschten Fehler…

Da langsam der ganze Schnickschnack auf meinem Blog die Ladezeiten ungünstig zu erhöhen drohte bzw. in unangenehme Höhen trieb, habe ich beschlossen auszumisten. Besonders auf der Startseite. Geholfen hat dabei die hilfreiche Firefox-Erweiterung Firebug, wo man (u.a.) sehen kann, welche Elemente wieviel Ladezeit benötigen.

Zuerst mussten einige Banner und Hinweise auf verzichtbare Aktionen weichen (verzichtbar im Sinne von “Der Besucher denkt sich ‘Ist ja toll, dass die das unterstützt, aber das kannte ich schon’.”). Namentlich waren das Deine Stimme gegen Armut, Stoppt die Vorratsdatenspeicherung, Too Cool for IE und GSDS (das Finale kommt zwar noch, aber darüber blogge ich extra).

Dann wurde meine Button-Farm reduziert sowohl die Bildgröße als auch die Bildanzahl. Es sind z.B. die Aktionen rausgeflogen, bei denen ich mich nicht persönlich gemeldet habe bzw. über die ich nicht berichtet habe.

Eine große Geschwindigkeitsbremse ist die Anzeige der Feed-Abonnenten von Feedburner. Eigentlich möchte ich lieber das Plugin WP-FeedStats verwenden, aber da wurden Sicherheitslücken entdeckt, die noch nicht geschlossen wurden. Zusätzlich ist da die Angabe der Abonnentenzahl viel genauer und schwankt lange nicht so stark. Ich hoffe also auf eine schnelle Behebung der Mängel!

Des Weiteren habe ich versucht, die Anzahl der Anfragen (Queries) zu reduzieren. Einen Anfang habe ich mit der Aktivierung des WorPress-internen Cache gemacht. Den Tipp gabs beim Software Guide. Dort wurde auch in einem älteren Artikel auf die von Plugins erzeugten Queries eingegangen. Von dort kam ich zu einem Artikel von Robert Basic, der erklärt, wie man rausbekommt, welche Plugins für wieviele Queries verantwortlich sind.

Sehr passend fand ich das Beispiel, an dem diese Untersuchtung vorgenommen wurde: Anzeige der letzten Kommentare. Das Plugin, das ich bisher verwendet habe (Recent Comments von Rob Marsh) funktioniert seit meinem Providerwechsel nicht mehr. Schade eigentlich, weil der Autor gleich das Plugin Output Cache zur schnelleren Anzeige mitliefert, welches seine Plugins verwenden. Also habe ich zu dem im Basic-Beitrag beschriebenen Plugin Get Recent Comments gewechselt. Das läuft bisher wunderbar und das Aussehen kann zudem sehr gut angepasst werden. Ein paar mehr Queries werden allerdings generiert. Aber ich finde, dass die Anzeige der letzten Kommentare eine wichtige Informationsquelle sind, die ich nicht weglassen möchte.

Wo ich schon bei den Plugins war, habe ich da mal geschaut, welche eigentlich überflüssig sind. Besonders die “Media”-Informationen (Anzeige der meistgespielten Alben, Bücher- und Filmliste) sind Ressourcen-fressend. Interessiert sich jemand dafür? Kann ich die weglassen? Auf eine eigene Seite auslagern?

Eine weitere Sparte von Ladezeiten-erhöhenden Plugins sind Statistik-Sammler. Einige externe Dienste hatte ich neulich schon aussortiert. Aber bei den Plugins bin ich mir noch nicht so schlüssig. Wir werden sehen, ob ich mich noch durchringen kann. Oder gibt es bei jemandem deutliche Einbußen, die sich auf ein Plugin zurückführen lassen?

Zum Abschluss noch ein zwiespältiges Thema: Werbung. Verhasst und geliebt, geldbringend und nervig. Ich habe mir mit dem Plugin Who Sees Ads? beholfen. Damit sollen die Anzeigen nur sichtbar sein, wenn jemand von einer Suchmaschine kommt und/oder die Beiträge älter als 30 Tage sind. Regelmäßige Besucher (jetztige Definition: zwei Beiträge in den letzten zehn Tagen gelesen) sehen keine Werbung. Funktioniert das auch? Bzw. sind die Einstellungen so ok?

Zum Abschluss noch die passende Umfrage (es können mehrere Antworten gegeben werden):Die Umfrage ist beendet und außerdem wurde das zugehörige Plugin wieder deinstalliert, deshalb hier ein Screenshot des Ergebnisses:

Ausführlichere Antworten bitte in die Kommentare….

Genau hier verzweifle ich gerade. Alle Vorraussetzungen sind erfüllt und bis gestern war auch noch alles auf deutsch und jetzt nicht mehr. GRRRR. WARUM?!?!

FEHLER GEFUNDEN!!! Es liegt an PHP5! Bei meinem neuen Provider kann ich einstellen, welche PHP-Version ich möchte. Als ich das gerade auf PHP4 zurückgestellt habe, ging es wieder.

Neues Dilemma: Deutsch und altes PHP oder englisch und neues PHP!

Die Idee ist toll, doch leider gibt es einen kleinen Nachteil: die Seite validiert nicht[1].

Ich habe mir die Mühe gemacht, die Datei counterize.php standardkonform umzuändern. Das wird natürlich bei jedem Update wieder nötig und ist etwas ärgerlich. Der Autor des Plugins hat mich nun gebeten, meine geänderte Datei hier anzubieten, damit auch andere, denen ein valider Code wichtig ist, sich nicht die Mühe machen müssen.

Die Datei gibt es in zwei Versionen:

• Version 1, wo alle “alten” Html-Elemente auf den neuesten Stand gebracht wurden, damit die Seite auch XHTML 1.1 valide ist.
• Version 2, wo zusätzlich einige eigentlich falsche Tags eingefügt sind, die aber nötig sind, weil WordPress beim Speichern einer Seite automatisch Tags hinzufügt.

PS: Diesen Beitrag hatte ich gestern schon einmal veröffentlicht, aber der ist beim Providerwechsel verschütt gegangen. Genauer gesagt, ich hatte das Datenbank-Backup VOR dem Verfassen des Beitrags angelegt….

1. Warum ist das wichtig? Bei der Checkliste für Webstandards heißt es eine den Webstandards entsprechende Seite sollte im Idealfall schlank, aufgeräumt, CSS-basierend, zugänglich, nutzer- und suchmaschinenfreundlich gestaltet sein. und Valider Coder wird schneller und besser gerendert als invalider Code mit Fehlern. Browser werden standardkonformer und valider Code bekommt einen immer größeren Stellenwert.

if(function_exists('plugin_funktion') : plugin_funktion(); endif;

Aber das ging natürlich völlig schief. Erst verabschiedete sich langsam das SBM-Plugin, was sich dadurch bemerkbar machte, dass ich keine Änderungen mehr vornehmen konnte. Das rief unangenehme Erinnerungen wach. Und irgendwann waren dann auch alle Sidebar-Elemente verschwunden und ich musste wieder von vorne anfangen. Bzw. mühsam Modul für Modul aus dem Backup wiederherstellen. GRRRR. Aber irgendwann war wieder Schluss! Keine Änderungen mehr möglich. Außerdem traten im Admin-Bereich weitere Unregelmäßigkeiten auf, die ich mir nicht erklären konnte. Das war gestern nachmittag und ich hab dann irgendwann frustriert aufgegeben.

Heute morgen hatte ich plötzlich die Eingebung, dass es sich evtl. um das gestern neu installierte Plugin handeln könnte. BINGO! Nach der Deaktivierung ging alles wieder. Leider brauche ich das Plugin. Heißt das jetzt in Zukunft, dass ich für jede Änderung an den Modulen solange das fragliche Plugin deaktivieren muss? Blöd!

Tja, geschafft habe ich sozusagen nix, denn die Maintenance-Aktion ist natürlich noch lange nicht abgeschlossen und den Artikel habe ich nur grob zusammengeschustert. Nicht mal den GSDS-Trostpreis (Glühweinjunkies-Tasse) habe ich gewonnen, schnief.

Fürs erste habe ich genug vom Internet. Aufheitern könnte mich die Aussicht, dass zu Hause noch die zweite Staffel von Life on Mars[Amazon-Partner-Link] auf mich wartet. Leider sind diesmal keine Audiokommentare dabei. Kleiner Tipp am Rande: Die DVD-Box ist bei Amazon UK[Amazon-Partner-Link] inkl. Versand für knapp 45 Euro zu haben.

So, ich werd dann mal und noch ein schönes Restwochenende und einen erholsamen Wochenstart!!!

Ich habe es kurz ausprobiert und es funktioniert tatsächlich. Leider, leider geht die Umstellung nicht so schnell, wie ich das wohl will. Das liegt daran, dass ich die Datenbank bei meinem Versuch, das SBM-Plugin doch zum Laufen zu bringen wohl etwas durcheinander gebracht habe. Ich musste also alle Spuren löschen und nun dementsprechend alle Module neu erstellen. Bzw. mühsam alles von den Widgets kopieren. Das ist ein wenig mehr Aufwand, den ich aber gerne auf mich nehme, damit ich wieder die völlige Modul-Freiheit erleben darf. Hach, wie schön.

Wer mich jetzt für völlig bekloppt hält, hat die Freiheit noch nicht gekostet. In obigem Beitrag hatte ich einige Vorzüge der Module versucht aufzuzeigen. Wer noch nicht überzeugt ist, sollte das hurtig (in einer ruhigen Minute) mal ausprobieren, es lohnt sich wirklich. Und jetzt geht es auch wieder in der aktuellen WP-Version.

Wie gesagt, bei mir dauert das Zurück-Umstellen ein paar Minuten länger, weswegen ich das am Wochenende machen werde. Ich wollte nur schon mal die frohe Botschaft verkünden.

Der geneigte und evtl. unwissende Leser wird sich nun fragen, was denn nun so toll an den SBMs ist. Nun, man kann alle Arten von Modulen erstellen. Mit alle meine ich neben HTML-Widgets und allen sonst verfügbaren vor allem die PHP-Widgets. Sozusagen Exec-PHP für die Sidebar[1]. Weitere Vorteile sind, dass man den Titel des Widgets ausblenden und eine zusätzliche CSS-Datei verwenden kann. Und man kann sehr feinkörnig bestimmen, auf welchen Seiten das Modul erscheinen soll. Es ist sogar möglich, einzelne Beiträge ein- oder auszuschließen. Geradezu perfekt. Deshalb plädierten auch viele dafür, dass dieses Plugin statt des WP-Widgets-Plugin in die neue Version übernommen werden soll. Schade, wäre so schön gewesen.

Denn die Arbeit mit den Modulen ist wesentlich stressfreier als mit Widgets. Das Drag & Drop geht flüssiger und die Bearbeitung der Widget-Eigenschaften ist übersichtlicher gestaltet. Die Bearbeitung geschieht in einem eigenen Bereich statt durch ein Popup, was sehr viel schneller geht. Die Änderung der Reihenfolge muss nicht mit einem Buttonklick aktiviert werden (= keine lange Wartezeit, bis sich das Ding berappelt hat), sondern die Sidebar wird sofort in der neuen Reihenfolge dargestellt.

Das Ausführen von PHP-Code ist auch mit den klassischen Widgets möglich, wenn man zusätzlich das Plugin Widgetize Anything verwendet. Das hat aber den entscheidenden Nachteil, dass die Überschriften der Widgets dann durchnummeriert sind mit “Widgetize Anything 1″, …. , “Widgetize Anything n”, wobei n die Anzahl der WA-Widgets ist. Ich selber habe über zehn und da weiß ich gar nicht, welches jetzt welchen Inhalt hat, weil die sich nur durch die laufende Nummer unterscheiden. Die Anzahl muss man übrigens auch extra einstellen. Wenn es zu wenige sind, kann man nicht einfach ein neues Widget per Klick erstellen, wie das bei den SBMs möglich ist, sondern muss erst die Anzahl erhöhen.

Man merkt es vielleicht schon am genervten Unterton: ich bin gezwungenermaßen wieder umgestiegen. Denn auch ein Downgrade auf WordPress 2.1.3 brachte nicht das gewünschte Ergebnis, da dann plötzlich alle Module verschwunden waren und auch ein Datenbank-Backup hat nichts gebracht. Da war ich nicht so erfolgreich wie jojodat.

Dann habe ich also gezwungenermaßen eine Rolle Rückwärts gemacht und bin wieder auf Widgets+Widgetize Anything anstatt SBM umgestiegen. Ich musste alle PHP-Module neu anpassen. Naja, ich hatte das vorher schon mal gemacht und ich musste nur die Änderungen seit meiner letzten Reorganisierungsorgie erneut ausführen. Sieht (fast) wie vorher aus. ABER: jetzt kann ich mich endlich als Weiberblog outen. Mir ist das Problem mit den SBMs nämlich aufgefallen, als ich eine Button-Farm erstellen wollte und nicht konnte. Und dann habe ich gleich auch mal den Junkie-Blog-Button hinzugefügt. Wurde ja Zeit.

Wer noch mehr Vorschläge für hübsche Buttons hat, die da unbedingt reinmüssen, nur her damit.

Angesprochene Links (Auswahl)

• Sidebar Modules (SBM)
• Widgetize Anything
• Exec-PHP
• Prinzzess – Frauen aller Blogs…
• Junkie-Blogs

1. Besagtes Plugin lässt es zu, dass auch php-Code in Beiträgen und Seiten ausgeführt werden kann. Eines der essentiellen Plugins

Was genau soll das jetzt?

Dies hier soll eine Hilfe zum Lokalisieren von WordPress und speziell von Plugins sein. Es richtet sich sowohl an lernwillige Anfänger als auch an Fortgeschrittene, die aber noch nicht alles im Griff haben. Deshalb gibt es die Möglichkeit einzelne Abschnitte zu überspringen. Wer schon den Üblick hat, aber einen Merkzettel zum Ablauf der Lokalisierung sucht, dem empfehle ich die Zusammenfassung.

Inhaltsverzeichnis

1. Voraussetzungen
2. Grundprinzip der Lokalisierung
3. Besonderheit bei Plugins
4. Einrichten von poEdit
5. Erstellen/Bearbeiten einer Sprachdatei
6. Bedienung von poEdit
7. Zusammenfassung

Voraussetzungen

Folgende Vorraussetzungen werden benötigt für die eigentliche Übersetzungsarbeit und das anschließende ungefährliche Testen.

1. Entweder eine lokale Installation von WordPress ODER eine Testinstallation auf einem entfernten Server[1].
   • Entscheidet man sich für erstere Variante, empfehle ich die Anleitung im Mediengestalter-Blog.
   • Die zweite Variante ist für Leute geeignet, die Zugriffsrechte auf ihre entfernten Daten per FTP haben. Man erstellt eine Kopie seines WordPress-Ordners (z.B. als wordpress-test) auf dem Server.
     Wichtig: in wp-configdie Zeile

     $table_prefix  = 'wp_';

     ändern zu

     $table_prefix  = 'wp_test_';

     (wahrscheinlich Zeile 9), damit eine parallele WordPress-Installation erstellt werden kann.

2. Die Software poEdit (erhältlich für Windows und Linux)[2] zum Editieren der Sprachdatei.
3. Auf seinem lokalen Rechner einen Ordner (nennen wir ihn localization direkt auf C:\), der zwei Unterordner zur getrennten Lokalisierung von Theme und Plugins enthält:
   • wordpress-test, der der eigentlichen Wordress-Installation entspricht, aber OHNE zusätzliche Plugins in wp-content/plugins und nur das gewünschte Theme im Ordner wp-content/themes,
   • wordpress-test-plugins/wp-content/plugins für die zusätzlichen Plugins,
   • für jedes Plugin einen eigenen Ordner (auch bei denen, die nur aus einer Datei bestehen – der Ordner heißt dann wie das Plugin).
4. Prüfen: In der Datei wp-config steht die Zeile

   define ('WPLANG', 'de_DE');

   (wahrscheinlich Zeile 15) und im Ordner wp-includes/languages gibt es die Datei de_DE.mo.[3] Der Dateiname kann auch anders lauten, er sollte nur mit der in WPLANG definierten Variable übereinstimmen.

Grundprinzip der Lokalisierung

← zum vorherigen Abschnitt – Inhaltsverzeichnis – → zum nächsten Abschnitt

Zum Prozess der Lokalisierung ein paar einführende Worte. Im WordPress-Codex erfährt man auf der Seite Localizing WordPress, dass dies ein zweistufiger Prozess ist. Im ersten Schritt ist der Entwickler gefragt, der im Quelltext die Möglichkeiten bereitstellt, damit später sein Theme bzw. Plugin übersetzt werden kann. Und im zweiten Schritt erfolgt dann die tatsächliche Übersetzung (hier per poEdit).

Das Ganze basiert auf dem GNU gettext Framework, dem Standard für modulare Übersetzung. Laut der deutschen WordPress-Doku (Bearbeitung der Sprachdatei), sind für gettext zwei Dateien wichtig. Der Ablauf ist folgendermaßen:

1. Gettext liest Zeichenfolgen im Quelltext ein, die in der PO-Datei gespeichert werden.
2. Die Übersetzung erfolgt durch Bearbeiten der PO-Datei.
3. Die übersetzten Zeichenfolgen werden in der MO-Datei gespeichert.
4. Beim Aufruf einer Seite wird die MO-Datei von WordPress ausgelesen und es wird die Übersetzung angezeigt.

Die einzelnen Zeichenfolgen müssen im Quelltext markiert werden für die Übersetzung. Dies erfolgt über zwei PHP-Funktionen, __() und _e(). Zur Erklärung heißt es (meine Übersetzung des Originaltextes):

__($message)

(zwei Unterstriche) Durchsucht das Lokalisierungsmodul nach der Übersetzung von $message und übergibt die Übersetzung als Rückgabewert (return statement). Wenn keine Übersetzung für $message gefunden wird, wird einfach $message zurückgegeben.

_e($message)

(Unterstrich und e) Durchsucht das Lokalisierungsmodul nach $message und übergibt die Übersetzung als Ausgabewert (echo statement). Wenn keine Übersetzung für $message gefunden wird, wird einfach $message ausgegeben.

Diese Markierungen dienen als Schlüsselwörter beim Einlesen. In den PHP-Dateien sollte dann also nicht

echo 'gib mich aus'

stehen, sondern

_e('gib mich aus');

bzw. nicht

'gib mich zurück'

sondern

__('gib mich zurück')

Gut: Das Theme bzw. Plugin ist schon auf diese Weise vorbereitet, d.h. gettextet. Man erspart sich die Fleißarbeit, alle Zeichenfolgen zu ersetzen.

Schlecht: Ist das nicht der Fall, muss man die Dateien durchgehen und an den entsprechenden Stellen __() und _e() einfügen. Dabei die Anführungszeichen nicht vergessen! Man kann sowohl einfache (‘) als auch doppelte (“) verwenden, es sollten nur die gleichen öffnenden und schließenden sein.

Besonderheit bei Plugins

← zum vorherigen Abschnitt – Inhaltsverzeichnis – → zum nächsten Abschnitt

Hier gibt es einen zusätzlichen Parameter, die sog. Domäne, also lautet die Funktion

__($message, $domain)

Damit kann für jedes Plugin (bzw. jede Domäne) eine eigene Sprachdatei erstellt werden. Häufig ist es so, dass die Autoren der Plugins das schon getan haben. Dann findet sich im Quelltext eine Zeile, die etwa so aussehen sollte:

load_plugin_textdomain('plugin-name');

oder

load_plugin_textdomain('plugin-name','wp-content/plugins/pfad/zur/sprachdatei');

Die Domäne impliziert, dass die Übersetzungen in der Sprachdatei wp-content/plugins/$domain-de_DE.mo statt in wp-includes/languages/de_DE.mo zu suchen sind. Der zweite Parameter kann genutzt werden, um einen speziellen Ordner anzugeben. Nachzulesen ist das Ganze im Abschnitt Localizing Plugins.

Vorteil: Die eigentliche Installation und die Zusatzfunktionen werden getrennt übersetzt. Die Haupt-Sprachdatei wird nicht unnötig aufgebläht.

Nachteil: Man muss für jedes Plugin (bzw. jede Domäne) eine eigene Sprachdatei erstellen und verwalten.

Möchte man Ordnung halten und alle Plugin-Sprachdateien in einem bestimmten Verzeichnis speichern, z.B. wp-content/plugins/languages, muss dieses Verzeichnis bei jedem Plugin in der obigen Funktion eingetragen werden.

Achtung: Angenommmen, man möchte keine getrennte Lokalisierung der Plugins vornehmen, sondern die Übersetzungen in der Hauptsprachdatei speichern. Dann muss der zusätzliche Parameter entfernt werden, wenn der Plugin-Autor diesen eingefügt hat. Ansonsten ignoriert WordPress diese Zeichenketten bei der Übersetzung, weil nach der Domänen-Sprachdatei gesucht wird.

Einrichten von poEdit

← zum vorherigen Abschnitt – Inhaltsverzeichnis – → zum nächsten Abschnitt

Im Beitrag Erstellen der Sprachdatei mit poEdit ist vor allem der Abschnitt Konfiguration von poEdit – Allgemeine Programmeinstellungen wichtig. Dort heißt es

Deshalb starten wir poEdit und rufen die Programmeinstellungen (Datei > Einstellungen) auf. Auf der ersten Registerkarte trägst du jetzt deinen Vor- und Nachnamen ein. Auf der Editor-Registerkarte entfernst du das Häkchen vor der Option CR/LF-Konvertierung > Behalte Format existierender Kategorie bei. Dann wechselst du auf die Karteikarte Parser und klickst auf Neu.
In den Feldern trägst du jetzt von oben nach unten ein:

1. PHP
2. *.php
3. xgettext –output=%o %K –language=php %F
4. –keyword=%k
5. %f

Das letzte Feld bleibt frei. Jetzt klickst du zweimal auf OK. Damit ist poEdit fertig für das Parsen von PHP-Dateien.

Neben diesen allgemeinen Einstellungen gibt es noch Einstellungen für die Katalogverwaltung. Die folgenden weichen von den “offiziellen” von WordPress ab, weil hier in einer anderen Ordnerstruktur gearbeitet wird.

Aufgerufen werden diese mit Datei > Katalogverwaltung. Als erstes wird ein neues Übersetzungsprojekt angelegt durck Klick auf den ersten Button ganz links (Tooltip: Erstelle neues Übersetzungsprojekt). Der Name kann beliebig gewählt werden. Die wichtigste Einstellung ist der Pfad zum Projekt, der absolut angegeben wird. Der schon vorgegebene Pfad kann durch Klick auf den Bearbeiten-Button (a|e) angepasst werden. Ist kein Pfad vorgegeben, durch Klick auf den Neu-Button einen neuen erstellen. Hier den Pfad zum oben angelegten Ordner angeben (in diesem Beispiel C:\localization). Fertiggestellt wird das Übersetzungsprojekt durch Klick auf OK.

Damit sind alle allgemeingültigen Einstellungen abgeschlossen. Die folgenden Einstellungen sind katalogspezifisch.

Erstellen/Bearbeiten einer Sprachdatei

← zum vorherigen Abschnitt – Inhaltsverzeichnis – → zum nächsten Abschnitt

Zunächst gehe ich von dem Fall aus, dass bereits eine Sprachdatei existiert, die aktualisiert werden soll. Für die deutsche Version von WordPress, kann man sich die aktuelle PO-Datei herunterladen. Diese ist ein guter Ausgangspunkt für das Übersetzen. poEdit bietet nämlich einen sogenannten Übersetzungsspeicher (Translation Memory, abgekürzt tm), der aufgrund ähnlicher Formulierungen die wahrscheinlichste Übersetzung rät.

Die Sprachdatei de_DE.po im Verzeichnis localization speichern (d.h. in dem Ordner ÜBER der WordPress-Installation) und mit poEdit öffnen. Damit poEdit die richtigen Textstellen zum Übersetzen findet, müssen einige Einstellungen vorgenommen werden.

1. Katalogoptionen öffnen (Katalog > Optionen),
2. in der Registerkarte Projektinfo sollte schon alles Wichtige eingetragen sein, vor allem sollte UTF-8 als Zeichensatz gewählt sein,
3. in der Registerkarte Pfade als Basispfad ./wordpress-test (Punkt Slash und der oben gewählte Ordnername für die WordPress-Installation) eingeben,
4. zusätzliche folgende Pfade durch Klick auf den Neu-Button eintragen:
   • . [das ist ein Punkt]
   • wp-includes
   • wp-admin
   • wp-content\themes [hier Backslash verwenden]
5. in der Registerkarte Schlüsselwörter zwei neue Einträge anlegen mit __ und _e (den oben erwähnten Schlüsselwörtern),
6. Klick auf OK.

Der Klick auf Ok sollte ein Durchsuchen des Quelltextes zur Folge haben. Wenn Fehler kommen, kann es evtl. daran liegen, dass man sich beim Eingeben der Pfade vertan hat. Dann Rückgängig wählen und erneut die Daten eingeben. Das Ergebnis sollte ungefähr so aussehen, wie das Bild rechts (Anklicken für volle Größe). Erst einmal SPEICHERN (zweiter Button von links).

Möchte man eine neue Sprachdatei erstellen, öffnet man poEdit und wählt Datei > Neuer Katalog. Es erscheint wieder der Dialog Katalogoptionen, nur diesmal völlig leer. Die Einstellungen für die Registerkarten Pfade und Schlüsselwörter sind die gleichen wie oben. In der Registerkarte Projektinfo trägt man in den ersten drei Feldern die entsprechenden Infos ein. In die nächsten drei Felder sollten german, germany, utf-8 eingetragen werden. Der Rest bleibt leer. Nach klick auf OK wird man aufgefordert die Datei zu speichern. Als Speicherort den Ordner localization wählen und als Dateiname die Variable bei WPLANG, z.B. de_DE.po.

Für eine Plugin-Sprachdatei gibt es zwei Abweichungen. Bei den Pfaden den Basispfad und den Pfad zum Plugin angeben, z.B. wp-content/plugins/plugin-name. Gespeichert wird die Datei im Ordner localization unter dem Namen $domain-de_DE.po, wobei $domain meist der Name des Plugins ist (siehe oben genannte Besonderheit).

Bedienung von poEdit

← zum vorherigen Abschnitt – Inhaltsverzeichnis – → zum nächsten Abschnitt

Zur Bedienung von poEdit wird man bei WordPress auf die Programm-eigene Hilfe verwiesen. Die ist jedoch lückenhaft, teilweise veraltet, schwer verständlich und bezieht sich nur allgemein auf gettext-Techniken. Deshalb hier eine kurze Einführung.

Die bunten Zeilen bekommt man, wenn im Ansicht-Menü die Option “Gefärbte Übersetzungsliste” angekreuzt ist. Die Farben haben folgende Bedeutung:

• hellblau = unübersetzt
• gelb/beige = unklar
• weiß = übersetzt/alles ok

Am Anfang jeder Zeile können verschiedene Icons auftauchen. Die Beschreibung ist in der Hilfe nicht auf dem neuesten Stand. Hat man in der aktuellen Sitzung eine Zeile verändert, sieht man einen gelben Stern. Die Hilfe gibt an, dass es sich um einen grünen Punkt handeln soll. Wurde ein Eintrag von der tm übersetzt, so sieht man ein Computer-Icon. Besitzt ein Eintrag einen Kommentar, so soll ein Bleistift-Icon erscheinen. Tatsächlich handelt es sich aber um eine Sprechblase.

In der Statuszeile unten stehen die Anzahlen der Zeichenketten (gesamt, unklar, ungültig, unübersetzt). So behält man den Überblick darüber, was noch gemacht werden muss. Alle unklaren Übersetzungen werden von WordPress bei der Anzeige ignoriert, d.h. sie werden so wie nicht übersetzte Zeichenketten behandelt.

Ein schnelles Durcharbeiten ist möglich, da man mit Tab und den Cursor-Tasten bequem durch die Zeichenketten navigieren kann. Es gibt die Short-Cuts Alt-U zum Bestätigen einer unklaren Übersetzung und Alt-C zum Kopieren des Originals in die Übersetzung.

Achtung ist geboten, wenn Platzhalter im Originaltext vorkommen. Diese sind mit einem % gekennzeichnet. Die Anzahlen sollten beim Original und in der Übersetzung übereinstimmen, sonst wird die Übersetzung ungültig.[4] Wenn mehrere Platzhalter vorkommen, sollten diese unterschiedliche Bezeichnungen haben. Oft werden aber alle Platzhalter in einer Zeichenkette mit %s bezeichnet. Das ist ok, solange im Original und der Übersetzung die gleiche Reihenfolge eingehalten wird. Leider ist das aber beim Übersetzen vom Englischen ins Deutsche nicht in allen Fällen möglich. Oder man wählt absichtlich eine Formulierung, die eine andere Reihenfolge der Platzhalter erfordert.

In diesem Fall muss der Quelltext bearbeitet werden. Das geht aber nicht direkt in poEdit, sondern nur in einem externen Editor. Wo die Zeichenkette auftaucht, mit Dateiname und Zeilennummer, erfährt man durch einen Rechtsklick auf die Zeichenkette (siehe Screenshot). Klick auf den Eintrag im Kontextmenü öffnet den Editor an dieser Textstelle[5]. Nun kann man die Platzhalter durchnummerieren mit %1$s, %2$s, .... Datei speichern nicht vergessen.

Nach jeder Änderung der Originaltexte oder Hinzufügen von Dateien, muss der Katalog aktualisiert werden, d.h mit den Quellen synchronisiert werden. Dazu einfach den Update-Button klicken (dritter Button von links). Nach dem Aktualisieren und Speichern werden die Icons und Farben angepasst.

Das Kontextmenü gibt außerdem Informationen über die Übersetzungsvorschläge an (wenn es denn welche gibt) und man kann sich den besten aussuchen oder selber eine bessere Übersetzung eingeben.

Am Ende der Bearbeitung den Katalog speichern. Damit wird automatisch auch die MO-Datei erstellt. Wenn nicht, unter Datei > Einstellungen, Registerkarte Editor ganz oben diese Option ankreuzen.

Zusammenfassung

Um immer wieder seine WordPress-Installation bzw. neue Plugins zu übersetzen geht man folgendermaßen vor.

1. Synchronisation der Test-WordPress-Installation mit dem localization-Ordner, mit dem Unterschied, dass die Plugins separat abgespeichert werden (Was ist damit gemeint?),
2. bei einem neuen Theme oder Plugin:
   1. Textstellen auf gettext-Zustand prüfen, d.h. ob überhaupt gettextet, ob mit __($message) oder mit __($message, $domain) (letzteres gilt nur für Plugins),
   2. wenn nötig, Textstellen anpassen (Was ist damit gemeint?),
   3. bei Plugins, Anpassen an individuelle Vorzüge (Was ist damit gemeint?),
   4. geänderte Dateien zur Test-WordPress-Installation kopieren.
3. Öffnen/Erstellen der PO-Datei in poEdit (Wie geht das?),
4. Ändern, Aktualisieren und Speichern der PO-Datei bis zum gewünschten Ergebnis (Wie geht das?),
5. Kopieren der erstellen MO-Datei in das entsprechende Verzeichnis der Test-WordPress-Installation (wp-includes/languages für die Haupt-Sprachdatei, und wp-content/plugins bzw. wp-content/plugins/languages,
6. Aufruf der Seite, auf der der übersetzte Text auftauchen soll, um zu prüfen, dass man die richtigen Stelle erwischt hat,
7. gegebenenfalls diese Schritte wiederholen, bis das gewünschte Ergebnis erreicht ist,
8. Wenn dies dann endlich der Fall ist, kann man die Dateien endlich zur “realen” WordPress-Installation kopieren (d.h. alle neuen und geänderten Dateien – bloß keine vergessen!)

Das war es auch schon. Anregungen, Kritik oder sonstige Anmerkungen?

1. Ich persönlich empfehle die zweite Variante, weil sie (sehr viel) weniger aufwändig ist. Außerdem kann man auf dem Server testen, auf dem die “richtige” WordPress-Installation ist.
2. Es gibt auch andere Software, aber poEdit ist leicht zu bedienen und frei erhältlich. Außerdem beziehe ich mich hier in den Erklärungen auf poEdit.
3. Dies sollte der Fall sein, wenn man die DE-Version von WordPress installiert hat. Ansonsten muss man nachträglich die deutsche Sprachdatei installieren.
4. Wenn es ungültige Fehlerketten gibt, lässt sich der Katalog manchmal nicht mehr speichern. Es gibt dann eine Fehlermeldung mit Details. Abhilfe schafft die Bearbeitung der PO-Datei in einem Texteditor. Die Zeile(n) suchen, die in der Fehlermeldung angegeben ist/sind und alles zwischen den Anführungszeichen bei msgstr löschen.
5. Sollte das nicht funktionieren, stimmen die Einstellungen zum externen Editor nicht. Diese findet man unter Datei > Einstellungen, Registerkarte Editor. Im Feld Editor EXE-Datei sollte z.B. notepad %f stehen. Das Ankreuzfeld darunter sollte ein Häkchen haben. Funktionert es immer noch nicht, kann man die Datei auch manuell im Editor öffnen.

Warum keine Sidebar? Tja, da gibt es wohl einen Fehler und die Seite wird ab da nicht mehr geladen. Unabhängig vom Theme. Sehr seltsam. Hatte das Problem vor Kurzem schon einmal. Da hat es sich aber nach wenigen Minuten wieder gegen. Das hier hält jetzt seit über zwei Stunden an.

Update: ich konnte es zurückverfolgen auf ein Sidebar-Widget. Aber auf eins, das automatisch bei der Standard-Installation von WordPress dabei ist! Die neueste Version des Widget-Plugins soll WP 2.1 kompatibel sein.

Mein Problem tauchte im Category-Widget auf. Dort wird noch die als deprecated eingestufte Funktion wp_list_cats verwendet. Ich habe mal ausprobiert und die neue Funktion wp_list_categories eingesetzt. Geht rudimentär auch. Die Anzahl der Beiträge pro Kategorie wird nicht angezeigt. Kreuze ich das im Widget an, dann gibt es wieder den EOF-Fehler. Meine Annahme, dass es daran lag, dass das Argument optioncount durch show_count ersetzt wurde, konnte sich nicht bestätigen. Also habe ich den Funktionsnamen und die Argumentbezeichnung wieder zurückgesetzt.

Immerhin habe ich jetzt auch rausgefunden, dass man mit dieser Funktion auch den Feed pro Kategorie anzeigen lassen kann. Ganz noch das Argument feed_image=/pfad/zum/rss/icon einfügen.

Vielleicht stellt sich ja auch hier raus, dass das gar nicht der Fehler war, aber immerhin weiß ich jetzt wieder ein wenig mehr über die WordPress-Funktionen… Vielleicht reicht es irgendwann dazu, mein eigenes Theme zu gestalten. Wir werden sehen.

Update: Es liegt bei mir definiv an den Sidebar-Widgets. Mittlerweile musst ich das Pandora-Widget aus diesem Grund deaktivieren.

Das muss ich jetzt mal loswerden. Gestern (bzw heute gegen Mitternacht) kam WordPress 2.1 raus. So viel besser, so viel einfacher, so viel einfach alles. HA! Erst sollen gar nicht alle Plugins funktionieren (naja für mich irrelevant, aber trotzdem) aber ansonsten soll es gaaaaanz einfach gehen.

Also ich frisch ans Werk und brav die Instruktionen ausgeführt und auch Backup gemacht. Und dann wieder brav alle deaktivierten Plugins aktiviert. Es ging soweit ganz gut bis ich zur Auflistung meiner Blogroll-Kategorien komme:

WordPress database error: [Unknown column 'link_count' in 'where clause']
SELECT * FROM wp_categories WHERE cat_ID > 0 AND link_count > 0 ORDER BY cat_name ASC

Begeisterung pur. Irgendwas stimmt also nicht mit der Zuordnung der Links meiner Blogroll zu Kategorien (Tabelle wp_link2cat). Das gleiche Bild im Admin-Bereich. Aber beheben kann ich das auch nicht! Beim Verfassen dieses Beitrags lacht mich die gleiche Fehlermeldung an, da wo es um die Zuordnung des Beitrags zu einer Kategorie geht.

Und hier liegt auch der Grund: ab Version 2.1 sollen Beitrags- und Blogroll-Kategorien ein- und dasselbe sein. Pech nur, dass ich das ganz anders organsiert habe. Man sollte erwarten, dass dies beim Upgrade beachtet wird, aber Pustekuchen. GRUML. In der Admin-Übersicht meiner Beiträge werden die Kategorien schön ordentlich aufgeführt. Und bei meinen Links gibt es auch eine Zuordnung, die allerdings etwas gewöhnungsbedürftig ist. Ich nehme an, es liegt daran, dass die Kategorien per ID angesprochen werden und deshalb etwas seltsam anmuten.

Behebungsversuche meinerseits (Rumbastlen an Datenbank per phpMyAdmin, Neuinstallation von WordPress etc) haben bisher nichts gefruchtet. Ich weiß nicht, ob ich es übers Herz bringe, da noch länger dran rumzubasteln. Eigentlich hab ich ja auch was anderes (Wichtigeres) zu tun. Also nicht wundern. Zwischendurch hab ich noch fast einen Herzinfarkt bekommen, als gar nichts mehr dargestellt wurde und der Aufruf jeder php-Seite von Firefox mit einer Datei-Speichern-Aufforderung quittiert wurde. Aber das geht ja mittlerweile wieder.

Update: Aufgeben konnte ich ja nicht und deshalb bin ich das mal logisch angegangen. Es hat tatsächlich irgendwie funktioniert, wenn auch mit ein wenig Aufwand und ohne Sicherheitsgarantie. Wer einen Fehler in meiner Vorgehensweise findet, bitte einen kurzen Kommentar dazu – Danke. Aber mit folgender Vorgehensweise, funktioniert es zumindest vorläufig bei mir:

1. Einloggen in Datenbank per phpMyAdmin (wenn das auf dem betreffenden Weblog nicht möglich ist, weiß ich auch nicht…),
2. Auswahl der Tabelle wp_categories (wenn “wp_” das Tabellenpräfix),
3. Anlegen eines neues Feldes (am Ende) mit den Eigenschaften
   

   Feld	link_count
   Typ	BIGINT
   Länge/Set	20
   Attribute	[leer]
   Null	not null
   Standard	0
   Extras	[leer]

4. Speichern des eben erstellen Feldes.
5. Zurück in WordPress im Admin-Bereich die Blogroll-Kategorie aufrufen,
6. Manuelles Bearbeiten jedes einzelnen Blogroll-Links,
7. Kategorien sind noch keine vorhanden, können aber leicht hinzugefügt werden,
8. werden bereits vorhandenen Kategorienamen verwendet (also Kategorien für Beiträge), dann wird auch die Anzahl Links in der Admin-Kategorie Verwalten » Kategorien entsprechend angepasst.

So, nachdem ich das Wort Kategorie in drei verschiedenen Varianten gebraucht habe, hoffe ich, dass niemand verwirrt wird.

Ganz optimal ist dieser Lösungsansatz nicht, man kann nämlich keine neuen Beitragskategorien anlegen. Möchte ich eine neue Kategorie names Kategorie anlegen, erscheint der Fehler

WordPress database error: [Unknown column 'links_private' in 'field list']
INSERT INTO wp_categories (cat_ID, cat_name, category_nicename, category_description, category_parent, links_private, posts_private) VALUES (’0′, ‘Kategorie’, ‘kategorie’, ”, ’0′, ’0′, ’0′)

HILFE! Wer weiß Rat? Ich bisher (noch) nix finden können.

Update 2: So, hab mir selber geholfen! War ganz einfach. Einfach zwei weitere Felder in wp_categories analog obiger Methode einfügen:

1.  
   

   Feld	posts_private
   Typ	TINYINT
   Länge/Set	1
   Attribute	[leer]
   Null	not null
   Standard	0
   Extras	[leer]

2.  
   

   Feld	links_private
   Typ	TINYINT
   Länge/Set	1
   Attribute	[leer]
   Null	not null
   Standard	0
   Extras	[leer]

3. Es muss eine Kategorie "Blogroll" geben. Falls noch nicht vorhanden, als neue Zeile einfügen.

Das sollte auf jeden Fall stimmen. Ich bin erst nicht darauf gekommen, weil in der zweiten Fehlermeldung das Feld link_count fehlte und ich deshalb nicht weiter wusste. Aber dann habe ich eine zusätzliche Instanz von WordPress (mit anderem Tabllenpräfix - einzustellen in wp-config.php) installiert und mir da die Tabellenstruktur angesehen. Dort hat wp_categories genau jene drei zusätzlichen Felder mit den gegeben Eigenschaften. Also sollte es damit funktionieren. Bei mir gab es jedenfalls noch keine Probleme.

Das Einzige, was ich noch nicht rausgefunden habe, ist die Standardkategorie. Bei einer Neuinstallation sind sowohl "Unkategorisiert" als auch "Blogroll" als Standardkategorien definiert (einmal für Beiträge, einmal für Links). Wo man das einstellt, habe ich nicht gefunden. Es gibt in der Tabelle wp_options die Zeile "default_category", aber da steht nur die ID für "Unkategorsiert" drin.

Dann bin ich auf die Idee gekommen, mit poEdit die sogenannten .po Dateien zu bearbeiten. Ich habe aber einfach nicht herausbekommen, wie man Einträge hinzufügt. Das wäre aber natürlich notwendig gewesen, um die gettexten Phrasen zu übersetzen. Bis mir dann irgendwann (nach mehreren Stunden) aufgegangen ist, dass ich den Quelltext durchsuchen muss. Bis ich dann auf der deutschen WP-Doku-Seite zum Erstellen der Sprachdatei mit poEdit [Edit: geänderten Link angepasst] gefunden habe, wie man poEdit so einstellt, dass die Quellen durchsucht werden. Und tatsächlich wurden dann auch die von mir geänderten Einträge neu aufgenommen! Von da war es nur noch eine Frage der Ausdauer und guter Augen, dass ich alle Textstückchen finde, die übersetzt werden sollen. Hat auch fast komplett alles geklappt.

Nur bei den kniffligeren PHP-Sachen hat es mich dann aus der Bahn geworfen. Ich möchte eine Variable ($time_period) auch übersetzen. Das kann mal year, mal month sein und da soll dann logischerweise Jahr bzw. Monat draus werden. Ok, man kann Parameter z.B. mit der Funktion sprintf() übergeben, wie ich mir dann zusammengelesen und -gereimt habe, aber was ist mit Variablen? Geht das gar nicht? Muss ich eine Fallunterscheidung machen? Hüülfe!

Worum ging es eigentlich konkret? Um das Now Reading Plugin, dass mir auf meiner Bibliotheksseite anzeigen soll, wie viele Bücher ich durchschnittlich pro Jahr/Monat gelesen habe. Und jetzt steht da year/month. Gruml. Vielleicht überkommt mich ja noch eine Eingabe. Mal sehen. Nachtrag: Das Plugin wurde mittlerweile wieder deaktiviert und deswegen gibt es die Bibliotheksseite nicht mehr.