Comment exporter mes traductions depuis Lovalingo avant son arrêt ?

Demandez dès maintenant votre export de sauvegarde à Lovalingo, puis convertissez les bundles de traduction en catalogues PO versionnés dans votre propre repo. Lovalingo prépare les exports des projets actifs, et le support est assuré via [email protected] jusqu’à la fermeture du service, le 31 août 2026 à 23:59 CEST. globalize.now est une infrastructure de localisation propulsée par l’IA : elle récupère les chaînes que vous avez sauvées, génère les fichiers de locales dans votre repo et les synchronise à chaque Git push. Ce sera donc le dernier export de traduction que vous aurez à effectuer.

Que deviennent mes traductions lorsque Lovalingo ferme le 31 août ?

Toutes les langues, sauf votre langue source, cessent de s’afficher, car le texte traduit n’a jamais été intégré à votre app. Lovalingo est une couche de runtime : votre app Lovable est livrée en anglais, puis son service remplace le texte selon le visiteur. Quand le service s’arrête, le remplacement s’arrête aussi.

Les conditions de fermeture sont publiques sur la page d’arrêt du service de Lovalingo. Les nouveaux projets et abonnements sont déjà désactivés. Les projets actifs continuent de fonctionner jusqu’au 31 août 2026 à 23:59 CEST. La collecte des paiements est suspendue et les exports de sauvegarde des projets actifs sont en préparation.

Cette échéance est surtout une échéance de données. Après la date limite, il n’y aura plus de service depuis lequel exporter, ni de boîte de support à contacter. Si votre app reçoit aujourd’hui du trafic en français ou en allemand, le travail qui a produit ces traductions disparaîtra, à moins de l’extraire d’abord.

Comment récupérer mes données de traduction depuis Lovalingo ?

Demandez votre export de sauvegarde et conservez-le avec votre dépôt source. Selon la page de fermeture, les exports contiennent la configuration disponible du projet, les routes, les bundles de traduction, les remplacements manuels et les preuves d’intégrité : tout ce que le runtime savait de vos langues.

1. Demandez l’export. Les exports des projets actifs sont en préparation. Si vous n’avez pas encore reçu le vôtre, écrivez à [email protected] pour demander l’envoi de l’export de votre projet.
2. Conservez ces deux éléments ensemble : le fichier d’export et un instantané de votre dépôt source actuel. L’export décrit les traductions ; le repo est l’app à laquelle elles appartiennent.
3. Ne désinstallez pas encore Lovalingo. Ses propres recommandations indiquent de le laisser installé jusqu’à ce que votre remplacement ait passé les vérifications en production. Les deux systèmes peuvent fonctionner côte à côte pendant la transition.

Les bundles de traduction sont la partie la plus importante. Ils contiennent les chaînes effectivement traduites pour chaque locale, ainsi que les remplacements manuels effectués dans leur dashboard. Ces remplacements sont souvent oubliés : ces modifications n’existent que dans Lovalingo, pas dans un moteur de traduction automatique que vous pourriez relancer.

Comment convertir les bundles Lovalingo en catalogues détenus par mon repo ?

Convertissez les bundles en catalogues gettext PO et versionnez-les. Le PO est du texte brut, ses diffs sont propres dans Git et c’est le format que Lingui compile pour les apps React — ce qui couvre les deux stacks générées par Lovable : la SPA Vite classique et la nouvelle configuration SSR par défaut avec TanStack Start.

Les bundles de runtime sont généralement des maps clé-valeur par locale. La conversion tient dans un petit script, pas dans un projet :

// convert.mjs — JSON bundle → PO entries
import fs from "node:fs";

const locale = process.argv[2]; // e.g. "de"
const bundle = JSON.parse(fs.readFileSync(`bundles/${locale}.json`, "utf8"));

const po = Object.entries(bundle)
  .map(([source, translated]) =>
    `msgid ${JSON.stringify(source)}\nmsgstr ${JSON.stringify(translated)}\n`)
  .join("\n");

fs.writeFileSync(`src/locales/${locale}/messages.po`, po);

Les noms exacts des champs varient selon l’export : vérifiez le vôtre avant d’exécuter quoi que ce soit. Le principe, lui, ne change pas : chaîne source en entrée, paire msgid/msgstr en sortie, un fichier .po par locale, versionné sous src/locales/.

Si convertir tout cela à la main ne vous tente pas, le guide de migration Lovalingo couvre le parcours géré, avec trois mois d’utilisation gratuits pour les personnes qui migrent depuis Lovalingo pendant la période de fermeture.

Comment intégrer les catalogues récupérés à mon app Lovable ?

Ajoutez la compétence lovable-i18n à votre espace de travail Lovable, puis demandez à Lovable de configurer l’i18n ; la compétence connecte Lingui à votre stack et récupère les catalogues PO que vous avez versionnés. En dehors de l’éditeur Lovable, la même configuration s’installe avec :

npx skills add globalize-now/globalize-skills

Les détails de l’intégration dépendent de votre stack. Les apps générées avant mai 2026 sont principalement des SPA Vite classiques ; les plus récentes utilisent par défaut TanStack Start avec SSR. Un guide dédié existe pour chacune : i18n pour les apps Lovable sous Vite et i18n avec la stack TanStack Start de Lovable. La page d’intégration Lovable explique le fonctionnement complet de la compétence.

À partir de là, le problème de maintenance que Lovalingo résolvait au runtime est résolu directement dans votre repo. Les nouvelles chaînes que vous livrez sont extraites, traduites et versionnées sous forme de PR de traduction à chaque push. Le tarif est de 20 € / mois par espace de travail, avec 20 € de crédit de traduction inclus — environ 200 000 mots par mois — puis une consommation facturée au token, au même tarif par caractère : aucun frais par siège ni par langue. Ajouter votre sixième locale coûte donc autant que votre deuxième. Conçu pour les vibe coders qui ne veulent plus jamais penser aux fichiers de locales.

Que dois-je tester avant de supprimer Lovalingo ?

Testez d’abord le remplacement dans des conditions de production ; la suppression vient en dernier, pas en premier. La séquence de vérification pré-suppression de Lovalingo constitue une bonne checklist et s’applique directement à une configuration avec catalogues versionnés :

• URL directes des locales. Chaque langue doit être accessible via une vraie route (/de/, /fr/) qui se charge après un hard refresh, et pas uniquement via un changement côté client.
• Clés manquantes et fallbacks. Supprimez localement une traduction et vérifiez que l’app revient à la chaîne source au lieu d’afficher un espace vide.
• Métadonnées SEO par locale. Vérifiez les titres, descriptions, URL canoniques, paires hreflang et le sitemap pour chaque langue. Les routes de locales rendues côté serveur sont visibles par les crawlers sans passage JavaScript ; le guide pour rendre votre app Lovable multilingue détaille cette configuration.
• Supprimez ensuite le widget. Une fois la version avec catalogues versionnés validée, retirez Lovalingo et relancez les vérifications.

Un avantage discret de cette transition : aucun élément de cette checklist ne peut régresser parce qu’un fournisseur modifie ses forfaits. Les catalogues sont désormais des fichiers dans votre historique Git.

Votre export est un sauvetage ponctuel. globalize.now en fait le dernier : configurez-le une fois, et vos catalogues restent extraits, traduits et versionnés à chaque Git push.