Messages automatiques multilingues : tester le bon texte pour le bon événement

Une fiche produit traduite ne garantit pas que le client recevra un message cohérent lors de la commande, de l’expédition ou du remboursement. Les notifications possèdent leurs modèles, leurs variables et parfois leurs propres règles de langue.

Le contrôle utile relie un événement précis, la langue attendue et l’exemplaire obtenu. Shopify sert ici d’exemple documenté au 23 octobre 2026. Aucun courriel n’a été envoyé et aucun parcours marchand n’a été testé pour ce dossier.

Retrouver le système qui émet chaque message

Commencer par les messages qui portent une information importante pour le client. Identifier leur émetteur : plateforme, application d’abonnement, logisticien ou autre service. Deux messages semblables peuvent venir de systèmes différents et se traduire à des endroits différents.

Associer à chaque message son événement déclencheur et sa fonction. Une commande reçue, un paiement enregistré et une expédition ne décrivent pas la même étape. Le vocabulaire doit conserver cette différence dans chaque langue.

Limiter la recette aux variantes utiles : langue effectivement proposée, événement distinct, donnée facultative susceptible de manquer ou parcours qui change la destination. Multiplier des captures identiques n’améliore pas la preuve.

Distinguer langue de navigation et traduction disponible

La documentation Shopify sur le checkout et les notifications indique que, si une traduction est disponible pour une notification, celle-ci est envoyée dans la langue utilisée pour passer la commande. La langue des notifications peut aussi être modifiée dans le profil client.

La présence d’une langue publiée ne suffit donc pas à affirmer que toutes les notifications ont été traduites. Vérifier chaque modèle concerné et l’état de ses traductions. Examiner séparément les messages issus d’applications tierces.

Préparer un cas avec une commande dans la langue visée et relever le profil client utilisé. La page décrit la possibilité de changer la langue des notifications depuis ce profil ; elle ne détaille pas tous les conflits entre une modification du profil, une nouvelle commande et le moment où l’événement est traité. Ne pas transformer ces deux indications en une règle universelle de priorité valable pour toutes les notifications. Une attente fondée sur l’adresse du client ou son pays ne remplace pas le comportement à établir pour l’événement concerné.

La documentation générale de localisation indique un repli du contenu de la boutique vers sa langue principale lorsqu’une traduction manque. Ce passage ne suffit pas à attribuer automatiquement le même repli à chaque notification. Le passage consacré aux courriels conditionne l’envoi dans la langue de commande à la disponibilité de la traduction, sans préciser ici le résultat de tous les cas où elle manque.

La liste de recette recommandée sépare donc les cas suivants :

• Commande dans une langue proposée, profil inchangé et traduction disponible pour le modèle : attendre la langue de commande selon la règle documentée, puis comparer le message obtenu.
• Langue du profil changée après la commande, traduction disponible : relever l’événement, la chronologie et la langue demandée dans le profil. La fonction documentée permet de changer la langue reçue ; établir son effet pour ce message avant de qualifier une divergence.
• Traduction absente pour le modèle : relever la langue principale de la boutique, sans la déclarer d’office langue attendue du courriel. Faire établir le repli applicable par une documentation précise ou une recette autorisée ; garder ce cas ouvert tant que ce résultat manque.
• Nouvelle commande dans une autre langue après changement du profil, ou message émis par une application tierce : qualifier séparément la règle et son moment de prise en compte, sans réutiliser automatiquement l’attente du premier cas.

Pour chaque cas, consigner l’événement, la langue de commande, celle du profil au moment pertinent, la traduction disponible, l’attente établie et le résultat reçu. Une attente encore inconnue appelle une vérification ; elle ne permet ni un PASS ni un diagnostic automatique d’anomalie.

Relire ensemble le sujet, le corps et les variables

Une traduction fluide peut rester fausse si elle décrit le mauvais événement. Comparer le sujet et le corps avec l’état de la commande. Un message d’expédition ne doit pas devenir une promesse de livraison déjà réalisée.

Vérifier les données insérées : produit et variante, quantité, montant et devise, adresse, mode de retrait ou d’expédition et liens nécessaires selon le message. Cette liste est un contrôle de cohérence, pas une prescription exhaustive commune à tous les contrats.

Faire traiter les variantes grammaticales et les textes conditionnels par une personne compétente dans la langue. Une variable manquante peut laisser une phrase incomplète ; une information facultative peut rendre un paragraphe inadapté. Employer des cas de test prévus pour ces différences.

La page de personnalisation des modèles Shopify décrit aussi des effets différents d’un changement de langue du thème selon les modifications déjà apportées au sujet ou au corps. Ne pas présumer qu’un changement du thème remettra toutes les notifications en cohérence.

Passer de l’aperçu au résultat reçu

Shopify documente la localisation de la notification avec Translate & Adapt et un aperçu par langue après sauvegarde. Cet aperçu constitue une première vérification du modèle.

Il reste distinct d’un message obtenu avec les données et le destinataire d’un scénario. La documentation permet également l’envoi d’un message de test au compte utilisé pour se connecter à l’administration. Vérifier ce destinataire avant toute utilisation autorisée de cette fonction ; ne pas supposer qu’un bouton de test enverra le message au client fictif.

Pour une recette complète autorisée, conserver l’aperçu puis l’exemplaire reçu et noter comment celui-ci a été produit. Comparer langue, sujet, corps, données et liens sur les formats de lecture retenus, notamment mobile. Un aperçu seul ne prouve ni la réception ni le rendu chez tous les destinataires.

Si l’exemplaire reçu a été généré avec des données de démonstration, le signaler. Il ne démontre pas le remplissage correct des variables d’une véritable commande.

Un contre-cas fictif rend la décision plus précise : une commande passée dans une langue reçoit un message de commande correctement traduit, puis un message d’expédition dans une autre langue. Rechercher le modèle et l’émetteur du second événement, sa traduction disponible et le profil utilisé. Ne pas retraduire tout le catalogue ou déplacer les URL pour corriger ce seul message. Si les deux textes sont dans la bonne langue mais qu’une variable décrit un retrait alors que l’article est expédié, traiter la condition ou la donnée plutôt que la traduction. Ces cas sont proposés pour la recette ; aucun résultat d’envoi n’est revendiqué.

Ne pas confondre traduction et confirmation du contrat

La notification peut participer à la relation contractuelle, mais sa qualité linguistique ne qualifie pas à elle seule son contenu ou son support. Le dossier sur la confirmation de commande traite la fourniture et la conservation des informations contractuelles.

De même, un message de paiement n’établit pas tous les effets de l’événement sur la commande. Le dossier sur les notifications de paiement examine cette chaîne de traitement.

Dans la recette multilingue, noter lorsqu’un texte important dépend d’une autre validation : conditions, rétractation, calendrier ou portée du message. La traduction ne doit pas introduire un engagement plus large ou une restriction absente de la version de référence.

Organiser la maintenance du modèle et de ses traductions

La recommandation est d’associer chaque changement du modèle à l’examen de ses traductions concernées. Nommer la version de référence, la personne chargée de la langue et les scénarios à reprendre.

Conserver le texte précédent et les résultats utiles selon une politique adaptée. Si un ajout concerne une variable ou une condition, ne pas limiter la relecture à la nouvelle phrase : vérifier les branches où cette donnée manque.

La clôture exige un résultat pour les cas retenus et une liste explicite des limites. Un message sauvegardé n’est pas un message reçu, et un message reçu sur un appareil ne démontre pas tous les rendus. Le dossier de recette sert à décider ce qui peut être conservé et ce qui doit encore être corrigé.