Das Problem, das niemand auf dem Schirm hat
Wenn Unternehmen den Aufwand für einen neuen Markt-Store schätzen, denken sie an Produkte, Theme und Design. An die Übersetzungen denkt fast niemand — bis sie zum Flaschenhals werden.
Der Grund: In Shopify sind Übersetzungen keine Eigenschaft eines Produkts, sondern eine eigene Datenebene, die sich quer durch den ganzen Store zieht. Ein internationaler Store kommt schnell auf über 12.000 Translation-Einträge. Und jeder einzelne ist eine potenzielle Bruchstelle.
Warum es nicht nur um Produkttexte geht
Die naheliegende Annahme lautet: Übersetzt werden Produkttitel und Beschreibungen. Tatsächlich kennt Shopify mehrere übersetzbare Resource-Types, und sie alle müssen mitwandern, wenn der neue Store vollständig sein soll:
Produkte und Varianten. Titel, Beschreibungen, Optionsnamen, Variantenbezeichnungen. Der offensichtliche Teil — und meist nicht einmal der größte.
Collections. Titel und Beschreibungen jeder Collection, oft mit eigenem Marketing-Text pro Markt.
Theme-Inhalte. Alle statischen Texte aus dem Theme: Button-Beschriftungen, Hinweise, Hilfetexte, Fehlermeldungen. Diese stecken in den Locale-Dateien und werden beim reinen Datenexport gerne vergessen.
Metaobjects. Sobald Inhaltsblöcke über Metaobjects gepflegt werden, haben auch die übersetzbare Felder. Ein häufig übersehener Resource-Type.
Pages, Blogs und Articles. Der gesamte redaktionelle Content, jeweils in allen aktiven Sprachen.
Über die translatableResource-API hängen all diese Übersetzungen an den jeweiligen Objekten — und genau hier entsteht das Folgeproblem.
Warum manuelles Patchen scheitert
Übersetzungen hängen an IDs. Eine Produktübersetzung gehört zu einer Produkt-ID, eine Metaobject-Übersetzung zu einer Metaobject-ID. Im neuen Store sind diese IDs andere. Wer Übersetzungen per CSV exportiert und importiert, muss also jede einzelne Übersetzung dem richtigen neuen Objekt zuordnen.
Bei ein paar hundert Einträgen ist das machbar, wenn auch mühsam. Bei 12.000 Einträgen passiert zwangsläufig eines von beidem: Es dauert tagelang, oder es schleichen sich Fehler ein. Und Übersetzungsfehler sind heimtückisch. Ein verrutschter Eintrag fällt im deutschen Test nicht auf — wohl aber dem Kunden in Japan, der plötzlich einen deutschen Button sieht oder eine leere Produktbeschreibung.
Das ist der Moment, in dem ein Markt-Launch nicht am Launch-Tag scheitert, sondern leise im Betrieb.
Wie eine saubere Übertragung funktioniert
Der Schlüssel ist, Übersetzungen nicht als losen Datenhaufen zu behandeln, sondern an die migrierten Objekte zu binden. Während die Produkte, Collections und Metaobjects in den neuen Store wandern, wird über eine ID-Map festgehalten, welche alte ID welcher neuen entspricht. Die Übersetzungen werden anschließend über die translatableResource-API genau diesen neuen Objekten zugeordnet.
So bleibt die Verbindung erhalten, ohne dass jemand 12.000 Zeilen von Hand prüft. Und weil die ganze Übertragung anschließend durch automatisierte Tests läuft, fällt eine fehlende oder falsch zugeordnete Übersetzung auf, bevor der Store live geht — nicht erst durch eine Kundenbeschwerde.
Wie dieses Zusammenspiel aus ID-Auflösung und Test im Gesamtbild aussieht, steht in Shopify-Store duplizieren.
Fazit
Übersetzungen sind die unterschätzte Bruchstelle beim Multi-Store-Launch. Sie betreffen fünf Resource-Types, hängen an IDs, die sich beim Storewechsel ändern, und sind genau die Art von Detail, das im Test übersehen wird und im Betrieb auffällt. Wer einen neuen internationalen Store aufsetzt, sollte die Übersetzungsebene von Anfang an mitdenken, nicht als letzten Schritt.
Was ein vollständiger Markt-Launch kostet und wie er abläuft, steht in Was kostet ein Shopify-Plus-Markt-Launch? und auf der Seite zum Markt-Launch-Paket. Wenn Ihr Store viele Sprachen führt, lassen Sie uns über den Umfang sprechen.
