Un workflow i18n pratique pour Vue 3 dans les grosses apps : nommage des clés, pluriels, contrôles QA et étapes de release pour éviter des traductions manquantes en production.
Quand votre app atteint quelques centaines de chaînes, la première chose qui casse n’est généralement pas Vue I18n. C’est la cohérence. Les gens ajoutent des clés avec des styles différents, dupliquent une même idée sous des noms différents, et personne n’est sûr des messages qu’on peut supprimer en toute sécurité.
Les traductions manquantes cessent d’être rares. Elles apparaissent dans des parcours utilisateurs normaux, surtout sur des écrans peu utilisés comme les paramètres, les états d’erreur, les écrans vides et les notifications.
Quand une traduction manque, l’utilisateur voit en général l’un de ces trois problèmes : une interface vide (un bouton sans label), des clés brutes (par exemple checkout.pay_now), ou un fallback étrange où une partie de la page bascule dans une autre langue. Aucun de ces cas ne ressemble à un bug mineur — ça donne l’impression que l’app est cassée.
C’est pour ça qu’un workflow i18n pour Vue 3 compte plus que la bibliothèque choisie. La bibliothèque fera ce que vous lui demandez. À grande échelle, les équipes ne s’accordent souvent pas sur ce que signifie « terminé ».
Un exemple courant : un dev met en production un nouveau flux « Inviter un coéquipier » avec 40 chaînes. Le fichier anglais est mis à jour, mais le fichier français ne l’est pas. En staging tout semble OK parce que le testeur utilise l’anglais. En production, les utilisateurs français voient un mélange d’UI traduite et non traduite, et le support reçoit des captures d’écran de clés brutes.
La solution est de définir ce que signifie « terminé » pour une UI traduite. Ça ne peut pas être juste « chaînes ajoutées ». Une définition de done pratique inclut généralement : les clés respectent les règles de nommage, les locales compilent sans warnings de clés manquantes, les pluriels et variables s’affichent correctement avec des données réelles, au moins une locale non par défaut a été vérifiée, et les changements de copy sont suivis pour que d’anciennes clés ne traînent pas.
À plus de 500 clés, gagnez en traitant la localisation comme un processus de release, pas comme une édition de fichier de dernière minute.
Après quelques centaines de chaînes, le travail de traduction n’est pas le plus chaotique. C’est la cohérence. Un petit ensemble de règles rend votre workflow i18n Vue 3 prévisible, même si plusieurs personnes touchent au contenu chaque semaine.
Commencez par décider ce qu’est un « concept » et conservez une source de vérité unique pour celui‑ci. Si la même idée d’UI apparaît à cinq endroits (par exemple « Enregistrer les modifications »), vous voulez une seule clé, pas cinq variations comme save, saveChanges, save_update et saveBtn. Les clés dupliquées dérivent en sens au fil du temps, et les utilisateurs ressentent cette incohérence.
Ensuite, décidez où vit le formatage. Les équipes le répartissent souvent par accident : certains messages incluent la ponctuation et la casse, d’autres s’appuient sur le code pour l’ajouter. Choisissez une approche et tenez‑vous y.
Un choix pratique par défaut :
Puis définissez la propriété des contenus. Décidez qui peut ajouter des clés, qui révise la copie en langue de base, et qui approuve les autres locales. Sans ça, les chaînes sont ajoutées à la va‑vite et ne sont jamais relues.
Enfin, choisissez et documentez une stratégie de fallback. Si une clé manque, que doit voir l’utilisateur : le nom de la clé, le texte de la locale par défaut, ou un message générique sûr ? En production, beaucoup d’équipes préfèrent revenir à la locale par défaut tout en journalisant l’erreur, pour que les utilisateurs ne soient pas bloqués et que vous ayez tout de même un signal indiquant qu’il y a un problème.
Si vous créez des apps Vue 3 avec un générateur comme AppMaster (UI web Vue3 plus vrai code backend), ces règles s’appliquent aussi. Traitez les traductions comme du contenu produit, pas comme du « simple texte dev », et vous éviterez la plupart des surprises de dernière minute.
Au‑delà de quelques centaines de chaînes, la cohérence est le plus grand multiplicateur. Choisissez un seul style de clé (la plupart des équipes utilisent des chemins en points comme billing.invoice.title) et faites‑en une règle. Mélanger points, slashs, snake_case et casse aléatoire rend la recherche et la revue lentes.
Utilisez des clés stables qui survivent aux changements de copy. Une clé comme « Please enter your email » sera cassée dès que le marketing retouche la phrase. Préférez des noms basés sur l’intention comme auth.email.required ou auth.email.invalid.
Regroupez les clés d’abord par domaine produit ou surface UI, puis par objectif. Pensez dans les mêmes bacs que votre app : auth, billing, settings, support, dashboard. Cela rend les fichiers de locale plus faciles à parcourir et réduit les doublons quand deux écrans ont besoin de la même idée.
Dans chaque domaine, gardez un petit ensemble de modèles pour les éléments UI courants :
*.actions.save, *.actions.cancel*.fields.email.label, *.fields.password.label*.fields.email.hint*.errors.required, *.errors.invalidFormat*.notices.saved, *.notices.failedLes messages dynamiques doivent indiquer ce qui change, pas comment. Nommez le message par intention et utilisez des paramètres pour les parties variables. Par exemple, billing.invoice.dueInDays avec {days} est plus clair que billing.invoice.dueIn3Days.
Exemple (fonctionne bien dans un workflow i18n Vue 3) : orders.summary.itemsCount avec {count} pour le nombre, et orders.summary.total avec {amount} pour l’argent. Quand quelqu’un lit la clé dans le code, il doit savoir où elle appartient et pourquoi elle existe, même si la copy finale change plus tard.
Le texte au pluriel casse silencieusement quand vous traitez chaque langue comme l’anglais. Décidez tôt quand vous utiliserez la syntaxe ICU et quand un simple placeholder suffit.
Utilisez de simples remplacements pour des labels et courts textes UI qui ne changent jamais selon le nombre (par exemple, « Welcome, {name} »). Passez à ICU pour tout ce qui dépend d’un compte, car cela garde toutes les formes au même endroit et rend les règles explicites.
{
"notifications.count": "{count, plural, =0 {No notifications} one {# notification} other {# notifications}}"
}
Rédigez les messages de nombre de façon à ce qu’ils soient faciles à traduire. Préférez une phrase complète et gardez le placeholder du nombre (#) proche du nom. Évitez les astuces comme réutiliser la même clé pour « 1 item » et « 2 items » dans le code. Les traducteurs ont besoin de voir le message entier, pas de deviner comment il sera assemblé.
Prévoyez au minimum =0, one et other, et documentez ce que vous attendez pour 0. Certains produits veulent « 0 éléments », d’autres « Aucun élément ». Choisissez un style et tenez‑vous y pour que l’UI soit cohérente.
Faites aussi attention aux langues qui ont plus de catégories de pluriel que prévu. Beaucoup de langues ne suivent pas le schéma « un vs plusieurs ». Si vous ajoutez une nouvelle locale plus tard, un message n’ayant que one et other peut être grammaticalement incorrect même s’il s’affiche.
Avant de livrer, testez les pluriels avec des comptes réels dans l’interface, pas seulement en regardant le JSON. Un contrôle rapide qui détecte la plupart des problèmes : 0, 1, 2, 5 et 21.
Si vous construisez une app web Vue3 (par exemple, avec AppMaster), faites ce test sur l’écran réel où le texte apparaît. Les problèmes de mise en page, texte tronqué et formulations gênantes apparaissent d’abord là.
Après quelques centaines de chaînes, un gros en.json devient un goulot d’étranglement. Les gens touchent le même fichier, les conflits de merge augmentent, et vous perdez la trace de l’emplacement des copies. Une bonne structure maintient votre workflow i18n Vue 3 stable même si le produit évolue.
Pour 2 à 5 locales, scinder par fonctionnalité suffit généralement. Gardez la même structure de fichiers pour chaque locale afin que l’ajout d’une clé soit une modification prévisible.
locales/en/common.json, locales/en/auth.json, locales/en/billing.jsonlocales/es/common.json, locales/es/auth.json, locales/es/billing.jsonlocales/index.ts (charge et fusionne les messages)Pour 20+ locales, appliquez la même idée mais rendez la dérive plus difficile. Traitez l’anglais comme source de vérité et imposez que chaque locale reflète les mêmes dossiers et noms de fichiers. Si un nouveau domaine apparaît (par exemple notifications), il doit exister pour chaque locale même si le texte est temporaire.
Séparer par domaine réduit les conflits de merge parce que deux personnes peuvent ajouter des chaînes dans des fichiers différents sans se marcher dessus. Les domaines doivent correspondre à la construction de votre app : common, navigation, errors, settings, reports, plus des dossiers de feature pour les zones plus larges.
Dans chaque fichier, conservez la même forme de clé à travers les locales : même nesting, mêmes noms de clés, textes différents. Évitez des clés « créatives » par langue, même si une phrase est difficile à traduire. Si l’anglais a besoin de billing.invoice.status.paid, chaque locale doit avoir exactement cette clé.
Centralisez uniquement ce qui se répète vraiment partout : labels de boutons, erreurs de validation génériques et navigation globale. Gardez la copy spécifique à une fonctionnalité proche du domaine de la fonctionnalité, même si elle semble réutilisable. « Enregistrer » appartient à common. « Enregistrer le moyen de paiement » appartient à billing.
Les textes longs d’aide, étapes d’onboarding et modèles d’emails deviennent vite compliqués. Quelques règles aident :
help ou onboarding) et évitez les profondeurs de nesting inutiles.Cette organisation facilite la revue des changements, la traduction progressive et évite les trous juste avant la release.
Un workflow i18n Vue 3 stable, c’est moins une question d’outils que de répéter les mêmes petites étapes à chaque fois. Le nouveau texte UI ne doit pas atteindre la production sans une clé, un message par défaut et un statut de traduction clair.
Commencez par ajouter la clé dans votre locale de base (souvent en). Rédigez le texte par défaut comme une vraie copy, pas un placeholder. Cela donne à produit et QA quelque chose de lisible à relire, et évite les « chaînes mystères » plus tard.
Lorsque vous utilisez la clé dans un composant, incluez d’emblée les params et la logique de pluriel pour que les traducteurs voient la forme complète du message.
// simple param
$t('billing.invoiceDue', { date: formattedDate })
// plural
$t('files.selected', count, { count })
Si les traductions ne sont pas prêtes, ne laissez pas des clés manquantes. Ajoutez des traductions temporaires dans les autres locales ou marquez‑les comme en attente de façon cohérente (par exemple, préfixer la valeur par TODO:). L’essentiel est que l’app s’affiche de manière prévisible et que les réviseurs repèrent facilement la copy inachevée.
Avant le merge, lancez des vérifications automatisées rapides. Gardez‑les ennuyeuses et strictes : clés manquantes entre locales, clés inutilisées, mismatch de placeholders (manque {count}, {date} ou mauvaise accolade), formes de pluriel invalides pour les langues supportées, et overrides accidentels.
Enfin, faites une courte passe UI dans au moins une locale non‑par défaut. Choisissez une langue avec des chaînes plus longues (souvent l’allemand ou le français) pour détecter débordements, boutons tronqués et sauts de ligne gênants. Si votre UI Vue 3 est générée ou maintenue avec d’autres parties du produit (par exemple une app Vue3 produite par AppMaster), cette étape reste importante car la mise en page évolue avec les fonctionnalités.
Traitez ces étapes comme votre définition de done pour toute feature qui ajoute du texte.
La façon la plus rapide de rendre la localisation pénible est de traiter les clés i18n comme de « simples chaînes ». Après quelques centaines de clés, de petites habitudes se transforment en bugs de production.
Les fautes de frappe et différences de casse sont des causes classiques de texte manquant : checkout.title à un endroit, Checkout.title ailleurs. Ça passe en revue de code, puis votre fallback envoie autre chose en prod.
Un autre problème fréquent est de réutiliser une clé pour des sens différents. « Open » peut vouloir dire « Ouvrir un ticket » sur un écran support et « Ouvrir maintenant » sur une page boutique. Si vous réutilisez une seule clé, l’un des écrans sera faux dans d’autres langues, et les traducteurs devineront.
Une règle simple aide : une clé = un sens. Si le sens change, créez une nouvelle clé même si l’anglais reste identique.
Les équipes intègrent souvent ponctuation, espaces ou bouts de HTML dans les traductions. Ça fonctionne jusqu’à ce qu’une langue nécessite une ponctuation différente, ou que votre UI échappe ou rende le markup différemment. Gardez les décisions de markup dans les templates, et concentrez les messages sur le texte.
Le mobile est l’endroit où les problèmes se cachent. Un label qui tient en anglais peut passer à trois lignes en allemand, ou déborder en thaï. Si vous testez une seule taille d’écran, vous manquerez ça.
Surveillez les coupables récurrents : présumer l’ordre des mots anglais pour insérer des variables (noms, nombres, dates), construire des messages par concaténation au lieu d’un message unique, oublier de tester des valeurs longues (noms de produits, adresses, détails d’erreur), livrer avec un fallback silencieux qui fait paraître les clés manquantes « normales » en anglais, et copier‑coller des clés en ne modifiant que la valeur anglaise.
Si vous voulez un workflow i18n Vue 3 qui reste calme à 500+ clés, traitez les clés comme une partie de votre API : stables, spécifiques et testées comme tout le reste.
Les traductions manquantes sont faciles à rater parce que l’app « fonctionne » toujours. Elle retombe simplement sur la clé, la mauvaise locale, ou une chaîne vide. Traitez la couverture de traduction comme des tests : vous voulez un retour rapide avant que quoi que ce soit n’atteigne la production.
Commencez par des contrôles qui cassent la build, pas des warnings que personne ne lit.
$t('...') et t('...'), puis vérifiez que chaque clé utilisée existe dans la locale de base.en).Gardez la liste d’exceptions courte et sous la responsabilité de l’équipe, pas « tout ce qui passe la CI ».
Même avec la CI, vous voulez un filet en staging parce que des parcours réels déclenchent des chaînes dynamiques qu’on a oubliées.
Activez la journalisation des traductions manquantes en staging et incluez assez de contexte pour corriger rapidement : locale, route, nom du composant (si disponible) et la clé manquante. Rendez‑la bruyante. Si c’est facile à ignorer, ça sera ignoré.
Ajoutez une pseudo‑locale et utilisez‑la pour une passe UI rapide. Une approche simple : transformer chaque chaîne (l’allonger et ajouter des marqueurs) pour que les problèmes de mise en page sautent aux yeux, par exemple : [!!! 𝗧𝗲𝘅𝘁 𝗲𝘅𝗽𝗮𝗻𝗱𝗲́ !!!]. Cela détecte les boutons tronqués, en‑têtes de table cassés et espaces manquants avant la mise en prod.
Enfin, faites une vérification pré‑release ciblée de vos parcours à haute valeur en 2–3 locales : connexion, paiement/checkout, paramètres essentiels et la nouvelle fonctionnalité. C’est là que vous attrapez « c’était traduit mais le placeholder est faux ».
Ajouter une nouvelle langue devient compliqué quand vous le traitez comme du « travail de copy » et non comme une petite release produit. La façon la plus simple de garder votre workflow i18n Vue 3 stable est de faire en sorte que l’app build même quand une locale est incomplète, tout en rendant les trous évidents avant que les utilisateurs ne les voient.
Quand vous ajoutez une nouvelle locale, commencez par générer la même structure de fichiers que la locale source (souvent en). Traduire vient après, structurez d’abord.
Les traductions arrivent souvent en retard, donc décidez à l’avance ce que signifie « partiel » pour votre produit. Si une feature est visible par les utilisateurs, envisagez un feature flag afin que la feature et ses chaînes soient livrées ensemble. Si vous devez livrer sans traductions complètes, préférez un fallback clair (comme l’anglais) plutôt que des labels vides, mais signalez‑le fortement en staging.
Les modifications de copy sont l’endroit où les équipes cassent les clés. Si vous modifiez la formulation, conservez la clé. Les clés doivent décrire l’intention, pas la phrase exacte. Ne renommez la clé que si le sens change, et faites‑le via une migration contrôlée.
Pour éviter les « chaînes zombies », dépréciez les clés volontairement : marquez‑les comme dépréciées avec une date et une clé de remplacement, conservez‑les pendant un cycle de release, puis supprimez‑les seulement après avoir confirmé qu’il n’y a plus aucune référence.
Gardez les notes de traduction proches de la clé. Si votre format JSON ne peut pas contenir de commentaires, stockez les notes dans un petit document compagnon ou un fichier méta adjacent (par exemple « utilisé sur l’écran de confirmation de commande »). C’est particulièrement utile quand votre app Vue 3 est générée depuis un outil comme AppMaster et que plusieurs personnes touchent au texte et à l’interface.
Un sprint, votre équipe livre trois choses en même temps : une nouvelle page Paramètres, un écran Facturation, et trois templates d’email (reçu, paiement échoué, fin d’essai). Environ 60 nouvelles chaînes — c’est là où l’i18n devient souvent chaotique.
L’équipe s’accorde pour grouper les clés par feature, puis par surface. Un nouveau fichier est créé pour chaque feature, et les clés suivent le même pattern partout : feature.area.element.
// settings
"settings.profile.title": "Profile",
"settings.security.mfa.enable": "Enable two-factor authentication",
// billing
"billing.plan.current": "Current plan",
"billing.invoice.count": "{count} invoice | {count} invoices",
// email
"email.receipt.subject": "Your receipt",
"email.payment_failed.cta": "Update payment method"
Avant de lancer la traduction, les chaînes au pluriel sont testées avec des valeurs réelles, pas des suppositions. Pour billing.invoice.count, la QA vérifie 0, 1, 2 et 5 en utilisant des données seedées (ou un simple toggle dev). Cela évite des cas gênants comme « 0 invoice ».
La QA exécute ensuite un parcours ciblé qui révèle souvent les clés manquantes : ouvrir Paramètres et Facturation et cliquer chaque onglet, déclencher chaque template d’email en staging avec des comptes tests, lancer l’app avec une locale non‑par défaut active, et bloquer le build si des warnings de traductions manquantes apparaissent dans les logs.
Dans ce sprint, la QA trouve deux clés manquantes : un label sur l’écran Facturation et un objet d’email. L’équipe les corrige avant la release.
Pour décider de bloquer la livraison ou d’autoriser un fallback, ils suivent une règle simple : les écrans utilisateurs et les emails transactionnels bloquent la release ; le texte admin à faible risque peut temporairement retomber sur la langue par défaut, mais seulement avec un ticket et une date limite claire.
Un workflow i18n Vue 3 reste stable quand vous traitez les traductions comme du code : ajoutez‑les de la même façon à chaque fois, testez, et mesurez.
Choisissez quelques indicateurs simples et révisez‑les régulièrement : taux de clés manquantes lors de vos runs de test, nombre de chaînes non traduites dans les locales non par défaut, et nombre de clés inutilisées (chaînes qui n’apparaissent plus nulle part). Suivez‑les par release si possible pour voir les tendances plutôt que des échecs isolés.
Écrivez les étapes exactes pour ajouter une chaîne, mettre à jour les traductions et vérifier le résultat. Restez concis et incluez des exemples de noms de clés et d’usage des pluriels. Un nouveau contributeur doit pouvoir suivre sans poser de questions.
Si vous créez des outils internes, AppMaster (appmaster.io) peut être un moyen pratique de garder le texte UI et les clés de traduction cohérents entre une app web Vue3 et des apps mobiles associées, puisque tout est géré au même endroit.
Planifiez une petite tâche santé i18n chaque sprint : supprimer les clés mortes, corriger les placeholders incohérents et revoir les dernières erreurs. De petites opérations de maintenance évitent les chasses aux traductions en urgence en production.
21 janv. 2026
8 min
20 janv. 20268 min
20 janv. 20268 minExpérimentez avec AppMaster avec un plan gratuit.
Lorsque vous serez prêt, vous pourrez choisir l'abonnement approprié.
