WooCommerce + WPML oder Polylang: Warum die meisten Chat-Plugins mehrsprachige Shops brechen

Wenn Sie grenzübergreifend auf WooCommerce verkaufen, laufen Sie WPML, Polylang oder TranslatePress. Vielleicht zwei davon auf verschiedenen Seiten. Die Übersetzungsschicht ist so häufig, dass Shop-Besitzer aufhören, es als separates Plugin zu bemerken. Es ist nur wie der Shop funktioniert.

Dann wird ein Chat-Plugin installiert und die Risse zeigen sich innerhalb eines Tages. Der Käufer auf der französischen Version des Shops erhält Antworten auf Englisch. Oder das Chat findet ein englisches Produkt und empfählt es auf einer deutschen Seite, wo das gleiche Produkt eine deutsche URL hat. Oder schlimmstenfalls, das Chat sagt ein Produkt existiert, verlinkt zu ihm und der Link ist ein 404, weil das Chat nur die Master-Sprache indexiert.

Ich habe dies auf mehrfachen Shops passieren beobachtet. Der Shop-Besitzer reicht es ein als "komisch Chat-Verhalten" und versucht ein anderes Chat-Plugin. Das neue bricht die gleiche Weise. Die meisten Chat-Plugins wurden nicht für die Weise entworfen, dass WordPress-Übersetzungs-Plugins Daten speichern und die Fehler sehen identisch aus vom Anbieter zum Anbieter.

Wie WPML, Polylang und TranslatePress Daten speichern

Dies ist das Stück das die meisten Chat-Plugins überspringen. Jedes Übersetzungs-Plugin nutzt ein anderes Modell.

WPML: Separate Posts verlinkt durch trid

WPML erstellt ein neues WP_Post für jede Übersetzung. Das ursprüngliche Produkt, seine französische Übersetzung und seine deutsche Übersetzung sind drei separate Posts mit drei separaten IDs. Sie sind durch eine Übersetzungs-ID (trid) in der wp_icl_translations Tabelle verlinkt.

Wenn ein Chat-Plugin wp_posts für Produkte abfragt und dort aufhört, erhält es alle drei Posts als separate Produkte. Das Chat indexiert eine französische und englische Version, als ob sie zwei unverbundene SKUs waren. Gleiches Bild, verschiedene Sprache, verschiedene ID. Reine Daten-Duplizierung und das Chat wird empfehlen, whichever Sprache es rankt höchste in seinen Embedding-Raum, welcher normalerweise der Master ist.

Polylang: Gleiches Muster, verschiedene Tabellen

Polylang folgt dem gleichen Separaten-Post-Modell wie WPML, aber speichert seine Übersetzungs-Links in wp_term_taxonomy mit einer post_translations Taxonomie. Der Gruppierungs-Mechanismus ist unterschiedlich; die Konsequenz für ein naives Chat-Plugin ist die gleiche. Jede Sprach-Version ist ein separater Post.

TranslatePress: Gleiches Post, übersetzt beim Renderings

TranslatePress nimmt den gegenteiligen Ansatz. Es gibt einen Post in wp_posts. Die Übersetzungen leben in einer separaten wp_trp_dictionary_xx_YY Tabelle, Schlüsseln durch die ursprüngliche String. Wenn der Storefront rendert, TranslatePress tauscht Strings, während die Seite aufbaut.

Ein Chat-Plugin, das wp_posts liest, sieht nur die Master-Sprache. Es findet die französische Version nie, weil der französische Inhalt in einer String-Ersatz-Tabelle lebt, das Plugin nicht abfragt. Das Chat beantwortet französische Käufer vom englischen Post. Manchmal übersetzt der LLM fliegen; manchmal nicht. So oder so, die Erfahrung ist falsch.

Die drei mehrsprachigen Fehlermodi

1. Indexierung einer Sprache und Übersetzung des Rests während Runtime

Der billigste Pfad für einen Chat-Anbieter: indexiere die Master-Sprache, frage den LLM, um die Antwort bei Konversations-Zeit zu übersetzen. Es funktioniert für Grüße und Kategorie-Fragen. Es schlägt das Moment ein, den ein Käufer etwas Spezifisches tipt.

"Avez-vous le sac à main en cuir noir taille moyenne?" Das Chat sucht seinen englischen Index für "Ledertasche schwarz mittel." Die englische Übersetzung im Katalog könnte "mittlere Größe" sagen. Der Vektor-Suche misses. Der Käufer erhält eine "Ich konnte nicht finden, dass" Nachricht auf Französisch. Das Produkt ist auf dem Storefront auf Französisch.

Sie sehen dies nicht in Chat-Dashboards, weil die Konversation normal aussieht. Sie sehen es in den Daten umrechnen: französische Käufer konvertieren sich an der Hälfte der englischen Rate.

2. Indexierung jeder Übersetzung als separates Produkt

Das Plugin liest wp_posts und indexiert alles, das es findet. Das Chat endet mit drei "Black Leather Handbag" Einträgen (Englisch, Französisch, Deutsch), alle mit ähnlichen Embeddings. Wenn ein Käufer es fragt, wählt das Chat eins nach dem Zufall, oder durch Sprach-Detektion, die nicht immer funktioniert.

Die Empfehlung verlinkt zu dem Master-Sprache-URL. Der Käufer auf der französischen Seite klickt durch und landet auf einem 404 oder auf der englischen Seite in der Mitte ihres französischen Einkaufs-Flows. Vertrauen weg.

3. Indexierung pro Sprache aber falsch verlinken bei Empfehlung

Einige Plugins tun die schwierigere Arbeit: Detektion des Besucher-Sprache von der Seite, Route der Anfrage zum rechten Sprache-Index. Aber wenn das Chat ein Produkt-Karte zurückgibt, gibt es die URL aus seinem Index zurück ohne sie durch die Übersetzungs-Schau-Tafel zurück zu führen.

Das Chat sagt "Voici le sac" und verlinkt zu /en/black-leather-handbag/ statt /fr/sac-a-main-en-cuir-noir/. Der Link funktioniert, aber der Käufer liest jetzt Englisch auf einem französischen Einkaufs-Fluss. Einige bouncen unmittelbar.

Was mehrsprachig-bewusstes Chat braucht

Für das Chat, das sich richtig auf einem WPML, Polylang oder TranslatePress Shop verhalten, vier Dinge brauchen zu passieren:

1. Erkennen Sie den Besucher-Sprache aus dem Seiten-Kontext. Das Widget braucht die Storefront-Sprache bei Konversations-Start zu kennen, nicht von der Nachrichten-Text zu raten. WPML und Polylang surface die Sprache aktiv als ICL_LANGUAGE_CODE oder pll_current_language(). Das Widget sollte dies an das Chat-Backend auf jeder Sitzung übergeben.
2. Indexe jede Übersetzung als eine Sprach-Variante des gleichen Produkts. Drei URLs, ein Produkt, drei Sätze übersetzter Text. Das Chat sucht über alle Varianten aber empfiehlt die URL, die der Besucher-Sprache passt.
3. Lösen Sie Übersetzungs-Gruppierung bei Synchronisierungs-Zeit. Wenn das Plugin einen Webhook für ein Produkt-Save emit, sollte es den WPML trid oder Polylang post_translations Taxonomie gehen, finde jede verlinkte Übersetzung und emit eine Single-Payload mit alle Sprach-Versionen. Für TranslatePress, sollte das Plugin die Wörterbuch-Tabellen abfragen und konsolidieren.
4. Tauschen Sie die URL bei Empfehlung. Wenn das Chat ein Produkt zu empfehlen wählt, wählt es die URL, die der Besucher-Sprache-Code passt, nicht die Index-Treffer-URL.

Wie Emporiqa WPML, Polylang und TranslatePress verwaltet

Das Emporiqa-Plugin Auto-Detect, welches Übersetzungs-Plugin installiert wird und die rechte Gruppierung-Mechanismus abfrage. Bei Produkt-Save, emits das Plugin einen Single Webhook für das Produkt mit einer translations Map: {en: {name, description, slug, url}, fr: {…}, de: {…}}. Das Chat indexiert alle drei als ein logisches Produkt.

Das Widget liest die Seiten-Sprache von ICL_LANGUAGE_CODE (WPML), pll_current_language() (Polylang), oder die TranslatePress URL-Präfix und übergibt es auf jeder Konversation. Das Chat sucht über alle Sprach-Varianten und empfiehlt mit der passenden URL.

Wenn Sie benutzerdefinierte Felder lokalisiert haben (ACF Strings, Attribut-Label in nicht-Standard-Plätzen), exposes das Plugin einen Filter:

add_filter('emporiqa_product_translations', function($translations, $product) {
    foreach ($translations as $lang => &$data) {
        $data['custom_label'] = pll_translate_string('Default Label', $lang);
    }
    return $translations;
}, 10, 2);

Dieser Filter lädt einmal pro Produkt auf Speichern, so dass der Chat-Index was auch immer Übersetzungs-Logik Ihr Shop nutzt widerspiegelt.

Wie man ein Chat-Plugin auf Ihren mehrsprachigen Shop testet

Bevor Sie sich auf ein Chat-Plugin auf einem WPML, Polylang oder TranslatePress Shop festlegen, führen Sie diesen fünf-Minuten-Test aus:

1. Öffnen Sie das Storefront in Ihrer zweiten Sprache. Wenn Ihr Shop englisch-Master und Französisch-Secondary ist, navigieren zu /fr/.
2. Fragen Sie das Chat eine spezifische Produktfrage auf Französisch. Nutzen Sie einen Satz, das nur die französische Produktbeschreibung matched, nicht den englischen. "Avez-vous une lampe de chevet en bois?" funktioniert, wenn "bedside lamp wood" ist wie die englische Version liest.
3. Überprüfen Sie die Antwort-Sprache. Das Chat sollte auf Französisch antworten, nicht auf Englisch.
4. Klicken Sie die empfohlene Produktverbindung. Die URL sollte die französische URL sein (/fr/...), nicht die Master-URL.
5. Wiederhole für jede dritte Sprache der Shop unterstützt.

Jeder Fehler auf diese vier Punkte bedeutet das Chat bricht auf Übersetzung. Der Shop wird Umsatz auf jeder non-Master-Sprach-Sitzung lecken und das Chat-Dashboard wird das Verlust nicht zeigen, weil die Konversation komplett wurde.

Was dies nicht tut

• Auto-Übersetzen unübersetzte Inhalte. Wenn ein Produkt nur in Englisch existiert und ein französischer Käufer es fragt, wird das Chat nicht eine französische Version erfinden. Es wird dem Käufer sagen, das Produkt ist nicht auf Französisch verfügbar und schlagen die nächste übersetzte Alternative vor. Shops, die Auto-Übersetzung wollen, sollten ihr Übersetzungs-Plugin-Maschinen-Übersetzungs-Schritt zuerst laufen.
• Übersetz das Chat-Widget-UI. Das Widget unterstützt 65+ Sprachen, aber die Beschriftungen werden aus einem festen Satz gepickt. Benutzerdefinierte UI-Strings (Gruß, Öffner, Prompts) brauchen pro Sprache im Emporiqa Admin konfiguriert werden.
• Synchronisieren Sprach-spezifische Bestand oder Preis-Unterschiede. Wenn Ihr Shop unterschiedliche Preise pro Sprache setzt (selten aber real), exponiert das über den WordPress Filter oben. Die Standard-Synchronisierung nutzt einen Preis pro Produkt.

Warum dies am meisten für Shops zählt, die in 3+ Sprachen verkaufen

Für einen Ein-Sprach-Shop, ist mehrsprachige Verarbeitung unerheblich. Für einen Shop mit Englisch plus eins Sekundär-Sprache, könnten Sie den Runtime-Übersetz-Modell tolerieren und nicht viel verlieren. Durch die dritte Sprache, die Runtime-Übersetz-Kosten Zusammensetzung und die Such-Mismatch-Fehler werden sichtbar in den Bounce-Daten.

Wenn Ihr Shop in drei oder mehr Sprachen verkauft, wird das Chat-Plugin, das Sie wählen, leise Ihre Umrechnungs-Rate auf Ihren Sekundär-Märkten bestimmen. Der fünf-Minuten-Test oben ist der billigste Weg zu wissen, was Sie vor einem Jahr monatlicher Gebühren bekommen.

Verwandte Lektüre: die Cross-Plattform mehrsprachige Fall in Ihre deutschen Kunden verlassen, die WC-spezifischen Fehler herum Variable Produkte, die HPOS Migrations-Auswirkung und Peak-Last überstehen. Für die komplette WooCommerce Setup Walkthrough, siehe warum die meisten WooCommerce Chat-Plugins die Architektur falsch hinkriegen.

Versuchen Sie das Live-Demo bei demo.emporiqa.com in jeder 65+ Sprache, oder installieren Sie das Plugin auf einem Sandbox-Shop mit WPML oder Polylang. Mehrsprachige Abdeckung ist in der WooCommerce-Dokumentation dokumentiert.