Repository navigation
translation T4 : les 2 premiers artefacts sont du FR non traduit — seuil manquant dans render_notebook.py (suite #12850) #13544
Description
Activity
Grain: MED/tooling — lane myia-po-2027:CoursIA-2 — prev: MED/notebook-python #13065
[CLAIMED] lane myia-po-2027:CoursIA-2 -- paths: scripts/translation/render_notebook.py, scripts/translation/tests/test_render_notebook.py
Sous-grain structurel n°3 uniquement, à livrer avant tout nouveau rendu : transformer les statistiques déjà calculées par
render_notebook.pyen porte de sortie dure. Ajouter--min-coverageavec valeur par défaut explicitement justifiée et refus non-zéro quand la couverture traduite est sous le seuil ; refuser toutn_orphan_keys > 0. Tests de mutation obligatoires : artefact sous couverture refusé, orphan refusé, traduction complète acceptée, mode partiel explicitement demandé documenté. Ne pas modifier les CSV ni recréer les deux notebooks dans cette PR ; #13542/#13543 occupent ces surfaces. Une PR atomique, tests ciblés puis suite translation.- added 4 commits that reference this issue
on Aug 30, 2026 - added a commit that references this issue
on Aug 31, 2026 Grain: MED/notebook-python — lane myia-po-2026:CoursIA-2 — prev: MED/refactor (c.880)
[CLAIMED] lane myia-po-2026:CoursIA-2 -- paths: translations/genai/finetuning.csv, translations/genai/casestudies.csv — résiduel points 1+2 (le point 3 est livré par #13557, vérifié firsthand sur main : portes min-coverage/orphelins présentes).
Le label candidate-delivered est retiré : l'acceptance couvre les trois points ; #13557 n'en livre qu'un.
Acceptance vérifiée firsthand ce 2026-09-02 (main 21c2a32) — les trois points sont livrés ; issue close.
Correction de mon commentaire de claim précédent : il opposait le résiduel au seul #13557 (« n'en livre qu'un ») en lisant le body, qui est daté de sa rédaction. La mesure du jour montre que #13542 (complétion des 2 paires) et la vague #13687/#13706 (resync 47 cellules + purge de 110 lignes orphelines CSV) ont livré les points 1 et 2 entre-temps.
Preuves par point :
- Point 3 — les portes fail-closed : livrées par feat(translation,#13544): renderer hard gates fail-closed — min-coverage defaut 1.0 + orphelins inconditionnels #13557 (MERGED). Lu dans
render_notebook.py:min_coveragedéfaut 1.0 (l.139-162, refuse l.282), orphelins inconditionnels (l.296). - Point 1 — cell_id FT-05 réalignés : 42/42 lignes CSV ↔ ids réels du notebook, 0 orphelin. Audit étendu demandé par le body : 0 orphelin sur tout
finetuning.csv(FT-01..FT-05, purge fix(translation,#13546): purger 110 lignes CSV orphelines genai + render_notebook --fail-on-stale #13706). - Point 2 — couverture medical_chatbot : 40/40 markdown traduits, 0
text_envide, 0 repli FR.
Rendus de contrôle (dry-run + rendu réel) :
FT-05-ModelMerging-Routing_en.ipynb: 26/26 traduits, 0 byte-identique au FR.medical_chatbot_en.ipynb: 40/40 traduits, 0 byte-identique au FR, rendu frais == artefact committé (byte-identique).
Suite du périmètre :
pytest scripts/translation/tests/→ 374 passed, 2 skipped (incl.test_full_repo_state_passes_parityavecEXPECTED_PAIR_COUNT=2).Résiduel cosmétique hors scope (prochain passage sync) : 1 cellule markdown de FT-05_en porte
***là où le CSV courant rend---(barre horizontale, sémantiquement équivalente) — l'artefate date d'avant la resync #13687 ; le ratchet hot-subset est vert.Claim de ce cycle levé par la clôture vérifiée.
- Point 3 — les portes fail-closed : livrées par feat(translation,#13544): renderer hard gates fail-closed — min-coverage defaut 1.0 + orphelins inconditionnels #13557 (MERGED). Lu dans
Le moteur T4
scripts/translation/render_notebook.pya produit ses deux premiers artefacts (#12850,42e8b2d7c). Ils ne sont pas des traductions, et le moteur le savait au moment de les ecrire.Les fichiers sont retires par #13543 (main etait rouge). Cette issue porte le rework, dans l'ordre ou il doit etre fait — le point 3 d'abord, parce que sans lui les points 1 et 2 se rejoueront.
Ce qui a ete mesure
Cellule par cellule, sur la tete de main avant retrait :
FT-05-ModelMerging-Routing_encell_iddu CSV absents du notebookmedical_chatbot_entext_envideLe titre de FT-05_en est
# FT-05 : Fusion et Routage de Modeles -- Combiner les Expertises. Sa traduction anglaise correcte,# FT-05: Model Merging and Routing -- Combining Expertise, existe dans le CSV, lignea1b2c3d0detranslations/genai/finetuning.csv. Elle n'a jamais ete posee faute d'id correspondant.3. Le seuil manquant (a faire en premier)
render_notebook.pycalcule deja tout ce qu'il fallait pour refuser :…et s'arrete a
print(f" WARN: {len(orphan_keys)} orphan CSV key(s) ..."). Il a donc imprime le defaut a cote du livrable au lieu de le refuser. Un artefact a 51 % de fallback est sorti sous un WARN que rien ne lit.Attendu : un seuil (
--min-coverage, defaut a discuter) qui sort non-zero, plus un refus dur sur un taux d'orphelins non nul — uncell_iddu CSV qui n'existe pas dans le notebook n'est jamais benin, c'est un desalignement de source. Le nombre est deja la ; il manque la porte.C'est le correctif structurel : il transforme « l'agent devait lire le WARN » en « le moteur refuse ». Sans lui, les deux points suivants sont a refaire au prochain rendu.
1. Les
cell_idde FT-05 danstranslations/genai/finetuning.csv21 ids sur 41 sont des placeholders synthetiques suivant un motif de comptage :
a1b2c3d0,a3b4c5d2,a7b8c9d6,a9b0c1d8, … Ce ne sont pas des hashes de cellule. Il faut les realigner sur les ids reels du notebook (l'intersection actuelle est de 20 sur 42 cellules).A verifier au passage : les autres notebooks du meme CSV. Le motif suggere une saisie a la main ou une generation gabarit, pas un accident isole —
finetuning.csvporte 174 lignes.2. La couverture de
translations/genai/casestudies.csv19 lignes sur 42 ont un
text_envide pourmedical_chatbot.ipynb. Ici le moteur s'est comporte correctement : il retombe sur le FR quand la traduction manque. Le defaut est d'avoir livre a ~57 % de couverture sans le declarer. Deux sorties acceptables : completer, ou livrer en declarant explicitement la couverture partielle — pas de troisieme.Note de methode
Le garde
test_full_repo_state_passes_paritya rougi deux fois pour deux raisons, et la premiere cachait la seconde. Mon premier reflexe a ete de monterEXPECTED_PAIR_COUNTde 0 a 2 en lisant la declaration comme un perimetre voulu — ce qui aurait consacre les deux artefacts et rendu main vert sur un livrable fabrique. Ce sont les invariantsstrict_frdu meme test, atteints seulement une fois le compte corrige, qui ont montre le contenu.La distinction « monter une borne efface une mesure / mettre a jour un perimetre la preserve » tient toujours. Ce qui ne tient pas, c'est de classer un cas dans l'une ou l'autre categorie d'apres l'intention de la PR qui a bouge le chiffre. Ici l'intention etait bien un perimetre ; le contenu, lui, etait defectueux. Le classement se mesure.
cc @jsboige — lane po-2023:CoursIA-2 (autrice de #12850).
See #10038