Übersetzungs-Support für Page Builder kommt zu WPML

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.

Hintergrund – Wie wir heute empfehlen, Websites mit Page Buildern zu übersetzen

Für alle Page Builder außer Toolset Layouts (wird in einem neuen Tab geöffnet) besteht die einzige Möglichkeit zur Übersetzung heute darin, separate Designs pro Sprache zu erstellen.

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.

Frage: Sind Sie mit der aktuellen Methode zur Übersetzung von Inhalten, die mit Page Buildern erstellt wurden, zufrieden?

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.

Frage: Welche Page Builder nutzen Sie häufig?

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.

Wie wird der Übersetzungsprozess ablaufen?

Da wir dies bereits vollständig in das Layouts-Plugin integriert haben und es funktioniert (obwohl die Dokumentation noch „in Arbeit“ ist), werde ich Layouts als Beispiel verwenden.

Schritt 1) Design im Page Builder

Wie ich bereits erklärt habe, müssen Sie das Design im Page Builder nur einmal erstellen. Dasselbe Design wird für alle Übersetzungen verwendet.

Schritt 2) Zur Übersetzung senden

Wenn eine Seite einen Page Builder verwendet, müssen Sie diese „zweimal“ übersetzen. Zuerst die Seite, was den Seitentitel und alle von Ihnen verwendeten benutzerdefinierten Felder umfasst. Das zweite Mal das Page-Builder-Design. Ich weiß, dass dies etwas umständlich ist. Wir werden daran arbeiten, dies zu automatisieren, aber wahrscheinlich nicht in der ersten Runde.

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.

Schritt 3) Übersetzen

Sie sehen alle Texte, die zum Design gehören, nebeneinander. Sie übersetzen nur die Texte und nicht die Struktur. Übersetzen und markieren Sie jedes Feld als „Abgeschlossen“. Wenn Sie speichern, werden die Übersetzungen automatisch auf das Page-Builder-Design angewendet.

Schritt 4) Die Ergebnisse im Frontend ansehen

Ihre Übersetzungen erscheinen im Frontend, wenn Sie den Inhalt ansehen. Sie werden im Page Builder keine Übersetzungen sehen, da Übersetzungen diesen nicht verändern.

Schritt 5) Die Übersetzung aktualisieren, wenn das Design aktualisiert wird

Wenn Sie das Design im Page Builder bearbeiten, gehen Sie zum Übersetzungs-Dashboard und senden Sie es erneut zur Übersetzung. Nur geänderte Texte werden zur Übersetzung angezeigt.

Roadmap für die Integration der Übersetzung für Page Builder mit WPML

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.

Feedback?

Wie klingt das für Sie? Ich bin sicher, dass einige Leute möchten, dass wir zuerst an anderen Page Buildern arbeiten. Wir müssen Prioritäten setzen, also beginnen wir mit dem, was die meisten Leute nutzen. Wir werden sicherstellen, dass wir letztendlich ALLE Page Builder erreichen, besser früher als später. Ich würde gerne Ihr Feedback zum Übersetzungsprozess und zum Gesamtplan erhalten. Wenn Sie Ideen, Fragen oder Vorschläge haben, hinterlassen Sie Ihre Kommentare und ich werde mich bei Ihnen melden.