String Catalog Mehrsprachentest: Remote Mac 2026 automatisieren?

Eine grüne Übersetzungsanzeige im Editor beweist nicht, dass die Anwendung korrekt läuft. Sie sagt zunächst nur, dass im String Catalog ein bestimmter Status hinterlegt ist. Für eine belastbare Freigabe müssen mindestens diese Nachweise getrennt vorliegen:

• Die erwarteten Zeichenfolgen wurden aus dem Quellcode und den relevanten Ressourcen extrahiert.
• Die Übersetzungs- und Varianteninformationen sind für die unterstützten Sprachen plausibel.
• Die App zeigt zur Laufzeit die richtige Sprache, Region, Formatierung und Schreibrichtung.
• Das finale Archive enthält die erwarteten Sprachressourcen.
• Die wichtigsten Nutzerpfade funktionieren auch bei längeren Texten, Pluralformen und variablen Werten.

Apple beschreibt den String Catalog als zentrale Verwaltung für Sprachen, Übersetzungen, Pluralformen und Gerätevarianten. Diese Funktionen dürfen jedoch nicht mit einer vollständigen Release-Abnahme gleichgesetzt werden. Die offizielle Dokumentation zu String Catalog trennt die Verwaltung der Inhalte von der Prüfung des tatsächlichen App-Verhaltens.

Der sinnvollste Startpunkt ist ein begrenzter kritischer Pfad: Anmeldung, Kauf, Kernfunktion oder Export. Werden sofort alle Ansichten und Sonderfälle aufgenommen, steigt der Wartungsaufwand schneller als der Prüfwert. Ein kleiner, stabiler Testumfang liefert zunächst verwertbare Fehler und kann später gezielt erweitert werden.

Drei Beweisarten statt einer Übersetzungsquote

Eine einfache Vollständigkeitsquote kann fehlende Einträge verdecken. Deshalb sollte die Pipeline drei Beweisarten speichern:

1. Extraktionsnachweis: Welche Schlüssel oder lokalisierbaren Texte wurden aus dem aktuellen Quellstand erzeugt?
2. Laufzeitnachweis: Wie sieht der kritische Pfad unter einer bestimmten Sprache und Region aus?
3. Artefaktnachweis: Welche Sprachverzeichnisse und Ressourcen befinden sich im erzeugten Archive?

Damit wird klar, ob ein Problem im Quellcode, im Übersetzungsbestand, in der UI oder erst beim Verpacken entsteht. Diese Trennung verhindert, dass ein scheinbar erfolgreicher Editorstatus eine fehlerhafte Veröffentlichung überdeckt.

Bei SwiftUI beginnt die Automatisierung mit der Frage, ob lokalisierbare Texte tatsächlich über die vorgesehenen APIs erkannt werden. Apple erläutert die Regeln für SwiftUI und andere Quellcodebereiche in der Dokumentation zur Vorbereitung von Text für die Übersetzung.

Ein Testprojekt sollte mindestens diese Fälle enthalten:

• Einen kurzen Standardtext.
• Einen Text mit einer variablen Einfügung.
• Eine Pluralform für unterschiedliche Mengen.
• Eine längere Übersetzung, die eine Schaltfläche oder eine Navigationszeile beansprucht.
• Eine Geräte- oder Layoutvariante, falls die App diese verwendet.

Die Prüfung darf nicht bei der Frage enden, ob ein Schlüssel im String Catalog vorhanden ist. Entscheidend ist, ob die API korrekt verwendet wird und ob die Laufzeit den erwarteten Wert einsetzt. Ein dynamisch zusammengesetzter String, der nicht lokalisierbar angelegt wurde, kann in der Oberfläche erscheinen, ohne im erwarteten Katalog aufzutauchen.

Wie lassen sich fehlende lokalisierte Zeichenfolgen in einem String Catalog erkennen?
Zuerst wird der Build beziehungsweise die Extraktion mit dem aktuellen Quellstand ausgeführt. Danach werden neue oder nicht erwartete Einträge gegen eine geprüfte Referenzliste abgeglichen. Für jeden kritischen Schlüssel sollte zusätzlich ein UI-Test existieren, weil ein vorhandener Eintrag keine korrekte Darstellung garantiert. Die Referenzliste muss dabei projektbezogen gepflegt werden; eine pauschale Prüfung aller Texte erzeugt in gewachsenen Projekten häufig falsche Alarme.

SwiftUI-Previews können bei der schnellen Sichtprüfung helfen, sollten aber nicht allein als CI/CD-Nachweis gelten. Für die Freigabe braucht es eine reproduzierbare laufende App mit festgelegter Sprache, Region und Gerätekonfiguration. So werden auch Textumbruch, Fallback-Sprache und unerwartete Layoutänderungen sichtbar.

Bei UIKit- oder Mischprojekten liegt die Schwierigkeit oft nicht im String Catalog selbst, sondern in mehreren parallelen Ressourcenquellen. strings, stringsdict, Storyboards, XIBs und lokalisierte Werte in Info.plist können weiterhin relevant sein. Eine Migration sollte deshalb nicht mit dem Ziel erfolgen, jedes ältere Format sofort zu ersetzen.

Sinnvoller ist eine modulare Zuordnung:

• Welche Texte stammen aus Swift- oder Objective-C-Code?
• Welche Werte werden aus Storyboards und XIBs geladen?
• Welche Pluralformen liegen noch in stringsdict?
• Welche Ressourcen gehören zum App-Target, zu einer Erweiterung oder zu einem Framework?
• Welche Dateien werden tatsächlich in das jeweilige Bundle kopiert?

Ein häufiger Fehler entsteht, wenn das App-Target geprüft wird, während eine Erweiterung oder ein Framework eigene lokalisierte Ressourcen besitzt. Die Quelle sieht korrekt aus, aber das finale Bundle enthält die Datei am falschen Ort oder gar nicht. Deshalb muss die Prüfung nach dem Build im erzeugten Bundle und anschließend in der laufenden Oberfläche erfolgen.

Für ein Bestandsprojekt ist ein Rückfallpfad wichtig. Ein Modul kann zuerst in den String Catalog überführt werden, während nicht migrierte Ressourcen unverändert bleiben. Erst wenn Extraktion, Laufzeit und Bundle-Inhalt übereinstimmen, wird der nächste Bereich umgestellt. Eine rein formale Vereinheitlichung erhöht das Risiko, wenn gleichzeitig Target-Grenzen, Storyboards und alte Pluraldefinitionen verändert werden.

Kann ein String Catalog in einer kontinuierlichen Integration automatisch geprüft werden?
Ja, aber nicht durch eine einzelne Statusabfrage. Die CI/CD-Pipeline sollte Extraktion, lokalisierte Laufzeittests und Artefaktprüfung als getrennte Aufgaben ausführen. Für den Export und Import lokalisierter Inhalte stellt Apple eigene Dokumentationen zum Exportieren von Lokalisierungen und zum Importieren von Lokalisierungen bereit. Die Pipeline muss trotzdem festlegen, welche Schlüssel kritisch sind und wann ein Fehler die Veröffentlichung blockiert.

Eine gute Sprachmatrix besteht nicht aus jeder technisch möglichen Kombination. Sie folgt den Märkten, den tatsächlich unterstützten Regionen, der Schreibrichtung, den Kernmodellen und den wichtigsten Geschäftsabläufen.

Für jede ausgewählte Kombination werden mindestens diese Eigenschaften festgelegt:

• Anwendungssprache.
• Anwendungsregion.
• Relevantes Gerät oder Simulatorprofil.
• Kritischer Nutzerpfad.
• Erwartete Datums-, Zahlen- und Währungsdarstellung.
• Erwartetes Verhalten bei langen Texten und Pluralformen.
• Erforderliche Screenshot- oder Testergebnisdatei.

Sprache und Region müssen getrennt betrachtet werden. Eine deutsche Spracheinstellung mit einer anderen Region kann andere Datums- oder Zahlenformate erzeugen. Bei Märkten mit Rechts-nach-links-Schrift kommen zusätzlich Navigation, Ausrichtung und Symbolpositionen hinzu. Ein erfolgreicher Test unter der Standardsprache deckt diese Fälle nicht ab.

Wie lassen sich die Sprachen und Regionen einer iOS-App gesammelt testen?
In Xcode werden im Test Plan getrennte Konfigurationen für Application Language und Application Region angelegt. Jede Konfiguration erhält nur die Kombinationen, die für das Produkt relevant sind. Die Apple-Dokumentation zum Testen von Lokalisierungen beschreibt die Laufzeitprüfung; die Anleitung zu Test Plans zeigt, wie Tests für besseres Feedback organisiert werden können.

Die Tests sollten nicht nur auf den Startbildschirm zugreifen. Ein belastbarer kritischer Pfad öffnet etwa einen Kaufdialog, ändert eine Menge, zeigt einen Fehlertext und navigiert zurück. Dadurch werden Pluralformen, variable Werte, längere Beschriftungen und Fallbacks in derselben Ausführung sichtbar.

Lokalisierte Screenshots als Beweismittel

Screenshots sind in diesem Verfahren vor allem Rückverfolgungs- und Review-Nachweise. Sie zeigen, unter welcher Sprache und Region ein Fehler auftrat. Sie sind nicht automatisch identisch mit den finalen Marketingbildern für den Store.

Jede Datei sollte deshalb eine maschinenlesbare oder zumindest eindeutige Zuordnung zu Sprache, Region, Testkonfiguration und Build besitzen. Die offizielle Anleitung für Screenshots lokalisierter Apps beschreibt den vorgesehenen Xcode-Workflow.

Ein Screenshot mit abgeschnittenem Kaufbutton ist ein UI-Fehler, auch wenn die Übersetzung im Katalog vollständig markiert wurde. Umgekehrt ist ein fehlender Screenshot nicht zwingend ein Lokalisierungsfehler, wenn der Simulator oder die grafische Sitzung während der Ausführung ausgefallen ist. Beide Fehlerklassen müssen getrennt erfasst werden.

Ein Remote Mac eignet sich besonders dann, wenn Xcode, Simulatoren und Ergebnisdateien dauerhaft verfügbar sein sollen, ohne dass ein lokaler Rechner ständig für die Abnahme eingeschaltet bleiben muss. Die Automatisierung sollte jedoch nicht als ein einziges langes Skript angelegt werden.

Eine robuste Ausführung besteht aus voneinander unterscheidbaren Aufgaben:

1. Quellstand und Konfiguration reproduzierbar bereitstellen.
2. Lokalisierte Inhalte exportieren oder die String-Catalog-Extraktion ausführen.
3. Sprach- und Regionskonfigurationen über den Test Plan starten.
4. UI-Testergebnisse, Screenshots und Logs archivieren.
5. Das finale Archive prüfen und die Entscheidung für die Veröffentlichung dokumentieren.

Für den Aufruf über SSH oder eine andere Fernsteuerung ist entscheidend, welche Aufgabe eine grafische Sitzung benötigt. Reine Extraktion und manche Build-Schritte lassen sich ohne sichtbare Oberfläche ausführen. Simulatorbasierte UI-Tests und Screenshot-Erzeugung benötigen dagegen eine funktionierende macOS-Grafiksitzung. Diese Abhängigkeit gehört in die Pipeline-Dokumentation, statt erst nach einem nächtlichen Fehlschlag untersucht zu werden.

xcodebuild kann in diesem Ablauf als reproduzierbarer Einstieg dienen. Für jede Aufgabe sollten die verwendeten Scheme-, Test-Plan- und Exportoptionen feststehen. Die Ergebnisse werden als xcresult und ergänzende Artefakte aufbewahrt, damit ein späterer Vergleich nicht von einer manuellen Xcode-Sitzung abhängt.

Wie führt ein Remote Mac mehrsprachige UI-Tests und Screenshots aus?
Der Remote Mac startet zuerst die festgelegte grafische Sitzung, danach wird der Test Plan mit den vorgesehenen Sprach- und Regionskombinationen ausgeführt. Die Pipeline speichert pro Konfiguration Testergebnis, Screenshot und Protokoll. Nach einem Neustart oder einer unterbrochenen SSH-Verbindung muss derselbe Auftrag erneut gestartet werden können, ohne alte Ergebnisse mit dem neuen Lauf zu vermischen.

Für den Betrieb sollte ein Wiederholungstest eingeplant werden. Dabei werden Host-Neustart, abgebrochene Sitzung, fehlende Simulatorverfügbarkeit und ein erneuter Lauf geprüft. Erst wenn die Pipeline nach diesen Störungen eindeutig fehlschlägt oder sauber fortgesetzt werden kann, sollte sie als Pull-Request-Prüfung, zeitgesteuerter Lauf oder Release-Gate verwendet werden.

Wer eine solche Umgebung nicht auf eigener Hardware dauerhaft vorhalten kann, kann die Remote-Mac-Optionen von NUKCLOUD als mögliche Betriebsform prüfen. Der entscheidende Vergleichspunkt ist nicht nur die Erreichbarkeit, sondern ob Xcode-Projekt, Simulator, Test Plan und Ergebnisarchiv nach einer Unterbrechung reproduzierbar verfügbar sind.

Vor der Veröffentlichung wird ein repräsentativer Build als fertiges Archive geprüft. Dabei zählen nicht nur die Dateien im String Catalog, sondern die Ressourcen im tatsächlichen Bundle. Für jede unterstützte Zielgruppe wird ein kritischer Nutzerpfad ausgeführt und das Ergebnis mit der vorher festgelegten Sprach- und Regionsmatrix abgeglichen.

Die Abnahmeliste kann so aussehen:

• [ ] Die erwarteten lokalisierbaren Texte wurden aus dem aktuellen Quellstand erkannt.
• [ ] Kritische Schlüssel besitzen Übersetzungen oder eine bewusst dokumentierte Fallback-Entscheidung.
• [ ] Pluralformen und variable Einfügungen zeigen grammatikalisch und technisch plausible Ergebnisse.
• [ ] Lange Beschriftungen werden nicht abgeschnitten oder unlesbar überlagert.
• [ ] Datum, Zahl und Währung entsprechen der getesteten Region.
• [ ] Rechts-nach-links-Oberflächen wurden dort geprüft, wo sie angeboten werden.
• [ ] App, Erweiterungen und Frameworks enthalten die jeweils benötigten Ressourcen.
• [ ] Die Sprachverzeichnisse sind im finalen Archive vorhanden.
• [ ] xcresult, Logs und lokalisierte Screenshots lassen sich dem Build zuordnen.
• [ ] Ein Fehler der Testinfrastruktur wird nicht als erfolgreicher Lokalisierungstest gewertet.

Für die Entscheidung gelten klare Rückgaben:

• Weiter veröffentlichen, wenn Ressourcen, Laufzeitoberfläche und Artefakte übereinstimmen.
• Nach Fehlerkorrektur erneut ausführen, wenn Übersetzung, Formatierung oder Layout fehlerhaft sind.
• Lokalisierungsänderung zurücknehmen, wenn eine Migration Ressourcen aus dem Bundle entfernt oder ein kritischer Pfad nicht mehr reproduzierbar ist.
• Infrastruktur separat beheben, wenn die App-Prüfung wegen Simulator, Sitzung oder Remote-Verbindung nicht abgeschlossen wurde.

Eine lokalisierte App darf erst dann als fertig gelten, wenn diese Fehlerarten voneinander getrennt sind. Andernfalls kann eine grüne Übersetzungsprüfung neben einer tatsächlich unbrauchbaren Kauf- oder Anmeldeseite stehen.

Die passende Umgebung hängt davon ab, ob der Bedarf punktuell oder dauerhaft ist:

• Wenn bereits ein lokal verfügbarer Mac mit ausreichend freiem Speicher und einer stabilen grafischen Sitzung vorhanden ist, dann kann die lokale Ausführung für kleine Matrizen genügen.
• Wenn mehrere tägliche Builds, wiederholte Simulatorläufe und archivierte xcresult-Dateien erforderlich sind, dann ist eine dauerhaft erreichbare Mac-Umgebung sinnvoller.
• Wenn nur Übersetzungsexporte geprüft werden und keine UI-Tests oder Screenshots notwendig sind, dann kann die Pipeline ohne dauernde Simulator-Sitzung schlanker aufgebaut werden.
• Wenn die Abnahme von UI, Sprache, Region und Archive gemeinsam erfolgen soll, dann sollte die Ausführung auf einem Mac mit verlässlich wiederherstellbarer grafischer Sitzung geplant werden.
• Wenn physische Geräte, lokale Spezialhardware oder dauerhaft hohe Build-Lasten zwingend erforderlich sind, dann sollte vor einer Miete geprüft werden, ob eine eigene Hardwarelösung besser passt.

Windows oder Linux bleiben für viele Quellcode- und Backend-Aufgaben nützlich, lösen aber nicht den Bedarf an Xcode, macOS-Simulator, Apple-Signierung und dem vollständigen Archive-Prozess. Eine unklare Cloud-Umgebung kann zusätzlich daran scheitern, dass grafische Sitzungen, Testresultate oder lokale Ressourcen nach einer Unterbrechung nicht zuverlässig erhalten bleiben. Ein eigener Mac vermeidet diese Abhängigkeit, bindet aber Kapital, Wartung und einen dauerhaft belegten Arbeitsplatz.

Wenn lokale Hardware nicht ständig verfügbar sein muss, bietet die Miete eines Remote Mac einen sachlichen Mittelweg: Xcode und die Simulatorumgebung bleiben für wiederkehrende Tests erreichbar, während der Entwicklungsrechner frei von der dauerhaften Abnahmeaufgabe bleibt. Für die Auswahl einer passenden Region und Laufzeit kann der Entwickler die verfügbaren NUKCLOUD-Bestelloptionen anhand von Erreichbarkeit, Sitzungsanforderungen und geplanter Testfrequenz prüfen. Entscheidend ist, dass die Umgebung nicht nur einen Build startet, sondern nach Fehlern, Neustarts und erneuten Testläufen verwertbare Lokalisierungsbelege erzeugt.