JTL-Shop international: Warum „einfach Englisch dazuschalten“ nie reicht

Wer im Ausland verkauft, verkauft in einen Markt

Ein zusätzlicher Sprachbutton übersetzt die Oberfläche – mehr nicht. Wer im Ausland ernsthaft verkaufen will, verkauft in einen Markt: mit eigener Domain, eigenen Lieferländern, eigenen Zahlarten, eigenen Versandkosten, eigenen Preisen und Feeds für die dortigen Preisportale. Und mit einer Sprache, die nicht nach maschineller Übersetzung klingt. All das steckt im JTL-Ökosystem – aber verteilt über Shop, Warenwirtschaft und externe Kanäle. Die Kunst liegt darin, diese Bausteine so zu verbinden, dass sie zusammen einen sauberen Auftritt pro Land ergeben.

Das Fundament: eine Domain pro Land mit Multidomain

Technisch lässt sich ein einzelner JTL-Shop 5 über mehrere Domains und Subdomains betreiben – mit nur einer JTL-Shop-Lizenz. Wir setzen dafür das Plugin Admorris Multidomain ein: Ein und dieselbe Shop-Installation, dieselbe Warenwirtschaft und derselbe Artikelstamm bedienen mehrere Domains – jede mit eigener Sprache, Währung, Kundengruppe (samt eigener Preise) und eigenen Lieferländern. Die Zuordnung zum passenden Markt erfolgt über die Domain, ergänzt um IP-basierte Ländererkennung; Kundenkonten und Warenkörbe funktionieren dabei domainübergreifend. (Hinweis: Der Link zu Admorris ist ein Affiliate-Link; für dich entstehen dadurch keine Mehrkosten.)

Das Plugin bringt zugleich SEO-Grundlagen mit: länderspezifische Domains, automatisch erzeugte hreflang-Tags und eigene Sitemaps je Land, damit sich die Sprachversionen nicht als Duplicate Content kannibalisieren. Übersetzt wird dabei nichts: Die Domain-Infrastruktur ist das eine, die tausenden Sprachvariablen und Textbausteine dahinter das andere. Genau an dieser Grenze beginnt der aufwendigere Teil des Projekts, um den sich Admorris nicht kümmert (dazu weiter unten mehr).

Gegenüber vollständig getrennten Shops pflegst du Artikel, Bestände und Preise weiterhin an einer Stelle in der JTL-Wawi (bei JTL inzwischen JTL ERP). Gegenüber einer einzelnen mehrsprachigen Domain bekommt jeder Markt einen eigenständigen, lokal glaubwürdigen Auftritt, inklusive länderspezifischer ccTLDs (.co.uk, .fr, .it …).

Deutschland · tk-shop24.comItalien · tk-shop24.it

Mehrsprachige URLs automatisiert erzeugen

Suchmaschinen bewerten sprechende, lokalisierte URLs. Ein englischer Shop mit deutschen URL-Pfaden wirkt halbfertig – und verschenkt Rankings. JTL-Shop kann pro Sprache eigene URL-Pfade für Artikel, Kategorien und Hersteller führen. Diese händisch für tausende Datensätze zu pflegen, ist unrealistisch.

tk-shop24.it/en/Telecommunications/MITEL/

Vergrößern

Deshalb erzeugen wir die Pfade über einen kontrollierten Export/Import: Artikel-, Kategorie- und Hersteller-URL-Pfade werden je Sprache als Datei aus der Wawi gezogen, regelbasiert in saubere, lokalisierte Slugs überführt und zurückgespielt. Ergänzt um korrekte hreflang-Auszeichnung weiß Google, welche URL für welches Land und welche Sprache gilt – und die Länderversionen kannibalisieren sich nicht gegenseitig als Duplicate Content.

Wie das aussieht, lässt sich im Quelltext jeder Länder-Domain nachlesen: Der Shop erzeugt die hreflang-Auszeichnung automatisch – jede Sprach-/Länder-Kombination verweist auf ihre eigene URL, plus ein x-default als Rückfallebene. Ein realer Auszug aus dem <head> von tk-shop24.com:

Lieferländer, Sprachen, Versandklassen & Zahlarten pro Domain

Ein Markt ist mehr als eine Sprache. Pro Domain definieren wir, welche Länder beliefert werden, welche Sprache und Währung greifen, welche Versandklassen und -kosten gelten und welche Zahlarten angeboten werden. Ein französischer Kunde erwartet andere Zahlarten als ein britischer; die Versandkosten nach Italien sind andere als die innerhalb Deutschlands; und wer nach UK liefert, muss Zoll- und Steuerlogik sauber abbilden.

tk-shop24.it

Vergrößern

Feeds pro Domain: Google Shopping & Idealo

Preisportale und Shopping-Anzeigen sind in vielen Märkten der wichtigste Trafficmotor – aber sie erwarten pro Land einen eigenen Feed. Für jedes Zielland entsteht deshalb je ein eigener Google-Shopping-Feed und ein eigener Idealo-Feed – jeweils in Landessprache, Landeswährung und mit den dort gültigen Preisen, Versandkosten und Verfügbarkeiten. Ein einzelner deutscher Feed, der für alle Länder herhalten soll, führt zu Ablehnungen und falschen Preisen. Sauber getrennt lässt sich jeder Markt gezielt aussteuern.

Cross-Domain-Analytics: eine Customer Journey, mehrere Domains

Sobald mehrere Domains im Spiel sind, zerfällt die Messung – wenn man nichts unternimmt. Wechselt ein Nutzer von der .com- auf die .co.uk-Domain, zählt Analytics ihn standardmäßig als neuen Besuch aus einer fremden Quelle. Deshalb richten wir Cross-Domain-Tracking ein: Die Domains werden als ein zusammengehöriges Set konfiguriert, Referral-Ausschlüsse gepflegt und die Attribution über Domaingrenzen hinweg erhalten. Erst dann siehst du, welcher Kanal welchen Umsatz in welchem Land wirklich bringt.

Das größte Stück Arbeit: Sprachvariablen und Übersetzungen

Unterschätzt wird fast immer die schiere Textmenge. Zu übersetzen sind Artikel und Kategorien, dazu die Shop-Oberfläche, alle Sprachvariablen des Shops und seiner Plugins (Zahlarten, Hinweise, Fehlermeldungen) und sämtliche Transaktions-E-Mails, Shop- wie Wawi-seitig. Das sind schnell mehrere tausend Sprachvariablen und Textbausteine je Sprache. Von Hand ist das ein Projekt über Monate; vollständig „per Knopfdruck maschinell“ wird es unsauber. Wir gehen einen dritten Weg.

Sprachvariablen per SQL übersetzen: Shop und Wawi

Statt jede Vorlage einzeln im Backend anzufassen, ziehen wir die deutschen Quelltexte direkt aus den Datenbanktabellen: die Sprachvariablen der Plugins, die Sprachtabellen des Shops und die mehrsprachigen E-Mail-Vorlagen der Warenwirtschaft. Aus einer Arbeitsliste ist pro Textbaustein ersichtlich, welche Zielsprachen noch fehlen. Nach der Übersetzung werden die Ergebnisse als kontrollierte SQL-Batches zurückgeschrieben – tausende Strings in einem nachvollziehbaren Durchlauf, versioniert und wiederholbar, statt Klick für Klick.

Automatische Übersetzung mit Platzhalter-Schutz

Die eigentliche Übersetzung läuft über eine Übersetzungs-API (etwa DeepL oder ein LLM). Der entscheidende Schritt davor: Jeder String wird tokenisiert, damit Platzhalter und Technik unangetastet bleiben. Variablen wie {{OrderNumber}}, Zähler wie %d, HTML-Tags und Shortcodes werden erkannt und geschützt – übersetzt wird ausschließlich der echte Text dazwischen. So bleibt „Bestellung {{OrderNumber}} vom {{OrderDate}}“ in jeder Sprache funktionsfähig, statt dass die API den Platzhalter mitübersetzt und die E-Mail bricht.

Review dort, wo es zählt

Maschinell übersetzt heißt nicht ungeprüft veröffentlicht. Rechtstexte, Zahlungs- und Fehlermeldungen, Betreffzeilen und alles, was der Kunde im Kaufprozess sieht, gehen durch eine gezielte Sichtung. Der Rest – der große, unkritische Textkörper – ist nach dem automatisierten Durchlauf sofort brauchbar. So verschiebt sich der Aufwand von „alles selbst tippen“ zu „das Wichtige prüfen“.

Fazit

Internationalisierung im JTL-Shop ist ein Systemprojekt. Wer Domains, URLs, Versand, Zahlarten, Feeds, Analytics, Steuerlogik und die Übersetzung der Sprachvariablen als zusammenhängendes Ganzes plant, bekommt pro Land einen Auftritt, der lokal glaubwürdig ist und sauber messbar bleibt, aus einer einzigen, gepflegten Datenbasis in der JTL-Wawi. Die Sprache ist am Ende das kleinste Problem; die Prozesse dahinter entscheiden.