[๐ ] Mengapa Codex Goal Blog Multibahasa Melewati 13 Jam
โจ Ringkasan GPT-5.5 ใ
Catatan tentang Codex Goal yang memperluas hyuk.blog dari versi Inggris /en/ menuju standar operasi delapan locale, sambil menata ulang kualitas terjemahan, pengalih bahasa, views bersama, aturan p, dan biaya penggunaan.
Awalnya saya kira cukup memilih /en/
Pertanyaan pertama sederhana.
Apakah en.hyuk.blog lebih baik?
Apakah /en/ lebih baik?
Setelah mempertimbangkan SEO, operasi GitHub Pages, hubungan antara sumber asli dan terjemahan, views bersama, serta struktur bahasa untuk ekspansi berikutnya, kesimpulannya adalah /en/.
Saya tidak sedang mencoba menjalankan versi Inggris sebagai produk yang sepenuhnya terpisah. Blog ini memiliki tulisan asli berbahasa Korea, lalu terjemahan ditempelkan di atasnya. Dalam struktur seperti itu, membagi URL bahasa di dalam domain yang sama dan menghubungkannya dengan hreflang lebih sederhana.
Namun itu belum selesai.
Begitu memilih /en/, home, About, kategori, pencarian, sitemap, language switcher, jumlah views, kualitas terjemahan, dan cara melakukan push untuk post berikutnya ikut bergerak bersama.
Ini bukan soal file terjemahan, tetapi batas collection
Post bahasa Inggris tidak boleh dicampur ke dalam _posts.
Di Jekyll, _posts masuk ke site.posts. Jika post bahasa Inggris dicampur di sana, home Korea, feed, pagination, dan related posts ikut memakannya diam-diam. Kelihatannya hanya satu post tambahan, tetapi sebenarnya seluruh indeks blog tercemar.
Karena itu post terjemahan dipisahkan ke collection per locale.
_posts/... -> /daily-review/.../
_en_posts/... -> /en/daily-review/.../
_ja_posts/... -> /ja/daily-review/.../
_zh_hans_posts/... -> /zh-Hans/daily-review/.../
Pelajaran pertama jelas.
Blog multibahasa bukan pekerjaan menambah file terjemahan. Itu pekerjaan menentukan batas collection.
Arsip Goal saat itu
Pekerjaan dimulai pada 7 Juni 2026 dan berlanjut sampai 8 Juni 2026.
Awalnya terlihat seperti hanya menambahkan versi Inggris. Goal cepat membesar menjadi ini.
Mengubah hyuk.blog menjadi blog multibahasa yang dapat dioperasikan, dengan ko sebagai locale dasar dan en, ja, zh-Hans, es, pt-BR, fr, id sebagai locale perluasan.
Tidak berhenti pada terjemahan. Samakan UI, routing, SEO, sitemap, search, language switcher, shared view counts, dan today dedupe.
Memilih bahasa dengan mempertimbangkan promosi Tadak Bible, nilai portofolio, populasi Kristen, dan potensi ekspansi.
Tidak menggunakan API terjemahan berbayar.
Menggunakan standar worker/subagent GPT terbaru untuk terjemahan.
Tidak mempercayai hasil terjemahan lokal berkualitas rendah.
Tidak menerjemahkan sebelum sumber Korea dikonfirmasi.
Saat mengubah post dan menjalankan p, sinkronkan juga terjemahan active locale.
Jalankan build di akhir, bukan setelah setiap batch terjemahan.
Goal itu sendiri tidak salah.
Masalahnya, Goal itu tidak mengecil menjadi aturan eksekusi. Laporan status, item review, dan cakupan terjemahan terus menempel sampai terlalu besar.
Kualitas terjemahan memberi pukulan besar
Terjemahan adalah tempat pertama di mana kepercayaan rusak.
Awalnya saya kira banyak post bisa diterjemahkan sekaligus. Namun dalam sampel, ada file yang mencampurkan instruksi prompt sebagai isi terjemahan.
Return only the translated content. Do not add notes or fences.
Ini bukan beberapa kalimat yang canggung. Ini berarti jalur generasinya tidak bisa dipercaya.
Jadi saya melihat ulang lewat sampel apakah terjemahan buruk sebaiknya diselamatkan lewat review atau dibuat ulang. Kesimpulannya adalah dibuat ulang. Output terjemahan lokal dari alat seperti Ollama atau Argos tidak cukup dapat dipercaya untuk post publik. Kecepatan lebih tidak penting dibanding model apa yang menghasilkan teks dan gate apa yang dilewati.
Standar yang tersisa jelas.
Dalam terjemahan, jalur kepercayaan lebih dulu daripada rasio selesai.
Jangan menerjemahkan sebelum sumber dikonfirmasi.
Jangan menambal terjemahan publik dengan MT lokal berkualitas rendah.
Pengalih bahasa dan views juga ikut goyah
Halaman Inggris bisa dibuka lewat URL langsung.
Namun pengguna tidak menemukan pengalih Korea/Inggris.
Awalnya saya menaruh English / Korean di menu biasa. Itu ada di HTML, tetapi pengguna tidak melihatnya. Di mobile lebih buruk. Dari situ standarnya jelas: pengalih bahasa bukan item menu, tetapi global control.
Views juga tidak sesederhana itu.
Post Inggris bukan post lain. Itu terjemahan dari post yang sama. /daily-review/x/ dan /en/daily-review/x/ tidak boleh memakai key views yang berbeda. Jadi data-page-view-path di HTML, JS klien, dan Cloudflare Worker semuanya menghitung views berdasarkan canonical path setelah locale prefix dihapus.
Di sini pekerjaan juga membesar. Memperbaiki kode Worker saja tidak cukup. Worker harus dideploy dengan Wrangler CLI, dan dry-run menunjukkan sinyal bahwa binding D1 DB bisa saja hilang. Karena itu saya mengunci Worker entrypoint dan binding D1 di wrangler.toml, memastikan binding itu ada, lalu baru melakukan deploy.
Bagian pentingnya adalah today dedupe.
Membaca post yang sama dalam bahasa Korea lalu menggantinya ke bahasa Inggris tidak boleh menaikkan today dua kali. Jika canonical page sama, dedupe key juga harus sama.
Mengapa penyelesaian Codex Goal melewati 13 jam
Ini bukan berarti waktu pengembangan murninya sendiri mencapai 13 jam.
Masalahnya adalah Goal yang dijalankan di Codex membutuhkan lebih dari 13 jam sampai mencapai status selesai.
Itu bukan hanya karena pekerjaannya banyak. Ada beberapa penilaian yang terus berubah.
Saya memegang terjemahan penuh dan review sekaligus. Standar bergeser antara โhasilkan semuanya dulu lalu reviewโ dan โreview sambil jalanโ. Saya mencoba percaya pada kualitas terjemahan sebelum memastikan model worker, lalu ketika terjemahan buruk muncul, semuanya harus dibuat lagi.
Menerjemahkan sebelum mengonfirmasi sumber juga masalah.
Jika post Korea publik terus berubah, terjemahan yang dibuat lebih dulu pasti melenceng. Akhirnya sumber ditulis ulang, terjemahan lama dibuang, lalu diterjemahkan lagi.
Penilaian tentang build juga bergeser.
Jika build dijalankan setelah setiap batch terjemahan, pekerjaan tidak akan selesai. Build adalah verifikasi penting, tetapi bukan ritual yang harus diulang setiap saat. Sumber dan cakupan terjemahan harus dikunci dulu, lalu verifikasi yang diperlukan dijalankan mendekati akhir.
Makna p juga baru jelas belakangan.
Sekarang, jika ada perubahan post, p bukan sekadar commit dan push. Itu berarti menyinkronkan terjemahan active locale untuk sumber yang sudah dikonfirmasi, lalu push.
Penggunaan juga biaya
Pekerjaan terjemahan ini tidak selesai hanya dengan menghindari API berbayar.
Kuota penggunaan mingguan Pro x20 yang baru saya bayar kemarin turun dari 100% menjadi 50% dalam dua hari.
Konsumsi itu adalah biaya dari membuat terjemahan paralel tanpa mengunci kriteria, membuat ulang terjemahan gagal, dan menerjemahkan lagi setelah sumber berubah. Tidak memakai API terjemahan berbayar bukan berarti biayanya nol. Penggunaan model, waktu, fokus, dan lelah review semuanya biaya.
Jadi hal-hal ini harus dikunci lebih dulu.
konfirmasi sumber
cakupan terjemahan
metode review
waktu build
kriteria push
Jika lima hal ini kabur, pekerjaan multibahasa cepat membesar lagi.
Standar operasi yang tersisa
Standar yang ditinggalkan pekerjaan ini lebih penting daripada fiturnya.
URL bahasa dibagi dalam domain yang sama.
Post terjemahan hidup di locale collection.
Dalam terjemahan, jalur kepercayaan lebih dulu daripada rasio selesai.
Jangan menerjemahkan sebelum sumber dikonfirmasi.
Pengalih bahasa harus menjadi global control yang selalu terlihat.
Views dan today dedupe memakai canonical page.
Saat menjalankan p untuk post, sertakan sinkronisasi active locale.
Build dijalankan di akhir untuk cakupan yang perlu, bukan setelah setiap batch.
Goal harus mengecil menjadi aturan eksekusi, bukan membesar menjadi laporan status panjang.
Menambahkan versi Inggris memang penting.
Namun hasil yang lebih penting adalah standar untuk menjaga blog tetap dapat dioperasikan saat menjadi multibahasa.
Saya mempelajarinya dengan mahal.
Tetap saja, itu standar yang diperlukan.
Tinggalkan komentar