# General Translation Knowledge Base: Comment localiser une app iOS avec les String Catalogs ? URL: https://generaltranslation.com/fr/kb/localize-ios-app.mdx Docs index: https://generaltranslation.com/llms.txt Description: Ajoutez vos langues dans Xcode, rédigez le texte destiné aux utilisateurs avec des API localisables comme Text de SwiftUI et String(localized:), puis lancez une compilation pour que Xcode rassemble ces chaînes dans un String Catalog (.xcstrings). Traduisez dans Xcode, via XLIFF, ou avec la CLI de General Translation si vos catalogues doivent être mis à jour à chaque livraison et partager la même terminologie que votre site web et votre app Android. Category: Internationalisation Last updated: 2026-10-20 Authors: Kevin Wu, Jackie Chen Published: 2026-10-20 Un String Catalog réunit une table de chaînes dans toutes les langues au sein d’un unique fichier JSON, et Xcode le synchronise avec votre code à chaque compilation. Il ne vous reste alors que deux tâches : faire figurer chaque chaîne destinée aux utilisateurs dans le catalogue, puis y réintégrer des traductions de qualité. ## Configurer la localisation dans Xcode ### Ajouter vos langues Dans l'éditeur de projet, sélectionnez le projet, ouvrez **Info**, puis cliquez sur le bouton d'ajout sous **Localizations** (la barre latérale de l'éditeur de String Catalog en propose également un). Chaque entrée possède un identifiant de langue, par exemple `de`, `ja` ou `en-IN` ([Apple : Adding support for languages and regions](https://developer.apple.com/documentation/xcode/adding-support-for-languages-and-regions)). Ne choisissez une variante régionale que si le texte diffère, comme entre `pt-BR` et `pt-PT` (voir [codes de paramètres régionaux](/docs/platform/core/guides/locale-codes)). ### Ajouter un String Catalog et compiler Choisissez **File > New > File from Template**, filtrez sur « string », puis sélectionnez **String Catalog**. Le nom par défaut est `Localizable.xcstrings`. Choisissez ensuite **Product > Build** : Xcode détecte les chaînes localisables dans votre code et les ajoute au catalogue, qu'il met ensuite à jour à chaque nouvelle compilation ([Apple : Localizing and varying text with a string catalog](https://developer.apple.com/documentation/xcode/localizing-and-varying-text-with-a-string-catalog)). Les String Catalogs ont fait leur apparition avec Xcode 15 ([notes de version](https://developer.apple.com/documentation/xcode-release-notes/xcode-15-release-notes)). Lors du build, ils sont compilés en fichiers `.strings` et `.stringsdict` : les adopter ne vous oblige donc pas à relever votre cible de déploiement minimale ([WWDC23 : Discover String Catalogs](https://developer.apple.com/videos/play/wwdc2023/10155/)). ### Écrire du texte avec des API localisables Xcode n'extrait que les chaînes transmises à des API localisables. Dans SwiftUI, les littéraux de chaîne présents dans les vues sont des valeurs [`LocalizedStringKey`](https://developer.apple.com/documentation/swiftui/localizedstringkey) et sont extraits automatiquement. Partout ailleurs, utilisez `String(localized:)` ([Apple : Preparing your app's text for translation](https://developer.apple.com/documentation/xcode/preparing-your-apps-text-for-translation)) : ```swift import SwiftUI struct CartView: View { let itemCount: Int let couponCode: String var body: some View { VStack { // Dans les vues SwiftUI, les littéraux de chaîne sont des valeurs LocalizedStringKey : // Xcode les ajoute donc au String Catalog lors de la compilation. Text("Your cart") // L'interpolation devient un spécificateur de format (%lld), que vous pouvez décliner selon le pluriel. Text("\(itemCount) items") // Un commentaire indique aux traducteurs où et comment le texte est utilisé. Text("Checkout", comment: "Button that starts payment for the items in the cart.") // Une variable String est affichée telle quelle. Text(verbatim:) le rend explicite. Text(verbatim: couponCode) } } } // En dehors des vues SwiftUI, créez du texte localisable avec String(localized:). let emptyCartMessage = String( localized: "Your cart is empty", comment: "Shown when the cart has no items." ) ``` L'erreur la plus fréquente consiste à écrire `Text(someString)` : une variable `String` n'est pas recherchée dans le catalogue. Pour transmettre du texte localisable d'une vue à l'autre, utilisez `LocalizedStringResource`, recommandé par Apple, qui contient en outre un commentaire et un nom de table. Les commentaires sont importants, car « Checkout » pris isolément peut être un nom ou un verbe. Ajoutez-les avec le paramètre `comment:`, ou faites un Contrôle-clic sur une clé dans le catalogue et choisissez **Generate Comment** pour que Xcode en rédige un à partir du code environnant. Pour repérer le texte qui n'a jamais été ajouté au catalogue, ouvrez **Product > Scheme > Edit Scheme > Run > Options** et activez **Show non-localized strings** ; ces chaînes s'affichent alors en majuscules lorsque l'application s'exécute ([Apple : Preparing your interface for localization](https://developer.apple.com/documentation/xcode/preparing-your-interface-for-localization)). (Voir [Comment trouver les chaînes codées en dur qui ne sont pas traduites ?](/kb/find-hardcoded-strings)). ## Gérer les formes plurielles, les appareils et Info.plist Faites un Contrôle-clic sur une clé contenant un nombre interpolé, puis choisissez **Vary by Plural**. Xcode ajoute les catégories de pluriel requises par chaque langue : `one` et `other` pour l'anglais, puis `one`, `few`, `many` et `other` lorsque vous ajoutez le russe. **Vary by Device** permet d'attribuer à une clé une valeur différente selon l'appareil, par exemple "Tap to learn more" sur iPhone et "Click to learn more" sur Mac. Sous l'éditeur, le catalogue est un fichier JSON, ce qui produit des diffs lisibles dans les pull requests. Voici un court extrait contenant une forme plurielle en anglais et une traduction en espagnol : ```json title="Localizable.xcstrings" { "sourceLanguage" : "en", "strings" : { "%lld items" : { "comment" : "Number of items in the shopping cart.", "localizations" : { "en" : { "variations" : { "plural" : { "one" : { "stringUnit" : { "state" : "translated", "value" : "%lld item" } }, "other" : { "stringUnit" : { "state" : "translated", "value" : "%lld items" } } } } } } }, "Checkout" : { "comment" : "Button that starts payment for the items in the cart.", "localizations" : { "es" : { "stringUnit" : { "state" : "translated", "value" : "Pagar" } } } } }, "version" : "1.0" } ``` Le texte destiné au système dans `Info.plist`, comme le nom d’affichage de l'app et les descriptions d'usage affichées dans les demandes d'autorisation, doit figurer dans un catalogue distinct. Ajoutez un fichier `InfoPlist.xcstrings` à la cible : Xcode le remplit alors avec les clés localisables connues de `Info.plist` à chaque compilation. ## Suivre l'état des chaînes Chaque traduction du catalogue possède un état, affiché dans la colonne **State** de l'éditeur : * **New :** pas encore traduite dans cette langue. * **Needs Review :** la source a été modifiée après la traduction, ou quelqu'un l'a signalée ; choisissez **Mark as Reviewed** pour conserver la valeur actuelle. * **Translated :** une coche verte ; plus rien à faire. * **Stale :** Xcode ne trouve plus la chaîne de caractères dans le code. Les chaînes non traduites qui disparaissent du code sont supprimées ; les chaînes traduites sont conservées et marquées comme obsolètes jusqu'à ce que vous les supprimiez. Les chaînes que vous ajoutez à la main, comme les clés construites à l'exécution, peuvent passer en gestion manuelle : les compilations ne les mettront alors jamais à jour et ne les supprimeront jamais. ## Migrer depuis .strings et .stringsdict Pour convertir un projet existant, choisissez **Edit > Convert > To String Catalog** (ou faites un Ctrl-clic sur un fichier et choisissez **Migrate to String Catalog**). La migration s'effectue fichier par fichier et cible par cible, et les catalogues peuvent coexister avec les anciens fichiers le temps de la migration. Un catalogue et un fichier `.strings` ou `.stringsdict` portant le même nom dans la même cible provoquent une erreur de compilation : terminez donc chaque table avant de passer à la suivante. Lors de la migration de `InfoPlist.strings`, ses commentaires éventuels sont conservés. ## Choisir comment traduire Ces approches permettent d’ajouter des traductions au catalogue : | Approche | Qui traduit | Contexte fourni au traducteur | Reproductible à chaque livraison | Ce qui reste à votre charge | | --------------------------------------------------------------------------------------------- | ----------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | Saisie dans l’éditeur de catalogue | Vous ou un collègue bilingue | L’application entière | Non | Chaque chaîne de caractères dans chaque langue, à la main | | Agent de codage Xcode (Xcode 27) | L’agent que vous activez dans Xcode | L’endroit où chaque chaîne est utilisée, les chaînes similaires, les besoins en matière de pluriel, les guides de style linguistique d’Apple | Exécuté à la demande dans Xcode | Configuration initiale de l’agent, relecture des chaînes traduites automatiquement, cohérence de la terminologie avec vos applications web et Android | | Export `.xcloc` et XLIFF vers des traducteurs ou un système de gestion de la traduction (TMS) | Traducteurs professionnels | Commentaires, ainsi que les captures d’écran que vous ajoutez au dossier `Notes` | Automatisable avec `xcodebuild` | Un aller-retour à chaque livraison, et le délai qui va avec | | CLI de General Translation | Le service de traduction de GT | Commentaires du catalogue, ainsi que glossaire et instructions personnalisées partagés | Exécutez [`gt translate`](/docs/cli/reference/commands/translate) avant la compilation | Relecture dans le tableau de bord ou dans Xcode, puis test de l’application | | Script de traduction automatique ou LLM appliqué au JSON | Un modèle ou une API de traduction | Ce que votre script envoie | Oui | Variations, substitutions, catégories de pluriel par langue, spécificateurs de format, états et relecture | **Exportation.** **Product > Export Localizations** crée un Xcode Localization Catalog (un dossier `.xcloc`) par langue, contenant un fichier XLIFF ([Apple : Exporting localizations](https://developer.apple.com/documentation/xcode/exporting-localizations)). Activez le réglage de compilation **Use Compiler to Extract Swift Strings** pour que l’export inclue toutes les chaînes Swift. Réimportez les traductions avec **Product > Import Localizations**, ou automatisez l’export et l’import avec `xcodebuild -exportLocalizations` et `xcodebuild -importLocalizations` ([Apple : Importing localizations](https://developer.apple.com/documentation/xcode/importing-localizations)). **Nouveautés d’Xcode 27.** Les agents d’Xcode peuvent désormais traduire les String Catalogs : Xcode ajoute les langues, crée les String Catalogs manquants et fournit à l’agent le contexte de chaque chaîne ([notes de version d’Xcode 27](https://developer.apple.com/documentation/xcode-release-notes/xcode-27-release-notes), [WWDC26 : Translate your app using agents in Xcode](https://developer.apple.com/videos/play/wwdc2026/213/)). L’éditeur de catalogue dispose d’un nouveau bouton **Generate Translations**, les traductions produites par l’agent reçoivent l’état **Machine Translated**, et le XLIFF exporté les signale avec `state-qualifier="leveraged-mt"`. Un commentaire de localisation « do not translate » marque désormais une chaîne comme **Don't Translate** dans le catalogue et `translate="no"` dans le XLIFF. Vous pouvez faire pointer `AGENTS.md` ou `CLAUDE.md` vers un fichier `TRANSLATION.md` contenant un glossaire et une liste de chaînes que l’agent ne doit pas traduire ([Apple : Localizing your app using agents](https://developer.apple.com/documentation/xcode/localizing-your-app-using-agents)). Utilisez l’éditeur de catalogue pour une ou deux langues que vous maîtrisez. Utilisez l’agent d’Xcode si vous voulez une traduction automatique directement dans Xcode. Optez pour General Translation si vous avez besoin d’une commande reproductible dans le dépôt et d’une terminologie partagée entre vos produits ; vous continuez à utiliser Xcode et les API de localisation natives d’Apple. Passez par un export XLIFF lorsque le travail est confié à des traducteurs professionnels ou à un [TMS](/kb/what-is-a-translation-management-system) existant. ## Tester chaque langue Choisissez **Product > Scheme > Edit Scheme**, sélectionnez **Run**, puis **Options**, et définissez **App Language** et **App Region** pour la prochaine exécution ([Apple : Testing localizations](https://developer.apple.com/documentation/xcode/testing-localizations-when-running-your-app)). Ce même menu **App Language** propose également des pseudo-langues : **Double-Length** pour le foisonnement du texte, **Right-to-Left** pour les mises en page en miroir, **Accented** et **Tall** pour les glyphes plus hauts, et **Bounded String** pour la troncature (voir [Qu’est-ce que la pseudo-localisation ?](/kb/pseudo-localization)). Pour les aperçus SwiftUI, utilisez `.environment(\.locale, .init(identifier: "de"))`. Les métadonnées de l’App Store (nom, description, captures d’écran) se localisent séparément dans [App Store Connect](https://developer.apple.com/help/app-store-connect/manage-app-information/localize-app-information). ## Traduire des String Catalogs avec General Translation Si vous souhaitez lancer la traduction via une commande reproductible et garantir une terminologie cohérente entre votre application iOS, votre site web et votre application Android, la CLI de General Translation, `gt`, traduit les fichiers `.xcstrings` sur place (`gt` 2.21.0 ou version ultérieure). Ajoutez à `gt.config.json` une entrée `xcstrings` qui pointe directement vers chaque catalogue : ```json title="gt.config.json" { "defaultLocale": "en", "locales": ["es", "ja"], "files": { "xcstrings": { "include": ["Resources/Localizable.xcstrings", "Resources/InfoPlist.xcstrings"] } } } ``` Tous les paramètres régionaux se trouvent dans le même fichier : les chemins `include` ne contiennent donc pas d’espace réservé `[locale]`, et la valeur `sourceLanguage` du catalogue doit correspondre à `defaultLocale`, sans quoi l’exécution s’arrête avant le téléversement. Connectez-vous avec [`npx gt login`](/docs/cli/reference/commands/login), définissez `GT_PROJECT_ID` ([informations d’authentification de la CLI](/docs/cli/guides/configuring#credentials)) et, pour une application existante, importez la source et les traductions relues avec [`npx gt upload`](/docs/cli/reference/commands/upload). Exécutez ensuite [`npx gt translate`](/docs/cli/reference/commands/translate) pour générer les mises à jour. En CI, stockez dans `GT_API_KEY` une clé API de projet disposant des autorisations **Files > Write** et **Translation queue > Enabled**. La CLI ne téléverse que la partie en langue source, puis réintègre chaque locale cible dans le fichier, sans toucher aux autres paramètres régionaux ni à la structure du catalogue. Lors du traitement des String Catalogs, elle applique les catégories de pluriel de la langue cible pour traduire les variations et préserve les spécificateurs de format ainsi que les substitutions. (Consultez la [référence `.xcstrings`](/docs/cli/reference/formats/xcstrings-files).) Avec l’ancienne organisation, ce sont les clés `dotStrings` et `dotStringsdict` qui traduisent les fichiers `.strings` et [`.stringsdict`](/docs/cli/reference/formats/dot-stringsdict-files). Relisez le catalogue dans Xcode ou utilisez l’[éditeur de fichiers bruts](/docs/platform/dashboard/guides/reviewing-translations) du tableau de bord. Si vous modifiez des traductions dans Xcode, exécutez [`npx gt save-local`](/docs/cli/reference/commands/save-local) pour que les exécutions suivantes les conservent. Attribuez un même [groupe de contexte](/docs/platform/dashboard/guides/defining-context-for-translations) à vos projets iOS, web et [Android](/docs/cli/reference/formats/android-strings-files) : un terme du glossaire, comme le nom de vos offres, reste ainsi identique sur toutes les interfaces. Ramp utilise GT pour plus de 11 paramètres régionaux sur son tableau de bord, sa page d’accueil et son application iOS : un exemple d’une même plateforme de traduction au service de produits web comme natifs. (Consultez les [déploiements en production](https://generaltranslation.com/enterprise).) ## Points clés * Lancez une compilation après avoir ajouté `Localizable.xcstrings` : Xcode extrait les littéraux SwiftUI et le texte `String(localized:)`, mais pas les `Text` construits à partir d'une variable `String`. * Utilisez **Vary by Plural** pour les quantités ; Xcode ajoute les catégories propres à chaque langue, par exemple quatre pour le russe. * Les chaînes traduites supprimées du code ne disparaissent pas : elles passent à l'état **Stale**. Pensez donc à les nettoyer vous-même. * Xcode 27 introduit la traduction par agent, un état **Machine Translated** et `leveraged-mt` dans les fichiers XLIFF exportés. * La CLI de General Translation traduit le catalogue sur place avec `"xcstrings": { "include": [...] }` et [`npx gt translate`](/docs/cli/reference/commands/translate). Elle préserve les paramètres régionaux non concernés ainsi que la structure du catalogue, tout en produisant les variantes dans les langues cibles. ## Related questions - [Qu’est-ce que la pseudo-localisation ?](https://generaltranslation.com/fr/kb/pseudo-localization.mdx): La pseudo-localisation est un test qui remplace votre texte source par une version modifiée, accentuée, allongée d’environ 40 % et encadrée de crochets, afin de faire apparaître les chaînes codées en dur, les troncatures, les polices défaillantes et les phrases concaténées avant même qu’une traduction n’existe. Android propose à cet effet les pseudo-paramètres régionaux en-XA et ar-XB. - [Comment trouver les chaînes codées en dur qui ne sont pas traduites ?](https://generaltranslation.com/fr/kb/find-hardcoded-strings.mdx): Exécutez dans votre CI un linter qui signale les littéraux de chaîne de caractères visibles par l’utilisateur, comme la règle no-literal-string d’eslint-plugin-i18next pour JSX, la vérification HardcodedText d’Android Lint ou le linter HardCodedString d’erb_lint pour Rails. Parcourez ensuite l’application avec un pseudo-paramètre régional pour repérer le texte que les vérifications statiques ne peuvent pas détecter. - [Comment prendre en charge les langues RTL (right-to-left) en CSS ?](https://generaltranslation.com/fr/kb/right-to-left-css.mdx): Placez dir="rtl" et lang sur l’élément html, car lang seul ne modifie pas le sens d’écriture, puis remplacez les propriétés CSS physiques comme margin-left par des propriétés logiques comme margin-inline-start. Les lignes flex, les colonnes de grille et l’alignement du texte par défaut s’inversent automatiquement ; ce n’est pas le cas de translateX(), left et right. - [General Translation ou un TMS (Crowdin, Lokalise, Phrase)](https://generaltranslation.com/fr/kb/general-translation-vs-tms.mdx): Choisissez General Translation lorsque les développeurs veulent que la génération des traductions, le contexte tiré du code et la relecture soient liés aux livraisons du produit. Conservez vos catalogues et votre bibliothèque de rendu existants, ou rédigez du JSX intégré sans clés de traduction. Un TMS convient aux programmes centrés sur les prestataires linguistiques, les outils de TAO et l’échange XLIFF ; ses intégrations peuvent automatiser les transferts de fichiers. ## Previous and next questions - Previous question: [Comment détecter la langue du navigateur d’un utilisateur ?](https://generaltranslation.com/fr/kb/detect-user-language.mdx) - Next question: [Comment nommer les clés de traduction i18n ?](https://generaltranslation.com/fr/kb/i18n-key-naming.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/fr/kb/sitemap.md) for every article.