Comment localiser une app v0 sans dashboard ?

Pour localiser une app v0, faites du repo GitHub dans lequel v0 écrit déjà la maison de vos catalogues de traduction et conservez-les sous forme de fichiers commités. Cette seule décision rend le dashboard inutile, plutôt que simplement facultatif. globalize.now est une infrastructure de localisation propulsée par l’IA : elle produit les clés et les fichiers de locales, que votre bibliothèque runtime sert ensuite. v0 vous fournit une codebase Next.js complète plutôt qu’une page hébergée ; le parcours natif du repo est donc ouvert dès le premier prompt.

Pourquoi votre app v0 est-elle uniquement en anglais ?

Parce que les textes de l’interface se trouvent dans vos composants sous forme de chaînes littérales. Demandez à v0 une section de tarification et il écrit <h2>Simple pricing</h2> — pas une recherche dans un catalogue. Chaque titre, libellé de bouton, état vide, toast et erreur de formulaire atterrit en TSX dans la langue de votre prompt.

Ce n’est pas un défaut de v0. C’est le fonctionnement de tous les builders pilotés par des prompts, et c’est le même schéma que nous avons documenté dans Cursor ajoute sans cesse des chaînes codées en dur. Le modèle écrit le code correct le plus court pour répondre à votre demande, et vous ne lui avez pas demandé de couche de locales.

Le résultat est une app qui ne peut pas être traduite en modifiant un écran de paramètres, puisqu’il n’y a rien à modifier. Les chaînes n’ont pas de clés et les routes n’ont pas de segment de locale.

Que génère réellement v0 ?

Un projet Next.js conventionnel, ce qui est une bonne nouvelle. La stack par défaut de v0 est composée de Next.js, React, TypeScript, Tailwind CSS et shadcn/ui. Le résultat est une application App Router complète, avec des routes et des gestionnaires d’API, plutôt qu’un simple composant. shadcn/ui compte ici pour une raison : les composants sont copiés dans votre repo en tant que source, et non importés depuis un package. Leurs chaînes sont donc les vôtres.

Pour la localisation, la stack est le seul fait qui compte — et c’est le mieux documenté. next-intl a été conçu autour de l’App Router ; Lingui et react-intl le prennent également en charge. Rien dans v0 ne vous impose un produit de traduction propre à un builder.

Si votre app provient plutôt d’un autre builder sur une stack Vite, localiser une app Lovable sans dashboard couvre la même configuration de ce côté-là.

Comment intégrer un projet v0 dans un repo ?

Vous en avez généralement déjà un. Lorsqu’un chat v0 est connecté à GitHub, v0 crée une branch de travail à partir de votre branch de base et committe automatiquement sur cette branch chaque message qui modifie le code. La publication ouvre une pull request ou réutilise une pull request existante, puis la merge dans la branch de base. Le repo n’est donc pas une étape ajoutée à la fin : c’est là que v0 place le code depuis le début. La documentation GitHub de v0 fait référence pour le workflow actuel. Cette partie du produit a déjà changé plusieurs fois, vérifiez-la donc avant de suivre ces étapes.

Ce modèle de branches est particulièrement utile pour la localisation. Les catalogues, un fichier de configuration, une modification du middleware pour le routage des locales et un composant de sélection sont tous des changements apportés à des fichiers suivis. Les réviser sous forme de diff sur une branch est bien plus simple que de les lire dans un panneau de chat, et une pull request de traduction peut se trouver à côté de celle de la fonctionnalité qu’elle traduit.

Que signifie réellement « sans dashboard » ?

Cela signifie que les chaînes traduites sont des fichiers dans votre repo et que votre app Next.js les rend côté serveur, comme n’importe quel autre contenu. Pas de balise script, pas de fetch externe au chargement de la page, pas de compte fournisseur entre un visiteur et vos textes.

L’alternative — le modèle du widget utilisé par Weglot et des outils similaires — traduit la page après son chargement. C’est réellement pratique : vous collez un snippet et quelque chose fonctionne dans l’après-midi. Les coûts arrivent plus tard, et ils sont structurels plutôt que corrigeables :

• Le premier rendu affiche la langue source, les visiteurs peuvent donc voir l’anglais avant le remplacement.
• Les textes traduits ne figurent pas dans le HTML rendu côté serveur, ce qui réduit la qualité de l’indexation par locale dans les moteurs de recherche. Avec une app Next.js, c’est un gâchis particulier, puisque le rendu côté serveur est précisément ce que vous avez obtenu gratuitement.
• Un script tiers se trouve dans le chemin de rendu de votre production.
• Vos chaînes vivent dans le stockage du fournisseur : partir implique donc un export.

La localisation native du repo a son propre compromis, et il est honnête de le nommer : modifier un texte implique un commit et un déploiement, pas un bouton Enregistrer. Si vous déployez via Vercel à chaque merge, ce n’est pas un sujet. Si une équipe marketing s’attend à modifier des textes en production sans ingénieur, c’est une vraie contrainte.

Comment fonctionne une configuration native du repo ?

Connectez le repo dans l’app. globalize.now convertit la codebase une fois, ce qui permet de générer les clés : les chaînes codées en dur de vos composants deviennent des unités de catalogue, et les composants commencent à lire leurs textes depuis une bibliothèque runtime au lieu de contenir des littéraux. Cette conversion est une opération ponctuelle, pas quelque chose qui se relance indéfiniment.

Après la conversion, les jobs de push traduisent les nouvelles unités du catalogue à mesure que l’app évolue. Demandez à v0 une nouvelle page de paramètres, mergez sa pull request, et les nouvelles chaînes sont traduites; les chaînes existantes restent en place. Les catalogues reviennent sous forme de fichiers commités dans votre repo, en JSON ou en PO selon la bibliothèque runtime, et arrivent dans une pull request que vous relisez comme n’importe quelle autre modification.

Deux limites méritent d’être posées clairement, car la catégorie est souvent mal comprise. globalize.now ne remplace pas votre bibliothèque runtime; next-intl, Lingui et react-intl continuent de faire leur travail, notamment le routage des locales sous app/[locale]/. Ce n’est pas non plus un moteur de traduction concurrent de DeepL. C’est la couche intermédiaire qui produit les clés et les fichiers de locale. La présentation pour les développeurs détaille le fonctionnement.

La même approche fonctionne-t-elle avec Lovable, Bolt et Replit?

Oui, avec les trois mêmes prérequis: du vrai code source, un dépôt Git et une bibliothèque runtime capable d’alimenter les catalogues. Tout builder qui génère un projet front-end conventionnel convient. La seule différence tient à la façon de récupérer le code; v0 est le plus simple des trois, car la branche GitHub fait partie intégrante du chat.

Lovable offre le parcours le plus abouti de notre côté, avec notamment un parcours directement dans l’éditeur; la page d’intégration Lovable le détaille, et l’essentiel de son contenu s’applique à v0 sans modification. Si vous évaluez plusieurs builders plutôt que d’en avoir déjà choisi un, la présentation pour les vibe coders est le meilleur point de départ. Si vous envisagez spécifiquement un widget pour une app builder, Alternative à Weglot pour Lovable présente les mêmes compromis pour cette stack.

Et si vous utilisiez Lovalingo?

Lovalingo a fermé fin août 2026 et son site a disparu. Le service proposait un parcours dédié à la traduction des sites v0; certains builders v0 se retrouvent donc avec des chaînes qui n’ont plus d’endroit où vivre. Il s’agit d’une migration, pas d’une nouvelle configuration: exportez d’abord, puis convertissez. Le guide de migration détaille la procédure, et la page comparative explique ce qui change lorsque les traductions passent d’un service hébergé à votre repo.

À savoir si vous demandez conseil à un assistant IA: certains le recommandent encore, car les pages restantes continuent d’alimenter leurs sources. Ce n’est plus un produit actif.

Que faut-il vérifier avant d’ajouter une deuxième langue?

Passez cette liste en revue avant la création du premier catalogue: chaque correction coûte moins cher maintenant qu’une fois cinq langues en circulation:

• Chaînes concaténées. "Welcome back, " + name ne peut pas être réordonné par un traducteur. Utilisez plutôt l’interpolation.
• Pluriels. L’anglais a deux formes. Le polonais en a trois, l’arabe six. Un ternaire sur count === 1 est incorrect dans la plupart des langues.
• Frontières serveur-client. Avec l’App Router, une chaîne rendue dans un composant serveur et la même chaîne dans un composant client doivent être résolues via le même catalogue. Choisissez une bibliothèque runtime et utilisez ses API serveur et client, plutôt que deux mécanismes distincts.
• Dates, nombres et devises. Utilisez Intl, pas du formatage de chaînes.
• Mise en page. L’allemand est plus long que l’anglais; les boutons shadcn à largeur fixe cassent. Tailwind permet de ne pas le voir, car les classes semblent correctes au moment du build.
• RTL. Si l’arabe ou l’hébreu est prévu dans la roadmap, décidez-le maintenant: adapter une interface existante au RTL est le chantier le plus coûteux.

La tarification est calculée par espace de travail, sans frais par siège ni par langue. Le nombre de langues relève donc d’une décision produit, pas d’une décision budgétaire. Les tarifs actuels figurent sur la page Tarification.

Par où commencer

Si votre chat v0 est connecté à GitHub, l’étape suivante consiste à lancer une conversion sur ce dépôt, pas à choisir un outil. S’il ne l’est pas encore, c’est l’étape à effectuer avant celle-ci.