Warum ich Sprach-Plugins anbiete – und selten bei Community-Übersetzungen mitwirke

Kurz und bündig: weil es sehr viel Sinn ergibt – und praktischen Nutzen.

Ich habe schon manchmal bei Community-Übersetzungen mitgewirkt, also direkt auf Community-Portalen zum sofort loslegen (mit dem übersetzen), zum Beispiel bei einigen wenigen Programmen für Linux (Ubuntu), bei der deutschen Version von “Hootsuite” und natürlich auch bei einigen Sprachdateien für WordPress bzw. dessen Plugins. Früher sogar im Bereich konfessioneller Popularmusik, damals noch ohne Portale, dennoch um viele Erfahrungen reicher.

Mein Jetpack Sprach-Plugin bei WordPress.org

Trotz dieser Mitwirkungen und mehrheitlich positiven Erfahrungen biete ich derzeit öffentlich einige Sprach-Plugins für diverse WordPress Plugin-Projekte an – und werde dies noch ausbauen.

Einige Leute aus der deutschsprachigen WordPress-Community fragen mich immer mal wieder, warum ich das tue und nicht die bestehenden Sprachdateien, zum Beispiel für “Jetpack”, mitpflege und dort Korrekturen etc. beitrage. Gute Frage, hehe! :)

Meine Gründe:

Gefallen

Mir gefallen einfach viele Community-Übersetzungen nicht. Punkt.

Konsistenz

Übersetzungen sollten immer konsistent sein, zumindest nach meiner Überzeugung für solch eine Art Software wie WordPress bzw. dessen Plugins/ Themes. Gleiches sollte, wenn möglich, immer gleich übersetzt werden. Natürlich muss der Kontext berücksichtigt werden, doch das Grundprinzip bleibt. Bei den Community-Übersetzerportalen bleibt die Konsistenz bisweilen recht großflächig auf der Strecke. Leider.

Übersetzungsprinzipien

Übersetzungen haben aus meinen Erfahrungen und Überzeugung nur dann längerfristig die Chance, wenn sie nach klaren Übersetzungsprinzipien erfolgen. Die oben genannte “Konsistenz” kann ja auch nur ein Prinzip davon sein. Es gibt ganz sicher viele weitere. Ich brauche eine Art Geländer bzw. “Roadmap”, woran ich mich orientiere. Das WooCommerce Plugin hat derzeit 2.500 Strings, Jetpack etwa 1.200 aktuell, und WordPress selbst hat mindestens um die 3.500. Bei solch einer Menge an Texten braucht es eine klare Grundstuktur und Herangehensweise oder man wird am Ende viele Brüche, d.h. Stolpersteine oder Quellen für (Bedienungs-) Fehler haben. Fehlende Grundprinzipien könnten sogar am Ende in mehr Support-Aufwand münden – an welcher Stelle der “Kette” auch immer…

Grobe Linien

Wenn bei Jetpack zum Beispiel viele zig oder hunderte Übersetzer mitwirken, ist das erst einmal für sich genommen große Klasse und verdient Lob und Anerkennung! Allerdings werden oftmals nur kleine Übersetzungs-Schnipsel beigesteuert oder wenige Alternativvorschläge. Was fehlt bei dieser Art Schwarmübersetzerei, sind die groben Linien, die Grundprinzipien, der rote Faden halt; inbesondere für verschiedene Begriffe, Passagen oder ganze Grundlagen von Texten. Jetpack kommt im Original mit ziemlich legerer Slang-Sprache daher, die ich ungeignet für solche Plugins finde. Wortwörtliche Übersetzungen können schnell in die Irre führen. Manche Community-Übersetzer binden sich recht eng ans Original und finden deutsche, legere (Slang-) Begriffe. Andere Übersetzer vermeiden das und schleifen das Ganze “neutral” ab. Beides für sich ist vollkommen in Ordnung – nur ich möchte nicht Beides in ein und derselben Software-Übersetzung haben, oder dazu noch fünf weitere Prinzipien… Nein, wirklich nicht!

Unterschiedlicher Einarbeitungsstand

Nicht jeder Beitragende hat den vollen Übersetzungsstand vor sich und im Überblick, ist also nicht “eingearbeitet” in die Details. Zwar gibt es die Moderatoren – Validatoren genannt – die wohl eingearbeitet sein sollten und bestimmt auch sind. Diese schalten dann pro Sprache die Beiträge frei. Oft ist aber gar nicht mal klar, wer das im Einzelnen ist, und auch nicht, in welchen Zeiträumen das geschieht. Das hängt unter anderem mit dem nächsten Punkt zusammen:

GlotPress als Software in Teilen völlig ungeeignet

translate.wordpress.org, also die Polyglot-Übersetzer Webseite, verwendet als Software GlotPress. Die Software ist prima, und ich verwende sie sogar selbst für Community-Übersetzungen meiner Plugins. Allerdings gibt es auch entscheidende Nachteile: der Kontext fehlt. D.h. ich sehe nicht, wo genau die übersetzte Passage im Adminbereich oder in der Besucheransicht (Frontend) erscheint. Es wird nicht deutlich, wer Moderator ist, d.h. wer am Ende meine Übersetzung freischaltet und auch nicht, wann, d.h. in welchem Zeitraum. Auch Übersetzungsprinzipien sind keine bekannt – oder zumindest nicht öffentlich definiert?!? Weiterhin fehlt ein Community-Ansatz, im Sinne von Benachrichtigungen, (Direkt-) Nachrichtensystem usw. Ferner bietet GlotPress keine vernünftige Suche. Die integrierte Filter-Funktion ist zwar nett, aber fürs schnelle, viele Arbeiten damit ziemlich ungeeignet.

Als Alternative käme ein Dienst wie “Transifex” in Frage, der nach Freemium-Modell arbeitet und einige Schwachstellen von GlotPress ausbügelt, zum Beispiel, Integration/ Sichtbarkeit der Moderatoren, Benachrichtigungen usw. Das Problem des Kontextes meiner Übersetzungen kann auch Transifex nicht lösen, zumindest bislang nicht. Die Frage ist auch, wie sowas aussehen soll.

Ungünstiger Arbeitsfluss

Kontext heißt für mich direktes Testen meiner Übersetzungen, wenn möglich detailliert: wie passt es vom Platz her, wie wirkt der Text, ist er gut lesbar und verstehbar? Das geht nur, wenn man dies in WordPress selbst testet und damit interagiert. Am besten die Übersetzungen über längeren Zeitraum selbst verwenden und bei Kunden einsetzen und vielleicht ab und an mal konkret hachhaken…

Bei Plattformen wie translate.wordpress.org ist ein Testen, d.h. Ausprobieren meiner gerade angefertigten Übersetzung, fast nicht möglich, oder wenn, nur sehr umständlich. Es wäre nur möglich durch ständiges Exportieren, und re-Importieren von Übersetzungsdateien. Das wäre vielleicht noch hinnehmbar, jedoch nicht die Zeitfrage: ich weiß nie, wann meine Übersetzungen oder Korrekturen bestätigt werden – falls überhaupt (was auch völlig ok wäre!).

Ich werde mich sicherlich nicht zwei, drei Tage lang hinsetzen und die – aktuell – ca. 1.200 Strings von Jetpack übersetzen, bzw. überarbeiten und optimieren, um dann einige Stunden, Tage oder Wochen auf eine Freischaltung zu warten. Nur, um drei Tage später festzustellen, dass jemand anderes große Teile meiner Übersetzungen bereits erneut überarbeitet hat… Das wäre zwar Sinn und Zweck von Community-Übersetzungen, aber da keiner (so richtig?) voneinander weiß, endet das irgendwann unweigerlich im Chaos…

Außerdem wäre der Arbeitsfluss nur sinnvoll, wenn man eben Moderator wäre und damit das Recht hätte, gleich die gesamte Sprachdatei neu zu importieren. Es wäre jedoch ziemlich anmaßend, sich hier überall einzumischen und alles durcheinander zu bringen.

Ja, es hat durchaus mit Kontrolle und Kontrollverlust zu tun. Damit wären wir aber wieder bei den Übersetzungs-Grundprinzipen: ein kleines Team, welche diese Prinzipien selbst “atmet” und an der Sache arbeitet, kann nach meiner Auffassung in vielen Fällen weitaus bessere Ergebnisse hervorbringen, als Unmengen von Schwarmübersetzern, die “unorganisiert” an derselben Sache wirkten. Für mich drängt sich der “Wikipedia vs. Lexika”-Vergleich durchaus auf: die Wikipedia als solche ist sicher sehr gut, aber in nicht wenigen Fällen sind klassische Lexikonartikel einfach besser, sprich: neutraler, besser recherchiert und belegt – und meist auch besser geschrieben. Das heißt nicht, dass ich nur ein Lexikon hernehmen würde, absolut nicht, aber ein Buch-Vergleich mit der Wikipedia kann ab und an durchaus höchst willkommen sein :-).

Weitere Gründe von mir sind konkrete Vorteile und Nutzen von Sprach-Plugins:

Ein Plugin ist eben ein Plugin: ich kann es jederzeit aktivieren oder deaktivieren. Damit habe ich diesen Vorteil quasi genau für die Übersetzungen. Bei meinen Plugins kann man in der Regel zwischen Du- und Sie-Version wählen. D.h. auf einer Webseite könnte ich die formelle, auf einer anderen die informelle Version verwenden. Beides wäre dieselbe Übersetzung, gleiche Konsistenz usw., eben nur die andere Anrede.

Außerdem können solche Sprach-Plugins auch unabhängig vom “Mutter-Plugin” aktualisiert werden, d.h. im laufenden Betrieb. Damit hängen die Übersetzungen nicht immer lange Zeit hinterher, bzw. ein oder mehrere Versionen. Auch kann man so gut auf Fehlerkorrekturen usw. reagieren.

Über Sprach-Plugins können auch Fehler des Original-Plugins “ausgeglichen” werden, zum Beispiel wenn falsche Textdomains gesetzt wurden oder dergleichen. Außerdem ist es möglich, gleich Übersetzungen für Add-On-Plugins (Erweiterungen/ Extensions) mitzuliefern. Beispielsweise liegen bei meinem Jetpack Sprach-Plugin schon 3 Add-On-Übersetzungen bei, bei dem WooCommerce Sprach-Plugin sogar über 20! :)

Ein Sprach-Plugin kann bereits vor dem Mutter-Plugin aktiviert werden, damit beim Installieren/ Aktivieren des letzteren bestimmte Werte – die in den Übersetzungen stecken – gleich vernünftig gesetzt werden. Bei WooCommerce sind dies beispielsweise die Permalinkteile (sogen. Slugs), zum Beispiel für “/warenkorb/” und “/kasse/”. Somit spart man sich unschöne Permalinkfehler und dort ein erneutes Speichern (bzw. lange Fehlersuche… :).

Desweiteren kann ein Sprach-Plugin zusätzlich alternative Pfade anbieten und “abarbeiten”, wo der Anwender individuell angepaßte Übersetzungen ablegt, die dann alternativ geladen werden. Das ist sehr benutzerfreundlich und eine Möglichkeit, das “Problem” von strikt individiualisierten oder projektbezogenen Übersetzungen anzugehen. Angepaßte Übersetzungen eines Mutter-Plugins – in dessen mitgeliefertem Sprachdateienordner – würden bei Aktualisierungen des Mutter-Plugins immer überschrieben. Die alternativ-Orte eines Sprach-Plugins dagegen sind Update-sicher und werden nicht angetastet.

Jeder ist frei!

Am Ende ist die Verwendung eines Sprach-Plugins völlig freigestellt: jeder entscheidet selbst! Noch ein weiteres Plugin oder doch lieber die Community-Übersetzungen? — Bei WordPress ist außerdem die Menge der Plugins nicht entscheidend, es kommt auf die Qualität des Codes an, nicht die Anzahl der Plugins. Leider wird das noch vielfach anders “gelehrt”, dennoch!

Mein Fazit

Aus meiner Sicht bieten Sprach-Plugins jede Menge Vorteile und echten praktischen Nutzen. Die Nutzer meiner Plugins sehen das genauso, wie ich aus ganz vielen persönlichen Rückmeldungen weiß. Sprach-Plugins sind sicher nicht die Lösung aller “Probleme” und eben eine Möglichkeit unter vielen. Allerdings, und das sage ich ganz offen, sehe ich in den derzeitigen Übersetzer-Portalen nur ganz am Rande eine Möglichkeit, mich sinnvoll und vor allem nachhaltig einzubringen. Wäre es nicht so, würde ich dort ganz sicher sehr viel Zeit und Nerven lassen und die Ergebnisse wären aus meiner Sicht bescheiden. Ich brauche meine Sprach-Plugins und viele andere Anpassungen jeden Tag im Selbsteinsatz und im Einsatz bei meinen Kunden, ich möchte keine Zeit verlieren, auf Moderatoren-Freigaben zu warten oder durch ungünstigen Arbeitsfluss mich irgendwo verheddern. Wenn schon die zusätzliche Zeit und Arbeit für konsistente Übersetzungen investiert wird, dann bitte so effektiv und zielgerichtet wie möglich – für den schnell verfügbaren und funktionierenden Praxiseinsatz vor Ort!