Wie man einen PrestaShop-Shop übersetzt, ohne ihn zu beschädigen

Eine Sprache zu PrestaShop hinzuzufügen dauert etwa zwei Minuten. Man öffnet das Back-Office, installiert die Sprache, und sie erscheint im Sprachauswähler im Frontend. Dann besucht man die neue Version des Shops und stößt auf dasselbe Problem wie alle anderen: Die Benutzeroberfläche ist übersetzt, der eigentliche Shop-Inhalt jedoch nicht.

Genau hier scheitern die meisten PrestaShop-Übersetzungsprojekte. Nicht weil die Werkzeuge schlecht sind, sondern weil viele falsch verstehen, was PrestaShop bereits leistet und was es bewusst leer lässt.

PrestaShop ist bereits mehrsprachig. Das verändert das ganze Problem

WordPress braucht ein Plugin, um überhaupt das Konzept einer zweiten Sprache zu kennen. PrestaShop nicht. Jedes übersetzbare Inhaltselement liegt in einer eigenen Sprachtabelle: Produkte, Kategorien, CMS-Seiten, Meta-Titel, URL-Rewrites. Der Shop wurde von Anfang an mehrsprachig entwickelt.

Die Frage lautet also nie: „Wie mache ich meinen Shop mehrsprachig?" Der Shop ist bereits mehrsprachig. Die Frage lautet: „Wie befülle ich Tausende leerer Zeilen, ohne eine Agentur zu beauftragen und ohne meine URLs zu ruinieren?"

Dieser Unterschied ist wichtig, denn er schließt eine ganze Kategorie von Tools aus, bevor man überhaupt anfängt, sie zu vergleichen.

Was das offizielle Sprachpaket wirklich liefert

Wenn man eine Sprache installiert, lädt PrestaShop das Community-Sprachpaket herunter. Es ist kostenlos und durchaus nützlich, aber sein Umfang ist begrenzt und es lohnt sich, das genau zu verstehen.

Das Paket füllt die Interface-Texte sowie eine kurze Liste von Datenbankzeilen: die Standard-Statikseiten und ihre URL-Rewrites, die üblichen Farb- und Größenattribute, Bestellstatus, Lieferzeiten der Versanddienstleister sowie die Standardkategorien. Bei einem frischen Shop sind das einige Dutzend Zeilen.

Was das Paket niemals anrührt: den Produktkatalog und die CMS-Seiten. Kein Produktname, keine Beschreibung, keine benutzerdefinierte Seite. Das sind Ihre Inhalte, also lässt das Paket sie unangetastet.

Das ist die genaue Grenze der Arbeit. Alles, was das Paket abdeckt, sollte man nie von einer KI übersetzen lassen. Alles darüber hinaus ist die eigentliche Aufgabe.

Die Overlay-Falle

Viele Übersetzungs-Tools, besonders solche, die aus der WordPress-Welt stammen, funktionieren so, dass sie die Seite beim Ausliefern an den Browser umschreiben. Der Shop bleibt darunter einsprachig, und eine Schicht tauscht den Text auf dem Weg zum Nutzer aus.

Bei PrestaShop ist das ein schlechtes Geschäft, aus Gründen, die sich eher nach ein paar Wochen zeigen als am ersten Tag.

Der Shop weiß nicht, dass die übersetzten Seiten existieren. Deshalb beschreiben Sitemap, hreflang-Tags, kanonische URLs und strukturierte Daten allesamt einen einsprachigen Shop. Suchmaschinen indexieren, was PrestaShop deklariert, nicht was ein Overlay obendrauf malt.

Transaktionale Inhalte bleiben außen vor. Bestellbestätigungs-E-Mails, Rechnungen und PDF-Lieferscheine werden serverseitig generiert, außerhalb der Seite, die das Overlay abfängt. Kunden erhalten einen übersetzten Shop und eine E-Mail in der falschen Sprache.

Man zahlt außerdem doppelt für das, was kostenlos ist. Ein Overlay übersetzt alles, was auf dem Bildschirm steht, einschließlich der Interface-Texte und Bestellstatus, die das Sprachpaket bereits kostenlos geliefert hat.

Und wer bereits einen mehrsprachigen Shop betreibt, für den ist ein Overlay schlicht inkompatibel. Man endet mit zwei konkurrierenden Quellen für denselben Inhalt.

Das letzte Problem ist dasjenige, das später am meisten kostet: Schaltet man das Tool ab, verschwinden alle übersetzten Seiten auf einmal.

Die nativen Tabellen stattdessen befüllen

Die Alternative ist unspektakulär und deutlich robuster: die Übersetzungen in die Sprachtabellen schreiben, die PrestaShop bereits verwendet.

Sobald diese Zeilen befüllt sind, erledigt PrestaShop den Rest selbst, denn genau dafür wurde es entwickelt. Routing, hreflang-Tags, Sitemap, der Sprachauswähler im Theme, E-Mails, PDF-Rechnungen. Dafür braucht man kein Plugin. Man braucht Daten.

Das bedeutet auch, dass die Übersetzungen einem im buchstäblichen Sinne gehören. Sie liegen in der eigenen Datenbank, in den eigenen Backups, im eigenen Export. Deaktiviert man das Modul, das sie geschrieben hat, bleiben die übersetzten Seiten weiterhin erreichbar.

Das ist der Ansatz, den das TrueLang PrestaShop-Modul verfolgt: Katalog, Kombinationen, Merkmale, Kategorien, CMS-Seiten, Facettensuche-Filter, URL-Rewrites und Meta-Felder, nativ geschrieben, für PrestaShop 1.7.6 bis 8.x.

URLs sind der Punkt, an dem lebende Shops Schaden nehmen

Wer irgendetwas in einem Shop übersetzt, der bereits Traffic hat, sollte diesen Abschnitt zweimal lesen.

Die Standard-Routen von PrestaShop enthalten die Objekt-ID, zum Beispiel /3-clothes oder /content/1-delivery. Da die ID in der URL enthalten ist, bricht die alte Adresse nicht, wenn man den Rewrite ändert: Der Front-Controller erkennt die ID und leitet auf die neue Adresse um. Das schützt bei Produkten und Kategorien.

Statische Seiten sind die Ausnahme. Ihre Rewrites enthalten keine ID, sodass die alte Adresse im Moment der Übersetzung zu einem echten 404-Fehler wird. Haben diese Seiten Backlinks oder sind im Index, braucht man Weiterleitungen von den alten Adressen, keine guten Absichten.

Übersetzte URLs lohnen sich dennoch. Ein /damen/sommerkleider schlägt /3-summer-dresses in einem deutschen SERP. Man sollte es jedoch mit einem fertigen Weiterleitungsplan tun, nicht erst nachdem der Traffic eingebrochen ist. Dieselbe Sorgfalt gilt für jede mehrsprachige Migration: Die Rankings, die man bereits hat, sind das Kapital, das es zu schützen gilt.

Checkout, E-Mails und Rechnungen gehören zum Shop

Es ist verlockend, den Erfolg zu erklären, sobald die Produktseiten korrekt aussehen. Kunden hören jedoch nicht bei Produktseiten auf.

Checkout-Beschriftungen, die Texte im Zahlungsschritt, Bestellbestätigungs-E-Mails, Rechnungen und Lieferscheine sind allesamt Teil des Kauferlebnisses. Und in all diesen Bereichen verliert ein halb übersetzter Shop das Vertrauen der Kunden genau in dem Moment, in dem er es hätte gewinnen können. Ein nativer Ansatz deckt sie alle ab, weil PrestaShop sie aus denselben Sprachtabellen generiert.

Schützen, was man bereits geschrieben hat

Zwei Regeln ersparen später einen enormen Aufwand beim Aufräumen.

Niemals menschliche Arbeit überschreiben. Hat jemand im Team eine Produktbeschreibung auf Deutsch überarbeitet, sollte kein automatischer Durchlauf sie erneut anfassen. Ein manuell bearbeitetes Feld sollte als solches erkannt und dauerhaft in Ruhe gelassen werden.

Ein Glossar führen. Markennamen, Produktlinien, Fachbegriffe, Wörter, die man niemals übersetzt haben möchte. KI-Übersetzungen sind inzwischen gut genug, dass die Fehler selten grammatikalischer Natur sind. Es sind Terminologiefehler: der Modellname wird zu einem Gattungsbegriff, die Marke wird hilfsbereit lokalisiert. Ein Glossar kostet zehn Minuten und verhindert das alles.

Was das kosten sollte

Bei der Preisgestaltung für Übersetzungen wird aus einem normalen Projekt oft eine unberechenbare laufende Ausgabe. Abo-Tools berechnen jeden Monat Gebühren für Seiten, die man einmal übersetzt und schon lange veröffentlicht hat, und die Rechnung wächst mit dem Katalog.

Für einen Shop ist dieses Modell verkehrt. Ein Katalog ist kein Strom, sondern ein Bestand. Man übersetzt ein Produkt einmal, und es verkauft sich zwei Jahre lang.

Credit-basierte Preise passen weit besser: Man zahlt für die Übersetzungsarbeit, die man tatsächlich ausführt, und nichts, solange der Katalog einfach dort sitzt und verkauft. TrueLang-Lizenzen werden mit 5 EUR Guthaben geliefert, was ungefähr einem hundert Seiten großen Shop in zwei Sprachen entspricht, ohne ein Abonnement dahinter. Wer die Kalkulation im Detail möchte, findet sie in how much website translation costs.

Eine vernünftige Reihenfolge

1. Zuerst das offizielle Sprachpaket für jede Zielsprache installieren. Es ist kostenlos und deckt die Benutzeroberfläche ab.
2. Die Quellsprache prüfen. Bei PrestaShop ist die Quelle diejenige Sprache, in der die Inhalte tatsächlich geschrieben wurden, was nicht immer die Store-Standardsprache ist.
3. Den Katalog und die CMS-Seiten übersetzen. Das ist der Teil, den sonst nichts abdeckt.
4. Die verkaufsrelevanten Seiten nochmals durchlesen: Bestseller, Landingpages, Liefer- und Rückgaberichtlinien.
5. Weiterleitungen für jede Statikseite einrichten, deren URL sich geändert hat.
6. hreflang und die Sitemap einmal im Frontend prüfen. Liegen die Übersetzungen in den nativen Tabellen, generiert PrestaShop beides korrekt von selbst.

Die Kurzfassung

PrestaShop weiß bereits, wie man mehrsprachig ist. Es wird nur mit leeren Regalen ausgeliefert.

Befüllt man die Regale richtig, in den eigenen Tabellen des Shops, funktioniert alles Nachgelagerte so, wie die Plattform es vorgesehen hat: URLs, SEO, E-Mails, Rechnungen und Übersetzungen, die einem gehören, egal was man später mit dem Tool entscheidet, das sie erstellt hat.