[Gelöst] JKit Elementor Widgets werden nicht in WPML String Translation angezeigt

Der Plugin-Ordner von Jeg Kit for Elementor beinhaltet keine wpml-config.xml-Datei, was bedeutet, dass diese Widgets nicht die empfohlene von uns Methode verwenden, um diese Custom Elementor Widgets mit dem WPML Übersetzungseditor übersetzbar zu machen.

Quelle:
https://wpml.org/documentation/support/multilingual-tools/registering-custom-elementor-widgets-for-translation/

Ich habe daraufhin einen Jeg Kit-Button auf einen Test-Beitrag eingefügt und übersetzt. Beim Übersetzen werden der Button-Text und der Link im Übersetzungseditor ausgegeben.

Soll bedeuten, die Widgets sind anscheinend übersetzbar, aber verwenden eine veraltete Methode, bei der direkt in den Code der Widgets eingegriffen wurde, um diese übersetzbar zu machen.

Hier wird der Link im Übersetzungseditor ausgegeben, selbst dann, wenn es sich um einen internen Link handelt.

Quelle (alte Developer Docs):
https://wpml.org/documentation/plugins-compatibility/elementor/how-to-add-wpml-support-to-custom-elementor-widgets/

In dem Fall muss man die Links selbst übersetzen, da dies im Widget so vorgesehen ist.

Umgehen könnte man das nur mit einer XML-Konfiguration, die für dieses Button Widget wie folgt aussehen müsste:

<wpml-config>
  <elementor-widgets>
    <widget name="jkit_button">
      <fields>
        <field>sg_content_label</field>
        <field editor_type="LINK">sg_content_link>url</field>      
        <field>ekit_adv_tooltip_content</field>
        <field>eael_tooltip_section_content</field>
        <field>eael_ext_content_protection_password_placeholder</field>
        <field>eael_ext_content_protection_password_submit_btn_txt</field>
        <field>eael_ext_content_protection_password_incorrect_message</field>      
        <field>ekit_cursor_text_label</field>
      </fields>     
    </widget>
  </elementor-widgets>
</wpml-config>

Ich habe diese Config unter WPML > Einstellungen > Benutzerdefinierte XML-Konfiguration eingefügt.

Danach muss jeder Button auf dem originalen Inhalt editiert, der Inhalt erneut gespeichert und die Übersetzung erneut durchgeführt werden.

Die Button-Links erscheinen dann nicht mehr im Übersetzungseditor, wenn es sich um interne Links handelt, und werden im Frontend automatisch angepasst.

Funktionierender Test-Beitrag:
versteckter Link

Eine bessere Lösung kann ich aktuell leider nicht anbieten und ich empfehle zudem den Autor des Plugins hierüber in Kenntnis zu setzen.

Das Plugin ist bei uns aktuell als nicht-kompatibel gelistet:
https://wpml.org/plugin/jeg-elementor-kit/

Es wäre auch im Falle der Icon Box besser eine XML-Konfiguration zu erstellen, damit man die Links nicht manuell übersetzen muss.

Ich habe auf dem Staging unser Plugin "Multilingual Tools" installiert. Unterhalb des Inhaltes im WordPress-Editor zeigt dieses die komplette Config für alle vorhandenen Widgets des Inhaltes an.

Man muss diese Config nur gelegentlich etwas anpassen.

Ich habe nun ebenfalls eine Config für das Icon-Box-Widget erstellt. Hier trat das Problem mit den Links bei meinem Test nicht auf, aber ich konnte feststellen, dass sich einige Texte nicht übersetzen lassen. Die benutzerdefinierte Konfiguration in den WPML-Einstellungen sieht nun wie folgt aus:

<wpml-config>
  <elementor-widgets>
    <widget name="jkit_button">
      <fields>
        <field>sg_content_label</field>
        <field editor_type="LINK">sg_content_link>url</field>
        <field>ekit_adv_tooltip_content</field>
        <field>eael_tooltip_section_content</field>
        <field>eael_ext_content_protection_password_placeholder</field>
        <field>eael_ext_content_protection_password_submit_btn_txt</field>
        <field>eael_ext_content_protection_password_incorrect_message</field>
        <field>ekit_cursor_text_label</field>
      </fields>
    </widget>
     <widget name="jkit_icon_box">
      <fields>
        <field>sg_icon_text</field>
        <field>sg_icon_description</field>
        <field>sg_readmore_enable_button</field>
        <field editor_type="LINK">sg_readmore_globallink>url</field>
        <field>sg_readmore_button_label</field>     
        <field>sg_badge_text</field>    
        <field>ekit_adv_tooltip_content</field>        
        <field editor_type="LINK">elementskit_wrapper_link>url</field>
        <field>eael_tooltip_section_content</field>
        <field>eael_ext_content_protection_password_placeholder</field>
        <field>eael_ext_content_protection_password_submit_btn_txt</field>
        <field>eael_ext_content_protection_password_incorrect_message</field>      
        <field>ekit_cursor_text_label</field>
      </fields>     
    </widget>
  </elementor-widgets>
</wpml-config>

Editiere nun die betroffenen Widgets auf dem originalen Inhalt in Elementor, speichere die Seiten erneut ab und aktualisiere dann die Übersetzung. Die internen Links müssen nun nicht mehr übersetzt werden.

Ich würde empfehlen den Autor dieses Elementor-Addons darüber in Kenntnis zu setzen.

---

Zur Seite "Wissenswertes":

Wenn ich die Übersetzung der Seite öffne, sehe ich, dass hier einige interne Links verwendet werden, wie zum Bespiel:
versteckter Link

- Solche Links sind im Übersetzungseditor per Standard blockiert (Schlosssymbol).
- Solange sie blockiert sind, wird sie automatisch angepasst.

Hier wurde die "Blockierung" aber anscheinend durch einen Nutzer aufgehoben und der Link wurde identisch übersetzt.

Deshalb funktioniert die interne Verlinkung nun nicht mehr automatisch. In dem Fall kann man den Link leider nur manuell im Übersetzungseditor anpassen.

Nun kann man alle Texte der Icon-Box übersetzen. Beachte in dem Fall bitte, dass man hier zwar die Link-URLs im Übersetzungseditor sieht, aber man diese nicht manuell anpassen muss. Sie werden auf der Übersetzung automatisch angepasst.

Hallo Patrizia,

Vielen Dank für deine Rückmeldung und die detaillierte Beschreibung.

Die Seite „Wissenswertes“ verwendet bereits den Slug /wissenswertes.

Gleichzeitig ist in den Permalink-Einstellungen die Struktur /wissenswertes/%postname%/ hinterlegt.

Unter Einstellungen → Lesen ist jedoch keine Beitragsseite definiert, die diesen Slug nutzt.

Könnte es sein, dass die Seite „Wissenswertes“ als zentrale Blogseite gedacht ist?

Falls ja, wäre es sinnvoll, diese unter Einstellungen → Lesen → Beitragsseite zuzuweisen, damit WordPress die Permalink-Struktur korrekt anwenden kann.

Problem hierbei:

Leider unterstützt WordPress selbst keine Übersetzung von benutzerdefinierten Permalink-Strukturen wie /wissenswertes/%postname%/.

WPML kann diesen statischen Basis-Slug nicht automatisch zur Übersetzung registrieren, da es sich um einen globalen Permalink-Wert handelt, der nicht sprachspezifisch ist. Das betrifft nicht nur WPML – auch andere Übersetzungsplugins stoßen hier an die Grenzen von WordPress.

---

Lösung des Problems:

Eine Übersetzung wäre nur möglich, wenn der Slug Teil eines benutzerdefinierten Beitragstyps ist und hier existiert bereits ein solcher CPT namens "Wissenswertes".

Dessen Slug kann man über WPML → Einstellungen → Übersetzung von Beitragstypen behandeln und sprachspezifisch ausgeben – z. B. /de/wissenswertes/artikelname und /en/insights/article-name.

Aktuell war der englische Slug nicht korrekt übersetzt. Er muss URL-gerecht sein. Ich habe das angepasst.

Um diesen CPT nun für die Standard-WordPress-Beiträge zu verwenden, muss ein entsprechendes Template im Child Theme erstellt werden.

Beispiel:
archive-wissenswertes.php

<?php
$args = [
  'post_type' => 'post',
  'posts_per_page' => 10,
  'paged' => get_query_var('paged') ?: 1,
  'suppress_filters' => false,
];
$query = new WP_Query($args);

if ($query->have_posts()) :
  while ($query->have_posts()) : $query->the_post();
    get_template_part('template-parts/content', get_post_type());
  endwhile;

  the_posts_pagination();
  wp_reset_postdata();
else :
  echo '<p>' . esc_html__('Keine Beiträge gefunden.', 'textdomain') . '</p>';
endif;
?>

---

Gib mir gerne Bescheid, ob du die Seite als Blogseite nutzen möchtest oder ob du alternativ über einen benutzerdefinierten Beitragstyp nachdenkst – ich unterstütze dich gerne bei der Umsetzung.

---

Mit der Übersetzung der Seite "Wissenswertes" hatte ich heute kein Problem. Bei welcher Übersetzung kommt es hier aktuell zu einem Fehler?

Bitte nenne mir ein exaktes Beispiel.

---

Zur Startseite:
Mir ist aufgefallen, dass die Übersetzung hier nicht wie erwartet funktioniert.

Ein Blick auf WPML > Einstellungen > Benutzerdefinierte Felder übersetzen zeigt, dass das Feld "_elementor_data" auf "Übersetzen" gestellt wurde.

Das ist nicht empfehlenswert.

Ich habe das Feld nun wieder auf seinen Standardwert "Einmal kopieren" zurückgesetzt.

Danach funktionierte die Übersetzung wie erwartet:
versteckter Link

Viele Grüße
Andreas

Hallo Patrizia,

Du versuchst einen benutzerdefinierten Permalink /wissenswertes/%postname% anzuwenden, welcher in WordPress nur dann angewendet wird, wenn unter Einstellungen > Lese eine Blogseite hinterlegt ist. Aktuell ist hier keine Blogseite hinterlegt.

Das Problem dabei ist, dass WPML /wissenswertes/ in diesem Fall nicht übersetzen kann.

---

Es kann /wissenswertes/ nur dann übersetzen, wenn du anstatt dessen deinen Custom Post Type "Wissenswertes" verwendest, um über diesen Beitragstyp die WordPress-Beiträge anzuzeigen.

Das kann man mit einem Theme-Template erreichen, welches im Child Theme integriert wird.

Siehe meinen letzten Kommentar unter "Lösung des Problems:".

Soll ich mal versuchen das in der Staging Site zu integrieren?

Mit freundlichen Grüßen
Andreas

Das Problem ist, dass hier ein Konflikt dadurch ausgelöst wird, dass man versucht den gleichen Slug /wissenswertes/ auf drei unterschiedliche Wege zu verwenden:

- Als benutzerdefinierter Permalink für eine Blogseite
- Als Slug für den Custom Post Type "Wissenswertes" (PODS Plugin)
- Als Slug einer Seite namens "Wissenswertes".

---

Ich habe die Template-Datei page-wissenswertes.php nun im Child Theme eingefügt. Dieses Template gilt für die Seite "Wissenswertes".

Das Pods-Plugin habe ich deaktiviert, da es sonst zu einem Konflikt kommt.

Die Permalink-Struktur der Website habe ich an "Beitragsname" angepasst, da WPML hier /wissenswertes" nicht übersetzen kann-.

Die Seite "Wissenswertes" operiert dadurch als Blog:

versteckter Link
versteckter Link

Man kann aber leider nun nicht automatisch alle Beiträge unter /wissenswertes/beitragsname oder /worth-knowing/postname anzeigen.

Das funktioniert leider nicht.

Im Grunde müsste man dazu einen Custom Post Type verwenden.

Die Beiträge müssten aber dann ebenfalls in diesem Custom Post Type erstellt werden, was hier nicht der Fall ist.

Man könnte mit einem Plugin wie "Post Type Switcher" die Beiträge dem Custom Post Type "Wissenswertes" zuordnen.

Das Template sollte dann wieder auf dem Theme entfernt werden.

Man muss dazu nur die Datei page-wissenswertes.php aus dem Child Theme entfernen. Ich habe dies nun getan.

Um nun die Beiträge nun auf der Seite "Wissenswertes" anzuzeigen, muss man auf die WordPress-Standard-Methode einer Blogseite zurückgreifen. Ich habe dazu die WordPress-Einstellungen unter "Lesen" die Blogseite auf die Seite "Wissenswertes".

Zu den Permalink-Einstellungen würde ich empfehlen den Beitragsnamen oder Kategorie & Beitragsnamen anzuwenden.

Das Pods - Custom Content Types and Fields Plugin sollte nicht aktiviert werden, da es für den dort generierten Custom Post Type den gleichen Slug wie die Seite "Wissenswertes" verwendet. Du benötigst diesen Beitragstype allerdings nicht, wenn du nicht vorhast die vorhandenen Beiträge zu diesem zuzuordnen.

Der Header und Footer erscheinen auf der Blogseite "Wissenswertes" nun wie erwartet.