Was macht comments_popup.php?

Da fängt das Problem schon an. Denn eine vernünftige Dokumentation gibt es nicht. Nach langer Suche findet man heraus, dass das Template comment_popup.php von WordPress genutzt wird, wenn die Kommentare in einem Popup dargestellt werden sollen. Diese Form der Darstellung habe ich bisher noch nie gesehen. Nach weiterer Recherche findet man heraus, dass man um diese Darstellung zu aktivieren in die header.php den Funktionsaufruf

<?php comments_popup_script(); ?>

von Hand eintragen muss. Am besten macht man das mit dem Default Theme, denn das sollte ja die Funktion perfekt unterstützen . Wer es ausprobiert wird feststellen, dass selbst im Default Theme die Darstellung nicht perfekt ist – total kaputt trifft es eher.
Die Funktion wird bisher also (kaum) genutzt, weil sie nicht benötigt wird oder weil sie unbekannt ist.

Der Inhalt von comments_popup.php

Beim Blick in die Templatedatei des Default Theme fällt auf, dass die Struktur und die Texte sich stark von denen in den anderen Templatedateien unterscheiden.
Das liegt haupsächlich daran, dass ab WordPress 2.7 die Ausgabe der Kommentare in die Funktion

<?php comments_template(); ?>

ausgelagert wurde.
Will man in einer aktuellen WordPress Version die Kommentare anders ausgeben, schreibt man sich eine Callback Funktion und ruft comments_template() damit auf. Dagegen wird in comments_popup.php ganz Old School die Liste der Kommentare ausgelesen und per Schleife ausgegeben. Ein Austausch der Ausgabeschleife gegen den Funktionsaufruf comments_template() funktioniert nicht. Auch die Texte im Footer sind andere als im Template footer.php.
Das spricht alles dafür, dass die Funktion der comments_popup.php schon längere Zeit technisch bzw. WordPress intern nicht mehr auf den neuesten Stand der Technik gebracht wurde.

Fazit

Aus meiner Sicht ist die comments_popup Funktion überholt. Kaum einer verwendet sie. Ein eigenes Theme für die Verwendung mit Popup Kommentaren vorzubereiten ist sehr aufwändig, da sich das Layout dieses einen Templates sehr von den übrigen Templates unterscheidet. Man müsste ein neues Layout inkl. allen Formatierungen für die Kommentarausgabe erstellen. Dazu wäre man gezwungen, die Kommentare wieder “per Hand” auszugeben, was die WordPress Entwickler durch die neue comments_template() Funktion vermeiden wollten. Bleibt zu hoffen, dass die Funktionen des Templates entweder aktualisiert werden oder es aus WordPress entfernt wird.

Einheitliche Bezeichnungen verwenden

In WordPress Themes wird an vielen Stellen der gleiche Text benutzt. Z.B. der “Bearbeiten” Link oder das Erstellungsdatum eines Beitrags. Um dem Übersetzer die Arbeit zu erleichtern und auch den Nutzern eine einheitliche Beschreibung zu bieten, sollte man schon bei der Erstellung eines Themes darauf achten, nicht ständige unterschiedliche Textstrings zu verwenden.

Beispiel: ‘Bearbeiten’, ‘Beitrag bearbeiten’, ‘Artikel bearbeiten’ können alle normalerweise durch ‘Bearbeiten’ ersetzt werden.

Themes immer in English erstellen und dann übersetzen

Wenn man beabsichtigt, ein Theme zu veröffentlichen, sollte man von Anfang an das Theme mit englischen Texten erstellen und erst danach übersetzen. Durch die englische Sprache erreicht man mehr Menschen, die das Theme dann in ihre eigene Sprache übersetzen können. Außerdem merkt man bei der Übersetzung ins Deutsche selbst, ob sich Fehler eingeschlichen haben oder die Texte nicht optimal sind.

Plugins aus

Bei der Erstellung eines Themes und für die ersten Tests sollte man alle Plugins ausschalten. Viele Plugins laden Stylesheets in das Theme, was zu Darstellungsfehlern führen kann. Ohne Plugins hat man die Darstellungsfehler selbst verursacht. Damit ohne Plugins das Blog nicht zum gefundenen Fressen für Spammer wird, entwickle ich Themes nur in einer lokalen Entwicklungsumgebung.

Theme Checklist durchgehen

Sehr hilfreich ist die Theme Development Checklist auf dem WordPress Codex. Hier werden eine ganze Reihe Punkte aufgelistet, auf die man sein Theme überprüfen sollte. Mit Sicherheit finden sich einige Punkte, an die man selbst nicht gedacht hätte, weil man sie selbst nicht nutzt. Bei mir waren das z.B. die Gallery und $content_width.

Testen, Testen, Testen

Klingt blöde und jeder Theme Entwickler macht sicher Tests bevor er sein Theme veröffentlicht, aber wie wird getestet?

In der Theme Development Checklist findet sich ein Download von Testdaten, die in WordPress importiert werden können. Im Netz gibt es an einigen Stellen auch ähnliche Demodatensätze. Durch solche Demodaten kann man sicherstellen, keine Funktion von WordPress zu übersehen, weil man sie normalerweise nicht nutzt.
Testet man nur im eigenen Blog mit seinen eigenen Artikeln, dann testet man auch nur, wie das Theme mit der eigenen typischen Nutzung aussieht. Wie sieht das Theme aber mit sehr vielen Bildern oder extrem vielen Kategorien aus? Oder mit extrem kurzen oder sehr langen Beiträgen? Fremde und strukturierte Daten erlauben umfassendere Tests.

WordPress hat sich weiterentwickelt und ich habe einiges gelernt, deswegen kann ich ein paar Tipps zur Übersetzung mit poEdit hinzufügen:

Die richtigen Keywords in poEdit angeben

poEdit bietet die Möglichkeit den Übersetzungskatalog aus den Quelldateien zu aktualisieren (Menü “Catalog” -> “Update from Sources”). Das ist nützlich, wenn man größere Änderungen in den Quelldateien gemacht hat und dadurch z.B. neue Texte hinzufügt hat, die übersetzt werden müssen.

Die entsprechenden Stellen findet poEdit, indem das Programm nach den in den Einstellungen hinterlegten Keywords sucht (Menü “Catalog” -> “Settings” -> Tab “Keywords”)

poEdit Keywords

Diese Keywords sind für WordPress __ , _e, _c und __ngettext. Die Keywords bzw. die Funktionen _c und __ngettext sind erst mit neueren WordPress Versionen hinzugekommen.

Unklare Übersetzungen mit Beschreibungen kennzeichnen

Die Funktion _c() wird genutzt, um Texte mit Kommentaren zu versehen z.B. _c("Vortrag|Rede") und _c("Vortrag|Buchhaltung"), damit ein Übersetzer leichter die beabsichtigte Aussage erkennen kann. Ein gutes Beispiel ist im Default Theme in der Datei archive.php

<h2 class="pagetitle"><?php printf(_c('Archive for %s|Daily archive page', 'kubrick'), get_the_time(__('F jS, Y', 'kubrick'))); ?></h2>

<h2 class="pagetitle"><?php printf(_c('Archive for %s|Monthly archive page', 'kubrick'), get_the_time(__('F, Y', 'kubrick'))); ?></h2>

<h2 class="pagetitle"><?php printf(_c('Archive for %s|Yearly archive page', 'kubrick'), get_the_time(__('Y', 'kubrick'))); ?></h2>

Platzhalter benutzen

Es ist einfacher einen ganzen Satz zu übersetzen, statt einzelner Satzteile

Schlecht:

<?php _e("Benutzer: ").$x._e(" hat ").$iArticleCount._e(" Artikel geschrieben"); ?>

Hier sind Teilestrings mit Leerzeichen und Satzzeichen enthalten. Dazu kommt, dass in anderen Sprachen evtl. die Gramatik einen anderen Satzaufbau erfordert.

Besser:

<?php _e("Benutzer %1$s hat %2$d Artikel geschrieben", $x, $iArticleCount); ?>

Der Übersetzer kann jetzt den Satz beliebig umstellen. Durch die Platzhalter werden die Werte an den entsprechenden Stellen eingefügt.

Pluralformen übersetzen

Der Plural ist in den verschiedenen Sprachen sehr unterschiedlich und damit auch schwer zu übersetzen. Dazu gibt es die __ngettext() Funktion. Singular und Plural können dabei unterschiedlich übersetzt werden.

Beispiel:

<?php printf(__ngettext("Ein Beitrag ist neu","%d Beiträge sind neu", $iArticleCount), $iArticleCount); ?>

In Variable $iArticleCount ist die Anzahl der Beiträge enthalten. Ist $iArticleCount == 1, dann wird die Singularform “Ein Beitrag ist neu” gewählt. Ist $iArticleCount > 1, dann wird die Pluralform “%d Beiträge sind neu” gewählt. Abschließend wird noch der Platzhalter %d durch $iArticleCount ersetzt.

Im WordPress Codex ist im Artikel I18n_for_WordPress_Developers noch mehr zu Thema Übersetzungen bzw. I18n zu finden.

Bei Mediadonis habe ich vor langer Zeit (2007!) einen Artikel gefunden und gebookmarkt, der für obiges Problem eine Lösung beschreibt. Inzwischen ist aber die Entwicklung bei WordPress weiter und der Code von Marcus ist nicht mehr optimal.

Mediadonis Code:

register_sidebar(array(
"before_widget" => "<li>",
"after_widget" => "</li>",
"before_title" => "<div>",
"after_title" => "</div>",
));

Der Code funktioniert noch immer, aber die neuen Widget-IDs und CSS Klassen, die WordPress automatisch generiert, gehen verloren. Das Styling einzelner Widgets per CSS über entsprechende Klassen ist nicht mehr möglich.

Aktueller Code:

register_sidebar(array(
'name' => sprintf(__('Sidebar %d'), 1 ),
'id' => 'sidebar-1',
'before_widget' => '<li id="%1$s" class="widget %2$s">',
'after_widget'  => '</li>',
'before_title' => '<div class="sidebar_header">',
'after_title' => '</div>'
));

Obiger Code erzeugt eine zum WordPress Standard identische Struktur inkl. aller CSS Klassen und IDs. Nur eben mit einem DIV um die Überschriften anstatt der H2 Tags.

Über den Nutzen so einer Detailoptimierung kann man sicher streiten. So könnte man behaupten, dass dadurch die Struktur bzw. das Markup versaut wird. Eine Suchmaschine könnte inzwischen durchaus so intelligent sein und erkennen, dass eine H2 Überschrift “Kommentare” im Quelltext mit großer Wahrscheinlichkeit von Kommentaren gefolgt wird und nichts mit dem eigentlichen Content zu tun hat. Auch Marcus verwendet auf Mediadonis.net – noch oder wieder – H2 Tags für die Überschriften in seiner Sidebar. Bei mir ist es im Moment (noch?) genauso.

Mein bisheriges Theme ZyRed war von mir für die WordPress Version 2.5 erstellt worden. Es funktioniert zwar auch noch mit der aktuellen WordPress Version 2.8.x, aber man konnte es im Laufe der Zeit förmlich altern sehen. WordPress generiert jetzt andere HTML Strukturen und die CSS Stylesheets funktionieren dadurch nicht mehr perfekt. Vor allem werden neue Theme Funktionen wie Gravatars oder verschachtelte Kommentare nicht unterstützt. ZyRed ist kurz gesagt überaltert und ich hatte mich seit zwei größeren WordPress Releases nicht mehr um die Theme Entwicklung gekümmert. Obwohl ZyRed sehr vielen Nutzern gefällt habe ich mich daran satt gesehen und wollte seit vielen Monaten ein neues Theme für diesen Blog.

Es gibt zwar sehr viele und sehr schöne Themes zum Download, aber ich wollte wieder auf den aktuellen Stand der WordPress Theme Entwicklung kommen und auch ein Theme erstellen, das genau das macht, was ich mir wünsche. Also viele Stunden Nachtarbeit verbracht mit Durchwühlen der WordPress Dokumentation, HTML und PHP und sehr viel CSS Bastelei. Herausgekommen ist ein Theme, das bis auf eine Ausnahme alle Funktionen von WordPress 2.8.x unterstützt und als Basis für die Entwicklung weiterer Themes hervorragend geeignet ist. Ich nenne es ZYUI. Die Layoutgrundlage ist YUI Grids von Yahoo. Ein CSS Framework, das ein gleiches Erscheinungsbild auf verschiedenen Browsern sicherstellt und verschiedene Grundlayouts bereitstellt.

ZYUI ist mit CSS Stylesheets leicht anpassbar, vollständig übersetzbar und Dank YUI und wenig HTML Ballast von Anfang an SEO optimiert. ZYUI ist aber kein weiteres Theme Framework. Wieso und warum und weitere Informationen zum Theme werde ich in den nächsten Beiträgen schreiben. Im Laufe der ZYUI Entwicklung habe ich einiges über WordPress gelernt und möchte dies gerne weitergeben.

Da ZYUI die neuen Theme Tags von WordPress 2.8 unterstützt, war auch ein Update meiner WordPress Installation unvermeidlich. Hier habe ich leider eine unangenehme Überraschung erleben müssen. Mein Hoster verwendet ein 64 Bit Betriebssystem auf dem Server, wodurch ich fast schon mit der Basisinstallation von WordPress  die 32 MB PHP Speichergrenze meines Webhosters überschreite. Als Notlösung musste ich die deutsche Sprachdatei von WordPress deaktivieren. Deswegen sind hier im Moment viele Texte in Englisch. Das ZYUI Theme ist natürlich schon vollständig eingedeutscht.

Das neue ZYUI Theme ist noch nicht ganz fertig für eine Veröffentlichung. Auch hier im Blog ist noch einiges zu tun, so könnte sich das Design noch komplett ändern. Das jetzige Design ist ein Child-Theme von ZYUI, das ich innerhalb einer Stunde vom ZYUI ableiten konnte.

“Alles glänzt so schön neu” …. und es wird noch besser.