Code Styling Project

In vielen Blogs und Foren kann man immer wieder lesen, das es Probleme mit den Monatsnamen gibt, wenn ein Plugin oder Theme diese nicht mit WordPress eigenen Funktionen ausgibt. Meist wird dann zur groben Kelle gegriffen und einfach die locale (Gebietsschema) umgeschaltet.
Auch gibt es einige Plugins für Mehrsprachigkeit von WordPress, die diese Umschaltung standardmäßig durchführen, ohne das man selbst was per Konfigurationsseite dran ändern könnte.

Um das Ganze mal an einem praktischen Beispiel zu zeigen, habe ich die Unterschiede zwischen amerikanischen englisch und deutsch gewählt. Nachfolgend der übliche Umschaltcode für ein deutsches Gebietsschema:

<?php setlocale(LC_ALL, "de_DE.utf-8"); ?>

oder aber die geläufigere Variante:

<?php setlocale(LC_ALL, "de_DE"); ?>

Das löst zwar das Problem mit den Monatsnamen der date() Funktion, produziert aber unbeabsichtigt weit größere und zum Teil versteckte Probleme.
Wenn man beispielsweise nun eine Zahl mit Nachkomma-Anteil benutzen möchte und diese dann im Zuge der HTML Ausgabe in Zeichenketten konvertieren lässt, dann wundert man sich, warum das Layout dann “kollabiert”. Auch hier wieder ein Beispiel:

<?php $my_float = 32.5;
echo "<div style='width:$my_float%;'>Hallo</div>"; ?>

Was würde man jetzt erwarten im Quelltext des Browsers ? Sicher dies hier:

<div style='width:32.5%;'>Hallo</div>

Aber leider bekommt man jetzt folgende Ausgabe:

<div style='width:32,5%;'>Hallo</div>

Das ist aber für den Browser nun keine gültige Dezimalzahl mehr, da der Browser die deutsche Dezimaltrennung in Stylesheets nicht versteht! Somit ist dieser Container nicht 32.5% breit sondern die vollen 100% (sofern keine float’s im Spiel sind).
Unerwartet? Erstaunt? Genau das ist das Spiel mit den Komma-Separatoren. CSS und auch PHP verstehen nur die US Dezimaltrenner, weshalb alles was man dann damit machen will, nicht mehr funktioniert.

Und auch ein weiteres Beispiel, wie das versteckt im Backend schaden kann, will ich nicht vorenthalten. Die meisten kennen sicher den Google Sitemap Generator. Dieser funktioniert einwandfrei, solange die Locale Einstellung auf US oder “C” Standard steht. Stellt man das jedoch per setlocale() auf deutsch um, kann der Sitemap Generator die Häufigkeitsangaben der einzelnen Bereiche in der Sitemap nicht mehr von Text in Zahlen korrekt umwandeln, denn die Oberfläche schickt ja alles als Text beim Speichern an das Plugin.

Somit wird dann aus “0,5″ eine Priorität von 0.0 denn die PHP interne Konvertierung von Text in Zahlen beruht weiterhin auf dem Dezimaltrenner ‘.’ und hört nach der 0 eben auf.
Das führt zu 2 Problemen:

1. man kann so nur zwischen Priorität 0% und 100% wählen, denn alles was kleiner 1,0 ist wird zu 0 !
2. Google Webmaster Tools beschwert sich nachfolgend und nachdrücklich, dass alles 100% ist oder ignoriert die Seite wegen unbeabsichtigter 0% Einstellung !

Das ist SEO Horror pur, oder? Aber was kann man dagegen unternehmen?

a) Hände weg von setlocale() und WordPress Funktionen nutzen

WordPress stellt eine resistente Datumsfunktion für Lokalisierungen bereit, die man immer dann nutzen sollte, wenn man einen Monatsnamen im Datum formatiert haben möchte:

<php
echo date_i18n( 'D F j G:i:s T Y', strtotime( $post->post_date ) );
?>

ergibt dann die Ausgabe:

Sat March 10 15:16:08 MST 2001 (englisch, Standard WordPress)
Sam März 10 15:16:08 MST 2001 (deutsch, mit deutscher Sprachdatei)

b) die locale setzen aber den Dezimaltrenner wieder umstellen

Es soll ja Fälle geben, in denen man die locale trotzdem setzen muss (auch wenn mir keiner einfällt im Moment). Dann kann man die Dezimaltrennung direkt nach dem Setzen des Gebietsschemas wieder ändern:

<?php
setlocale(LC_ALL, "de_DE");
setlocale(LC_NUMERIC, 'C');
?>

Die Umstellung auf ‘C’ als locale für die numerischen Werte sagt dem Betriebssystem und PHP, dass nun die C/C++ Dezimaltrennung zu verwenden ist, welche der normale Punkt ‘.’ ist. Damit werden die Monatsnamen nun korrekt deutsch durch die normale PHP date() Funktion ausgegeben, andererseits rechnet und konvertiert PHP dann mit korrekten Fließkommazahlen.

Fazit: Wenn man am Gebietsschema (locale Einstellungen) rumspielt, sollte man immer wissen, was einem da so blühen kann. Die Resultate können plötzlich zerstörte Layouts, nicht mehr funktionierende Scripts aber auch abstürzende oder funktionsgestörte Plugins sein.
Ich hoffe, das hilft ein wenig weiter, zu verstehen, wo Fehler schlummern können oder plötzlich herkommen.