Gérer plusieurs langues dans son app

Flutter gère la localisation via le package officiel intl et les fichiers ARB. ARB, pour Application Resource Bundle, est un format JSON simple où chaque clé correspond à une chaîne traduite, et vous gardez un fichier par langue, comme app_en.arb et app_fr.arb. Vous activez la génération de code dans votre pubspec pour que Flutter construise une classe de messages typée à partir de ces fichiers, puis vous lisez les chaînes via AppLocalizations.of(context) au lieu de les coder en dur. Le framework choisit le bon fichier ARB selon la langue de l'appareil, et MaterialApp expose une liste supportedLocales ainsi que des delegates de localisation qui traduisent aussi les widgets intégrés comme les sélecteurs de date. Le flux de travail : extraire chaque chaîne dans votre ARB modèle, traduire les copies, régénérer, puis référencer les getters générés dans vos widgets.

1. Ajoutez flutter_localizations et intl à pubspec.yaml, et activez generate: true dans la section flutter.
2. Créez un fichier modèle comme lib/l10n/app_en.arb avec vos chaînes sources et leurs descriptions.
3. Ajoutez un fichier ARB par langue cible, en gardant les mêmes clés avec des valeurs traduites.
4. Branchez supportedLocales et localizationsDelegates dans votre MaterialApp pour que Flutter résolve la langue de l'appareil.
5. Remplacez le texte codé en dur par les getters AppLocalizations.of(context) et recompilez.

React Native n'a pas de couche de localisation intégrée, donc la pile classique est i18next avec react-i18next, associée à un détecteur de langue. Vous stockez les traductions sous forme de namespaces JSON, un objet par langue, et vous enveloppez votre app dans un I18nextProvider. Les composants lisent alors le texte via le hook useTranslation et un appel t('key'). Pour détecter la langue de l'appareil, vous ajoutez une petite librairie comme react-native-localize, qui remonte les langues préférées et la région pour choisir un défaut cohérent et se rabattre proprement quand une traduction manque. i18next gère nativement la pluralisation et l'interpolation, ce qui vous évite d'écrire cette logique à la main. Le modèle mental est identique à Flutter : les chaînes vivent dans des fichiers de données, le code référence des clés, et la langue active décide quel fichier l'emporte.

• i18next et react-i18next pour le stockage des traductions et le hook useTranslation.
• react-native-localize pour lire les langues préférées et la région de l'appareil.
• Un fichier JSON par langue, idéalement découpé en namespaces par fonctionnalité pour garder des fichiers courts.
• Un gestionnaire de clé manquante qui retombe sur votre langue par défaut au lieu d'afficher une clé brute.

Ce sont les détails qui séparent une app traduite d'une app vraiment localisée. Les règles de pluriel varient selon la langue : l'anglais a deux formes, mais le polonais et l'arabe en ont plusieurs, donc vous devez utiliser la syntaxe de pluriel de votre librairie plutôt qu'un if-else sur un compteur. Dates et nombres varient aussi, où 1,000.50 aux États-Unis devient 1 000,50 dans une grande partie de l'Europe, et les formats de date inversent l'ordre du jour et du mois. intl dans Flutter et Intl en JavaScript les formatent correctement à partir de la langue, alors ne les formatez jamais à la main. Les langues de droite à gauche comme l'arabe et l'hébreu exigent que toute la mise en page soit inversée, pas seulement le texte. Flutter le fait automatiquement quand vous réglez la direction du texte selon la langue, et React Native expose I18nManager pour la même chose. Testez le sens droite à gauche tôt, car rattraper une mise en page inversée tard est pénible.

Les fichiers de traduction pourrissent vite quand une équipe grandit, donc un peu de structure paie. L'objectif : n'importe quel développeur peut ajouter une chaîne, n'importe quel traducteur peut la trouver, et aucune clé ne part vide. Quelques habitudes gardent le tout propre, sur Flutter comme sur React Native.

• Gardez une langue source de vérité, souvent l'anglais, et traitez chaque autre fichier comme sa traduction.
• Découpez les chaînes en namespaces ou fichiers par fonctionnalité, pour qu'un écran de paiement ne vive pas dans le même fichier de 4 000 lignes que l'onboarding.
• Ajoutez une description ou un commentaire à chaque clé pour donner le contexte, car « Ouvrir » peut être un verbe ou un adjectif.
• Ajoutez une étape de lint en CI qui casse le build quand une langue manque une clé présente dans le fichier source.
• Ne laissez jamais un développeur écrire le texte final en dur. Ajoutez d'abord la clé, puis remplissez les traductions, pour que rien ne contourne le pipeline.

Une fois que l'app parle plusieurs langues, la page du store doit le faire aussi, et c'est là que beaucoup d'installations se gagnent ou se perdent. L'App Store d'Apple comme Google Play permettent d'ajouter une localisation par langue, chacune avec son titre, son sous-titre ou sa description courte, sa description longue, son champ de mots-clés et son propre jeu de captures d'écran. Un visiteur qui parcourt le store en français voit votre fiche française, et si vous n'en avez pas créé, il voit votre langue par défaut. Ce décalage tue discrètement la conversion, car quelqu'un qui ne peut pas lire vos captures installe rarement. Localiser la fiche, c'est trois choses : traduire les métadonnées, adapter les mots-clés à la façon dont les gens cherchent vraiment dans cette langue, et localiser les captures pour que légendes et texte à l'écran correspondent. Pas besoin de localiser tous les marchés d'un coup, mais chaque marché où vous entrez mérite les trois.

Les métadonnées et les visuels sont deux tâches distinctes. Pour les mots, notre guide sur comment générer les métadonnées de l'App Store couvre l'écriture de titres, sous-titres et descriptions qui respectent les limites de caractères de chaque store. Pour les images, créer des visuels du store facilement montre comment produire des jeux de captures localisés sans un designer par langue. Traitez les deux en paire, car une description traduite au-dessus de captures en anglais fait inachevé, et les relecteurs le remarquent.

Il ne faut pas localiser dans toutes les langues d'un coup, car chacune ajoute de l'entretien continu pour les traductions, les captures et le support. Priorisez en pesant deux forces l'une contre l'autre : la taille du marché et la concurrence. La taille, c'est combien d'utilisateurs potentiels et de revenus une langue débloque, où l'anglais, l'espagnol, le portugais du Brésil, le japonais, l'allemand, le français et le chinois simplifié couvrent une grande part des dépenses mondiales sur les apps. La concurrence, c'est la difficulté à se classer dans le store de cette langue, et un marché plus petit avec des concurrents localisés faibles peut mieux convertir qu'un marché immense déjà saturé. Regardez où vous obtenez déjà des téléchargements organiques avec une fiche en anglais, car ces pays vous disent que la demande existe avant même d'avoir dépensé un centime en traduction.

• Commencez par les langues qui apparaissent déjà dans vos analytics d'installation, car la demande est prouvée.
• Ajoutez des marchés à forte dépense où votre catégorie n'est pas déjà dominée par des acteurs localisés.
• Préférez les langues qui débloquent plusieurs pays d'un coup, comme l'espagnol ou l'arabe, pour l'effet de levier.
• Dépriorisez une langue si vous ne pouvez pas en supporter les utilisateurs, car des installations que vous ne servez pas partent vite.

Une fiche localisée aide deux fois, une fois dans l'algorithme et une fois auprès de l'humain. Côté classement, les deux stores indexent vos champs de mots-clés localisés, donc un jeu de mots-clés en français vous rend visible sur des recherches françaises pour lesquelles vous ne vous classeriez jamais avec une fiche en anglais. Traduire machinalement vos mots-clés anglais rate tout cela, car les mots que les gens tapent en français sont rarement la traduction littérale des anglais. Côté conversion, un visiteur qui lit votre titre, votre description et vos captures dans sa langue fait plus confiance à l'app et installe plus souvent que celui qui plisse les yeux sur une fiche étrangère. Voilà pourquoi un vrai ASO par langue bat une simple traduction automatique : vous recherchez les vrais termes de recherche pour chaque langue, puis vous écrivez les métadonnées autour. L'effet se cumule, car un meilleur taux d'installation nourrit à son tour le classement. Pour la mécanique de l'ASO par store, voyez notre guide sur comment améliorer l'ASO dans App Store Connect, et pour transformer ce trafic en installations, améliorer la conversion de la fiche.

La traduction automatique fait un bon brouillon mais une mauvaise fiche finale. Elle gère correctement les phrases descriptives, mais échoue sur les deux choses qui comptent le plus pour le store : les mots-clés et le ton. Les termes de recherche correspondent rarement à la traduction littérale, et le texte automatique sonne souvent un peu faux pour un natif, ce qui érode la confiance. Utilisez-la pour une première passe, puis faites ajuster les mots-clés et polir la formulation par un locuteur natif avant de publier.

Oui, et fortement. Chaque localisation ajoutée donne au store un nouveau champ de mots-clés à indexer, donc vous devenez trouvable sur des recherches dans cette langue pour lesquelles votre fiche par défaut ne se classerait jamais. Sur l'App Store, les localisations permettent même de cibler des jeux de mots-clés supplémentaires qui peuvent aider sur des marchés proches. Ajouter une langue est l'un des leviers d'ASO les plus puissants disponibles, à condition de rechercher les mots-clés plutôt que de les traduire littéralement.

La plupart des nouvelles apps devraient sortir avec une à trois langues, pas dix. Commencez par votre marché principal et toute langue qui apparaît déjà dans vos premières données d'installation, puis élargissez à mesure que vous confirmez la demande et pouvez supporter les utilisateurs. Localiser trop de langues au lancement disperse vos captures, vos métadonnées et votre support, et des localisations à moitié entretenues font pire qu'une fiche propre en une seule langue. Allongez la liste délibérément, un marché à la fois.

Localisez les deux, car les captures pèsent plus dans la décision d'installer que la description. Un visiteur survole d'abord les images, donc des légendes dans sa langue et un texte à l'écran localisé donnent l'impression d'une app pensée pour lui. Laisser des captures en anglais sous une description traduite est la localisation à moitié faite la plus courante, et elle abaisse visiblement la conversion. Si vous ne pouvez bien localiser qu'un seul élément, faites-en les captures, puis traduisez les métadonnées autour.