[🛠] Por que o Codex Goal do blog multilíngue passou de 13 horas

✨ Resumo do GPT-5.5 　

Registro da execução do Codex Goal que levou o hyuk.blog de uma versão em inglês /en/ para regras de operação com oito locales, revendo qualidade de tradução, troca de idioma, views compartilhadas, regra p e custo de uso.

No começo achei que bastava escolher /en/

A primeira pergunta era simples.

en.hyuk.blog seria melhor?
/en/ seria melhor?

Depois de considerar SEO, operação no GitHub Pages, a ligação entre original e traduções, views compartilhadas e a estrutura de idiomas para futuras expansões, a conclusão foi /en/.

Eu não queria operar a versão em inglês como um produto totalmente separado. Este blog parte de textos originais em coreano e adiciona traduções. Nesse caso, separar as URLs de idioma dentro do mesmo domínio e conectá-las com hreflang é mais simples.

Mas não terminou aí.

No momento em que escolhi /en/, home, About, categorias, busca, sitemap, language switcher, contagem de views, qualidade de tradução e até a forma de dar push em posts futuros começaram a se mover juntos.

Não era um arquivo traduzido, era uma fronteira de collection

Posts em inglês não podiam ser misturados em _posts.

No Jekyll, _posts entra em site.posts. Se os posts em inglês forem misturados ali, a home coreana, feed, paginação e related posts passam a consumi-los em silêncio. Parece só mais um post, mas o índice inteiro do blog fica contaminado.

Por isso os posts traduzidos foram separados em collections por locale.

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

A primeira lição ficou clara.

Um blog multilíngue não é adicionar arquivos traduzidos. É definir fronteiras de collection.

Arquivo do Goal daquela execução

O trabalho começou em 7 de junho de 2026 e continuou até 8 de junho de 2026.

No começo parecia apenas uma versão em inglês. O Goal logo cresceu para isto.

Transformar hyuk.blog em um blog multilíngue operável, com ko como locale base e en, ja, zh-Hans, es, pt-BR, fr e id como locales expandidos.
Não parar na tradução. Alinhar UI, routing, SEO, sitemap, search, language switcher, views compartilhadas e today dedupe.
Escolher idiomas considerando promoção do Tadak Bible, valor de portfólio, população cristã e potencial de expansão.
Não usar APIs de tradução pagas.
Usar o padrão dos workers/subagents GPT mais recentes para tradução.
Não confiar em tradução local de baixa qualidade.
Não traduzir antes de confirmar o original coreano.
Ao modificar um post e rodar p, sincronizar também as traduções dos active locales.
Rodar build no fim, não depois de cada batch de tradução.

O Goal em si não estava errado.

O problema foi que ele não encolheu até virar regra executável. Relatórios de status, itens de revisão e escopo de tradução foram grudando nele até ficar grande demais.

A qualidade da tradução bateu forte

A tradução foi o primeiro lugar onde a confiança quebrou.

No início achei que bastaria traduzir muitos posts em lote. Mas uma amostra trouxe instruções de prompt misturadas como conteúdo traduzido.

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

Isso não era algumas frases estranhas. Significava que o caminho de geração não era confiável.

Então revisei por amostras se traduções ruins deveriam ser salvas por revisão ou regeneradas. A conclusão foi regenerar. Saídas locais de ferramentas como Ollama ou Argos não eram confiáveis para posts públicos. Velocidade importava menos do que qual modelo gerou o texto e qual gate ele passou.

A regra que ficou é clara.

Na tradução, o caminho de confiança vem antes da taxa de conclusão.
Não traduzir antes de confirmar a fonte.
Não remendar tradução pública com MT local de baixa qualidade.

Troca de idioma e views também balançaram

As páginas em inglês abriam por URL direta.

Mas o usuário não encontrava a troca coreano/inglês.

No começo coloquei English / Korean dentro do menu comum. Existia no HTML, mas o usuário não via. No mobile era pior. Daí veio a regra: troca de idioma não é item de menu, é global control.

Views também não eram tão simples.

Um post em inglês não é outro post. É tradução do mesmo post. /daily-review/x/ e /en/daily-review/x/ não devem usar chaves de view diferentes. Por isso o data-page-view-path do HTML, o JS do cliente e o Cloudflare Worker passaram a contar views pelo canonical path depois de remover o locale prefix.

Aqui o trabalho também cresceu. Corrigir só o código do Worker não bastava. Era preciso fazer deploy com o Wrangler CLI, e o dry-run mostrou um sinal de que o binding D1 DB poderia estar ausente. Então fixei o entrypoint do Worker e o binding D1 em wrangler.toml, confirmei que o binding estava presente e só então fiz o deploy.

O ponto importante era today dedupe.

Ler o mesmo post em coreano e depois trocar para inglês não pode aumentar today duas vezes. Se a canonical page é a mesma, a dedupe key também precisa ser a mesma.

Por que concluir o Goal no Codex passou de 13 horas

Isso não significa que o tempo puro de desenvolvimento sozinho tenha sido de 13 horas.

O problema foi que o Goal aberto no Codex levou mais de 13 horas para chegar ao estado concluído.

Não foi só porque havia muito trabalho. Algumas decisões ficaram instáveis.

Tentei segurar tradução completa e revisão ao mesmo tempo. O critério oscilou entre “gerar tudo e revisar depois” e “revisar enquanto avança”. Confiei na qualidade antes de confirmar o modelo do worker, e quando traduções ruins apareceram foi preciso refazer.

Traduzir antes de confirmar a fonte também foi problema.

Se o post público em coreano continua mudando, traduções feitas antes obviamente se desalinhavam. Isso levou a reescrever a fonte, jogar fora traduções existentes e traduzir de novo.

O julgamento sobre build também oscilou.

Se build roda depois de cada batch de tradução, o trabalho nunca termina. Build é uma verificação importante, mas não um ritual para repetir toda hora. Primeiro a fonte e o escopo de tradução precisam estar fechados; depois, perto do fim, rodam as verificações necessárias.

O significado de p também ficou claro tarde.

Agora, quando há mudança de post, p não é só commit e push. Significa sincronizar traduções dos active locales para a fonte confirmada e só então dar push.

Uso também era custo

Este trabalho de tradução não se resolvia apenas evitando APIs pagas.

A cota semanal Pro x20, que eu tinha acabado de pagar no dia anterior, caiu de 100% para 50% em dois dias.

Esse consumo foi o custo de gerar traduções em paralelo sem travar critérios, regenerar traduções falhas e traduzir de novo depois que a fonte mudou. Não usar APIs de tradução pagas não torna o custo zero. Uso de modelo, tempo, foco e fadiga de revisão também são custos.

Por isso, primeiro é preciso travar isto.

confirmação da fonte
escopo de tradução
método de revisão
momento do build
critério de push

Se esses cinco pontos ficam vagos, o trabalho multilíngue cresce de novo rapidamente.

As regras operacionais que ficaram

As regras deixadas por este trabalho importam mais do que a função em si.

URLs de idioma ficam dentro do mesmo domínio.
Posts traduzidos vivem em locale collections.
Na tradução, o caminho de confiança vem antes da taxa de conclusão.
Não traduzir antes de confirmar a fonte.
A troca de idioma deve ser um global control sempre visível.
Views e today dedupe usam a canonical page.
Ao rodar p para posts, incluir sync das traduções dos active locales.
Rodar build no fim para o escopo necessário, não depois de cada batch.
Goals devem encolher para regras executáveis, não crescer como longos relatórios de status.

Adicionar a versão em inglês foi importante.

Mas o resultado mais importante foi o padrão para manter o blog operável enquanto ele se torna multilíngue.

Aprendi caro.

Mesmo assim, era um padrão necessário.