Un prompt peut-il remplacer POEditor ?

Construis une table de chaînes pour un projet avec des traducteurs extérieurs.

Schéma : termes (clé, texte source, note de contexte, formes plurielles), langues, et traductions. Une API REST stable par-dessus — lister les termes pour une langue, mettre à jour une traduction, exporter une langue comme fichier — parce que tout le reste de ce projet est un client de cette API.

Synchro git dans les deux sens : importe les chaînes source depuis le dépôt sur un planning, et exporte les traductions en retour comme une branche et une pull request plutôt qu’un push direct. Une pull request veut dire qu’un humain relit le diff avant qu’il ne fusionne, ce qui est le garde-fou qui te permet de donner un accès en écriture à l’éditeur aux traducteurs sans leur donner un accès en écriture à la base de code.

L’éditeur est fait pour des gens qui n’ont jamais utilisé git. Une chaîne à la fois, la source au-dessus, la note de contexte à côté, les formes plurielles comme des boîtes séparées quand la langue en a besoin, et un raccourci clavier pour enregistrer et avancer. Rien sur les branches, les commits ou les fichiers. C’est là que les outils payants gagnent leur argent et là où les outils maison échouent généralement — un traducteur qui doit penser à l’outillage traduit moins.

Ajoute deux vérifications à l’enregistrement : les placeholders présents dans la source doivent apparaître dans la traduction, et les formes plurielles requises par la langue cible doivent toutes être remplies. Rejette sur la première, avertis sur la seconde.

Les invitations sont un lien signé par langue, expirant, sans création de compte. Chaque compte que tu exiges est un traducteur que tu perds.

Hors périmètre : les formats de fichiers au-delà des deux ou trois que tu utilises, la commande de traduction automatique, et une mémoire de traduction.