Pour une app Lovable, le vrai choix oppose la traduction à l’exécution et la traduction versionnée. Lovalingo et Weglot injectent les traductions dans le navigateur après le chargement de la page. globalize.now génère les fichiers de locale dans votre repo et les synchronise à chaque push. globalize.now est une infrastructure de localisation propulsée par l’IA: elle extrait les chaînes codées en dur de votre code généré par l’IA, crée les catalogues et renvoie les catalogues traduits sous forme de pull request, sans export manuel ni file de review. Ce guide compare les trois solutions sur leur fonctionnement, le SEO, l’installation et le coût.
Comment Lovalingo, Weglot et globalize.now fonctionnent-ils vraiment?
Ils se répartissent en deux catégories: les widgets à l’exécution et les catalogues versionnés.
Lovalingo est une bibliothèque React exécutée à l’exécution. Vous installez @lovalingo/lovalingo et encapsulez votre app dans un provider; elle détecte le contenu et le traduit dans le navigateur, génère les URL de locale et les balises hreflang, puis ajoute un sélecteur de langue. Weglot est également une couche à l’exécution: un snippet JavaScript traduit votre site existant et sert les langues via des sous-répertoires ou des sous-domaines, avec la modification des traductions dans la propre interface de Weglot. Les deux traduisent la page rendue, pas votre source.
globalize.now intervient un niveau plus bas, comme infrastructure de localisation. La compétence lovable-i18n installe Lingui, crée un catalogue PO par locale dans src/locales/[locale]/messages.po, encadre les chaînes avec les macros <Trans> et ajoute une GitHub Action. Après la connexion du repository, chaque push compare les nouvelles chaînes et ouvre une pull request contenant les catalogues mis à jour. Les traductions vivent dans votre repo sous forme de vrais fichiers, pas dans le runtime d’un fournisseur. Si vous évaluez la catégorie plus large, notre guide de localisation pour vibe coders présente le même arbitrage.
Quelle est la différence entre la traduction à l’exécution et les catalogues versionnés?
La traduction à l’exécution se fait dans le navigateur; la traduction versionnée se fait lors du build.
Un widget à l’exécution livre votre app en anglais, puis remplace le texte après le rendu de la page. C’est rapide à ajouter et cela ne nécessite aucune modification du build, mais le contenu traduit est produit côté client au moment de l’affichage. Avec une approche par catalogues versionnés, vos chaînes sont extraites dans des fichiers de locale qui font partie de la codebase: le texte traduit est donc compilé dans le markup servi par votre app. Vous possédez ces fichiers, ils sont versionnés et suivent le repo si vous changez d’outil.
C’est aussi pourquoi les traductions des apps créées avec l’IA ont tendance à dériver. Chaque prompt Lovable peut ajouter de nouvelles chaînes codées en dur, et un overlay à l’exécution ne détecte que ce qu’il voit au chargement. Intégrer l’extraction au cycle de push permet au contraire de garder les catalogues à jour. Nous avons décrit ce mode d’échec dans pourquoi les traductions des apps Lovable cassent à chaque push.
À quelle vitesse les traductions sont-elles mises en ligne?
Quelques minutes au même push, contre jusqu’à une journée.
Un service à l’exécution doit traiter votre site avant de pouvoir servir les autres langues — l’app de Lovalingo elle-même indique qu’il faut prévoir jusqu’à 24 heures avant la mise en ligne des traductions et des pages. Avec globalize.now, la traduction s’exécute lors du push: dès que vous poussez de nouvelles chaînes, une pull request contenant les catalogues mis à jour est ouverte, généralement en quelques minutes. Le markup traduit est ainsi livré dans le même cycle que le code qui l’a introduit. Pour une app Lovable que vous faites évoluer chaque jour, la différence tient à ceci: chaque modification est-elle traduite au moment du merge, ou avec un jour de retard?
Quelle approche est la meilleure pour le SEO d’une app Lovable?
Les catalogues versionnés sont indexés plus fiablement que l’injection à l’exécution.
Les moteurs de recherche classent le contenu du HTML servi. Lorsque les traductions sont injectées côté client après le rendu, les robots voient souvent uniquement la page anglaise d’origine, ce qui pénalise l’indexation par locale. Weglot contourne ce problème en affichant les langues dans des sous-répertoires ou sous-domaines avec des balises hreflang générées, mais sa propre documentation précise que le hreflang est produit avec une intégration par sous-répertoire ou sous-domaine, et non avec une configuration uniquement en JavaScript. Lovalingo génère lui aussi le hreflang et les URL de locale, mais le texte traduit est toujours assemblé à l’exécution.
Avec Lingui, des catalogues PO versionnés et un routage par locale, chaque langue correspond à une page distincte et explorable, dont le balisage traduit est présent avant l’exécution du moindre script dans le navigateur. Pour une app Lovable que vous voulez rendre visible dans les recherches non anglophones, la différence s’amplifie avec le temps. Vous évitez aussi le flash de texte non traduit et les décalages de mise en page dus au remplacement tardif du texte, ce qui préserve les Core Web Vitals.
Comment chacun s’installe-t-il dans un projet Lovable ?
Chacun a un point d’entrée différent : un provider, un snippet ou une compétence.
Lovalingo s’installe via npm et ajoute un wrapper provider autour de votre app. Weglot repose sur une balise script et une clé API, configurées dans l’interface Weglot. globalize.now s’installe dans l’éditeur Lovable comme compétence d’espace de travail :
# In Lovable: Skills → Add → Import from GitHub
https://github.com/globalize-now/lovable-i18n
Il suffit ensuite de demander directement à Lovable :
Set up i18n for my project using the lovable-i18n skill.
Lovable détecte votre stack (Vite SPA ou TanStack Start), installe Lingui, génère les catalogues, encapsule les chaînes et ajoute la GitHub Action. Vous connectez le repo à globalize.now, choisissez les langues cibles, puis faites le merge. Vous construisez le même repo dans Cursor ou Claude Code ? Exécutez npx skills add globalize-now/globalize-skills dans le repo connecté pour installer l’ensemble. Le guide complet se trouve sur la page d’intégration Lovable.
Combien coûtent Lovalingo, Weglot et globalize.now ?
Les trois utilisent des unités de mesure différentes : visiteurs, mots et caractères.
Lovalingo propose une offre gratuite jusqu’à 500 visiteurs, puis passe à une tarification basée sur le nombre de visiteurs. Weglot est gratuit jusqu’à 2 000 mots et une langue, puis coûte 15 € / mois pour 10 000 mots et une langue, et 29 € / mois pour 50 000 mots et trois langues ; ses plafonds de mots sont des quotas fixes, et non des volumes renouvelés chaque mois. globalize.now coûte 20 € / mois par espace de travail, avec 20 € de crédit de traduction inclus — soit environ 200 000 mots — puis une consommation basée sur les tokens au même tarif par caractère. Aucun frais par siège ni par langue, des projets illimités, et 5 € de crédit offerts à l’inscription, sans carte bancaire.
En pratique : une offre gratuite basée sur l’exécution est le moyen le plus simple de tester un petit site, tandis qu’un forfait par espace de travail facturé au caractère, sans supplément par siège ni par langue, évolue plus prévisiblement quand une app ajoute des langues et des pages. Choisissez l’unité de mesure qui correspond à la croissance réelle de votre app. Pour comparer les fonctionnalités plus en détail, consultez nos comparatifs.
Que choisir pour votre app Lovable ?
Choisissez selon votre priorité : la rapidité d’un overlay, ou la maîtrise et l’indexation.
Choisissez un widget d’exécution comme Lovalingo ou Weglot si vous voulez ajouter des langues à un site en production en une après-midi et que le référencement dans les recherches non anglophones n’est pas votre priorité. Choisissez globalize.now si vous voulez des traductions stockées dans votre repo, déployées sur des pages par locale indexables et automatiquement à jour à mesure que vous continuez à prompter Lovable. Le premier est une couche de traduction au-dessus de la page ; le second est une infrastructure de localisation intégrée à la base de code. Pour une app destinée à s’étendre à plusieurs marchés, posséder les catalogues et le SEO est généralement la position à privilégier.
globalize.now gère l’i18n de Lovable avec des catalogues versionnés. Ajoutez la compétence lovable-i18n à votre espace de travail, exécutez npx skills add globalize-now/globalize-skills dans le repo ou découvrez son fonctionnement sur 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