Ein neues Backend-Feld für Mehrsprachigkeit ist schnell angelegt. Der Teil, der danach Monate dauert…
Internationalisierung im E-Commerce: Die 9 Frontend-Baustellen, die dir kein Backend abnimmt
Ein neues Backend-Feld für Mehrsprachigkeit ist schnell angelegt. Der Teil, der danach Monate dauert, sitzt im Frontend. Locale-Routing, hreflang, Zahlenformate, RTL-Layouts, Zahlungsarten, Versandversprechen und Rechtstexte lassen sich nicht durch ein Datenbank-Flag lösen, sie sind Rendering-Entscheidungen, Layout-Entscheidungen und Content-Modeling-Entscheidungen, die direkt im Storefront getroffen werden. Wer Internationalisierung als reines Übersetzungsprojekt plant, stößt spätestens beim zweiten Markt auf eine Liste von Baustellen, die vorher niemand aufgeschrieben hat. Dieser Beitrag ist genau diese Liste: neun konkrete Frontend-Baustellen, die bei jedem Markteintritt wiederkehren, mit dem jeweiligen Lösungsansatz auf Frontend-Ebene. Übersetzungs-Tooling und die Entscheidung zwischen maschineller und menschlicher Übersetzung behandeln wir hier nur kurz, dafür gibt es eigene, tiefere Beiträge, auf die wir verweisen. Jede einzelne Baustelle ist für sich genommen lösbar, das Problem entsteht fast immer dadurch, dass Teams sie parallel und ohne gemeinsame Schema-Entscheidung angehen, ein Team kümmert sich um Übersetzung, ein anderes um Payment, ein drittes um Recht, und am Ende zeigt keiner der drei, wo Locale und Content tatsächlich zusammenlaufen.
1. Locale-Routing und URL-Struktur
Das Problem beginnt vor jedem Content: Läuft ein Markt unter einem Subdirectory, einer Subdomain oder einer eigenen ccTLD, und löst das Frontend diese Struktur konsistent auf, ohne den kompletten Seitenbaum pro Markt zu duplizieren? In der Praxis wächst die Duplikation genau dort, wo Routing und Content-Locale nicht denselben Datensatz referenzieren, jede neue Landingpage muss dann von Hand in jeder Marktversion nachgezogen werden. Der tragfähige Ansatz ist ein einziger Komponentenbaum, dessen Locale-Variante beim Rendern aus derselben Content-Quelle aufgelöst wird, nicht ein pro Markt geforktes Set an Templates. Genau das ist der praktische Grund, Multi-Brand und Multi-Market als Plattform-Eigenschaft zu behandeln statt als Projekt-Build pro Land. Für die Locale-Kennung selbst lohnt sich ein Blick auf den IETF-Standard BCP 47, der Sprach-Tags wie `de-DE` oder `de-AT` definiert, statt eigene Kürzel zu erfinden, die spätestens beim vierten Markt kollidieren.
2. hreflang und Canonical-Tags
hreflang funktioniert laut Googles eigener Dokumentation nur als reziprokes, sich selbst referenzierendes Set: Jede Sprachversion muss auf jede andere verweisen, inklusive sich selbst, sonst ignoriert Google die Annotation ganz oder teilweise. Das lässt sich von Hand kaum sauber pflegen, sobald eine vierte oder fünfte Locale dazukommt. Wenn Locale-Routing und Content-Locale, wie in Baustelle 1 beschrieben, auf denselben Knoten zeigen, kann das Frontend das reziproke Set automatisch aus dieser einen Quelle generieren, statt eine separat gepflegte Mapping-Tabelle zu betreiben, die beim nächsten neuen Markt garantiert veraltet. Dazu gehört auch ein `x-default`-Eintrag für Besucher, deren Sprache zu keiner ausgelieferten Locale passt, sonst entscheidet der Zufall, welche Marktversion Google als Fallback zeigt.
3. Content- und Textübersetzung im Frontend
Übersetzung selbst ist eine der neun Baustellen, aber nicht die, an der die meisten Projekte hängen bleiben, wenn Schema und Rollen von Anfang an klar sind. Wie TMS, PIM und Komponenten-Schema sauber zusammenspielen, beschreiben wir ausführlich im Beitrag zum Übersetzungs-Workflow zwischen TMS, PIM und Komponenten-Schema. Ob ein Content-Typ maschinelle Übersetzung verträgt oder einen menschlichen Review-Schritt braucht, ist eine eigene Entscheidung pro Feld, die wir im Framework für maschinelle versus menschliche Übersetzung durchgehen. An dieser Stelle reicht der Hinweis: Ohne ein Übersetzbar-Flag pro Feld und einen stabilen Referenz-Key wird jede der folgenden acht Baustellen schwerer zu lösen, weil sich Inhalt und Layout gegenseitig blockieren.
4. Textexpansion und Layout-Stabilität
Deutsche und finnische Strings laufen spürbar länger als ihr englisches Original, und eine Komponente, die nur gegen englische Wortlängen getestet wurde, bricht zuverlässig, sobald die erste lange Übersetzung ankommt. Der Fix ist kein Übersetzungsproblem, sondern ein Component-Review-Schritt: jeder Prop, der übersetzten Text annimmt, bekommt ein Zeichen-Budget und ein definiertes Umbruch- oder Kürzungsverhalten, getestet gegen einen Worst-Case-Platzhalter, bevor überhaupt eine echte Übersetzung existiert. Fixe Höhen für Buttons und Labels sind in einem internationalen Storefront eine Wette, die man verliert, sobald ein Markt mit langen zusammengesetzten Wörtern dazukommt. Ein deutsches Wort wie „Versandkostenfrei" ist auf Englisch drei kürzere Wörter, und ein Label-Container, der nur für „Free" gebaut wurde, muss entweder umbrechen dürfen oder die Schrift verkleinern, statt den Text abzuschneiden.
5. RTL-Sprachen und Bidi-Rendering
Arabisch oder Hebräisch sind nicht einfach rechtsbündiger Text, sie kehren die gesamte Leserichtung der Seite um: Navigation, Warenkorb-Icon, Formularfelder, Slider-Pfeile, alles spiegelt sich. Die Grundlage dafür ist der Unicode Bidirectional Algorithm, der festlegt, wie gemischt links- und rechtsläufiger Text im selben Absatz aufgelöst wird. Ein Frontend, das Abstände und Ausrichtung mit `margin-left` statt mit logischen CSS-Properties wie `margin-inline-start` definiert, muss für jede RTL-Locale einen eigenen Style-Zweig pflegen. Wer von Anfang an mit logischen Properties und dem `dir`-Attribut auf Komponentenebene arbeitet, bekommt RTL faktisch geschenkt, sobald die erste arabische oder hebräische Locale live geht. Ein einfacher Test dafür: den Storefront einmal komplett mit `dir="rtl"` auf dem Root-Element öffnen und schauen, welche Icons und Abstände stur links bleiben, statt sich zu spiegeln.
6. Währung, Zahlen- und Datumsformate
Ein Preis, ein Datum und eine Telefonnummer sehen in jedem Markt anders aus, Dezimaltrennzeichen, Tausendertrenner, Datumsreihenfolge und Währungsposition variieren unabhängig von der Sprache selbst. Der Unicode CLDR-Standard bündelt genau diese Formatierungsregeln pro Locale, und Standard-APIs wie `Intl` bauen direkt darauf auf. Das Problem entsteht, sobald Formate hart im Template verdrahtet oder aus dem Backend als fertiger String geliefert werden, statt sie an der Komponentengrenze aus Rohwert plus Locale zu berechnen. Sobald ein Markt dazukommt, muss dann jede betroffene Komponente einzeln gepatcht werden, statt dass die Locale-Auflösung automatisch mitläuft. Ein Preis wie „1.234,56 €" in Deutschland und derselbe Wert als „€1,234.56" in einem anderen Markt ist keine Ausnahme, sondern die Regel, sobald Dezimal- und Tausendertrennzeichen die Rollen tauschen, und genau dafür ist CLDR gedacht, nicht für eine hausgemachte Formatierungsfunktion pro Team.
7. Marktspezifische Zahlungsarten im Checkout
iDEAL ist in den Niederlanden Standard, Klarna dominiert in Teilen Skandinaviens, Bancontact in Belgien, in anderen Märkten wiederum spielt keine dieser Optionen eine Rolle. Ein Checkout-Frontend, das die Zahlungsarten-Liste hart codiert, statt sie konfigurierbar pro Markt zu laden, zwingt jede neue Zahlungsart zu einem eigenen Deploy. Der belastbarere Ansatz ist ein Checkout-Baustein, der Zahlungsarten als Konfiguration pro Markt aus dem Growth Kit für den Checkout zieht, statt sie im Component-Code zu verankern, sodass ein neuer Provider ein Konfigurationseintrag ist und kein Release. Das betrifft nicht nur die Zahlungsart-Icons im Checkout, sondern auch, welcher Anbieter überhaupt als Default vorausgewählt ist, denn die Reihenfolge selbst beeinflusst die Conversion pro Markt.
8. Lieferversprechen und Versandlogik pro Markt
Ein Lieferversprechen, das im Heimatmarkt stimmt, verschiebt sich im nächsten Markt durch Zoll, Mehrwertsteuer-Schwellen oder schlicht andere Carrier-Laufzeiten. Wenn die Versandzeile im Frontend als statischer Text im Template liegt statt als datengetriebener Block, der an Versandzone und Lager gebunden ist, bekommt jeder neue Markt ein falsches Versprechen auf der Produktseite, bis jemand es manuell korrigiert. Das gehört in dieselbe Kategorie wie Preis und Zahlungsart: ein Frontend-Baustein, der Locale und Versandzone gemeinsam auflöst, statt sie getrennt zu pflegen. Für Handelsteams, die genau das über mehrere Märkte hinweg orchestrieren, ist das der Kernfall unter den E-Commerce-Lösungen. Zoll- und Schwellenwert-Regeln ändern sich zudem regelmäßig pro Markt, weshalb die Versandzeile ein Content-Feld mit Redaktionsprozess sein sollte, nicht eine Konstante im Quellcode.
9. Rechtstexte pro Markt
Impressum, AGB und Widerrufsrecht unterscheiden sich zwischen Deutschland, Österreich, der Schweiz und Frankreich in Formulierung und teils in Inhalt, und ein global ausgerolltes Rechtstext-Template ist im Zweifel in mindestens einem Markt falsch. Das ist kein Frontend-Problem allein, aber das Frontend entscheidet, ob Rechtstexte als versionierte, marktspezifische Content-Objekte behandelt werden oder als eine hart codierte Seite, die niemand mehr aktualisiert, sobald der Launch vorbei ist. Rechtstexte gehören in eine Content-Management-Struktur mit klarer Marktzuordnung und Versionshistorie. Wichtig an dieser Stelle: Das ist eine Aussage zur Content-Architektur, keine Rechtsberatung, die tatsächlichen Anforderungen pro Markt klärt ihr mit eurer Rechtsabteilung oder externer Beratung. Dasselbe gilt für Cookie-Banner und Consent-Texte, die je nach Markt an unterschiedliche gesetzliche Vorgaben gebunden sind und deshalb dieselbe versionierte Content-Struktur brauchen wie Impressum und AGB.
Wo das ins Frontend passt
Keine dieser neun Baustellen wird durch ein einzelnes Tool gelöst, sie sind alle Ausdruck derselben Grundfrage: Wo lebt die Entscheidung, was sich pro Markt unterscheidet, und wo lebt die Entscheidung, was überall gleich bleibt? Unter unserer Composable Headless Frontend-Architektur laufen Routing, Formatierung, Zahlungsarten-Konfiguration und Rechtstext-Content über dieselbe Komponentenschicht, statt über neun getrennte Sonderlösungen pro Markt. Wie stark lokales Vertrauen den Umsatz in internationalen Storefronts tatsächlich beeinflusst, zeigen wir separat im Beitrag zu lokalem Vertrauen in internationalen Storefronts. Als Composable DXP entkoppeln wir diese Entscheidungen bewusst vom jeweiligen Backend, damit ein neuer Markt an der Frontend-Ebene startet und nicht an einem weiteren Custom-Fork des gesamten Stacks.
Häufig gestellte Fragen
Muss ich alle neun Baustellen vor dem ersten neuen Markt lösen? Nein. Locale-Routing, hreflang und die Übersetzbar-Flags im Schema sind die Grundlage, auf der die übrigen sechs Baustellen aufbauen. Zahlungsarten und Versandlogik lassen sich oft pro Markt nachziehen, wenn die Schema-Entscheidung von Anfang an sauber ist.
Ist RTL nur relevant, wenn wir aktiv in RTL-Märkte expandieren? Für die meisten DACH-Storefronts kurzfristig nein. Aber logische CSS-Properties statt physischer kosten am Anfang nichts zusätzlich, während sie im Nachhinein ein eigenes Refactoring-Projekt sind.
Ersetzt dieser Beitrag eine rechtliche Prüfung der Rechtstexte? Nein. Baustelle 9 beschreibt, wie Rechtstexte im Frontend als Content-Struktur organisiert werden sollten, nicht welche Formulierungen rechtlich korrekt sind. Das bleibt Aufgabe eurer Rechtsabteilung.
Was ist mit Bildern und Produktmedien pro Markt? Bild-Lokalisierung ist real, ein Verpackungsfoto mit lateinischer Beschriftung passt nicht in jeden Markt, und Models oder Kontext-Bilder wirken nicht überall gleich. Wir behandeln sie hier bewusst nicht als eigene Baustelle, weil die Lösung dieselbe ist wie bei Rechtstexten: Medien gehören als marktspezifisch zuordenbare Content-Objekte ins Schema, nicht als hart verlinkte Datei im Template.
Nächste Schritte
Wenn ihr gerade den zweiten oder dritten Markt aufbaut und merkt, dass Locale-Entscheidungen quer durch euer Frontend verstreut liegen, bucht eine 30-minütige Demo. Wir schauen uns eure aktuelle Locale-Struktur an und zeigen, welche der neun Baustellen bei euch am dringendsten sind.
Mehr von der Laioutr-Plattform
Über den Autor: Marcel Thiesies ist Co-Founder von Laioutr und beschäftigt sich damit, wie Internationalisierung im Frontend tatsächlich skaliert, jenseits des einzelnen Übersetzungs-Tickets.