Die Entwicklung der iOS-Lokalisierung
Um zu verstehen, wie weit die Lokalisierung gekommen ist – und wo sie noch Schwächen hat – werfen wir einen kurzen Blick zurück: In der Ära vor den String Catalogs verließen sich Entwickler auf eine Kombination aus .strings- und .stringsdict-Dateien, organisiert in sprachspezifischen Ordnern wie en.lproj. Dieses System war zwar funktional, hatte aber einige Nachteile:
Fehlende Sicherheitsprüfungen für ungenutzte oder fehlende Übersetzungen
Manuelle Synchronisierung zwischen verschiedenen Sprachdateien nötig
Keine eingebaute Unterstützung für die Extraktion von Strings aus dem Code
Tools wie SwiftGen und BartyCrouch entstanden, um diese Probleme zu lösen, und boten Typsicherheit und automatisierte Extraktion. Und die Community etablierte Best Practices rund um semantische Keys (z. B. "Onboarding.Page1.title"), um Kontext für Übersetzer zu liefern und verwandte Strings zu gruppieren.
String Catalogs: Ein Gamechanger mit Kompromissen
String Catalogs, 2023 von Apple eingeführt, lösten mehrere langjährige Probleme:
✅ Automatische Key-Extraktion aus dem Code ✅ Eingebaute Sicherheitsprüfungen für fehlende Übersetzungen ✅ Visuelles Fortschritts-Tracking in Xcode ✅ Einheitliches Dateiformat für alle Sprachen ✅ Abwärtskompatibilität mit älteren iOS-Versionen
Allerdings brachte Apples empfohlener Ansatz, englische Strings als Keys zu verwenden – obwohl er die Lesbarkeit im Code verbessert – neue Herausforderungen mit sich:
❌ Zusammengehörige Strings sind alphabetisch verstreut ❌ Weniger Kontext für Übersetzer ❌ Keine Gruppierung nach Feature oder Screen
Das Fehlen von Gruppierung in String Catalogs ist beim Übersetzen nicht hilfreich.
Ebenso wichtig: Es gibt eine erhebliche Lücke im iOS-Entwicklungs-Ökosystem rund um Lokalisierung, die der Situation bei Icons vor SF Symbols ähnelt. Vor SF Symbols musste jeder Entwickler eigene Icons erstellen oder beschaffen, was zu inkonsistenten Erlebnissen über Apps hinweg führte. SF Symbols löste das durch einen standardisierten, umfassenden Satz an Icons, die Konsistenz sicherstellen und enorm viel Entwicklungszeit sparen.
Der Lokalisierungsbereich braucht dringend eine ähnliche Lösung. Jede App braucht gängige UI-Strings wie “Speichern”, “Abbrechen”, “Fertig”, “Datenschutzrichtlinie” oder “Allgemeine Geschäftsbedingungen” – und diese sollten über Apps hinweg genauso konsistent sein wie Icons. Nutzer profitieren von dieser Konsistenz in gleicher Weise wie von konsistenter Ikonografie. Doch aktuell muss jeder Entwickler diese gängigen UI-Elemente unabhängig übersetzen, was zu unterschiedlichen Übersetzungen für die gleichen Konzepte in verschiedenen Apps und Sprachen führt.
TranslateKit: Das fehlende Puzzlestück
Das Open-Source-TranslateKit SDK schließt diese Lücken und bietet eine umfassende Lösung, die Best Practices beibehält und gleichzeitig die Vorteile von String Catalogs voll ausschöpft. So wie SF Symbols die Icon-Nutzung in iOS-Apps revolutioniert hat, will dieses neue Swift-Package dasselbe für die Lokalisierung tun.
1. Semantische Key-Generierung ohne Aufwand
Das #tk-Macro bringt semantische Keys zurück und hält den Code dabei sauber und lesbar:
struct OnboardingView: View {
var body: some View {
// Generates key: OnboardingView.Body.welcomeToMyApp
Text(#tk("Welcome to MyApp"))
}
}Dieser Ansatz:
Generiert automatisch semantische Keys basierend auf dem Code-Kontext
Bewahrt die Lesbarkeit des Codes
Liefert wichtigen Kontext für Übersetzer
Gruppiert zusammengehörige Strings im String Catalog
Automatisch generierte semantische Keys, die zusammengehörige Strings natürlich gruppieren.
Und alles, was du schreiben musst, ist #tk() um deine String-Literale. Super einfach!
2. Vorlokalisierte gängige UI-Elemente
So wie SF Symbols die Icon-Nutzung standardisiert hat, brauchen wir Konsistenz bei UI-Texten. TranslateKit bietet über 2.000 Strings, die in alle 40 von Apple im iOS-Betriebssystem unterstützten Sprachen vorlokalisiert sind.
Sie sind in 4 Kategorien unterteilt, damit du leicht findest, was du brauchst:
// Actions
Button(TK.Action.save) { saveData() }
// => en: "Save", de: "Sichern", etc.
// Labels
Text(TK.Label.privacyPolicy)
// => en: "Privacy Policy", de: "Sichern", etc.
// Messages
Text(TK.Message.areYouSure)
// => en: "Privacy Policy", de: "Datenschutzerklärung", etc.
// Placeholders
ProgressView(TK.Placeholder.loadingDots)
// => en: "Loading…", de: "Laden…", etc.Vorteile:
Passt zu System-UI-Übersetzungen von Apple (Konsistenz)
Garantiert professionelle Qualität für gängige UI-Elemente (Genauigkeit)
Reduziert den Lokalisierungsaufwand (spart Zeit & Geld)
3. Kontextbewusste Übersetzungen
Moderne Lokalisierung bedeutet nicht nur, Wörter zu übersetzen – es geht darum, den Kontext zu verstehen. Während die automatische Key-Generierung in 90 % der Fälle dabei hilft, musst du in manchen Fällen zusätzlich den optionalen c-Parameter angeben:
struct DocumentView: View {
let fileName: String
var body: some View {
Button(#tk("Delete '\(fileName)'?",
c: "Example: Delete 'MyStats.csv'?")) {
handleDelete()
}
}
}Dieser Kommentar-Parameter wird am häufigsten benötigt, wenn du dynamische Daten in deinem String hast, wie im obigen Beispiel. Es ist wichtig, immer typische Beispieldaten im Kommentar anzugeben, damit es klar wird. Sonst wissen Übersetzer möglicherweise nicht, wie sie korrekt übersetzen sollen.
Was kommt als Nächstes?
Dieser Artikel hat gezeigt, wie das TranslateKit SDK den grundlegenden Lokalisierungs-Workflow modernisiert. Wenn du dich für fortgeschrittenere Themen wie Pluralisierung, Formatter und mehr interessierst, abonniere meinen YouTube-Kanal, um dein Interesse an detaillierteren Videos zu signalisieren:
✨ TranslateKit SDK funktioniert perfekt zusammen mit TranslateKit for Mac, einem präzisen, KI-gestützten Übersetzungstool, um den Rest deiner App zu lokalisieren! Es ist superschnell und erschwinglich, probiere es kostenlos aus, um mehr Nutzer zu erreichen.