2026-05-07 Catalogue de chaînes iOS (xcstrings) — barrières CI localisation sur Mac cloud Apple Silicon loué (HK / JP / KR / SG / US)

La dérive des chaînes tue silencieusement les soumissions App Store : captures nettes en anglais, mais troncatures, pluriels manquants ou variantes stale visibles seulement quand la QA change la langue système sans tenir l’appareil. Les Xcode String Catalogs (.xcstrings) centralisent tout, mais louer un Mac mini M4 à HK/JP/KR/SG/US exige encore un contrat CI : valider chaque PR, exporter des XLIFF pour les traducteurs, importer avec détection de conflit, et au moins un passage UI automatisé par locale critique métier. Ce guide 2026-05-07 assemble le détail opérationnel absent des notes de version—garder xcodebuild rapide avec 12+ locales, s’aligner sur les limites de lanes parallèles, éviter un DerivedData qui gonfle quand les assets se régénèrent via isolation TMPDIR/xcresult. Si la résolution de dépendances partage l’hôte, croisez ce runbook avec l’hygiène du cache SwiftPM pour ne pas rivaliser sur la même profondeur de file NVMe en semaine de release.

Pourquoi la localisation casse en dernier

Les tests fonctionnels passent en anglais ; le marketing valide des decks qui ne touchent pas le dépôt ; les ZIP pour les traducteurs sont périmés au retour. Les catalogs ne réparent pas le processus—ils donnent un artefact unique à diff dans Git. Le job CI : rendre les clés manquantes, pluriels invalides ou placeholders illégaux aussi bruyants qu’une erreur de compilation.

xcstrings vs .strings / stringsdict épars

Les anciennes dispositions éparpillent les traductions ; les relecteurs ratent les suppressions. .xcstrings regroupe métadonnées, états et variantes, simplifiant l’automatisation mais élargissant les conflits de merge. Pendant la migration, maintenez une matrice de compatibilité listant les cibles encore legacy. Supprimez vite les doubles sources.

Garde-fous dans GitHub/GitLab

• Validation syntaxique — même DEVELOPER_DIR que la release.
• Couverture des clés — échec si NEW_KEY n’a pas l’état translated pour les locales tier-1.
• Parité des placeholders — rejeter %@, %d ou positions divergentes.
• Lint captures — optionnel, mais avec tests screenshot, exécutez une locale non anglaise la nuit.

Runbook import/export pour builders headless

SSH uniquement : privilégiez des commandes reproductibles aux clics GUI.

xcodebuild -exportLocalizations -project YourApp.xcodeproj -localizationPath ./exports xcodebuild -importLocalizations -project YourApp.xcodeproj -localizationPath ./imports

Gardez les exports sur le même volume NVMe que export IPA & uploads ASC pour des permissions et umask cohérents. Toujours avec l’utilisateur CI dédié, jamais root.

Hygiène du va-et-vient XLIFF

Les traducteurs ont besoin d’IDs stables ; les ingénieurs d’imports déterministes. Versionnez les XLIFF ou placez-les dans un stockage objet avec tags de checksum. Rejetez les imports qui modifient des clés absentes du catalog de base ou qui retirent les champs note. Encodez les règles multi-régions (zh-Hans vs zh-Hant) en YAML pour éviter les suppositions CI.

Pluriels, appareils et variantes de largeur

Les apps modernes exigent des largeurs spécifiques pour complications Apple Watch, captures Dynamic Type et raccourcis. Les catalogs supportent les variantes si votre matrice QA les liste. Documentez obligatoire vs best effort et reflétez-le dans les seuils CI.

Matrice locale parallèle sans faire fondre l’hôte

Chaque locale multiplie le travail asset dans XCTest. Limitez les destinations concurrentes comme pour les jobs xcodebuild parallèles. Préférez le sharding : voie A Asie de l’Est, B Europe, C fumée RTL. Si le p95 dépasse 25 % sur un trimestre, ajoutez un second nœud loué près des traducteurs.

Disque, DerivedData et caches de localisation

Imports/exports touchent des milliers de petits fichiers—charge idéale pour saturer les métadonnées APFS. Gardez au moins 18 % libres avant un export complet ; archivez les anciens XLIFF vers du froid. Suivez TMPDIR + isolation xcresult pour ne pas effacer les artefacts d’un autre pipeline.

Objectifs chiffrés internes

• 100 % couverture tier-1 avant tag RC.
• 0 clé stale non résolue depuis plus de 14 jours.
• < 12 minutes pour la validation incrémentale typique.

Check-list en neuf étapes avant gel des chaînes

1. Geler le copy produit ; notifier les vendeurs avec le SHA.
2. Exporter le XLIFF de base depuis la branche release.
3. Valider le catalog avec le même Xcode que l’App Store.
4. Importer les fichiers vendeur dans une branche jetable ; diff des états JSON.
5. Smoke UI sur trois locales : LTR, RTL, CJK.
6. Vérifier les métadonnées App Store si synchronisées.
7. Snapshot du -sh pour suivre la régression NVMe.
8. Taguer le merge ; attacher le manifeste checksum pour conformité.
9. Planifier l’audit post-release des entrées needs_review.

FAQ : revue App Store, utilisateurs CI, pods hybrides

Question	Réponse pratique (2026-05-07)
Repos CocoaPods + SPM hybrides ?	Oui—localisez après résolution des dépendances pour que les bundles générés existent ; voir SwiftPM vs CocoaPods.
Ignorer UI tests pour une typo ?	Seulement si changement whitespace et bot politique le prouve—sinon au moins un smoke non anglais.

Pourquoi Mac mini M4 1–2 TB pour une CI riche en localisation

Les pipelines sont aléatoires en métadonnées : des milliers de petits fichiers martèlent le même contrôleur NVMe que xcodebuild test. Les nœuds Mac mini M4 MacXCode gardent une latence prévisible. Capacité : tarifs régionaux ; onboarding : aide.