[🛠] Pourquoi le Codex Goal du blog multilingue a dépassé 13 heures

✨ Résumé de GPT-5.5 　

Récit de l’exécution du Codex Goal qui a fait passer hyuk.blog d’une version anglaise /en/ à des règles d’exploitation pour huit locales, avec traduction, changement de langue, vues partagées, règle p et coût d’usage.

Au début, je pensais seulement devoir choisir /en/

La première question était simple.

en.hyuk.blog serait-il mieux ?
/en/ serait-il mieux ?

Après avoir pesé le SEO, l’exploitation sur GitHub Pages, le lien entre original et traductions, le partage des vues et la structure de langues à étendre ensuite, la conclusion a été /en/.

Je ne voulais pas exploiter la version anglaise comme un produit complètement séparé. Ce blog part d’originaux coréens auxquels on ajoute des traductions. Dans ce cas, séparer les URL de langue dans le même domaine et les relier avec hreflang est plus simple.

Mais cela ne s’est pas arrêté là.

Dès que j’ai choisi /en/, l’accueil, About, les catégories, la recherche, le sitemap, le language switcher, les vues, la qualité de traduction et même la manière de pousser les futurs articles ont commencé à bouger ensemble.

Ce n’était pas un fichier traduit, mais une frontière de collection

Les articles anglais ne pouvaient pas être mélangés dans _posts.

Dans Jekyll, _posts entre dans site.posts. Si les articles anglais y sont mélangés, l’accueil coréen, le feed, la pagination et les related posts les consomment aussi en silence. Cela ressemble à un article de plus, mais l’index entier du blog est contaminé.

Les articles traduits ont donc été séparés dans des collections par locale.

_posts/...         -> /daily-review/.../
_en_posts/...      -> /en/daily-review/.../
_ja_posts/...      -> /ja/daily-review/.../
_zh_hans_posts/... -> /zh-Hans/daily-review/.../

La première leçon était claire.

Un blog multilingue ne consiste pas à ajouter des fichiers traduits. Il consiste à définir des frontières de collection.

Archive du Goal de cette exécution

Le travail a commencé le 7 juin 2026 et s’est poursuivi jusqu’au 8 juin 2026.

Au début, cela ressemblait seulement à l’ajout d’une version anglaise. Le Goal a vite grandi jusqu’à ceci.

Transformer hyuk.blog en blog multilingue exploitable, avec ko comme locale source et en, ja, zh-Hans, es, pt-BR, fr et id comme locales étendues.
Ne pas s'arrêter à la traduction. Aligner UI, routing, SEO, sitemap, search, language switcher, vues partagées et today dedupe.
Choisir les langues en tenant compte de Tadak Bible, de la valeur portfolio, des populations chrétiennes et du potentiel d'expansion.
Ne pas utiliser d'API de traduction payante.
Utiliser le standard des workers/subagents GPT les plus récents pour la traduction.
Ne pas faire confiance aux traductions locales de basse qualité.
Ne pas traduire avant confirmation de la source coréenne.
Lorsqu'un post est modifié et que p est lancé, synchroniser aussi les traductions des active locales.
Lancer le build à la fin, pas après chaque batch de traduction.

Le Goal lui-même n’était pas faux.

Le problème est qu’il ne s’est pas réduit en règles exécutables. Les rapports d’état, les points de revue et la portée de traduction se sont collés dessus jusqu’à le rendre trop grand.

La qualité de traduction a frappé fort

La traduction a été le premier endroit où la confiance s’est cassée.

Au début, je pensais pouvoir traduire beaucoup d’articles en bloc. Mais un échantillon contenait des instructions de prompt mélangées telles quelles au contenu traduit.

Return only the translated content. Do not add notes or fences.

Ce n’était pas quelques phrases maladroites. Cela voulait dire que le chemin de génération n’était pas fiable.

J’ai donc revu, par échantillons, s’il fallait sauver les mauvaises traductions par relecture ou les régénérer. La conclusion a été de régénérer. Les sorties locales d’outils comme Ollama ou Argos n’étaient pas assez fiables pour des articles publics. La vitesse comptait moins que le modèle utilisé et le contrôle franchi.

La règle restante est nette.

En traduction, le chemin de confiance passe avant le taux d'achèvement.
Ne pas traduire avant confirmation de la source.
Ne pas rafistoler une traduction publique avec de la MT locale de basse qualité.

Le changement de langue et les vues ont aussi bougé

Les pages anglaises s’ouvraient par URL directe.

Mais l’utilisateur ne trouvait pas le passage coréen/anglais.

Au début, j’avais mis English / Korean dans le menu ordinaire. C’était dans le HTML, mais l’utilisateur ne le voyait pas. Sur mobile, c’était pire. La règle est donc devenue claire : le changement de langue n’est pas un item de menu, mais un global control.

Les vues non plus n’étaient pas aussi simples que cela.

Un article anglais n’est pas un autre article. C’est la traduction du même article. /daily-review/x/ et /en/daily-review/x/ ne doivent pas utiliser des clés de vues différentes. Le data-page-view-path du HTML, le JS côté client et le Cloudflare Worker comptent donc les vues selon le canonical path après suppression du locale prefix.

Là aussi, le travail a grossi. Corriger seulement le code du Worker ne suffisait pas. Il fallait déployer avec le Wrangler CLI, et le dry-run a montré que le binding D1 DB pouvait manquer. J’ai donc fixé l’entrypoint du Worker et le binding D1 dans wrangler.toml, vérifié que le binding était présent, puis seulement déployé.

Le point important était today dedupe.

Lire le même article en coréen puis passer à l’anglais ne doit pas incrémenter today deux fois. Si la canonical page est la même, la dedupe key doit l’être aussi.

Pourquoi l’achèvement du Goal Codex a dépassé 13 heures

Cela ne veut pas dire que le pur temps de développement a été de 13 heures à lui seul.

Le problème était que le Goal lancé dans Codex a mis plus de 13 heures à atteindre l’état terminé.

Ce n’était pas seulement parce qu’il y avait beaucoup à faire. Certains jugements ont bougé.

J’ai essayé de tenir la traduction complète et la revue en même temps. Le standard oscillait entre “tout générer puis relire” et “relire au fur et à mesure”. J’ai voulu croire la qualité avant de confirmer le modèle du worker, et quand de mauvaises traductions sont apparues, il a fallu les refaire.

Traduire avant de confirmer la source était aussi un problème.

Si l’article coréen public continue de changer, les traductions faites d’abord se décalent forcément. Cela a mené à réécrire la source, jeter les traductions existantes et traduire encore.

Le jugement sur le build a aussi bougé.

Si un build tourne après chaque batch de traduction, le travail ne finit jamais. Le build est une vérification importante, mais pas un rituel à répéter à chaque fois. Il faut d’abord verrouiller la source et la portée de traduction, puis vérifier ce qui est nécessaire vers la fin.

Le sens de p est aussi devenu clair tardivement.

Désormais, quand un changement de post est impliqué, p ne signifie pas simplement commit et push. Cela signifie synchroniser les traductions des active locales pour la source confirmée, puis pousser.

L’usage était aussi un coût

Ce travail de traduction ne se réglait pas seulement en évitant les API payantes.

Le quota hebdomadaire Pro x20, que je venais de payer la veille, est passé de 100% à 50% en deux jours.

Cette consommation était le coût des traductions générées en parallèle sans verrouiller les critères, des traductions ratées à refaire et des traductions à refaire après changement de source. Ne pas utiliser d’API de traduction payante ne rend pas le coût nul. Usage du modèle, temps, concentration et fatigue de revue sont aussi des coûts.

Il faut donc verrouiller ceci d’abord.

confirmation de la source
portée de traduction
méthode de revue
moment du build
critère de push

Si ces cinq points restent flous, le travail multilingue regrossit très vite.

Les règles d’exploitation restantes

Les règles laissées par ce travail comptent plus que la fonctionnalité.

Les URL de langue restent dans le même domaine.
Les articles traduits vivent dans des locale collections.
En traduction, le chemin de confiance passe avant le taux d'achèvement.
Ne pas traduire avant confirmation de la source.
Le changement de langue doit être un global control toujours visible.
Les vues et today dedupe utilisent la canonical page.
Quand p est lancé pour des posts, inclure la synchronisation des active locales.
Lancer le build à la fin pour la portée nécessaire, pas après chaque batch.
Les Goals doivent se réduire en règles exécutables, pas grossir en longs rapports d'état.

Ajouter la version anglaise était important.

Mais le résultat le plus important a été un standard pour garder le blog exploitable pendant qu’il devient multilingue.

Je l’ai appris cher.

Mais c’était un standard nécessaire.