Comment rendre une application Replit multilingue sans dashboard ?

Vous rendez une application Replit multilingue en connectant son dépôt Git à GitHub et en gardant les catalogues de traduction dans ce dépôt sous forme de fichiers commités. Replit stocke déjà chaque checkpoint de l'Agent comme un commit Git, donc le dépôt existe avant même que vous pensiez aux langues ; le travail consiste à le faire migrer vers GitHub et à laisser les catalogues revenir par le même historique. globalize.now est une infrastructure de localisation propulsée par l'IA : elle produit les clés et les fichiers de traduction, et la bibliothèque runtime que votre application utilise déjà les sert. Aucun dashboard ne se trouve sur le chemin runtime, et rien ne traduit la page après son chargement.

Pourquoi demander à l'Agent de traduire l'application ne fonctionne-t-il pas ?

Parce qu'il n'y a rien vers quoi traduire. Quand vous demandez à Replit Agent un dashboard, il écrit <h2>Your bookings</h2> dans un composant, pas une recherche dans un catalogue. Chaque titre, bouton, état vide, toast et erreur de validation atterrit en JSX sous forme de littéral dans la langue de votre prompt.

Donc, quand vous demandez plus tard à l'Agent de « traduire l'application en afrikaans », vous obtenez l'un de ces deux résultats à moitié : une seconde copie des composants avec le texte remplacé, ou un objet translations fait main couvrant les écrans que l'Agent a examinés. Ni l'un ni l'autre n'est une couche de locales. La prochaine fonctionnalité arrive de nouveau en anglais. Nous avons documenté la même récurrence dans Cursor n'arrête pas d'ajouter des chaînes codées en dur ; Replit Agent ne se comporte pas différemment, car il résout le prompt qu'il a sous les yeux, pas l'architecture derrière.

La correction est structurelle : donner des clés aux chaînes, mettre les traductions dans des fichiers, et faire lire ces fichiers par le runtime. C'est ce que « multilingue » signifie dans une base de code, et c'est un changement ponctuel.

Que génère réellement Replit Agent ?

Un projet web conventionnel, ce qui est une bonne nouvelle. Les types d'applications proposés par Replit sont construits autour de React avec ShadCN UI côté front-end, généralement associé à un serveur Express dans le même projet, le tout en TypeScript. Depuis septembre 2025, l'Agent fonctionne aussi avec n'importe quel framework que vous apportez, y compris des dépôts GitHub importés, ce qui rend possible un projet Next.js ou Vue ; le chemin par défaut reste la stack React.

Pour la localisation, la stack est le seul fait qui compte, et c'est un terrain standard. React plus Vite plus TypeScript est la combinaison la plus prise en charge dans l'écosystème i18n : i18next, Lingui et react-intl la ciblent tous directement. Si l'Agent vous a construit une application Next.js à la place, le choix se fait entre next-intl, react-i18next et Lingui, et cette comparaison fait l'objet d'un article séparé.

Ce qui diffère d'un générateur front-end seul, c'est la seconde moitié du projet. Une application Replit a généralement un serveur, et les serveurs ont eux aussi des chaînes. Plus de détails ci-dessous.

Où se trouve le dépôt Git dans une application Replit ?

Il est déjà là. Le contrôle de version de Replit repose sur Git en dessous, et les checkpoints de l'Agent sont des commits dans ce dépôt. Chaque fois que l'Agent termine une fonctionnalité et vous propose un point de retour en arrière, il a effectué un commit. La documentation de Replit elle-même recommande de passer à des commits Git ordinaires pour le suivi à long terme lorsque vous travaillez avec des dépôts externes, ce qui est exactement la situation ici.

Pour le faire migrer vers GitHub :

1. Ajoutez l'outil Git depuis la section Tools de l'éditeur de projet.
2. Connectez votre compte GitHub sous les services connectés, puis connectez le dépôt depuis le panneau Git. Si le projet n'a jamais été initialisé, le panneau propose de le faire en premier.
3. Poussez. Le panneau pousse en un clic, et il reste synchronisé avec tout ce que vous exécutez dans le Shell, donc git push origin main fonctionne aussi.

Replit prend aussi en charge GitLab et Bitbucket, et le même flux s'applique. Le fournisseur n'est pas le point important ; ce qui compte, c'est que le dépôt vit désormais quelque part où un job de localisation peut ouvrir une pull request sur lui.

Faites cela avant de toucher la moindre chaîne. Le travail de localisation est un travail de fichiers, et un diff est le bon endroit pour le passer en revue.

Que signifie « sans dashboard » pour une application Replit ?

Cela signifie que les chaînes traduites sont des fichiers dans le dépôt, et que l'application les sert comme n'importe quel autre asset. Pas de balise script, pas de récupération externe au chargement de la page, pas de compte fournisseur entre un visiteur et votre contenu.

L'alternative est un widget runtime qui remplace le texte une fois la page affichée. Ses coûts sont structurels : le premier affichage est en anglais, le contenu traduit ne figure pas dans le HTML que les robots d'indexation lisent en premier, un script tiers se trouve sur votre chemin de production, et vos chaînes vivent dans le stockage du fournisseur, si bien que partir implique un export. La version Lovable de cet argument se trouve dans Localiser une application Lovable sans dashboard et s'applique à Replit sans changement.

Il y a une raison spécifique à Replit pour laquelle cela compte encore plus ici. Replit déploie l'application pour vous, si bien que la copie en cours d'exécution sur votre domaine Replit correspond exactement à ce qui se trouve dans le projet au moment du déploiement. Un widget traduirait ce déploiement depuis l'extérieur. Des catalogues dans le dépôt signifient que le déploiement contient déjà toutes les langues, et l'aperçu Replit vous montre la version allemande avant même que vous la mettiez en ligne.

Le compromis est réel et mérite d'être dit : un changement de texte implique un commit et un redéploiement, pas un simple bouton d'enregistrement. Pour un développeur solo qui livre depuis Replit, ce n'est pas un problème ; pour quelqu'un qui s'attend à modifier du contenu en direct sans toucher au projet, c'est une contrainte.

Comment fonctionne une configuration native du repo ?

Connectez le dépôt dans l'application globalize.now. La conversion s'exécute une fois sur l'ensemble du code : les chaînes codées en dur deviennent des unités de catalogue avec des clés, et les composants se mettent à lire depuis une bibliothèque runtime au lieu de contenir des littéraux. C'est une opération ponctuelle, pas quelque chose qui se relance ensuite.

Après la conversion, des jobs de push traduisent les nouvelles unités de catalogue à mesure que l'application évolue. Demandez à l'Agent une nouvelle page de paramètres, poussez, et les nouvelles unités sont traduites ; les unités existantes restent inchangées. Les catalogues reviennent sous forme de fichiers commités, JSON ou PO selon la bibliothèque runtime, dans une pull request que vous examinez comme n'importe quelle autre modification.

Deux frontières, parce que la catégorie prête à confusion. globalize.now ne remplace pas la bibliothèque runtime ; i18next, Lingui et next-intl continuent de faire leur travail. Et ce n'est pas un moteur de traduction qui concurrence DeepL. C'est la couche intermédiaire qui produit les clés et les fichiers de locale. L'aperçu développeur détaille les mécanismes.

Comment les traductions reviennent-elles dans Replit ?

Via le même panneau Git, dans l'autre sens. C'est l'étape qui diffère de Bolt ou Lovable, car Replit est aussi l'endroit où l'application s'exécute.

1. Examinez et fusionnez la pull request sur GitHub.
2. Dans le panneau Git de Replit, sélectionnez Pull. Si vous ou l'Agent avez modifié les mêmes fichiers entre-temps, le panneau met en évidence les conflits et vous les résolvez dans l'éditeur avant de finaliser la fusion.
3. Redéployez. Les catalogues font désormais partie du projet, donc le déploiement embarque toutes les langues.

Une mise en garde spécifique à Replit : les checkpoints de l'Agent restaurent l'état complet du projet, fichiers compris. Si vous revenez à un checkpoint créé avant d'avoir tiré la branche de traduction, les catalogues repartent avec lui. Traitez la fusion comme une étape clé, laissez l'Agent créer un checkpoint juste après, et revenez à celui-ci plutôt qu'à un checkpoint antérieur.

Quelles chaînes vivent sur le serveur ?

Celles que le front-end ne voit jamais sous forme de JSX. Une application Replit avec un back-end Express possède une seconde surface de chaînes : messages d'erreur d'API, réponses de validation, objets d'e-mail, corps de notifications, en-têtes CSV, tout ce que le serveur formate avant de l'envoyer. Un catalogue front-end ne les atteint pas, et un widget ne peut pas les voir du tout, car elles ne sont jamais dans le DOM.

Le principe est le même que côté client, appliqué côté serveur. Donnez au serveur une copie de la bibliothèque runtime, lisez la locale du visiteur depuis la requête (un en-tête Accept-Language ou un champ locale sur l'enregistrement utilisateur), et formatez les réponses à partir du catalogue plutôt que de littéraux. L'espace de noms des clés reste partagé, donc errors.booking.overlap signifie la même chose dans un toast et dans une réponse 409.

Négligez cela et l'application aura l'air multilingue jusqu'à la première erreur, où elle se remettra à parler anglais.

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

Passez en revue ces points avant la conversion, car chacun coûte moins cher à corriger maintenant qu'une fois cinq langues déjà en production :

• Chaînes concaténées. "Welcome back, " + user.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 est incorrect dans la plupart des langues.
• Dates, nombres et devises. Utilisez Intl, pas du formatage de chaînes, aussi bien côté client que côté serveur.
• Mise en page. L'allemand et le finnois sont plus longs que l'anglais. Les boutons à largeur fixe cassent, et les classes Tailwind ont l'air correctes jusqu'à l'arrivée du texte réel.
• Droite à gauche. Si l'arabe ou l'hébreu est sur la feuille de route, décidez-le maintenant. Rajouter le RTL après coup est ce qui coûte le plus cher.
• Dérive des catalogues. Une fois les catalogues en place, une clé ajoutée dans une locale et absente des autres est un bug silencieux. Pourquoi les fichiers de traduction dérivent explique comment cela arrive et ce qu'un job de push y change.

La tarification est par espace de travail, sans frais par utilisateur ni par langue, donc le nombre de langues relève d'une décision produit plutôt que d'une ligne budgétaire. Les tarifs actuels sont sur la page tarification. Pour le même parcours sur d'autres builders, l'aperçu pour vibe coders est le point de départ.

Par où commencer

Si votre projet Replit est déjà connecté à GitHub, l'étape suivante est une conversion sur ce dépôt, pas une décision d'outillage. S'il n'est pas encore connecté, le panneau Git est l'étape qui précède celle-ci.