Mehrsprachigkeit WordPress Plugins

Aus aktuellem Anlass (Erstellung meines ersten WordPress Plugins GarageSale) habe ich mich auch mit dem Thema Multilingualität und Übersetzungen auseinandergesetzt (Jetzt weiß ich auch woher I18N kommt – 18 Buchstaben zwischen i und n im Wort internationalization ;-)

Grundsätzlich muss die zu übersetzende WordPress Komponente natürlich die Funktionen __(„text“,“domain“) oder _e(„text“,“domain“) verwenden. Siehe hierzu I18N for WordPress Developers.

WordPress stellt für die Übersetzung einige Werkzeuge auf dem Subversion Host bereit. Aber zunächst einmal ein Schritt nach dem Anderen.

Schritt 1 – Download der Tools für Windows

Da ich auf den Clients Windows einsetze habe ich mich dazu entschlossen auch die Entwicklungswerkzeuge für Windows (in meinem Fall noch das gute alte Windows XP aber es sollte keinen Unterschied machen) einzusetzen  und zu beschreiben.

Wir beginnen also mit dem Download von folgenden Komponenten:

Und danach installieren wird zunächst einmal alle 4 Programme mit dem Windows Installer.

Schritt 2 – gettext und php einrichten

Damit die Gettext Werkzeuge funktionieren sollten Sie noch zum Windows Pfad hinzugefügt werden. Dies kann man entwededer dauerhaft machen unter Systemsteuerung -> System -> Erweitert -> Umgebungsvariablen oder aber direkt vor dem Aufruf des Übersetzungswerkzeugs in der Commandshell.

Ich habe gettext einfach in das Standardverzeichnis c:\Programme\GnuWin32 installiert. Da die Utilities im Unterverzeichnis bin liegen muss also der vollständige bin Pfad hinzugefügt werden:

c:\Programme\GnuWin32\bin

Wie gesagt die Alternative lautet, direkt vor dem Aufruf der Übersetzungstools den Pfad in der Commandline mittels set PATH=%PATH%;c:\Programme\GnuWin32\bin hinzufügen.

Analog zu gettext wird dies mit PHP gemacht. Also falls php in das Standard-Verzeichnis c:\Programme\php installiert wird, dann muss dieses ebenfalls zur Umgebungsvariable Path hinzugefügt werden.

Schritt 3 – Entwicklerwerkzeuge von WordPress aus SVN holen

Um mit der Übersetzung zu beginnen benötigt man jetzt die Entwicklerwerkzeuge von WordPress. Diese holt man sich mittels Subversion (in unserem Fall komfortabel mit dem Tool tortoiseSVN) von der Adresse http://i18n.svn.wordpress.org/tools/trunk

Hierzu erstellt man am Besten ein leeres Verzeichnis (z.B. c:\Work\wp-i18n\) und dort drückt man die rechte Maustaste und wählt SVN Checkout. Im darauffolgendem Tortoise Fenster gibt man unter URL of repository http://i18n.svn.wordpress.org/tools/trunk und drückt auf OK.

Schritt 4 – WP i18n tool starten

Nach dem Checkout befinden sich jetzt die WordPress i18n Übersetzungs Tools im Verzeichnis c:\Work\wp-i18n. Wir öffnen nun ein Commandline Fenster und wechseln in diesen Ordner (wichtig, falls oben in Schritt 2 die Methode mit der dauerhaften Pfad Anpassung gewählt wurde, darf ein jetzt bereits schon offenes Commandline Fenster nicht weiterverwendet werden, da sich die Umgebungsvariablen Änderung nicht auf bereits geöffnete Fenster auswirkt!

Eine Eingabe des Kommandos xgettext sollte nun eine Informationszeile auswerfen ebenso wie eine Eingabe des Befehlst php -v. Falls dies nicht funktioniert, nochmal zurück zu Schritt 2 und prüfen ob die Pfade auch wirklich korrekt gesetzt wurden.

Nun kann die Übersetzung eines Plugins gestartet werden. Zu diesem Zweck muss folgendes Kommando ausgeführt werden: php makepot.php wp-plugin <Pfad des WordPress Plugins>

wp-plugin steht hierfür für den Typ des zu übersetzenden Objekts (in diesem Fall ein WordPress Plugin).

In diesem Beispiel übersetze ich mein eigenes Plugin welches sich im Pfad y:\ktzv-fischamend.at\www\wp-content\plugins\garagesale befindet.

Nach dem Fehlerfreien Durchlauf des makepot.php Scripts (zu erkennen an keiner Ausgabe) befindet sich nun eine pot Datei mit dem Namen des Plugins im aktuellen Verzeichnis (in diesem Beispiel garagesale.pot).

Schritt 5 – Mit POEdit die POT Sprach Datei editieren

Nun starten wir das Programm POEdit und öffnen die pot Datei. Um sie zu öffnen muss der Dateityp Filter auf *.* gestellt werden.

Nach dem Laden der pot Datei kann sofort mit dem Übersetzen begonnen werden. In der linken Spalte sind immer die Original (englischen) Begriffe zu sehen und in der rechten Spalte die bereits übersetzten (deutschen) Begriffe. Man wählt einfach den zu übersetzenden Begriff aus und tippt die Übersetzung in das unterste der Eingabefelder.

Vor dem Speichern sollten jetzt noch die Katalog Optionen angepasst werden. Diese finden sich unter dem Menüpunkt Katalog -> Optionen. Wird auf Deutsch übersetzt sollte nicht nur bei Sprache „German“ sondern auch bei Land „GERMANY“ ausgewählt werden (der Ländercode für Deutsch lautet nämlich üblicherweise de_de und nicht de_at, weil man übersetzt üblicherweise nicht extra ins Österreichische – obwohl das sicher witzig wäre ;-)

Nach dem Speichern findet sich dann zusätzlich zur geänderten Quellsprachdatei garagesale.pot (die jetzt auch die deutschen Übersetzungen enthält) eine Datei namens garagesale.mo. Dies ist die Datei, die für WordPress notwendig ist um das Plugin dann in der korrekten Sprache anzuzeigen.

Wie in dem Screenshot zu sehen, muss diese .mo Datei mit dem richtigen Namen in das Plugin Verzeichnis kopiert werden: <PluginName>-<Länder-und-Sprach-Code>.mo (in diesem Beispiel garagesale-de_DE.mo).

Schritt 6 – Hinzugekommene Begriffe und erneute Übersetzung

Wie das so ist, kommt man nach der fertigen Übersetzung drauf, dass man doch noch eine Funktionalität vergessen hat. Zu diesem Zweck muss man natürlich nochmals das makepot.php Script aus Schritt 4 starten. ABER VORSICHT!

Vor dem erneuten Start muss unbedingt die bereits übersetzte .pot Datei umbenannt werden in z.B. garagesale-translated.pot – Das Extraktionsscript überschreibt kommentarlos eine eventuell bereits bestehende <pluginname>.pot Datei!

Nach erneuter Erstellung der garagesale.pot Datei (in der sich nun auch die zusätzlichen, noch nicht übersetzten Begriffe befinden, können nun mit dem gettext Tool msgmerge die beiden .pot Dateien gemerget werden:

msgmerge -N [bereits-übersetzte-pot-Datei.pot] [neu-generierte-pot-datei.pot] > neue-Pot-Datei.pot

Nun befindet sich im aktuellen Verzeichnis eine Datei namens garagesale_new.pot die wieder mit POEdit um die zusätzliche Begriffe ergänzt werden kann und anschließend muss wieder die .mo Datei entsprechend der oben genannten Namenskonvention in das Plugin Verzeichnis kopiert werden.

 

 

Ähnliche Artikel:

Meine genutzten Plugins aus dem Eclipse Marketplace

Eclipse Marketplaces feiert den millionsten Downlaod eines Plugins. Die Top10 der Plugins sind mir gar nicht so unbekannt. Außerdem gibts weitere Plugintips.

Anlässlich der millionsten Installation eines Plugins über den Eclipse Marketplace seit Juni 2010 wollte ich hier ein wenig über die Top10 der gedownloadeten Plugins schreiben, sowie über die von mir eingesetzten Erweiterungen.

01. Subclipse

Subclipse steht in Konkurrenz zu Subversive, welches ich verwende. Auch wenn ich Subclipse schon selbst verwendet habe, bin ich doch überzeugter Subversive Nutzer. Wohl aber nur weil ich das Teil bereits gewöhnt bin.
http://marketplace.eclipse.org/content/subclipse

02. Maven Integration for Eclipse

Unverzichtbar für jedes Maven Projekt. Da ich selbst bei TrayRSS auf Maven setze komme auch ich nicht um m2e herum. Hier bleibt zu resumieren, dass einem das Plugin nicht davor bewahrt sich mit Maven selbst auseinander zu setzen, um das beste für seinen Build zu erzielen. Wer sich mehr mit Maven auseinandersetzen möchte, dem empfehle ich die Dokumentation auf der Maven Seite selbst: http://maven.apache.org/ Diese ist mMn gut aufbereitet. Für tiefersitzende Probleme ist vielleicht folgendes frei erhältliches EBook hilfreich: The Maven Cookbook. Es ist als PDF oder als HTML Version als direktes Nachschlagewerk vorfügbar.
http://marketplace.eclipse.org/content/maven-integration-eclipse

03. Subversive – SVN Team Provider

Das SVN Plugin meiner Wahl. Bisher durchaus ein Usabilitygraus in der Installation, hat der Market die Installation des Plugins erheblich vereinfacht. Subversive bietet nämlich die Möglichkeit über verschiedene Connectoren auf die Repositories zuzugreifen. Diese mussten aus lizenzrechtlichen Gründen über eine extra Installationsseite nachinstalliert werden. Der Market bietet nun nach Installation des Basis-Plugins eine eigene Auswahlseite auf der die gewünschten Connectoren gewählt werden können, sodass Eclipse diese dann ohne weiteres zutun des Benutzers installiert.
http://marketplace.eclipse.org/content/subversive-svn-team-provider

04. EGit – Git Team Provider

„Neu“ in der Familie der meiner Plugins ist EGit. Da ich Git noch nicht sehr lange als Versionierungsverwaltung nutze, und erst langsam auf den Geschmack von Git und Github gekommen bin, beschränkt sich meine Erfahrung mit dem Plugin auf ein paar Feldversuche. Git selbst hat mich bereits überzeugt. Und in Zusammenhang mit Open Source finde ich hat Git alle Trümpfe in der Hand. Das Plugin selbst ist etwas komplexer aufgebaut, lässt aber auf den ersten Blick nichts missen. Als Unterstützung für Git-Einsteiger ist es jedoch im Gegensatz zu den SVN-Plugins meiner Meinung nach nicht geeignet. Hier führt der Weg an einem Kommandozeilenbasierten Einstieg nicht vorbei.
http://marketplace.eclipse.org/content/egit-git-team-provider

05. Spring IDE

Dieses Plugin habe ich bisher noch nicht genutzt. Equivalent dazu sind wohl die JBoss Tools. Um Spring Anwendungen zu entwickeln greife ich selbst noch auf die Pluginsammlung von MyEclipse zurück (u.a. die MyEclipse Spring Tools), welche von meinem Arbeitgeber zur Verfügung gestellt wurde.
http://marketplace.eclipse.org/content/spring-ide

06. Eclipse Color Theme

Dieses Plugin nutze ich ebenfalls nicht. Ich habe mir im Zuge dieses Artikels die Funktionsweise des Plugins angesehen, denke aber dass ich es weiterhin nicht einsetzen werde. Ich war bisher noch nie der Typ Mensch, der seine Fenster farblich komplett neu coloriert und muss daher auch den Inhalt des Editors an nichts anpassen.
http://marketplace.eclipse.org/content/eclipse-color-theme/metrics

07. PyDev – Python IDE for Eclipse

Jeder der schon mal in Eclipse eine Python Anwendung entwickelt hat kommt an diesem Plugin eigentlich nicht vorbei. Auch ich nicht. Ich habe damit z.B. Pong programmiert. Mag es zum Python Entwickeln nicht mehr missen, auch wenn die mit Python mitgelieferte IDLE Entwicklungsumgebung durchaus auch seinen Charm und seine Einsatzzwecke hat.
http://marketplace.eclipse.org/content/pydev-python-ide-eclipse

08. FindBugs Eclipse Plugin

Dieses Plugin habe ich aktuell ebenfalls nicht im Einsatz. Das sollte ich allerdings nochmal gründlich überdenken. Erste Versuche damit vor mehr als einem Jahr waren eigentlich ein für meinen Code interessant Erlebnis. FindBugs versucht mittels prüfen auf Bug Pattern Fehlerquellen im Code zu identifizieren durch z.B. falsch genutzte API Aufrufe. Vielleicht gebe ich dem Plugin bald mal wieder einen Versuch.
http://marketplace.eclipse.org/content/findbugs-eclipse-plugin

09. Google Plugin for Eclipse

Mit diesem Plugin habe ich leider noch keine Erfahrung und kann daher nicht viel dazu sagen. Am besten selbst mal nachlesen.
http://marketplace.eclipse.org/content/google-plugin-eclipse

10. JBoss Tools (Helios)

Als ich damals für eine Übung an der TU mit JBoss Seam entwickeln musste hab eich die JBoss Tools kennen gelernt. Sie sind eine mächtige Sammlung an Tools für das Entwickeln von Webanwendungen. Dabei habe ich aber auch ein paar Grenzen kennengelernt. So erzeugen die JBoss Tools in Fundament gegossene Projektstrukturen, was einem späteren Einsatz der Tools auf bereits vorhandene Projekte etwas erschwert. Dennoch bieten sie genug positive Funktionalitäten um derartige Hürden zu überwinden. Und sie sind natürlich perfekt auf den JBoss Server zugeschnitten ;)
http://marketplace.eclipse.org/content/jboss-tools-1

Aus den Top10 habe ich somit bereits 8 Verwendet und verwende 6 immer noch, lediglich 4 weitere Plugins kommen bei mir bewusst zum Einsatz:

Checkstyle

Dieses Plugin dient zur Code Analyse und unterstützt den Entwickler bei der Einhaltung von Coding Conventions.
http://marketplace.eclipse.org/content/checkstyle-plug

GitHub Mylyn Connector

Um Mylyn mit den Github Issues kurzzuschließen
http://marketplace.eclipse.org/content/github-mylyn-connector

Android Configurator m2e

Um Maven mit der Android Entwicklung zu verbinden
http://marketplace.eclipse.org/content/android-configurator-m2e

Android Developement Tools

Die Entwicklungstools für Android sind nicht Teil des Marketplaces sondern direkt zu beziehen:
http://developer.android.com/sdk/eclipse-adt.html

Leider ist der Eclipse Marketplace noch nicht für Eclipse 4.x vorhanden. Auf diese Version bin ich im Zuge des Releases von Java 7 umgestiegen. Wenn jedoch der große Umstieg bevorsteht hoffe ich ihn auch darin wieder nutzen zu können.

Ähnliche Artikel:

Back again – WordPress Plugin deaktivieren ohne WP

Hat man sein Wordpress durch ein Plugin zerschossen und kann es nicht mehr über WP ausschalten, helfen die hier beschriebenen Kniffe beim Plugin deaktivieren.

Wordpress Logo Wir sind wieder da, und wie könnte es anders sein, nicht ganz problemlos. So macht mir ein Plugin am neuen Server Probleme, indem es eine Endlosschleife generiert. Dummerweise bei jedem Login, ein deaktivieren des Plugins über das Backend ist somit nicht möglich.

Es kann schon mal vorkommen, dass man WordPress im Übereifer mit einem Plugin lahmlegt, da braucht man noch nichtmal einen Serverumzug dafür. Drum kurz eine Auflistung der Möglichkeiten die Plugins zu deaktivieren:

wp-content/plugins umbenennen

Die Plugins werden von WordPress im Verzeichnis wp-content/plugins abgelegt. Benennt man dieses Verzeichnis um werden sie beim nächsten Aufruf von WordPress nicht gefunden. WordPress deaktiviert daraufhin alle Plugins und lädt normal. Wird der Ordner wieder zurück umbenannt, sind die Plugins wieder aktiv.

pluginverzeichnis umbenennen

Möchte man nur ein Plugin umbenennen und hat keinen direkten Zugriff zur Datenbank kann man auch nur das Verzeichnis des jeweilgen Plugins umbenennen. Dadurch wird nur dieses Plugin deaktiviert.

alle per SQL Statement

Hat man zugriff auf die Datenbank können alle Plugins per SQL Aufruf deaktiviert werden. Dazu muss man folgendes Statement absetzen. Der Tabellenname wp_options muss natürlich noch angepasst werden.

update wp_options set option_value=’’ where option_name=’active_plugins’

Dadurch wird der bisherige Wert mit nichts (set options_value=’’ – zwei einzelne Anführungszeichen)  ersetzt und alle Plugins sind deaktiviert.

einzelne per SQL Statement

Will man hier nur ein einzelnes Plugin deaktivieren bedarf es schon gezielterer Eingriffe. Ist das vorige Update noch mit einer Holzhammer Methode zu vergleichen muss man den String der unter active_plugins verborgen ist mit einem Skalpell zerlegen um nur ein einzelnes Plugin abzudrehen.

Als erstes holen wir uns den Wert der zur Zeit unter active_plugins gespeichert ist:

select option_value from wp_options where option_name=’active_plugins’;

Dabei bekommen wir beispielhaft folgenden String zurück:

a:3:{i:0;s:25:“plugin-one/plugin-one.php“;i:1;s:25:“plugin-two/plugin-two.php“;i:2;s:29:“plugin-three/plugin-three.php“;}

Der Aufbau des Strings ist wie folgt:

a:3 zeigt an, dass es sich um einen Array mit 3 Elementen handelt. Jedes Element wird über seinen Index gefunden. In unserem Fall a:3 gibt es also drei Elemente mit den Indexwerten 0 bis 2: i:0, i:1 und i:2

Nach jedem Indexwert steht der eigentliche Inhalt des Array. Dabei wird erst noch ein wenig Meta-Information angeliefert. s steht hierbei für String, die Zahl zeigt die Zeichenanzahl des Strings an.

Möchte man nun zum Beispiel plugin-two deaktivieren sind folgende Schritte notwendig:

Zuerst muss man den Array kürzen, aus a:3 wird a:2

Das zu entfernende Plugin muss rausgenommen werden, folgender Textteil wird ausgeschnitten: i:1;s:25:“plugin-two/plugin-two.php“;

Damit das Array nun wieder konsistent ist, müssen final noch die anderen Indexe angepasst werden: i:2 wird zu i:1

Den neuen Gesamt-String stecken wir dann wieder in die Datenbank:

update wp_options set option_value=
’a:3:{i:0;s:25:"plugin-one/plugin-one.php";i:1;s:29:"plugin-three/plugin-three.php";}’
where option_name=’active_plugins’

Und schon ist das einzelne Plugin deaktiviert.

So ich hoffe das hilft!

So long, have fun!

Quelle: http://www.buildblog.de/2009/04/03/wordpress-plugins-manuell-deaktivieren

Ähnliche Artikel: