Cause racine (reproduite et verrouillee par test) : l'insertion PDF
demandait la police integree Helvetica tout en fournissant un fichier
de police — PyMuPDF ignore alors le fichier, et Helvetica n'a aucun
glyphe arabe : chaque lettre persane devenait un '?', et ces '?'
debordaient les boites d'origine (les nombreux « [translation
overflow] »). Defaut present dans toutes les versions deployees.
- le nom de police est desormais Personnalise quand un fichier de
police est fourni : le fichier est reellement integre
- reproduction complete avant/apres : 0 '?', 0 debordement, persan
rendu avec la police resolue
- test de non-regression : la page traduite ne contient PAS Helvetica
et le texte extrait n'a aucun '?'
- bouton « Reconstruire » de la relecture : une infobulle explique
desormais pourquoi il est grise (aucun segment approuve ni modifie),
dans les 13 langues
Un travail echoue ou expire cote serveur restait dans « Traductions
recentes » : sa page de relecture n'affichait rien (0 segments) avec une
erreur brute non traduite, et aucune suppression n'existait.
- serveur : nouvelle route DELETE /api/v1/translations/{job_id} —
retire le travail de la memoire et de Redis, supprime ses segments de
relecture ; idempotente (200 meme si le serveur avait deja oublie le
travail) ; refuse les travaux en cours (annuler d'abord) ; proprietaire
seul (404 pour le travail d'autrui, sans reveler son existence)
- interface : bouton corbeille sur chaque ligne des traductions recentes
(deux clics pour confirmer) qui nettoie la liste locale ET le serveur ;
l'historique serveur ne liste plus les travaux non termines
- page de relecture : message d'erreur traduit (fini le message brut) et
etat « rien a relire » explicite avec explication
- libelles ajoutes dans les 13 langues de l'interface
- 5 tests backend nouveaux (tests/test_delete_translation_history.py)
