Tests multilingues de String Catalog : comment automatiser un Mac distant en 2026 ?

Un projet peut afficher un état de traduction complet tout en échouant dans une situation importante : une chaîne n’a pas été extraite, un texte allemand déborde d’un bouton d’achat, une date adopte le mauvais format régional ou une extension ne contient pas la ressource attendue. Ces défauts appartiennent à des niveaux différents et doivent être observés séparément.

Le socle de contrôle comporte quatre questions :

• la chaîne source a-t-elle été extraite vers le String Catalog ?
• la traduction, le pluriel et les variantes attendues sont-ils présents ?
• l’interface s’affiche-t-elle correctement avec la langue et la région sélectionnées ?
• le produit construit contient-il effectivement les ressources nécessaires ?

La documentation Apple sur la préparation du texte à traduire distingue précisément les chaînes provenant de SwiftUI, du code et des ressources d’interface. Cette distinction est déterminante pour les projets où une nouvelle vue SwiftUI cohabite avec des Storyboards, des fichiers XIB ou des ressources historiques.

Les trois preuves à conserver

L’état de l’éditeur constitue une première preuve, mais il ne représente pas le résultat complet. La seconde preuve est l’exécution dans la langue et la région choisies. La dernière est l’Archive construite pour la distribution.

Cette séparation évite une erreur fréquente : interpréter une indication verte dans le catalogue comme une garantie de publication. Une traduction peut être renseignée mais apparaître dans un mauvais contexte, tandis qu’une ressource peut être correcte dans l’interface de développement et manquer du Bundle final.

Le périmètre doit commencer par les parcours qui portent une conséquence commerciale ou fonctionnelle : connexion, achat, création de contenu, export audio ou vidéo, réglages essentiels et confirmation d’abonnement. Inclure immédiatement toutes les écrans rend la suite difficile à maintenir et masque les défauts prioritaires derrière une grande quantité de résultats secondaires.

SwiftUI et chaînes variables

Dans une application SwiftUI, la première vérification porte sur la manière dont les textes sont déclarés. Une chaîne affichée directement dans une vue peut être correctement extraite, tandis qu’une construction dynamique ou une abstraction interne peut nécessiter une vérification spécifique. Le document Apple consacré à l’extraction des chaînes doit servir de référence pour chaque forme utilisée dans le projet.

Le test minimal doit contenir une chaîne simple, une valeur interpolée, un pluriel et une variante liée à l’appareil ou au contexte d’affichage. Il ne s’agit pas de multiplier artificiellement les cas, mais de s’assurer que la chaîne traduite conserve son sens lorsque la valeur change.

Pour une interface créative, le parcours peut inclure le nom d’une piste audio, la durée d’un fichier vidéo, une action d’export ou une palette de modèles. Ces éléments révèlent souvent des défauts que les écrans administratifs ne montrent pas : libellé trop long, retour à la langue source, unité mal localisée ou bouton devenu ambigu après traduction.

La validation ne doit pas s’arrêter au catalogue. Une Preview peut accélérer l’inspection visuelle, mais le test automatisé doit exécuter la vue dans un environnement contrôlé, avec la langue et la région définies. Le résultat attendu doit préciser ce qui constitue un échec : texte absent, valeur non remplacée, chevauchement, retour imprévu à la langue par défaut ou action inaccessible.

UIKit, ressources anciennes et projets hybrides

Dans un projet UIKit ou hybride, le risque principal vient de la coexistence de plusieurs sources. String Catalog, fichiers strings, stringsdict, Storyboards, XIB et chaînes de Info.plist ne doivent pas être considérés comme un seul bloc lors de la migration.

Chaque Target doit être inspecté séparément : application principale, extension, framework ou module partagé. Une chaîne peut être correctement déclarée dans le projet tout en étant absente du Bundle qui l’utilise. La preuve utile se trouve donc dans le produit construit et dans l’écran réellement chargé, non dans la seule arborescence du projet.

La migration progressive est préférable lorsqu’un projet contient des ressources anciennes fiables. Un module peut être converti, testé, puis conservé avec une possibilité de retour arrière avant qu’un autre module ne soit touché. Une uniformisation immédiate augmente le risque de doublons, de clés modifiées et de régressions difficiles à attribuer.

Comment repérer les chaînes localisées qui manquent ?
Il faut comparer l’extraction produite par la construction avec la cartographie des écrans prioritaires, puis exécuter ces écrans dans la langue cible. Une différence entre le code, le catalogue et le Bundle indique un problème d’extraction ou d’appartenance à un Target. Le pourcentage de traduction ne peut pas révéler une chaîne qui n’a jamais été extraite.

Langue, région et format

Tester plusieurs langues ne revient pas à changer uniquement le texte. La région influe sur les dates, les nombres, les devises, les séparateurs, les unités et certains pluriels. La direction d’écriture doit également être incluse lorsqu’une langue prise en charge utilise une interface de droite à gauche.

Le guide Apple consacré aux tests de localisation décrit l’exécution avec des paramètres de langue et de région. Dans Xcode, ces paramètres doivent être séparés dans le Test Plan afin de savoir si un échec vient du texte traduit ou du format régional.

La matrice doit être construite à partir du marché réel, des fonctionnalités sensibles et des appareils visés. Il est rarement utile de combiner mécaniquement toutes les langues avec toutes les régions et toutes les tailles d’écran. Une sélection raisonnée couvre mieux les parcours critiques qu’un ensemble gigantesque impossible à maintenir.

Pour chaque combinaison retenue, consignez :

• la langue de l’application ;
• la région de l’environnement ;
• la direction d’écriture ;
• le format de date, d’heure et de nombre attendu ;
• la règle de pluriel utilisée ;
• la taille d’écran ou la classe d’interface pertinente ;
• le parcours à capturer et le résultat attendu.

Comment tester en série les langues et les régions d’une application iOS ?
Créez des configurations distinctes dans le Test Plan, avec un nom qui expose la langue et la région, puis associez chaque configuration aux tests nécessaires. La documentation Apple sur l’organisation des tests explique comment séparer les ensembles afin d’obtenir un retour exploitable. Une matrice plus petite mais reliée aux marchés réellement servis est préférable à une combinaison exhaustive sans critères d’arrêt.

Captures et preuves visuelles

Les captures localisées servent à vérifier l’interface et à faciliter la relecture des traductions. Elles ne doivent pas être confondues avec les visuels marketing de l’App Store. Une capture de test doit d’abord montrer que le parcours est fonctionnel dans un contexte identifié.

Le nom du fichier peut contenir la langue, la région, l’appareil logique et le scénario, sans inclure de données personnelles. Un écran d’achat, une exportation vidéo ou une timeline audio doit être capturé après une action déterministe, et non après une navigation manuelle difficile à reproduire.

Les instructions Apple pour créer des captures destinées aux localisateurs encadrent cette utilisation. Dans une chaîne automatisée, les captures doivent être conservées avec le résultat de test et le commit correspondant, afin qu’une modification de traduction puisse être comparée à une version antérieure.

Découpage des tâches

Un pipeline de tests multilingues de String Catalog devient plus lisible lorsqu’il sépare les opérations au lieu de lancer une commande unique qui échoue sans préciser la cause. Le découpage recommandé est le suivant :

• préparer l’environnement et sélectionner le Scheme ;
• construire ou exporter les ressources localisées ;
• exécuter les tests du Test Plan pour une langue et une région ;
• lancer les tests d’interface et produire les captures ;
• construire l’Archive et vérifier ses ressources ;
• conserver les journaux, le fichier xcresult, les captures et la décision finale.

Les commandes d’automatisation doivent rester alignées sur les capacités documentées de xcodebuild. Apple documente l’export des localisations et leur importation ; ces opérations ne remplacent pas les tests d’exécution, mais elles permettent de contrôler le flux entre le projet et les fichiers transmis à la traduction.

Le pipeline doit aussi distinguer les tâches compatibles avec une session distante non graphique de celles qui nécessitent un simulateur et une session graphique. Une connexion SSH peut lancer une construction et archiver les journaux, mais le test d’interface et la génération de captures dépendent de la disponibilité correcte du simulateur et de l’environnement utilisateur.

String Catalog peut-il être vérifié automatiquement dans une intégration continue ?
Oui, si le contrôle est défini comme une suite de vérifications distinctes : extraction, cohérence des ressources, exécution du Test Plan, tests d’interface et inspection de l’Archive. La réussite de la construction seule ne prouve ni la qualité de la traduction ni l’absence de texte tronqué. Le pipeline doit donc produire des preuves consultables et échouer sur les critères qui bloquent réellement la publication.

Exploitation du Mac distant

Un Mac distant est pertinent lorsque le projet doit conserver Xcode, les simulateurs, les résultats et les scripts entre deux exécutions, sans réserver un ordinateur local à cette seule fonction. Les détails d’accès et de continuité sont à documenter dans le cadre de la mise en place d’un environnement Mac distant pour les tests, notamment pour les accès SSH, la session graphique et la récupération des artefacts.

Le contrôle opérationnel doit inclure les situations suivantes :

• une coupure SSH pendant la construction ;
• un redémarrage de la machine avant les tests d’interface ;
• une nouvelle exécution après échec ;
• un espace de stockage insuffisant pour les résultats et les captures ;
• une session graphique indisponible pour le simulateur ;
• un résultat produit dans un répertoire temporaire non récupéré.

La règle de décision peut être formulée ainsi :

• Si le projet exige des tests de simulateur, des captures et une Archive régulière, choisissez un Mac distant conservé comme environnement de régression.
• Si le projet ne nécessite qu’une vérification ponctuelle d’extraction, commencez par une exécution locale ou une machine temporaire, puis évitez de maintenir une infrastructure permanente.
• Si les échecs doivent être reproduits avec une session graphique stable, choisissez un accès distant avec reprise documentée plutôt qu’un simple script SSH sans contrôle du bureau.
• Si l’Archive contient les ressources attendues mais que l’interface échoue dans une langue, bloquez la publication et corrigez le texte ou la mise en page.
• Si l’interface est correcte mais qu’une langue manque du Bundle, bloquez la distribution et corrigez l’appartenance de la ressource au Target.
• Si la panne vient uniquement du simulateur ou de la machine, classez l’incident comme défaillance d’infrastructure, relancez la tâche et conservez les journaux avant de modifier la traduction.

Une configuration de Mac distant pour Xcode et les simulateurs peut être envisagée lorsque le poste local ne peut pas rester disponible pour les tâches de CI. Le choix doit toutefois être lié au besoin de conservation des environnements et non à la seule possibilité d’ouvrir Xcode à distance.

La dernière phase doit partir du produit réellement construit. Vérifiez que les langues attendues sont présentes dans l’Archive, que l’application principale et ses extensions possèdent les ressources adéquates, puis exécutez le parcours critique dans les langues représentatives de la matrice.

Les défauts doivent être classés selon leur conséquence :

• Blocage de publication : langue absente, chaîne essentielle non traduite, achat inutilisable, mauvaise devise ou action principale inaccessible ;
• Correction obligatoire avant nouvelle validation : texte tronqué, pluriel incorrect, retour à la langue source ou capture incohérente ;
• Incident d’infrastructure : simulateur indisponible, session graphique interrompue, fichier xcresult non récupéré ou machine redémarrée ;
• Amélioration ultérieure : défaut visuel secondaire qui ne compromet ni la compréhension ni l’action principale.

Quels contrôles effectuer avant de publier une application multilingue ?
Contrôlez au minimum les chaînes nouvelles, les valeurs interpolées, les pluriels, les variantes d’appareil, les dates, les nombres, les devises, la direction d’écriture, les écrans essentiels, les extensions et les ressources de l’Archive. Ajoutez une preuve visuelle pour les parcours sensibles et conservez le résultat de test afin de distinguer une régression de traduction d’une panne du Mac distant.

La décision finale doit être explicite : poursuivre la publication, corriger puis relancer la matrice, ou rétablir la dernière modification de localisation validée. Cette décision, accompagnée des journaux et des captures, transforme une vérification ponctuelle en référence réutilisable pour la prochaine version.

Un poste local reste préférable lorsque le développeur travaille quotidiennement sur l’interface, dépend d’un périphérique physique ou doit inspecter un défaut graphique sans délai. Il évite aussi la dépendance à une connexion et simplifie certaines opérations manuelles.

Cependant, un poste local utilisé seul présente des limites réelles pour une équipe : il peut être éteint, occupé par une autre tâche, difficile à reproduire après une modification système et dépourvu d’un historique centralisé des résultats. La planification des tests, la conservation des captures et la reprise après interruption deviennent alors des opérations manuelles.

À l’inverse, un Mac distant réservé à la validation apporte une machine accessible pour les exécutions planifiées, un environnement persistant pour Xcode et les simulateurs, ainsi qu’une séparation claire entre développement quotidien et contrôle de publication. Il ne supprime pas les problèmes de permissions, de session graphique, de stockage des artefacts ou de version d’outil : ceux-ci doivent être testés avant de rendre le pipeline bloquant.

Si l’objectif est de conserver une machine de validation sans acheter un second Mac, la présentation des environnements Mac accessibles à distance permet d’examiner les modalités de disponibilité et de durée adaptées au projet. Pour une charge lourde et permanente, l’achat d’un Mac local peut rester plus rationnel ; pour des campagnes de tests, une migration ou une période de publication, la location évite d’immobiliser du capital dans une machine qui resterait inutilisée entre deux versions.

La différence pratique est nette : une solution locale dépend de la disponibilité d’un poste et d’une personne, tandis qu’une solution distante exige une vérification initiale de l’accès, de la session graphique et de la récupération des résultats. Dans les deux cas, la décision doit se prendre après la conception de la matrice, pas avant.

La méthode la plus fiable consiste donc à ne jamais traiter String Catalog comme un indicateur de traduction isolé. Les chaînes doivent être extraites, les langues et régions doivent être sélectionnées selon les marchés, les interfaces doivent être exécutées avec un Test Plan, les captures doivent servir de preuves et l’Archive doit confirmer que les ressources livrées correspondent bien au projet validé. Si le poste local ne peut pas conserver Xcode, les simulateurs et les résultats entre les campagnes, la location d’un Mac auprès de NUKCLOUD constitue une option plus adaptée qu’un poste Windows ou Linux incapable d’exécuter directement cette chaîne macOS ; elle reste toutefois à réserver aux besoins temporaires, aux validations de publication et aux environnements de CI, plutôt qu’à un usage nécessitant en permanence un périphérique physique.