10 juillet 2026

• Markdown → JSONL Converter a traité la collecte de documents officiels JSONL, passant de 1180 à 1230 fichiers
• La pipeline de traduction multilingue a pris plus de retard que prévu, confirmant que la stabilisation peut prendre du temps
• J’ai testé la pipeline de synchronisation des documents multilingues dans un dépôt privé, et les critères que j’ai définis sont les suivants

Critères de structure des documents :

• Le document coréen sert de document de référence
• Les documents multilingues sont placés sous la forme docs/<lang>/…
• Les sous‑chemins qui se trouvaient directement sous docs/ sont considérés comme coréens et déplacés sous docs/ko/...
• Les codes de langue ne sont pas des codes arbitraires comme jp, ch mais des codes standards tels que ja, zh, pt-BR
• Le README.md à la racine reste le document racine
• La traduction du README est également traitée à la racine
• Les modifications du README.md ne doivent pas être propagées à tort comme modifications de fichiers dans docs/
• Les dossiers de langue existants comme docs/en, docs/ja ne doivent pas être imbriqués comme docs/ko/en
• Lors des tests de fichiers compressés, seuls le README et le dossier docs sont extraits et pris en compte

Critères de liens et de chemins :

• Les liens dans le README et dans les docs sont adaptés à la langue cible. Par exemple, le lien docs/ko/... du README coréen devient docs/en/... dans le README anglais
• Les chemins relatifs entre les documents internes sont également adaptés à la langue cible
• Les chemins d’image, les sous‑répertoires et les chemins relatifs ne doivent pas se casser pendant la traduction/synchronisation
• Les liens de langue du README doivent être présentés de façon à ce que l’utilisateur ait l’impression de passer ou de basculer vers le document de la langue correspondante

Critères de synchronisation automatique :

• Lorsqu’un fichier est ajouté dans docs/ko, un fichier correspondant est créé dans les autres langues
• Lorsqu’un fichier est supprimé dans docs/ko, le fichier correspondant est également supprimé dans les autres langues
• Lorsqu’un fichier spécifique de docs/ko est modifié, seul le fichier correspondant dans les autres langues est marqué pour régénération
• On ne traduit pas tout depuis le début à chaque fois
• Les langues/fichiers déjà traduits avec succès ne sont pas retraduits
• En cas d’échec, les livrables déjà réussis ne sont pas supprimés
• Seuls les fichiers en échec sont retirés et recréés lors de la prochaine exécution
• Les comparaisons de nombre de fichiers ou les simples fichiers de version permettent d’ignorer les dossiers de langue déjà corrects
• Les fichiers de version utilisent une forme simple comme v1 ou un nombre, plutôt que des JSON/hash complexes

Critères de traitement de la traduction :

• La traduction est testée avec l’API réelle
• Aucun traitement de succès factice (mock) n’est utilisé
• La taille des chunks est déterminée en fonction des limites officielles de contexte/sortie du modèle
• Il est plus important de tronquer la sortie de traduction pour qu’elle ne dépasse pas max_tokens que le contexte d’entrée
• Chaque chunk est vérifié immédiatement après traduction
• Les zones qui échouent lors de la vérification post‑traduction sont placées dans une file d’attente
• Les zones en échec sont découpées davantage (augmentation de profondeur) puis retraduites/revérifiées
• On évite les structures où tous les chunks sont rassemblés puis vérifiés une seule fois à la fin

Critères de vérification :

• Vérifier qu’il ne reste aucun texte coréen dans le résultat traduit
• Vérifier que les espaces n’ont pas disparu
• Vérifier que la structure Markdown est conservée
• Vérifier que les fences de code, les liens, les images et les en‑têtes sont préservés
• Les langues dont la longueur diminue (ex. le chinois) ne sont pas jugées uniquement par comparaison de longueur
• Lire le livrable final pour s’assurer qu’il n’y a pas d’anomalies par rapport à l’original

Critères de journalisation des échecs :

• Identifier les causes d’échec telles que HTTP 429, 504, RemoteDisconnected, finish_reason=length, réponses vides, etc.
• Consigner les en‑têtes de réponse, le corps de réponse, le temps écoulé, le nom du modèle, la taille de l’entrée et la consommation de tokens
• Un seul échec ne doit pas interrompre toute la pipeline ni faire disparaître les livrables
• En cas d’échecs répétés, analyser d’abord la cause

Critères d’utilisation de l’API NVIDIA :

• La pipeline de traduction est testée avec l’API NVIDIA
• gpt-oss-120b accepte un contexte d’entrée allant jusqu’à 128 k, mais la politique NVIDIA limite la sortie à environ 4096 tokens
• Même si l’on peut fournir de gros contextes, la sortie peut être tronquée ; la taille des chunks est donc basée sur la limite de sortie de 4096 tokens
• On tente jusqu’à 40 appels par minute, avec une politique d’attente/re‑essai en cas d’erreur

Critères de codage en dur :

• Utiliser des règles de structure telles que docs/<lang>, marqueurs, expressions régulières de liens, parsing des fences de code, etc.
• Ne pas remplacer ou supprimer arbitrairement des mots spécifiques
• Ne pas supprimer example.com de façon arbitraire
• Ne pas enregistrer chaque fichier de documentation individuellement via son chemin
• Ne pas forcer la substitution de formulations ou de mots spécifiques

Critères opérationnels :

• Examiner à la fois GitHub Actions et le runner auto‑hébergé Mac
• Même sur Mac, le flux doit se terminer par un commit/push automatique
• Offrir une visibilité similaire à GitHub Actions sur l’avancement
• Permettre de voir dans les logs quels langages/fichiers/chunks sont en cours de traitement
• Consigner clairement le nom de branche, l’URL du run, la cause de l’échec et le pourcentage d’avancement

En dehors de la traduction, j’ai récemment découvert un document intéressant :

• Pollinations APIDOCS.md a été consulté

• On peut appeler l’API avec curl sans clé et obtenir une réponse texte, ainsi que générer des images

• Cela pourrait permettre d’expérimenter sans créer de clé API ni craindre de facturation

• J’ai d’abord développé quelque chose d’amusant avec cela, et je prévois de le publier après l’avoir davantage testé

• La séparation de version du débogueur Qwen Validation Debugger a été réorganisée en structure de slots JSONL

  • docs_chunks sert de justification de code, donc on conserve des slots distincts pour le code Godot 3 et le code Godot 4
  • Au lieu de créer séparément des JSONL api_mapping et label_prototypes pour Godot 3 et Godot 4, on les combine en un JSONL de justification de conversion 3 → 4
  • La valeur attendue pour la validation du JSONL de conversion 3 → 4 est « Oui » pour le code Godot 3 et « Non » pour le code Godot 4
  • La valeur attendue pour le JSONL de conversion non pertinente est « Non » pour les deux codes Godot 3 et Godot 4

• Rétrospective : docs/retrospectives/2026-07-10.md