Ein neues Backend-Feld für Mehrsprachigkeit ist schnell angelegt. Der Teil, der danach Monate dauert…
Übersetzungs-Workflow im Frontend: TMS, PIM und Komponenten-Schema zusammenschalten
Die meisten Übersetzungsfehler sind keine Übersetzungsfehler. Sie sind Übergabefehler zwischen drei Systemen, die sich nie darauf geeinigt haben, wer wofür zuständig ist. Das Translation-Management-System, kurz TMS, verschiebt Strings von einer Ausgangssprache in eine Zielsprache. Das Product-Information-Management-System, kurz PIM, verwaltet die Produktdaten. Das Komponenten-Schema im Frontend entscheidet, was am Ende tatsächlich gerendert wird, und wie. Wenn diese drei Systeme sich nicht einig sind, welche Felder überhaupt übersetzbar sind, wo lokalisierte Inhalte tatsächlich liegen und wie viel Platz ein übersetzter String einnehmen darf, zeigt sich der Fehler selten im TMS selbst. Er zeigt sich im Browser: ein deutsches Button-Label, das in drei Zeilen umbricht, eine französische Produktbeschreibung, die in einem Layout sitzt, das für englische Wortlängen gebaut wurde, ein Locale-Switch, der still auf die falsche Seite zeigt. Dieser Beitrag zeigt praktisch, wie ihr TMS, PIM und Komponenten-Schema so zusammenschaltet, dass Übersetzung nicht mehr am Frontend zerbricht.
Was tatsächlich bricht (selten die Übersetzung selbst)
Fragt ein Team, woher der letzte Lokalisierungs-Bug kam, lautet die Antwort fast nie schlechte Übersetzung. Es ist meist einer von vier Wiederholungstätern. Erstens Textexpansion: Übersetzte Strings, besonders ins Deutsche, laufen spürbar länger als die englische Quelle, und eine Komponente, die für einen Button mit fester Breite oder ein einzeiliges Label gebaut wurde, bricht, sobald ein längerer String hineinläuft. Zweitens PIM-Attribute, die nie als Fließtext gedacht waren, werden trotzdem wie übersetzbarer Content behandelt, sodass ein strukturiertes Feld für eine SKU oder einen Spec-Wert plötzlich Marketing-Sätze trägt, für die niemand modelliert hat. Drittens driften Locale-Routing und Content-Locale auseinander: Eine Seite rendert im CMS-Preview korrekt, löst in der Produktions-Route aber die falsche Locale auf, weil niemand beide Systeme auf Schema-Ebene verbunden hat. Viertens, und am häufigsten, schleicht sich Scope-Creep im Komponenten-Schema selbst ein: Ein Status-Label, das eigentlich auf ein Design-Token gemappt ist, wird nach und nach von einem Redakteur trotzdem übersetzt, weil nichts im Schema das verhindert. Keiner dieser vier Fälle ist ein Qualitätsproblem der Übersetzung. Es sind Übergabeprobleme, und sie werden einmal auf Schema-Ebene gelöst, nicht einmal pro Locale.
Drei Systeme, drei unterschiedliche Aufgaben
Sobald das Übergabeproblem sichtbar ist, ist die Lösung vor allem eine Frage klarer Zuständigkeit. Die Aufgabe des PIM ist kanonische Produktdaten: SKUs, Maße, Preisregeln, Kategorie-Codes, Werte, die überall identisch bleiben. Das meiste davon sollte nie in einen Übersetzungs-Workflow laufen, weil es nicht sprachabhängig ist. Die Ausnahme ist ein Feld, das eigentlich Marketing-Text ist, aber den Namen eines PIM-Attributs trägt, etwa eine lange Produktbeschreibung. Dieses Feld muss als Content behandelt und durch Übersetzung geroutet werden, auch wenn es technisch direkt neben der SKU liegt. Die Aufgabe der Content-Ebene, egal ob CMS oder komponentenbasierter Page-Builder, ist redaktioneller Inhalt: Landingpages, Kampagnen-Texte, Blog-Beiträge, pro Markt verfasst mit einem vollständigen Lokalisierungs-Workflow dahinter. Die Aufgabe des Komponenten-Schemas im Frontend ist es, den Vertrag zu definieren: welche Props übersetzten Rich Text annehmen, welche einen fixen Wert annehmen, der sich nie nach Locale unterscheiden darf, und wie viel Länge ein übersetzbarer Prop tragen kann, bevor das Layout bricht. Die Aufgabe des TMS ist reine Orchestrierung, keine Eigentümerschaft. Es holt sich markierte, mit Keys versehene Strings aus der Quell-Locale, schickt sie durch einen Übersetzungsauftrag und schreibt das Ergebnis unter demselben Key in die Ziel-Locale zurück. Sobald ein TMS zu einem zweiten Ort wird, an dem Content tatsächlich lebt, hat die Locale-Drift bereits begonnen.
Übersetzbare Felder auf Schema-Ebene deklarieren, nicht in einer Tabelle
Die Lösung für die meiste Zuständigkeits-Verwirrung ist bewusst unspektakulär: Jedes Feld in einem Content-Modell sollte ein explizites Lokalisierungs-Flag tragen, übersetzbar oder fix, einmal entschieden, wenn das Feld angelegt wird, nicht neu verhandelt von wem auch immer gerade einen Übersetzungsauftrag betreut. Diese Entscheidung gehört denen, die Komponenten-Management und Content-Modeling verantworten, nicht einer separat gepflegten Tabelle des Lokalisierungs-Teams. Daraus folgen zwei praktische Regeln. Erstens braucht jeder übersetzbare String einen einzigen, stabilen Source-Key, den Content-Ebene und TMS identisch referenzieren, damit ein Übersetzungs-Roundtrip nie still eine zweite, driftende Kopie des Inhalts erzeugt. Zweitens sollten Localisations auf denselben zugrunde liegenden Content-Node über alle Locales hinweg verweisen, statt pro Locale einen neuen Node zu forken, denn ein geforkter Node ist das Versprechen, zwei Dokumente von Hand synchron zu halten, und dieses Versprechen bricht spätestens im nächsten Quartal.
Layout-Brüche durch Textexpansion verhindern
Textexpansion ist kein Übersetzungsfehler, sondern eine Design-Annahme, die nie gegen etwas anderes als die englische Quelle getestet wurde. Deutsche UI-Strings laufen spürbar länger als ihr englisches Pendant, manchmal so viel länger, dass ein Layout bricht, das nur mit englischen Wortlängen bewiesen wurde. Drei Gewohnheiten verhindern das meiste davon. Erstens: Jeder Komponenten-Prop, der übersetzten Text annimmt, bekommt ein explizites Zeichen-Budget als Teil seiner Schema-Definition, nicht nur einen Datentyp. Ein Button-Label-Prop ist nicht einfach ein String, sondern ein String mit einer maximal sinnvollen Länge, bevor der Button wachsen oder das Label kürzen muss. Zweitens: Neue Komponenten werden gegen einen Platzhalter mit Worst-Case-Länge getestet, manchmal Pseudo-Lokalisierung genannt, im Component-Review, bevor überhaupt eine echte Übersetzung existiert. Erst bei der deutschen Übersetzung einen Layout-Bug zu entdecken, ist der teuerste Weg, ihn zu finden. Drittens: Flexible Container mit definiertem Umbruch- oder Line-Clamp-Verhalten sind fixen Höhen für jeden übersetzbaren Text-Prop vorzuziehen, und übersetzbarer Text darf nie in ein Bild-Asset gebacken werden. Sobald eine Textänderung ein Bild neu rendern muss, wird aus einer Copy-Änderung ein Design-Ticket.
Wie Locale-Routing an dieselbe Schema-Entscheidung zurückgebunden ist
Routing wird meist einmal, früh, von wem auch immer das Frontend aufgesetzt hat, gebaut und danach von allen anderen vergessen. Genau das ist das Problem: Eine URL sollte auf die Locale auflösen, die zum tatsächlich lokalisierten Content dahinter passt, nicht auf den Markt, für den das Frontend ursprünglich gebaut wurde. Wenn das Schema bereits festlegt, welche Felder übersetzbar sind, muss die Routing-Schicht diese Locale-Variante auflösen können, ohne den gesamten Seitenbaum pro Markt zu duplizieren. Das ist das praktische Argument dafür, Multi-Brand und Multi-Market als Plattform-Eigenschaft zu behandeln statt als Pro-Projekt-Build: ein Komponentenbaum, dessen Locale-spezifische Daten erst beim Rendern aufgelöst werden, statt eines pro Markt geforkten Frontends, das jemand von Hand synchron halten muss. Stimmen Schema, Content-Ebene und Routing-Schicht auf dieselbe Quelle der Wahrheit überein, folgt Hreflang-Korrektheit meist von selbst. Bleiben sie getrennt, wird Hreflang zu einer manuell gepflegten Mapping-Tabelle, die veraltet, sobald jemand eine neue Locale hinzufügt.
Fünf Schritte, um alles zusammenzuschalten
Nichts davon erfordert einen Neubau. Es erfordert eine kurze, bewusste Reihenfolge, meist ein Content-Modell nach dem anderen statt als ein einziges Migrationsprojekt.
- Auditiert euer Content-Modell und markiert jedes Feld als übersetzbar oder fix auf Schema-Ebene, nicht in einer Wiki-Seite oder einer separat gepflegten Tabelle.
- Verschiebt Marketing-Texte, die aktuell in PIM-Attributfeldern liegen, in eine echte Content-Ebene mit Lokalisierungs-Support, und beschränkt das PIM selbst auf kanonische, größtenteils nicht übersetzbare Daten.
- Gebt jedem übersetzbaren String einen stabilen Key, den sowohl Content-Ebene als auch TMS referenzieren, damit ein Übersetzungs-Roundtrip nie einen zweiten, konkurrierenden Datensatz desselben Inhalts erzeugt.
- Legt für jeden Komponenten-Prop, der übersetzten Text annimmt, ein Zeichen-Budget und eine Umbruch- oder Kürzungs-Strategie fest, und prüft neue Komponenten gegen einen Worst-Case-String, bevor eine echte Übersetzung existiert.
- Verbindet Locale-Routing direkt mit der Content-Locale, sodass ein Locale-Wechsel denselben Komponentenbaum mit anderen Daten auflöst, statt auf einen separaten Seitenbaum zu routen, der mit der Zeit auseinanderdriftet.
Geht diese fünf Schritte der Reihe nach durch, und das meiste, was auf dem Ticket-Board wie ein Übersetzungsproblem aussieht, entpuppt sich als Schema-Problem.
Wie das in eine größere Frontend-Architektur passt
Wir versuchen nicht, ein TMS oder ein PIM zu ersetzen, und Teams, die das erwarten, suchen an der falschen Stelle. Was wir unter der Agentic Frontend Management Platform bauen, ist die Schicht, an der die Ergebnisse beider Systeme tatsächlich auf die gerenderte Seite treffen: ein Komponenten-Schema, das weiß, welche Props übersetzbar sind, bevor ein übersetzter String überhaupt ankommt, und eine Content-Management-Ebene, die genau für den oben beschriebenen Lokalisierungs-Workflow gebaut ist, statt eines generischen CMS, das nachträglich auf ein starres Frontend geschraubt wurde, das nie mit Locales im Kopf entworfen wurde. Für Teams, die Content aktuell über ein Headless CMS auf einem monolithischen Frontend laufen lassen, ist das meist der schnellste Startpunkt: kein neues TMS, kein neues PIM, sondern eine Schema-Schicht, die beiden endlich sagt, was sie wissen müssen.
Häufig gestellte Fragen
Ersetzt Laioutr unser PIM oder TMS? Nein. Laioutr sitzt auf der Frontend- und Komponenten-Ebene, wo die Ergebnisse beider Systeme tatsächlich gerendert werden. Euer PIM bleibt die Quelle kanonischer Produktdaten, euer TMS bleibt die Orchestrierungs-Schicht, die Strings durch einen Übersetzungsauftrag schickt.
Wo sollte Marketing-Text liegen, im PIM oder in der Content-Ebene? In fast jedem Fall in der Content-Ebene. Beschränkt das PIM auf strukturierte, größtenteils nicht übersetzbare Daten. Eine lange Produktbeschreibung ist Content, kein Attribut, auch wenn sie aktuell direkt neben der SKU liegt.
Wie testen wir Textexpansions-Probleme, bevor überhaupt eine Übersetzung existiert? Prüft neue Komponenten während Design und Entwicklung gegen einen Platzhalter mit Worst-Case-Länge, nicht gegen die englische Standardversion. Das wird oft Pseudo-Lokalisierung genannt und deckt Layout-Brüche Wochen auf, bevor eine echte Übersetzung existiert.
Behebt das auch lokale SEO-Probleme? Indirekt ja. Sobald Schema, Content-Ebene und Routing-Schicht auf dieselbe Quelle der Wahrheit einigen, folgt Hreflang-Korrektheit meist automatisch. Das ist ein Nebeneffekt, nicht der Hauptgrund für diese Arbeit.
Nächste Schritte
Wenn euer Team gerade einen Übersetzungs-Workflow entwirrt, der immer wieder am Frontend bricht, bucht eine 30-minütige Demo. Wir schauen uns euer aktuelles Content-Modell an, euer PIM-Setup, und wo die Schema-Schicht dazwischen nachziehen muss.
Mehr von der Laioutr-Plattform
Über den Autor: Marcel Thiesies ist Co-Founder von Laioutr und beschäftigt sich damit, wie Übersetzung, Produktdaten und Frontend-Schema in produktiven Storefronts tatsächlich zusammenspielen.