Pour auditer toutes les clés de localisation d’une app Mac, compilez les cibles concernées, vérifiez chaque table de chaînes pour toutes les langues prises en charge, puis testez les variantes de messages dans l’app en cours d’exécution. L’exhaustivité du catalogue et l’affichage correct à l’exécution nécessitent des vérifications distinctes.

Ce processus s’adresse aux développeurs qui gèrent une app Mac de bureau dans Xcode. Son objectif concret est de produire un relevé traçable des messages manquants, des traductions inachevées, des arguments incorrects et des problèmes d’affichage. Les exemples utilisent des libellés et des nombres fictifs ; ils décrivent une méthode d’audit que vous pouvez appliquer à votre propre projet.

Définir les critères d’un message complet

Commencez par créer une petite fiche d’audit. Notez la cible de l’app, le bundle de ressources, la table de chaînes, la clé, la localisation prise en charge, les variantes requises, l’état de la traduction et le résultat à l’exécution. Traitez chaque combinaison bundle–table–clé comme une identité de message distincte, afin qu’un texte de clé identique dans différentes ressources ne masque pas une omission.

Apple indique que les API localisables peuvent spécifier une table et un bundle, et que les ressources hors du bundle principal nécessitent le bundle approprié pour leur recherche. Vérifier uniquement le fichier Localizable.xcstrings par défaut peut donc faire manquer des messages ailleurs dans l’app. Consultez Préparer le texte de votre app pour la traduction.

Consultez les localisations prises en charge par le projet dans l’éditeur de projet : sélectionnez le projet sous Project, ouvrez Info et examinez Localizations. Vérifiez également quelles ressources sont associées à ces localisations. La documentation Apple Ajouter la prise en charge des langues et des régions explique ces réglages de projet et la sélection des ressources.

Pour la fiche, vous pouvez utiliser des alias fictifs tels que Localisation A, Localisation B et Localisation C. Conservez leur correspondance avec les identifiants de localisation réels du projet dans votre relevé de travail. Ces alias sont des libellés pour la fiche, et non des valeurs à saisir dans Xcode.

Utilisez les critères suivants pour déterminer si l’audit est complet. Il s’agit d’une méthode de vérification proposée, et non d’un état d’achèvement défini par Apple.

Vérification Éléments à consigner
Inventaire Le message est associé à une cible, un bundle, une table et une clé identifiés.
Découverte Le message est extrait du code ou maintenu délibérément à la main.
Couverture Chaque localisation requise possède les variantes de message nécessaires.
Arguments Chaque argument conserve le sens qui lui est destiné et un type compatible.
Exécution Le message et les valeurs corrects apparaissent dans l’interface Mac concernée.
Décision Chaque problème relevé est corrigé, délibérément exclu avec une justification ou encore ouvert.

Constituer l’inventaire du catalogue avant d’examiner les traductions

Ouvrez les catalogues de chaînes existants du projet. Si une cible n’a pas de catalogue, la procédure de création documentée par Apple est la suivante : File > New > File from Template, puis sélectionnez String Catalog. Le nom par défaut est Localizable ; utilisez le nom de table attendu par votre code. Choisissez Product > Build pour renseigner et mettre à jour le catalogue. Consultez Localiser et faire varier le texte avec un catalogue de chaînes.

Compilez chaque schéma Mac concerné au lieu de considérer qu’une seule compilation réussie constitue l’inventaire complet. Apple explique que l’extraction découvre les chaînes du schéma et de la plateforme en cours. Un message absent d’une compilation mérite une enquête avant de conclure qu’il est inutilisé. Cette limite est décrite dans Découvrir les catalogues de chaînes.

Vérifiez le réglage de compilation Use Compiler to Extract Swift Strings. Apple exige explicitement qu’il soit activé pour inclure tout le texte Swift localisable dans les exportations de localisation. Si vous avez besoin d’une copie d’échange pour le travail de traduction, sélectionnez le projet, choisissez Product > Export Localizations, puis sélectionnez les localisations requises. Le paquet .xcloc exporté est un catalogue de localisation Xcode, distinct d’une table de chaînes .xcstrings individuelle. Consultez Exporter des localisations.

Ensuite, parcourez les surfaces ordinaires de l’app de bureau : sa fenêtre principale, les menus, la barre d’outils, les réglages, les panneaux, les états vides et les libellés dont le contenu dépend d’un décompte. Pour chaque message appartenant à l’app que vous rencontrez, repérez l’entrée correspondante dans la fiche. Cette vérification inverse — de l’interface visible à l’inventaire — aide à repérer les textes qui ne sont jamais entrés dans un catalogue.

Ne partez pas du principe que l’extraction découvre toutes les expressions de chaîne arbitraires. Apple décrit l’extraction au moyen d’API localisables. Lorsqu’un message attendu est absent, examinez comment le code le crée et le transmet avant d’ajouter une deuxième entrée manuellement. Consultez Préparer le texte de votre app pour la traduction.

Distinguer extraction, recherche et formatage à l’exécution

Ces opérations répondent à des questions différentes. L’extraction détermine si Xcode peut découvrir un message pendant le développement. La recherche détermine quelle ressource localisée l’app en cours d’exécution demande. Le formatage à l’exécution fournit le contenu variable affiché par le message sélectionné.

Avec SwiftUI, le type des arguments est important. Un littéral tel que Text("Open collection") participe à la recherche localisée. En revanche, transmettre une variable de type String à l’initialiseur correspondant affiche normalement cette variable sans la localiser. Apple documente cette distinction dans LocalizedStringKey.

Créer explicitement une LocalizedStringKey à partir d’une variable demande une recherche, mais cela ne garantit pas que l’extraction au moment de la compilation ait découvert toutes les valeurs possibles de la variable. Pour les clés sélectionnées de manière dynamique, comparez l’ensemble complet des clés autorisées au catalogue. Examinez chaque valeur sans correspondance au lieu de vous fier à la valeur apparue lors d’un test.

L’interpolation joue également un rôle dans le message. SwiftUI peut rechercher un message localisé contenant un spécificateur de format et substituer la valeur interpolée avant le rendu. Dans la documentation de Text, Apple recommande l’interpolation pour composer du texte localisable.

Prenons un message illustratif qui indique le nombre d’éléments. Le catalogue stocke la structure du message localisable et ses variantes ; le nombre qui change relève du comportement à l’exécution. Tester les nombres 1 et 24 ne devrait pas nécessiter deux clés gérées indépendamment simplement parce que le nombre change.

Un libellé qui semble plausible ne prouve guère que la recherche a réussi. Apple indique que SwiftUI peut afficher la clé elle-même lorsqu’il ne trouve pas la valeur localisée. Si une clé est un texte lisible dans le code source, un problème de recherche peut ressembler à un libellé ordinaire. Vérifiez la localisation sélectionnée et l’entrée du catalogue en plus du résultat affiché. Consultez Préparer les vues à la localisation.

Examiner chaque langue et chaque variante requise

Procédez table par table et localisation par localisation. Pour chaque message, vérifiez son état de traduction, son texte, ses arguments et ses variantes développées. Laissez ouvertes les lignes inachevées même si les messages voisins sont complets.

Le processus des catalogues d’Apple distingue les entrées New, Needs Review, les entrées traduites et les chaînes Stale. Une entrée obsolète correspond à une chaîne qui n’a plus été trouvée dans le code ; les entrées gérées manuellement ne sont pas automatiquement mises à jour ni supprimées lors de la synchronisation. Confirmez qu’une clé obsolète est inutile avant de supprimer ses traductions. Consultez Découvrir les catalogues de chaînes.

Pour les messages dont le contenu dépend d’un décompte, faites un Contrôle-clic sur la clé interpolée, puis choisissez Vary by Plural. Examinez toutes les formes fournies par Xcode pour chaque localisation. Les formes requises peuvent varier ; vérifier que le nombre de lignes correspond à celui de la localisation source ne suffit donc pas. Si le catalogue comprend des variantes par appareil, examinez la valeur propre au Mac et la valeur générale. Apple documente ces deux commandes dans Localiser et faire varier le texte avec un catalogue de chaînes.

Vérifiez les arguments en fonction de leur sens, ainsi que de leur apparence. Pour un message fictif indiquant le nombre d’éléments répartis en groupes, déterminez quel argument représente le nombre d’éléments et lequel représente le nombre de groupes. Une traduction peut les placer différemment tout en devant préserver leur sens. La session d’Apple sur les catalogues explique les positions des arguments, les spécificateurs de type et les substitutions plurielles dans Découvrir les catalogues de chaînes.

Ajoutez du contexte lorsqu’un libellé court est ambigu. Un commentaire associé à Open pourrait préciser qu’il s’agit de l’action appliquée à une ligne de collection. Le paramètre comment de SwiftUI transmet ce contexte au résultat de localisation ; Apple le décrit dans Préparer les vues à la localisation.

Utiliser une matrice de couverture qui fait ressortir le travail inachevé

Un pourcentage unique permet de suivre l’avancement du catalogue, mais l’audit nécessite des colonnes distinctes pour la couverture et le comportement. L’exemple ci-dessous illustre pourquoi. Ses chiffres sont fictifs et représentent des paires message–localisation, et non des mesures provenant d’une app.

Supposons que l’inventaire contienne 48 messages requis et trois localisations prises en charge. Cela donne 144 paires requises : 48 multiplié par 3. Chaque paire peut comporter d’autres variantes plurielles ou par appareil, qui nécessitent leurs propres vérifications.

Localisation Paires requises Vérifications du catalogue terminées Vérifications à l’exécution terminées
Localisation A 48 48 48
Localisation B 48 46 44
Localisation C 48 48 45
Total 144 142 137

Dans cet exemple, deux paires nécessitent encore des interventions dans le catalogue et sept n’ont pas encore fait l’objet de toutes les vérifications à l’exécution. Ces groupes peuvent se recouper ; les additionner ne donnerait donc pas un décompte fiable des messages distincts encore inachevés. Conservez les deux constats dans leurs lignes respectives.

Pour chaque ligne inachevée, consignez une prochaine action précise : retrouver un message source manquant, compléter une variante plurielle, vérifier un argument, examiner la sélection du bundle ou revoir l’interface à une largeur plus réduite. La matrice devient ainsi une liste de corrections à effectuer plutôt qu’un rapport d’avancement décoratif.

Exécuter l’app Mac dans chaque localisation prise en charge

Utilisez les réglages de schéma de Xcode pour effectuer des vérifications reproductibles au niveau de l’app. Choisissez Product > Scheme > Edit Scheme, sélectionnez Run, ouvrez Options, puis choisissez App Language et App Region. Fermez la boîte de dialogue, sélectionnez la destination d’exécution Mac et lancez l’app. Répétez l’opération pour les combinaisons prises en charge dans votre audit. Apple documente cette procédure dans Tester les localisations lors de l’exécution de votre app.

Suivez le même parcours dans l’interface à chaque exécution. Testez chaque message dans les états pertinents : une collection vide, un élément, plusieurs éléments et des libellés fictifs plus longs. Pour les messages pluriels, choisissez des valeurs supplémentaires permettant d’exercer les variantes présentes dans cette localisation ; un petit ensemble fixe de nombres ne garantit pas une couverture complète des variantes.

Examinez les phrases complètes, les valeurs substituées, le retour à la ligne, la troncature ainsi que la largeur des menus et des commandes. Lorsqu’un message comporte deux nombres, faites-les varier indépendamment. Par exemple, modifier le nombre d’éléments tout en maintenant le nombre de groupes constant aide à repérer une erreur de correspondance des arguments.

Les aperçus SwiftUI peuvent accélérer la boucle de correction. Apple permet de définir la valeur d’environnement locale de l’aperçu et de créer plusieurs aperçus localisés après avoir ajouté ou importé ces localisations. Utilisez-les pour examiner de nouveau une vue problématique, puis vérifiez le parcours dans l’app réelle. Consultez Prévisualiser les localisations.

Terminez l’audit lorsque chaque paire message–localisation requise fait l’objet d’une décision consignée et que ses variantes nécessaires ont été vérifiées. Conservez ensemble l’inventaire, le parcours de test et les problèmes non résolus. Ce relevé rendra le prochain audit exploitable : un message modifié aura un emplacement connu, des arguments attendus, des variantes requises et une méthode reproductible pour en vérifier l’affichage.

Sources