# General Translation Knowledge Base: Liste de contrôle des tests de localisation pour les applications multilingues URL: https://generaltranslation.com/fr/kb/multilingual-app-launch-checklist.mdx Docs index: https://generaltranslation.com/llms.txt Description: Testez neuf points dans chaque paramètre régional pris en charge sur une compilation de Production : les parcours complets, y compris les états d’erreur et les e-mails, le changement de langue, les formes plurielles, la devise et les fuseaux horaires, le foisonnement du texte, la mise en page right-to-left, l’accessibilité, la distribution des traductions et des URL de langue explorables. Associez à chaque vérification 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 au foisonnement 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. ## Video The video is narrated in English, with English captions. [What should I check before launching a multilingual app?](https://caxecubb9c64cezv.public.blob.vercel-storage.com/films/kb-multilingual-app-launch-checklist.mp4) (33 s) Before launching a multilingual app, test nine things in every supported locale: complete user journeys including errors, language detection and switching, variables and plurals, currency and time zones, text expansion, right-to-left layout, accessibility, production translation delivery, and crawlable language URLs. With General Translation, run gt validate, then `npx gt translate` before the build so new copy ships translated. ## 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. Utilisez des [vérifications de chaînes codées en dur](/kb/find-hardcoded-strings) pour repérer les littéraux en langue source avant la vérification manuelle. **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, les relecteurs corrigent la formulation dans l'[Éditeur de Traduction du tableau de bord](/docs/platform/dashboard/guides/reviewing-translations). Partagez les [termes de glossaire et les instructions personnalisées](/docs/platform/dashboard/guides/defining-context-for-translations) entre vos projets d'application et d'e-mail avant de générer de nouvelles traductions. Les modifications de contexte s'appliquent aux nouvelles traductions ; relisez attentivement les formulations existantes plutôt que de supposer qu'elles ont, elles aussi, été mises à jour. ### 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. Le [guide de détection de la langue](/kb/detect-user-language) traite de la mise en correspondance des préférences ; le [guide du sélecteur de langue](/kb/language-switcher) traite des choix explicites et de la navigation accessible. **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. ### 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. Dans les bibliothèques React de GT, [``](/docs/react/reference/components/plural) sélectionne les formes plurielles propres au paramètre régional, [``](/docs/react/reference/components/branch) conserve les alternatives conditionnelles au sein de l'unité de traduction, et [``](/docs/react/reference/components/var) substitue les valeurs dynamiques localement. Testez chaque alternative, et pas seulement la phrase par défaut ; les valeurs utilisateur encapsulées dans [``](/docs/react/reference/components/var) n'ont pas besoin d'être envoyées à l'API de traduction. **Critère de réussite :** les valeurs restent intactes, la phrase se lit correctement et chaque forme plurielle 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. Pour les messages issus d'un catalogue, testez également les branches de vos [messages ICU](/kb/icu-message-format). (Consultez [Comment gérer les formes plurielles en React ?](/kb/how-to-handle-plurals-in-react) pour une approche fondée sur les composants.) ## 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. Changer la langue de l’IU ne doit modifier ni le montant dû ni le moment où un événement se produit. Les composants [``](/docs/react/reference/components/currency) et [``](/docs/react/reference/components/datetime) de GT appliquent un formatage adapté au paramètre régional, avec des options explicites de devise et de fuseau horaire ; testez ces choix comme vous le feriez pour les appels `Intl` ci-dessus. ### 5. Testez le foisonnement 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](/kb/pseudo-localization) 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. Le [guide de Lingui](https://lingui.dev/guides/pseudolocalization) en présente une mise en œuvre. ### 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. Le [guide CSS RTL](/kb/right-to-left-css) aborde les espacements, les icônes et les valeurs bidirectionnelles. **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. Conservez les informations d’authentification des outils de traduction dans l’environnement de compilation, en dehors des bundles destinés au navigateur. Avec GT, exécutez [`gt validate`](/docs/cli/reference/commands/validate), puis [`gt translate`](/docs/cli/reference/commands/translate) avant la compilation. Vous pouvez configurer la compilation pour qu’elle s’interrompe en cas d’échec des traductions. [`gt generate`](/docs/cli/reference/commands/generate) se contente d’écrire les modèles source. Si des relecteurs modifient la sortie locale, utilisez [`gt save-local`](/docs/cli/reference/commands/save-local) pour conserver ces modifications lors des exécutions suivantes. Testez le mode de mise à jour que vous avez configuré : [Locadex](/docs/platform/locadex/guides/configuring-automations) doit créer ou mettre à jour sa pull request de traduction lorsque vous actionnez le déclencheur configuré (push, pull request ou manuel). Vérifiez que la branche prévue est bien suivie. Avec les [traductions incluses dans le bundle](/docs/react/guides/storing-translations), l’application déployée peut afficher les fichiers fournis indépendamment du service de GT. Avec la livraison par CDN, testez les modifications publiées en fonction de votre version et de vos paramètres de cache, y compris le délai éventuel avant qu’elles ne parviennent aux utilisateurs. ### 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](/kb/what-is-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 ; [le guide sur la structure des URL](/kb/multilingual-url-structure) les compare. 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 (voir [redirections linguistiques et SEO](/kb/locale-routing-seo)). 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. Le [Report Card](https://generaltranslation.com/report-card) gratuit de GT permet une première évaluation de la localisation d’un site public ; il ne peut toutefois ni inspecter les parcours authentifiés ni déclencher délibérément vos scénarios d’échec. ## 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é. Voici à quoi pourrait ressembler un registre rempli : | Compilation | Paramètre régional | Vérification | Appareil | Attendu | Obtenu | Résultat | | ---------------- | ------------------ | ---------------------------------- | ------------------ | ---------------------------------------------------------------- | ------------------------------------------------------ | ------------------------------------------------ | | 4.12.0 (a1b2c3d) | `de` | 1. Carte refusée lors du paiement | Chrome, ordinateur | Erreur en allemand avec option pour réessayer | Erreur en allemand, libellé du bouton tronqué à 320 px | Échec : bloque la livraison, responsable désigné | | 4.12.0 (a1b2c3d) | `pl` | 3. Panier avec 2, 5 et 22 articles | Safari, iPhone | Formes polonaises « few » et « many » | Forme `few` affichée pour 5 articles | Échec : corriger les clés de pluriel | | 4.12.0 (a1b2c3d) | `ar` | 6. Paramètres du compte | Chrome, Android | Mise en page en miroir, flèche de retour orientée vers la droite | Conforme | Réussite | ## Related questions - [Comment trouver les chaînes codées en dur qui ne sont pas traduites ?](https://generaltranslation.com/fr/kb/find-hardcoded-strings.mdx): Exécutez dans votre CI un linter qui signale les littéraux de chaîne de caractères visibles par l’utilisateur, comme la règle no-literal-string d’eslint-plugin-i18next pour JSX, la vérification HardcodedText d’Android Lint ou le linter HardCodedString d’erb_lint pour Rails. Parcourez ensuite l’application avec un pseudo-paramètre régional pour repérer le texte que les vérifications statiques ne peuvent pas détecter. - [Bonnes pratiques pour le sélecteur de langue : UX, SEO et accessibilité](https://generaltranslation.com/fr/kb/language-switcher.mdx): Affichez chaque langue sous son propre nom, comme Deutsch ou 日本語, et bannissez les drapeaux, qui représentent des pays. Faites pointer chaque option vers la même page dans cette langue grâce à un lien explorable par les robots, mémorisez le choix dans un cookie et ne redirigez jamais automatiquement une URL localisée. - [Qu’est-ce que la pseudo-localisation ?](https://generaltranslation.com/fr/kb/pseudo-localization.mdx): La pseudo-localisation est un test qui remplace votre texte source par une version modifiée, accentuée, allongée d’environ 40 % et encadrée de crochets, afin de faire apparaître les chaînes codées en dur, les troncatures, les polices défaillantes et les phrases concaténées avant même qu’une traduction n’existe. Android propose à cet effet les pseudo-paramètres régionaux en-XA et ar-XB. - [Comment prendre en charge les langues RTL (right-to-left) en CSS ?](https://generaltranslation.com/fr/kb/right-to-left-css.mdx): Placez dir="rtl" et lang sur l’élément html, car lang seul ne modifie pas le sens d’écriture, puis remplacez les propriétés CSS physiques comme margin-left par des propriétés logiques comme margin-inline-start. Les lignes flex, les colonnes de grille et l’alignement du texte par défaut s’inversent automatiquement ; ce n’est pas le cas de translateX(), left et right. - [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 préfixée, comme /en/about et /es/about, puis publiez html lang, une URL canonique autoréférente, des variantes localisées hreflang avec x-default, un titre et une description traduits, ainsi qu’une entrée de plan de site pour chaque langue publiée. Marquez les versions non publiées en noindex. Le package gt-next de General Translation associe chaque langue à sa propre URL et traduit les titres avec getGT. ## Previous and next questions - Previous question: [General Translation vs i18next, react-intl et next-intl : quelle bibliothèque d’i18n choisir ?](https://generaltranslation.com/fr/kb/general-translation-vs-i18n-libraries.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.