Pilihan dan Preferensi: Merancang Sistem Bilingual yang Memahami Manusia di Balik Data

Pilihan dan Preferensi: Merancang Sistem Bilingual yang Memahami Manusia di Balik Data

Setelah membahas bagaimana menjaga integritas konten saat berpindah medium, kita masuk ke lapisan yang lebih personal: bagaimana sistem mengenali dan menghormati identitas bahasa penggunanya—sebuah tugas yang ternyata jauh lebih rumit daripada sekadar membaca setting browser.

Saya ingat ketika pertama kali diminta untuk mengimplementasikan logika deteksi bahasa otomatis. Waktu itu, tahun mungkin 2015 atau 2016. Saya, dengan percaya diri yang naif, berpikir: “Ah, gampang. Ambil saja navigator.language. Selesai.” Saya menulis tiga baris kode. Saya jalankan. Ia bekerja dengan sempurna di laptop saya di kamar kos. Saya merasa seperti dewa kecil yang telah memecahkan salah satu misteri interaksi manusia-mesin. Ternyata, saya baru saja menggali lubang yang dalam.

Masalahnya muncul ketika seorang teman, Andi, yang saat itu sedang kuliah S2 di Belanda, mengakses sistem. Andi menggunakan laptop yang dibelinya di Amsterdam, dengan sistem operasi berbahasa Inggris, tetapi dia sendiri adalah orang Indonesia tulen dari Solo. Apa yang terjadi? Sistem saya dengan bangga menyambutnya dalam bahasa Inggris yang sempurna. Andi mengirim pesan, “Mas, kok bahasanya Inggris? Gantiin dong.” Saya beralibi, “Itu kan setting-mu.” Dia membalas, “Setting-nya emang Inggris, tapi otak dan hatiku Indonesia. Masa sistemmu nggak bisa nebak?”

Nah. Di situlah jatuhnya. “Nebak.” Kata yang sederhana, tetapi mengandung dunia. Bisakah sebuah sistem “menebak” identitas seseorang? Lebih jauh lagi, seberapa jauh kita, sebagai pembangun sistem, berhak “menebak” dan memutuskan untuk pengguna? Pertanyaan itu menggelayuti saya selama berhari-hari. Ini bukan lagi soal teknis if-else. Ini soal filosofi. Soal batas antara kemudahan dan paternalisme. Antara kepraktisan dan penghormatan.

Logika pertama saya runtuh. Saya mulai menyusun lapisan-lapisan baru. Lapisan pertama: cek localStorage, apakah pengguna pernah memilih bahasa secara manual? Jika ada, utamakan itu. Itu adalah bentuk penghormatan tertinggi: pilihan sadar pengguna. Lapisan kedua: cek navigator.languages (plural), daftar preferensi bahasa yang diatur pengguna di browser. Ini lebih halus daripada satu bahasa default. Ia memberi kita hierarki. Seseorang bisa saja mengatur: Inggris, lalu Jepang, lalu Indonesia. Itu cerita yang berbeda dengan hanya “Bahasa: Inggris”. Lapisan ketiga: cek navigator.language standar, sebagai fallback yang paling kasar. Tiga lapisan ini sudah jauh lebih baik daripada satu baris kode saya dulu. Tapi tetap terasa kaku. Masih seperti mesin.

Kemudian saya membaca tentang Intl.DateTimeFormat().resolvedOptions().timeZone. Zona waktu. Ini petunjuk geografis yang halus. Seseorang bisa menyembunyikan bahasanya, tetapi zona waktunya seringkali jujur. Jika zona waktunya “Asia/Jakarta”, kemungkinan besar dia berinteraksi dengan konteks Indonesia, meski bahasanya Inggris. Tapi lagi-lagi, ini tebakan. Seorang ekspatriat di Jakarta mungkin tetap ingin bahasanya Inggris. Seorang pelajar Indonesia di Jepang mungkin zonanya Asia/Tokyo, tapi ingin bahasanya Indonesia. Setiap pengecualian menggerogoti kepercayaan diri logika kita.

Saya jadi teringat pada tukang sate langganan dekat rumah dulu. Setiap saya datang, tanpa saya bilang, dia sudah tahu: “Nasi separo, sate campur, nggak pakai kecap, daun bawangnya banyak.” Dia “menyimpan preferensi” saya di kepalanya. Sistemnya sederhana: pengamatan, ingatan, dan sedikit empati. Tapi dia tidak pernah memaksanya. Suatu hari saya bilang, “Bang, hari ini pake kecap ya.” Dia hanya angguk, “Okeh.” Dan mulai saat itu, untuk saya, dia menyimpan dua profil: “Hajriah biasa” dan “Hajriah hari ini”. Apakah sistem digital kita bisa selembut itu? Menyimpan preferensi, tetapi selalu siap dikoreksi, tanpa membuat pengguna merasa bersalah karena telah “mengacaukan” logika kita?

Pekerjaan mendesain logika ini membuat saya melihat bahwa “preferensi” bukanlah sebuah titik statis. Ia cair. Ia kontekstual. Preferensi bahasa saya saat membaca dokumentasi teknis (Inggris) berbeda dengan preferensi saya saat membaca notifikasi dari aplikasi bank (Indonesia, jelas). Sebuah sistem yang baik harus memungkinkan granularitas itu. Bukan cuma satu toggle untuk segalanya. Tapi di sisi lain, kita juga tidak bisa membuat pengguna kebingungan dengan terlalu banyak opsi. Di sinilah seninya. Di sinilah “kerja sunyi” itu terjadi: merancang arsitektur keputusan yang kuat di balik sebuah antarmuka yang terlihat sederhana.

Proses debugging-nya lucu sekaligus filosofis. Saya membuat sebuah halaman percobaan yang menampilkan semua data mentahnya: browser language, timezone, IP-derived country (dengan segala ketidakakuratannya), dan kemudian menunjukkan keputusan akhir sistem. Saya membagikannya ke teman-teman di berbagai belahan dunia. Hasilnya adalah koleksi kisah-kisah manusia modern: seorang WNI yang bekerja di kapal kargo internasional, IP-nya selalu berubah, tapi hatinya ingin berita dari tanah air. Seorang ibu rumah tangga di Texas yang mengajari anaknya bahasa Indonesia lewat aplikasi, sehingga setting perangkatnya sengaja dibuat bilingual. Setiap kasus melucuti asumsi saya satu per satu.

Asumsi adalah musuh terbesar dalam mendesain sistem seperti ini. Asumsi bahwa “satu bahasa cukup”. Asumsi bahwa “pengguna akan jujur pada setting-nya”. Asumsi bahwa “geolocation IP akurat”. Hidup jauh lebih berantakan dan lebih indah daripada asumsi-asumsi kita. Tantangannya adalah membangun sistem yang tidak takut pada kerantakan itu, tetapi justru merangkulnya sebagai bagian dari realitas.

Pada akhirnya, yang saya desain bukanlah sebuah “detektor bahasa yang sempurna”. Mustahil. Yang saya coba bangun adalah sebuah “proses negosiasi” antara sistem dan pengguna. Lapisan-lapisan logika itu adalah cara sistem berkata, “Ini yang saya ketahui tentang kamu, dari data yang kamu tinggalkan secara tidak sengaja. Apakah ini benar?” Tombol toggle yang selalu terlihat dan mudah dijangkau adalah cara sistem berkata, “Kamu selalu punya kata akhir. Saya hanya menebak-nebak.”

Ada kepuasan tertentu ketika melihat logika ini berjalan di belakang layar. Ketika seorang pengguna dari Papua Nugini yang kebetulan sedang liburan di Bali, dan sistem berhasil menyambutnya dengan bahasa Indonesia yang pas (karena kombinasi timezone dan IP), tanpa dia harus mengklik apa pun. Itu momen kecil dimana teknologi terasa “paham”. Sebaliknya, ada pelajaran berharga ketika logika itu salah, dan pengguna dengan mudah membetulkannya dengan satu klik. Itu berarti sistem kita cukup rendah hati untuk dikoreksi.

Desain teknis ini, pada hakikatnya, adalah cermin dari bagaimana kita melihat manusia: bukan sebagai kumpulan data yang rapi dan konsisten, tetapi sebagai entitas yang kompleks, berlapis, dan kadang kontradiktif. Sebuah sistem yang baik harus bisa menampung kompleksitas itu, bukan menyederhanakannya secara paksa.

Dan inilah kerja sunyi sistem yang sesungguhnya: bukan memaksa satu kebenaran teknis, tetapi dengan rendah hati menyediakan lapisan-lapis keputusan yang memungkinkan setiap pengguna—dengan segala kerumitan identitas dan kebiasaannya—merasa ditemukan, bukan diasingkan.

Choices and Defaults: Designing a Bilingual System That Sees the Human Behind the Data

After discussing how to preserve content integrity across mediums, we move to a more intimate layer: how a system recognizes and respects the linguistic identity of its user—a task that turned out to be infinitely more complex than just reading a browser setting.

I remember when I was first asked to implement an automatic language detection logic. It must have been 2015 or 2016. I, with naive confidence, thought: "Ah, easy. Just grab the navigator.language. Done." I wrote three lines of code. I ran it. It worked perfectly on my laptop in my boarding house room. I felt like a minor deity who had solved one of the mysteries of human-machine interaction. Turns out, I had just started digging a very deep hole.

The problem emerged when a friend, Andi, who was studying for his Master's in the Netherlands at the time, accessed the system. Andi used a laptop he bought in Amsterdam, with an English operating system, but he himself was a pure Indonesian from Solo. What happened? My system proudly welcomed him in perfect English. Andi sent a message, "Bro, why's it in English? Change it, will you?" I made an excuse, "That's your setting." He replied, "The setting is English, but my brain and heart are Indonesian. Can't your system guess?"

There. That was the fall. "Guess." A simple word, containing a world. Can a system "guess" a person's identity? Furthermore, how far are we, as system builders, entitled to "guess" and decide for the user? That question haunted me for days. This was no longer about technical if-else. This was about philosophy. About the boundary between convenience and paternalism. Between practicality and respect.

My first logic crumbled. I began to assemble new layers. First layer: check localStorage, has the user ever manually chosen a language? If yes, prioritize that. That is the highest form of respect: the user's conscious choice. Second layer: check navigator.languages (plural), the list of language preferences the user set in their browser. This is more subtle than a single default language. It gives us a hierarchy. Someone might set: English, then Japanese, then Indonesian. That's a different story from just "Language: English". Third layer: check the standard navigator.language, as the crudest fallback. These three layers were already much better than my single line of code from before. But it still felt rigid. Still machinic.

p>Then I read about Intl.DateTimeFormat().resolvedOptions().timeZone. Timezone. A subtle geographical clue. A person can hide their language, but their timezone is often honest. If the timezone is "Asia/Jakarta", chances are they interact with an Indonesian context, even if their language is English. But again, this is a guess. An expatriate in Jakarta might still want English. An Indonesian student in Japan might have the Asia/Tokyo timezone, but want Indonesian. Every exception erodes our logic's confidence.

It reminded me of the satay vendor I used to frequent near my old house. Every time I came, without me saying anything, he already knew: "Half portion of rice, mixed satay, no sweet soy sauce, extra scallions." He "saved my preference" in his head. His system was simple: observation, memory, and a little empathy. But he never imposed it. One day I said, "Boss, with sweet soy sauce today, please." He just nodded, "Okay." And from that moment on, for me, he stored two profiles: "Regular Hajriah" and "Today's Hajriah". Can our digital systems be that gentle? Storing preferences, but always ready to be corrected, without making the user feel guilty for "messing up" our logic?

Designing this logic made me see that "preference" is not a static point. It's fluid. It's contextual. My language preference when reading technical documentation (English) is different from my preference when reading notifications from my bank app (Indonesian, definitely). A good system must allow for that granularity. Not just one toggle for everything. But on the other hand, we also can't confuse users with too many options. That's where the art lies. That's where the "quiet work" happens: designing a robust decision architecture behind an interface that looks simple.

The debugging process was funny and philosophical at the same time. I made a test page that displayed all the raw data: browser language, timezone, IP-derived country (with all its inaccuracies), and then showed the system's final decision. I shared it with friends across the globe. The result was a collection of modern human stories: an Indonesian citizen working on an international cargo ship, his IP always changing, but his heart wanting news from home. A homemaker in Texas teaching her child Indonesian through an app, so her device settings were intentionally made bilingual. Each case stripped away my assumptions one by one.

Assumption is the greatest enemy in designing a system like this. The assumption that "one language is enough". The assumption that "the user will be honest with their settings". The assumption that "IP geolocation is accurate". Life is far messier and more beautiful than our assumptions. The challenge is to build a system that is not afraid of that mess, but embraces it as part of reality.

In the end, what I designed was not a "perfect language detector". Impossible. What I tried to build was a "negotiation process" between the system and the user. Those layers of logic are the system's way of saying, "This is what I know about you, from the data you left behind unintentionally. Is this correct?" The always-visible, easily accessible toggle button is the system's way of saying, "You always have the final say. I'm just guessing."

There's a certain satisfaction in watching this logic run in the background. When a user from Papua New Guinea who happens to be vacationing in Bali is greeted with just the right Indonesian (due to a combination of timezone and IP), without them having to click anything. That's a small moment where technology feels "understanding". Conversely, there's a valuable lesson when the logic is wrong, and the user easily corrects it with one click. That means our system is humble enough to be corrected.

This technical design is, in essence, a mirror of how we view humans: not as a collection of neat and consistent data, but as entities that are complex, layered, and sometimes contradictory. A good system must be able to accommodate that complexity, not force-simplify it.

And this is the true quiet work of the system: not to enforce a single technical truth, but to humbly provide layers of decisions that enable every user—with all the complexity of their identity and habits—to feel found, not alienated.