# General Translation Knowledge Base: Que faut-il vérifier avant de lancer une application multilingue ? URL: https://generaltranslation.com/fr/kb/multilingual-app-launch-checklist.mdx Docs index: https://generaltranslation.com/llms.txt Description: Avant de lancer une application multilingue, testez neuf points dans chaque paramètre régional pris en charge : les parcours utilisateur complets, erreurs comprises, la détection de la langue et le changement de langue, les variables et les formes plurielles, la devise et les fuseaux horaires, l’expansion du texte, la mise en page right-to-left, l’accessibilité, la distribution des traductions en Production et des URL de langue explorables pour le SEO. Chaque vérification doit s’accompagner d’un critère de réussite explicite. Category: Internationalisation Last updated: 2026-10-16 Authors: Jackie Chen Published: 2026-10-16 Une page d’accueil traduite peut sembler terminée alors que le paiement, les messages d’erreur de validation ou le parcours de réinitialisation du mot de passe restent dans la langue source. Commencez par les parcours que l’utilisateur doit pouvoir mener à bien, et testez-les sur la compilation de Production. Avant de lancer une application web multilingue, vérifiez ces neuf points dans chaque paramètre régional pris en charge : 1. **Les parcours sont entièrement traduits**, y compris les états de chargement, vides et d’erreur, les e-mails et les notifications. 2. **La sélection de la langue est cohérente** lors de la première visite, après un changement de langue et lors des visites suivantes. 3. **Les variables et les formes plurielles sont correctes** pour chaque catégorie de pluriel utilisée par vos langues. 4. **La devise et le fuseau horaire sont définis explicitement**, indépendamment de la langue de l’IU. 5. **Les mises en page résistent à l’expansion du texte** sur les écrans étroits et avec le zoom du navigateur. 6. **Les langues right-to-left** ont le bon sens d’écriture, une mise en page adaptée et un texte bidirectionnel correct. 7. **Les technologies d’assistance reçoivent la bonne langue**, ainsi que des étiquettes et des noms accessibles corrects. 8. **La compilation de Production contient des traductions complètes**, et les nouveaux textes sont traduits avant la livraison. 9. **Les pages publiques disposent d’URL de langue explorables**, avec des métadonnées traduites et des balises `hreflang`. Testez le contenu dans chaque paramètre régional pris en charge, ainsi que la mise en page et les interactions sur un échantillon représentatif d’appareils et de navigateurs. Le point 9 ne concerne que les pages publiques que vous souhaitez faire indexer. ## Vérifier le contenu et le comportement selon la langue ### 1. Traduisez l'intégralité du parcours, y compris les états d'échec Choisissez un parcours critique, comme la création d'un compte ou la finalisation d'un achat. Testez ses états de chargement, vide, de réussite et d'erreur. Vérifiez les boutons, les boîtes de dialogue, la validation des formulaires, les espaces réservés, les libellés d'accessibilité, ainsi que tout e-mail ou toute notification envoyés au cours du parcours. **Critère de réussite :** chaque interface affiche du contenu relu dans la langue cible, à l'exception de cas voulus comme un nom de produit. Aucune clé brute, aucun marqueur de message manquant ni aucun contenu de secours injustifié en langue source n'apparaît. **Avec General Translation :** vérifiez que la sortie de [`gt translate`](/docs/cli/reference/commands/translate) correspond bien à la version incluse dans la livraison. ([`gt generate`](/docs/cli/reference/commands/generate) se contente d'écrire des modèles source, qu'il reste à compléter avec le texte traduit.) Les relecteurs corrigent la formulation dans l'[Éditeur de Traduction du tableau de bord](/docs/platform/dashboard/guides/reviewing-translations) ; si votre équipe modifie plutôt les fichiers générés directement dans le dépôt, exécutez [`gt save-local`](/docs/cli/reference/commands/save-local) afin que les exécutions suivantes conservent ces modifications. Pour garantir la cohérence des termes produit dans votre application, votre documentation et vos notifications, attribuez des termes de glossaire et des instructions personnalisées partagés à l'aide des [groupes de contexte](/docs/platform/dashboard/guides/defining-context-for-translations) avant de générer les traductions. Les modifications de contexte s'appliquent aux nouvelles traductions ; elles ne réécrivent pas les traductions existantes. ### 2. Vérifier les premières visites, le changement de langue et les visites suivantes Testez avec un navigateur vierge, un choix de langue explicite, un rechargement, un lien profond et une langue de navigateur non prise en charge. Si l'application enregistre une préférence de langue au niveau du compte, testez également la connexion et la déconnexion. Notez quel réglage l'emporte lorsque l'URL, la préférence enregistrée et le navigateur divergent. **Critère de réussite :** L'application applique cette règle de manière cohérente, et l'utilisateur peut revenir sur un choix de langue non souhaité. Pour les applications server-rendered, inspectez à la fois la réponse initiale et la page hydratée. Les identifiants de paramètres régionaux suivent la norme BCP 47 : `es-MX` et `es-AR` peuvent constituer des cibles distinctes pour l'espagnol du Mexique et l'espagnol d'Argentine. Testez chaque cible régionale que vous livrez. Un sélecteur basé sur un cookie et des routes préfixées par le paramètre régional répondent à des besoins différents ; vérifiez le comportement réel des URL de l'application. **Avec General Translation :** Définissez les langues prises en charge, y compris les cibles régionales, dans votre [configuration des paramètres régionaux](/docs/react/guides/managing-locales). ### 3. Tester les variables et les catégories de pluriel Testez des quantités comme 0, 1, 2 et des valeurs plus élevées, puis ajoutez des cas couvrant les catégories de pluriel de vos langues cibles. Incluez des noms contenant de la ponctuation, des noms de compte longs et des phrases dont les variables peuvent changer d'ordre une fois traduites. Évitez de construire une phrase en concaténant des fragments traduits séparément. **Critère de réussite :** les valeurs restent intactes, la phrase se lit correctement et chaque forme du pluriel requise dispose d'un contenu exploitable. Les [règles de pluriel](https://cldr.unicode.org/index/cldr-spec/plural-rules) d'Unicode expliquent pourquoi une simple paire de tests singulier/pluriel en anglais ne suffit pas. **Avec General Translation :** [``](/docs/react/reference/components/plural) applique les règles de pluriel du paramètre régional : l'anglais possède deux catégories cardinales, l'arabe en compte six. Utilisez [``](/docs/react/reference/components/branch) lorsque la formulation dépend d'une valeur explicite, comme le genre grammatical d'une personne, et [``](/docs/react/reference/components/var) pour du texte dynamique, comme un nom. Les valeurs encapsulées dans ce composant de variable ne sont pas envoyées à l'API de traduction. L'[article sur la pluralisation en React](/kb/how-to-handle-plurals-in-react) détaille l'approche à suivre pour l'implémentation. ## Vérifier le formatage, la mise en page et l'accessibilité ### 4. Distinguer la langue, la devise et le fuseau horaire Testez un même montant et un même instant avec plusieurs paramètres régionaux. Définissez explicitement la devise et le fuseau horaire voulus lorsque votre produit l'exige. La préférence linguistique ne suffit pas, à elle seule, à déterminer la devise dans laquelle un client paie ni le fuseau horaire d'un rendez-vous. Par exemple, le code suivant formate un montant existant en USD selon les conventions allemandes : ```js new Intl.NumberFormat('de-DE', { style: 'currency', currency: 'USD', }).format(1234.5); ``` Il formate le montant fourni sans effectuer de conversion de devises. Le formatage peut arrondir les chiffres affichés : vérifiez donc la précision dont votre produit a besoin. De même, indiquez un fuseau horaire explicite pour afficher un instant dans un lieu donné : ```js new Intl.DateTimeFormat('en-GB', { dateStyle: 'medium', timeStyle: 'short', timeZone: 'Europe/Paris', }).format(new Date('2026-01-15T12:00:00Z')); ``` **Condition de réussite :** les séparateurs, la devise concernée, la date calendaire et l’heure affichée correspondent au sens voulu par le produit. Incluez un passage à l’heure d’été ou d’hiver lorsque les fuseaux horaires que vous prenez en charge en appliquent un. Les API de [nombres](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/NumberFormat) et de [dates](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat) exposent ces choix séparément. **Avec General Translation :** [``](/docs/react/reference/components/currency), [``](/docs/react/reference/components/datetime) et [``](/docs/react/reference/components/num) formatent les valeurs selon la locale active. Définissez la devise et le fuseau horaire en fonction de la signification métier voulue : changer la langue de l’IU ne doit modifier ni le montant dû ni le moment où un événement se produit. ### 5. Testez l'expansion du texte sur différentes tailles d'écran Ouvrez les écrans traduits sur des fenêtres d'affichage étroites et avec le zoom du navigateur. Vérifiez la navigation, les boutons, les tableaux, les boîtes de dialogue et les messages de validation. Testez de longues chaînes traduites et de longues valeurs saisies par les utilisateurs : un titre court ne sollicite pas la mise en page de la même façon qu'une adresse complète. **Critère de réussite :** le texte essentiel reste lisible et les commandes restent utilisables. Aucune action ne disparaît derrière du texte tronqué ou des éléments qui se chevauchent. Appliquez la troncature de manière réfléchie plutôt que de l'utiliser pour masquer systématiquement tout débordement. La [pseudo-localisation](https://lingui.dev/guides/pseudolocalization) permet de détecter les problèmes de mise en page et les chaînes non balisées avant même que les traductions soient prêtes. Elle complète les tests en langues réelles, mais ne garantit pas la qualité de la traduction. ### 6. Tester le contenu right-to-left comme une exigence de mise en page Si vous prenez en charge l’arabe, l’hébreu ou une autre langue right-to-left, testez le sens du document, l’ordre de navigation, les formulaires et les contenus bidirectionnels, comme les adresses e-mail et les identifiants de commande. Utilisez les propriétés CSS logiques lorsque la mise en page doit suivre le sens du texte, et vérifiez les icônes directionnelles au cas par cas. **Critère de réussite :** la mise en page respecte le sens de lecture prévu, et les valeurs left-to-right intégrées restent lisibles. Définir un code de langue ne suffit pas à définir le sens du texte ; suivez les [recommandations du W3C sur la directionnalité en HTML](https://www.w3.org/International/questions/qa-html-dir). ### 7. Vérifier la langue transmise aux technologies d'assistance Vérifiez l'attribut `lang` de la page, les changements de langue au sein du contenu le cas échéant, les étiquettes visibles, les noms accessibles et le texte alternatif. Testez la navigation au clavier et un lecteur d'écran sur le parcours principal. Un espace réservé traduit ne remplace pas une étiquette de formulaire permanente. **Critère de réussite :** le document déclare la bonne langue, les contrôles disposent de noms localisés explicites et la mise en page traduite reste fonctionnelle. Le W3C présente les [déclarations de langue](https://www.w3.org/International/questions/qa-html-language-declarations), et ses [recommandations sur les étiquettes de formulaire](https://www.w3.org/WAI/tutorials/forms/labels/) expliquent comment associer les étiquettes aux champs. ## Vérifier la livraison que recevront les utilisateurs ### 8. Vérifier les ressources de production et les mises à jour des traductions Effectuez une compilation à partir d’un checkout propre en suivant le processus de livraison, puis exécutez cette compilation avec chaque paramètre régional pris en charge. Vérifiez que les ressources de traduction sont présentes et se chargent correctement. Modifiez un message source dans une branche de test et vérifiez que le pipeline de traduction détecte la modification avant la prochaine livraison. **Critère de réussite :** l’application sert les traductions prévues sans dépendre de fichiers résiduels de la phase de développement. Des ressources manquantes ou un échec de génération entraînent une erreur visible ou un contenu de secours explicitement accepté, et non une livraison partielle passée inaperçue. **Avec General Translation :** exécutez [`gt validate`](/docs/cli/reference/commands/validate) pour détecter les erreurs de traduction intégrée prises en charge avant tout appel d’API, puis placez l’[étape de traduction incrémentale avant la compilation](/docs/cli/guides/generating-translations). Elle réutilise les traductions existantes et ne traduit que le contenu modifié : les nouveaux textes peuvent ainsi être livrés traduits dès la livraison qui les introduit. Le [suivi des branches](/docs/cli/guides/branching) permet de garder séparées les branches de développement parallèles. Les [automatisations Locadex](/docs/platform/locadex/guides/configuring-automations) peuvent gérer les mises à jour des traductions via des pull requests. Dans le cadre de cette vérification de livraison, testez le déclencheur configuré en modifiant un texte source. Avec le [workflow de stockage local](/docs/react/guides/storing-translations), l’application sert les traductions intégrées au bundle sans appeler General Translation à l’exécution ; les mises à jour sont livrées avec une nouvelle compilation. Avec la livraison par CDN, les modifications publiées peuvent parvenir à l’application sans redéploiement, en fonction de sa version de traduction et de ses paramètres de cache. Testez ce mode de mise à jour. Conservez les informations d’authentification privées des outils de traduction dans l’environnement de compilation, en dehors des bundles destinés au navigateur. ### 9. Vérifier la découvrabilité des versions linguistiques publiques Pour les pages destinées à être référencées, vérifiez que chaque version linguistique dispose d’une URL explorable, de titres et de descriptions traduits, de l’URL canonique prévue et de variantes localisées valides. Vérifiez que les références `hreflang` sont réciproques, y compris celle vers la page elle-même. Si les variantes localisées sont déclarées dans un sitemap, vérifiez qu’il reflète les mêmes relations entre les pages. **Condition de réussite :** chaque URL linguistique publique charge le contenu attendu, est indexable lorsque c’est souhaité et pointe vers des versions alternatives qui existent réellement. Les [recommandations de Google sur les pages localisées](https://developers.google.com/search/docs/specialty/international/localized-versions) décrivent les méthodes d’annotation prises en charge. Pour une implémentation Next.js, consultez le [guide SEO multilingue](/kb/multilingual-nextjs-seo). Les préfixes de chemin, les sous-domaines linguistiques et les domaines nationaux permettent tous de fournir des URL distinctes par langue. Un en-tête `Accept-Language` ou un cookie peut servir à sélectionner la langue d’un visiteur, mais ne crée pas à lui seul une URL explorable pour chaque version. Les [recommandations de Google sur les sites multilingues](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites) préconisent des URL distinctes. Un tableau de bord accessible après authentification n’a pas forcément besoin d’URL linguistiques indexées ; choisissez la stratégie de routage adaptée à l’audience du produit. ## Tenir un registre de livraison Consignez la compilation, le paramètre régional, le parcours, le navigateur ou l'appareil, le résultat attendu, le résultat obtenu et le relecteur. Désignez un responsable pour chaque échec. Ne traitez pas une traduction manquante dans le tunnel de paiement ou une action principale illisible comme une simple préférence de formulation, et documentez explicitement tout contenu de secours accepté. Pour une première vérification rapide d'un site public, le [Report Card](https://generaltranslation.com/report-card) gratuit de General Translation évalue sa localisation. Comme il n'a pas accès aux parcours authentifiés ni aux états d'erreur, complétez-le par les vérifications de parcours décrites ci-dessus. ## Questions fréquentes ### Comment tester une application multilingue ? Exécutez des parcours utilisateur complets dans chaque paramètre régional pris en charge sur une compilation de production, en incluant les états d'erreur, les e-mails et les notifications. Vérifiez les formes plurielles, les variables, les devises, les fuseaux horaires, la mise en page, le texte right-to-left et l'accessibilité, et consignez un critère de réussite pour chaque vérification. ### Quel est le bug de localisation le plus souvent oublié ? Les états d'échec non traduits. Les messages d'erreur, la validation des formulaires, les états vides et les e-mails transactionnels restent souvent dans la langue source, même une fois les écrans principaux traduits. Testez-les spécifiquement lors de la vérification 1. ### Qu'est-ce que la pseudo-localisation ? La pseudo-localisation remplace le texte source par un texte d'espace réservé plus long et accentué, ce qui permet de repérer les débordements de mise en page et les chaînes non balisées avant même que les vraies traductions soient disponibles. Elle ne dispense pas de tester avec de vraies langues. Consultez le [guide de pseudo-localisation de Lingui](https://lingui.dev/guides/pseudolocalization). ### Les pages multilingues ont-elles besoin d'URL distinctes pour le SEO ? Oui, pour les pages que vous souhaitez faire indexer. Google recommande une [URL distincte pour chaque version linguistique](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites), reliées entre elles par `hreflang`. Un cookie ou un en-tête `Accept-Language` ne suffit pas, à lui seul, à créer des versions explorables par les robots. Pour Next.js, consultez [SEO multilingue avec Next.js](/kb/multilingual-nextjs-seo). ## Related questions - [Quelle est la meilleure bibliothèque d’i18n pour une application React ?](https://generaltranslation.com/fr/kb/best-react-i18n-library.mdx): Les quatre principales bibliothèques d’i18n pour React sont gt-react de General Translation, react-i18next, Lingui et React Intl. Toutes les quatre affichent et formatent les traductions, mais seule gt-react les génère aussi, à partir du texte intégré directement dans votre JSX. Choisissez react-i18next pour conserver vos catalogues et plugins i18next, Lingui pour l’extraction vers des catalogues compilés, et React Intl pour FormatJS et ICU MessageFormat. - [Peut-on faire de l’i18n sans fichiers de traduction ?](https://generaltranslation.com/fr/kb/i18n-without-translation-files.mdx): Oui. Avec gt-react ou gt-next, le contenu reste intégré dans vos composants, à l’intérieur d’un composant ``, et les traductions sont générées lors du build. Il n’y a donc ni clés ni fichiers JSON par paramètre régional à écrire et à garder synchronisés. - [Comment gérer les formes plurielles dans React ?](https://generaltranslation.com/fr/kb/how-to-handle-plurals-in-react.mdx): Ne codez pas en dur la logique de pluralisation avec des tests comme n === 1. Un petit utilitaire suffit pour une application uniquement en anglais, mais une application multilingue a besoin de règles de pluriel adaptées au paramètre régional, que prend en charge pour chaque langue un composant i18n tel que `` de gt-react ou gt-next. - [Comment configurer le SEO d’une application Next.js multilingue ?](https://generaltranslation.com/fr/kb/multilingual-nextjs-seo.mdx): Attribuez à chaque langue sa propre URL, définissez l’attribut lang de la balise html, faites pointer l’URL canonique de chaque page vers elle-même, ajoutez des variantes localisées hreflang pour chaque langue, traduisez les titres et les descriptions, et listez toutes les versions linguistiques dans votre sitemap. ## Previous and next questions - Previous question: [Pourquoi utiliser General Translation plutôt qu’un TMS (Smartling, Lokalise, Phrase, Crowdin ou Transifex) ?](https://generaltranslation.com/fr/kb/general-translation-vs-tms.mdx) - Next question: [Quelle est la meilleure bibliothèque d’i18n pour une application React ?](https://generaltranslation.com/fr/kb/best-react-i18n-library.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/fr/kb/sitemap.md) for every article.