Jedes Unternehmen, mit dem wir sprechen, stößt auf dieselben zwei Hürden.
Die erste ist die Koordinationssteuer für Konsistenz.
Ihre Android-App wird von einem Team gebaut. Ihre Web-App von einem anderen. Ihre Marketing-Website, Ihre Dokumentation, Ihre internen Tools – all das liegt bei unterschiedlichen Teams, jedes mit eigener Release-Kadenz, eigenen Prüfern und eigener Auslieferungspipeline.
Bestehende Tools können Translation Memorys und Glossare projektübergreifend teilen. Workspaces gibt es. Assets auf Organisationsebene gibt es. Aber Geteiltes wird nicht durchgesetzt. Ein Begriff im gemeinsamen Glossar ist für den Übersetzer ein Vorschlag, keine Vorgabe für das Modell. Konsistenz über Teams hinweg wird zur Disziplin. Jemand hält das Glossar synchron. Jemand löst die fachsprachlichen Konflikte zwischen Teams. Jemand läuft dem Team hinterher, das einen Call-to-Action so übersetzt, während ein anderes ihn anders ausspielt. Konsistenz ist möglich. Die Pflege ist dauerhaft.
Innerhalb der Projekte der einzelnen Teams nimmt die Drift weiter zu. Ein Translation Memory hält Konsistenz nur so lange, wie sich Segmente nicht ändern. In einer Codebasis, die jede Woche refaktoriert wird, ändern sich Segmente jede Woche. Unsere RAL-Forschung misst, wie schnell Terminologie driftet, wenn dem Modell kein abgerufener Kontext vorliegt.
Die zweite Hürde sind die Kosten, diese Tools jemals zu verlassen – also genau die Tools, die diese Steuer überhaupt erst erzeugen. In einem Unternehmen verstärkt jede Dimension den Aufwand: teamübergreifend angesammelte Glossare, Translation Memorys in TMX und proprietären Anbieterformaten über verschiedene Projekte hinweg, in die CI jedes Teams verdrahtete Konnektoren, über den Einkauf verhandelte Übersetzerpools, mit dem IdP integriertes SSO.
Die Migration liest sich wie ein Engineering-Programm über mehrere Quartale – und keines, das ein Localization Manager verantworten will.
Für diese Multi-Team-Struktur passen zwei Architekturen.
Die eine ersetzt projektbezogene Translation Memorys durch eine organisationsweite Lokalisierungs-Engine, die Kontext zur Inferenzzeit abruft. Ein Glossar, eine Markenstimme, und die App jedes Teams greift auf dieselbe Lokalisierungs-Engine zu.
Die andere ersetzt das Modell, bei dem der Kunde die Migration selbst stemmt, durch einen Forward-Deployed Localization Engineer von Lingo.dev, der die Migration nach unserem Zeitplan durchführt, nicht nach Ihrem.
Beide Muster betreiben längst jeden anderen Teil Ihrer Infrastruktur – jetzt soll die Lokalisierung endlich aufholen.
Architektur #1: die Lokalisierungs-Engine#
Lokalisierungs-Engine
Eine zustandsbehaftete Übersetzungs-API, die Teams auf Lingo.dev anlegen und pro Organisation konfigurieren. Jede Lokalisierungs-Engine speichert ihr eigenes Glossar, ihre eigene Markenstimme, sprachspezifische Anweisungen und eine gerankte Modellkette. Jede Anfrage ruft passende Glossarbegriffe ab, injiziert sie in das Kontextfenster des Modells, bevor das erste Token erzeugt wird, und wird nach Abschluss unabhängig bewertet. Die erste Übersetzung profitiert von null Kontext; die tausendste von allem.
Eine Lokalisierungs-Engine hält Konsistenz auf Begriffs- statt auf Segmentebene. Sie ist auf Ihre Organisation ausgelegt, nicht auf das Projekt eines einzelnen Teams. Ein Glossar, eine Markenstimme, und jede Oberfläche jedes Teams greift auf dieselbe Lokalisierungs-Engine zu.
Ein Glossar-Eintrag für "Submit" greift auf jeder spanischen Oberfläche – Button, E-Mail-Betreff, Tooltip. Ob Web-Team oder Mobile-Team, spielt keine Rolle. Retrieval gleicht Bedeutung ab, nicht Strings. Ein Eintrag für "Deploy" greift bei "deploying", "deployment", "Deploy your app" – kein separater Eintrag für jede Form.
Eine Markenstimme ist pro Sprache an die Lokalisierungs-Engine gebunden. Jede Anfrage nutzt sie.
Anweisungen sind klar abgegrenzte, testbare Regeln pro Sprache. Abkürzungskonventionen, geschützte Leerzeichen, Anführungszeichen – jedes Element lässt sich für sich debuggen.
Eine Modellkette leitet jede Anfrage an das primäre Modell mit gerankten Fallbacks weiter. Wechseln Sie den Anbieter, ohne das Glossar anzutasten.
Ein KI-Bewerter läuft auf einem unabhängigen Modell. Er bewertet jede Anfrage separat anhand des Glossars und jeder einzelnen Anweisung. Bestanden/nicht bestanden mit Begründung, als Zeitreihe nachverfolgt.
| Aspekt | Projektbezogene Tools | Organisationsweite Lokalisierungs-Engine |
|---|---|---|
| Umfang der Konsistenz | Pro Projekt, pro Team | Pro Organisation |
| Konsistenzeinheit | Ganzes Segment, per Hash referenziert | Einzelner Begriff, semantisch abgeglichen |
| Überlebt Umschreibungen im Ausgangstext | Nein | Ja |
| App- und teamübergreifend | Disziplin; Menschen halten es synchron | Architektonisch; die Lokalisierungs-Engine hält es synchron |
| Qualitätsmessung | Regelbasierte Prüfungen (Tags, Zahlen) | LLM-Bewertung pro Anfrage |
| Modellflexibilität | Anbieterbindung | Gerankte Kette |
| Hoheit über die Ausgabe | Ermessensspielraum des Übersetzers | Glossar setzt sich gegen das Modell durch |
Drift wird zu einem Zustand, den Sie messen können, nicht zu einem, den Sie einfach hinnehmen. Das Glossar greift bei jeder Anfrage. Der KI-Bewerter verifiziert die Einhaltung pro Anfrage.
Der Name dieses Mechanismus ist retrieval augmented localization (RAL). Zur Inferenzzeit zerlegt die Engine die Eingabe in n-Gramm-Phrasen, erzeugt Embeddings dafür und führt eine Kosinus-Ähnlichkeitssuche gegen den Vektorindex des Glossars aus. Treffer gelangen in das Kontextfenster des Modells, bevor das erste Token erzeugt wird. Strukturell identisch mit RAG, angewandt auf Übersetzung.
In einer kontrollierten Evaluation über mehrere LLM-Anbieter und mehrere europäische Sprachen hinweg reduzierte RAL Terminologiefehler um 17–45%. 42.000+ gepaarte Qualitätsurteile. Holm-Bonferroni-korrigiertes p < 0,001 bei jedem Anbieter. Ganzheitliche Qualitätswerte konnten den Unterschied überhaupt nicht erkennen.
Architektur #2: Forward-Deployed Localization Engineering#
Die zweite Hürde ist die Migration. Sie haben einen funktionierenden Stack. Er erzeugt die Steuer, aber er funktioniert. Die Kosten für den Ersatz – Engineering-Zeit, überarbeitete Integrationen, erneutes Onboarding von Übersetzern, Migration historischer Daten – übersteigen durchweg die Kosten, die Steuer weiter zu zahlen.
Diese Rechnung erklärt, warum die Steuer weiter gezahlt wird. Nachdem wir gesehen haben, wie derselbe Migrationsengpass ernsthafte Unternehmen immer wieder am Wechsel hindert, haben wir entschieden, die Migration selbst zu übernehmen.
Wenn Lingo.dev ein Unternehmen onboardet, übernehmen unsere Engineers die Migration. Nicht als Professional-Services-Vertrag zusätzlich zur Lizenz. Sondern als standardmäßigen Onboarding-Pfad.
Ein Forward-Deployed Localization Engineer arbeitet sich in Ihr Glossar, Ihre Dokumente zur Markenstimme, Ihre Konnektorkonfiguration und Ihre Übersetzerverträge ein. Er importiert Ihr Translation Memory aus TMX und Ihr Glossar aus jedem Legacy-Format, in dem es vorliegt. Nichts wird neu hergeleitet. Er baut die Lokalisierungs-Engine auf Lingo.dev mit bereits geladener Terminologie. Er bindet sie in Ihre CI ein. Er führt Ihren Übersetzerpool durch die asynchrone Pipeline, damit die Menschen, denen Sie vertrauen, im Prozess bleiben.
Gerade im Multi-Team-Fall zahlt sich die Architektur aus. In der Legacy-Version bedeutet die Abstimmung der Terminologie über Teams hinweg N synchronisierte Migrationen – jedes Team leitet Schlüssel und TM in seinem eigenen Projekt neu her. Hier wird die Lokalisierungs-Engine einmal aufgebaut. Jedes Team bindet seine App in seinem eigenen Tempo daran an. App-übergreifende Konsistenz zeigt sich schon bei der ersten Sprache, die die Engine erreicht, nicht erst, nachdem jedes Team seine eigene Migration abgeschlossen hat.
Unsere Engineers bleiben an Ihrer Seite bis zum nächsten Deployment in die Produktion – und bis zum darauffolgenden –, bis Ihr internes Team das System übernimmt.
So onboarden wir Unternehmenskunden.
Sobald eine Multi-Team-Organisation jede Woche ausliefert, kann Übersetzung kein Procurement-Ticket zwischen Käufer und Anbieter mehr sein. Sie muss parallel zum nächsten Deployment in die Produktion laufen, nicht danach. Forward-Deployed Engineering ist die Art, wie Palantir, Scale AI, Ramp und andere Infrastrukturanbieter seit über einem Jahrzehnt Unternehmenskunden onboarden.
Jetzt soll die Lokalisierung endlich aufholen.
Audit
Ein Engineer von Lingo.dev prüft Ihre Source-Repositories, Ihr bestehendes TM (einschließlich TMX-Exporte), Ihr Glossar, Ihre Konnektoren und Ihre Übersetzerverträge – über alle Teams hinweg, die eine Oberfläche verantworten. Er erstellt einen Migrationsplan mit Reihenfolge und Zeitplan. Der Plan gehört Ihnen.
Engine auf Ihre aktuelle Qualität abgestimmt
Wir konfigurieren die Lokalisierungs-Engine mit Ihrem importierten Glossar, Ihrer Markenstimme pro Sprache und Ihrer Übersetzerpipeline. Bevor Production-Traffic darauf läuft, führen wir einen Side-by-Side-Vergleich durch – die Ausgabe Ihres aktuellen Tools versus die der Engine, gleiche Strings, gleiche Woche. Sie entscheiden, ob die Qualität hält.
In die CI jedes Teams eingebunden
Kein Rip-and-Replace. Die Lokalisierungs-Engine läuft als ein Schritt in der bestehenden Pipeline jedes Teams. Merge-Flows, Prüfungs-Flows, Prüfer – alles bleibt gleich. Die Engine ersetzt den alten Schritt.
Umstellung in Ihrem Tempo
Zuerst ein Team, ein Sprachpaar. Dann drei. Dann der Rest. Sie wählen die Reihenfolge. Wir führen den Vergleich bei jedem Schritt durch. Rollback ist ein Commit.
Übergabe an Ihr Team
Unser Engineer übergibt das System an Ihr Plattform-Team – Dokumentation, Runbooks und eine On-Call-Rotation, die wir abdecken, bis Ihr Team sie übernimmt.
Evidenz#
Forschung. Die RAL-Studie: 42.000+ gepaarte Qualitätsurteile über mehrere LLM-Anbieter und mehrere europäische Sprachen hinweg. Holm-Bonferroni-korrigiertes p < 0,001 bei jedem Anbieter. Die Reduktion von Terminologiefehlern lag zwischen 17 und 45%.
Konfiguration statt Modellwahl. Wir haben festgestellt, dass über Mistral, Gemini, Claude, GPT hinweg – jedes Modell plus ein gutes Glossar, eine gute Markenstimme und ein gutes Kontext-Setup – konsistent produktionsreife Übersetzungen in Referenzqualität zu einem Bruchteil der Kosten liefert. Nicht, weil wir das Modell verbessert hätten. Bei jeder Anfrage ruft die Lokalisierungs-Engine die passenden Glossarbegriffe, die Markenstimme und die Anweisungen pro Sprache per Ähnlichkeitssuche ab und injiziert sie in das Kontextfenster des Modells, bevor das erste Token erzeugt wird.
Produktionsmaßstab. 200 Mio.+ Wörter auf der Plattform übersetzt.
Namentlich genannte Kunden. Mistral, Solana, SoSafe, Cal.com.
Umfang#
Lingo.dev unterstützt Lokalisierungsteams jeder Größe und Struktur – vom Unternehmen mit nur einem Produkt über Open-Source-Projekte und reine Mobile-Teams bis hin zu Enterprise-Plattformen. Die hier beschriebene Architektur ist auf Unternehmen mit mehreren Teams zugeschnitten, die mehrere Apps in 20+ Sprachen ausliefern.
So geht es weiter#
Der erste Schritt ist ein zweiwöchiges Pilotprojekt. Ein Team, ein Sprachenpaar.
Ein Forward-Deployed Localization Engineer arbeitet eng mit Ihrer Lokalisierungsverantwortung und Ihrer technischen Leitung zusammen. Wir analysieren Ihren Workflow. Wir richten ein Messsystem ein, damit Sie die Qualität von Übersetzungen in Sprachen beurteilen können, die Ihr Team nicht spricht – mit KI-Bewertern auf unabhängigen Modellen, die jede Übersetzung anhand Ihres Glossars und Ihrer Regeln bewerten. Die Bewertung ist an MQM angelehnt, das Standardframework zur Bewertung von Übersetzungsqualität.
Wir bauen die Lokalisierungs-Engine auf Basis Ihres Glossars und Ihrer Dokumente zur Markenstimme. Wir lassen sie parallel zu Ihrem aktuellen Tool auf Ihren Quellinhalten laufen. Sie sehen den Unterschied und entscheiden.
Danach planen wir die Migration für die verbleibenden Teams und Sprachen nach Ihrem Zeitplan, nicht nach unserem.
Sprechen Sie noch heute mit unseren Experten für Localization Engineering.
