Vos textes restent dans le code et votre écran de cours ne change pas de langue au lancement ?
Pour une app iOS 27 bilingue chinois-anglais, commencez par un String Catalog dans Xcode, puis testez séparément les deux langues, les textes longs et les contenus dynamiques.

Ce guide s’adresse aux étudiants qui créent leur premier écran SwiftUI et veulent ajouter le chinois et l’anglais sans traduire tout le projet d’un coup.
Il aide aussi les débutants dont les textes sont dispersés dans le code et les membres d’un groupe qui doivent remettre une version vérifiable.
Pour construire et exécuter le projet, prévoyez un Mac utilisable avec une version de Xcode adaptée à votre environnement.

Dernière vérification : 26 septembre 2026. Les indications sur String Catalog et les tests s’appuient sur la documentation de localisation d’Apple et sur ses notes de version Xcode 27.2. La mention d’une version bêta dans des notes de publication ne garantit pas que les mêmes fonctions ou menus soient disponibles dans chaque version stable : vérifiez la version installée avant de suivre une procédure affichée à l’écran.

iOS 27 : organiser le chinois et l’anglais dans String Catalog

Un String Catalog est un fichier de projet qui rassemble les textes destinés à l’interface et leurs traductions. Pour un devoir, vous pouvez commencer par les titres, boutons et messages de l’écran que vous présentez, au lieu de traduire toutes les images et ressources du projet. Apple décrit la gestion de ces chaînes et l’ajout de langues dans son guide consacré aux String Catalogs.

Cette méthode évite de transformer chaque phrase en deux versions écrites à la main dans une vue SwiftUI. Vous gardez le code responsable de l’affichage, tandis que le catalogue contient les variantes linguistiques. Cela facilite la relecture par une autre personne et limite les modifications accidentelles lorsque vous corrigez une traduction.

Votre situation Approche conseillée Point à contrôler
Vous créez votre premier écran Commencez par les chaînes visibles de cet écran et utilisez un String Catalog Les textes apparaissent dans le catalogue et peuvent recevoir leurs traductions
Les textes sont déjà dans le code Repérez les chaînes destinées à l’utilisateur, puis adoptez une écriture localisable Ne transformez pas les noms de variables ou les données en texte traduit
Une phrase contient une valeur variable Gardez la phrase et sa valeur dans une forme localisable adaptée Vérifiez le résultat dans chaque langue et avec plusieurs valeurs

La documentation Apple sur les langues prises en charge par une app présente les principes de configuration. Les libellés exacts de l’interface Xcode peuvent varier selon la version : retenez la tâche à effectuer, plutôt qu’un chemin de menu recopié sans vérifier votre écran.

Si vous débutez avec SwiftUI

Dans une vue SwiftUI, les textes affichés aux utilisateurs sont généralement décrits par des éléments comme Text ou par les libellés d’un bouton. Xcode peut extraire des chaînes éligibles pour les gérer dans un String Catalog. Commencez par un petit écran représentatif, par exemple une page de cours avec un titre, une courte description et un bouton d’action.

L’extraction ne signifie pas que chaque texte du projet sera automatiquement traduit, ni que toutes les chaînes présentes dans le code sont des éléments d’interface. Apple précise le fonctionnement et les limites dans ses explications sur la préparation des textes d’une app pour la traduction. Après l’extraction, ouvrez le catalogue, vérifiez les entrées proposées et complétez les variantes manquantes.

Si votre app affiche déjà des textes en dur

Un texte « en dur » est une phrase écrite directement dans le code, au lieu d’être référencée depuis une ressource localisable. Faites d’abord un inventaire en parcourant les écrans que le correcteur verra : en-têtes, boutons, messages d’erreur et libellés de champs. Remplacez progressivement les chaînes visibles par des formes que Xcode et SwiftUI peuvent traiter pour la localisation.

Ne traduisez pas pour autant tout ce qui ressemble à du texte. Une variable comme courseTitle décrit le code, pas nécessairement un libellé d’écran. Les données de cours peuvent nécessiter une traduction si elles sont présentées aux utilisateurs, mais elles doivent rester distinguées des messages de l’interface. Les traces de débogage ne sont pas des textes à localiser, sauf si elles sont aussi affichées dans une fonction visible de l’app.

Distinguer le texte d’interface des données du projet

La confusion entre « ce que voit l’utilisateur » et « ce que contient le code » produit souvent un catalogue incomplet ou encombré. Passez chaque chaîne au crible avec une question simple : cette valeur fait-elle partie de l’interface montrée dans l’app, ou sert-elle seulement au fonctionnement interne ?

  • À localiser : titres, boutons, consignes, messages de validation et erreurs visibles.
  • À examiner au cas par cas : noms de cours, descriptions ou contenu saisi par l’équipe, selon qu’ils sont présentés à l’utilisateur et qu’une traduction est prévue.
  • À ne pas traduire automatiquement : noms de variables, identifiants internes et informations de débogage qui ne figurent pas dans l’interface.

Cette séparation a un effet pratique pour un projet de groupe : la personne chargée de la traduction reçoit des chaînes compréhensibles, tandis que l’équipe de développement conserve ses noms et sa logique sans les modifier pour des raisons linguistiques. Pour les éléments à traduire, donnez aussi du contexte. Un mot isolé peut avoir plusieurs sens ; une note indiquant qu’il s’agit d’un bouton ou d’un titre aide à choisir la bonne formulation.

Gérer les valeurs dynamiques sans assembler des bouts de phrase

Les textes qui varient selon une valeur demandent davantage d’attention qu’un titre fixe. Pensez à un message qui annonce le nombre de leçons restantes ou reprend le nom d’un cours. Évitez de construire une phrase en assemblant des fragments traduits séparément : l’ordre naturel des mots peut changer d’une langue à l’autre, et certaines formes dépendent de la valeur affichée.

Privilégiez une entrée localisable cohérente, avec la valeur dynamique intégrée selon les mécanismes pris en charge par SwiftUI et Xcode. Les variations liées aux nombres doivent être traitées par les ressources et les formats localisés prévus pour cet usage, plutôt que par une série de concaténations improvisées. La documentation Apple sur les String Catalogs et la préparation des textes explique les comportements à vérifier ; ne déduisez pas qu’une chaîne est correctement localisée simplement parce qu’elle apparaît dans le fichier.

Pour un exercice de cours, testez au minimum les cas qui changent réellement le contenu : une valeur absente, une valeur courte et une valeur plus longue si votre logique le permet. Examinez aussi les deux langues. Une phrase qui semble acceptable dans une langue peut devenir trop longue ou sembler maladroite dans l’autre.

Préparer une traduction et remettre le travail à un groupe

Si une autre personne relit les textes, ne lui envoyez pas une liste de chaînes sans contexte. Ajoutez pour chaque entrée une description de son rôle, l’écran où elle apparaît et, pour une valeur dynamique, ce qui peut être inséré. Vérifiez ensuite que le fichier exporté correspond bien aux langues et au contenu que vous souhaitez faire relire.

Xcode prévoit un parcours d’exportation des localisations, décrit dans la documentation officielle sur l’export de localisations. Après le retour des traductions, réimportez-les et contrôlez le catalogue dans le projet. Un texte obtenu automatiquement peut servir de brouillon, mais ne constitue pas à lui seul une validation linguistique ou fonctionnelle : faites relire les formulations et vérifiez-les dans l’app en fonctionnement.

Pour éviter les désaccords en équipe, convenez aussi de ce qui est traduit et de ce qui ne l’est pas. Les noms de cours peuvent rester identiques dans les deux langues si c’est le choix du projet ; les boutons d’action et les instructions destinées au public doivent, eux, faire l’objet d’une décision explicite.

Choisir le bon environnement de travail

Vous pouvez apprendre les principes de localisation en lisant un catalogue ou en préparant vos traductions, mais la création, la compilation et la vérification du projet nécessitent un environnement Mac avec Xcode. Les exigences système d’Xcode publiées par Apple sont à vérifier avant de choisir une machine ou une version : elles évoluent et déterminent si votre configuration peut installer l’outil requis.

Voici le choix selon votre situation :

  • Si vous avez accès à un Mac compatible avec la version de Xcode du cours, utilisez-le pour créer le catalogue, compiler l’app et vérifier les écrans.
  • Si vous n’avez pas de Mac mais devez rendre une app SwiftUI exécutable, voyez si votre établissement peut vous prêter un poste ou vous donner accès à un environnement autorisé. Sinon, un Mac distant peut être une option pour les tâches qui exigent Xcode.
  • Si le cours n’exige pas encore de compiler une app, préparez les textes, le vocabulaire et les notes de traduction, puis effectuez les opérations propres à Xcode quand un environnement compatible est disponible.
  • Si votre ordinateur est celui de l’établissement et que vous ne pouvez pas installer de logiciel, ne contournez pas les restrictions : demandez un accès autorisé ou reportez la compilation à un Mac disponible.

L’utilisation à distance dépend de la connexion et de l’accès permis par votre cours. Elle ne remplace pas toujours les essais sur un appareil physique si le devoir exige une validation matérielle. Si vous examinez cette piste, vous pouvez découvrir les environnements Mac proposés par MACCOME et vérifier qu’ils correspondent à votre besoin avant de choisir. Pour les étapes générales d’accès, consultez aussi la présentation de MACCOME en français.

Vérifier les deux langues avant de rendre le devoir

Un catalogue renseigné est un indice de préparation, pas la preuve que l’app est entièrement bilingue. Lancez le projet avec les réglages linguistiques prévus par votre version de Xcode, puis inspectez le résultat réel. La procédure de test et ses options peuvent dépendre de la version : appuyez-vous sur la documentation Apple dédiée aux tests de localisation pendant l’exécution, puis confirmez que les réglages disponibles correspondent à votre environnement.

Suivez ces étapes avant la remise :

  1. Définissez les langues du projet. Vérifiez que le chinois et l’anglais sont bien prévus dans les réglages de localisation de l’app. Ne supposez pas que la simple présence de traductions dans un fichier active automatiquement toutes les options du projet.
  2. Contrôlez le catalogue. Repérez les chaînes visibles de l’écran rendu et examinez leur statut pour chacune des langues. Une entrée manquante doit être expliquée ou complétée.
  3. Exécutez l’app dans la langue par défaut. Vérifiez les titres, boutons, messages et contenus qui changent selon les actions.
  4. Recommencez dans l’autre langue. Utilisez les réglages de lancement ou de test proposés par votre version de Xcode. Notez les textes qui restent dans la langue par défaut, puis retrouvez leur source dans le projet.
  5. Essayez un texte long et un contenu dynamique. Le but est de repérer les libellés tronqués, les retours à la ligne inattendus ou les phrases assemblées dans un ordre peu naturel.
  6. Inspectez la mise en page dans l’app exécutée. Un fichier de traduction ne montre pas à lui seul comment les textes occupent l’écran. Vérifiez les boutons, les zones de texte et les éléments qui risquent de se chevaucher.
  7. Préparez la remise. Indiquez les langues vérifiées, les limites connues et les éléments qui n’ont pas été traduits. Si le projet dépend d’un accès particulier au Mac, expliquez comment le correcteur peut le lancer.

Cette vérification est particulièrement utile pour une page de cours, une fiche de révision ou un petit projet de création audio ou vidéo. Les noms d’outils et les titres peuvent s’allonger ; une interface qui fonctionne avec un libellé court peut devenir difficile à lire avec une traduction plus longue. Le rendu final, et non la seule existence du catalogue, doit guider votre décision de valider l’écran.

Si vous êtes encore en train de préparer le projet, commencez par un écran et une liste courte de textes. Si l’app doit être compilée et contrôlée pour le cours mais qu’aucun Mac compatible n’est disponible, comparez d’abord l’accès à un poste de votre établissement avec une solution temporaire à distance. L’ordinateur de l’école peut être soumis à des restrictions ou à des créneaux d’utilisation ; un Mac personnel implique un achat et une installation que votre projet n’exige peut-être pas sur le long terme. Pour un exercice limité, utiliser un Mac distant via MACCOME peut vous donner accès à un environnement de développement sans acheter immédiatement une machine. Si le travail devient un usage régulier ou exige des périphériques physiques, un Mac auquel vous avez accès en continu sera probablement plus adapté.