Localisation et internationalisation iOS (i18n) : de Localizable.strings aux String Catalogs

La localisation iOS (l10n) adapte les textes, les formats et la fiche App Store d’une app à chaque langue et région ; l’internationalisation iOS (i18n) est le travail d’ingénierie qui la rend possible : sortir les textes du code, formater selon la région de l’utilisateur, prévoir des mises en page qui s’allongent et s’inversent. En pratique, vous internationalisez une fois en Swift, regroupez tous les textes visibles dans des catalogues de chaînes Xcode (Localizable.xcstrings, qui remplace Localizable.strings et .stringsdict, et InfoPlist.xcstrings), laissez Xcode les extraire, testez avec les pseudolangues, puis traduisez : traduction automatique pour la vitesse, relecture humaine là où elle compte. Terminez par la fiche App Store, qui se localise à part dans App Store Connect. C’est ainsi que Develak publie ses propres apps dans jusqu’à 44 langues.

Points clés

• L’internationalisation se fait une fois dans le code ; la localisation se répète pour chaque langue.
• Les catalogues de chaînes (.xcstrings, Xcode 15 et ultérieur) remplacent .strings et .stringsdict : un fichier par table, pluriels et variantes par appareil compris. Xcode migre les anciens fichiers table par table.
• Ne construisez jamais une phrase par concaténation et ne formatez jamais une date ou un nombre à la main.
• Localisez aussi InfoPlist.xcstrings : les demandes d’autorisation et le nom de l’app font partie de la première impression.
• Testez avec les pseudolangues avant de payer la moindre traduction.
• Localisez la fiche App Store (nom, sous-titre, mots-clés, description, captures) pour chaque marché.
• La traduction automatique, LLM compris, fait un bon premier jet ; faites relire les textes qui vendent, qui facturent ou qui avertissent.

Pourquoi localiser une app iOS ?

L’App Store est disponible dans 175 pays et régions, et chacun y cherche, lit les avis et décide dans sa langue. Une app localisée, avec une fiche localisée, se positionne sur les mots-clés locaux et inspire confiance sur des marchés que la plupart des apps en anglais seul délaissent. iOS permet aussi de choisir la langue de chaque app dans Réglages : chaque langue ajoutée sert donc des utilisateurs qui la veulent explicitement.

Une fois la méthode en place, chaque langue supplémentaire coûte bien moins cher que la première. Nos apps les plus récentes, comme le journal de crises Seizly ou le chronomètre de circuit ApexLap, sont disponibles en 44 langues, dont l’arabe, l’hébreu et l’ourdou (écrits de droite à gauche) et des langues indiennes comme le hindi, le bengali, le tamoul et le télougou ; le pilulier Pillio l’est en 33. Ce n’est tenable que parce que les étapes ci-dessous sont devenues une routine.

Internationalisation (i18n) ou localisation (l10n) sur iOS

Les chiffres comptent les lettres entre la première et la dernière (en anglais, « internationalization » et « localization »). Le guide d’Apple consacré aux apps multilingues fixe l’ordre : on internationalise d’abord en préparant le code et les ressources pour d’autres langues et régions, puis on localise en traduisant les chaînes et en déclinant les ressources. Concrètement, une app Swift ou SwiftUI internationalisée coche cette liste :

• Aucun texte en dur : chaque texte affiché passe par Text, String(localized:) ou LocalizedStringResource, avec un commentaire quand le sens est ambigu.
• Des formats qui suivent la région : dates, nombres, devises et unités passent par FormatStyle, jamais par un motif ou un symbole figé.
• Des mises en page extensibles : piles SwiftUI ou contraintes Auto Layout sans largeur fixe, libellés sur plusieurs lignes et Dynamic Type, pour que l’allemand ou le finnois tiennent.
• Prête pour la droite à gauche : leading et trailing plutôt que left et right, images directionnelles inversées (voir plus bas).
• La grammaire dans le catalogue : pluriels en variantes du catalogue, jamais de test count == 1 dans le code.
• Les ressources dans le bundle : images, couleurs et sons localisables dans les catalogues d’assets, chaînes cherchées dans le bon bundle (Bundle.module dans un package), aucun texte incrusté dans les images.

Les catalogues de chaînes en cinq minutes

Un catalogue de chaînes (String Catalog) est un fichier JSON à l’extension .xcstrings, apparu avec Xcode 15, qui stocke toutes les chaînes d’une table et toutes leurs traductions. Ajoutez-en un nommé Localizable à votre cible et compilez : Xcode extrait les chaînes des vues SwiftUI, de String(localized:), de LocalizedStringResource et de NSLocalizedString. Chaque entrée affiche un état (New, Needs Review, Translated, Stale) et un commentaire pour les traducteurs. Les fichiers .strings et .stringsdict existants se migrent, comme le détaille la section suivante.

// Extrait automatiquement dans Localizable.xcstrings
Text("Take your medication")

// Le commentaire donne au traducteur le contexte nécessaire
Text("Open", comment: "Button: opens the selected bottle's details")

// En dehors des vues SwiftUI
let title = String(localized: "Cellar", comment: "Tab title for the list of bottles")

Les commentaires sont l’amélioration de qualité la moins chère en localisation : « Open » peut être un verbe ou un adjectif, « Archive » un nom ou une action. Xcode 26 sait aussi rédiger des commentaires pour les traducteurs grâce à un modèle exécuté sur l’appareil, et générer des symboles Swift typés pour les chaînes ajoutées à la main au catalogue. Dans un package Swift, définissez defaultLocalization dans Package.swift et cherchez les chaînes dans Bundle.module ; avec Xcode 26, la macro #bundle désigne pour vous le bon bundle, que le code tourne dans une app, un framework ou un package.

Localizable.strings ou String Catalogs (.xcstrings) : migrer pas à pas

L’ancien format : .strings et .stringsdict

Avant Xcode 15, chaque langue avait son propre fichier Localizable.strings dans un dossier .lproj (en.lproj, fr.lproj…), une liste de paires clé-valeur tenue à la main ou générée avec genstrings (notre guide du fichier Localizable.strings détaille sa syntaxe, la recherche des traductions et les erreurs propres à ce format). Les pluriels exigeaient un second fichier par langue, Localizable.stringsdict, une liste de propriétés avec une entrée par catégorie de pluriel :

/* fr.lproj/Localizable.strings */
/* Button: opens the selected bottle's details */
"Open" = "Ouvrir";
"Welcome back, %@!" = "Bon retour, %@ !";

/* en.lproj/Localizable.stringsdict (extrait) */
<key>%lld reminders</key>
<dict>
    <key>NSStringLocalizedFormatKey</key>
    <string>%#@reminders@</string>
    <key>reminders</key>
    <dict>
        <key>NSStringFormatSpecTypeKey</key>
        <string>NSStringPluralRuleType</string>
        <key>NSStringFormatValueTypeKey</key>
        <string>lld</string>
        <key>one</key>
        <string>%lld reminder</string>
        <key>other</key>
        <string>%lld reminders</string>
    </dict>
</dict>

Pourquoi les String Catalogs les remplacent

Apple présente désormais les catalogues de chaînes comme la méthode recommandée pour localiser les pluriels avec Xcode 15 et ultérieur, et a annoncé dans la session Discover String Catalogs que ce format remplacera à terme .strings et .stringsdict. À la compilation, les catalogues deviennent des fichiers .strings et .stringsdict : les adopter ne relève donc pas la version minimale d’iOS de l’app.

Checklist de migration

1. Faites d’abord un commit ou créez une branche, pour relire la migration en un seul diff.
2. Vérifiez que le réglage de compilation Use Compiler to Extract Swift Strings est activé, pour que les chaînes Swift soient extraites.
3. Dans le navigateur de projet, faites un Contrôle-clic sur Localizable.strings et choisissez Migrate to String Catalog (Xcode 15 ou ultérieur). L’assistant de migration liste, par cible, les fichiers .strings et .stringsdict qu’il peut migrer ; cochez les tables voulues.
4. Laissez Xcode compiler : dans la démonstration d’Apple, les traductions et les pluriels du .stringsdict arrivent dans le catalogue, les pluriels en variantes de la clé correspondante, et les traductions manquantes apparaissent dans la progression de chaque langue.
5. Passez en revue les clés marquées Stale ou Needs Review avant de supprimer quoi que ce soit.
6. Migrez les autres tables, comme InfoPlist.strings, à votre rythme : catalogues et anciens fichiers cohabitent. Ne laissez derrière vous aucun fichier .strings ou .stringsdict portant le même nom de table, y compris dans Base.lproj.
7. Lancez l’app dans une pseudolangue et dans une langue aux pluriels complexes, comme le russe ou l’arabe.

Le code existant continue de fonctionner : le nom de table ne change pas, donc les appels à NSLocalizedString et à String(localized:table:) se résolvent comme avant, et les chaînes Objective-C sont extraites sans réglage supplémentaire. Un package Swift doit déclarer defaultLocalization dans son manifeste avant de recevoir un catalogue.

Les bases de l’i18n en Swift : String(localized:), LocalizedStringResource et formats

L’internationalisation (i18n) est la part du travail qui se joue dans le code : rendre localisable chaque valeur affichée, pour que la localisation (l10n) se résume ensuite à ajouter des traductions. En Swift, une poignée d’API couvrent presque tous les cas, et choisir la bonne décide si une chaîne arrive ou non dans le catalogue.

// SwiftUI : un littéral est une LocalizedStringKey, recherchée automatiquement
Text("Settings")

// Une variable String s'affiche telle quelle, sans recherche
let label = "Settings"
Text(label)                      // non localisé
Text(LocalizedStringKey(label))  // recherché ; ajoutez la clé au catalogue vous-même
Text(verbatim: "Pillio")         // jamais localisé

// Hors des vues : résolu immédiatement, l'interpolation devient un placeholder
let toast = String(localized: "Welcome back, \(name)!", comment: "Toast on launch")

// Clé explicite pour un mot source ambigu
let action = String(localized: "call.verb", defaultValue: "Call", comment: "Button: phone the pharmacy")

// Différé : le système le résout plus tard, éventuellement avec d'autres réglages de langue
struct LogDoseIntent: AppIntent {
    static let title: LocalizedStringResource = "Log a dose"
    func perform() async throws -> some IntentResult { .result() }
}

// Le formatage suit la région de l'utilisateur
Text(Date.now, format: .dateTime.day().month(.wide))
Text(0.25, format: .percent)

Le bug d’i18n le plus fréquent en Swift est le deuxième exemple : passer une variable String à Text contourne la localisation sans prévenir, comme l’explique la documentation de LocalizedStringKey. Gardez les littéraux à l’endroit de l’appel, ou stockez des LocalizedStringResource plutôt que des chaînes dans vos modèles. Apple présente LocalizedStringResource comme une référence à une chaîne localisable dont la recherche est différée ; les App Intents s’en servent pour que Siri et Raccourcis puissent résoudre le texte avec leurs propres réglages de langue. Pour savoir dans quelle langue l’app tourne réellement, lisez Bundle.main.preferredLocalizations plutôt que de déduire la langue de l’appareil.

Pluriels et variantes par appareil

Écrivez la phrase une seule fois avec interpolation, puis choisissez Vary by Plural sur cette clé dans le catalogue. Xcode affiche exactement les catégories de pluriel dont chaque langue a besoin :

// Clé du catalogue : "%lld reminders" → Vary by Plural
Text("\(count) reminders")

Une chaîne contenant deux nombres (« %lld photos dans %lld albums ») peut varier sur chacun indépendamment. Vary by Device gère les formulations qui dépendent de l’appareil, comme « Touchez pour commencer » sur iPhone et « Cliquez pour commencer » sur Mac.

InfoPlist.xcstrings : demandes d’autorisation et nom de l’app

Ajoutez à la cible un second catalogue nommé InfoPlist : Xcode y place les clés localisables d’Info.plist, du nom affiché sur l’écran d’accueil (CFBundleDisplayName) à chaque texte d’autorisation, de NSCameraUsageDescription et NSMicrophoneUsageDescription à NSHealthShareUsageDescription. Une demande d’autorisation est le moment où vous sollicitez la confiance, et une demande en anglais dans une app en français paraît inachevée précisément à ce moment-là. App Review lit aussi ces textes au titre de la règle 5.1.1 : leurs traductions doivent rester précises.

Deux autres emplacements s’oublient facilement : les phrases des App Shortcuts vivent dans AppShortcuts.xcstrings, et les extensions de widget doivent disposer de leurs chaînes dans la cible de l’extension.

Dates, nombres et unités : laissez faire FormatStyle

L’ordre des dates, l’horloge sur 12 ou 24 heures, le séparateur décimal, la place du symbole monétaire, le premier jour de la semaine et le système de mesure changent tous selon la région de l’utilisateur. Ne codez jamais en dur "MM/dd/yyyy" ni un symbole de devise :

// Jour et heure, dans la langue et le format horaire de l'utilisateur
Text(dose.scheduledAt, format: .dateTime.weekday(.wide).hour().minute())

// Devise avec le bon symbole et les bons séparateurs
Text(price, format: .currency(code: "EUR"))

// Kilomètres ou miles selon la région de l'utilisateur
Text(distance, format: .measurement(width: .abbreviated, usage: .road))

// "Pillio, Seizly, and ApexLap" ou "Pillio, Seizly et ApexLap"
Text(appNames.formatted(.list(type: .and)))

Triez les listes visibles avec localizedStandardCompare et cherchez avec localizedStandardContains, pour que les accents et la casse se comportent comme on s’y attend.

Langues de droite à gauche : arabe, hébreu, ourdou

SwiftUI inverse automatiquement la mise en page quand vous utilisez leading et trailing plutôt que left et right. Les SF Symbols directionnels s’inversent d’eux-mêmes ; pour vos propres images directionnelles, activez l’inversion explicitement. N’inversez pas ce qui n’est pas directionnel : logos, photos, coches. Vérifiez le résultat dans une prévisualisation :

Image("swipe-hint")
    .flipsForRightToLeftLayoutDirection(true)

#Preview("Arabe, droite à gauche") {
    ContentView()
        .environment(\.locale, Locale(identifier: "ar"))
        .environment(\.layoutDirection, .rightToLeft)
}

Tester avant de traduire : les pseudolangues

Dans l’éditeur de schéma (Run › Options › App Language), Xcode propose des pseudolangues qui révèlent les bugs de localisation sans aucune traduction. Activez dans le même panneau « Show non-localized strings » pour repérer le texte codé en dur.

Les tests d’interface peuvent lancer l’app dans n’importe quelle langue, ce qui permet aussi d’automatiser les captures App Store localisées :

let app = XCUIApplication()
app.launchArguments += ["-AppleLanguages", "(fr)", "-AppleLocale", "fr_FR"]
app.launch()

Localiser aussi la fiche App Store

Le binaire et la fiche se localisent séparément. La ligne « Langues » de votre fiche provient du bundle de l’app ; tout le reste se règle par localisation dans App Store Connect, qui accepte des métadonnées dans 50 langues et variantes régionales :

• Nom et sous-titre (30 caractères chacun), texte promotionnel, description et nouveautés.
• Mots-clés (100 octets par localisation : les lettres accentuées et les écritures non latines consomment donc le quota plus vite), à rechercher dans chaque langue plutôt qu’à traduire : un utilisateur français qui cherche un rappel de médicaments peut taper « pilulier », un mot qu’aucune traduction de « pill reminder » ne produit.
• Captures et aperçus vidéo avec légendes traduites ; à défaut, ceux de la langue principale s’affichent. Les captures en arabe et en hébreu doivent montrer l’interface inversée. Notre guide des tailles de captures App Store détaille les dimensions attendues pour chaque jeu localisé.
• Noms et descriptions des achats intégrés, et noms des groupes d’abonnements.

Mots-clés et captures localisés relèvent pleinement de l’optimisation App Store : notre service d’optimisation App Store (ASO) traite chaque marché séparément.

Traduction humaine, automatique, ou les deux ?

Les grands modèles de langage traduisent désormais bien les chaînes d’interface quand on leur donne du contexte : le commentaire pour le traducteur, l’écran concerné, un glossaire des termes du produit. Ils trébuchent encore sur le registre (tutoiement ou vouvoiement en français, « du » ou « Sie » en allemand), les accords, la longueur et les placeholders qui doivent rester intacts. Notre règle : traduction automatique pour un premier jet sur tout, puis relecture humaine de l’accueil, du paywall et des conditions d’abonnement, des demandes d’autorisation, des métadonnées App Store et de tout ce qui touche au médical, au juridique ou à la sécurité. Les noms de marque comme Pillio ou Seizly sont marqués « Don’t translate », et les builds TestFlight passent entre les mains de locuteurs natifs avant la publication.

Les outils de localisation iOS

• L’éditeur de catalogues de Xcode : intégré, avec les états, les variantes de pluriel et d’appareil et, depuis Xcode 26, la génération de commentaires.
• Export et import (XLIFF) : Product › Export Localizations crée un Xcode Localization Catalog (.xcloc) par langue, qui contient un fichier XLIFF, le format standard des traducteurs et des outils de traduction ; Product › Import Localizations le réintègre. xcodebuild -exportLocalizations et -importLocalizations font de même en intégration continue.
• genstrings : l’ancien outil en ligne de commande qui parcourt les appels à NSLocalizedString pour générer un fichier Localizable.strings, décrit dans le guide d’internationalisation archivé d’Apple. Les catalogues de chaînes le rendent inutile.
• fastlane : outil d’automatisation open source ; deliver envoie les métadonnées et captures localisées vers App Store Connect, et snapshot réalise les captures localisées avec les tests d’interface.
• Xlocalize : notre app Mac, qui ouvre directement le fichier .xcstrings et le traduit par IA, sans étape d’export ni d’import (détails plus bas).
• Plateformes et services de traduction : la plupart acceptent le XLIFF et beaucoup lisent les .xcstrings ; vérifiez que variantes de pluriel et placeholders survivent à l’aller-retour, et voyez quand un service se justifie.

Notre outil : Xlocalize pour les fichiers .xcstrings

Localiser un catalogue de plus de 30 apps nous a conduits à créer notre propre app Mac. Xlocalize ouvre un fichier .xcstrings, vous laisse choisir les langues cibles et traduit avec OpenAI, Anthropic Claude ou Google Gemini, avec votre propre clé d’API stockée dans le trousseau macOS, sans compte à créer. Elle préserve pluriels, variantes par appareil et substitutions, transmet le commentaire de chaque clé comme contexte, suit l’état de chaque clé (nouvelle, traduite, « ne pas traduire ») et signale les placeholders incohérents, les copies non traduites et les traductions manquantes avant qu’ils n’atteignent un build. Elle fonctionne sous macOS 14 ou ultérieur et se télécharge gratuitement, avec des achats intégrés facultatifs. L’étude de cas Xlocalize raconte pourquoi nous l’avons créée.

Checklist du processus de localisation

1. Internationalisez le code : aucun texte en dur, FormatStyle partout, mises en page leading et trailing, tailles flexibles et Dynamic Type.
2. Créez les catalogues Localizable, InfoPlist et, si besoin, AppShortcuts, puis compilez pour extraire les chaînes.
3. Commentez les chaînes ambiguës et marquez les noms de marque « Don’t translate ».
4. Configurez les pluriels et les variantes par appareil.
5. Testez avec les pseudolangues et en droite à gauche.
6. Traduisez : premier jet automatique, relecture humaine des chaînes critiques.
7. Vérifiez placeholders et troncatures dans chaque langue, sur le plus petit iPhone pris en charge.
8. Localisez métadonnées App Store, mots-clés, captures et noms des achats intégrés.
9. Diffusez la version via TestFlight à des locuteurs natifs.
10. À chaque version, traduisez les chaînes nouvelles ou périmées avant de soumettre.

Les pièges courants

• La concaténation. "Hello " + name casse l’ordre des mots ; utilisez une seule chaîne localisée avec interpolation.
• Une clé, deux sens. Réutiliser « Open » comme verbe et comme adjectif impose une mauvaise traduction dans la moitié des langues.
• L’ordre des arguments. Le traducteur peut devoir réordonner les valeurs ; les spécificateurs positionnels comme %1$@ et %2$lld le permettent.
• Le texte dans les images, qu’aucun catalogue ne peut traduire.
• Les largeurs fixes et les libellés sur une ligne qui débordent en allemand.
• Les libellés d’accessibilité. VoiceOver lit à voix haute le texte de .accessibilityLabel ; il est extrait comme les autres chaînes, vérifiez qu’il est bien traduit.
• Les textes côté serveur : notifications push et e-mails se localisent aussi, par exemple avec loc-key dans la charge utile de la notification.
• Les chaînes périmées restées non traduites après une refonte.

Faire soi-même ou passer par un service de localisation iOS ?

Tout ce qui précède peut se faire en interne avec Xcode et un outil de traduction, et pour deux ou trois langues, c’est généralement la bonne option. Un service de localisation iOS externe devient rentable quand le nombre de langues augmente plus vite que votre capacité à les relire, quand l’app contient des formulations médicales, juridiques ou liées aux abonnements qui ne tolèrent pas l’à-peu-près, ou quand chaque marché demande sa propre recherche de mots-clés plutôt qu’une traduction. Vérifiez que le prestataire travaille directement dans vos fichiers .xcstrings, teste l’app en fonctionnement dans chaque langue plutôt qu’un tableur, et considère la fiche App Store comme faisant partie du travail.

Si vous préférez confier tout le processus à une équipe qui le pratique chaque semaine, notre service de localisation d’application couvre la mise en place des catalogues de chaînes, la traduction et l’adaptation, les vérifications de mise en page et de droite à gauche, la relecture linguistique sur appareil et la fiche App Store localisée.

Questions fréquentes