Migrer Localizable.strings vers un String Catalog (.xcstrings)

Avant de lancer la migration

Deux précautions, qui évitent la plupart des mauvaises surprises :

• Un arbre Git propre, sur une branche dédiée. Toute la valeur de l'opération se lit ensuite dans le diff ; il faut pouvoir le lire seul.
• Un build qui passe avant la migration. Xcode remplit le catalogue en analysant le code au moment du build. Si le projet ne compile pas, le catalogue restera incomplet et vous ne saurez pas pourquoi.

La migration elle-même

Dans le navigateur de projet, clic droit sur Localizable.strings, puis Migrate to String Catalog. Xcode affiche la liste des fichiers et des cibles concernés ; l'intitulé exact peut varier d'une version de Xcode à l'autre, le principe reste le même.

Les fichiers fr.lproj/Localizable.strings, de.lproj/Localizable.strings, etc. disparaissent au profit d'un seul Localizable.xcstrings, qui contient toutes les langues. Les commentaires des fichiers .strings deviennent le commentaire de chaque clé.

À quoi ressemble le fichier

Un String Catalog est un fichier JSON. Une clé simple :

{
  "sourceLanguage" : "en",
  "strings" : {
    "welcome_user" : {
      "comment" : "Home screen greeting",
      "localizations" : {
        "fr" : {
          "stringUnit" : {
            "state" : "translated",
            "value" : "Bon retour, %@ !"
          }
        }
      }
    }
  },
  "version" : "1.0"
}

Et un pluriel, rangé sous variations :

"items_left" : {
  "localizations" : {
    "fr" : {
      "variations" : {
        "plural" : {
          "one" : { "stringUnit" : { "state" : "translated", "value" : "%lld article restant" } },
          "other" : { "stringUnit" : { "state" : "translated", "value" : "%lld articles restants" } }
        }
      }
    }
  }
}

Notez le style : un espace avant les deux-points, comme Xcode l'écrit. Un outil qui réécrit le fichier au format JSON « standard » produira un diff énorme sans rien changer au contenu.

Ce qu'il faut relire dans le diff

Les clés marquées Stale. Après un build, Xcode signale les clés qu'il ne retrouve plus dans le code. Ce ne sont pas forcément des clés mortes : une clé construite à l'exécution (NSLocalizedString(variable, comment: ""), une clé lue depuis un fichier de configuration) n'est pas détectée par l'analyse. Vérifiez avant de supprimer.

Les nouvelles clés extraites du code. Le build peut ajouter des chaînes que vous n'aviez jamais mises dans Localizable.strings, typiquement des Text("…") SwiftUI, localisables par défaut. Elles arrivent sans traduction : le pourcentage affiché par Xcode pour chaque langue baisse, c'est normal.

Les états. Chaque valeur porte un état : translated, needs_review, ou new pour une chaîne pas encore traduite. C'est ce qui permet de savoir, trois mois plus tard, ce qui a été relu.

Les format specifiers. Une chaîne SwiftUI comme Text("\(count) items left") donne la clé %lld items left. Si l'ancien .strings utilisait %d pour la même phrase, vous avez maintenant deux clés proches ; gardez celle que le code utilise vraiment.

Et sur les anciennes versions d'iOS ?

Pas besoin d'iOS 17. Le catalogue est un format de travail : au build, Xcode le compile en fichiers .strings classiques dans le bundle de l'app. Votre cible de déploiement ne change pas.

Éditer le catalogue hors de Xcode

L'éditeur de Xcode suffit pour quelques chaînes. Pour relire une langue entière, traduire en lot ou contrôler les placeholders, un outil dédié aide. LocalePilot ouvre les fichiers .xcstrings et les réécrit dans le style de Xcode : un catalogue réécrit sans modification est identique à l'octet près, une modification ne change que ses lignes, et une valeur modifiée passe à l'état translated. Les pluriels et variations par appareil sont éditables ; les clés à substitutions (%#@count@) et celles marquées shouldTranslate: false sont conservées telles quelles, à éditer dans Xcode.