Comment localiser les captures d'écran App Store sur plus de 30 langues

Pourquoi localiser les captures d'écran tout court ?

La propre recherche développeur d'Apple constate que les utilisateurs sont significativement plus susceptibles d'installer une application quand la fiche App Store est dans leur langue maternelle. La même chose est documentée dans la checklist de localisation de Google : les fiches localisées convertissent mieux et se classent mieux en recherche. Traduire uniquement les chaînes de métadonnées — titre, sous-titre, mots-clés — sans traduire les captures d'écran est la demi-mesure la plus courante, et cela laisse de la conversion réelle sur la table parce que l'actif héros est toujours en anglais.

Le bloqueur pour la plupart des équipes est opérationnel, pas stratégique. Traduire un ensemble de cinq captures d'écran en 30 langues à la main signifie 150 fichiers de design, 150 cycles de revue et 150 chances pour une faute de frappe. La solution consiste à traiter les captures d'écran comme toute autre UI localisée : clés dans le code, copy dans un TMS, mise en page rendue par une étape de build.

Comment devriez-vous structurer les clés de traduction ?

Utilisez la même structure de clés que vos traductions in-app. Groupez les clés par identifiant de capture d'écran, puis par rôle d'élément :

{
  "screenshots": {
    "01_home": {
      "headline": "Build faster.",
      "subhead": "Ship every store size in one API call.",
      "badge": "New"
    },
    "02_pricing": {
      "headline": "Plans for every team.",
      "cta": "Start free"
    },
    "03_api": {
      "headline": "Built for developers.",
      "subhead": "REST, Fastlane, and GitHub Actions out of the box."
    }
  }
}

Puis le fichier allemand correspondant :

{
  "screenshots": {
    "01_home": {
      "headline": "Schneller bauen.",
      "subhead": "Alle Store-Formate mit einem API-Call.",
      "badge": "Neu"
    },
    "02_pricing": {
      "headline": "Pläne für jedes Team.",
      "cta": "Kostenlos starten"
    }
  }
}

Les clés ne changent jamais. Seules les valeurs changent. Les traducteurs travaillent sur la colonne valeur dans leur TMS sans toucher au modèle Screenshots.live.

Quels codes de langue devriez-vous utiliser ?

Utilisez BCP-47 de manière cohérente. N'utilisez que le sous-tag de langue lorsqu'il n'y a pas de variation régionale (de, fr, ja) et ajoutez la région uniquement quand les variantes divergent significativement (en-GB vs en-US, pt-BR vs pt-PT, zh-Hans vs zh-Hant). Apple et Google acceptent tous deux BCP-47, bien que leurs codes internes diffèrent légèrement — voir la liste des langues App Store Connect et les langues prises en charge de Google Play. Mappez-les une fois dans votre script CI.

Comment multiplexer les rendus à travers les langues ?

L'API prend un identifiant de modèle, un catalogue de traduction et un tableau de langues. Elle retourne un PNG rendu par langue par appareil :

curl -X POST https://api.screenshots.live/v1/renders \
  -H "Authorization: Bearer $SCREENSHOTSLIVE_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "templateId": "tpl_app_release_v3",
    "locales": ["en", "de", "es", "fr", "pt-BR", "it", "nl", "ja", "ko", "zh-Hans", "ar", "he"],
    "devices": ["iphone-6.7", "iphone-6.1", "ipad-12.9", "phone-android"],
    "translations": {
      "en": "@translations/en.json",
      "de": "@translations/de.json",
      "es": "@translations/es.json"
    }
  }'

En coulisses, le moteur de rendu parallélise par langue et par appareil. Un rendu de 12 langues × 4 appareils — 48 fichiers PNG — se termine généralement en moins de 90 secondes. Voir la documentation du rendu API pour la forme complète de la requête.

Comment gérez-vous les langues de droite à gauche ?

L'arabe (ar), l'hébreu (he), le persan (fa) et l'ourdou (ur) ont besoin que toute la mise en page soit reflétée — alignement du texte, positions des images, icônes de flèches, même l'ordre des groupes multi-éléments. Un demi-reflétage (n'inverser que le texte mais pas la mise en page) paraît mauvais aux lecteurs natifs et endommage la crédibilité.

Dans Screenshots.live, marquez le modèle avec direction: "auto" et le moteur de rendu inverse automatiquement la mise en page, l'alignement du texte et les chevrons décoratifs lors du rendu des langues RTL. Surchargez les éléments individuels avec direction: "ltr" quand quelque chose doit rester de gauche à droite (un numéro de téléphone, une URL, un bloc de code).

Et les overrides de texte par langue ?

Certaines langues ne tiennent simplement pas dans la même boîte de légende. Les substantifs composés allemands peuvent être 40 % plus longs que l'anglais ; le japonais et le chinois peuvent être 50 % plus courts. Autorisez les overrides de texte par langue sans forker le modèle :

{
  "screenshots.01_home.headline": {
    "en": "Build faster.",
    "de": "Schneller bauen.",
    "fi": "Rakenna nopeammin.",
    "ja": "もっと速く。"
  },
  "screenshots.01_home.subhead": {
    "en": "Ship every store size in one API call.",
    "de": "Alle Formate mit einem Aufruf.",
    "ja": "ワンコールで全サイズ対応。"
  }
}

Et les polices et glyphes CJK ?

Les polices d'écriture latine (Inter, SF Pro, Roboto) manquent souvent de glyphes CJK, cyrilliques, devanagari ou arabes — le texte se rend en boîtes tofu. Configurez les replis de polices par écriture :

• Latin / cyrillique / grec : Inter, SF Pro, Roboto
• CJK (japonais / coréen / chinois) : Noto Sans CJK
• Arabe / persan / ourdou : Noto Sans Arabic, IBM Plex Sans Arabic
• Devanagari (hindi) : Noto Sans Devanagari
• Thaï : Noto Sans Thai, Sarabun

La famille Noto couvre chaque écriture qu'Apple et Google prennent en charge. Définissez-la comme chaîne de repli dans le modèle — le moteur de rendu choisit la bonne police par point de code, sans intervention manuelle.

Comment faire le QA des mises en page à grande échelle ?

L'examen manuel de 30 langues ne passe pas à l'échelle. Automatisez les modes d'échec évidents :

• Débordement de texte : rendez à un quart de résolution, OCRez le résultat, faites un diff par rapport à la chaîne source. Les non-correspondances signifient que le texte a été tronqué.
• Glyphes manquants : comptez les boîtes tofu dans le PNG rendu via un modèle de vision ou un histogramme de pixels sur le caractère de remplacement Unicode.
• Traductions vides : faites échouer le build si une langue a plus de 5 % de clés manquantes par rapport à l'anglais.
• Budgets de longueur : définissez un plafond de longueur strict par clé. Si la traduction allemande le dépasse, faites échouer le build au lieu de laisser le débordement passer en livraison.

Comment téléverser les captures d'écran par langue ?

App Store Connect et Google Play acceptent tous deux les captures d'écran par langue. Fastlane deliver lit depuis fastlane/screenshots/<locale>/ et Fastlane supply lit depuis fastlane/metadata/android/<locale>/images/phoneScreenshots/. Mappez la sortie de votre moteur de rendu vers ces chemins et le reste n'est que fastlane deliver / fastlane supply --skip_upload_apk.

Que devriez-vous faire ensuite ?

Combinez ceci avec notre guide d'automatisation CI/CD afin que la localisation s'exécute à chaque mise en production. Utilisez la fonctionnalité de prise en charge multi-plateformes pour multiplexer vers les stores iOS, Android et web à partir du même catalogue.