Apa yang Shipping DIALØGUE Ajarkan kepada Saya tentang Produk AI Multibahasa

Salah satu hal paling menggoda yang AI izinkan kita lakukan sekarang adalah menambah bahasa dengan cepat. Saya tahu karena saya terus melakukannya. Saya menambahkan 5 bahasa ke DIALØGUE dalam 48 jam, lalu menerjemahkan seluruh arsip blog saya ke 10 bahasa dalam 4 hari.

Dua post itu tentang sisi kecepatannya. Post ini tentang semua hal yang tidak tercakup oleh kecepatan.

Terjemahan adalah bagian yang paling mudah didemokan, dan bagian yang paling berbahaya untuk dilebih-lebihkan.

Mesin bisa memindahkan teks dari satu bahasa ke bahasa lain dengan kecepatan yang mengejutkan. Itu tidak berarti produknya sekarang terasa native. Dalam pengalaman saya, pekerjaan multibahasa yang sesungguhnya muncul di empat tempat: waktu, suara, sistem UI, dan perilaku fallback. Di situlah produk mulai terasa thoughtful, atau mulai terasa palsu.

Begini bentuknya dalam praktik:

	Translation Work	Product Work
Apa yang dicakup	Strings, copy, labels	Tanggal, layout, suara, fallbacks
Siapa yang sadar saat salah	Reviewer bilingual	Semua pengguna di locale itu
Bagaimana AI membantu	Menghasilkan terjemahan dengan cepat	Tidak bisa menilai kecocokan di level produk
Usaha untuk memperbaiki	Terjemahkan ulang string-nya	Desain ulang komponennya
Kapan Anda menyadarinya	Saat code review	Setelah seseorang benar-benar memakai aplikasinya

---

Bug Pertama Bukan Soal Terjemahan. Tapi Soal Waktu.

Salah satu perbaikan yang membuat ini terasa jelas sama sekali tidak ada hubungannya dengan copy.

Untuk show yang recurring, DIALØGUE menghasilkan judul episode secara otomatis. Versi yang paling straightforward terdengar jelas: nama show ditambah tanggal hari ini.

Kedengarannya aman sampai audiens Anda ada di Tokyo dan server Anda masih berpikir dalam waktu California.

Kalau seorang listener Jepang membuka daily show pada saat di Tokyo sudah tanggal 14 Maret, tetapi judul episodenya masih tertulis 13 Maret karena itulah yang diyakini server, produknya langsung terasa off. Tidak rusak. Hanya terasa sembrono.

Jadi saya akhirnya mengubah judul episode agar memakai tanggal lokal audiens, dalam locale dan timezone audiens, bukan default server.

Itu detail implementasi yang kecil. Dan justru itulah intinya.

Produk multibahasa bukan cuma soal kata-kata. Produk multibahasa adalah soal konteks.

Bahasa tanpa konteks lokal sering kali hanya jadi versi yang lebih sopan dari sesuatu yang salah.

---

Pelajaran 1: Suara Adalah Bagian dari Produk

Hal ini makin jelas ketika saya masuk lebih dalam ke DIALØGUE.

Produknya dibangun di atas dialogue, pacing, personality, dan audio. Itu membuat quality bar-nya jauh lebih tinggi daripada interface SaaS biasa.

Saat saya menambahkan template baru, saya cepat belajar bahwa dukungan multibahasa bukan sekadar:

• menerjemahkan nama template
• menerjemahkan copy landing page
• lalu shipping

Untuk satu template, saya harus memikirkan semua ini:

• host profiles
• audience profiles
• dialogue guides
• voice instructions untuk TTS
• localized naming conventions per bahasa

Pekerjaan itu ada dalam bahasa Inggris, tetapi juga perlu versi Jepang dan Vietnam, karena chemistry antara para host adalah bagian dari produk, bukan lapisan kosmetik di atasnya.

Kalau produk Anda menghasilkan konten, voice bukan dekorasi. Voice adalah infrastructure.

Sesuatu bisa saja benar secara tata bahasa dan tetap terasa mati.

Saya merasakannya dengan cukup tajam pada varian Chinese, dan pada konten spoken secara umum. Standard Mandarin bisa benar secara teknis, tetapi tetap terasa terlalu formal dalam konteks tertentu. Irama percakapan yang santai dalam bahasa Inggris bisa berubah menjadi birokratis ketika didorong lewat bahasa produk yang literal dalam bahasa lain. Lelucon yang mengena di satu market bisa berubah menjadi eksposisi datar di market lain.

Itulah sebabnya sekarang saya sangat peduli pada tone guides dan host profiles. Bukan karena saya ingin setiap output terdengar "branded". Tetapi karena voice drift adalah salah satu cara tercepat membuat produk AI multibahasa terasa generik.

Dan generik itu mahal.

---

Pelajaran 2: Panjang UI Adalah Masalah Produk, Bukan Masalah Terjemahan

Ini terdengar kecil sampai Anda benar-benar shipping aplikasi.

Lalu tiba-tiba masalahnya ada di mana-mana.

Ketika saya melokalkan aplikasi iOS DIALØGUE, itu bukan soal menerjemahkan beberapa layar. Itu berubah menjadi 253 strings di 7 bahasa.

Bahkan setelah itu, pekerjaannya belum selesai.

Saya harus mengubah wiring input components supaya app language picker benar-benar mengontrol bahasa UI secara konsisten. Placeholders, buttons, pricing labels, status text, semuanya. Kalau tidak, Anda dapat masalah aplikasi setengah diterjemahkan:

• satu screen mengikuti bahasa yang dipilih
• screen lain masih menampilkan placeholder bahasa Inggris
• status labels tetap berada di bahasa asal
• aplikasinya technically mendukung banyak bahasa, tetapi experience-nya tidak

Sebuah button yang rapi dalam bahasa Inggris bisa terasa canggung dalam bahasa Jerman. Satu baris pricing yang pendek bisa wrapping di bahasa Prancis. Sebuah settings label yang punchy bisa berperilaku berbeda dalam bahasa Jepang.

Kalau workflow localization Anda berhenti di text generation, Anda akan menemukan masalah-masalah ini terlalu telat dan cukup memalukan.

Karena itu saya makin yakin bahwa pekerjaan multibahasa harus diperlakukan sebagai product system yang lengkap:

• copy
• layout
• spacing
• truncation rules
• component behavior
• screenshot QA

Mesin bisa menghasilkan kata-katanya. Seseorang tetap harus membuka Simulator.

---

Pelajaran 3: Fallback Behavior Menunjukkan Seberapa Matang Produk Itu Sebenarnya

Hal ini bahkan lebih penting di produk audio daripada produk teks.

Salah satu perbaikan DIALØGUE yang paling berguna baru-baru ini terlihat membosankan dari luar: TTS thresholding dan per-segment consistency.

Whole-script TTS gate yang awal terlalu optimistis. Podcast yang panjang melewati batas input yang sebenarnya, membuang beberapa retry yang gagal sebelum akhirnya fallback. Dalam beberapa run, itu berarti kira-kira 12 detik latency yang sebenarnya bisa dihindari sebelum sistem mengoreksi dirinya sendiri.

Itu menjengkelkan dalam bahasa Inggris.

Dalam flow multibahasa, itu lebih buruk, karena voice consistency memang sudah lebih sulit dipertahankan.

Perbaikannya bukan "pakai model yang lebih bagus." Perbaikannya adalah product work:

• menurunkan threshold untuk whole-script synthesis
• memindahkan episode panjang ke per-segment mode lebih awal
• menambahkan opening / middle / closing guidance untuk energi tiap segmen
• mengirim beberapa baris dialogue sebelumnya sebagai continuity context supaya segmen berikutnya tidak terasa seperti show yang baru

Itu fallback behavior. Itu maturity.

Kalau suara TTS spesifik untuk satu bahasa terdengar salah, apa yang terjadi? Kalau jawaban yang dihasilkan mencampur bahasa, apa yang terjadi? Kalau ada untranslated error message muncul di tengah localized flow, apa yang terjadi? Kalau script panjang melewati model limit, apa yang terjadi?

Momen-momen seperti itu menunjukkan apakah dukungan multibahasa hanyalah feature, atau benar-benar foundation.

Pengguna biasanya cukup memaafkan ketika sistemnya jelas sedang berusaha membantu. Mereka jauh lebih tidak memaafkan ketika produknya terasa sembarangan.

---

Pelajaran 4: Tahu Kapan Coverage Itu Tidak Layak

Pertanyaan bisnisnya bukan "Bisakah saya mendukung satu bahasa lagi?"

Pertanyaannya adalah:

• apakah bahasa ini akan membuka usage nyata atau distribution nyata?
• apakah saya bisa menjaga quality bar yang meyakinkan, baik di UI maupun output?
• apakah saya bisa menangani failure cases tanpa menciptakan support debt?

Kalau jawabannya tidak, maka yang Anda luncurkan bukan multilingual capability. Itu multilingual surface area. Dan surface area tanpa kualitas secara pelan-pelan melemahkan trust.

---

Pelajaran 5: Produk Multibahasa Butuh Eval Layer Mereka Sendiri

Mungkin ini takeaway terbesar saya dari DIALØGUE dan arsip blog saya.

Anda tidak bisa menilai kualitas multibahasa hanya dari insting, apalagi saat skalanya membesar.

Anda butuh explicit checks:

• behavior tanggal dan timezone yang spesifik per locale
• consistency istilah
• UI overflow
• fallback language rules
• TTS consistency di berbagai segmen
• host/personality drift
• kualitas output dalam real user flows

Dengan kata lain, produk multibahasa juga butuh evals.

Dan saya pikir di sinilah para AI builders bisa terjebak. Kita terlalu terpesona oleh seberapa banyak hal yang bisa diproduksi model, lalu menghabiskan lebih sedikit waktu untuk mendefinisikan dengan tahan lama apa arti "bagus."

Dalam skala kecil, itu masih bisa dikelola.

Dalam skala yang lebih besar, itu menjadi berbahaya.

---

Posisi Saya Sekarang

Saya lebih optimistis dari sebelumnya tentang produk AI multibahasa.

AI benar-benar mengubah economics-nya. AI benar-benar memperluas apa yang bisa di-shipping oleh satu orang atau tim kecil. AI benar-benar membuat ambisi produk yang dulu terasa tidak realistis menjadi mungkin.

Tetapi AI juga menaikkan standar untuk product judgment.

Karena ketika ekspansi bahasa menjadi mudah, kualitaslah yang jadi pembeda. Dan kualitas dalam produk multibahasa tidak lahir dari terjemahan saja. Kualitas datang dari konteks, voice, interface fit, fallbacks, review loops, dan definisi yang sangat jujur tentang apa arti "cukup native."

Itulah yang DIALØGUE ajarkan kepada saya. Semakin banyak bahasa yang Anda dukung, semakin banyak product management yang sebenarnya sedang Anda lakukan, mau Anda menyebutnya begitu atau tidak.

Kalau produk Anda benar-benar multibahasa, pekerjaannya tidak selesai ketika strings sudah diterjemahkan. Justru di situlah pekerjaan yang sesungguhnya dimulai.

Kalau Anda ingin melihat hasil dari cara berpikir itu, DIALØGUE sudah live sekarang dalam 7 bahasa. Dan saya curiga layer multibahasanya akan terus mengajari saya hal-hal baru, semakin banyak orang memakainya. Biasanya jenis pelajaran yang merendahkan hati.

Kalau Anda juga sedang membangun produk multibahasa, saya ingin sekali tahu: kapan momen Anda sadar bahwa bug yang paling sulit sama sekali tidak ada hubungannya dengan terjemahan?

Cheers, Chandler

---

Pertanyaan yang Sering Diajukan

Apa bagian tersulit dalam membangun produk AI multibahasa?

Bukan terjemahannya. AI sekarang menangani bagian itu dengan sangat baik. Bagian tersulit adalah semua yang mengelilingi terjemahan: formatting yang sadar timezone, konsistensi voice di berbagai segmen TTS, UI components yang rusak karena panjang string yang berbeda, dan fallback behavior saat ada sesuatu yang gagal di locale tertentu. Itu masalah produk, bukan semata masalah bahasa.

Haruskah saya menambah lebih banyak bahasa ke produk AI saya?

Hanya jika Anda bisa menjaga kualitasnya. Setiap bahasa yang Anda tambahkan menciptakan product work yang berkelanjutan: layout QA, voice tuning, formatting tanggal dan angka yang spesifik per locale, dan fallback paths. Kalau produk Anda bergantung pada nuance dan generated content seperti podcasts, tulisan panjang, atau conversational AI, quality bar-nya lebih tinggi daripada interface transaksional yang sederhana.

Bagaimana cara menguji fitur AI multibahasa?

Bangun eval layer yang eksplisit. Untuk DIALØGUE, itu berarti mengecek tanggal spesifik per locale, konsistensi segmen TTS, UI overflow di semua 7 bahasa, dan personality drift dalam dialogue host yang dihasilkan. Anda tidak bisa hanya mengandalkan insting begitu Anda mendukung lebih dari dua atau tiga bahasa. Surface area-nya terlalu besar untuk di-spot-check secara manual.

Apakah AI membuat localization lebih mudah atau lebih sulit?

Keduanya. AI membuat terjemahan awal jauh lebih cepat dan murah. Tetapi AI juga menciptakan rasa selesai yang palsu. Anda mendapatkan kata-katanya benar lalu mengira produknya sudah siap. Pekerjaan yang sesungguhnya, yaitu konteks, voice, UI fit, dan fallbacks, tetap membutuhkan human judgment. AI menaikkan floor untuk multilingual coverage, tetapi ceiling-nya tetap product craft.