Alur lokalisasi untuk UI web dan native yang andal

Apa yang salah ketika lokalisasi tidak dikelola

Lokalisasi yang tidak dikelola biasanya gagal dalam cara-cara kecil dan menyebalkan dulu, lalu menjadi mahal kemudian. Label yang muat kemarin bisa meluap hari ini. Kunci yang hilang tampil sebagai identifier mentah. Plural yang terdengar wajar dalam bahasa Inggris jadi salah, atau bahkan terdengar kasar, di bahasa lain.

Kebanyakan tim akhirnya memperbaiki masalah yang sama dalam tekanan:

• Tombol terpotong, header yang terpotong, atau teks yang menutupi ikon
• Kunci hilang yang fallback ke Inggris atau menampilkan nama kunci
• Bentuk plural yang salah (misalnya, "1 items") dan tata bahasa yang rusak di bahasa yang bergender
• Pilihan kata yang tidak konsisten untuk konsep yang sama di berbagai layar
• Perbaikan mendadak sehari sebelumnya karena satu layar dikirim tanpa terjemahan

Layar web dan native sering gagal dengan cara berbeda. Di web, layout fleksibel bisa menyembunyikan masalah sampai viewport atau browser tertentu mengungkapkannya. Teks bisa membungkus tak terduga, mendorong tombol ke bawah, atau merusak grid. Di aplikasi native, spasi lebih ketat. Terjemahan panjang bisa mendorong elemen penting keluar layar, bertabrakan dengan ukuran font aksesibilitas, atau terpotong karena komponen tidak auto-resize.

Alur kerja lokalisasi yang solid mencegah sebagian besar ini dengan membuat kunci stabil, terjemahan bisa ditinjau, dan pemeriksaan UI menjadi rutin. Itu membantu Anda mengirim update dengan lebih sedikit kejutan. Yang tidak bisa diperbaiki adalah teks sumber yang tidak jelas. Jika copy asli samar (seperti "Open" atau "Apply" tanpa konteks), terjemahan tetap tebakan.

Definisi sederhana kesuksesan bukanlah "semua diterjemahkan." Melainkan:

• UI tetap dapat dibaca di seluruh layar web dan native
• Update cepat karena kunci tidak terus berubah
• QA menemukan masalah sebelum pengguna

Contoh: jika layar keranjang menampilkan "{count} item(s)", string yang tidak dikelola menyebabkan plural yang canggung dan spasi yang rusak. Pendekatan yang dikelola memaksa aturan plural yang tepat dan menangkap tombol yang membesar 30% dalam bahasa Jerman sebelum rilis.

Tentukan kepemilikan dan satu sumber kebenaran

Alur lokalisasi runtuh paling cepat ketika tak ada yang bisa menjawab satu pertanyaan: “Teks mana yang asli?” Pilih satu sumber kebenaran untuk string dan buat itu jelas membosankan. Sumber itu bisa file di repo, platform terjemahan, atau tabel internal, tapi harus satu tempat yang menang di setiap perselisihan.

Tentukan peran berdasarkan keputusan, bukan jabatan. Seseorang perlu menyetujui makna dan nada (sering Product atau Marketing). Seseorang perlu menjaga kunci stabil dan dapat dipakai di kode (sering Engineering). Seseorang perlu melindungi batas UI (sering Design), terutama ketika web dan native berperilaku berbeda.

Satu pemisahan yang menghindari banyak konflik:

• Pembuat kunci: orang yang mengirim layar membuat kunci baru ketika UI membutuhkan teks baru.
• Penyetuju kata: PM atau pemilik copy menandatangani teks bahasa dasar.
• Editor terjemahan: penerjemah bisa mengubah terjemahan, tapi tidak boleh mengganti nama kunci.
• Perubahan kunci: hanya pemilik kunci yang bisa mendeprakasi atau menggabungkan kunci, dengan catatan yang menjelaskan alasannya.

Tentukan ekspektasi waktu respons supaya rilis tidak macet. Contoh: permintaan kunci baru diakui dalam 1 hari kerja, persetujuan teks sumber dalam 2 hari, dan perbaikan kritis (UI rusak, teks legal salah) dalam hitungan jam.

Contoh konkret: tim Anda membuat flow “Reset password” baru untuk web dan native. Developer menambah kunci, PM menyetujui teks bahasa Inggris akhir, dan penerjemah mengisi bahasa lain. Jika penerjemah menyarankan “Reset” seharusnya “Change,” mereka memperbarui terjemahan, tapi kunci tetap sama. Jika PM ingin memakai ulang teks di beberapa layar, hanya pemilik kunci yang membuat perubahan struktural agar tidak ada yang rusak diam-diam.

Strategi kunci: gunakan ulang, stabilitas, dan batas layar

Alur kerja lokalisasi yang baik dimulai dengan satu aturan: kunci adalah identifier, bukan kalimat bahasa Inggris. Perlakukan seperti nomor part. Jika Anda mengubah kata nanti, kunci biasanya harus tetap sama.

Buat kunci baru ketika maknanya berbeda. Gunakan kembali kunci ketika maknanya sama, meski layarnya berbeda. “Save” di layar profil dan “Save” di layar pengaturan bisa berbagi kunci jika artinya sama yaitu “simpan perubahan.” Tapi “Save” yang berarti “bookmark” harus kunci berbeda, karena penerjemah mungkin butuh kata kerja lain.

Pisahkan label UI pendek dari konten yang lebih panjang. Label tombol, petunjuk kecil, dan pesan error sering diterjemahkan berbeda dan punya batas panjang berbeda. Menjaganya sebagai kunci terpisah memudahkan menyesuaikan nada dan tanda baca tanpa merusak layar lain.

Batas layar tanpa memaksakan frasa identik

Usahakan reuse antara web dan native, tapi jangan paksa ketika platform butuh bahasa berbeda. Prompt izin native sering butuh teks yang lebih jelas dan formal dibanding tooltip web. Dalam kasus itu, pertahankan konsep inti tapi gunakan kunci spesifik platform agar tiap UI terdengar alami.

Polanya praktis: kelompokkan kunci berdasarkan fitur dan tipe UI, lalu gunakan ulang dalam batas itu:

• Gunakan ulang dalam fitur yang sama ketika maknanya identik
• Pisahkan kunci menurut tipe UI (label vs help vs error vs system prompt)
• Gunakan varian platform hanya ketika frasa harus berbeda
• Jaga kunci stabil dan ubah hanya teks yang tampil
• Tambahkan catatan konteks (lokasi muncul, batas karakter)

Contoh: aksi “Delete customer” mungkin ada di panel admin web dan app lapangan native. Anda bisa menggunakan ulang label aksi inti, tapi punya kunci terpisah untuk teks konfirmasi native jika butuh peringatan yang lebih kuat atau baris yang lebih pendek.

Penamaan dan pengorganisasian kunci terjemahan

Sistem penamaan yang baik membuat lokalisasi terasa membosankan dengan cara terbaik. Orang menemukan string cepat, penerjemah mendapat konteks, dan kunci tetap stabil meski copy berubah.

Gunakan konvensi yang bisa dibaca dan menjawab empat pertanyaan: di mana, apa, untuk apa, dan apakah ini varian. Pola sederhana yang bekerja di web dan native:

<product_or_domain>.<screen_or_flow>.<component>.<purpose>[.<variant>]

Misalnya, di portal pelanggan: portal.login.button.submit atau portal.orders.empty_state.title. Ini membuat kunci tergrup menurut layar atau alur sekaligus mudah dicari menurut komponen.

Kunci yang buruk terlalu samar atau terlalu terkait ke teks Inggris saat ini:

• Baik: portal.profile.field.email.label
• Buruk: emailText (tanpa scope, tanpa tujuan)
• Buruk: please_enter_your_email (rusak saat copy berubah)
• Baik: portal.checkout.error.payment_failed
• Buruk: error_12

Varian harus eksplisit, jangan diakali dengan tanda baca atau casing campur. Jika butuh label lebih pendek untuk header mobile yang sempit, tambahkan suffix varian: ...title.short vs ...title.long. Jika butuh perbedaan kapitalisasi, lebih baik pisahkan kunci seperti ...button.save dan ...button.save_titlecase hanya ketika platform tidak bisa memanipulasi teks dengan aman.

Placeholder juga perlu aturan agar penerjemah tidak menebak.

• Gunakan placeholder bernama: {user_name}, {count}, {date}
• Jangan pernah menggabungkan: jangan bangun string seperti "Hello " + name
• Simpan unit di dalam string ketika tergantung bahasa: {count} items bukan {count} + " items"
• Definisikan format yang diperbolehkan: tanggal ISO, mata uang, atau format tanggal spesifik platform
• Tambahkan catatan singkat untuk string rumit (mis. apakah {count} bisa nol)

Pluralisasi dan aturan tata bahasa yang menghemat pekerjaan ulang

Pluralisasi adalah titik di mana alur kerja biasanya retak pertama kali. Banyak tim mengira setiap bahasa punya hanya “satu” dan “banyak,” lalu menemukan UI terdengar salah atau perlu perbaikan mendadak.

Bahasa bisa punya beberapa kategori plural. Bahasa Inggris umumnya pakai "one" dan "other", tapi bahasa seperti Rusia, Polandia, Arab, dan Ceko bisa memakai bentuk seperti few, many, atau zero. Jika Anda mengunci pola tunggal terlalu dini, Anda akan menulis ulang string di web dan native nanti.

Pilih satu standar untuk string plural dan gunakan konsisten di mana-mana (web, iOS, Android, teks yang dirender backend). Pendekatan praktis adalah menyimpan satu kunci dengan bentuk plural, bukan kunci terpisah per bentuk. Dasarkan set bentuk pada kategori CLDR agar sesuai aturan bahasa nyata.

Aturan yang mencegah pekerjaan ulang: jangan membangun kalimat UI dari potongan seperti "You have " + count + " messages". Urutan kata bisa berubah, dan beberapa bahasa membutuhkan akhiran atau kasus berbeda berdasarkan angka.

Pola kunci praktis

Untuk penghitung pesan, definisikan satu kunci stabil dan sertakan angka sebagai parameter. Lalu sediakan bentuk yang diperlukan penerjemah untuk tiap bahasa.

• Gunakan satu kunci per konsep (contoh: inbox.message_count)
• Dukung bentuk CLDR (zero, one, two, few, many, other)
• Selalu gunakan placeholder (contoh: {count}) di dalam kalimat penuh
• Tambahkan catatan penerjemah ketika makna tidak jelas (apakah itu “messages” atau “unread messages”? )

Gender dan kasus gramatikal

Terkadang aturan plural tidak cukup. Jika UI menyapa orang ("Welcome, Alex") atau merujuk peran ("assigned to him/her"), beberapa bahasa membutuhkan kata berbeda berdasarkan gender. Bahasa lain mengubah akhiran tergantung kasus gramatikal (misalnya setelah preposisi tertentu).

Saat itu terjadi, buat string terpisah untuk tata bahasa yang benar-benar berbeda, bukan sekadar gaya. Tujuannya adalah lebih sedikit kunci, tetapi juga lebih sedikit kejutan saat QA ketika terjemahan "benar" masih terasa salah dalam konteks.

Format dan batas tata letak lintas platform

Terjemahan bisa benar tapi tetap merusak UI. Web dan native merender teks berbeda, jadi alur kerja Anda harus mencakup aturan format dan pengecekan tata letak, bukan hanya string terjemahan.

Standarkan bagaimana Anda menampilkan angka, uang, dan tanggal. Hindari membangun ini dengan concatenation seperti "$" + amount atau meng-hardcode format tanggal di label. Gunakan pemformat yang sadar-locale sehingga pemisah dan urutan sesuai ekspektasi (1,000.50 vs 1 000,50; day-month-year vs month-day-year). Zona waktu sering menjadi jebakan: simpan timestamp di UTC, format di zona lokal pengguna, dan jelaskan ketika waktu berada di zona tertentu (mis. waktu pengambilan toko).

Arah teks adalah pemecah masalah yang diam. Jika mendukung RTL, rencanakan layout cermin dan tanda baca yang “bergeser”. Ikon yang menunjukkan arah (panah, tombol kembali, langkah progres) sering perlu dibalik. Lakukan pengecekan RTL singkat sebagai bagian review, meski Anda belum mendukung RTL sepenuhnya.

Di mobile, font dan spasi bisa bergeser lebih banyak daripada di web. String yang muat di UI web dapat membungkus canggung di SwiftUI atau Kotlin. Tentukan ukuran font minimum aman, izinkan label membungkus di tempat yang masuk akal, dan tentukan font cadangan untuk skrip yang tidak didukung font default Anda.

Aksesibilitas juga butuh pemeriksaan terlokalisasi. Screen reader bisa membacakan angka, singkatan, dan teks campuran bahasa dengan cara yang mengejutkan.

Guardrail tata letak yang mencegah sebagian besar masalah:

• Desain untuk perluasan teks (30–50%) dan hindari tombol lebar tetap.
• Simpan nilai dinamis (count, price, date) sebagai token terformat terpisah.
• Gunakan pemformat tanggal dan angka bawaan platform, bukan pola custom.
• Uji satu locale RTL dan satu locale “teks panjang” sebelum rilis.
• Jalankan pengecekan screen-reader di alur inti (login, checkout, settings).

Contoh: label “Total: $1,234.50” mungkin perlu berubah menjadi “1 234,50 €” dengan simbol setelah nilai, spasi berbeda, dan jeda yang ramah screen reader antara “Total” dan jumlah.

Langkah demi langkah alur kerja dari layar baru hingga rilis

Alur kerja lokalisasi harus dimulai lebih awal daripada yang kebanyakan tim duga: saat layar masih didesain. Jika menunggu sampai UI “selesai,” Anda akan tergesa-gesa menerjemahkan, mengirim teks terpotong, atau meng-hardcode string “sementara.”

Mulailah dengan menambahkan kunci terjemahan saat Anda mendesain tiap label, tombol, dan pesan. Tuliskan teks default dalam bahasa dasar, dan lampirkan konteks singkat seperti di mana muncul dan apa aksi yang dilakukan. Kunci seperti checkout.pay_button hanya berguna jika penerjemah tahu apakah itu kata kerja (“Pay”) atau label (“Payment”).

Implementasikan UI menggunakan placeholder dan bahasa default sebagai fallback. Jaga variabel eksplisit (seperti {name} atau {count}) dan hindari merangkai kalimat. Itu adalah salah satu cara tercepat merusak tata bahasa antar bahasa.

Saat mengirim string untuk diterjemahkan, sertakan apa yang penerjemah butuhkan untuk akurat: screenshot per layar (atau video singkat jika teks berubah), batas karakter untuk tempat sempit (tabs, tombol, badge), catatan nada dan terminologi, serta daftar placeholder dinamis dan maknanya.

Setelah terjemahan kembali, merge lebih awal dan bangun versi web dan native. Lakukan pengecekan UI cepat pada layar dengan risiko tertinggi: login, onboarding, checkout, dan settings. Cari teks terpotong, elemen yang saling tumpang tindih, kunci hilang, dan bentuk plural yang salah.

Terakhir, rilis dan pantau. Lacak kunci hilang, kejadian fallback-ke-default, dan layar tempat teks sering meluap.

Beri penerjemah apa yang mereka butuhkan untuk akurat

Terjemahan akurat dimulai sebelum kata pertama diterjemahkan. Jika penerjemah hanya melihat kunci dan frase Inggris, mereka menebak. Itulah cara mendapatkan kata yang benar di tempat yang salah, dan UI yang terasa aneh atau tidak sopan.

“Paket konteks” sederhana menghilangkan sebagian besar tebakan. Untuk tiap string, tambahkan di mana muncul (layar dan komponen), apa yang pengguna coba lakukan, dan nada (ramah, formal, mendesak). Juga catat apakah itu label tombol, pesan error, item menu, atau teks bantuan. Kategori itu diterjemahkan berbeda.

Saat ruang sempit, sebutkan langsung. Layar web dan native rusak berbeda, jadi tentukan batas ketika penting: label tombol pendek, judul tab, toast messages, dan apa pun di kartu tetap. Jika string harus tetap satu baris, sebutkan. Jika pemenggalan baris boleh, jelaskan di mana aman.

Tandai bagian yang “jangan diterjemahkan” dengan jelas. Nama produk, nama paket, kode kupon, field API, dan placeholder seperti {name} harus tetap utuh. Tanpa panduan, penerjemah mungkin melokalkan dan aplikasi jadi tidak masuk akal.

Paket praktis per string:

• Screenshot atau nama layar (mis. “Checkout - Payment method”)
• Tipe dan intent (tombol yang mengonfirmasi pembayaran)
• Catatan nada (tenang, meyakinkan)
• Kendala (maks 18 karakter, satu baris)
• Token terlindungi (nama produk, integrasi, {amount})

Perlakukan teks legal dan konten support sebagai aliran terpisah. Copy legal sering butuh persetujuan dan update lebih lambat, jadi pisahkan dari string UI produk dan versioning dengan hati-hati. Artikel support biasanya perlu terjemahan bentuk panjang dan bisa ditempatkan di sistem atau set file berbeda.

Contoh: tombol “Continue” di mobile mungkin butuh batas yang lebih ketat daripada web. Jika penerjemah tahu itu, mereka bisa memilih kata kerja yang lebih pendek di bahasa yang meluas daripada memaksa redesign UI mendadak.

QA dan loop review yang mencegah UI rusak

Kerusakan UI akibat lokalisasi jarang terlihat seperti "bug" pada awalnya. Mereka terlihat seperti label hilang, tombol yang membungkus dua baris, atau placeholder yang menampilkan nilai salah. Alur kerja yang baik memasukkan langkah QA yang menyingkap masalah itu sebelum pengguna.

Mulai dengan pseudo-lokalisasi di build development. Ganti string nyata dengan versi lebih panjang dan beraksen (mis. "[!!! Šéttïñĝš !!!]") dan tingkatkan panjang 30–50%. Ini cepat mengekspos pemangkasan, overlap, dan string yang di-hardcode di web dan native.

Tambahkan pemeriksaan otomatis di setiap build. Mereka menangkap kesalahan membosankan yang manusia lewatkan saat meninjau ratusan baris:

• Kunci hilang di locale mana pun (fallback menyembunyikan masalah sampai nanti)
• Kunci tidak terpakai (tanda Anda melayang dan mengirim teks mati)
• Mismatch placeholder ("Hello, {name}" vs "Hello, {username}")
• Bentuk plural tidak valid untuk locale (zero, one, few, many)
• Pola terlarang seperti HTML mentah dalam string mobile

Lalu gunakan loop sign-off manual yang jelas. Product memverifikasi makna dan nada untuk layar kunci, sementara QA memeriksa tata letak dan interaksi.

Jaga matriks tes kecil tapi ketat. Jangan uji semuanya. Uji yang paling mungkin rusak: login/signup, password reset, checkout atau konfirmasi pembayaran, settings dan edit profil, notifikasi dan empty states, serta layar dengan tabel, badge, atau tombol kecil.

Saat melaporkan masalah, buat perbaikannya mudah dengan spesifik. Sertakan locale, perangkat dan versi OS (atau browser dan lebar), teks yang diharapkan, teks aktual, dan screenshot yang menunjukkan area terpotong. Jika melibatkan plural atau placeholder, tempelkan kunci tepatnya dan string yang dirender.

Kesalahan umum dan cara menghindarinya

Sebagian besar bug lokalisasi bukan "masalah terjemahan." Mereka masalah alur kerja yang muncul sebagai UI rusak, teks hilang, atau pesan membingungkan.

Jebakan umum adalah mengganti nama kunci padahal yang diinginkan hanya ubah kata. Kunci harus ID stabil, bukan teks. Jika Anda mengganti checkout.button.pay menjadi checkout.button.pay_now, semua terjemahan lama menjadi “hilang,” dan Anda kehilangan riwayat. Pertahankan kunci, perbarui string bahasa dasar, dan tambahkan konteks jika makna berubah.

Masalah sering lain adalah meng-hardcode string di satu platform. Tim web menggunakan kunci, tapi tim mobile memasukkan teks literal untuk perbaikan cepat. Sebulan kemudian, pengguna melihat alert berbahasa Inggris di iOS. Jadikan "tidak ada string user-facing yang di-hardcode" aturan bersama web dan native.

Placeholder menyebabkan kesalahan halus ketika Anda berasumsi urutan kata. Bahasa Inggris bekerja dengan "{count} items", tapi bahasa lain mungkin butuh urutan berbeda atau kata tambahan. Gunakan placeholder bernama (bukan positional) dan jaga konsistensi antar platform.

Kesalahan yang patut ditangkap lebih awal:

• Memperlakukan kunci seperti copy, lalu merusak terjemahan yang ada. Jaga kunci stabil.
• Menggunakan satu kunci untuk dua makna. Pisahkan kunci ketika intent berbeda.
• Mencampur gaya placeholder (sebagian bernama, sebagian bernomor). Standarkan satu.
• Hanya mengetes di Inggris. Selalu cek setidaknya satu locale teks panjang dan satu locale kompak.
• Mengirim tanpa rencana fallback. Tentukan apa yang terjadi saat kunci hilang.

Menguji hanya satu bahasa "panjang" tidak cukup. Jerman sering memperluas UI, sementara Cina bisa menyembunyikan masalah spasi. Lakukan uji cepat di keduanya, dan juga cek kasus plural seperti 0, 1, dan 2.

Setujui perilaku fallback sebelum rilis. Contoh: jika Prancis hilang, fallback ke Inggris, catat kunci hilang, dan blokir rilis hanya jika layar kritis kosong.

Daftar periksa cepat dan langkah praktis berikutnya

Alur lokalisasi sehat ketika pengecekan kecil dan dapat diulang. Tujuannya sederhana: lebih sedikit string mengejutkan, lebih sedikit tata letak rusak, lebih sedikit rush terjemahan mendadak.

Sebelum merge perubahan UI, lakukan pemeriksaan cepat untuk masalah “ops” umum:

• Kunci baru mengikuti aturan penamaan dan berada di namespace yang benar (layar atau fitur).
• Placeholder cocok persis di seluruh bahasa (variabel sama, makna sama).
• Bentuk plural lengkap untuk bahasa yang Anda dukung (bukan hanya tunggal/jamak Inggris).
• Tidak ada teks yang di-hardcode di UI (termasuk error state dan empty state).
• Teks baru atau diubah memiliki konteks dasar (screenshot atau catatan jelas).

Sebelum kirim, jalankan QA rilis singkat fokus pada tempat lokalisasi pertama kali rusak. Batasi waktu, tapi konsisten: alur pengguna teratas di setiap platform yang Anda kirim, satu pengecekan RTL, layar teks panjang (settings, legal, onboarding, tabel, tombol sempit), dan pemformatan tanggal/angka/mata uang di beberapa locale.

Tetapkan cadence yang sesuai tim Anda. Banyak tim memperbarui terjemahan mingguan, lalu membekukan string 1–2 hari sebelum rilis. Intinya untuk menghindari mencampur edit copy menit terakhir dengan QA final.

Langkah berikut yang cepat memberi hasil: tuliskan konvensi Anda (penamaan kunci, placeholder, aturan plural, kepemilikan), lalu jalankan satu layar pilot end-to-end dan sesuaikan berdasarkan apa yang rusak.

Jika Anda membangun lintas backend, UI web, dan mobile native di platform tunggal seperti AppMaster, lebih mudah menjaga kunci dan placeholder konsisten karena layar dan logika yang sama bisa berbagi konvensi. Menjaga konvensi itu stabil membuat lokalisasi terasa rutin alih-alih rapuh.