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:

HOWTO: Git Commands – ein Überblick

Ein Überblick über die wichtigsten Kommandos in Git zur Versionsverwaltung. Branchen, Taggen, an den Server senden. Alles ist abgedeckt

Von Git hab ich hier ja schon ein paar mal geschrieben. Gestern war dann sogar ein Howto für den eigenen Git Server an der Reihe. Damit wir nun auch damit arbeiten können möchte ich hier kurz und knackig die wichtigsten Git Befehle anführen:

Allgemein

Um ein komplett neues Projekt lokal anzulegen, erst das Verzeichnis anlegen, dann in das Verzeichnis wechseln und abschließent Git initialisieren

$ git init

Um das Repository auszuchecken

$ git clone gitosis@example.com:repository.git

Um zu sehen was sich lokal getan hat und noch nicht commited wurde

$ git status

Um Änderungen lokal zu commiten

$ git commit -am „Commit Description“

Das Git log ansehen

$ git log
$ git log –pretty=oneline
$ git log –date=short –pretty=format:“%ad: %s“ –since=“4 month ago“

Um zu sehen was sich am Server getan hat

$ git log –no-merges origin/master

Um den eigenen Datenbestand mit den letzten Änderungen vom Server abzugleichen:

$ git fetch origin
$ git merge origin/master

$ git pull origin master

Um seine Änderungen auf den Server zu laden in den Master-branch

$ git push origin master

Branches

Einen Branch anlegen oder zu ihm wechseln

$ git checkout -b branchname

Auf einen Branch wechseln (Legt keinen neuen an wenn nicht vorhanden)

$ git checkout branchname

Einen Branch auf den Server laden

$ git push origin branch

Einen Branch mit dem aktuell ausgecheckten Branch mergen

$ git merge branchname

Einen Branch lokal löschen

git branch -d branchname

Einen Branch am Server löschen

$ git push origin :branchname

Tags

Einen Tag anlegen

$ git tag -a tagname -m „tag description“

Einen Tag zum Server schicken

$ git push origin tag tagname

Alle Tags zum Server schicken

$ git push origin –tags

Einen Tag löschen

$ git tag -d tagname

Einen Tag am Server löschen

$ git push origin :tagname

Commitverwaltung

Ein Commit zurücknehmen

$ git reset –hard HEAD^

Mehrere Commits zurücknehmen (zB 3)

$ git reset –hard HEAD^^^
$ git reset –hard HEAD~3

Patch für Server erzeugen

$ git format-patch origin/master

Patchfiles für letzten 3 Commits erzeugen

$ git format-patch HEAD^^^

Patchfile einspielen

$ git am < patchfile

Was vergessen? Ab in die Kommentare damit. Viel Erfolg beim Versionsverwalten!

Eine gute Quelle für den Einstieg in Git ist unter anderem: http://de.gitready.com/

Ähnliche Artikel:

HOWTO: Der eigene GIT Server mit Gitosis

Eine Versionsverwaltung gibt Stabilität, Kontrolle und vereinfacht die Arbeit im Team. Deshalb wird hier erklärt wie man seinen eigenen Git Server aufsetzt und konfiguriert.

Ich hab ja unlängst über die Vorzüge von Source Control Management Lösungen gesprochen. Deshalb möchte ich nun aufzeigen wie man sich selbst eine entsprechende Versionsverwaltung aufsetzt. Wir werden einen GIT Server aufsetzen und somit auf den Trend den Github und Co vorlebten aufspringen. Um eine einfache Verwaltung für den Zugriff von mehreren Usern auf verschiedene Repositories zu ermöglichen verwenden wir Gitosis

In diesem Tutorial setzen wir Gitosis auf dem neuesten Debian Squeeze Release, Version 6.0.3, auf. Dazu wurde das Betriebssystem in einer Virtual Machine aufgesetzt.

Zu erst installieren wir Git, den Kern unseres Tutorials:

# aptitude install git-core

Danach wird mit der Installation von Gitosis fortgefahren. Dabei könnten, so noch nicht installiert, diverse Abhängigkeiten zu Python installiert werden. Außerdem wird ein User mit dem Namen Gitosis, ebenso wie eine namensgleiche Gruppe und unter /srv/gitosis ein Homeverzeichnis für den User angelegt.

# aptitude install gitosis

Nach der Installation benötigt man einen ssh-rsa Key um sich als Administrator zu registrieren. Diesen benötigt man auf der Client Seite. Unter Windows ist dieser zB mit Puttygen zu erzeugen. Unter Linux wäre der Befehl:

ssh-keygen –t rsa –C “john@example.com

Dieser funktioniert auch in der Git Bash so man unter Windows auf msysgit zurückgreift.

Dabei werden 2 Files erzeugt: id_rsa (Private Key) und id_rsa.pub (Public Key).

Der Public Key wird nun auf den Linux Server transferiert, der Private Key bleibt nur am Client. Der Transfer kann mittels scp oder wget durchgeführt werden. Abgelegt sollte er unter dem Benutzernamen mit dem man am Server unterwegs ist in folgendes Verzeichnis: /etc/gitosis/sshkeys z.B. /etc/gitosis/sshkeys/theuser

Nicht vergessen darf man, dass man dem gitosis User alle notwendigen Rechte auf den Key verpasst:

# chown -R gitosis:gitosis /etc/gitosis/sshkeys

Möchte man das Homeverzeichnis des gitosis Users an einen anderen Ort legen kann man das wie folgt:

# mkdir /home/git

# usermod -d /home/git gitosis

Nicht vergessen rechte geben!

# chown -R gitosis:gitosis /home/git

Nun sind wir soweit, das Admin Repository kann angelegt werden. Gitosis verwendet nämlich ein eigenes Git Repository in dem alle Daten zur Erzeugung der individuellen Repositories und zur Steuerung der Rechte auf diese hinterlegt werden. Dazu wechseln wir auf den gitosis User

# su gitosis

und initialisieren dann den Dienst

$ gitosis-init < /etc/gitosis/sshkeys/thefake

Dabei müssten zwei Zeilen ausgegeben werden die in etwa so aussehen:

Initialized empty Git …
Reinitialized existing Git …

Hat der Server den SSH Port nicht wie standardmäßig auf Port 22 sondern z.B. auf 22222, muss am Client selbst unter ~/.ssh ein File mit dem Namen config angelegt werden. Dort trägt man dann den Host sowie den Port auf dem SSH zu finden ist ein:

Host 10.0.0.3
Port 22022

Nun steht dem initialen Auschecken des Admin-Repositories nichts mehr im Wege. Wir wechseln deshalb auf den Client, auf dem wir Git bereits installiert haben und holen uns das Repository folgendermaßen:

$ git clone gitosis@10.0.0.3:gitosis-admin.git

Dabei erhält man eine lokale Kopie der Configuratinsdatei sowie des Schlüsselverzeichnisses.

Um nun ein neues Repository anzulegen editiert man das Configurationsfile gitosis.conf mit einem Editor seiner Wahl und ergänzt es um folgende Zeilen

[group projektname]
writable = projektname
members = user@example.com

group benennt eine Gruppe von Usern, über die Kindattribute writable und members werden deren Rechte sowie deren Identitäten festgelegt. So kann im obigen Beispiel der Benutzer user@example.com auf das Projekt projektname zugreifen. Mittels Leerzeichen kann man hier mehrere User oder Repositories angeben. Mehr dazu später oder auf in der Gitosis Dokumentation zur Configurationsdatei.

Der Benutzer user@example.com benötigt einen public ssh-rsa Key der im Administrations-Projekt im Unterverzeichnis keydir hinterlegt werden muss. Dabei gilt die Namenskonvention <gitemailadresse>.pub

Erst commiten wir die neue Configuration ins lokale Repository

$ git commit -a -m „Added new repository ‚projektname'“

Anschließend wird die Configration auf den Server aufgespielt.

$ git push

Und schon können wir ein neues Projekt beginnen. Dazu erstellen wir ein neues Verzeichnis, initialisieren darin ein Git Projekt und legen eine erste Datei an.

mkdir projektname
cd projektname
git init
echo „This is a test file.“ > README
git add README

Nachdem wir das lokale Repository mit dem eben konfiguriertem Remote Repository verbunden haben commiten wir unsere lokalen Änderungen und laden diese auf den Server.

git remote add origin gitosis@10.0.0.3:projektname
git commit -a -m „Initial commit“
git push –all

Will man weitere Benutzer hinzufügen muss man deren Public Key wie vorhin beschrieben im Administrationsprojekt ablegen und fügt die Email Adresse in der Konfiguration einfach per Leerzeichen hinzu:

[group projektname]
writable = projektname
members = user@example.com another@example.com

Das ganze wird wieder commited und auf den Server gepushed, und schon ist der neue Benutzer berechtigt auf das Repo zuzugreifen.

Möchte man allgemeine Leserechte in einem Repository vergeben, ohne dass dazu ein User eingetragen werden muss, kann man dies individuell steuern indem man eine Kontrolldatei anlegt:

sudo touch /home/git/repositories/test.git/git-daemon-export-ok

Und fertig ist der Git Server. In einem weiteren Blogeintrag werde ich noch über die Installation einer Webmaske berichten. Also schaut mal wieder vorbei.

——–

Achja, sollte man noch nicht so fit mit Git selbst sein kann ich hier ein paar gute Links empfehlen:

Setting up Git (for Github)http://help.github.com/win-set-up-git/ Eine Installationsaleitung für Git unter WIndows. Die darin enthaltenen Informationen bezüglich User und User Email möchte ich nochmal hervorheben:

$ git config –global user.name “Firstname Lastname”

Damit setzt man den Namen seines Benutzers für alle Git Instanzen auf dem System

$ git config –global user.email „your_email@youremail.com

Dieser Befehl setzt die Email mit der auch über Gitosis der Key gematched wird. Sie dient somit als zentrales Element der Identifikation.

Generell sind die Github Manpages recht gute Quellen um sich mit Git vertraut zu machen.

Git Tutorials bei Kernel.org – http://web.archive.org/web/20110613161039/http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html

Leider derzeit offline, aber in meinen Augen der beste Überblick über die Befehle von Git, über die WayBackMachine noch erreichbar.

Wer sich vertiefend mit dem Thema auseinandersetzen will dem sein zwei Online Bücher ans Herz gelegt:

Git In The Trencheshttp://cbx33.github.com/gitt/ bzw der Source vom Buch auf Github https://github.com/cbx33/gitt

ProGithttp://progit.org/book/

Bis zum nächsten Commit!

Ähnliche Artikel: