Ich hatte euch ja schon angekündigt, dass ich euch ein paar Informationen dazu geben möchte, wie mir der Umstieg von qTranslate auf Multilingual Press gelungen ist.
Als ich von drei Jahren meinen Blog angefangen habe wollte ich gleich von Anfang an die Artikel in Deutsch und Englisch verfassen. Ich muss zwar zugeben, dass ich von den 126 deutschen Artikeln bisher nur 36 übersetzt habe, aber dennoch war mir diese Zweisprachigkeit wichtig, gerade im Hinblick auf die Plugin-Seiten. Zuerst einmal möchte ich euch erläutern, wieso ich den Wechsel vollzogen habe.
Stärken und Schwächen von qTranslate
Von allen Plugins, die damals verfügbar waren bot qTranslate die mit Abstand kompletteste Lösung für Mehrsprachigkeit an. Folgende positive Eigenschaften machen es auch heute noch zu einem tollen Plugin:
Stärken
- Einfache Installation und Einrichtung
- Keine besonderen Systemvoraussetzungen
- Zusammenarbeit mit vielen Plugins wie z.B. für SEO oder Suchen
- Übersetzung des gesamten Contents inkl. Feeds und Kategorien
- Auswahl Verschiedener Linkvarianten für Mehrsprachigkeit
- Erkennung der Browsersprache
- Ein Backend für alle Sprachen
- Kommentare in allen Sprachen eines Artikels gleich
- Lokalisierung des Backend über einfachen Umschalter
- … und vieles mehr
Aber wo Licht ist, da ist auch immer Schatten. Das Feature, dass z.B. Kommentare in allen Sprachen dieselben sind (es gibt einen Artikel ja auch nur genau einmal) kann auch negativ sein, wenn es sehr viele Kommentare gibt und die Nutzer ständig über die „falschen“ wegscrollen müssen um welche in der Sprache zu finden, die sie verstehen. Aber hier mal ein paar Gründe, die mich zum Wechsel bewegt haben:
Schwächen
- Kein SEO Permalink, da der Slug nur in einer Sprache möglich ist
- Nach Major-Updates folgt ein Update von qTranslate teilweise erst nach mehreren Tagen
- Die benutzerdefinierten Überschriften für Widgets lassen sich nicht übersetzten
- Abhängigkeit von der Weiterentwicklung des Plugins aufgrund der komplexen und etwas unsauberen Umsetzung der Mehrsprachigkeit
- … und einige wenige mehr
Das Problem mit den Updates war eines der weniger Kritischen für mich. Zum einen kenne ich die Syntax mit den notwendigen Kommentaren gut genug um selbst bei inaktivem Plugin noch korrekt einen Artikel zu erstellen und zum anderen kommen die Updates trotzdem sehr schnell. Man muss Qian Qin, dem Entwickler des Plugins, ja auch zugutehalten, dass er das Plugin nicht kommerziell vertreibt und dafür eine erstklassige Lösung bieten.
Sträken und Schwächen von Multilingual Press
Aber kommen wir jetzt noch zu Multilingual Press und den Gründen, wieso ich hierauf gewechselt habe. Das Plugin ist noch in der Entwicklung und einiges was ich hier als negativ aufliste wird wohl noch (eventuell nur in der Pro Version) kommen.
Stärken
- Umsetzung der Mehrsprachigkeit „mit Boardmitteln“ über die Multisite-Funktionalität
- Vollständige Übersetzbarkeit von Themes, Widgets, Kategorien, Schlagwörtern usw.
- Optimale SEO Eigenschaften durch Vermeidung von doppelten Titeln und Inhalten (bei fehlenden Übersetzungen)
- Möglichkeit verschiedene Themes zu verwenden, was besonders bei Sprachen mit Leserichtung von rechts nach links interessant sein könnte
- Keine Abhängigkeit von der Weiterentwicklung des Plugins, da jede Sprache für sich ein eigenständiger Blog ist
- … und einige mehr
Wie schon erwähnt fehlen in der aktuellen Version noch ein paar Features, aber einige Dinge machen die Arbeit mit dem Plugin auch so schwieriger. Hier mal ein paar Dinge, die mir persönlich noch fehlen:
Schwächen
- Keine Erkennung der Browsersprache (in Pro-Version enthalten)
- Nicht übersetze Artikel verlinken immer auf Startseite der anderen Sprache beim Umschalten
- Nur Verlinkung von Artikel aber nicht von Archivseiten wie für Kommentare oder Schlagwörter möglich
- Die Pflege des Kategorien, Schlagwörtern, Themes-Einstellungen, Widgets und Menüs erfordert es alle Schritte für alle Sprachen durchzuführen (Kopieren eines gesamten Blogs in eine neue Sprache in Pro-Version enthalten)
- Bei Verwendung von verschiedenen Top-Level-Domains muss man sich dafür mehrfach anmelden, selbst bei gleichen Benutzernamen und Passwort (ist aber eher ein generelles Problem von Multisite-Installationen und nicht direkt eine Schwäche von Multilingual Press)
- Keine Möglichkeit der Integration von Kommentaren anderer Sprachen
- … und einige mehr
Gerade in der Entwicklung des neuen Blog-Layouts war das Anpassen der Widgets, Menüs und der Theme-Einstellungen sehr mühsam. Aber diese strikte Trennung hat natürlich auch seine Vorteile. So gibt es vielleicht manche Seiten in einer Sprache nicht und man kann sie dann einfach in den Menüs weglassen. Genauso kann man auch die Widgets und damit z.B. auch Links zu andern Blogs und Werbung zielgerichtet einstellen.
Was mich persönlich am meisten stört ist die fehlende Verlinkung auf eine „Dieser Artikel ist nur in der Sprachen … zu finden“ Seite über den Sprachumschalter. Der Nutzer erwartet nämlich bestimmt nicht, dass er kommentarlos auf die Startseite umgeleitet wird. Aber dieses Manko kann ich ja eventuell noch mit einem eigenen Widget, das die Eigenschaften des mitgelieferten überschreibt, lösen.
So liebe Leser. Da der Artikel schon jetzt sehr lange geworden ist werde ich euch für heute die technischen Details ersparen, denn damit kann ich locker noch einmal zwei Artikel mit ähnlicher Länge schreiben. Die folgen dann in den nächsten Tagen und ich werde darin dann auch mein neues Plugin qTranslate Exporter beschreiben, dass ich im Zuge der Migration erstellt habe.
Wer sich jetzt nach dem Lesen fragt, ob er qTranslate für seinen Blog einsetzen sollte oder nicht, für den habe ich noch folgenden Rat: Wenn du nur über wenig technisches Know-How oder eingeschränkte Möglichkeiten bei deinem Hosting-Paket verfügst, dass dich an einer Installation eines Multisite Netzwerks hindert oder wenn du nicht innerhalb von einem Jahr mehrere hundert Artikel schreiben möchtest, dann ist qTranslate auf jeden Fall eine Überlegung wert. Wenn es dir aber um eine saubere Umsetzung geht, du ein Multisite Netzwerk installieren kannst und du aufgrund der noch nicht finalen Version von Multilingual Press auch experimentierfreudig bist, dann würde ich dir hierzu raten.
Update 10.10.2013: Einige der Schwächen von Multilingual Press sind mit erscheinen der Pro-Version behoben worden. Diese sind in der Aufzählung gekennzeichnet.
Habe für eine Website auch Multilingual Press eingesetzt und mit einem Theme umgesetzt.
Um eine sprachliche Trennung innerhalb eines Templates hinzubekommen, habe ich eine Abfrage der Blog-Id eingebaut. Etwas umständlich, aber dadurch kann ich alles in einem Theme ändern.
global $blog_id; if ($blog_id == 1) { //First blog links echo '<strong>Deutsche Seite</strong>'; } else { echo '<strong>Englische Seite</strong>'; }Vielleicht kennst Du einen Weg diese Abfrage kürzer zu fassen.
Generell sehe ich die Stärken und Schwächen genauso wie Du.
Den Sprung auf die Startseite finde ich aber nicht so schlecht, zumeist wird der User sich ohnehin nur innerhalb einer Sprache bewegen.
Autsch! Deine Lösung ist nicht wirklich so umgesetzt, wie man es tun sollte. Das Stichwort für die richtige Lösung heißt: I18n. Du solltest für Texte, die je nach Sprache übersetzt werden sollen, immer die Übersetzungsfunktionen von WordPress nutzen. Bei deiner Lösung müsstes du ja sämtliche Stellen, an denen eine Lösung wie deine exisitiert überarbeiten. Bei der Lösung mit den Übersetzungsfunktionen erzeugst du einfach eine neue Sprachdatei für die neue Sprache und übersetzt in dieser alle Texte einmalig. Eine kompakte Lösung sieht also z.B. wie folgt aus:
<strong><?php _e('English Page', 'your-theme-textdomain'); ?></strong>Hiermit würde dann immer der englische Text ausgegeben werden, solange keine Übersetzungsdatei der aktuellen Sprache exisitert oder in dieser der entsprechende Text noch nicht übersetzt wurde.
Solltest du anhand der Anleitung auf WordPress.org nicht weiterkommen, kannst du gerne noch einmal einen Kommentar hinterlassen.
Ich habe das ähnlich umgesetzt wie funkygog. Der Übersicht halber habe ich allerdings alle Übersetzungen in ein Array in einer Datei „lang.php“ gespeichert (sind ca. 20-30 Wortschnipsel für Navigation, Footer und anderen Kleinkram) und dann im Theme die Sprachdatei eingebunden und nur noch die Variable eingesetzt. Ich finde, das reicht doch vollkommen für eine geringe Anzahl von zusätzlichen Themeübersetzungen, oder nicht?
'Company',
'company_slug' => 'company',
'products' => 'Products',
'products_slug' => 'products',
'contact' => 'Contact',
'contact_slug' => 'contact',
'anyquestions' => 'Any Questions?',
'gtc' => 'General terms and conditions',
'findus' => 'How to find us:',
'largermap' => 'Larger map'
);
}
else
{
$lang = array ( /* etc */ );
}
?>
Hey Lukas,
dein Code ist irgendwie nicht ganz vollständig. Poste ihn doch einfach nochmal in einem neuen Kommentar, dann korrigiere ich ihn gerne oben.
Grundsätzlich sollte man bei Übersetzungen auf die Möglichkeiten von WordPress zurückgreifen. Das mag anfangs eine kleine Hürde sein, aber es bietet extrem viele Möglichkeiten. Schau die einfach mal die Seite Translating WordPress des Codex an. Dort wird das alles sehr gut erklärt.
Hallo Bernhard,
der obige Code war nur als Beispiel gedacht.
Wie würdest Du es lösen wenn Du für die unterschiedlichen Sprachen eigene Header-Grafiken verwendest oder verschiedene Kontaktformulare etc.?
Ein gutes Formularplugin sollte schon lokalisiert sein. Die Formulare werden aber ja bei Multisite auch pro Blog über das Backend definiert. Daher kannst du hier auch die Felder entsprechend beschriften.
Für das Header-Bild kannst du natürlich auch die Übersetzungsfunktionen benutzen. Also statt ein Wort zu verwenden, nutzt du einfach den Bildnamen als zu übersetzenden String. Soweit klar?
Interessant, an die Möglichkeit hatte ich noch nicht gedacht, werde das mal testen.
Vielen Dank
Mir fällt eigentlich gerade die beste Lösung für das Headerbild ein (wenn ich ein Theme-Entwickler wäre, dann wäre ich wohl sofort drauf gekommen):
Seit neuestem gibt es in WordPress den Customizer. Damit kann man im Backend Theme-Optionen anbieten. Eine davon ist eben genau das Headerbild. Näheres dazu findest du im WordPress Codex. Ich würde dir also diese Lösung empfehlen. Damit kannst du am saubersten ein indiviuelles Headerbild umsetzt und die Änderungen dabei sind direkt aus dem Backend möglich. Du musst also keine Übersetzungsdatei anpassen und es kann somit auch von einem normalen Backend-Nutzer (mit entsprechenden Rechten) durchgeführt werden.
Hallo Bernhard!
Mir ist folgendes bei qTranslate aufgefallen. Wenn ich qTranslate aktiviere wechselt die WP-Admin-Sprache auf englisch. Wenn ich qTranslate deaktiviere wechselt sie wieder ins spansche,, so wie es von vornerherein eingestellt ist.
Ist das ein normales Verhalten?
Würde mich über eine Antwort freuen.
Danke!
Ich denke ich weiß, wieso du diesen Effekt beobachtest. Im Backend bietet qTranslate ja in der Sidebar die Möglichkeit, die Sprache für das Backend zu ändern. Diese Einstellung wird dann für deinen Nutzer gespeichert. Ist qTranslate also aktiv, wird dieser gespeicherte Wert verwendet und die Sprache entsprechend geändert. Wenn du allerdings qTranslate deaktivierst, dann ist es nicht möglich, die Sprache des Backends zu ändern. Es verwendet dann die gleiche, wie das Frontend.
Genau dafür hatte ich dann auch mein Plugin Backend Localization geschrieben. Damit kannst du auch ohne qTranslate für das Backend eine andere Sprache verwenden als für das Frontend.
Danke für die Anwort, sie hat mich auf die richtige Spur gebracht.
Ich musste die Locale ändern unter: Settings > Languages > (Spanisch etc..) > edit, dann hat es funktioniert.
Danke noch mal.
Moin Bernhard,
vielen Dank für den ausführlichen Bericht. Mittlerweile hat sich MultilingualPress stark verbessert und auch einige der Punkte in der „Schwäche“-Liste zumindest in der Pro-Version http://marketpress.de/product/multilingual-press-pro/ behoben, wie z.B.:
– Keine Erkennung der Browsersprache
Kurze Frage zu „Nicht übersetzte Artikel verlinken immer auf Startseite der anderen Sprache beim Umschalten“ wo sollen die denn sonst hin verlinken? Oder meinst du übersetzte, denn das geht in der Pro, dort wird direkt zum übersetzten Beitrag verlinkt.
Das ist natürlich Schwäche aber auch Stärke: „Die Pflege des Kategorien, Schlagwörtern, Themes-Einstellungen, Widgets und Menüs erfordert es alle Schritte für alle Sprachen durchzuführen“. So kann man jede Seite komplett individuell gestalten. Aber in der Pro-Version kann man einzelne Seiten komplett mitsamt Inhalt, Menüs, Plugineinstellungen, Themeeinstellungen ganz einfach kopieren und schon muss man nur die Inhalte und Menüs übersetzen, das wars.
Dieses Problem habe ich noch nicht gehabt:
– Bei Verwendung von verschiedenen Top-Level-Domains muss man sich dafür mehrfach anmelden, selbst bei gleichen Benutzernamen und Passwort
Ich hoffe die vielen Vorteile von MultilingualPress überzeugen. Viele Spaß damit!
Hallo Alex,
wie du vermutlich gesehen hast ist der Aritkel schon etwas älter. Damals gab es die Pro-Version mit den beschriebenen Funktionen noch nicht. Als Early Adopter habe ich diesen geringeren Funktionsumfang aber trotzdem nicht gescheut und den Wechsel von qTranslate bisher nicht bereut. Ich habe mal in der Liste die Schwächen, die in der Pro-Version nicht existieren entsprechend markiert.
Zum Thema „nicht übersetzte Aritkel“: Bei qTranslate gab es ebenfalls ein Sidebar-Widget. Wenn man nun in einem Aritkel, der nicht übersetzt war, auf die andere Sprachversion wechseln wollte, dann kam eine Seite mit dem Text „Dieser Aritkel ist leider nicht in deiner Sprache erhältlich“ (oder so ähnlich). Man kennt dieses Verhalten auch von anderen Websites und würde es wohl auch so erwarten. Auf einer solchen Seite könnte man dann verschiedene Optionen anbieten (z.B. Übersetzen per Google Translate, zurück zur anderen Sprache navigieren, zur Startseite wechseln etc.). Ich habe diese Seite einfach bei Multilingual Press vermisst. Aber es gehört wohl in die Rubrik „It’s not a bug, it’s a feature“ 😉
Ich habe aber Robert das Problem schon geschildert und wir zwei sind auch auf ein paar Ideen gekommen, wie man das per Option den Nutzern anbieten könnte. Er hat den Feature-Request eventuell auch schon an euch weitergegeben.
Das mit der Anmeldung bei zwei Top-Level Domains ist für mich eigentlich logisch. Mein Multisite-Netzwerk läuft auch der .com Domain. Wenn ich mich also bei der .de Domain anmelde, dann wird ja nur für diese Domain ein Cookie mit dem Login gespeichert. Wenn ich dann ins Dashboard der .com Domain wechseln will, werde ich erneut nach dem Login gefragt. Oder habt ihr das Problem irgendwie clever lösen können? Dass es aber nicht ein Problem von Multilingual Press selbst ist, habe ich auch bei den Schwächen erwähnt.
Alles in allem bin ich aber sehr zufrieden mit Multilingual Press, gerade wegen der sehr sauberen Umsetzung der Mehrsprachigkeit. Die Pro-Version ist mir für meinen privaten Blog aber etwas zu teuer. Denn schon jetzt sind die Hosting-Kosten mehr als doppelt so hoch, wie die Einnahmen über Werbung oder sonstige Vergütungen.
Ich habe zwar mittlerweile mit über 20% sehr viele Leser, die nicht Deutsch als Sprache in ihrem Browser eingestellt haben, aber ich habe leider auch noch nicht die Zeit gefunden alle Artikel zu übersetzen. Die Leser außerhalb des deutschsprachigen Raums werden aber wohl über die Suchmaschinen auch meistens auf den englischsprachigen Artikeln landen. Daher kann ich mit den Einschränkungen der Free-Version auch noch gut leben. Aber wer weiß, wenn mein Blog bei den Zugriffszahlen weiter so stetig wächst… 😉
Gruß
Bernhard
P.S. Ich hoffe ihr hattet auch eine entspannte Rückreise. Aber du hattest es ja nicht ganz so weit wie wir nach Berlin.
Hey Bernhard,
ja, hab gesehen, dass der Beitrag ein wenig älter ist, wollte nur für die anderen Leser drauf hinweisen. 🙂 Danke für die Anpassung der Liste!
Wir sind gerade am refactoring des Codes dran. Dann kommen noch einige weitere tolle Funktionen hinzu.
Wegen dem nicht übersetzten Artikel, das ist eine gute Idee, werde ich noch mal anstoßen.
Wegen dem Login-Problem, gehe mal zu
Wenn du kein Domainmapping Plugin nutzt und in der config einfügst:
const COOKIE_DOMAIN = “;
Sollte es gehen. Siehe Anleitung hier: http://toscho.de/2013/wordpress-multisite-mit-mehreren-domains/
Dann musst du dich bei den Domains nur jeweils einmal anmelden.
Geht aber nur, wenn man kein www nutzt, was man heutzutage eigentlich nicht mehr braucht.
Unsere Rückreise war ziemlich entspannt, aber auch Gott sei Dank nicht so weit wie ihr. Ich freu mich schon euch wieder in Berlin zu sehen, dann hab ich die lange Anreise. 🙂
Hm, habe den Artikel gerade mal gelesen. Sehe ich das richtig, dass man das Plugin WordPress MU Domain Mapping nicht mehr braucht? In der Beschreibung dieses Plugins steht nämlich drin, dass man dann die Konstante COOKIE_DOMAIN nicht setzen darf.
Falls das so ist, werde ich es gleich mal am Wochenende testen. Da ich einen ROOT Server habe, kann ich die Domains alle auf ein Verzeichnis zeigen lassen.
@Bernhard, das siehst du richtig. 🙂
Hm, ich habe es mal getestet. Ich kann mich zwar dann im Backend für alle anderen Domains einloggen, aber ich habe zwei Probleme festgestellt. Ich kann mich nicht mehr ausloggen (es sei denn, ich lösche für alle Seiten die Cookies) und ich bin nur im Backend angemeldet. Wenn ich im Frontend bin fehlt die Adminbar und ich kann auch auf keinen Kommentar als eingeloggter Nutzer antworten.
Ich habe es daher wieder mit dem Domain-Mapping Plugin gelöst. Da muss ich mich dann zwar ab und zu nochmal für eine andere Domain einloggen, aber immerhin funktioniert dann alles.
Hätte ich das mal früher getestet, dann hätte ich toscho ja auf dem WP Camp gleich mal ansprechen können 😉
Ich kann das nicht bestätigen. Zwar muss ich mich bei beiden Domains separat anmelden, dann bleibe ich aber auch im Front- und Backend eingeloggt, sehe die Adminbar und kann jederzeit wechseln.
Ja, solange ich das Domain-Mapping Plugin einsetze funktioniert das alles bei mir genau so. Wenn ich aber wie von Alex angeregt das Plugin deaktiviere und die Konstante COOKIE_DOMAIN setze (wie in deinem Artikel beschrieben), dann kommt es zu dem beschriebenen Effekt.
Ich logge mich also genau wie du lieber bei beiden Domains separat ein, kann dann aber Front- und Backend normale nutzen.
Merkwürdig. Ich habe selbst für wpkrauts.com und .de Accept cookies only for the site I visit gesetzt, und es funktioniert. Jetzt müsste man mal die Cookies untersuchen und eventuell die Authentifizierung Schritt für Schritt in WordPress überwachen, um zu sehen, woran das liegt.
Ich kann mir als Fehlerquelle derzeit nur vorstellen, dass du für beide Sites unterschiedliche Salts benutzt.
Ich hatte ja extra mal sämtliche Cookies für alle Sites der Multisite-Installation gelöscht. Wo finde ich denn die Option „Accept cookies only for the site I visit“?
Aber so wie Axel gemeint hat, kann man sich dann nicht nur in einem Blog anmelden und sofort das Front- und Backend aller Blogs ohne zusätzliches Login nutzen?
Also wenn das doch irgendwie klappt und ich die Migration schaffe, schreibe ich auch gerne nen Artikel darüber 😉
P.S. Salts gibt es bei mit nur einmal in der wp-config.php der Multisite. Ich wüsste auch gar nicht, wo ich unterschiedliche angeben könnte.
Die Option solltest du in deinem Browser finden. IN Opera 12 in den Site preferences, ich weiß jetzt nicht, wie andere das handhaben.
Anmelden muss man sich in jedem Blog einmal. Da man im eigenen Blog ja ohnehin meistens angemeldet bleibt (Exremfall), finde ich das nicht so wichtig.
Danke für das PlugIn! Das hat mir heute ein Problem gelöst!
Ich bin Kau-Boy-Fan! 🙂
[…] Gründe für die Migration von qtranslate auf MultilingualPress […]
[…] Als ich meine Blog am 21. Juni 2009 gestartet habe, war es das Ziel, den Blog in Deutsch und Englisch zu betreiben. Damals habe ich mich nach einiger Recherche das Plugin qTranslate entschieden. Nach drei Jahren war ich aber mit dem Plugin nicht mehr zufrieden und habe eine Migration zu MultilingualPress durchgeführt. […]