Was mir das Shipping von DIALØGUE über mehrsprachige AI-Produkte beigebracht hat
DIALØGUE unterstützt 7 Sprachen, aber die eigentliche Mehrsprachigkeitsarbeit bestand nicht im Übersetzen von Strings. Sie bestand darin, zielgruppenlokale Datumsangaben zu korrigieren, TTS-Konsistenz zu halten, Sprachdrift in der UI zu beheben und zu entscheiden, an welchen Stellen Qualität wichtig genug ist, um langsamer zu werden.
Eines der verführerischsten Dinge, die AI uns gerade ermöglicht, ist: Sprachen schnell hinzuzufügen. Ich weiß das, weil ich es ständig tue. Ich habe DIALØGUE in 48 Stunden 5 Sprachen hinzugefügt und danach mein gesamtes Blog-Archiv in 4 Tagen in 10 Sprachen übersetzt.
In diesen beiden Posts ging es um die Geschwindigkeit. In diesem hier geht es um alles, was Geschwindigkeit nicht abdeckt.
Übersetzung ist der Teil, der sich am leichtesten vorführen lässt, und gleichzeitig der Teil, den man am gefährlichsten überschätzt.
Die Maschine kann Text erstaunlich schnell von einer Sprache in eine andere bewegen. Das heißt noch lange nicht, dass sich das Produkt dadurch nativ anfühlt. Aus meiner Erfahrung zeigt sich die eigentliche Mehrsprachigkeitsarbeit an vier Stellen: Zeit, Stimme, UI-Systeme und Fallback-Verhalten. Genau dort beginnt ein Produkt entweder durchdacht zu wirken oder künstlich.
So sah das in der Praxis aus:
| Translation Work | Product Work | |
|---|---|---|
| Was es abdeckt | Strings, Copy, Labels | Datumsangaben, Layout, Stimme, Fallbacks |
| Wer merkt, wenn es falsch ist | Bilinguale Reviewer | Jede Nutzerin und jeder Nutzer in dieser Locale |
| Wie AI hilft | Erzeugt Übersetzungen schnell | Kann Produkt-Fit auf Systemebene nicht beurteilen |
| Aufwand für die Korrektur | String neu übersetzen | Komponente neu entwerfen |
| Wann du es bemerkst | Im Code Review | Nachdem jemand das Produkt tatsächlich benutzt |
Der erste Bug war keine Übersetzung. Sondern Zeit.
Eine der Änderungen, die mir das besonders klar gemacht hat, hatte überhaupt nichts mit Copy zu tun.
Für wiederkehrende Shows erzeugt DIALØGUE Episodentitel automatisch. Die naheliegende Version klingt harmlos: Name der Show plus heutiges Datum.
Das klingt unproblematisch, bis dein Publikum in Tokio sitzt und dein Server noch in Kalifornien denkt.
Wenn eine japanische Hörerin eine Daily Show öffnet und in Tokio bereits der 14. März ist, im Titel aber noch der 13. März steht, weil der Server das glaubt, fühlt sich das Produkt sofort off an. Nicht kaputt. Nur nachlässig.
Also habe ich am Ende die Episodentitel so umgestellt, dass sie das lokale Datum des Publikums verwenden, in dessen Locale und Zeitzone, nicht in der Server-Default.
Das ist ein kleines Implementierungsdetail. Und genau das ist der Punkt.
Mehrsprachige Produkte gehen nicht nur um Worte. Sie gehen um Kontext.
Sprache ohne lokalen Kontext ist oft einfach nur die höflichere Version von falsch.
Lektion 1: Stimme ist Teil des Produkts
Je tiefer ich in DIALØGUE hineingegangen bin, desto klarer wurde mir das.
Das Produkt basiert auf Dialog, Pacing, Persönlichkeit und Audio. Dadurch liegt die Qualitätslatte viel höher als bei einer normalen SaaS-Oberfläche.
Als ich neue Templates hinzugefügt habe, habe ich schnell gelernt, dass mehrsprachige Unterstützung nicht einfach heißt:
- den Template-Namen übersetzen
- die Landingpage-Copy übersetzen
- shippen
Für ein Template musste ich über all das nachdenken:
- host profiles
- audience profiles
- dialogue guides
- voice instructions für TTS
- lokalisierte Benennungskonventionen pro Sprache
Diese Arbeit gab es bereits auf Englisch, aber sie brauchte auch japanische und vietnamesische Versionen, weil die Chemie zwischen den Hosts Teil des Produkts ist, nicht nur eine kosmetische Schicht darüber.
Wenn dein Produkt Inhalte erzeugt, ist Voice keine Dekoration. Voice ist Infrastruktur.
Etwas kann grammatikalisch korrekt sein und sich trotzdem tot anfühlen.
Das habe ich besonders deutlich bei chinesischen Varianten und bei gesprochenen Inhalten generell gespürt. Standard-Mandarin kann technisch korrekt sein und sich in einem bestimmten Kontext trotzdem zu formell anfühlen. Ein lockerer Gesprächsrhythmus im Englischen kann in einer anderen Sprache plötzlich bürokratisch wirken, wenn man ihn zu wörtlich durch Produktsprache presst. Ein Witz, der in einem Markt funktioniert, wird in einem anderen zu flacher Exposition.
Deshalb lege ich heute so viel Wert auf Tone Guides und Host Profiles. Nicht weil ich will, dass jeder Output "branded" klingt. Sondern weil Voice Drift eine der schnellsten Arten ist, ein mehrsprachiges AI-Produkt generisch wirken zu lassen.
Und generisch ist teuer.
Lektion 2: UI-Länge ist ein Produktproblem, kein Übersetzungsproblem
Das klingt klein, bis du eine echte App shipst.
Dann ist es plötzlich überall.
Als ich die DIALØGUE-iOS-App lokalisiert habe, ging es nicht nur darum, ein paar Screens zu übersetzen. Es wurden 253 Strings in 7 Sprachen.
Und selbst dann war die Arbeit noch nicht vorbei.
Ich musste die Input Components so neu verdrahten, dass der App-Sprachpicker die tatsächliche UI-Sprache konsistent steuert. Placeholders, Buttons, Pricing Labels, Status-Text, alles. Sonst bekommt man das halb übersetzte App-Problem:
- ein Screen respektiert die ausgewählte Sprache
- ein anderer zeigt immer noch den englischen Placeholder
- die Status Labels bleiben in der Ursprungssprache
- die App unterstützt technisch mehrere Sprachen, aber die Experience tut es nicht
Ein sauberer englischer Button wird auf Deutsch plötzlich sperrig. Eine kompakte Pricing-Zeile bricht im Französischen um. Ein knackiges Settings-Label verhält sich auf Japanisch anders.
Wenn dein Lokalisierungs-Workflow bei der Texterzeugung endet, entdeckst du diese Probleme peinlich spät.
Deshalb glaube ich immer stärker, dass Mehrsprachigkeit als vollständiges Produktsystem behandelt werden muss:
- Copy
- Layout
- Spacing
- Truncation Rules
- Component Behavior
- Screenshot-QA
Die Maschine kann die Worte erzeugen. Irgendjemand muss trotzdem den Simulator öffnen.
Lektion 3: Fallback-Verhalten zeigt, wie reif das Produkt wirklich ist
Das gilt bei Audio-Produkten sogar noch mehr als bei Text-Produkten.
Eine der nützlichsten DIALØGUE-Änderungen der letzten Zeit sah von außen ziemlich langweilig aus: TTS-Thresholding und Konsistenz pro Segment.
Das ursprüngliche Whole-Script-TTS-Gate war zu optimistisch. Lange Podcasts liefen über das tatsächliche Input-Limit, verschwendeten mehrere fehlgeschlagene Retries und fielen erst dann zurück. In manchen Runs bedeutete das ungefähr 12 Sekunden vermeidbare Latenz, bevor das System sich selbst korrigierte.
Das ist auf Englisch nervig.
In mehrsprachigen Flows ist es schlimmer, weil Voice Consistency ohnehin schwerer zu halten ist.
Die Lösung war nicht: "ein besseres Modell nutzen." Die Lösung war Produktarbeit:
- den Threshold für Whole-Script-Synthese senken
- lange Episoden früher in den Per-Segment-Modus verschieben
- Opening-, Middle- und Closing-Guidance für die Energie jedes Segments ergänzen
- einige Zeilen des vorherigen Dialogs als Continuity Context mitgeben, damit sich das nächste Segment nicht wie eine neue Show anfühlt
Das ist Fallback-Verhalten. Das ist Reife.
Wenn sich eine sprachspezifische TTS-Stimme falsch anhört, was passiert dann? Wenn eine generierte Antwort Sprachen mischt, was passiert dann? Wenn mitten in einem lokalisierten Flow eine nicht übersetzte Fehlermeldung auftaucht, was passiert dann? Wenn ein langes Skript das Modell-Limit überschreitet, was passiert dann?
An solchen Momenten erkennst du, ob Mehrsprachigkeit nur ein Feature ist oder ein Fundament.
Nutzerinnen und Nutzer verzeihen oft, wenn das System erkennbar versucht zu helfen. Sie verzeihen viel weniger, wenn sich das Produkt nach Nachlässigkeit anfühlt.
Lektion 4: Wissen, wann Coverage es nicht wert ist
Die Business-Frage lautet nicht: "Kann ich noch eine Sprache unterstützen?"
Sie lautet:
- wird diese Sprache echte Nutzung oder echte Distribution freischalten?
- kann ich eine glaubwürdige Qualitätslatte in UI und Output halten?
- kann ich die Failure Cases abfangen, ohne Support Debt zu erzeugen?
Wenn die Antwort nein ist, launchst du keine mehrsprachige Fähigkeit. Du launchst mehrsprachige Oberfläche. Und Oberfläche ohne Qualität schwächt leise das Vertrauen.
Lektion 5: Mehrsprachige Produkte brauchen ihre eigene Eval-Ebene
Das ist vielleicht mein größtes Learning aus DIALØGUE und dem Blog-Archiv.
Du kannst mehrsprachige Qualität nicht allein nach Instinkt beurteilen, schon gar nicht in größerem Maßstab.
Du brauchst explizite Checks:
- locale-spezifisches Datums- und Zeitzonenverhalten
- Terminologiekonsistenz
- UI-Overflow
- Fallback-Sprachregeln
- TTS-Konsistenz über Segmente hinweg
- Drift bei Host/Persönlichkeit
- Output-Qualität in echten User Flows
Anders gesagt: Mehrsprachige Produkte brauchen ebenfalls Evals.
Und genau hier, glaube ich, tappen viele AI-Builder in die Falle. Wir sind fasziniert davon, wie viel das Modell produzieren kann, und verbringen zu wenig Zeit damit, dauerhaft zu definieren, was "gut" eigentlich bedeutet.
Im kleinen Maßstab ist das noch handhabbar.
Im größeren Maßstab wird es gefährlich.
Wo ich inzwischen stehe
Ich bin optimistischer denn je, was mehrsprachige AI-Produkte angeht.
AI verändert die Economics absolut. AI erweitert absolut das, was eine einzelne Person oder ein kleines Team shippen kann. AI macht Produktambitionen möglich, die vor nicht allzu langer Zeit unrealistisch gewesen wären.
Aber AI erhöht auch den Standard für Produkt-Urteilsvermögen.
Denn sobald Sprach-Expansion einfach wird, wird Qualität zum Differenzierungsmerkmal. Und Qualität in mehrsprachigen Produkten entsteht nicht allein durch Übersetzung. Sie entsteht durch Kontext, Stimme, Passung der Oberfläche, Fallbacks, Review Loops und eine sehr ehrliche Definition davon, was "nativ genug" eigentlich heißt.
Genau das hat mir DIALØGUE beigebracht. Je mehr Sprachen du unterstützt, desto mehr Produktmanagement machst du in Wahrheit, ob du es so nennst oder nicht.
Wenn dein Produkt wirklich mehrsprachig ist, endet die Arbeit nicht, wenn die Strings übersetzt sind. Dann beginnt die eigentliche Arbeit erst.
Wenn du sehen willst, was aus diesem Denken entstanden ist: DIALØGUE ist jetzt live in 7 Sprachen. Und ich vermute, dass mir die mehrsprachige Ebene noch viele neue Lektionen beibringen wird, je mehr Menschen es nutzen. Meistens die demütig machenden.
Wenn du selbst mehrsprachige Produkte baust, würde ich gern wissen: Was war der Moment, in dem dir klar wurde, dass der schwierigste Bug überhaupt nichts mit Übersetzung zu tun hatte?
Cheers, Chandler
Häufig gestellte Fragen
Was ist der schwierigste Teil beim Bau eines mehrsprachigen AI-Produkts?
Nicht die Übersetzung. AI übernimmt diesen Teil inzwischen erstaunlich gut. Der schwierigste Teil ist alles um die Übersetzung herum: zeitzonenbewusste Formatierung, Konsistenz der Stimme über TTS-Segmente hinweg, UI-Components, die bei unterschiedlichen String-Längen brechen, und Fallback-Verhalten, wenn in einer bestimmten Locale etwas schiefläuft. Das sind Produktprobleme, keine reinen Sprachprobleme.
Sollte ich meinem AI-Produkt mehr Sprachen hinzufügen?
Nur wenn du die Qualität halten kannst. Jede zusätzliche Sprache erzeugt fortlaufende Produktarbeit: Layout-QA, Voice-Tuning, locale-spezifische Datums- und Zahlenformate und Fallback-Pfade. Wenn dein Produkt auf Nuance und generiertem Inhalt basiert, etwa Podcasts, Longform Writing oder Conversational AI, liegt die Messlatte höher als bei einer einfachen transaktionalen Oberfläche.
Wie testet man mehrsprachige AI-Features?
Bau eine explizite Eval-Ebene. Für DIALØGUE heißt das: locale-spezifische Datumsangaben prüfen, Konsistenz der TTS-Segmente, UI-Overflow in allen 7 Sprachen und Persönlichkeitsdrift in generierten Host-Dialogen. Auf Instinkt allein kannst du dich nicht verlassen, sobald du mehr als zwei oder drei Sprachen unterstützt. Die Oberfläche wird dafür einfach zu groß.
Macht AI Lokalisierung einfacher oder schwieriger?
Beides. AI macht die erste Übersetzung dramatisch schneller und günstiger. Gleichzeitig erzeugt sie ein falsches Gefühl von Fertigstellung. Du bekommst die Worte richtig und glaubst, das Produkt sei bereit. Die eigentliche Arbeit, also Kontext, Stimme, UI-Fit und Fallbacks, braucht weiterhin menschliches Urteilsvermögen. AI hebt den Floor für mehrsprachige Coverage an, aber die Decke bleibt Produkt-Handwerk.
