Lokalisierung — die Essenz, Anpassung von Inhalten an Sprache und Region

Was ist Lokalisierung (l10n) und wie unterscheidet sie sich von i18n?

Lokalisierung (abgekürzt l10n — 10 Buchstaben zwischen „l“ und „n“) ist der Prozess der Anpassung einer Anwendung an eine bestimmte Sprache und Region. Wenn i18n das architektonische Fundament ist, dann ist l10n der Inhalt. i18n ermöglicht die Übersetzung, l10n führt sie aus. Die Lokalisierung umfasst: Übersetzung aller Oberflächentexte, Anpassung von Datums- und Zahlenformaten, Austausch kulturell sensibler Bilder, Anpassung rechtlicher Texte (Datenschutzerklärung, EULA), Konfiguration von Zahlungssystemen für die Region und Tests auf Zielgeräten.

Business-ROI — Lokalisierung wirkt sich direkt auf die Conversion aus. Laut CSA Research (2023) bevorzugen 76% der Nutzer den Kauf in Apps in ihrer Muttersprache, und 40% kaufen niemals in einer Fremdsprache. Die Lokalisierung einer Einzelhandels-App ins Japanische steigert die Conversion im Durchschnitt um 150% (Google, 2022). Lokalisierte Apps erhalten 2–3 Mal mehr organische Installationen in regionalen App Stores und bei Google Play dank regionalem ASO (Keywords in der Zielsprache).

i18n vs l10n — zwei Seiten desselben Prozesses. i18n: Auslagern von Zeichenketten in Ressourcen, RTL-Unterstützung, Zahlenformatierung. Wird einmal von Entwicklern durchgeführt. l10n: Übersetzen von Zeichenketten, Anpassen von Inhalten, lokale Tests. Wird wiederholt von Übersetzern und QA für jedes Gebietsschema durchgeführt. Bei IT Sectr reservieren wir 20–30% der Sprintzeit für die Lokalisierung jeder neuen Sprache — das umfasst Übersetzung, Überprüfung, Tests auf Geräten und Fehlerbehebung.

Lokalisierung unter iOS: Localizable.strings und Base Internationalization

Localizable.strings — die Hauptdatei zum Speichern von Übersetzungen unter iOS. Jedes Gebietsschema hat seinen eigenen .lproj-Ordner: en.lproj/Localizable.strings, ru.lproj/Localizable.strings, de.lproj/Localizable.strings. Format: „Schlüssel“ = „Wert“; (mit Semikolon). Apple verwendet Base Internationalization: Storyboard und XIB werden einmal erstellt (Base.lproj), und Oberflächenzeichenketten werden für jede Sprache in Localizable.strings exportiert. Dadurch entfällt die Notwendigkeit, Kopien des XIB für jedes Gebietsschema zu erstellen.

// en.lproj/Localizable.strings
// "settings.title" = "Einstellungen";
// "profile.greeting" = "Hallo, %@!";
// "items.count" = "%d Artikel";

// ru.lproj/Localizable.strings
// "settings.title" = "Einstellungen";
// "profile.greeting" = "Hallo, %@!";
// "items.count" = "%d Artikel";

// Laden einer Zeichenkette per Schlüssel
navigationItem.title = NSLocalizedString(
    "settings.title",
    comment: "Titel des Einstellungsbildschirms"
)

// Zeichenkette mit Parameter
let name = "Anna"
greetingLabel.text = String.localizedStringWithFormat(
    NSLocalizedString("profile.greeting", comment: ""), name
)

// XLIFF-Import (Xcode → Editor → Import Localizations)
// Aktualisiert automatisch .lproj-Dateien nach der Arbeit des Übersetzers

Base Internationalization — Apples Ansatz, bei dem die Oberfläche (Storyboard, XIB) einmal in Base.lproj erstellt wird. Beim Hinzufügen einer Sprache exportiert Xcode Zeichenketten aus Base in eine XLIFF-Datei. Der Übersetzer übersetzt das XLIFF. Nach dem Import erstellt Xcode .lproj mit übersetzten Zeichenketten. Vorteil: Keine Duplizierung des XIB für jede Sprache erforderlich. Einschränkung: Für RTL-Sprachen (Arabisch, Hebräisch) kann ein separates XIB mit gespiegeltem Layout erforderlich sein.

InfoPlist.strings und Metadaten-Lokalisierung

InfoPlist.strings — eine Datei zur Lokalisierung des App-Namens (CFBundleDisplayName), von Kamera-/Mikrofonberechtigungen (NSCameraUsageDescription) und anderen Werten aus Info.plist. Wird in .lproj erstellt: ru.lproj/InfoPlist.strings. Format: CFBundleDisplayName = „Meine App“; NSCameraUsageDescription = „Die App benötigt Kamerazugriff zum Fotografieren“;. Ohne Lokalisierung von InfoPlist.strings werden Systemdialoge auf Englisch angezeigt.

Lokalisierung unter Android: values-ru und lokalisierte Ressourcen

Android-Ressourcen für die Lokalisierung werden durch Qualifizierer in Verzeichnisnamen organisiert. Für Russisch — res/values-ru/, für Deutsch — res/values-de/, für brasilianisches Portugiesisch — res/values-pt-rBR/. Android unterstützt mehr als 160 Gebietsschemata. Das System wählt automatisch Ressourcen basierend auf der Gerätesprache aus (Locale.getDefault()). Wenn kein genaues Gebietsschema gefunden wird, werden Ressourcen aus values/ (Basisgebietsschema, normalerweise en) verwendet.

// res/values/strings.xml (Basis — Englisch)
<string name="settings_title">Settings</string>
<string name="greeting">Hello, %s!</string>

// res/values-ru/strings.xml (Russisch)
<string name="settings_title">Einstellungen</string>
<string name="greeting">Hallo, %s!</string>

// res/values-de/strings.xml (Deutsch)
<string name="settings_title">Einstellungen</string>
<string name="greeting">Hallo, %s!</string>

// Kotlin — einheitlicher Code für alle Sprachen
textView.text = getString(R.string.settings_title)

// Zeichenkette mit Parameter
val greeting = getString(R.string.greeting, userName)

// Lokalisierte Bilder
// res/drawable-ru/flag.png — Flagge für die russische Version
// res/drawable/flag.png — Standard-Flagge

// Layout-Lokalisierung (für RTL-Sprachen)
// res/layout-ar/activity_main.xml — arabische Version

Lokalisierung über Zeichenketten hinaus — Android ermöglicht die Lokalisierung von Bildern (res/drawable-ru/), Farben (res/values-ru/colors.xml), Abmessungen (res/values-ru/dimens.xml), Animationen, Menüs und sogar ganzer Layouts. Für Sprachen mit unterschiedlicher Wortlänge (Deutsch ist 30–40% länger als Englisch) verwenden Sie lokalisierte dimens.xml mit vergrößerten Schaltflächenbreiten. Für Regionen mit unterschiedlicher Farbsymbolik (Weiß ist Trauer in China) verwenden Sie lokalisierte colors.xml.

Lokalisierungstest auf dem Gerät

Testen — Ändern Sie die Gerätesprache über Einstellungen → System → Sprache in die Zielsprache. Überprüfen Sie: Alle Zeichenketten sind übersetzt, Daten sind korrekt formatiert, Zahlen werden mit dem richtigen Trennzeichen angezeigt, Bilder entsprechen der Region, das Layout bricht bei langen Zeichenketten nicht. Für die Automatisierung verwenden Sie Espresso mit LocaleTestRule (Android Testing Library) — damit können Tests mit verschiedenen Gebietsschemata ausgeführt werden, ohne die Sprache manuell umschalten zu müssen.

Kulturelle Anpassung: Was außer Text zu übersetzen ist

Kulturelle Besonderheiten — Lokalisierung beschränkt sich nicht auf die Übersetzung von Zeichenketten. Die Farbsymbolik variiert: Rot ist Glück in China, Gefahr in den USA, Trauer in Südafrika. Weiß ist Reinheit in Europa, Trauer in China. Gestensymbole: Daumen hoch ist positiv in den USA, eine Beleidigung im Nahen Osten. Bilder von Menschen: In arabischen Ländern sind Bilder von Frauen in Badebekleidung inakzeptabel. Religiöse Symbole: Kreuz, Halbmond, Davidstern sollten nur im entsprechenden Kontext verwendet werden.

Rechtliche Anforderungen — jedes Land hat seine eigenen Gesetze zu digitalen Produkten. GDPR (EU) — zwingende Zustimmung zu Cookies und Datenverarbeitung. CCPA (Kalifornien) — Recht auf Datenlöschung. Personendatengesetz (Russland, 152-FZ) — Datenspeicherung auf russischen Servern. LGPD (Brasilien) — GDPR-Äquivalent. Zahlungen: In China werden Alipay/WeChat Pay benötigt, in Indien — UPI, in Brasilien — Boleto und PIX. Konfigurieren Sie das Zahlungsgateway für die Region, bevor Sie die Lokalisierung starten.

Beispiele und Inhalt — passen Sie Beispiele an die Region an. Für die deutsche Lokalisierung verwenden Sie das metrische System (kg, km), für die amerikanische — das imperiale System (lb, mi). Telefonnummern, Postleitzahlen, Adressen — alles wird unterschiedlich formatiert. Währungsbeispiele: ¥1000 in Japan, $9.99 in den USA, 999 ₽ in Russland. Bilder von Essen, Kleidung und Innenräumen sollten den regionalen Standards entsprechen. Bei IT Sectr empfehlen wir die Beauftragung lokaler Berater zur Überprüfung der kulturellen Anpassung.

Lokalisierungsprozess: Werkzeuge, Übersetzer, CI/CD

Lokalisierungswerkzeuge — professionelle Plattformen automatisieren den Prozess: Lokalise, Crowdin, POEditor, Smartling, Phrase. Sie integrieren sich in das Repository, importieren automatisch neue Zeichenketten, verfolgen Änderungen (Delta-Updates — nur geänderte Zeichenketten werden übersetzt), bieten Übersetzungsspeicher (TM — Speicherung zuvor übersetzter Phrasen) und Glossar. Durchschnittliche Kosten für professionelle Übersetzung: 0,08–0,15 $ pro Wort (je nach Sprache).

Prozess — (1) Der Entwickler fügt i18n-Schlüssel zum Code hinzu und pusht in das Repository. (2) CI/CD (GitHub Actions / GitLab CI) sendet automatisch neue Schlüssel an die Lokalisierungsplattform. (3) Übersetzer erhalten eine Benachrichtigung, übersetzen und speichern. (4) Übersetzte Dateien erstellen automatisch einen PR im Repository. (5) QA überprüft die Lokalisierung auf Geräten. (6) Veröffentlichung. Zyklus für ein Gebietsschema: 2–5 Werktage (je nach Umfang). Für 10 Gebietsschemata: 5–15 Tage bei paralleler Arbeit der Übersetzer.

Maschinelle Übersetzung + menschliche Überprüfung — der moderne Standard. Neuronale Netzübersetzung (DeepL, Google Translate, GPT-4) bietet 80–90% Qualität für gängige Sprachpaare. Ein menschlicher Übersetzer überprüft: Terminologie, Kontext (Wörter können auf verschiedenen Bildschirmen unterschiedliche Bedeutungen haben), kulturelle Anpassung. Bei IT Sectr verwenden wir einen hybriden Ansatz: ML-Übersetzung + Überprüfung durch einen Muttersprachler. Für kritische Zeichenketten (rechtliche, Zahlungsverkehr) — nur professionelle Übersetzung. Einsparungen: bis zu 60% der Kosten bei gleichbleibender Qualität.