10 juillet 2026 | idea_world

Nous avons fait passer la quantité de documents officiels JSONL convertis avec le Markdown → JSONL Converter de 1180 à 1230.
Le pipeline de traduction multilingue a été plus retardé que prévu, ce qui montre qu’il peut falloir beaucoup de temps pour atteindre la stabilisation.
Nous avons testé le pipeline de synchronisation des documents multilingues dans un dépôt privé, et les critères que nous avons établis 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 des documents de référence coréens et sont déplacés sous docs/ko/....
Les codes de langue utilisent les codes standards tels que ja, zh, pt-BR et non des codes arbitraires comme jp ou ch.
Le README.md à la racine reste le document racine.
Les traductions du README sont également traitées à partir de la racine.
Les modifications du README.md ne doivent pas être propagées à tort comme des 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 pour les liens et les 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’images, les liens de sous‑répertoires et les chemins relatifs ne doivent pas se casser pendant la traduction ou la 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 chaque autre langue.
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é, seules les versions correspondantes dans les autres langues sont marquées pour régénération.
On ne traduit pas tout le projet à chaque exécution.
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 dossiers de langue déjà à jour, détectés par comparaison du nombre de fichiers ou d’un simple fichier de version, sont ignorés.
Le fichier de version utilise une forme simple comme v1 ou un numéro, plutôt qu’un JSON ou un hash complexe.

Critères de traitement de la traduction :

La traduction est testée avec l’API réelle.
Aucun traitement « mock » de succès n’est utilisé.
La taille des chunks est déterminée en fonction des limites officielles de contexte et de sortie du modèle.
Il est plus important de tronquer la sortie de traduction pour qu’elle ne dépasse pas max_tokens que de respecter la taille d’entrée.
Chaque chunk est vérifié immédiatement après traduction.
Les zones qui échouent lors de la vérification immédiate sont placées dans une file d’attente.
Les zones en échec sont découpées davantage (augmentation de la profondeur) avant d’être retraduites et revérifiées.
On évite une architecture où l’on ne vérifie qu’une seule fois à la fin après avoir recombiné tous les chunks.

Critères de vérification :

S’assurer qu’aucun texte coréen ne subsiste 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.
Pour les langues comme le chinois, dont la longueur diminue, on ne se base pas uniquement sur la comparaison de longueur.
Lire le livrable final pour s’assurer qu’il n’y a pas d’anomalies par rapport à l’original.

Critères des journaux d’échec :

Identifier les causes d’échec telles que HTTP 429, 504, RemoteDisconnected, finish_reason=length ou réponses vides.
Consigner dans le journal les en‑têtes de réponse, le corps de réponse, le temps écoulé, le nom du modèle, la taille d’entrée et la consommation de tokens.
Un seul échec ne doit pas interrompre tout le 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 :

Le pipeline de traduction est testé 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 blocs d’entrée, la limite de sortie peut tronquer la traduction ; le critère réel est donc la restriction de sortie à 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 :

On utilise des règles structurelles comme docs/<lang>, des marqueurs, des expressions régulières pour les liens et le parsing des fences de code.
Aucun mot ne doit être remplacé ou supprimé arbitrairement.
example.com ne doit pas être supprimé arbitrairement.
On n’enregistre pas chaque fichier de documentation individuellement via son chemin.
On ne force pas la substitution de tournures ou de mots spécifiques.

Critères opérationnels :

On examine à la fois les GitHub Actions et les runners auto‑hébergés macOS.
Même sur macOS, le flux se termine par un commit/push automatique.
On rend le suivi de progression visible comme dans GitHub Actions.
Les logs doivent indiquer quels langages/fichiers/chunks sont en cours de traitement.
Le nom de branche, l’URL du run, la cause de l’échec et le pourcentage d’avancement doivent être clairement consignés.

En dehors de la traduction, nous avons découvert un document intéressant récemment.

Nous avons consulté Pollinations APIDOCS.md.
Même sans clé API, on peut appeler l’API avec curl et obtenir une réponse texte ; la génération d’images semble également possible.
Cela pourrait permettre d’expérimenter légèrement sans craindre de facturation.
Nous avons d’abord développé quelque chose d’amusant avec cela, et nous prévoyons de le publier plus tard après l’avoir davantage testé.
Nous avons réorganisé la structure des slots JSONL de séparation de version du Qwen Validation Debugger :
- docs_chunks constitue la base de l’explication du 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 api_mapping et label_prototypes pour Godot 3 et Godot 4, on les regroupe dans un même JSONL servant de base de conversion 3 → 4.
- Les valeurs attendues pour la validation du JSONL de conversion 3 → 4 sont : « Oui » pour le code Godot 3 et « Non » pour le code Godot 4.
- Les valeurs attendues pour le JSONL de conversion neutre sont : « Non » tant pour le code Godot 3 que pour le code Godot 4.
Rétrospective : docs/retrospectives/2026-07-10.md