10 häufige i18n-Fehler und wie du sie vermeidest

Ein Entwickler schreibt ein Button-Label direkt in JSX: <button>Submit Order</button>.

Die App wird auf Englisch ausgeliefert und funktioniert einwandfrei. Sechs Monate später expandiert das Unternehmen nach Deutschland.

Das Lokalisierungsteam entdeckt 2.000+ hardcodierte Strings. Die Nachrüstung dauert 3 Wochen und verursacht 47 Bugs.

Richte ein Übersetzungs-Framework ein (z.B. next-intl, react-i18next, vue-i18n), bevor du deine erste Komponente schreibst.

Erstelle eine Ressourcen-Dateistruktur (z.B. messages/de.json) und referenziere alle Strings über Übersetzungs-Keys wie t('checkout.submitButton').

Füge eine Linting-Regel oder einen Pre-Commit-Hook hinzu, der rohes String-Literal in UI-Komponenten flaggt.

Eine Übersetzungsdatei enthält den Firmennamen 'CloudForge Inc.' und den technischen Begriff 'OAuth 2.0 Token' als reguläre übersetzbare Strings.

Der spanische Übersetzer übersetzt 'CloudForge' zu 'ForjaNube' und 'OAuth 2.0 Token' zu 'ficha OAuth 2.0'.

Ergebnis: Nutzer finden das Unternehmen nicht unter seinem echten Namen, und Entwickler, die die spanische Dokumentation lesen, sind verwirrt durch unbekannte übersetzte Fachbegriffe.

Erstelle ein 'Nicht übersetzen'-Glossar, das alle Markennamen, Produktnamen, juristische Personen und Fachbegriffe auflistet, die unverändert bleiben müssen.

Verwende einen separaten Namespace oder spezielle Keys für nicht-übersetzbare Inhalte. Viele i18n-Tools unterstützen 'gesperrte' Segmente, die Übersetzer nicht bearbeiten können.

Füge Übersetzer-Kommentare/Beschreibungen zu deinen Übersetzungsdateien hinzu, die den Kontext erklären: 'Dies ist ein Markenname — nicht übersetzen' oder 'Fachbegriff — auf Englisch belassen'.

Entwickler schreibt: 'You have ' + count + ' items in your ' + cartType + ' cart' — funktioniert perfekt auf Englisch.

Der deutsche Übersetzer erhält drei separate Fragmente und kann keinen grammatisch korrekten Satz bilden, weil die Wortstellung sich ändern muss.

Ergebnis: Deutsche Nutzer sehen 'Sie haben 5 Artikel in Ihrem Warenkorb Standard' — holprig und unprofessionell.

Ersetze Verkettung durch einen einzelnen Message-Key mit Platzhaltern: 'cart.summary': 'Du hast {count} Artikel in deinem '{cartType}'-Warenkorb'.

Übergib Variablen als Parameter an deine Übersetzungsfunktion: t('cart.summary', { count: 5, cartType: 'Premium' }).

Übersetzer können jetzt frei umstellen: 'In deinem '{cartType}'-Warenkorb befinden sich {count} Artikel' — grammatisch korrektes Deutsch.

Entwickler schreibt: count + (count === 1 ? ' Datei' : ' Dateien') — behandelt Deutsch korrekt.

Der polnische Übersetzer braucht 4 Formen: 1 plik, 2-4 pliki, 5-21 plików, 22-24 pliki. Der einfache Ternär kann das nicht ausdrücken.

Ergebnis: Polnische Nutzer sehen '5 pliki' (falsche Form) statt '5 plików' (korrekte Form), und die App wirkt kaputt.

Definiere Nachrichten mit ICU-Syntax: 'fileCount': '{count, plural, one {# Datei} other {# Dateien}}'.

Übersetzer stellen alle benötigten Pluralformen für ihre Sprache bereit. Polnisch: '{count, plural, one {# plik} few {# pliki} many {# plików} other {# pliku}}'.

Deine i18n-Library wählt zur Laufzeit automatisch die korrekte Form basierend auf den CLDR-Regeln der aktiven Locale.

Designer erstellt eine Navigationsleiste mit 5 Buttons, jeweils exakt 100px breit — sieht auf Englisch super aus.

Deutsche Übersetzung: 'Settings' wird zu 'Einstellungen' (13 vs 8 Zeichen), 'Submit' wird zu 'Absenden' (8 vs 6). Die Navbar läuft über.

Ergebnis: Auf Mobilgeräten stapeln sich Buttons übereinander oder Text wird abgeschnitten, was die Navigation für deutsche Nutzer unbrauchbar macht.

Ersetze feste Breiten durch min-width, max-width und Flex-Layouts. Nutze CSS Grid oder Flexbox, um Platz dynamisch zu verteilen.

Setze Textcontainer auf Umbruch: verwende overflow-wrap: break-word und vermeide white-space: nowrap bei übersetzbarem Content.

Teste dein UI mit Pseudo-Lokalisierung, die alle Strings um 40% verlängert, um den Worst Case zu simulieren — noch bevor du Strings an Übersetzer schickst.

Entwickler formatiert ein Datum als MM/DD/YYYY und einen Preis als $1,234.50 — korrekt für US-Nutzer.

Ein deutscher Nutzer sieht das Datum 03/04/2025 und liest es als 3. April (DD/MM/YYYY-Konvention). Der Preis $1,234.50 sieht aus, als sollte es 1.234,50 sein.

Ergebnis: Der Nutzer bucht einen Flug für das falsche Datum und hinterfragt das Preisformat. Support-Tickets steigen im deutschen Markt um 15%.

Ersetze manuelle Formatierung durch Intl.DateTimeFormat(locale) für Daten und Intl.NumberFormat(locale, { style: 'currency', currency }) für Preise.

Speichere Daten intern im ISO 8601 Format (YYYY-MM-DD) und formatiere sie nur für die Anzeige mit der Locale des Nutzers.

Teste kritische Datums-/Zahlenanzeigen mit mindestens 5 verschiedenen Locales: en-US, de-DE, ja-JP, ar-SA und zh-CN, um die wichtigsten Formatierungsvarianten abzudecken.

Entwickler verwendet margin-left: 16px und text-align: left durch die gesamte App — Standard-LTR-Praxis.

Die App startet in Saudi-Arabien. Zurück-Pfeile zeigen vorwärts, Sidebars erscheinen auf der falschen Seite, und numerische Daten sind falsch ausgerichtet.

Ergebnis: Arabische Nutzer verlassen die App nach 30 Sekunden. Das Team braucht 4 Wochen Notfall-CSS-Refactoring, um das Problem zu beheben.

Ersetze alle physischen CSS-Properties durch logische Äquivalente: margin-left → margin-inline-start, padding-right → padding-inline-end, text-align: left → text-align: start.

Setze das dir-Attribut auf deinem HTML-Root-Element basierend auf der aktiven Locale. Nutze die :dir(rtl) CSS-Pseudoklasse für RTL-spezifische Overrides.

Prüfe alle Icons auf Richtungsbedeutung. Ersetze richtungsgebundene Icons durch gespiegelte Versionen oder nutze CSS transform: scaleX(-1) für RTL-Kontexte.

Ein Designer erstellt ein Promo-Banner mit dem Text 'Start Your Free Trial' direkt im Bild eingebettet.

Das Lokalisierungsteam übersetzt alle UI-Strings, aber das Banner zeigt auf der deutschen Seite immer noch englischen Text.

Ergebnis: Die deutsche Landingpage hat ein irritierendes englisches Banner. Lokalisierte Banner für 15 Sprachen zu erstellen dauert 3 Tage Designarbeit und verzögert den Launch.

Nutze CSS, um übersetzbaren Text über Hintergrundbilder zu legen: positioniere die Textebene mit absolute Positioning über dem Bild-Container.

Für Infografiken oder Diagramme nutze SVGs mit <text>-Elementen, die Übersetzungs-Keys referenzieren, statt rohe Strings einzubetten.

Für App-Screenshots in Marketingmaterialien automatisiere die Screenshot-Generierung mit Tools wie Fastlane (Mobile) oder Playwright (Web), die Screens in jeder Locale aufnehmen.

Entwickler fügt einen neuen 'Premium Features'-Bereich mit 15 neuen Übersetzungs-Keys hinzu. Die englische Version wird sofort ausgeliefert.

Die französischen Übersetzungen sind noch nicht fertig. Die französische Seite zeigt rohe Keys: 'premium.feature1.title', 'premium.feature1.description'.

Ergebnis: Französische Nutzer sehen eine kaputte Seite voller entwicklerseitiger Key-Namen. Das Support-Team erhält dutzende Bug-Reports.

Richte eine Fallback-Sprachkette in deiner i18n-Konfiguration ein: fehlende französische (fr) Keys fallen automatisch auf Englisch (en) zurück.

Füge einen Missing-Key-Handler hinzu, der unübersetzte Keys an dein Monitoring-System (z.B. Sentry, Datadog) loggt, ohne das Nutzererlebnis zu brechen.

Erstelle ein Übersetzungs-Coverage-Dashboard, das den Fertigstellungsgrad pro Locale trackt und Releases blockiert, wenn die Abdeckung unter einen Schwellenwert fällt (z.B. 95%).

Entwickler richtet eine MySQL-Datenbank mit latin1-Collation ein (der alte Standard). Der App-Quellcode nutzt UTF-8.

Japanische Nutzer registrieren sich mit ihrem echten Namen. Die Datenbank speichert '田中太郎' als beschädigte Bytes.

Ergebnis: Das Nutzerprofil zeigt verstümmelten Text. Schlimmer noch: Suche und Sortierung brechen für alle CJK-Namen, was tausende Nutzer betrifft.

Setze alle Quelldateien auf UTF-8 (konfiguriere deinen Editor und .editorconfig). Füge <meta charset='UTF-8'> in dein HTML und 'Content-Type: application/json; charset=utf-8' in API-Antworten ein.

Konfiguriere deine Datenbank auf utf8mb4 (nicht nur utf8, was in MySQL ein 3-Byte-Subset ist). Setze die Connection-Collation auf utf8mb4_unicode_ci.

Wähle Schriftarten, die deine Zielschriftsysteme abdecken: Lateinisch, Kyrillisch, CJK, Arabisch, Devanagari. Nutze System-Font-Stacks oder Google Fonts mit Sprach-Subsets für optimales Laden.