
Warum Community-Übersetzung für WordPress-Themes und -Plugins nicht skalierbar ist
Unsere Analyse von 60.000+ WordPress-Plugins und -Themes zeigt, dass die Community-Übersetzung weniger als 5 % des Bedarfs in 40 Sprachen abdeckt.
Vor zwei Tagen haben wir eine Umfrage durchgeführt und Sie gefragt, wie Sie Websites übersetzen möchten, die mit Page Buildern gestaltet wurden. In diesem Beitrag möchte ich die Ergebnisse mit Ihnen teilen und erläutern, wie diese unsere bevorstehende Entwicklung von WPML 3.6 beeinflussen werden.
Das ist nutzbar, aber nicht sehr komfortabel. Wir denken, dass es einfacher wäre, ein Design einmalig für alle Sprachen zu erstellen und nur die Texte mit WPML zu übersetzen. Übrigens stellen wir gerade die Dokumentation darüber fertig, wie man in Toolset alles übersetzt, einschließlich Layouts. Ich werde darüber schreiben, sobald sie fertig ist.

Einige Leute ziehen es tatsächlich vor, für jede Sprache ein separates Design zu erstellen. Das ist sinnvoll, wenn das gesamte Design angepasst werden muss. Ich nehme an, wenn Sie ein sehr präzises Design für die Startseite der Website haben, macht es Sinn, dieses pro Sprache anzupassen und zu optimieren.
Die meisten sind mit dem, was wir jetzt haben, OK, bevorzugen es aber, ein Design zu haben und mit WPML zu übersetzen. Und einige sagen, dass dieser Ansatz für sie nicht nutzbar ist. Ich denke, das sind Personen, die Übersetzungsdienste nutzen. Ich stimme zu, dass es meist unmöglich ist, externe Übersetzer zu bitten, Ihre Page-Builder-Designs zu bearbeiten. Wir sind auf diese Probleme gestoßen, als wir WPML mit einer Reihe von Übersetzungsdiensten integriert haben.

Fast 60 % der Websites, die Page Builder verwenden, nutzen Visual Composer. Die nächsten sehr beliebten Builder sind Divi und Avada. Andere sind ebenfalls recht beliebt.


Gehen Sie zu WPML->Übersetzungsmanagement. Dort sehen Sie neue Inhaltstypen für die Page-Builder-Designs. Wählen Sie die Designs aus, die Sie übersetzen möchten, und senden Sie sie zur Übersetzung. Sie können verschiedene Elemente Ihrer Website durchgehen und zum Übersetzungskorb hinzufügen. Wenn Sie mit dem Sammeln für die Übersetzung fertig sind, gehen Sie zu WPML->Übersetzungsmanagement->Übersetzungskorb und senden Sie alles zusammen in einem Durchgang. Sie können lokal (mit dem WPML-Übersetzungs-Editor) oder extern bei Ihrem bevorzugten Übersetzungsdienst übersetzen.

Wir beginnen die Integration mit Visual Composer, was leider am wenigsten komfortabel zu integrieren ist. VC speichert das Design als Shortcodes innerhalb „des Inhalts“. Die Shortcodes haben keine IDs, daher ist es schwierig, eine Zuordnung zwischen einem Element und seinen Texten herzustellen. Wir werden versuchen, mit den VC-Autoren zusammenzuarbeiten, um den Zellen IDs hinzuzufügen. Jedenfalls werden wir eine Fallback-Methode verwenden, die Strings anhand ihres Inhalts identifiziert. Das bedeutet, dass Sie einen Text, wenn er sich ändert, von Grund auf neu übersetzen müssen, da wir keine Möglichkeit haben zu erkennen, wie dieser Text lautete, bevor Sie die Zelle bearbeitet haben. Wir werden unser Bestes tun, um den VC-Zellen IDs hinzuzufügen. Ich hoffe, Sie verstehen, dass dies nicht vollständig in unseren Händen liegt.
Andere Page Builder funktionieren anders. Sie speichern das Builder-Design getrennt vom „Inhalt“ und die Zellen haben eindeutige Bezeichner. Wenn Sie also eine Zelle bearbeiten, sehen Sie die vorherige Übersetzung und können diese einfach aktualisieren.
WPML 3.6 wird mit Sicherheit Support für Visual Composer enthalten. Wir werden versuchen, auch Support für Divi einzubauen. Als Teil dieses Release-Zyklus werden wir zudem eine detaillierte Dokumentation darüber schreiben, wie man Strings für die Übersetzung in Page Buildern registriert. Es ist ziemlich einfach, es muss nur richtig dokumentiert werden.
Anschließend werden wir mit allen anderen Entwicklern von Page Buildern zusammenarbeiten, um einen solchen Support in ihre Produkte zu integrieren.