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 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?

q1-are-you-happy-with-current-page-builder-translation

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?

q2-which-page-builder

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.
Ein Layout bearbeiten
Ein Layout bearbeiten

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.
Ein Layout für die Übersetzung auswählen
Ein Layout für die Übersetzung auswählen

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.
Ein Layout übersetzen
Ein Layout im WPML-Übersetzungs-Editor übersetzen

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.
Die Seite mit dem Layout im FrontendDie übersetzte Seite auf Russisch
toolset-english toolset-russian

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.

Fanden Sie das nützlich? Teilen Sie diesen Artikel: