Localiser une application iOS en plus de 40 langues avec les String Catalogs (.xcstrings)

Pour localiser une application iOS en plus de 40 langues, regroupez tous les textes visibles dans des catalogues de chaînes Xcode (Localizable.xcstrings et InfoPlist.xcstrings), laissez Xcode les extraire automatiquement, gérez les pluriels dans le catalogue et les formats avec FormatStyle, testez avec les pseudolangues et les mises en page de droite à gauche, 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

• 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.
• 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.

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 depuis le menu contextuel du fichier.

// 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.

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.

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