Comment localiser une application Base44 sans passer par un dashboard ?

Vous localisez une application Base44 en la connectant à GitHub via la synchronisation bidirectionnelle fournie par Base44, et en conservant les catalogues de traduction dans ce dépôt sous forme de fichiers commités. Base44 reflète déjà chaque modification entre l'éditeur et le dépôt, donc dès que les fichiers de traduction atterrissent sur la branche main, ils font partie de l'application. 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 d'exécution de votre projet les sert. Aucun dashboard ne se trouve sur le chemin d'exécution, et rien ne traduit la page après son chargement.

Pourquoi votre application Base44 est-elle anglophone uniquement ?

Parce que le texte d'interface se trouve à l'intérieur de vos composants sous forme de chaînes littérales. Quand vous demandez à Base44 une page de réservations, il écrit <h2>Your bookings</h2> dans un composant React, pas une recherche dans 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 Base44. C'est ce que fait tout builder piloté par prompt, et c'est le même schéma que nous avons documenté dans Cursor continue d'ajouter des chaînes codées en dur. Le modèle écrit le code correct le plus court pour la demande que vous avez faite, et vous n'avez pas demandé de couche locale.

Demander à Base44 de « traduire l'application en allemand » ne règle pas le problème non plus. Vous obtenez une copie en allemand des écrans que le modèle a inspectés, ou un petit objet de chaînes qu'il invente sur le moment. Le prompt suivant réécrit du texte en anglais, car rien dans le projet n'impose que le texte passe par un catalogue.

Que génère réellement Base44 ?

Un projet React standard construit avec Vite. La documentation de Base44 sur la structure des projets montre l'organisation que vous obtenez dans l'onglet Code et dans un dépôt connecté : src/pages contient un fichier par route, donc Home.jsx devient / et Settings.jsx devient /settings ; src/components contient les éléments réutilisables avec un dossier ui/ de composants prêts à l'emploi ; src/api, src/hooks, src/lib et src/utils contiennent le client SDK, les hooks et les fonctions utilitaires.

Deux répertoires comptent plus que les autres pour la localisation. functions/ contient votre logique backend, un fichier TypeScript par fonction, et ces fichiers formatent du texte que les utilisateurs lisent : réponses d'erreur, e-mails, documents générés. entities/ contient votre modèle de données sous forme de fichiers JSON schema, et sous la synchronisation bidirectionnelle, les entités sont gérées dans Base44 plutôt que dans le dépôt.

Une application Base44 possède donc deux surfaces de chaînes que les catalogues peuvent couvrir, le client React et les fonctions backend, et une qu'ils ne peuvent pas couvrir, les données à l'intérieur des entités. Ce dernier point revient plus loin.

Comment faire entrer une application Base44 dans un dépôt ?

Base44 fournit la connexion. Dans l'éditeur, ouvrez le Dashboard, cliquez sur l'icône GitHub, et connectez-vous. Vous autorisez l'application Base44 Builder sur votre compte ou organisation GitHub, choisissez les dépôts auxquels elle peut accéder, et créez un nouveau dépôt pour l'application. À partir de là, le dépôt et l'éditeur restent alignés dans les deux sens.

Deux règles de la documentation Base44 structurent tout ce qui suit. Premièrement, la synchronisation est automatique : les changements que vous faites dans Base44, y compris ceux que l'IA fait à partir d'un prompt, sont commités dans le dépôt sans étape de push, et il n'existe aucun bouton pour pousser manuellement. Deuxièmement, le chemin retour passe par la branche main. Tout ce qui est fusionné vers main devient visible dans l'application Base44, et master ou tout autre nom de branche par défaut n'est pas pris en charge. Après une fusion, vous cliquez sur Publish pour rendre la nouvelle version accessible aux utilisateurs.

La synchronisation bidirectionnelle nécessite le plan Builder ou supérieur, et seul le propriétaire de l'application peut établir la connexion initiale. Si votre compte avait configuré l'ancienne intégration Export vers GitHub à sens unique, le panneau GitHub propose un lien pour la déconnecter et la reconnecter avec la synchronisation bidirectionnelle ; le chemin à sens unique ne ramène jamais rien dans l'éditeur, alors que c'est exactement le sens dont la localisation a besoin.

Pour travailler en local, clonez le dépôt, exécutez npm install, installez le CLI Base44, puis base44 login et base44 link pour relier le clone à son application. base44 dev fait tourner le frontend contre un backend local. La fusion de votre branche locale vers main est ce qui la resynchronise.

Que signifie « sans tableau de bord » pour une application Base44 ?

Cela signifie que les chaînes traduites ne vivent jamais dans un service hébergé que votre application doit appeler ou dont vous devez exporter les données. Elles vivent dans src/locales/de.json à côté de src/pages/Home.jsx, versionnées dans les mêmes commits, revues dans les mêmes pull requests, et déployées par le même clic sur Publish.

Les approches alternatives ont chacune un coût spécifique sur Base44. Un widget d'exécution qui traduit la page dans le navigateur laisse la source intacte, donc le dépôt continue d'indiquer que l'application est en anglais, et chaque visiteur subit le délai de traduction au chargement. Un outil de traduction hébergé avec son propre éditeur conserve la vérité en dehors du dépôt, donc la synchronisation bidirectionnelle construite par Base44 synchronise une base de code qui ne contient pas les langues. Les deux placent un second système entre vous et un texte qui vit déjà dans des fichiers que vous possédez.

L'approche native au dépôt utilise la synchronisation telle qu'elle a été conçue. Les catalogues sont des fichiers. Les fichiers sont commités. Les fichiers commités atteignent main. main atteint l'éditeur. C'est tout le pipeline, et rien de tout cela n'est spécifique à la localisation.

Comment fonctionne une configuration native du repo ?

Connectez le dépôt dans l'application et lancez la conversion une seule fois. La conversion trouve les chaînes littérales dans vos composants et vos fonctions backend, leur attribue des clés, câble une bibliothèque d'exécution comme i18next ou Lingui si le projet n'en a pas, et ouvre une pull request sur votre dépôt avec le catalogue source et les premières langues cibles. Cette pull request constitue toute la passation. Passez-la en revue sur GitHub comme n'importe quelle autre modification, fusionnez-la vers main, et Base44 la reflète dans l'éditeur.

À partir de là, des jobs de push traduisent les nouvelles unités de catalogue. Quand vous demandez à Base44 une nouvelle fonctionnalité et que la synchronisation la commite, toute nouvelle clé du catalogue source est traduite et livrée sous forme de pull request. Fusionnez-la, cliquez sur Publish, et la fonctionnalité est en ligne dans toutes les langues. Rien dans vos habitudes de prompt n'a besoin de changer, et rien dans votre application n'appelle un service externe à l'exécution.

La même approche fonctionne sur Lovable, Bolt, v0 et Replit, et la mécanique est identique car les quatre vous livrent un projet frontend conventionnel. Le guide pas à pas Lovable détaille le plus la structure des catalogues, le guide Bolt couvre l'étape d'export pour un builder sans synchronisation native, et le guide Vite pour la stack classique de Lovable est le plus proche du résultat React et Vite de Base44 au niveau du code. Si vous comparez les builders plutôt que d'être déjà engagé sur l'un d'eux, le tour d'horizon des vibe coders est un meilleur point de départ.

Quelles chaînes vivent dans les fonctions backend ?

Tout ce qu'un utilisateur lit et qui est produit côté serveur. Une erreur de validation renvoyée par une fonction, l'objet d'un e-mail qu'elle envoie, le corps d'un PDF qu'elle génère, le texte d'une notification. Ces chaînes n'apparaissent jamais en JSX, donc un catalogue frontend ne les contient pas et un widget d'exécution ne peut pas les voir.

Le schéma est le même que côté client. Lisez la locale demandée depuis la requête entrante, chargez le catalogue correspondant côté fonction, et partagez l'espace de noms des clés avec le client afin qu'un message ait le même sens dans l'UI et dans une réponse d'API. Comme le répertoire functions/ se trouve dans le dépôt, la conversion traite ces fichiers comme n'importe quelle autre source, et les catalogues se placent à côté.

Qu'en est-il du contenu à l'intérieur des entités ?

C'est la limite spécifique à Base44. Les entités constituent votre modèle de données, gérées à l'intérieur de Base44, et sous la synchronisation bidirectionnelle, elles ne font pas partie du dépôt. Un enregistrement comme un nom de produit, une description de service ou un article d'aide, c'est de la donnée, pas du texte d'interface, et aucun catalogue ne le contiendra jamais.

Le contenu de données a besoin d'une dimension linguistique sur l'entité elle-même : un champ de locale, ou un champ par langue, et des requêtes qui lisent la locale du visiteur. Le principe est le même que celui que nous décrivons pour le contenu en base de données dans les applications Lovable, et c'est une décision de modèle de données que vous prenez dans l'éditeur d'entités Base44, pas une décision d'outil de localisation. Planifiez-la tôt, car ajouter un champ de langue à une entité qui contient déjà des enregistrements demande plus de travail que de l'ajouter à une entité neuve.

Et si vous utilisiez Lovalingo?

Lovalingo a fermé fin août 2026, et ses cas d'usage publiés incluaient Base44 aux côtés de Lovable, v0 et Bolt. Quiconque a localisé une application Base44 via ce service doit trouver un endroit où faire atterrir ces chaînes. Il s'agit d'une migration plutôt que d'une nouvelle configuration : exportez d'abord, puis convertissez. Le guide de migration vous accompagne pas à pas, et la page de comparaison décrit ce qui change quand les traductions passent d'un service hébergé à votre propre dépôt.

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

Vérifiez que la synchronisation est bidirectionnelle, et non l'ancien export. Ouvrez le panneau GitHub dans Base44 et vérifiez qu'il signale un dépôt connecté ; s'il propose le lien « Vous cherchez l'ancienne configuration ? », vous êtes sur le chemin à sens unique et devez vous reconnecter.

Vérifiez que votre branche par défaut est main. Base44 ne reflète que cette branche, donc une pull request fusionnée ailleurs n'atteint jamais l'éditeur.

Cherchez une bibliothèque d'exécution. Si vous avez demandé des langues à Base44 à un moment donné, il a peut-être ajouté i18next ou un contexte fait maison ; la conversion conserve ce qui est en place et l'alimente.

Décidez où le contenu des entités obtiendra son champ de langue avant d'ajouter des enregistrements dans une seconde langue. Les catalogues ne feront pas ce travail à votre place.

Vérifiez votre routage. Les pages Base44 sont basées sur des fichiers, donc un préfixe de locale dans l'URL est une décision de routage que vous prenez une seule fois, et elle détermine comment les moteurs de recherche voient chaque langue. Le guide sur le sélecteur de langue et hreflang couvre ces choix et ils s'appliquent directement.

Par où commencer

Activez la synchronisation GitHub bidirectionnelle dans Base44 si ce n'est pas déjà fait, vérifiez que la branche est main, et connectez le dépôt dans l'application. La première pull request convertit la base de code. Tout ce qui suit se résume à une fusion, un clic sur Publish, et les langues que vous avez demandées. La page d'intégration Lovable décrit le même flux pour un builder disposant d'une route intégrée à l'éditeur, et l'essentiel de ce qui y est écrit s'applique à Base44 sans modification.