Inhaltsverzeichnis
Sprachanpassung in Software: Über die wörtliche Übersetzung hinausgehen
Wichtigste Erkenntnisse
- Sprachanpassung befasst sich mit Grammatik, Pluralformen, Genus, Formalität und kulturellem Kontext — nicht nur mit Vokabular
- ICU MessageFormat bietet eine Standardsyntax für die sprachübergreifende Behandlung von Pluralformen, Genus und Select-Ausdrücken
- Verschiedene Sprachen haben unterschiedliche Pluralregeln — Arabisch hat 6 Pluralformen, Japanisch hingegen keine
- Rechts-nach-links (RTL) Sprachen erfordern eine Spiegelung der Benutzeroberfläche, nicht nur eine Änderung der Textrichtung
- Korrekte Sprachanpassung reduziert Verwirrung bei Nutzern und verbessert die Produktakzeptanz in Zielmärkten
Was ist Sprachanpassung?
Sprachanpassung ist der Prozess, Softwareinhalte an die sprachlichen Regeln, kulturellen Normen und Nutzererwartungen jedes Zielgebiets anzupassen. Sie geht über die Übersetzung (das Ersetzen von Wörtern einer Sprache durch Wörter einer anderen) hinaus und berücksichtigt, wie sich Sprachen strukturell unterscheiden.
Englisch verwendet beispielsweise „1 item" vs. „2 items" (zwei Pluralformen), während Polnisch drei Formen hat: „1 element", „2 elementy", „5 elementów". Russisch hat eine ähnliche Komplexität. Arabisch hat sechs verschiedene Pluralkategorien. Eine korrekte Behandlung erfordert mehr als eine einfache Wörterbuchsuche.
Pluralregeln
Die Behandlung von Pluralformen ist eine der sichtbarsten Herausforderungen bei der Sprachanpassung in Software. Das Unicode CLDR (Common Locale Data Repository) definiert sechs Pluralkategorien: zero, one, two, few, many und other.
Beispiele nach Sprache
| Sprache | Verwendete Kategorien | Beispiel |
|---|---|---|
| Englisch | one, other | 1 file, 2 files |
| Französisch | one, other | 1 fichier, 2 fichiers (aber: „one" gilt für 0 und 1) |
| Polnisch | one, few, many, other | 1 plik, 2 pliki, 5 plików |
| Arabisch | zero, one, two, few, many, other | Alle 6 Formen werden verwendet |
| Japanisch | other | Nur eine Form (keine Pluralformen) |
| Russisch | one, few, many, other | 1 файл, 2 файла, 5 файлов |
ICU MessageFormat für Pluralformen
{count, plural,
one {# file selected}
other {# files selected}
}
Für Polnisch würde derselbe Schlüssel folgendes verwenden:
{count, plural,
one {# plik wybrany}
few {# pliki wybrane}
many {# plików wybranych}
other {# pliku wybranego}
}
Die i18n-Bibliothek ermittelt anhand der im CLDR definierten Pluralregeln der jeweiligen Locale, welche Kategorie zu verwenden ist.
Genus und grammatikalische Kongruenz
Viele Sprachen haben ein grammatikalisches Genus, das Artikel, Adjektive und Verbformen beeinflusst. Im Französischen wird „The file is deleted" je nach Kontext unterschiedlich übersetzt:
- Maskulin: „Le fichier est supprimé"
- Feminin: „La photo est supprimée"
ICU MessageFormat behandelt dies mit select:
{gender, select,
male {Le fichier est supprimé}
female {La photo est supprimée}
other {L'élément est supprimé}
}
Anwendungen müssen den Genuskontext zusammen mit dem übersetzten String übergeben, damit die korrekte Form gewählt werden kann.
Formalitätsstufen
Sprachen wie Japanisch, Koreanisch, Deutsch und Spanisch unterscheiden zwischen formeller und informeller Anrede. Dies betrifft:
- Pronomen: Deutsches „du" (informell) vs. „Sie" (formell)
- Verbkonjugationen: Spanisches „tú tienes" vs. „usted tiene"
- Gesamte Satzstrukturen: Japanisches Keigo (Höflichkeitssprache) verändert den Satzbau
Software für diese Märkte muss eine Formalitätsstufe festlegen und diese einheitlich anwenden. Die meisten B2B-Softwarelösungen verwenden formelle Anrede, während Consumer-Apps informelle wählen können.
Manche Anwendungen ermöglichen Nutzern, ihre bevorzugte Formalitätsstufe in den Einstellungen zu wählen, was die Pflege paralleler Übersetzungssätze erfordert.
Textexpansion und -kontraktion
Bei der Übersetzung aus dem Englischen in andere Sprachen ändert sich die Textlänge erheblich:
| Zielsprache | Typische Expansion |
|---|---|
| Deutsch | +30% länger |
| Finnisch | +30–40% länger |
| Französisch | +15–20% länger |
| Chinesisch | −30% kürzer |
| Japanisch | −20–30% kürzer |
| Koreanisch | −10–20% kürzer |
Dies beeinflusst das UI-Layout, Schaltflächengrößen, Tabellenspalten und Navigationsmenüs. Eine korrekte Sprachanpassung erfordert:
- Flexible Layouts, die Textexpansion aufnehmen können
- Tests mit der längsten Zielsprache (oft Deutsch oder Finnisch)
- Vermeidung von Containern mit fester Breite für übersetzbaren Text
- CSS-Techniken wie
text-overflow: ellipsisals letztes Mittel, nicht als Standard
Rechts-nach-links (RTL) Sprachen
Arabisch, Hebräisch, Persisch und Urdu werden von rechts nach links geschrieben. Die RTL-Anpassung geht über das bloße Setzen von dir="rtl" am HTML-Element hinaus:
- UI-Spiegelung: Navigation, Seitenleisten und Icon-Positionen sollten gespiegelt werden
- Bidirektionaler Text: Gemischter LTR/RTL-Inhalt (z. B. englische Markennamen in arabischem Text) erfordert eine korrekte Implementierung des Unicode Bidirectional Algorithm
- Richtungsgebundene Icons: Pfeil-Icons, Fortschrittsanzeigen und „Zurück"-Schaltflächen müssen gespiegelt werden
- Zahlen: Arabisch-Indische Ziffern (٠١٢٣) können in manchen Kontexten erwartet werden, während in anderen westliche Ziffern (0123) verwendet werden
- CSS logical properties:
margin-inline-startstattmargin-leftfür automatische RTL-Unterstützung verwenden
/* Statt: */
.sidebar { margin-left: 20px; }
/* Logische Properties verwenden: */
.sidebar { margin-inline-start: 20px; }
Datums-, Uhrzeit- und Zahlenformatierung
Locale-bewusste Formatierung ist ein wesentlicher Teil der Sprachanpassung:
| Format | US-Englisch | Deutsch | Japanisch |
|---|---|---|---|
| Datum | 03/02/2026 | 02.03.2026 | 2026年3月2日 |
| Zahl | 1,234.56 | 1.234,56 | 1,234.56 |
| Währung | $1,234.56 | 1.234,56 € | ¥1,235 |
| Uhrzeit | 3:30 PM | 15:30 | 15:30 |
Die Intl API in JavaScript übernimmt die meiste Formatierung automatisch:
new Intl.NumberFormat('de-DE', {
style: 'currency',
currency: 'EUR'
}).format(1234.56)
// → "1.234,56 €"
Praktische Implementierungstipps
- ICU MessageFormat verwenden: Es behandelt Pluralformen, Genus und Select-Ausdrücke sprachübergreifend auf standardisierte Weise
- Übersetzte Strings niemals verketten: „Welcome, " + name + „!" funktioniert nicht in Sprachen mit anderer Wortstellung
- Alle nutzerseitigen Texte externalisieren: Auch Fehlermeldungen und Validierungstexte müssen übersetzt werden
- Mit Pseudo-Lokalisierung testen: Werkzeuge verwenden, die Text expandieren und Sonderzeichen hinzufügen, um Layout-Probleme frühzeitig zu erkennen
- Kontext für Übersetzer bereitstellen: Ein String wie „Open" könnte ein Verb sein („Open the file") oder ein Adjektiv („The file is open") — der Kontext bestimmt die korrekte Übersetzung
- CSS logical properties verwenden: Sie behandeln RTL-Layouts automatisch ohne separate Stylesheets
- Mit Muttersprachlern validieren: Automatisierte Tools erkennen Formatierungsprobleme, aber kulturelle Angemessenheit erfordert menschliche Überprüfung
FAQ
Was ist der Unterschied zwischen Übersetzung und Sprachanpassung?
Übersetzung konvertiert Text von einer Sprache in eine andere. Sprachanpassung geht weiter, indem sie Grammatik (Pluralformen, Genus), Formatierung (Datumsangaben, Zahlen, Währungen), UI-Layout (RTL-Unterstützung, Textexpansion) und kulturellen Kontext (Formalitätsstufen, Farbbedeutungen, Redewendungen) anpasst, um für jede Locale ein natürliches Nutzererlebnis zu schaffen.
Wie hilft ICU MessageFormat bei der Sprachanpassung?
ICU MessageFormat ist eine Standardsyntax, die von den meisten i18n-Bibliotheken (react-intl, vue-i18n, better-i18n) unterstützt wird und es Übersetzern ermöglicht, Pluralformen, Genusauswahl und bedingten Text innerhalb eines einzigen Übersetzungsstrings zu behandeln. Statt dass Entwickler If/Else-Logik für die Regeln jeder Sprache schreiben, verfasst der Übersetzer das entsprechende MessageFormat-Muster, und die Bibliothek löst es zur Laufzeit auf.
Benötige ich separate Codebasen für RTL-Sprachen?
Nein. Moderne CSS logical properties (margin-inline-start, padding-block-end usw.) und das dir="rtl" HTML-Attribut behandeln die meisten RTL-Layouts automatisch. Der Schlüssel liegt darin, von Beginn des Projekts an hardcodierte Richtungswerte wie margin-left zugunsten logischer Äquivalente zu vermeiden.
