Rendre une app Lovable multilingue correctement signifie versionner de vrais catalogues de traduction dans votre repo et les synchroniser automatiquement, pas ajouter un widget de traduction par-dessus l’interface. globalize.now est une infrastructure de localisation propulsée par l’IA qui extrait vos chaînes codées en dur, prépare des catalogues PO et les met à jour à chaque push Git. Les outils rapides vous donnent une démo multilingue en quelques minutes. Ils vous laissent aussi des traductions qui dérivent, une mise en page qui bouge au chargement et des pages difficiles à lire pour les moteurs de recherche. Voici une configuration qui tient jusqu’à la douzième release.

Que signifie réellement « multilingue correctement » pour une app Lovable ?

Cela signifie que vos traductions vivent dans votre codebase sous forme de catalogues versionnés, qu’elles sont servies dans le markup initial et mises à jour automatiquement à mesure que l’app évolue.

Toute app réellement multilingue repose sur trois couches. Une librairie runtime d’i18n sert la bonne chaîne pour la locale active. Les catalogues de traduction contiennent les traductions elles-mêmes. Et quelque chose doit maintenir ces catalogues à jour lorsque l’interface évolue. La plupart des guides Lovable couvrent la première couche et ignorent la troisième — celle qui finit par casser.

Lovable est conçu pour modifier rapidement votre interface. Chaque prompt peut ajouter, renommer ou restructurer du texte visible par l’utilisateur. La question du multilingue n’est donc pas « comment traduire l’app une fois ? », mais « comment garder chaque locale complète tout en continuant à prompter ? ». Si vous vous trompez, vous livrez une interface dans plusieurs langues — l’un des moyens les plus rapides de perdre la confiance d’un marché non anglophone.

Pourquoi les widgets de traduction ne suffisent-ils pas pour les apps Lovable ?

Ils traduisent le contenu après le chargement de la page, remplaçant un problème de maintenance invisible par un problème visible de performance et de SEO.

Les traducteurs runtime comme Weglot, Lovalingo et les widgets injectés sont la première réponse la plus courante pour Lovable, parce qu’ils s’installent en quelques minutes et ne nécessitent aucun fichier de locale. Le coût apparaît plus tard. L’utilisateur voit brièvement la langue d’origine avant que la traduction ne s’affiche : c’est un flash de contenu non traduit. Ce remplacement déplace la mise en page et ajoute du Cumulative Layout Shift, que Google mesure dans le cadre des Core Web Vitals.

Le problème plus profond concerne la découvrabilité. Si le texte traduit n’existe qu’après l’exécution du JavaScript côté client, vous avez généralement une seule vraie page, plus une traduction dans le navigateur. Les URL par locale sont faibles ou inexistantes : vos pages espagnoles et allemandes ne se positionnent donc pas comme celles d’un site correctement localisé. Un widget peut être le bon choix pour un outil interne ou une démo jetable. Pour une app que vous voulez rendre visible sur d’autres marchés, c’est une mauvaise fondation.

Une configuration i18n unique suffit-elle à garder une app Lovable traduite ?

Non. Une extraction propre fonctionne jusqu’à votre prochain prompt. Ensuite, la dérive commence.

Vous pouvez demander à Lovable, Cursor ou Claude Code de configurer une vraie librairie i18n et d’extraire chaque chaîne dans des catalogues de traduction. Cela fonctionne réellement pour le build sur lequel vous l’exécutez. Le problème, c’est qu’il n’existe pas de point d’arrêt naturel où l’extraction serait « terminée ». La prochaine section de tarification, le prochain état vide et le prochain libellé de bouton arrivent comme de nouvelles chaînes codées en dur, tandis que vos catalogues prennent discrètement du retard.

L’alternative manuelle — demander à Lovable de mettre à jour chaque catalogue à chaque changement — semble rigoureuse et s’effondre en pratique. Vous devez vous en souvenir pour chaque chaîne, dans chaque langue, à chaque prompt. Multipliez cela par quatre locales et chaque modification d’interface devient un exercice de coordination. Cette friction tue précisément la vélocité qui rendait Lovable intéressant.

Comment rendre mon app Lovable multilingue, étape par étape ?

Avant de commencer : connectez votre projet Lovable à GitHub (menu + dans le champ de chat, puis GitHub, puis Connect project), créez un compte globalize.now (inscription gratuite, 5 € de crédit initial, sans carte bancaire) et vérifiez que vous êtes propriétaire ou administrateur de l’espace de travail Lovable afin de pouvoir y ajouter la compétence une seule fois.

Connectez le repo, ajoutez la compétence lovable-i18n une seule fois, puis laissez la synchronisation s’exécuter à chaque push. Voici le parcours complet.

  1. Connecter votre projet Lovable à GitHub. Utilisez le menu + dans le champ de chat, puis GitHub, puis Connect project. Lovable synchronise votre projet avec un vrai repo, ce qui rend l’i18n durable possible. Tout ce qui suit s’exécute sur ce repo, pas dans une boîte noire.
  2. Ajouter la compétence lovable-i18n à votre espace de travail. Lovable prend en charge les compétences réutilisables. 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 seule fois par espace de travail (propriétaire ou administrateur requis). L’ajout d’une compétence est gratuit et ne consomme aucun crédit. Vous développez plutôt dans Cursor ou Claude Code ? Exécutez npx skills add globalize-now/globalize-skills dans le repo connecté.
  3. Demander à 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 (@lingui/core, @lingui/react, le plugin Vite), configure le provider, prépare un catalogue PO par locale dans src/locales/{locale}/messages.po, entoure les chaînes de 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. Connecter le repo à globalize.now. Connectez-vous, puis sélectionnez Connect repository, autorisez l’app GitHub, choisissez le repo Lovable et la branche par défaut, puis sélectionnez les langues (50+, RTL inclus).
  6. Continuer à développer dans Lovable. À chaque push, globalize.now ouvre une PR de traduction avec les catalogues PO mis à jour. Mergez-la. Votre app est livrée traduite. Vous n’avez rien d’autre à faire entre deux releases.

L’élément important se trouve dans les étapes trois à six : la configuration est unique et la synchronisation continue ne nécessite ni commande, ni dashboard, ni file de review. Pour le parcours d’intégration complet, consultez la page d’intégration Lovable.

Quelle librairie i18n une app Lovable doit-elle utiliser ?

La compétence lovable-i18n installe Lingui, car les apps Lovable sont des projets React Vite SPA ou TanStack Start, et Lingui s’intègre bien à cette stack.

La compétence configure @lingui/core, @lingui/react et le plugin Vite, prépare les catalogues PO dans src/locales/{locale}/messages.po et entoure les chaînes de macros <Trans>. react-i18next et next-intl sont les bons choix pour d’autres configurations React et Next.js, mais la compétence ne les installe pas.

Évitez d’inventer un contexte de traduction personnalisé ou de coder en dur une map de langues. Cela semble plus léger le premier jour et devient la chose que vous devrez retirer le trentième. La page développeurs de globalize.now explique comment l’extraction s’intègre à chaque librairie, pour que vous ne choisissiez pas à l’aveugle.

Comment garder les traductions synchronisées tout en continuant à prompter Lovable ?

Intégrez la synchronisation à votre workflow Git pour qu’elle ne puisse pas être oubliée.

Si l’i18n manuelle échoue, c’est parce qu’elle dépend d’une personne qui doit penser à cette corvée pendant un cycle de build rapide. L’infrastructure retire cette personne de la boucle. Lorsque le diff et l’étape de traduction s’exécutent à chaque push, toute nouvelle chaîne créée par un prompt Lovable est détectée, traduite et renvoyée par PR avant le merge de la branche. Aucune release ne voit les catalogues PO prendre silencieusement du retard, puisqu’il n’y a aucune étape manuelle à oublier.

C’est la différence entre une configuration et une infrastructure. Une configuration est un état que vous atteignez une fois. Une infrastructure est une propriété qui reste vraie pendant que tout le reste change. Pour une app que vous continuez à modifier dans Lovable, vous voulez la propriété, pas l’état. La page dédiée aux vibe coders détaille le workflow des apps construites avec l’IA ; si vous comparez les outils, le guide comparatif indique où chacun se situe dans la stack.

Rendre une app Lovable multilingue est facile au départ, mais difficile à maintenir. globalize.now s’occupe de la maintenance. Dans Lovable, ajoutez la compétence lovable-i18n depuis Open Skills, puis Add, puis Import from GitHub, en indiquant globalize-now/lovable-i18n. Dans Cursor ou Claude Code, exécutez npx skills add globalize-now/globalize-skills. 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