Quelle est la meilleure façon de rendre une application Lovable multilingue ?

La meilleure façon de rendre une application Lovable multilingue est d'extraire le texte de votre interface dans des fichiers de traduction hébergés dans votre propre dépôt et de les traduire à chaque push Git, plutôt que de greffer une couche de traduction sur la page en runtime. globalize.now est une infrastructure de localisation propulsée par l'IA qui fait exactement cela : elle intègre Lingui à votre projet Lovable, extrait vos chaînes codées en dur dans des catalogues PO, et ouvre une PR de traduction à chaque push. Les pages traduites sont rendues par votre propre serveur, indexées par les moteurs de recherche, et restent dans votre base de code quels que soient les outils que vous choisirez ensuite. Les approches alternatives sacrifient toujours l'une de ces trois propriétés.

Que signifie localiser une application Lovable ?

Localiser une application Lovable recouvre deux tâches distinctes : extraire chaque chaîne codée en dur du code généré, et afficher une version traduite de chaque chaîne pour chaque langue. C'est la manière de traiter la deuxième tâche qui distingue les options.

Un widget de traduction en runtime agit dans le navigateur : la page en anglais se charge, puis un script remplace le texte visible. Une configuration repo-native agit avant même que le navigateur ne voie quoi que ce soit : vos chaînes vivent dans des fichiers de traduction, et votre application affiche la bonne langue à partir de ces fichiers au moment du build ou de la requête. Même résultat visible un bon jour, conséquences totalement différentes sur la vitesse, l'indexation par les moteurs de recherche, et ce que vous possédez réellement.

Lovable rend la première tâche plus difficile qu'une application écrite à la main, car le code généré par IA a tendance à disperser des chaînes littérales dans les composants sans aucune structure i18n. C'est aussi pour cette raison que les traductions des applications vibe-codées ont tendance à casser à chaque push, à moins d'être versionnées avec le code.

Quelle est la meilleure façon de rendre une application Lovable multilingue ?

Extrayez vos chaînes dans des fichiers de traduction commités et gardez-les traduites automatiquement à chaque push. Concrètement, pour une application Lovable, cela signifie des catalogues Lingui PO dans votre dépôt, plus une synchronisation qui traduit ce qui a changé à chaque push.

C'est le meilleur choix par défaut, car il gagne sur les trois propriétés à la fois. Vitesse : le texte traduit est déjà présent dans le HTML envoyé par votre serveur, donc pas de remplacement après chargement ni de décalage de mise en page. SEO : les moteurs de recherche et les moteurs de réponse IA reçoivent de vraies pages traduites qu'ils peuvent explorer et citer. Propriété : les catalogues sont de simples fichiers texte dans votre dépôt, donc votre application reste multilingue que vous continuiez ou non à payer un fournisseur en particulier.

globalize.now prend en charge toute la boucle. Vous ajoutez une compétence, demandez à Lovable de configurer l'i18n, et chaque futur push ouvre une PR de traduction. Il se situe au niveau de l'infrastructure de localisation, au-dessus de votre runtime i18n et en dessous de tout outil de gestion de traduction optionnel, donc il complète Lingui plutôt que de le remplacer. Le même flux fonctionne avec Cursor, Claude Code, Bolt et Replit, pas seulement Lovable.

Pourquoi ne pas simplement utiliser un widget de traduction en runtime ?

Parce qu'un widget optimise pour la démo et taxe tout ce qui vient après. Les outils en runtime comme Weglot et les couches de traduction React similaires s'intègrent rapidement par copier-coller, et c'est réellement leur atout pour un prototype jetable.

Les coûts apparaissent dès que l'application compte vraiment. Traduire après le chargement décale la mise en page pendant le remplacement du texte, ce qui nuit aux Core Web Vitals, et le contenu traduit est servi par la couche du fournisseur plutôt qu'intégré à vos pages, ce qui rend l'indexation fiable plus difficile pour les moteurs de recherche. Plus important encore, rien de portable ne reste dans votre dépôt. Si le service augmente ses prix, se fait racheter ou ferme, votre site multilingue redevient anglais uniquement.

Ce dernier risque n'est pas hypothétique. Lovalingo, l'un des outils de traduction en runtime les plus visibles pour les applications Lovable, a annoncé sa fermeture le 31 août 2026 et a déjà cessé d'accepter de nouvelles inscriptions. Son propre conseil aux utilisateurs concernés est de migrer vers une internationalisation détenue par le projet, ce qui correspond à l'approche repo-native décrite ici. Quand un fournisseur conseille lui-même, en partant, de posséder ses traductions, c'est un argument pour les posséder dès le départ.

La meilleure méthode fonctionne-t-elle avec la stack SSR TanStack Start de Lovable ?

Oui, et ce changement de stack renforce encore l'argument. Les nouveaux projets Lovable se déploient sur TanStack Start avec le rendu côté serveur, donc les pages sont assemblées sur le serveur avant d'atteindre le navigateur.

Les catalogues Lingui commités s'intègrent directement à ce modèle : le serveur lit le fichier de traduction et rend du HTML traduit dès le premier affichage, sans flash de texte anglais ni remplacement côté client. Un widget en runtime fait l'inverse : il laisse le serveur afficher l'anglais puis l'écrase après le chargement, ce qui est exactement le scintillement que le rendu côté serveur était censé éliminer. Nous détaillons ces spécificités dans le guide i18n Lovable TanStack Start. Les anciens projets Lovable rendus côté client sont également pris en charge, puisque les catalogues vivent dans votre dépôt quel que soit le mode de rendu de l'application.

Comment configurer globalize.now dans une application Lovable ?

Vous ne quittez jamais l'éditeur Lovable. La configuration se fait par prompt et se déroule en quatre étapes.

1. Ajoutez la compétence. Ajoutez lovable-i18n dans votre espace de travail Lovable, ou depuis un terminal exécutez npx skills add globalize-now/globalize-skills (ajoutez --all pour l'installer pour tous les agents).
2. Sollicitez Lovable. Demandez à Lovable de configurer l'i18n. La compétence le guide pour installer Lingui, extraire vos chaînes codées en dur, et créer les catalogues PO par locale.
3. Push. globalize.now récupère les catalogues et ouvre une PR de traduction avec vos langues cibles.
4. Merge. Votre application est multilingue, et chaque futur push maintient les traductions synchronisées.

Configurez-le une fois, synchronisation automatique à chaque push Git, aucune intervention manuelle requise. Le guide complet se trouve sur la page d'intégration Lovable, et il existe un guide séparé pour rendre votre application Lovable multilingue si vous voulez la version plus détaillée.

Combien coûte la meilleure approche ?

Le plan Starter de globalize.now coûte 20 €/mois par espace de travail, avec des projets illimités et des langues illimitées, y compris les langues RTL. Il inclut 20 € de crédit de traduction (environ 200 000 mots) par mois ; au-delà, l'usage continue au même tarif par caractère. Il n'y a aucun frais par siège ni par langue, et l'inscription s'accompagne d'un crédit de traduction de 5 € sans carte requise.

Ce n'est pas le prix affiché le plus bas de la catégorie, et ce n'est pas l'objectif. Les widgets en runtime facturent souvent par projet et verrouillent les langues derrière des paliers, donc un développeur qui déploie plusieurs petites applications Lovable paie à nouveau pour chacune. Facturer par espace de travail est précisément le principe : une application classique avec environ 10 000 clés de traduction sur 5 locales tient confortablement dans le volume inclus. La page tarifaire présente le détail du plan actuel.

La localisation Lovable en un coup d'œil