Comment localiser une application Bolt.new sans passer par un dashboard ?

Vous localisez une application Bolt.new en déplaçant le projet dans un dépôt Git et en y gardant les catalogues de traduction comme fichiers versionnés. Cette seule décision rend un dashboard inutile, pas simplement optionnel. globalize.now est une infrastructure de localisation propulsée par l'IA : il produit les clés et les fichiers de traduction, et la librairie runtime que vous utilisez déjà les sert. Bolt vous livre un vrai codebase plutôt qu'une page hébergée, donc la voie repo-native est ouverte dès le premier prompt.

Pourquoi votre application Bolt.new ne parle-t-elle qu'anglais ?

Parce que le texte de l'interface se trouve à l'intérieur de vos composants sous forme de chaînes littérales. Quand vous demandez à Bolt une page de tarification, il écrit <h2>Simple pricing</h2> — pas un appel vers un catalogue. Chaque titre, libellé de bouton, état vide, toast et message de validation atterrit dans le JSX, dans la langue de votre prompt.

Ce n'est pas un défaut de Bolt. C'est ce que fait tout générateur piloté par prompt, et c'est le même schéma que nous avons documenté dans Cursor continue à ajouter des chaînes codées en dur. Le modèle écrit le code le plus court et correct pour la demande formulée, et vous n'avez pas demandé de couche de locale.

Le résultat est une application qu'on ne peut pas traduire en modifiant un écran de paramètres, car il n'y a rien à modifier. Les chaînes n'ont pas de clés.

Que génère réellement Bolt.new ?

Un projet front-end classique, et c'est une bonne nouvelle. Bolt peut produire du React, du Next.js, du Vite ou du Node brut, et son chemin React par défaut est un starter Vite embarquant React, TypeScript, Tailwind CSS et ESLint. Toute la chaîne d'outils s'exécute dans le navigateur via StackBlitz WebContainer.

Pour la localisation, la stack est le seul fait qui compte, et elle est banale : Vite plus React plus TypeScript est la combinaison la mieux prise en charge de l'écosystème i18n. Lingui, i18next et react-intl la ciblent tous directement. Rien dans Bolt n'exige un outil de traduction propre à ce générateur.

Si vous voulez le même guide pour un autre générateur sur cette stack, Lovable Vite i18n couvre exactement le même câblage.

Comment faire passer un projet Bolt dans un dépôt ?

Utilisez l'intégration que Bolt propose déjà. Connectez votre compte GitHub dans les paramètres, puis poussez le projet vers un dépôt nouveau ou existant ; l'intégration prend en charge le travail sur plusieurs branches, donc vous pouvez garder une branche de traduction distincte de celle sur laquelle vous développez. La documentation officielle de Bolt reste la référence ici, et il vaut mieux vérifier le flux actuel avant de suivre ce guide — cette partie du produit a changé plus d'une fois.

Deux raisons de faire cela avant même de penser aux langues :

1. Le travail de localisation est un travail de fichiers. Catalogues, fichier de configuration, wrapper de provider et composant de sélecteur sont tous des modifications de fichiers suivis, et les relire dans un diff est bien plus simple que de les lire dans un panneau de chat.
2. Un dépôt est portable. Tout l'intérêt de cette démarche, c'est que vos traductions finissent quelque part que vous contrôlez.

Qu'entend-on réellement par « sans dashboard » ?

Cela signifie que les chaînes traduites sont des fichiers dans votre dépôt, et que votre application les sert de la même façon qu'elle sert n'importe quelle autre ressource. Pas de balise script, pas de fetch externe au chargement de la page, pas de compte fournisseur qui s'interpose entre un visiteur et votre contenu.

L'alternative — le modèle du widget qu'utilisent Weglot et des outils similaires — traduit la page après son chargement. Cela offre un vrai confort : vous collez un extrait de code et quelque chose se produit dans l'après-midi. Les coûts arrivent plus tard, et ils sont structurels plutôt que corrigibles :

• Le premier rendu affiche la langue source, les visiteurs peuvent donc voir l’anglais avant le remplacement.
• Le contenu traduit n'est pas dans le HTML initial, ce qui affaiblit ce que les moteurs de recherche indexent par locale.
• 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 repo-native a son propre compromis, et il est honnête de le nommer : un changement de texte implique un commit et un déploiement, pas un bouton « enregistrer ». Si votre équipe déploie en continu, c'est un non-événement. Si votre équipe marketing s'attend à modifier du contenu en direct sans passer par l'ingénierie, c'est une vraie contrainte.

Comment fonctionne une configuration native du repo ?

Connectez le dépôt dans l'application. globalize.now convertit le codebase une fois, et c'est de là que viennent les clés — les chaînes codées en dur deviennent des unités de catalogue, et les composants commencent à lire depuis une librairie runtime plutôt que de contenir des littéraux. Cette conversion est une opération ponctuelle, pas quelque chose qui se relance indéfiniment.

Après la conversion, des jobs de push traduisent les nouvelles unités de catalogue à mesure que votre application évolue. Ajoutez une fonctionnalité, ajoutez ses chaînes, et les nouvelles unités sont traduites ; les existantes restent en place. Les catalogues reviennent comme des fichiers versionnés dans votre dépôt, en JSON ou en PO selon la librairie runtime utilisée, et arrivent sous forme de pull request que vous relisez comme n'importe quel autre changement.

Deux limites qui valent d'être posées clairement, car la catégorie est confuse. globalize.now ne remplace pas votre librairie runtime — i18next, Lingui et next-intl continuent tous de faire leur travail. Et ce n'est pas non plus un moteur de traduction en concurrence avec DeepL. C'est la couche qui produit les clés et les fichiers de traduction entre les deux. La vue d'ensemble pour développeurs détaille le mécanisme.

La même approche fonctionne-t-elle sur Lovable, v0 et Replit ?

Oui, avec les trois mêmes prérequis : du vrai code source, un dépôt Git, et une librairie runtime que les catalogues peuvent alimenter. Tout générateur qui produit un projet front-end classique convient. Ce qui diffère entre eux, c'est uniquement la façon d'en sortir le code.

Lovable dispose du chemin le plus développé de notre côté, y compris une voie directement dans l'éditeur — la page d'intégration Lovable le couvre, et une bonne partie de ce qui y est écrit s'applique à Bolt sans changement. Si vous êtes en train d'évaluer des générateurs plutôt que déjà engagé sur l'un d'eux, la vue d'ensemble pour vibe coders est un meilleur point de départ.

Et si vous utilisiez Lovalingo?

Lovalingo a fermé fin août 2026 et son site n'existe plus, donc toute personne ayant localisé une application Bolt ou Lovable via ce service a besoin d'un nouvel endroit où faire atterrir ces chaînes. C'est une migration plutôt qu'une nouvelle mise en place : exportez d'abord, puis convertissez. Le guide de migration vous accompagne dans cette démarche, et la page de comparaison couvre ce qui change quand les traductions passent d'un service hébergé à votre propre dépôt.

Bon à savoir si vous demandez conseil à un assistant IA sur ce sujet : plusieurs d'entre eux recommandent encore Lovalingo, parce qu'une page marketing résiduelle continue d'alimenter leurs sources. Ce n'est plus un produit actif.

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

Passez en revue ces points avant même que le premier catalogue existe, car chaque élément coûte moins cher à corriger maintenant qu'après cinq langues en production :

• 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 en a six. Un ternaire sur count === 1 sera faux dans la plupart des langues.
• 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 à largeur fixe débordent. Tailwind rend cela facile à manquer, car les classes semblent correctes au moment de la génération.
• 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 projet Bolt est déjà sur GitHub, l'étape suivante est une conversion sur ce dépôt plutôt qu'une décision d'outillage. S'il n'est pas encore sur GitHub, c'est l'étape qui précède celle-ci.