Mein Blog.

WordPress Language Packs: Gute Hilfe oder Zwangsbeglückung?

Mit WordPress 3.7, dem nur vordergründig unscheinbaren “Plattform Update” wurden einige Weichen ganz neu gestellt im WordPress Universum, die noch viele Konsequenzen und Veränderungen mit sich bringen werden, u.a. sogenannte “Language Packs”.

Die essentielle Funktionsweise von “Language Packs” – oder auf gut Deutsch: Sprachpakete – ist schnell erklärt. Da werden bestehende Übersetzungen/ Sprachdateien von WordPress Plugins und Themes nun als ein eigenständiges Sprachpaket betrachtet. Quasi als extra “Einheit” (Entität). Und eben so ein Paket kann man dann auch gesondert aktualisieren, oder auf gut denglisch, “updaten”.

Ein ganzer Stapel Sprachpakete, oder was?

Ein ganzer Stapel Sprachpakete, oder was?

Ein Beispiel

Beispiel: Super-Duper-Plugin XYZ ist gerade in der Version 1.5.0 erschienen, es hat Übersetzungen für 3 Sprachen beigelegt. So weit, so gut. 2 Tage nach der 1.5.0-Veröffentlichung sendet ein Benutzer dem Entwickler eine weitere, neue Übersetzung ein. Der Entwickler packt diese dem Plugin bei, drückt ein Knöpfchen, und schwupp-di-wupp, liegt ein neues “Language Pack” für diese neue Sprache vor, d.h. ist als installierbares/ aktualisierbares Paket in meiner WordPress-Installation abrufbar. Die Plugin-Version bleibt auf 1.5.0 (statt wie früher 1.5.1 oder dergleichen), nur die Version der einen Sprache und/ oder aller Sprachpakete (für jede Sprache/ Übersetzung ein Paket) ändert sich.

Klingt erst mal super-duper einfach, nützlich, schlicht genial. Werde ich sicherlich als Plugin-Herausgeber auch nutzen und begeistert sein. Und es hat durchaus seine Praxisvorteile. Insbesondere für kleinere Helfer-Plugins…! Ich muss nicht wegen einer neuen Übersetzung, oder der Aktualisierung einer Bestehenden, das ganze Plugin als neue Version veröffentlichen. Das hat schon was, echt!

Manuell gepflegte Übersetzung vs. Automatische Aktualisierungen

Problematisch wird es aus meiner Sicht für größere Plugins, und insbesondere bei denen, die bereits im translate.wordpress.org Übersetzerportal beheimatet sind: jeder Druck aufs virtuelle Knöpfchen haut die Aktualisierungen für die Sprachpakete raus, ohne wenn und aber (es sei denn eine Installation hat das manuell via Filter abgesellt – via manuellem Webmaster-Eingriff!). Ganz egal, ob die jeweiligen Übersetzungen gerade vervollständigt, verbessert oder eben verschlimmbessert wurden. Beim Anwender zuhause im gemütlich eingerichteten WordPress – bzw. BuddyPress, Jetpack, oder was auch immer – wird dann heimlich still und leise die Übersetzung ausgewechselt. Schaut der Webmaster am Morgen wieder rein in seine tolle Community, könnte er das Sprach-Dillemma schnell entdecken: Gestern war da noch eine im Handbetrieb optimierte, projektbezogene Übersetzung, heute schon die von den Schwarmübersetzern zusammengepuzzelte, inkonsistente, automatisierte Sprachpaket-Version…?!?

Ich weiß, ich weiß, das klingt jetzt nach Panik und Schwarzmalerei. Aber so ist es nun mal mit des Pudels Kern. An dieser Realität kommt man schwerlich vorbei. Ich möchte sowas bei meinen Kundeninstallationen schlicht und einfach nicht erleben. Punkt.

Eben diese Realität wird meines Erachtens von – offenbar – der Mehrheit der WordPress Herausgeber verdrängt? Dort wird die Community-Schwarmübersetzerei als der Weißheit letzter Schluss gepriesen und als das Allheilmittel aller – bestehenden – Probleme in Bezug auf Internationalisierung und Lokalisierung im WordPress Universum angesehen. Allein, es ist ein Trugschluss.

Die Entwickler-Perspektive?

Diese ganzen Sachen werden offenbar zum großen Teil von Leuten entwickelt, die nie etwas anderes, als ein WordPress im reinen amerikanischen Englisch vor sich haben, höchstens angereichert mit Jetpack-Slang oder Spielerei-Plugins wie “Pig Latin”. Solche Entwickler erahnen vermutlich nichts von den täglichen Herausforderungen komplett übersetzter, gar mehrsprachiger Installationen. Sie erahnen wahrscheinlich erst rechts nichts davon, wenn man mehrere Groß-Plugins (a la WooCommerce, BuddyPress, Jetpack, Gravity Forms…) oder Themes/ Frameworks in monatelanger oder gar jahrelanger Pflegearbeit so spezialisiert übersetzt hat für ein Projekt, dass man automatische Aktualisierungen scheut, wie der Teufel das Weihwasser. Und um die Sache weiter zuzuspitzen: Ja, für ein oder mehrere spezielle Projekte braucht man nur diese Anpassungen, für den übergroßen Rest braucht man jene “regulären” Übersetzungen. — Ganz bestimmt, so etwas übersteigt deren Vorstellung völlig. In ebenjener Vorstellung sind solche “Custom Translations” nichts weiter als schmutzige Hacks. Denn, wenn schon Übersetzungen, dann doch bitte nur via automatisierten Language Packs, die wir gleich von unserem GlotPress aus ganz automatisch raus in die weite Welt schießen. Nur so kann, muss, das laufen…? Zwangsbeglückung, ick hör dir trapsen…!?

Muss nicht. Es gibt auch noch Übersetzungsprinzipien, übersetzen im Kontext, testen im Kontext, eben Sprach- und Übersetzungspflege. Dies steht nach meiner Überzeugung im Widerspruch zu lose organisierten, oft bruchstückhaft wirkenden Community-Übersetzungen.

Eigenes Ding machen?

Nun ist das alles für den Moment noch gar kein größeres Problem, denn WordPress wäre nicht WordPress – und damit flexibel -, hätte es nicht Mittel und Möglichkeiten, sein eigenes Ding zu machen. Sprich: es gibt alternative Funktionen, Hooks, Filter, die es uns erlauben, am “Normalzustand” vorbei, unsere Anpassungen einzubinden, d.h. laden zu lassen. Klar, es kostet Zeit und Aufwand, aber es ist grundsätzlich möglich. Wir gehen dankend auf die Knie :-).

Die Frage, die ich mir nur dabei stelle: wie lange wird man der Zwangsbeglückung noch entfliehen können? Irgendwann dürften die Notausgänge wahrscheinlich verriegelt und zugemauert werden. Ganz nach dem üblichen 80/20 Totschlagargument (muss nie bewiesen werden): wir schleppen im WordPress Core nur das mit, was 80% der Anwender benötigen. Toll, wenn man zu den weltweit fünf “PressThis”-Benutzern gehört, für diese Regel noch nie galt… :)

Wird ausgerollt …

Ruhig Blut, die Language Packs sind erst noch im Aufbau, zu neudeutsch: werden ausgerollt. Die Planung sieht vor, dass irgendwann alle Plugins und Themes auf WordPress.org damit ausgestattet sind und für alle Module das Community-Übersetzerportal zur Verfügung steht (oder je nach Lesart: “zuständig” ist). Dieses “irgendwann” könnte bereits 2014 eintreten oder auch erst in den darauffolgenden Jahren. Wir werden es erleben. Meine Prognose: Ab 2015 wird es ganz “heiß” bei diesem Thema.

So oder so: Bis es soweit ist, werden noch einige Kubikmeter Wasser an der San Francisco Bay vorüberfließen. Ob die Sprachpakete dabei mit auf eine Odyssee gehen oder ans anvisierte Ziel kommen, müssen wir gemeinsam abwarten bzw. aussitzen. Meine persönliche Entscheidung steht natürlich schon fest – oh, welch Überraschung – sie lautet: Zwangsbeglückung? Nein, Danke!

deckerweb.de läuft mit dem
Genesis Framework

Genesis Framework für WordPress CMS

Mit Genesis schnell und einfach unglaubliche Websites mit WordPress CMS bauen. Genesis bietet die sichere und suchmaschinen-optimierte Basis, um mit WordPress Dinge zu erreichen, die Sie sich noch nicht vorgestellt haben.


Nutzen Sie 6 Standard-Layout-Optionen, umfassende SEO-Einstellungen, felsenfeste Sicherheit, flexible Theme-Einstellungen, coole Genesis-eigene Widgets sowie eine riesige Auswahl an Genesis Child Themes ("Skins"). Mit automatischen Updates und erstklassigem Support wird Genesis die clevere Wahl für Ihre WordPress-Website.



Ein StudioPress Affiliate werden

Trackbacks/ Pingbacks

  1. […] deckerweb.de: WordPress Language Packs: Gute Hilfe oder Zwangsbeglückung? […]

Beitrag kommentieren

*

Neue Blog-Beiträge als E-Mail erhalten?