Beiträge von MarkusW

    Zur Erläuterung: gettext ist eine im Unix-Bereich ziemlich weit verbreitete Library, die im Grunde nichts anderes macht, als einen übergebenen "Original"-String (meist englisch) durch den korrespondierenden übersetzten String aus einer speziell aufbereiteten Sprachdatei zu ersetzen - das ist die .mo-Datei, die auch Wordpress verwendet.

    PHP kann mit gettext-Support kompiliert werden (--with-gettext). Ist das der Fall, dann stehen dem php-Programmierer php-Funktionen zur Verfügung, die ihrerseits das externe gettext-Programm kapseln und so gettext-Funktionalität direkt in PHP bieten.

    Ein Problem ergibt sich allerdings dann, wenn auf dem Rechner, auf dem das PHP-Script läuft, welches diese gettext-Funktionen verwendet, kein gettext installiert oder wenn php ohne die gettext-Extension kompiliert wurde oder wenn die gewünschte locale vom Betriebssystem nicht unterstützt wird. Anders als die meisten Linux-Distributionen bringt Windows standardmäßig kein installiertes gettext mit. Wordpress müsste daher bei Verwendung der externen gettext-Library beim lokalen Test auf einer XAMPP-Windows-Installation ohne Support für Internationalisierung laufen. Um Wordpress möglichst portabel zu halten, musste man daher auf ein Drop-In-Replacement für die gettext-Erweiterung zurückgreifen, welches ausschließlich mit internen PHP-Funktionen arbeitet und sich trotzdem auf das durch gettext definierte .mo-Format der Sprachdateien versteht.

    Dafür hat man auf php-gettext zurückgegriffen. Das sind die beiden Dateien gettext.php und streams.php im wp-includes-Verzeichnis. Diese Dateien stammen nicht vom Wordpress-Team. php-gettext wird nicht nur von Wordpress verwendet, sondern u.a. von den Projekten Gallery und SquirrelMail. Mit dieser php-nativen Lösung bekommt man theoretisch gettext-Funktionalität ganz ungeachtet von irgendwelchen Abhängigkeiten außerhalb von php selbst (Betriebssystem-locale, gettext-Verfügbarkeit, gettext-PHP-Extension).

    Das Problem mit php-gettext ist allerdings, dass dieser Code noch immer Beta ist. Es sind dort beim Zugriff auf das mo-File und beim Caching der Daten Operationen erforderlich, die nicht gerade zu den Stärken von php gehören. So führen z.B. aktivierte magic-quotes dazu, dass das binäre Lesen des mo-Files nur Datensalat produziert; das Script muss zudem entscheiden, wie die CPU tickt (Big Endian vs. low Endian) um Binärdaten korrekt in den Speicher zu schreiben und wieder einzulesen - wird dabei nicht richtig geraten (wie es z.B. bei 64-bit Prozessoren passieren kann), dann führt auch das wieder zu einem fatalen Fehler. Schließlich gibt es noch Bugs in php selbst, die in diesem Bereich dazu führen, dass Binäroperationen nicht so laufen wie sie sollen. gettext hat alle diese Probleme natürlich nicht, da es sich anders als bei einem php-Script eben um nativ kompilierten Code handelt.

    Da es sich bei php-gettext um ein externes Projekt handelt, würde ich vermuten, dass von den Wordpress-Entwicklern wenig Hilfe zu erwarten ist. Die deutsche Community kümmert sich auch eher um das Sprachfile, wenn ich das richtig mitbekommen habe, als um Wordpress-Systeminterna. Da php-gettext allerdings einen Kompromiss zwischen Performance und Portabilität darstellt und es ganz offensichtlich Probleme mit diesem Kompromiss gibt, würde ich mir persönlich wünschen, dass man als User eine Wahlmöglichkeit zwischen php-gettext (bessere Portabilität, schlechtere Performance, Bugs) und gettext-Extension (bessere Performance, stabilerer Code, schlechtere Portabilität) bekommt.

    Zitat von misfit

    Oha,hatte ich das mit dem DAU erwähnt?
    Aber bevor ich mich abstrample: damit ist der Admin-Bereich deutsch, ja?

    Der Admin-Bereich und die Datumsangaben im Frontend, korrekt.

    Bzgl. gettext-Installation: Welches Betriebssystem und ggf. welche Distribution in welcher Version läuft denn bei Dir? php ist nach meiner Erfahrung auf den meisten Linux-Versionen mit gettext-Unterstützung kompiliert - das sollte also bereits funktionieren. gettext selbst muss ggf. noch installiert werden, sofern es auf dem System noch nicht vorhanden ist. Wenn Du nicht Admin Deines Servers bist, kannst Du entweder den Admin bitten, das Paket für Dich zu installieren oder Du musst auf eine Lösung mit gettext.php hoffen - letzteres ist im Grunde eine Alternative zum "richtigen" gettext, die für Systeme gedacht ist, auf denen das Original eben nicht zur Verfügung steht. Allerdings ist diese reine php-Lösung notgedrungen langsamer und - zumindest in meinem Fall - derart verbuggt, dass es nicht zu gebrauchen ist.

    Wenn es Dir nichts ausmacht, die Änderungen wieder rückgängig zu machen, kannst Du ja auch einfach ausprobieren, ob das ganze nicht bereits bei Dir funktioniert - einfach die eine Datei durch meine Version austauschen, die .mo-Datei umbenennen und in den korrekten Pfad legen und die wp-config.php anpassen.

    Viele Grüße

    Markus

    Es geht auch ohne gettext.php...

    Nachdem keine Lösung für das oben beschriebene Problem in Sicht ist, habe ich einen Workaround gefunden, mit dem man Wordpress von gettext.php wieder auf die php gettext Erweiterung umstellen kann. Nach der Umstellung funktioniert das Sprachfile bei mir. Ich habe bis jetzt keine Nachteile entdeckt, lasse mich aber gerne eines besseren belehren, falls jemandem noch eine andere Lösung einfällt. Zumindest einem interessanten Blog zu Folge sollte die Extension-Methode sogar einen Performancegewinn gegenüber der gettext.php-Lösung bringen - wenn die Extension auf dem System funktioniert (PHP muss mit gettext-Support kompiliert, gettext muss installiert und die locale auf dem System verfügbar sein), dann müsste dieser Workaround also eigentlich der Standardlösung vorzuziehen sein.

    Zuerst muss wp-includes/wp-l10n.php durch folgendes ersetzt werden:

    Die leeren Funktionen müssen erhalten bleiben, damit Wordpress weiterhin funktioniert.

    Danach legt man ein Verzeichnis wp-includes/locale/de_DE.UTF-8/LC_MESSAGES/ an (für UTF-8-Support) bzw. wp-includes/locale/de_DE/LC_MESSAGES/ (für ISO-8859-1). In dieses Verzeichnis kopiert man die de_DE.mo und benennt sie um in wordpress.mo.

    Zuletzt muss noch die wp-config.php angepasst werden. Bei Verwendung von UTF-8 muss WPLANG folgendermaßen gesetzt werden:

    Code
    define ('WPLANG', 'de_DE.UTF-8');

    Bei Verwendung von ISO-8859-1 entsprechend mit

    Code
    define ('WPLANG', 'de_DE');


    Damit gettext funktioniert, muss das Paket auf dem System installiert sein. Unter Debian erledigt man das, sofern das Paket nicht ohnehin bereits vorhanden ist, mit

    Code
    apt-get install gettext gettext-base

    Weitere Informationen gibt's bei phpbar

    Viele Grüße

    Markus

    Zitat von MaD

    es ist genau anders herum ... die deutsche Sprachdatei ist für den Adminbereich ... für das deutsche Frontend muss man ein deutsches Theme nutzen ...

    bin aber leider noch zu keinem Ergebnis gekommen, warum das so ist bei euch ...


    Du hast recht - es macht bei mir überhaupt keinen Unterschied, ob das .mo-File nun vorhanden ist oder nicht. Im Frontend werden zudem Datumsangaben in Englisch dargestellt, da dieser Bereich offenbar auch von der Sprachdatei übersetzt werden müsste. Ich habe mich ein wenig in wp-l10n.php umgesehen und in der Funktion load_textdomain()
    geprüft, ob Wordpress den korrekten Pfad zur Sprachdatei findet (passt) und ob die Datei für Wordpress lesbar ist (passt ebenfalls). Auch die Funktion get_locale() gibt den korrekten Wert aus der wp-config.php zurück.

    Ich habe auch einen anderen Tipp aus diesem Thread getestet und die .mo-Datei in de.mo umbenannt und danach wp-config.php angepasst - hat leider nichts gebracht.

    Als nächstes habe ich die fragliche Stelle in gettext.php angesehen. Mein "Patch" macht leider offenbar nichts anderes, als sicherzustellen, dass bei die if-Abfrage (~Zeile 111) immer in den else-Bereich läuft - ($this->error = 1; return false;). Wenn ich dort versuche, $this->BYTEORDER selbst zu setzen (sollte auf einem nicht-64bit-System ja offenbar 0 sein), dann erhalte ich wieder die Fehlermeldung:

    Code
    [B]Warning[/B]:  unpack(): Type V: not enough input, need 4, have 0 in [B][...]/wp-includes/gettext.php[/B] on line [B]82[/B]
    
    
    [B]Warning[/B]:  unpack(): Type V: not enough input, need 4, have 0 in [B][...][/B][B]/wp-includes/gettext.php[/B] on line [B]82[/B]
    
    
    [B]Fatal error[/B]:  Maximum execution time of 30 seconds exceeded in [B][...][/B][B]/wp-includes/streams.php[/B] on line [B]60[/B]

    Ich habe leider zu wenig Know-How, um mich selbst weiter durch den Code zu wühlen, die eigentliche Funktionsweise der Sprachdatei ist weiterhin eine Black Box für mich. Wie könnte ich denn weiter vorgehen, um das ganze zu debuggen?

    Server Version: Apache/1.3.33 (Debian GNU/Linux) JRun/4.0 mod_gzip/1.3.26.1a PHP/4.3.10-16 mod_ssl/2.8.22 OpenSSL/0.9.7e

    register_globals = Off
    magic_quotes_gpc = Off
    magic_quotes_runtime = Off

    Ich habe testweise den installierten eAccelerator deaktiviert, dann komplett aus der php.ini auskommentiert, das Ergebnis blieb das gleiche.

    Viele Grüße

    Markus

    Zitat von misfit

    Aber bei MarkusW ging's dann danach mit deutsch, oder hatte ich das falsch verstanden? Ich mein, immerhin komme ich rein, aber mit deutsch tät ich mir extrem leichter (hoff ich).

    Das Admin-Interface ist bei mir nach wie vor Englisch, ich bin bislang davon ausgegangen, dass sich die deutsche Übersetzung aufs Frontend beschränkt.

    Selbes Spiel nach Upgrade von 2.0.3 auf 2.0.4

    Da sich die gettext.php geändert hat, muss wie zu Beginn dieses Threads beschrieben erneut gepatcht werden - zumindest auf meinem Debian Sarge System erhalte ich anderenfalls wieder die altbekannte Fehlermeldung

    Code
    Warning: unpack(): Type V: not enough input, need 4, have 0 in ..../wp-includes/gettext.php on line 82


    Mit folgender Änderung funktioniert es bei mir:

    Code
    108a109
    >     $MAGIC3 = (int)  2500072158; // ÄNDERUNG 64 BIT
    112c113
    <     if ($magic == ($MAGIC1 & 0xFFFFFFFF)) { // to make sure it works for 64-bit platforms
    ---
    >     if ($magic == (( $MAGIC1 || $magic == $MAGIC3 ) & 0xFFFFFFFF)) { // to make sure it works for 64-bit platforms


    Für Menschen, die keine diffs mögen, gibt's hier den betreffenden Codeabschnitt der funktionierenden Version:

    Ich habe übrigens kein 64-bit-System:

    Code
    # uname -a
    Linux WEB-01 2.4.27-2-686-smp #1 SMP Wed Aug 17 10:05:21 UTC 2005 i686 GNU/Linux


    Viele Grüße

    Markus