Globalization: Was ist das, i18n und Mehrsprachigkeit in Apps

Was ist Globalization (i18n) und wozu braucht man es?

Globalization (abgekürzt als i18n — 18 Buchstaben zwischen "i" und "n") ist die architektonische Vorbereitung einer Anwendung für die Arbeit mit jeder Sprache und Region. Die Schlüsselregel von i18n: Keine Textzeichenkette darf im Quellcode hartcodiert (hardcoded) sein. Stattdessen werden Zeichenketten in Ressourcendateien ausgelagert, und der Code greift über Schlüssel darauf zu. Beim Hinzufügen einer neuen Sprache reicht es aus, eine Übersetzungsdatei hinzuzufügen — der Code bleibt unverändert. Dies unterscheidet i18n von der Lokalisierung (l10n), bei der die Zeichenketten selbst übersetzt werden.

Geschäftsargument — Globalisierung erweitert den Markt. Laut Common Sense Advisory (2023) bevorzugen über 70% der Benutzer den Kauf in Apps in ihrer Muttersprache. Die Lokalisierung in 10 Sprachen erhöht die potenzielle Zielgruppe um 80%. Ohne i18n erfordert jede Erweiterung auf eine neue Sprache Code-Änderungen, was den Markteintritt verlangsamt und die Kosten um das 5- bis 10-fache erhöht. Eine richtige i18n-Architektur ermöglicht die Unterstützung von 40+ Sprachen mit minimalen Kosten.

Komponenten von i18n umfassen: Zeichenketten-Externalisierung, Pluralbildung (für 1/2/5+), Datums- und Zahlenformatierung (DateFormatter/SimpleDateFormat), Unterstützung von RTL-Sprachen (Right-to-Left), Sortierung nach Locale-Regeln (Collator), regionale Symbole (Tausendertrennzeichen, Dezimalzeichen). Bei IT Sectr implementieren wir i18n in der Architekturphase, nicht nachträglich — das spart bis zu 60% Zeit bei der späteren Lokalisierung.

Internationalisierung in iOS: NSLocalizedString und XLIFF

NSLocalizedString ist das wichtigste Swift-Makro für die Arbeit mit Übersetzungen. Format: NSLocalizedString("key", comment: "Beschreibung für den Übersetzer"). Das Makro setzt automatisch die Zeichenkette aus Localizable.strings für das aktuelle Gebietsschema des Geräts ein (NSLocale.preferredLanguages). Wenn keine Übersetzung für den Schlüssel gefunden wird, wird der Schlüssel selbst oder der Wert in der Entwicklungssprache (normalerweise en) zurückgegeben. Apple empfiehlt die Verwendung aussagekräftiger Schlüssel anstelle von englischen Zeichenketten als Schlüssel.

// Localizable.strings (en)
// "welcome_title" = "Welcome!";
// Localizable.strings (ru)
// "welcome_title" = "Willkommen!";

// Swift-Code — für alle Sprachen einheitlich
titleLabel.text = NSLocalizedString(
    "welcome_title",
    comment: "Titel des Willkommensbildschirms"
)

// Pluralformen über Localizable.stringsdict
// 
// <dict>
//     <key>items_count</key>
//     <dict>
//         <key>NSStringLocalizedFormatKey</key>
//         <string>%#@items@</string>
//         <key>items</key>
//         <dict>
//             <key>one</key>
//             <string>%d Produkt</string>
//             <key>few</key>
//             <string>%d Produkte</string>
//             <key>many</key>
//             <string>%d Produkte</string>
//         </dict>
//     </dict>
// </dict>

// Verwendung von Pluralformen
let items = 5
let label = String.localizedStringWithFormat(
    NSLocalizedString("items_count", comment: ""), items
)

XLIFF — ein Format zum Austausch von Übersetzungen zwischen Entwicklern und Übersetzern. Xcode exportiert eine XLIFF-Datei (Editor → Export for Localization), die alle zu übersetzenden Zeichenketten enthält. Der Übersetzer arbeitet mit XLIFF in CAT-Tools (Trados, memoQ, Smartcat). Nach der Übersetzung wird XLIFF zurück in Xcode importiert (Editor → Import Localizations). XLIFF aktualisiert automatisch alle .lproj-Verzeichnisse. Dies ist der Standard-Workflow für die Lokalisierung von iOS-Apps in der Produktion.

SwiftUI und i18n

SwiftUI arbeitet mit NSLocalizedString über den Text-Initialisierer. Text in SwiftUI wird automatisch internationalisiert: Text("welcome_title") sucht die Übersetzung in Localizable.strings genauso wie NSLocalizedString. Für Pluralformen verwenden Sie Text("%d items", count: items). SwiftUI unterstützt die Datumsformatierung über Text(date, style: .date) — es verwendet automatisch Locale.current. Apple empfiehlt SwiftUI für neue Projekte, da die Internationalisierung darin transparenter ist.

Internationalisierung in Android: strings.xml und RTL

Android i18n basiert auf dem Ressourcensystem. Zeichenketten werden in res/values/strings.xml für die Standardsprache (normalerweise Englisch) abgelegt. Für jede Sprache wird ein separates Verzeichnis erstellt: res/values-ru/strings.xml (Russisch), res/values-de/strings.xml (Deutsch), res/values-fr/strings.xml (Französisch). Android wählt automatisch Zeichenketten basierend auf der Systemsprache des Geräts aus (Locale.getDefault()). Wenn keine genaue Locale gefunden wird, wird die Basis (values/strings.xml) verwendet.

// res/values/strings.xml (Englisch, Standard)
<resources>
    <string name="welcome_title">Welcome!</string>
    <string name="items_count">%d item(s)</string>
</resources>

// res/values-ru/strings.xml (Russisch)
<resources>
    <string name="welcome_title">Willkommen!</string>
    <plurals name="items_count">
        <item quantity="one">%d Artikel</item>
        <item quantity="few">%d Artikel</item>
        <item quantity="many">%d Artikel</item>
    </plurals>
</resources>

// Kotlin-Code
textView.text = getString(R.string.welcome_title)

// Pluralformen
val items = 5
textView.text = resources.getQuantityString(
    R.plurals.items_count, items, items
)

// RTL-Unterstützung im Code
textView.textDirection = View.TEXT_DIRECTION_LOCALE
// Manifest: supportsRtl="true"

RTL (Right-to-Left) — Unterstützung für Sprachen, bei denen Text von rechts nach links gelesen wird (Arabisch, Hebräisch, Urdu, Farsi). Android unterstützt RTL über die Attribute android:layoutDirection und android:textDirection. Geben Sie im Manifest android:supportsRtl="true" an — und Android spiegelt das Layout automatisch. NavDrawer, Zurück/Vorwärts-Symbole, Textausrichtung sollten in beide Richtungen funktionieren. Verwenden Sie im Code View.LAYOUT_DIRECTION_LOCALE und Gravity.START/END anstelle von LEFT/RIGHT.

Lokalisierte Ressourcen

Android Resource Qualifiers ermöglichen die Lokalisierung nicht nur von Zeichenketten, sondern auch von Bildern (res/drawable-ru/), Layouts (res/layout-ru/), Animationen, Farben. Für Arabisch und Hebräisch werden separate Layouts mit gespiegelten Elementen benötigt — verwenden Sie res/layout-ar/ (Arabisch). Android unterstützt auch regionale Varianten: values-rUS, values-rGB, values-de-DE. Qualifiers können kombiniert werden: values-ldrtl-ru — Russisch für RTL-Displays.

Regionale Formate: Daten, Zahlen, Währung in iOS und Android

Daten und Uhrzeit — einer der Schlüsselaspekte von i18n. Verschiedene Regionen verwenden unterschiedliche Formate: Russland — TT.MM.JJJJ, USA — MM/TT/JJJJ, Japan — JJJJ.MM.TT. Die Verwendung eines festen Formats (yyyy-MM-dd) zur Anzeige für den Benutzer ist ein Fehler. Verwenden Sie in iOS DateFormatter mit Locale(identifier: locale), in Android — DateFormat.getDateInstance(DateFormat.SHORT, locale). Für Sprachassistenten und KI-Suche sollten Daten intern im ISO 8601-Format vorliegen.

Zahlen und Währung — verschiedene Regionen haben unterschiedliche Trennzeichen: 1,234.56 (USA) vs 1.234,56 (Russland), 1 234,56 (Frankreich). iOS: NumberFormatter mit .locale = locale. Android: DecimalFormat mit DecimalFormatSymbols(locale). Für Währungen: Format ¥1,234 (Japan) vs $1,234.56 (USA) vs 1 234,56 ₽ (Russland). Verketten Sie Währung und Zahl niemals manuell — verwenden Sie NumberFormatter.currencyCode und .currencySymbol.

Sortierung (Kollation) — die alphabetische Sortierung unterscheidet sich zwischen Sprachen. Im Spanischen kommt "ch" nach "c". Im Schwedischen steht "ä" am Ende des Alphabets. Im Deutschen wird "ß" wie "ss" sortiert. iOS: LocalizedComparison (String.localizedCompare). Android: Collator.getInstance(locale). Verwenden Sie niemals compareTo() für Zeichenketten, die dem Benutzer angezeigt werden — es verwendet die Unicode Code Point-Reihenfolge, die regionale Regeln nicht berücksichtigt.

Bewährte Verfahren zur Internationalisierung mobiler Apps

Architekturprinzipien — beginnen Sie mit i18n ab dem ersten Commit. Jede Zeichenkette im Code sollte eine Wrapper-Funktion (tr("key")) durchlaufen, die erst existiert, wenn i18n eingerichtet ist — das zwingt den Entwickler, Zeichenketten sofort auszulagern. Verwenden Sie keine englischen Zeichenketten als Schlüssel — wenn sich die englische Formulierung ändert, müssen alle Übersetzungen aktualisiert werden. Verwenden Sie aussagekräftige Schlüssel: "profile.title", "settings.language.label".

Pseudolokalisierung — eine Testtechnik für i18n vor der eigentlichen Übersetzung. Ersetzen Sie jeden lateinischen Buchstaben durch Zeichen mit Diakritika (á, é, ñ, ü) zur Überprüfung der Kodierung, fügen Sie ein Präfix [XXX] hinzu, um das Abschneiden von Zeichenketten zu prüfen. Xcode: Ausführungsschemata — Pseudosprache "Double-Length Pseudolanguage". Android: Entwickleroptionen — RTL-Layoutrichtung erzwingen, Systemschriftskalierung bis 200%. Pseudolokalisierung findet 80% der i18n-Probleme ohne Beteiligung eines Übersetzers.

IT Sectr i18n-Checkliste — vor der Veröffentlichung prüfen wir: (1) keine hartcodierten Zeichenketten im Code (Ausnahme: Logs), (2) Pluralformen funktionieren korrekt für alle Sprachen, (3) Daten/Zahlen werden über die Locale-API formatiert, (4) Layout wird auf RTL-Sprachen korrekt angezeigt, (5) Zeichenketten werden bei maximaler Skalierung nicht abgeschnitten, (6) Pseudolokalisierung hat keine Fehler ergeben, (7) alle in den Stores angegebenen Sprachen haben einen vollständigen Satz von Übersetzungen.