Wenn es schnell gehen soll: Konvertieren Sie einzelne .strings-Dateien direkt im Browser in einen Katalog, kostenlos, ohne Anmeldung und ohne Upload.
Vor der Migration
Zwei Vorsichtsmaßnahmen, die die meisten bösen Überraschungen verhindern:
- Ein sauberer Git-Stand, auf einem eigenen Branch. Alles, was Sie danach prüfen sollten, steht im Diff, also sollte er nichts anderes enthalten.
- Ein Build, der vor der Migration durchläuft. Xcode füllt den Katalog, indem es beim Build Ihren Code durchsucht. Kompiliert das Projekt nicht, bleibt der Katalog unvollständig, und Sie wissen nicht, warum.
Die Migration selbst
Klicken Sie im Projektnavigator mit der rechten Maustaste auf Localizable.strings, dann auf Migrate to String Catalog. Xcode listet die betroffenen Dateien und Targets auf; der genaue Wortlaut kann sich zwischen Xcode-Versionen ändern, das Prinzip nicht.
Die Dateien fr.lproj/Localizable.strings, de.lproj/Localizable.strings… werden durch eine einzige Localizable.xcstrings ersetzt, die alle Sprachen enthält. Kommentare aus den .strings-Dateien werden zum Kommentar des jeweiligen Schlüssels.
So sieht die Datei aus
Ein String Catalog ist JSON. Ein einfacher Schlüssel:
{
"sourceLanguage" : "en",
"strings" : {
"welcome_user" : {
"comment" : "Home screen greeting",
"localizations" : {
"fr" : {
"stringUnit" : {
"state" : "translated",
"value" : "Bon retour, %@ !"
}
}
}
}
},
"version" : "1.0"
}Und eine Pluralform, gespeichert unter variations:
"items_left" : {
"localizations" : {
"fr" : {
"variations" : {
"plural" : {
"one" : { "stringUnit" : { "state" : "translated", "value" : "%lld article restant" } },
"other" : { "stringUnit" : { "state" : "translated", "value" : "%lld articles restants" } }
}
}
}
}
}Beachten Sie die Formatierung: ein Leerzeichen vor jedem Doppelpunkt, so wie Xcode schreibt. Ein Tool, das die Datei als „normales“ JSON neu schreibt, erzeugt einen riesigen Diff, ohne eine einzige Übersetzung zu ändern.
Was Sie im Diff prüfen sollten
Als Stale markierte Schlüssel. Nach einem Build markiert Xcode Schlüssel, die es in Ihrem Code nicht mehr findet. Sie sind nicht unbedingt tot: Ein zur Laufzeit erzeugter Schlüssel (NSLocalizedString(variable, comment: ""), ein aus einer Konfigurationsdatei gelesener Schlüssel) ist für den Scan unsichtbar. Prüfen Sie vor dem Löschen.
Neu aus dem Code extrahierte Schlüssel. Der Build kann Strings hinzufügen, die nie in Localizable.strings standen, typischerweise SwiftUI-Literale Text("…"), die standardmäßig lokalisierbar sind. Sie kommen unübersetzt an, daher sinkt erwartungsgemäß der Prozentsatz, den Xcode für jede Sprache anzeigt.
Status. Jeder Wert hat einen Status: translated, needs_review oder new für einen String, den noch niemand übersetzt hat. In drei Monaten wissen Sie daran, was tatsächlich geprüft wurde.
Formatbezeichner. Ein SwiftUI-String wie Text("\(count) items left") erzeugt den Schlüssel %lld items left. Hat Ihre alte .strings-Datei für denselben Satz %d verwendet, haben Sie jetzt zwei fast identische Schlüssel; behalten Sie den, den Ihr Code wirklich verwendet.
Und ältere iOS-Versionen?
iOS 17 ist nicht nötig. Der Katalog ist ein Quellformat: Beim Build kompiliert Xcode ihn in normale .strings-Dateien im App-Bundle. Ihr Deployment Target ändert sich nicht.
Den Katalog außerhalb von Xcode bearbeiten
Der Editor von Xcode reicht für eine Handvoll Strings. Um eine ganze Sprache zu prüfen, viele Strings auf einmal zu übersetzen oder Platzhalter zu kontrollieren, hilft ein spezialisiertes Tool. LocalePilot öffnet .xcstrings-Dateien und schreibt sie im Stil von Xcode zurück: Ein unveränderter Katalog bleibt byte-identisch, eine Bearbeitung ändert nur ihre eigenen Zeilen, und ein bearbeiteter Wert wechselt in den Status translated. Pluralformen und Gerätevarianten sind bearbeitbar; Schlüssel mit Substitutionen (%#@count@) und Schlüssel mit shouldTranslate: false bleiben unverändert erhalten und werden in Xcode bearbeitet.