Internationalisierungsberatung: Probleme beheben, nächste Schritte planen
Du weißt bereits, dass i18n schwierig ist. Ich kenne die Symptome: RTL-Layouts, die zusammenbrechen, deutscher Text, der aus Schaltflächen überläuft, API-Antworten in der falschen Sprache und Übersetzungen, die schon wenige Wochen nach der Veröffentlichung nicht mehr synchron sind. Ich verkaufe keine Wundermittel. Ich helfe dir, das konkrete Chaos zu entwirren, in dem dein Team steckt – und Systeme aufzubauen, die nicht wieder auf dieselbe Weise kaputtgehen.
„Wir hätten das früher planen sollen"
Der Architekturpreis, den Sie jetzt zahlen
Sie haben auf Englisch gestartet. Es hat funktioniert. Dann haben Sie Französisch „nur für die Landingpage" hinzugefügt. Jetzt sind Sie hier, weil:
Ihre Codebasis enthält lang=-Prüfungen, verteilt auf 47 Dateien
Produktmanager:innen fragen: „Können wir den Text A/B-testen?“, und das Engineering antwortet: „Nicht ohne größeren Rewrite.“
Sie haben drei verschiedene Übersetzungs-Workflows, und keiner davon funktioniert zuverlässig.
Was ich gesehen habe, was kaputtgeht:
- Teams, die über 6 Monate damit verbringen, i18n nachträglich in eine Next.js-App einzubauen, weil Zeichenketten in den Komponenten fest einprogrammiert waren.
- Übersetzungsdateien geraten nicht mehr synchron, weil Entwickler nicht wissen, welche Datei sie aktualisieren sollen.
- „Lokalisierungsstopp"-Phasen vor Veröffentlichungen, weil niemand der Übersetzungspipeline vertraut.
- Widerstand gegen die Änderung übersetzter Inhalte, weil der Workflow so aufwendig ist.
Womit ich helfe:
- Refactoring-Strategien, mit denen Sie i18n schrittweise einführen können (Ich fordere nicht: „Alles stoppen und neu schreiben").
- Prozessdesign, um Übersetzungen synchron zu halten, ohne die Entwicklung zu blockieren.
- Architektur-Reviews, um festzustellen, wo Ihr aktueller Ansatz bei mehr als 10 Sprachen an seine Grenzen stößt.
Internationalisierung ist Architektur, keine Funktion. Sie nachträglich hinzuzufügen, ist so, als würde man erst nach dem Hausbau entscheiden, dass ein Keller nötig ist.
Ich helfe Ihnen, diesen Keller auszuheben – oder zu entscheiden, ob Sie überhaupt einen brauchen.
RTL bringt alles durcheinander.
Ihre Benutzeroberfläche wurde nicht für Arabisch, Hebräisch oder Urdu entworfen.
Sie haben dir="rtl" aktiviert und gesehen, wie Ihr Layout explodiert:
Was ich gesehen habe:
- Design-Systeme mit über 200 Komponenten, von denen nur 12 RTL korrekt unterstützen
- Teams, die float: left statt logischer Eigenschaften verwenden und damit in jedem neuen Feature RTL-Bugs produzieren
- Popovers und Modals, die komponentenspezifische RTL-Anpassungen benötigen
- Frameworks, die „RTL-Support" bewerben, der zwar die Layout-Richtung umkehrt, aber die Platzierungslogik stört.
Womit ich helfe:
- Migration auf logische CSS-Eigenschaften (margin-inline-start statt margin-left)
- Design-System-Audits, um RTL-Fallstricke zu finden, bevor sie veröffentlicht werden
- Framework-spezifische Anleitungen (Tailwind, shadcn, MUI) für RTL-first-Styling
RTL-Bugs in jeder einzelnen Komponente manuell zu beheben, ist nicht tragfähig. Ich mache RTL-Support systematisch, statt eines ständigen Feuerwehreinsatzes.
„Der deutsche Text hat unseren Button zerstört"
UI, die nicht übersetzungsgerecht konzipiert wurde.
Englisch passt. Deutsch passt nicht. Ihr Design ging davon aus:
Dann haben Sie ins Deutsche, Finnische oder Thailändische übersetzt und dabei festgestellt:
Schaltflächen, deren Text mitten im Wort abgeschnitten ist
Tabellen mit horizontalem Scrollbalken pro Zeile
Text, der in unleserliche Blöcke umbricht
Nicht-lateinischer Text wird abgeschnitten, weil Container feste Breiten haben
Womit ich helfe:
- Elastische UI-Muster, die sich an die Inhaltslänge anpassen
- Zeichenbudgetplanung (im Wissen, dass Deutsch sich um 30 % ausdehnt und Thai keine Leerzeichen verwendet).
- Typografie-Systeme, die CJK, Arabisch und Devanagari problemlos verarbeiten.
Ich helfe dir, UIs zu entwickeln, die auch nach der Übersetzung noch funktionieren – bevor du für 10.000 Wörter bezahlt hast, die nicht passen.
Sie brauchen keinen Vortrag darüber, warum i18n wichtig ist. Sie brauchen jemanden, der schon um 2 Uhr morgens RTL-Popovers debuggt hat, sich mit dem Produktteam über Zeichenbudgets gestritten und Übersetzungspipelines entworfen hat, die tatsächlich funktionieren.
Die Fallstricke, vor denen Sie niemand gewarnt hat
Geschichten aus der Praxis von Teams, die das schon durchgemacht haben
Das sind keine theoretischen Beispiele. Dies sind reale Probleme, die im Live-Betrieb auftraten:
Die Hölle der Pluralisierung
Englisch: „1 item" vs. „2 items"
Polnisch: „1 przedmiot" / "2 przedmioty" / „5 przedmiotów" (3 Pluralformen)
Arabisch: 6 Pluralformen
Ihre count === 1 ? 'item' : 'items'-Logik funktioniert nicht mehr.
Datums-/Zeitchaos
Sie haben Datumsangaben mit toLocaleDateString() formatiert, sodass Nutzer in Japan „2025年2月9日" in Ihren CSV-Exporten sahen und Excel damit nicht zurechtkam.
API-Sprachkonflikt
Dein Frontend fordert Französisch an. Deine API gibt Englisch zurück, weil das Authentifizierungstoken keine Locale-Informationen enthält. Das Ergebnis ist eine Benutzeroberfläche mit gemischten Sprachen, und Benutzer halten das für einen Fehler.
Pseudo-Locale-Tests
Du hast nicht mit [Ţĥîś îś ţéśţ ţéẋţ ţĥàţ éẋþàñðś 30%] getestet, bevor du in Produktion gegangen bist. Jetzt ist deine polnische Website unbrauchbar.
Die unsichtbare Annahme
Sie gingen davon aus, dass nur Zeichenketten übersetzt werden müssen. Dann kommen Datumsangaben, Zahlen, Währungen, Sortierung und Suche – alles hat länderspezifisches Verhalten.
Womit ich helfe:
- ICU MessageFormat-Implementierung (unterstützt Pluralformen, Genus und Kontext)
- API-i18n-Muster (Sprachverhandlungen und Fallback-Strategien)
- QA-Prozesse, die diese Probleme erkennen, bevor Übersetzungsagenturen sie entdecken.
Der Workflow ist der schwierige Teil.
Wie halten Sie 8 Sprachen synchron, wenn Sie täglich ausliefern?
Sie haben die Technik verstanden. Jetzt stecken Sie im Prozess fest:
Entwickler mergen Code mit neuen englischen Zeichenketten. Übersetzungen hinken 2 Wochen hinterher. Benutzer sehen eine halb übersetzte UI.
Sie wissen nicht, welche Zeichenketten bedenkenlos gelöscht werden können (werden sie noch verwendet, sind sie bereits übersetzt oder werden sie gerade von einer Agentur bearbeitet?).
Das Produktteam möchte den Text aktualisieren. Niemand weiß, ob die Änderung von „Absenden" zu „Senden" in 12 Sprachen zu Problemen führen wird.
Übersetzungsdateien sind wochenlang nicht mit der Produktionsumgebung synchron.
Fragen, die Teams mir stellen:
Was ich gesehen habe, was kaputtgeht:
- In Git eingecheckte Übersetzungsdateien, die von den Strings in der Produktionsumgebung abweichen.
- Warnungen wie „Die spanische Datei nicht anfassen", weil niemand weiß, welche Änderungen unbedenklich sind.
- Funktionen werden auf Englisch eingeführt und dann 6 Monate später übersetzt (falls überhaupt)
Womit ich helfe:
- Übersetzungspipeline-Design (wann man i18n-Bibliotheken, wann TMS und wann KI verwenden sollte)
- Git-Workflows, um Quellstrings und Übersetzungen synchron zu halten.
- Automatisierung, die PRs blockiert, wenn neue Strings nicht zur Übersetzung markiert sind.
Die technische Umsetzung ist machbar. Der Workflow ist das eigentliche Hindernis. Ich konzipiere Workflows, die ohne Heldentaten wartbar sind.
Teams, mit denen ich gearbeitet habe
Globale Produkte, regionale Expertise.
LINE (Japan, Taiwan, Thailand)
Messaging-Plattform in 3 ostasiatischen Kernmärkten. Arbeit an Herausforderungen rund um CJK-Zeichenverarbeitung, Integration ins Plattform-Ökosystem und unterschiedliche Erwartungen an die Nutzererfahrung in Japan, Taiwan und Thailand.
KakaoTalk (South Korea)
Koreas führende Messaging-Plattform. Berücksichtigung koreanischer marktspezifischer Produktanforderungen, einschließlich Erwartungen an die Sprachformalität in der Benutzeroberfläche und Anforderungen an die Plattform-Integration.
Change.org (196 countries, 20+ priority languages)
Globale Petitionsplattform, bei der sowohl die Geschwindigkeit als auch die Qualität des Inhalts wichtig sind. Unterstützung beim Übersetzungs-Workflow für benutzergenerierte politische und soziale Inhalte über verschiedene Märkte hinweg.
Airbnb (220+ countries, 60+ languages)
Global-Marktplatz mit komplexen i18n-Anforderungen. Beratung zu Herausforderungen rund um Vertrauen und Sicherheit in mehreren Sprachen sowie kulturelle Anpassung von Plattformkonzepten über verschiedene Märkte hinweg.
Intercom (30+ languages, global B2B SaaS)
Kundenkommunikationsplattform für globale Unternehmenskunden. Arbeit an Produktinternationalisierung für Echtzeit-Support-Tools und Lokalisierung der Wissensdatenbank.
Lilith Games (China, Japan, Korea, US, EU)
Publisher für Mobile Games mit weltweit veröffentlichten Titeln. Bewältigte marktspezifische Herausforderungen rund um Inhaltslokalisierung und regionale Plattformanforderungen.
Märkte, in denen ich Produkte eingeführt habe:
Ostasien (Japan, Korea, China):
CJK-Typografie, Plattform-Ökosystem-Integration, vertikale Textunterstützung
Südostasien (Thailand, Vietnam, Indonesien):
Multi-Skript-Unterstützung, Mobile-First-Nutzererwartungen
MENA (arabischsprachige Regionen):
RTL-Layout-Anforderungen, Erwartungen an formelle vs. umgangssprachliche Sprache, kulturelle Anpassung von Inhalten
Europa:
24 Amtssprachen, länderübergreifende Produkteinführungen
Nord- und Südamerika:
Regionale Sprachvariationen (lateinamerikanisches Spanisch vs. Spanien, brasilianisches Portugiesisch), zweisprachige Märkte
Ich habe gesehen, was in diesen Märkten funktioniert und was nicht – nicht aus der Theorie, sondern durch den Einsatz von Produkten, auf die echte Nutzer angewiesen sind.
Beheben wir, was nicht funktioniert
Sie brauchen keinen Vortrag darüber, warum i18n wichtig ist. Sie brauchen jemanden, der schon um 2 Uhr morgens RTL-Popovers debuggt hat, sich mit dem Produktteam über Zeichenbudgets gestritten und Übersetzungspipelines entworfen hat, die tatsächlich funktionieren.
Architektur- und Strategieüberprüfung (1-2 Wochen):
Ich sage Ihnen, was schiefgehen wird, wenn Sie Ihre nächsten 3 Sprachen hinzufügen – und was es kosten wird, das zu beheben
Unterstützung beim Marktstart (4-8 Wochen):
Sie starten in Japan/MENA/EU und brauchen Experten, die das bereits gemacht haben
Laufende Partnerschaft:
Begleitende Beratung, während Sie von 2 auf 20 Sprachen wachsen
Ich mache keine Theorie. Ich mache Triage, Roadmaps und Umsetzung.