Comment ajouter la compétence lovable-i18n à un espace de travail Lovable ?

Vous l'ajoutez depuis GitHub : ouvrez Paramètres, puis Compétences, puis Ajouter, puis Importer depuis GitHub, et pointez Lovable vers le dépôt globalize-now/lovable-i18n. Lovable le télécharge, le valide, et le publie dans l'espace de travail, où chaque projet peut l'utiliser. globalize.now est une infrastructure de localisation propulsée par l'IA : elle produit les clés et les fichiers de traduction, et la librairie runtime de votre application les sert. La compétence est ce qui fait arriver cela sans jamais quitter l'éditeur Lovable, et c'est aussi la raison pour laquelle aucun dashboard n'apparaît dans le parcours.

Qu'est-ce qu'une compétence Lovable, exactement ?

Une compétence est un court playbook nommé que vous stockez une fois au niveau de l'espace de travail. Elle comporte trois parties : un nom permanent en minuscules, une description qui indique à Lovable quand la charger, et des instructions en markdown que Lovable suit lorsqu'elle s'applique.

La propriété importante est que les compétences se chargent à la demande. Les connaissances d'espace de travail sont différentes — elles restent toujours dans le contexte, ce qui convient aux standards de code et aux règles de marque. Une compétence n'entre dans la conversation que lorsque la demande correspond à sa description, donc un espace de travail peut en contenir plusieurs, ciblées, sans qu'aucune ne pèse sur un travail sans rapport.

Vous pouvez en invoquer une délibérément en tapant / dans le champ de chat et en la sélectionnant, ou laisser Lovable l'appliquer automatiquement quand votre prompt correspond. Pensez à la compétence comme au comment, et à votre prompt comme au quoi.

Elles sont aussi portables. Lovable utilise la même structure SKILL.md que la convention Agent Skills d'Anthropic, ce qui explique pourquoi une compétence écrite pour un outil s'importe dans l'autre sans conversion. Ce n'est pas un détail mineur pour la localisation : cela signifie que les mêmes instructions qui structurent l'i18n dans Lovable peuvent voyager vers un dépôt que vous ouvrez ensuite dans Claude Code ou Cursor.

Pourquoi une application Lovable ne parle-t-elle qu'anglais ?

Parce que le code généré n'a aucune couche de locales pour livrer autre chose. Quand vous demandez à Lovable une page de tarification, il écrit le titre en dur, directement dans le composant, dans la langue de votre prompt. Chaque bouton, chaque état vide, chaque toast et chaque message de validation atterrit de la même façon.

Demander à l'agent de « traduire l'application » plus tard produit un résultat à moitié fait : les écrans qu'il a par hasard inspectés se retrouvent traduits, et la prochaine fonctionnalité que vous construisez arrive de nouveau en anglais. Nous avons documenté cette récurrence en détail dans pourquoi les traductions Lovable dérivent, et le mécanisme n'a pas changé — l'agent résout le prompt qu'il a sous les yeux, pas l'architecture derrière.

La correction est structurelle et se fait une fois pour toutes : donner des clés aux chaînes, mettre les traductions dans des fichiers, faire lire ces fichiers par le runtime. Une compétence est un bon vecteur pour ce travail, précisément parce que c'est un guide fixe plutôt qu'un prompt qu'il faut formuler correctement à chaque fois.

Qu'est-ce que la compétence lovable-i18n installe ?

Lingui v6, avec des catalogues PO à src/locales/[locale]/messages.po, des macros Trans pour l'extraction, un composant de sélection de langue et une GitHub Action. Il détecte quelle stack utilise votre projet et échafaude en conséquence — SPA Vite ou TanStack Start, deux configurations que Lovable génère.

Cette détection de stack compte plus qu'il n'y paraît. La stack générée par défaut par Lovable est passée à TanStack Start avec rendu serveur, et le bon câblage i18n diffère entre une SPA rendue côté client et une application rendue côté serveur. Nous avons traité le cas du rendu serveur séparément dans le guide TanStack Start ; la compétence choisit le bon chemin pour vous éviter d'avoir à savoir lequel vous avez obtenu.

Ce qu'elle n'installe pas, c'est une dépendance runtime envers nous. Les catalogues sont des fichiers dans votre dépôt. Si vous supprimiez globalize.now demain, une application Lingui avec des fichiers PO commités continue d'afficher toutes les langues qu'elle possède déjà.

Comment importer la compétence ?

Quatre étapes, une seule fois par espace de travail.

1. Connectez le projet Lovable à GitHub. Utilisez le menu + dans le champ de saisie du chat, choisissez GitHub, puis Connect project. Les catalogues ont besoin d'un vrai dépôt pour exister.
2. Importez la compétence. Settings, puis Skills, puis Add, puis Import from GitHub, en pointant vers https://github.com/globalize-now/lovable-i18n. Le SKILL.md se trouve à la racine du dépôt, ce qui correspond à la structure attendue par Lovable lorsque vous lui fournissez une URL de dépôt entier. Un sous-répertoire au sein d'un dépôt de compétences plus large fonctionne aussi, avec une URL tree ou blob.
3. Ajoutez le MCP globalize. Ouvrez Connectors, choisissez Custom MCP, puis ajoutez https://api.globalize.now/mcp. La compétence vous guide dans l'étape de connexion le moment venu.
4. Prompt à Lovable. Demandez-lui d'utiliser la compétence lovable-i18n et le MCP globalize pour configurer l'i18n et traduire l'application.

Deux contraintes à connaître avant de commencer. La création, la modification, la suppression et l'importation de compétences personnalisées de l'espace de travail sont réservées aux propriétaires et administrateurs de l'espace de travail — les éditeurs peuvent voir et invoquer toutes les compétences, mais ne peuvent pas en ajouter. Et ajouter une compétence depuis Settings ne consomme pas de crédits ; le message qui l'utilise ensuite est facturé comme n'importe quel autre message de build.

Le pas-à-pas complet avec les URL exactes se trouve sur la page d'intégration Lovable.

De quel MCP s'agit-il, et lequel n'est-ce pas ?

C'est le point qui prête à confusion, et se tromper de sens fait perdre un après-midi.

Lovable expose deux surfaces MCP orientées dans des directions opposées. Le serveur MCP Lovable à mcp.lovable.dev permet à un agent extérieur — ChatGPT, Claude, Cursor, VS Code — de créer et modifier vos projets Lovable depuis ailleurs. Les connecteurs de chat, ajoutés sous Connectors en tant que MCP personnalisé, font l'inverse : ils permettent à l'agent Lovable de faire appel à un outil externe pendant que vous construisez.

Le MCP globalize est du second type. Vous donnez à l'agent Lovable la capacité de créer votre projet de localisation, de traduire les catalogues et de connecter le dépôt, sans avoir à ouvrir un second produit pour le faire. La documentation de Lovable elle-même établit explicitement cette distinction, ce qui montre bien que la confusion est fréquente.

Conséquence pratique : si vous vous retrouvez à coller une URL dans Claude ou Cursor pour faire fonctionner tout ça, vous êtes sur la mauvaise surface. Tout ce dont il est question ici se passe dans l'éditeur Lovable.

Que se passe-t-il après la première configuration ?

La compétence échafaude, et le diff se synchronise avec GitHub. Passez-le en revue comme n'importe quel autre changement — la config Lingui, les catalogues PO, les modifications de composants enveloppant les chaînes dans des macros Trans, le sélecteur de langue — puis fusionnez-le dans votre branche par défaut.

Ensuite, la conversion est terminée. Elle se fait une seule fois, dans l'application : vous avez connecté le dépôt, et globalize.now a converti la base de code une fois pour produire le catalogue. À partir de là, des jobs de push traduisent les nouvelles unités du catalogue et les livrent sous forme de pull request que vous fusionnez. Vous continuez à faire vos prompts à Lovable normalement ; les nouvelles chaînes atterrissent dans le catalogue au lieu de s'accumuler comme des littéraux non traduits.

Il n'y a ni étape d'export, ni étape d'import, ni écran où quelqu'un approuve les chaînes une par une. Pour l'argumentaire complet sur pourquoi cela compte, c'est dans localiser une application Lovable sans dashboard.

Pourquoi une compétence plutôt qu'un widget de traduction ?

Parce qu'un widget et un catalogue produisent des artefacts différents, et un seul des deux vous appartient.

Un widget runtime — le modèle Weglot — injecte du JavaScript qui réécrit le texte dans le navigateur une fois la page chargée. Vous obtenez un flash d'anglais, une mise en page qui bouge à mesure que les chaînes changent de longueur, et une seule page anglaise dans l'index, la traduction se faisant côté client là où un robot d'indexation ne la voit pas de façon fiable. Ça fonctionne sur n'importe quel site, ce qui est son véritable argument de vente, et c'est un choix raisonnable pour une page marketing dont vous ne contrôlez pas le code.

Un catalogue versionné est le compromis inverse. Il exige un accès au code, ce que vous avez, et en échange le balisage traduit est généré depuis votre propre dépôt, avec une page indexable par langue. Lovalingo s'est construit sur le modèle runtime spécifiquement pour Lovable et a fermé le 31 août 2026 ; si vous quittez cette solution, le guide de migration explique comment exporter ce que vous aviez. Cette fermeture est aussi l'argument le plus clair en faveur du format fichier : des catalogues PO dans votre historique Git ne dépendent pas de l'existence continue d'une entreprise.

Si vous voulez la version complète axée sur le résultat plutôt que sur le mécanisme, commencez par rendre une application Lovable multilingue. Si vous voulez connaître le coût avant de commencer, la page tarifaire présente les formules actuelles.

L'ajouter une fois

L'import est une action ponctuelle au niveau de l'espace de travail, et elle est gratuite. Ensuite, l'i18n devient quelque chose que vous demandez dans le champ de chat comme n'importe quelle autre fonctionnalité, et les traductions arrivent sous forme de fichiers qui vous appartiennent.