Die besten Markteinführungen sind diejenigen, bei denen man gar nicht merkt, dass sie stattgefunden haben.
Kein Last-Minute-Übersetzungschaos und kein Krisenraum … einfach eine neue Sprache, die ungefähr pünktlich live geht, während das Team sofort weitermacht.
Nenn es das Nicht-Ereignis: Lokalisierung, die an den Start geht, ohne dass es jemand bemerkt. Für Produktmanager globaler Produkte ist das das Ziel – und die Teams, die es erreichen, liegen oft näher, als vermutet wird. Es ist ein wenig so, als wäre man Torwart oder Schlagzeuger: Wenn man es richtig macht, bemerkt einen niemand. Aber was sie dorthin bringt, hängt weniger vom Budget oder den Werkzeugen ab, als vielmehr davon, wie das Setup der Lokalisierung von Anfang an gestaltet wurde.
Die meisten Teams fangen an, es manuell zu erledigen: Dateien, die über Slack geteilt werden, Übersetzer, die über verschiedene Zeitzonen gehetzt werden, oder Übergaben, die nur durch guten Willen zusammenhalten. Es funktioniert, bis das Produkt wächst und die Zahl der verbundenen Systeme steigt – ab dann gerät der manuelle Ansatz ins Hintertreffen. Im Folgenden wird die Lücke zwischen diesem Zustand und dem Nicht-Ereignis aufgezeigt, basierend auf Gesprächen mit vier Personen bei Phrase, die täglich daran arbeiten.
Skalierung ist zunächst ein Systemproblem, bevor es zu einem Sprachenproblem wird.
Das Erste, was es wert ist, überdacht zu werden, ist die Maßeinheit. Teams bemessen die Lokalisierung oft nach der Anzahl der Sprachen: Bei fünf Sprachen bleibt alles überschaubar, bei fünfzehn wird es ernst, und fünfundzwanzig erfordert einen ganz anderen Ansatz. Das ist das falsche Maß.
Wie Jozsef Hodos, ein Senior Product Manager im Integration-Team von Phrase, es ausdrückt: „Skalierung bemisst sich nicht danach, wie viele Sprachen unterstützt werden. Es kommt darauf an, wie viele Systeme verwaltet werden.“
Stell dir ein Team vor, das fünf Sprachen über ein halbes Dutzend Systeme hinweg betreut: ein CMS, ein Helpdesk, eine mobile Codebasis, ein Marketing-Tool und eine Dokumentationsseite. Es kann mehr leisten als ein Team, das fünfzehn Sprachen über eine gut konfigurierte Integration abwickelt.
Sprachen treiben das Übersetzungsvolumen an. Systeme führen zu Wartungsaufwand, der sich anhäuft, bis er letztlich die Agenda bestimmt.
Die entscheidende Frage gilt also den Systemen, nicht den Sprachen: Wie viele müssen miteinander kommunizieren, und wer ist der Ansprechpartner, wenn sich eines ändert?
Integrationen zu erstellen ist einfach. Aber sie zu warten ist kostenintensiv.
Wenn die manuelle Lokalisierung zu nerven beginnt, ist der erste Gedanke meist, etwas selbst zu bauen: einen benutzerdefinierten Konnektor, eine Punkt-zu-Punkt-API-Integration oder ein Skript, das Dateien von einem Ort zum anderen verschiebt. Das ist vernünftig. Das Team kennt seinen Stack, das Problem erscheint spezifisch und hausinterne Lösungen vermeiden weitere Abhängigkeiten von einem Auftragnehmer. Die erste Version funktioniert, und das Problem scheint gelöst. Dann vergeht Zeit.
Integrationen wie diese sind nicht schwer zu erstellen, sagt Jozsef, der das vergangene Jahr genau damit bei Kunden gearbeitet hat. Die Probleme treten erst später auf: „Sie sind in der Wartung extrem anspruchsvoll.“ Lokalisierung bringt Anforderungen mit sich, die ein Entwickler möglicherweise nicht erwartet – etwa wie sich das Layout bei rechts-nach-links-Schriften verhält oder wie Content strukturiert sein muss, um in einem Translation Memory nützlich zu bleiben. Sonderfälle, die während der Tests nie auftraten, tauchen in der Produktion auf, und da diese Integrationen einzeln entwickelt werden, bringt jede ihre eigenen Eigenheiten und den jeweiligen Wartungsaufwand mit.
Infrastrukturteams bezeichnen das als aufgeschobene Wartung: Kosten, die unbemerkt bleiben, solange alles funktioniert, und später in noch schlimmerer Form auftreten.
Übergeordnete wirtschaftliche Zusammenhänge verstärken diesen Effekt. Die Konnektor-Analyse von Nimdzi ergab, dass native Integrationen über zehn Hoch-TMS-Plattformen hinweg unter 13% der Business-Anwendungen erreichen – der Rest erfordert benutzerdefinierte Lösungen. Und bei benutzerdefinierten Lösungen liegen die versteckten Kosten. In seinem Bericht zum TMS-Markt 2026 warnt Nimdzi, dass Teams, die versucht sind, ihre eigenen Tools mit KI zu entwickeln, häufig den Zeitrahmen, die Komplexität und das Change Management für Erstellung, Einführung und Wartung solcher Tools unterschätzen. Die erste Version ist selten der teure Teil.
Wo native Integrationen noch echten Nachbesserungsbedarf haben.
Die Alternative besteht darin, native Integrationen zu verwenden – Konnektoren, die von der Plattform gepflegt werden. Das eliminiert sowohl Aufbau als auch Wartungsaufwand und bringt eine neue Frage mit sich: Wie können sie optimal konfiguriert werden?
Noch korrekter wäre: Beispielsweise die automatisierte Projekteerstellung, die neuen Content in einer verbundenen Plattform über eine Integration erkennt und automatisch ein Übersetzungsprojekt startet. Wird es gut umgesetzt, dann wird Lokalisierung nahezu unsichtbar: Content erscheint, ein Projekt wird gestartet und Übersetzungen kommen zurück. In der Praxis erklärt Tomáš Doischer, Teamleiter für Integrationen bei Phrase, dass die meisten Setups einen zweiten Durchlauf benötigen, um richtig zu funktionieren. Jede Umgebung ist so unterschiedlich, dass keine Vorlage perfekt passt – ganz gleich, wie erfahren das Team ist.
Es gibt eine organisatorische Dimension, die selten genug Aufmerksamkeit erhält. Lokalisierungsmanager sind Experten – allerdings liegen die Systeme, mit denen sie arbeiten, meist in den Händen anderer Abteilungen: das CMS beim Web-Team, das CRM im Vertrieb und das Laufwerk, auf dem das Marketing seine Assets verwaltet. Das Einrichten einer Integration erfordert Anmeldeinformationen und Zugriff, die ein Lokalisierungsmanager oft nicht allein gewähren kann – das führt zu Abhängigkeiten zwischen Teams, die nicht täglich zusammenarbeiten.
Der Administrator, der beide verknüpfen könnte, ist bis Donnerstag im Urlaub. Dort liegt die eigentliche Arbeit – und das zu wissen, bevor man anfängt, ist Gold wert.
Warum Vorbereitung mehr zählt als technische Leistungsfähigkeit
Alejandro Medina, Enterprise Solutions Architect bei Phrase, hat genügend dieser Projekte geleitet, um zu wissen, was reibungslose von schmerzhaften Projekten trennt – und es ist nicht primär die technische Leistung: „Die spezifische Rolle oder der technische Hintergrund der Beteiligten bestimmt den Erfolg nicht. Am wichtigsten ist, das Kundenumfeld zu verstehen und die richtigen Fragen zu stellen.“
Er beschreibt zwei Teams mit nahezu identischen Setups. Eines integrierte GitHub über vier Repositories hinweg. Bevor sie etwas konfigurierten, studierten sie die Dokumentation und entdeckten ein Problem: Die Arbeit in Pull-Request-Branches, deren Namen sich bei jedem Release ändern, kollidiert mit der Art, wie die Integration den Content verfolgt. Also gestalteten sie zunächst den Workflow um, planten Importe über die Integration und führten Exporte über GitHub Actions durch. Das zweite Team, fast das gleiche Setup, stieß Wochen nach dem Livegang auf das gleiche Problem. Gleiche Integration, eine ganz andere Woche.
Die Kehrseite einer guten Planung ist das, was damit möglich wird. Die Figma-Integration von Phrase mit Phrase Strings ist ein schönes Beispiel: Wenn Designer Übersetzungsschlüssel in Figma erstellen, zieht die Integration Screenshots und hebt automatisch die Position jedes Strings hervor. Übersetzer sehen die Ausgangssprache in ihrem echten visuellen Kontext – etwa einer Schaltfläche oder eines Einstellungsbildschirms – ohne dass jemand alles manuell vorbereiten muss, sodass niemand raten muss, was „btn_confirm_2“ bedeutet. Der Kontext begleitet den Content.
Wie Francesca Sorrentino, unsere Leiterin der Lokalisierung, es ausdrückt: „Integrationen bilden die Grundlage.“ Aber sie lösen nicht jedes Problem in einem vollständigen Anwendungsfall. Die Teams, die das richtig machen, verstehen, wofür die Integration gedacht ist, und bauen entsprechend darum herum.“
Die Teams, die richtig gute Arbeit leisten, sind nicht die technisch versiertesten. Sie sind diejenigen, die ihr eigenes Setup verstehen, bevor sie es automatisieren, und – mehr als jeder Konnektor – sorgen dafür, dass ein Launch entspannt verläuft.
Je früher Produktmanager ins Boot geholt werden, desto kleiner wird das Problem
Produktmanager tauchen meist erst auf, wenn etwas schief läuft. Dann erweisen sie sich oft als die einzigen, die genau sehen, wie die Systeme zusammenhängen und was die Funktion wirklich bewirken soll. Aber bis dahin ist der Rahmen gesetzt und der beste Beitrag schon vorbei.
Was sich ändert, wenn sie frühzeitig einbezogen werden, ist, dass die für die Lokalisierung wichtigsten Informationen bei ihnen angesiedelt sind: Was die Funktion bewirkt, wo der Content erscheint und welche Märkte abgedeckt werden. Bei der Lokalisierung kommt selten etwas in strukturierter Form an. Ein Entwickler bearbeitet ein Ticket, erstellt die Keys und pusht den Code. Der Lokalisierungsmanager bekommt die Keys, und der Kontext, der es ihm erlauben würde, Übersetzer vorab zu informieren, verschwindet.
Dieser fehlende Kontext unterscheidet einen Übersetzer, der weiß, was eine Zeichenfolge bedeutet, von einem, der nur anhand eines Key-Namens vermutet.
Marty Cagan und Bob Baxley, die im Blog der Silicon Valley Product Group über globales Produktmanagement schreiben, benennen den Fehler: Lokalisierung wird als nachgelagerte Übergabe behandelt statt als ein Anliegen der Plattform – etwas, das von Anfang an bedacht werden sollte, anstatt es nachträglich anzubringen. Aude Moras, Head of Product bei Tablecheck, drückt es direkter aus: Du willst dich nicht auf den Markt vorbereiten und dann zwei Wochen vor dem Start anfangen, über Lokalisierung nachzudenken.
Die Version von Tomáš Doischer (Team Lead, Integrations bei Phrase) kommt zum gleichen Ergebnis. Er sagt, der Fehler, den er am häufigsten sieht, ist, dass Teams ihren alten Workflow in einem neuen System nachbilden, anstatt zu fragen, wofür er gedacht war: „Den alten Prozess eins zu eins auf ein neues System zu übertragen, ist, als würde man versuchen, ein Rezept für Pizza auf die Zubereitung von Hamburgern anzuwenden.“ Der Fokus sollte darauf liegen, welches Problem der bestehende Prozess gelöst hat. Im Anschluss sollte das Konzept so gestaltet werden, dass dieses Ergebnis erzielt wird.
Meiner Ansicht nach ist dies der entscheidende Beitrag des Produktmanagers:
Lange bevor es brennt, werden Timing und Produktkontext frühzeitig eingebracht, sodass die Lokalisierung von Anfang an berücksichtigt wird – statt erst am Ende mit der Forderung, sie bis Freitag global umzustellen.
So funktioniert es in der Praxis:
Die Integrationen von Phrase zeigen das Konnektor-Ökosystem und wie die automatisierte Projekterstellung darin funktioniert.
