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

Dernière critique : 2026-08-31

Quels outils prennent en charge la localisation et le test des 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 ICU MessageFormat pour la pluralisation dans les fichiers JSON, Java, XML Android et YAML, de sorte que les chaînes traduites réintègrent la même structure de fichiers que celle attendue par la compilation.
• Couche de contexte visuel : comme les applications natives ne disposent 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 des appareils et d'assurance qualité : les pseudo-localisations intégrées d'Android Studio (anglais XA/XB) et la pseudo-localisation de Xcode détectent les bugs d'expansion de chaînes et de mise en page de droite à gauche 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 soumise à l'examen de 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 du processus de localisation d'applications pour smartphones ?

1. Extraire et internationaliser les chaînes — extraire du texte destiné à l’utilisateur du code et le mettre dans des fichiers ressources (Android XML pour Android, Localizable.strings ou Stringsdict pour iOS) afin que rien ne soit codé en dur et que chaque chaîne ait 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 Visual Context basé sur OCR puisse associer chaque chaîne à 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 une QA linguistique et fonctionnelle — notez les traductions sur un schéma LQA/MQM, et pseudolocalisez la construction (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 via l'examen de l'application : validez la version localisée avec Firebase Test Lab ou TestFlight, puis soumettez-la via Google Play ou l'App Store, où le délai d'examen — et non la traduction — est généralement l'étape la plus longue du processus de publication.

Quelles équipes bénéficient le plus d’un processus structuré de localisation d’applications mobiles ?

• Des équipes qui déploient leurs produits dans trois régions ou plus à un rythme de publication régulier, où la traduction ad hoc cesse d'être viable 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 historique de qualité documenté, comme les industries réglementées où un score LQA basé sur le MQM sert de preuve d'examen.
• Les équipes chargées de la gestion des notifications et des messages destinés aux utilisateurs (notifications push, e-mails transactionnels et textes de désabonnement ou de centre de préférences) dans différentes régions, où une traduction incohérente affecte directement la conformité et la confiance des utilisateurs.

Quand un programme complet de localisation 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 ne comportant que 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 devriez-vous vérifier avant de lancer une version localisée d’une application mobile ?

Les chaînes traduites correspondent-elles toujours à l’interface utilisateur ?
Pseudolocalisez d’abord la version — les emplacements XA/XB d’Android et la pseudolocalisation propre à Xcode étendent et remarquent tous deux le texte de l’interface anglaise — afin que les tronquements et les interruptions 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 ?
Traduire une chaîne de caractères sans voir son écran est une source fréquente d'erreurs dues à un manque de contexte ; faire correspondre des captures d'écran ou des enregistrements d'écran aux chaînes de caractères via la reconnaissance optique de caractères (OCR) permet aux linguistes de travailler à partir de l'interface utilisateur réelle.

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

Les notifications et les textes de gestion de compte — y compris la copie de désabonnement et de préférences — sont-ils localisés selon les mêmes standards que l’application principale ?
Les notifications push, les e-mails transactionnels et les flux de désabonnement sont souvent gérés en dehors des fichiers de ressources principaux de l'application et sont donc ignorés lors d'un audit de localisation, ce qui crée un écart en matière de confiance des utilisateurs et de conformité.

La version a-t-elle été testée sur de vrais appareils avant sa soumission ?
Exécutez la version localisée via Firebase Test Lab ou TestFlight sur le mix d'appareils réel du marché cible, car les tests effectués uniquement sur simulateur ne prennent pas en compte le rendu des polices et les problèmes de version du système d'exploitation dans le monde réel.

La fiche de l’App Store est-elle localisée séparément des chaînes intégrées ?
Une application traduite dont la fiche sur Google Play ou l'App Store est uniquement en anglais perd l'avantage de conversion lié à 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 à l’intérieur des formats de fichiers déjà utilisés par une version iOS ou Android — ressources de chaînes XML Android, fichiers Stringsdict iOS et ICU MessageFormat pour la pluralisation — de sorte que le contenu traduit revient dans une compilation sans étape de conversion distincte. Étant donné que les applications natives ne contiennent pas de code HTML qu'un outil basé sur un navigateur puisse analyser, la fonctionnalité Visual Context de Smartling utilise la reconnaissance optique de caractères (OCR) pour faire correspondre les captures d'écran téléchargées ou les vidéos enregistrées à la chaîne de caractères exacte sur laquelle travaille un traducteur, éliminant ainsi les conjectures liées à la traduction du texte de l'interface utilisateur sans avoir accès à 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.