Votre app Lovable reste en anglais avec le SSR

Si votre app Lovable s’affiche en anglais quelle que soit la langue ajoutée, la cause vient du changement de stack : depuis la mi-mai 2026, les nouveaux projets Lovable utilisent TanStack Start avec rendu côté serveur, et non plus l’ancienne app monopage React et Vite. globalize.now est une infrastructure de localisation propulsée par l’IA qui s’intègre à cette nouvelle stack en extrayant vos chaînes dans des catalogues PO Lingui versionnés, afin que la bonne langue soit rendue côté serveur au lieu d’être remplacée dans le navigateur. La solution n’est pas d’ajouter un widget. Il faut déplacer la traduction dans votre repo, là où le serveur peut la rendre et les moteurs de recherche l’indexer.

---

Pourquoi la localisation de votre app Lovable est-elle soudainement devenue plus difficile ?

Parce que le terrain a changé sous les anciennes recommandations. La plupart des guides « traduire votre app Lovable » partent du principe qu’il s’agit d’une app monopage rendue côté client, où un widget peut réécrire le DOM après le chargement sans que personne ne le remarque. Cette hypothèse est désormais fausse pour les nouveaux projets.

Lovable est passé à TanStack Start avec SSR pour que les robots reçoivent du HTML entièrement rendu dès la première requête, sans exécution de JavaScript. C’est un vrai gain pour le SEO, mais cela inverse le fonctionnement de la traduction. Lorsque la première réponse est déjà rendue, la traduire ensuite dans le navigateur arrive trop tard.

Si vous avez créé votre app ces derniers mois et ajouté un widget de traduction à l’exécution, vous voyez le symptôme : un flash d’anglais, puis le remplacement. L’intégration de Lovable avec globalize.now existe précisément pour gérer cela au niveau où le problème doit être traité.

---

Qu’est-ce qui a réellement changé avec le passage de Lovable à TanStack Start ?

Le modèle de rendu est passé du côté client au côté serveur. Auparavant, Lovable générait des apps monopages basées sur React et Vite, déployées sous forme de fichiers statiques et entièrement rendues dans le navigateur. Désormais, la base est TanStack Start, un framework React full-stack avec SSR, SSG et CSR par route, ainsi que des fonctions serveur placées à côté des composants.

Pour la localisation, trois éléments comptent. Premièrement, le HTML est produit côté serveur avant d’atteindre le navigateur : la langue est donc déterminée côté serveur. Deuxièmement, le routage prend désormais en charge de véritables URL par locale. Troisièmement, tout ce qui dépend d’API accessibles uniquement dans le navigateur pour choisir une langue s’exécute après que le serveur a déjà arrêté son choix.

C’est ce troisième point qui est à l’origine de la plupart des configurations défaillantes. Une locale enregistrée dans localStorage est invisible pour le serveur : celui-ci rend donc la langue par défaut, puis le client la corrige un instant plus tard.

---

Pourquoi les widgets de traduction à l’exécution affichent-ils brièvement l’anglais avec le SSR ?

Parce qu’ils traduisent après que le serveur a déjà envoyé l’anglais. Sur la nouvelle stack, la séquence est la suivante : le serveur rend le HTML dans la langue par défaut, le navigateur l’affiche, puis le JavaScript du widget se charge et réécrit le texte. L’intervalle entre l’affichage et le remplacement est le flash d’anglais. Il est désormais structurel, et non lié à un problème de réglage.

Le coût SEO est plus important que le flash. Un robot lit la première réponse, puis passe à autre chose. Si le texte traduit n’apparaît qu’après l’exécution du JavaScript côté client, le robot indexe l’anglais pour chaque locale et vous n’obtenez aucune page par langue à classer. Toute la raison du passage de Lovable au SSR — du HTML indexable — est annulée par une traduction effectuée dans le navigateur.

Les catalogues versionnés évitent ce problème par conception. Lorsque les chaînes de traduction résident dans votre repo, TanStack Start génère la locale demandée côté serveur : la première réponse est donc correcte. C’est la différence durable entre une infrastructure intégrée à votre codebase et un widget qui s’exécute par-dessus. C’est aussi pourquoi les outils runtime comme Weglot conviennent mieux à l’ancien modèle SPA qu’au nouveau. Pour une analyse plus approfondie du problème de synchronisation, consultez pourquoi les traductions Lovable cassent à chaque push.

---

Comment rendre multilingue une app Lovable basée sur TanStack Start ?

Déplacez la traduction côté serveur et conservez les catalogues dans votre repo. Concrètement, cela représente quatre étapes avec la nouvelle stack, sans modifier manuellement le moindre fichier de locale.

1. Ajoutez la compétence lovable-i18n et laissez Lovable configurer l’i18n. Dans votre espace de travail Lovable, ajoutez la compétence lovable-i18n, puis demandez à Lovable de configurer l’internationalisation. Il installe Lingui, extrait vos chaînes d’interface codées en dur dans des catalogues de messages et configure le provider. En dehors de l’éditeur, la même configuration s’installe avec npx skills add globalize-now/globalize-skills (ajoutez --all pour l’installer pour tous les agents).
2. Gérez les locales avec le paramètre de chemin facultatif de TanStack. TanStack Router utilise {-$locale} pour les paramètres de chemin facultatifs. Une route définie comme /{-$locale}/about correspond donc à /about pour votre langue par défaut et à /es/about pour l’espagnol. Chaque langue dispose ainsi d’une URL distincte, explorable par les moteurs de recherche, au lieu d’une seule URL dont le texte change dans le navigateur.
3. Résolvez la locale côté serveur, pas dans localStorage. Stockez la langue active dans un cookie afin que le gestionnaire SSR puisse la lire dans la requête. Avec Lingui, le serveur appelle setupLocaleFromRequest() avant de créer le routeur, puis l’hydratation côté client appelle dynamicActivate() avec la locale fournie par le serveur avant le rendu. La même valeur des deux côtés signifie aucun mismatch d’hydratation et aucun flash.
4. Conservez les catalogues dans votre repo et synchronisez-les à chaque push. Les catalogues PO sont des fichiers versionnés, pas le runtime d’un fournisseur. À mesure que vous développez dans Lovable et que de nouvelles chaînes apparaissent, il faut les extraire et les traduire à nouveau — c’est précisément la partie qui finit par rouiller lorsqu’elle est faite à la main. C’est le travail que globalize.now automatise, pour que les catalogues restent à jour sans étape d’export manuel.

// server: resolve locale before the router exists
const locale = getLocaleFromCookie(request) ?? "en";
await setupLocaleFromRequest(locale);

// client: activate the SAME locale before first render
await dynamicActivate(serverLocale);

Comme il s’agit d’une procédure réelle, étape par étape, avec une sortie versionnée, elle se comporte comme du code standard géré par version : révisable dans une pull request, comparable dans un diff et portable si vous quittez un jour Lovable.

---

Quelle est la place de globalize.now dans la stack i18n de TanStack Start ?

globalize.now se situe sous la bibliothèque runtime et au-dessus du moteur de traduction. TanStack Start et Lingui servent les traductions au runtime ; DeepL ou un LLM produit les traductions elles-mêmes. globalize.now est l’infrastructure intermédiaire : elle génère les clés et les catalogues PO, puis les maintient synchronisés afin que le runtime ait toujours quelque chose de correct à afficher.

Concrètement, pour une personne qui construit avec Lovable, cela signifie que vous cessez de surveiller les fichiers de locale. Vous installez la compétence, demandez une fois à Lovable de configurer le tout, puis chaque push suivant extrait les nouvelles chaînes, complète les catalogues et ouvre la modification sous forme de PR normale. Aucun aller-retour dans un dashboard, aucun nouvel export, aucun décalage entre le texte affiché par votre app et le contenu de vos catalogues.

La tarification tient en un seul forfait : 20 € / mois par espace de travail, avec 20 € de crédit de traduction inclus par mois — soit environ 200 000 mots — puis une consommation facturée au token, au même tarif par caractère. Aucun frais par siège ni par langue. L’inscription inclut 5 € de crédit, sans carte bancaire. Une app Lovable classique sur cinq locales reste largement dans cette enveloppe. Pour les détails côté développement, les pages globalize.now pour les développeurs et vibe coders vont plus loin ; la présentation du produit couvre le reste de la stack.

---

Votre app Lovable reste en anglais parce que la traduction intervient au mauvais endroit : dans le navigateur, après que le serveur a déjà choisi une langue. Déplacez-la dans votre repo et le serveur génère la bonne langue dès la première requête. globalize.now gère l’extraction et la synchronisation : vous configurez une fois, puis tout reste à jour à chaque push.