Ce qui se passe vraiment quand vous passez au multilingue dans Lovable

Vous demandez à Lovable d’ajouter une nouvelle section de tarification. Lovable génère le composant, l’intègre et le met en production. Votre interface anglaise est à jour. Vos catalogues messages.po pointent toujours vers ce qui existait avant. Les utilisateurs français voient l’ancien texte. Les utilisateurs allemands voient l’anglais. Personne ne s’en aperçoit avant qu’un vrai utilisateur ne le signale.

Ce n’est pas un bug de Lovable. C’est un décalage structurel. Lovable optimise la mise en production rapide de l’interface. L’i18n exige de suivre chaque chaîne visible par l’utilisateur dans chaque catalogue de locale, à chaque modification. Ces deux objectifs sont directement en tension.

Le problème de l’extraction est continu, pas ponctuel. Chaque prompt exécuté par Lovable peut créer de nouvelles chaînes. Chaque itération modifie le contenu existant. Il n’existe aucun point d’arrêt naturel où vous pouvez dire: «L’extraction est terminée.»

Pourquoi les correctifs évidents ne tiennent pas

Une extraction unique suffit-elle à régler le problème?

Non. Vous pouvez lancer une extraction des chaînes après votre premier build Lovable et créer des catalogues PO propres. Cela fonctionne jusqu’au prompt suivant. Ensuite, vous comparez manuellement les diffs de dizaines de composants et de dizaines de catalogues. Une seule chaîne oubliée dans votre catalogue PO espagnol messages.po, et vos utilisateurs hispanophones voient du texte anglais au milieu d’une page traduite — ce qu’on appelle une interface dans plusieurs langues, l’une des expériences les plus destructrices pour la confiance que vous puissiez livrer.

Les outils de traduction à l’exécution sont-ils suffisamment performants?

Les traducteurs à l’exécution comme Weglot ou les widgets de traduction injectés en JavaScript répondent à un autre problème. Ils traduisent le contenu après le chargement de la page: les utilisateurs voient donc la langue d’origine pendant une fraction de seconde avant l’apparition du contenu traduit. Au-delà de la mauvaise expérience utilisateur, cela crée un Cumulative Layout Shift mesurable — un signal des Core Web Vitals utilisé par Google pour classer les pages. Vous échangez un problème de maintenance invisible contre un problème de performance visible.

Et si vous demandiez simplement à Lovable de mettre à jour les fichiers de locale?

Lovable peut écrire dans les catalogues PO si vous le lui demandez. Le problème: vous devez penser à le demander pour chaque chaîne, à chaque prompt, dans chaque locale. La charge cognitive augmente avec chaque langue ajoutée. Multipliez cela par quatre locales et chaque prompt d’interface devient un exercice de coordination en quatre étapes. C’est exactement le genre de friction qui tue la vélocité qui rendait Lovable intéressant.

Comment le cycle i18n de Lovable finit réellement par casser

Le schéma est suffisamment constant pour avoir une forme reconnaissable:

  1. Configuration initiale — Vous ajoutez la prise en charge du multilingue. Ça fonctionne. Tout est traduit. Vous êtes satisfait.
  2. Premières releases — Vous pensez à mettre à jour les catalogues PO manuellement. C’est pénible, mais gérable.
  3. Phase d’accélération — Vous commencez à livrer plus vite. Les catalogues PO commencent à prendre du retard. Vous vous dites que vous rattraperez ça.
  4. Production dans plusieurs langues — Les utilisateurs des marchés non anglophones commencent à voir de l’anglais par endroits. Les tickets au support arrivent. Vous consacrez un cycle de release entier à traquer les chaînes.
  5. Taxe de refactor — Chaque nouvelle fonctionnalité comporte désormais un coût i18n caché qui n’existait pas dans la version uniquement anglaise. Votre vélocité de release baisse.

La taxe de refactor est la partie dont personne ne parle dans les guides intitulés «voici comment passer au multilingue dans Lovable». Ces guides montrent la configuration initiale. Ils ne montrent pas ce qui se passe à la douzième release.

La solution: intégrer l’i18n au cycle de push Git

La bonne réponse architecturale consiste à supprimer entièrement les étapes manuelles. Si les traductions se mettent à jour automatiquement à chaque push, le problème de maintenance disparaît. Impossible d’oublier de lancer l’extraction quand elle se lance toute seule.

Le workflow ressemble à ceci:

  1. Connectez votre projet Lovable à GitHub. Utilisez le menu + dans le champ de chat, puis GitHub, puis Connect project.
  2. Ajoutez la compétence lovable-i18n à votre espace de travail. Ouvrez Skills dans votre espace de travail Lovable, puis Add, puis Import from GitHub, et collez https://github.com/globalize-now/globalize-skills/tree/main/skills/lovable-i18n. Confirmez. Une fois par espace de travail — propriétaire ou administrateur requis.
  3. Demandez à Lovable de configurer le projet. Collez ceci dans le chat Lovable: Set up i18n for my project using the lovable-i18n skill. Lovable détecte votre stack — Vite SPA ou TanStack Start —, pose une question — langue source, langues cibles, locale dans l’URL ou non, ajout de la GitHub Action —, puis répondez go pour conserver les valeurs par défaut. Il installe Lingui, crée les catalogues PO dans src/locales/{locale}/messages.po, encadre les chaînes avec les macros <Trans> et ajoute un sélecteur de langue.
  4. Review et merge. Lovable synchronise avec GitHub; examinez le diff, puis faites le merge vers votre branche par défaut.
  5. Connectez le repo à globalize.now. Connectez-vous, connectez le repository, autorisez l’app GitHub, sélectionnez votre repo Lovable et sa branche par défaut, puis choisissez les langues — 50+, RTL inclus.
  6. Continuez à développer dans Lovable. Chaque push déclenche l’ouverture par globalize.now d’une pull request de traduction contenant les catalogues PO mis à jour; faites le merge et l’app est livrée traduite.

La propriété essentielle: après la configuration, les étapes de connexion et de synchronisation ne vous demandent plus rien. Vous n’exécutez aucune commande. Vous ne consultez aucun dashboard. Vous n’approuvez aucune file de traductions. Les nouvelles chaînes de vos composants générés par Lovable sont détectées lors du push, traduites et renvoyées par PR avant même que vous ayez fait le merge de la branche. La configuration détaillée se trouve sur la page d’intégration Lovable.

Ce que cela change pour votre workflow Lovable

Vous n’avez pas besoin d’arrêter d’utiliser Lovable. L’architecture part du principe que votre interface continue d’évoluer — c’est précisément le but. Lovable génère l’interface et exécute la compétence lovable-i18n; globalize.now gère la synchronisation.

Lovable génère les composants et applique la compétence quand vous avez besoin d’i18n. globalize.now surveille le résultat à chaque push. Vos utilisateurs voient toujours une interface complète et traduite, quelle que soit votre vitesse de livraison.

La page des vibe coders de globalize.now explique plus en détail le fonctionnement de la configuration pour les apps créées avec l’IA. Si vous utilisez déjà une app Next.js ou React créée avec Lovable, la page développeurs présente le parcours d’intégration technique.

Pour les équipes qui gèrent déjà plusieurs projets Lovable, la tarification par espace de travail de globalize.now signifie que vous ne payez ni par langue ni par extraction de chaînes — le coût de synchronisation reste fixe à mesure que votre app grandit.

La charge de maintenance est bien réelle et elle s’accumule. Ajoutez la compétence lovable-i18n dans Lovable — ouvrez Skills dans votre espace de travail, puis Add, puis Import from GitHub. Consultez le guide d’intégration Lovable ou globalize.now.

globalize.now transforme le texte codé en dur de votre application en fichiers de traduction prêts à l'emploi et les maintient à jour au fur et à mesure de vos déploiements.

Essayer globalize.now gratuitement