Un prompt peut-il remplacer Crowdin ?

Construis un gestionnaire de traductions pour les deux ou trois formats de fichiers que tu utilises réellement.

Choisis-les explicitement — JSON avec clés imbriquées, gettext .po, et un troisième — et écris un parseur et un sérialiseur pour chacun. Le sérialiseur est la moitié difficile et celle à tester en premier : parse un fichier, sérialise-le sans modification, et vérifie l’égalité octet par octet. Si un aller-retour n’est pas identique au bit près, chaque commit de traduction transporte du bruit de formatage et les relecteurs arrêtent de les lire.

Synchronise avec git plutôt qu’avec une API : récupère les fichiers source sur un planning, compare-les aux chaînes en base, et ajoute les nouvelles clés comme non traduites. Marque les chaînes dont le texte source a changé comme à revoir plutôt que de garder silencieusement l’ancienne traduction — une traduction périmée d’une source modifiée est le bug qui arrive jusqu’aux utilisateurs.

L’éditeur affiche la clé, la source, les traductions existantes dans d’autres langues pour le contexte, et le fichier et la ligne d’où elle vient. Ajoute la traduction automatique uniquement comme suggestion, clairement identifiée, jamais enregistrée comme valeur sans qu’un humain ne l’accepte.

Réécris sous forme d’un commit par langue sur une branche, en ne touchant que les positions de valeurs. Ne laisse jamais l’écrivain réordonner les clés, réécrire les guillemets ou retirer les commentaires — que le diff git reste relisible est tout le contrat entre cet outil et les développeurs qui doivent le merger.

Stocke une mémoire de traduction sous forme de correspondance exacte plus similarité par embeddings sur les paires précédentes, et propose les correspondances à 90 % et plus.

Hors périmètre : les formats que tu n’utilises pas, une place de marché de prestataires, et les intégrations avec des outils de design.