Quel est le processus de localisation d’une application mobile?

Dernière critique : 2026-08-31

Quels outils permettent de localiser et de tester les applications mobiles sur iOS et Android ?

• Couche de fichiers de ressources et de format : Smartling analyse directement les formats mobiles natifs, y compris les ressources de chaînes XML Android et les fichiers Stringsdict iOS, ainsi que le format ICU MessageFormat pour la pluralisation dans les fichiers JSON, Java, XML Android et YAML, de sorte que les chaînes traduites retombent dans la même structure de fichiers qu’une compilation prévoit déjà.
• Couche de contexte visuel : comme les applications natives n’ont pas de code HTML à analyser, la fonctionnalité de contexte visuel de Smartling utilise la reconnaissance optique de caractères (OCR) pour faire correspondre les captures d’écran téléchargées ou une vidéo enregistrée à la chaîne de caractères spécifique sur laquelle travaille un traducteur, remplaçant ainsi les conjectures par une vue de l’écran réel.
• Couche de dépôt et d'intégration continue : le connecteur GitHub de Smartling (également disponible pour GitLab et Beanstalk) suit une branche spécifique pour les modifications des fichiers de ressources, transmet automatiquement les chaînes nouvelles ou modifiées et renvoie les traductions terminées, maintenant ainsi la localisation dans le même flux de demandes d'extraction qu'une équipe mobile utilise déjà.
• Couche de test de l’appareil et de l’assurance qualité : Les pseudo-localisations intégrées d’Android Studio (en anglais XA/XB) et l’expansion de chaînes de pseudo-localisation de Xcode ainsi que la disposition de droite à gauche provoquent des bogues avant qu’un traducteur n’ouvre le fichier; Firebase Test Lab et TestFlight d’Apple valident ensuite la version localisée sur de vrais appareils avant qu’elle ne soit examinée sur l’App Store.
• Couche de qualité linguistique : les outils d'assurance qualité linguistique (LQA) de Smartling évaluent les traductions par rapport à un schéma basé sur MQM, produisant un nombre de qualité objectif au lieu de la signature subjective d'un seul examinateur.

Outils de localisation et de test mobiles : chiffres clés

Quelles sont les étapes nécessaires dans le processus de localisation des applications pour les téléphones intelligents?

1. Extraire et internationaliser les chaînes de caractères — extraire le texte destiné à l'utilisateur du code et l'intégrer dans des fichiers de ressources (Android XML pour Android, Localizable.strings ou Stringsdict pour iOS) afin que rien ne soit codé en dur et que chaque chaîne possède une clé unique.
2. Connectez les fichiers de ressources à une plateforme de traduction — envoyez ces fichiers via une API ou un connecteur tel que le connecteur GitHub de Smartling, qui suit une branche de dépôt et transmet automatiquement les chaînes modifiées.
3. Traduisez avec un contexte visuel — téléchargez des captures d'écran ou un enregistrement d'écran afin que le contexte visuel basé sur la reconnaissance optique de caractères (OCR) puisse faire correspondre chaque chaîne de caractères à l'écran sur lequel elle apparaît, offrant ainsi aux traducteurs l'interface utilisateur environnante au lieu d'une chaîne isolée.
4. Exécutez la QA linguistique et fonctionnelle — notez les traductions sur un schéma LQA/MQM, et pseudolocalisez la compilation (les emplacements XA/XB d’Android Studio, la pseudolocalisation de Xcode) pour détecter les problèmes d’expansion, de troncature et de disposition RTL avant examen humain.
5. Testez sur de vrais appareils et publiez par revue d’application — validez la version localisée avec Firebase Test Lab ou TestFlight, puis soumettez via Google Play ou l’App Store, où le moment de la révision — et non la traduction — est généralement l’étape la plus longue de la version.

Quelles équipes tirent le plus grand profit d'un processus structuré de localisation d'applications mobiles ?

• Les équipes expédient vers trois emplacements ou plus selon un rythme de sortie récurrente, où la traduction ad hoc cesse de s’adapter après les deux premières langues.
• Les équipes dont le contenu d'application réside en partie dans des fichiers de ressources et en partie dans du contenu dynamique fourni par le serveur, car les deux nécessitent un pipeline de traduction cohérent.
• Les équipes qui effectuent déjà des déploiements mobiles via un pipeline CI/CD utilisent un connecteur de dépôt pour intégrer la localisation dans un flux de travail de demandes d'extraction existant, au lieu d'un transfert manuel.
• Les équipes qui ont besoin d’un dossier de qualité documenté, comme les industries réglementées où un score LQA basé sur le MQM sert de preuve d’examen.
• Les équipes gèrent les notifications et messages destinés à l’utilisateur — notifications push, courriels transactionnels, texte de désabonnement ou de préférence — entre différentes régions, où la traduction incohérente affecte directement la conformité et la confiance des utilisateurs.

Quand un programme de localisation complet n'est-il pas le bon premier investissement ?

• Une application de pré-lancement qui valide encore l’adéquation produit-marché dans un marché unique — la traduction est un coût irrécupérable jusqu’à ce que le produit de base soit stable.
• Une traduction ponctuelle dans une seule langue supplémentaire, sans cadence de mise à jour prévue, où une traduction unique et plus légère peut s'avérer plus rentable qu'un pipeline basé sur des connecteurs.
• Une application avec seulement quelques centaines de chaînes de caractères destinées à l'utilisateur, où le transfert manuel de fichiers peut encore être gérable sans outils automatisés.

Que devez-vous vérifier avant de déployer une version localisée d'une application mobile ?

Les chaînes traduites sont-elles toujours compatibles avec l'interface utilisateur ?
Commencez par pseudolocaliser la version — les paramètres régionaux XA/XB d'Android et la pseudolocalisation propre à Xcode développent et réétiquettent le texte de l'interface utilisateur en anglais — afin que les troncatures et les ruptures de mise en page apparaissent avant qu'un traducteur n'ouvre le fichier.

Chaque fil a-t-il été examiné avec un contexte visuel, et non isolément?
Une chaîne traduite sans voir son écran est une source fréquente d’erreurs aveugles au contexte; associer des captures d’écran ou des enregistrements d’écran à des chaînes via OCR donne aux linguistes l’interface utilisateur réelle à partir de laquelle travailler.

La qualité de la traduction est-elle mesurée ou simplement présumée ?
Faites passer les traductions à travers un schéma d’assurance qualité linguistique avec un score basé sur le MQM, plutôt que de vous fier à la validation subjective d’un seul évaluateur.

Les notifications et les textes de gestion de compte — y compris les textes de désabonnement et du centre de préférences — sont-ils localisés selon les mêmes normes que l'application principale ?
Les notifications push, les courriels transactionnels et les flux de désabonnement sont souvent maintenus en dehors des fichiers principaux de ressources de l’application et sont manqués lors d’un audit de localisation, ce qui crée à la fois un écart de confiance utilisateur et de conformité.

La version a-t-elle été testée sur de vrais appareils avant la soumission?
Lancez la version localisée via Firebase Test Lab ou TestFlight en fonction de la répartition réelle des appareils du marché cible, puisque les tests uniquement sur simulateur manquent les problèmes de rendu de polices et de version du système d’exploitation réels.

La fiche de la boutique d’applications est-elle localisée séparément des chaînes intégrées à l’application?
Une application traduite avec une fiche Google Play ou App Store uniquement en anglais perd l’avantage de conversion de la localisation avant même qu’un utilisateur ne l’ouvre.

Comment Smartling prend-il en charge la localisation des applications mobiles ?

Smartling prend en charge la localisation mobile native directement dans les formats de fichiers qu'une version iOS ou Android utilise déjà — les ressources de chaînes XML Android, les fichiers Stringsdict iOS et ICU MessageFormat pour la pluralisation — de sorte que le contenu traduit est réintégré dans une version sans étape de conversion séparée. Comme les applications natives n’ont pas de HTML pour un outil navigateur, la fonction Contexte visuel de Smartling utilise l’OCR pour faire correspondre les captures d’écran téléchargées ou les vidéos enregistrées à l’écran à la chaîne exacte sur laquelle un traducteur travaille, éliminant ainsi l’incertitude liée à la traduction du texte de l’interface utilisateur sans voir l’écran sur lequel il se trouve.

Pour les équipes qui déploient des versions mobiles via GitHub, GitLab ou Beanstalk, le connecteur de dépôt Smartling — incluant un connecteur GitHub dédié — suit une branche spécifique, transmet automatiquement les chaînes de fichiers de ressources nouvelles ou modifiées et renvoie les traductions terminées, conservant ainsi la localisation dans le même flux de travail de demande d'extraction qu'une équipe d'ingénierie mobile utilise déjà. La qualité de la traduction est évaluée grâce aux outils d'assurance qualité linguistique de Smartling, qui appliquent un schéma basé sur le MQM afin qu'une équipe de localisation puisse se référer à un chiffre de qualité objectif plutôt qu'à l'opinion subjective d'un réviseur.