Die besten Markteinführungen sind diejenigen, von denen man gar nicht merkt, dass sie überhaupt stattgefunden haben.
Kein Last-Minute-Übersetzungsstress und kein Krisenstab … einfach eine neue Sprache, die mehr oder weniger pünktlich online geht, während das Team sich schon der nächsten Aufgabe widmet.
Nennen wir es das Nicht-Ereignis: eine Lokalisierung, die veröffentlicht wird, ohne dass es jemand bemerkt. Für Produktmanager globaler Produkte ist das das Ziel – und die Teams, die das anstreben, sind meist näher dran, als sie annehmen. Es ist ein bisschen so wie bei einem Torwart oder einer Schlagzeugerin: Wenn sie es richtig gut machen, nimmt sie niemand wahr. 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 konzipiert wurde.
Die meisten Teams beginnen damit, alles manuell zu erledigen: Dateien, die über Slack geteilt werden, Übersetzer, die über verschiedene Zeitzonen hinweg kontaktiert werden müssen, oder Projektübergaben, die nur durch guten Willen zusammengehalten werden. Das funktioniert so lange, bis das Produkt wächst und die Anzahl der angeschlossenen Systeme steigt – ab dann gerät der manuelle Ansatz ins Stocken. Im Folgenden wollen wir die Kluft zwischen diesem Szenario und dem Nicht-Ereignis aufzeigen – basierend auf Gesprächen mit vier Mitarbeitenden bei Phrase, die sich täglich damit beschäftigen.
Skalierung ist in erster Linie ein Systemproblem – und erst in zweiter Linie ein Sprachproblem.
Als Erstes sollte man die Maßeinheit überdenken. Teams neigen dazu, den Umfang einer Lokalisierung anhand der Anzahl der Sprachen einzuschätzen: Fünf erscheinen überschaubar, fünfzehn sind schon eine ernstzunehmende Herausforderung, fünfundzwanzig stellen eine ganz andere Größenordnung dar. Das ist der falsche Ansatz.
Jozsef Hodos, Senior Product Manager im Integrationsteam von Phrase, drückt es so aus: „Skalierung heißt nicht, wie viele Sprachen du unterstützt. Sondern wie viele Systeme du verwaltest.“
Stell dir ein Team vor, das fünf Sprachen auf einem halben Dutzend Systemen verwaltet: ein CMS, ein Helpdesk, eine mobile Codebasis, ein Marketing-Tool und eine Dokumentations-Website. Es kann eine größere Last zu bewältigen haben als ein Team, das fünfzehn Sprachen über eine gut konfigurierte Integration abwickelt.
Sprachen bestimmen das Übersetzungsvolumen. Systeme bestimmen den Wartungsaufwand, und dieser Aufwand ist der Kostenfaktor, der sich so lange aufstaut, bis er schließlich die Agenda bestimmt.
Die entscheidende Frage gilt also nicht den Sprachen, sondern den Systemen: Wie viele müssen miteinander kommunizieren, und wer ist der Ansprechpartner, wenn sich eines davon ändert?
Integrationen zu erstellen ist einfach. Aber ihre Wartung ist kostenintensiv.
Wenn die manuelle Lokalisierung langsam lästig wird, ist der erste Impuls meist, selbst etwas zu entwickeln: 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 sich mit seiner Technologieplattform aus, das Problem scheint spezifisch zu sein, und durch die Eigenentwicklung wird eine weitere Abhängigkeit von einem Auftragnehmer vermieden. Die erste Version funktioniert, und das Problem scheint gelöst. Dann vergeht die Zeit.
Integrationen wie diese sind nicht schwer zu erstellen, sagt Jozsef, der sich im vergangenen Jahr gemeinsam mit Kunden genau damit beschäftigt 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-Schriftsystemen verhält oder wie Content strukturiert sein muss, um in einem Translation Memory sinnvoll genutzt werden zu können. 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 Besonderheiten und ihren eigenen Wartungsaufwand mit sich.
Infrastrukturteams bezeichnen das als aufgeschobene Wartung: Kosten, die unbemerkt bleiben, solange alles funktioniert, und die sich später in verschärfter Form bemerkbar machen.
Die gesamtwirtschaftlichen Rahmenbedingungen untermauern dies. Die Konnektor-Analyse von Nimdzi ergab, dass native Integrationen über zehn große TMS-Plattformen hinweg weniger als 13 % der von Unternehmen üblicherweise genutzten Geschäftsanwendungen abdecken – der Rest erfordert benutzerdefinierte Lösungen. Und gerade in den benutzerdefinierten Lösungen verbergen sich die Kosten. In seiner Marktanalyse zum TMS-Markt für das Jahr 2026warnt Nimdzi, dass Teams, die versucht sind, eigene KI-basierte Tools zu entwickeln, „häufig den Zeitaufwand, die Komplexität und das Änderungsmanagement bei der 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 eine Plattform für ihre Kunden pflegt. Dadurch entfallen die Entwicklung und die Wartung, und es stellt sich eine andere Frage: Wie können sie optimal konfiguriert werden?
Was wäre noch korrekter? Nehmen wir zum Beispiel die automatisierte Projekterstellung: Diese erkennt über eine Integration neuen Content auf einer verbundenen Plattform und eröffnet automatisch ein Übersetzungsprojekt. Richtig umgesetzt, wird Lokalisierung dadurch nahezu unsichtbar: Der Content erscheint, ein Projekt wird gestartet und Übersetzungen kommen zurück. In der Praxis, so Tomáš Doischer, Teamleiter für Integrationen bei Phrase, ist bei den meisten Konfigurationen ein zweiter Durchgang erforderlich, um das gewünschte Ergebnis zu erzielen. Jede Umgebung ist so unterschiedlich, dass keine Vorlage perfekt passt – ganz gleich, wie erfahren das Team ist.
Dazu kommt eine organisatorische Dimension, die selten genug ausreichend Beachtung erhält. Lokalisierungsmanager sind Expert*innen auf dem Gebiet der Lokalisierung – 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. Für die Einrichtung einer Integration sind Anmeldedaten und Zugriffsrechte erforderlich, die ein Lokalisierungsmanager oft nicht allein gewähren kann – was zu Abhängigkeiten zwischen Teams führt, die nicht täglich zusammenarbeiten.
Jeder, der schon einmal ein solches Projekt geleitet hat, kennt das: Die Person mit den Zugriffsrechten arbeitet nicht im Bereich Lokalisierung; die Person, die sich mit Lokalisierung auskennt, verfügt nicht über die Zugriffsrechte, und der Administrator, der die beiden miteinander verbinden könnte, ist bis Donnerstag im Urlaub. Darin liegt die eigentliche Arbeit – und das sollte man unbedingt wissen, bevor man loslegt.
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 mühsamen Projekten unterscheidet – und es ist nur selten die technische Leistungsfähigkeit: „Die konkrete Rolle oder der fachliche Hintergrund der Beteiligten ist nicht ausschlaggebend für den Erfolg. Es kommt viel mehr darauf an, das Umfeld des Kunden zu verstehen und die richtigen Fragen zu stellen.“
Als Beispiel beschreibt er zwei Teams mit nahezu identischen Setups. Ein Team integrierte GitHub über vier Repositorys hinweg. Bevor es etwas konfigurierte, studierte es die Dokumentation und stieß dabei auf ein Problem: Die Arbeit in Pull-Request-Branches, deren Namen sich mit jedem Release ändern, kollidierte mit der Art, wie die Integration den Content nachverfolgte. Also gestaltete man zunächst den Workflow um, plante Importe über die Integration und führte die Exporte über GitHub Actions durch. Das zweite Team, mit einem nahezu identischen Setup, stieß Wochen nach Inbetriebnahme auf das gleiche Problem. Die gleiche Integration, eine ganz andere Art von Woche.
Die Kehrseite einer guten Planung ist das, was mit ihrer Hilfe möglich wird. Die Figma-Integration von Phrase mit Phrase Strings ist ein gutes Beispiel dafür: Wenn Designer in Figma Übersetzungs-Keys erstellen, ruft die Integration Screenshots ab und markiert automatisch die Position der einzelnen Strings. Die Übersetzenden sehen den Quelltext in seinem tatsächlichen visuellen Kontext – etwa auf einer Schaltfläche oder einem Einstellungsbildschirm –, ohne dass jemand diesen manuell vorbereiten muss. Und niemand muss raten, was „btn_confirm_2“ bedeutet. Der Kontext begleitet den Content.
Wie Francesca Sorrentino, unser Director of Localization, es ausdrückt: „Integrationen sind die Grundlage. Aber sie lösen nicht jedes Problem in einem vollständigen Anwendungsfall. Die Teams, die richtig gute Arbeit leisten, verstehen, wozu die Integration dient, und richten ihre Arbeit entsprechend darauf aus.“
Die Teams, die richtig gute Arbeit leisten, sind nicht unbedingt die technisch versiertesten. Sie sind diejenigen, die ihr eigenes Setup verstehen, bevor sie es automatisieren, und genau das – mehr noch als jeder Konnektor – sorgt für einen entspannten Launch.
Je früher Produktmanager ins Boot geholt werden, desto kleiner wird das Problem.
Produktmanager kommen meist erst dann ins Spiel, wenn schon etwas schiefgelaufen ist. Dann erweisen sie sich oft als die Einzigen, die genau sehen, wie die Systeme zusammenhängen und was eine Funktion wirklich bewirken sollen. Doch zu diesem Zeitpunkt steht der Umfang bereits fest, und die beste Moment für einen wertvollen Beitrag ist bereits verpasst.
Wenn sie früher einbezogen werden, ändert sich vor allem, dass die Informationen, die für die Lokalisierung am dringendsten benötigt werden, bei ihnen vorliegen: was die Funktion bewirkt, wo der jeweilige Content erscheint und welche Märkte im Fokus stehen. Diese Informationen erreichen die Lokalisierung selten in strukturierter Form. Ein Entwickler bearbeitet ein Ticket, erstellt die Keys und pusht den Code. Der Lokalisierungsmanager bekommt die Keys, doch der Kontext, der es ermöglichen würde, die Übersetzenden vor Beginn der Arbeit einzuweisen, ist nicht mehr vorhanden.
Dieser fehlende Kontext unterscheidet einen Übersetzer, der weiß, was ein bestimmter String bedeutet, von einem, der nur anhand eines Key-Namens Vermutungen anstellt.
Marty Cagan und Bob Baxley, die im Blog der Silicon Valley Product Group über globales Produktmanagement schreiben, benennen den Fehler: Die Lokalisierung wird als nachgelagerter Übergabeprozess behandelt und nicht als plattformbezogene Angelegenheit – als etwas, das von vornherein in die Konzeption einbezogen werden muss, anstatt nachträglich angefügt zu werden. Aude Moras, Head of Product bei Tablecheck, drückt es noch deutlicher aus: „Man sollte sich nicht erst auf die Markteinführung vorbereiten und dann erst zwei Wochen vor dem Start über die Lokalisierung nachdenken.“
Tomáš Doischer, Team Lead, Integrations bei Phrase, kommt zum gleichen Ergebnis. Der Fehler, den er seiner Aussage nach am häufigsten beobachtet, besteht darin, dass Teams ihren alten Arbeitsablauf in einem neuen System einfach nachbilden, anstatt sich zu fragen, wozu dieser überhaupt diente: „Die Eins-zu-Eins-Übertragung eines alten Prozesses auf ein neues System ist so, als würde man versuchen, sein Pizzarezept 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 besteht der entscheidende Beitrag des Produktmanagers darin:
Lange, bevor etwas brennt, bringt er den Zeitplan und den Produktkontext früh genug ins Spiel, damit die Lokalisierung von Anfang an einbezogen wird, anstatt sie am Ende nachträglich anzuhängen – mit der Aufforderung, das Produkt bis Freitag für den globalen Markt bereit zu machen.
So funktioniert es in der Praxis:
Die Integrationen von Phrase zeigen das Konnektor-Ökosystem und wie die automatisierte Projekterstellung darin funktioniert.
