10 kesalahan i18n yang sering terjadi dan bagaimana cara memperbaikinya.
Pelajari kesalahan internasionalisasi yang paling umum yang dibuat pengembang, dan bagaimana cara memperbaikinya. Tingkatkan kualitas lokalisasi aplikasi Anda dengan praktik terbaik ini.
Internasionalisasi (i18n) tampak sederhana — sampai kamu menemukan bahwa pengguna Jermanmu melihat tombol yang terpotong, pengguna Jepangmu mendapatkan fragmen kalimat yang terpotong, dan pengguna berbahasa Arabmu mengalami tata letak yang benar-benar rusak. Itu bukan kejadian langka. Itu adalah konsekuensi yang bisa diprediksi dari kesalahan umum yang dilakukan sebagian besar tim pengembangan saat pertama kali menangani lokalisasi. Dalam panduan ini kita akan membahas 10 kesalahan i18n yang paling umum, menjelaskan dengan tepat mengapa mereka terjadi, dan menunjukkan langkah demi langkah bagaimana memperbaikinya. Tidak peduli apakah kamu membangun aplikasi baru atau menambahkan lokalisasi pada yang sudah ada — menghindari jebakan ini akan menghemat minggu-minggu debugging.
Kesalahan #1: Hardcodierte Strings
Hardcoding string adalah kesalahan i18n yang paling mendasar. Ini terjadi karena pengembang terlebih dulu fokus pada membuat fitur berjalan, dan berencana 'nanti diperbaiki'. Namun nanti tidak pernah datang, dan tiba-tiba ada ribuan string tersebar di ratusan berkas.
['Pasang kerangka i18n sebelum menulis baris kode UI pertama', 'Gunakan plugin linter untuk mendeteksi string yang di-hardcode di template dan komponen', 'Jaga agar kunci terjemahan deskriptif dan diatur menurut fitur atau halaman']
Pasang kerangka i18n sebelum menulis baris kode UI pertama
Gunakan plugin linter untuk mendeteksi string yang di-hardcode di template dan komponen
Jaga agar kunci terjemahan deskriptif dan diatur menurut fitur atau halaman
Skenario tipikal
한 개발자가 JSX에 버튼 레이블을 직접 작성합니다: <button>Submit Order</button>.
Aplikasi ini dikirim dalam bahasa Inggris dan berfungsi dengan baik. Enam bulan kemudian perusahaan berekspansi ke Jerman.
Tim lokalisasi menemukan lebih dari 2.000 string yang di-hardcode. Proses penyesuaian memerlukan 3 minggu dan menimbulkan 47 bug.
Mengapa ini masalah
Dalam basis kode yang matang, string yang di-hardcode bisa mencapai ribuan. Mengekstraknya secara belakangan berarti menyentuh setiap file, menguji ulang setiap komponen, dan berisiko regresi di mana-mana.
Hardcoded strings adalah ter-embed langsung dalam kode sumber, template, atau komponen. Mereka tidak bisa diekstrak, diterjemahkan, atau diganti saat berjalan tanpa mengubah kode itu sendiri.
Pengguna dengan lokal non-Inggris melihat elemen UI yang tidak diterjemahkan tercampur dengan konten yang telah diterjemahkan — kesan kacau dan tidak profesional.
Cara Mengatasinya
Pindahkan semua strings yang terlihat pengguna dari awal ke file sumber daya.
Rancang kerangka kerja i18n (mis. next-intl, react-i18next, vue-i18n) sebelum menulis komponen pertama.
Buat struktur berkas sumber daya (mis. messages/de.json) dan referensikan semua string lewat kunci terjemahan seperti t('checkout.submitButton').
Tambahkan aturan linting atau hook pre-commit yang menandai string literal mentah di komponen UI.
Kesalahan #10: Menerjemahkan semuanya secara harfiah
Tidak semua konten harus diterjemahkan. Nama merek, nama pihak hukum, istilah teknis, dan beberapa nama produk harus tetap dalam bahasa aslinya. Terjemahan berlebih dapat menimbulkan masalah hukum, inkonsistensi merek, dan kebingungan pengguna.
["Kembangkan glosarium 'Tidak diterjemahkan' dan bagikan ke semua penerjemah", 'Gunakan segmen yang 'terkunci' atau namespace terpisah untuk istilah merek dan istilah hukum', 'Selalu sediakan catatan konteks untuk string yang ambigu, guna mencegah terjemahan yang salah']
Kelola glosarium 'Tidak diterjemahkan' dan bagikan dengan semua penerjemah
Gunakan segmen terkunci atau namespace terpisah untuk istilah merek dan istilah hukum
Selalu berikan catatan konteks untuk string yang ambigu agar menghindari terjemahan yang salah
Skenario tipikal
Sebuah file terjemahan berisi nama perusahaan 'CloudForge Inc.' dan istilah teknis 'OAuth 2.0 Token' sebagai string yang dapat diterjemahkan.
Penerjemah Spanyol menerjemahkan 'CloudForge' menjadi 'ForjaNube' dan 'OAuth 2.0 Token' menjadi 'ficha OAuth 2.0'.
Hasilnya: Pengguna tidak menemukan perusahaan tersebut dengan nama aslinya, dan pengembang yang membaca dokumentasi berbahasa Spanyol bingung karena istilah teknis terjemahan yang tidak dikenal.
Mengapa ini masalah
Satu nama merek yang salah diterjemahkan dalam dokumen hukum dapat membuat kontrak tidak sah. Mengoreksi terjemahan berlebih memerlukan pemeriksaan setiap string dalam setiap bahasa — pekerjaan yang memakan beberapa minggu.
Jika semua string dikirim ke terjemahan tanpa konteks, penerjemah mungkin menerjemahkan merek dagang ('Apple' → 'Apfel'), istilah hukum ('GmbH' → 'LLC'), atau terminologi teknis yang harus tetap dalam bahasa Inggris.
Pengguna tidak menemukan produk dengan nama merek yang dikenal, dokumen hukum merujuk pada perusahaan yang salah, dan dokumentasi teknis menjadi tidak dapat dipahami jika istilah seperti 'API Endpoint' diterjemahkan.
Cara mengatasinya
번역하지 않는 콘텐츠를 명확하게 표시하고 번역가를 위한 맥락 노트를 제공하세요.
Buat glosarium 'Tidak diterjemahkan' yang mencantumkan semua nama merek, nama produk, entitas hukum, dan istilah teknis yang harus tetap tidak berubah.
Gunakan namespace terpisah atau kunci khusus untuk konten yang tidak dapat diterjemahkan. Banyak alat i18n mendukung segmen 'terenkripsi' yang tidak bisa diedit oleh penerjemah.
Tambahkan komentar penerjemah/penjelasan ke file terjemahanmu yang menjelaskan konteks: 'Ini adalah merek — jangan diterjemahkan' atau 'Istilah teknis — biarkan dalam bahasa Inggris'.
Fehler #2: String-Verkettung
Menyatukan kalimat dari fragmen-fragmen terdengar logis dalam bahasa Inggris, tetapi tidak berfungsi dalam bahasa lain. Urutan kata, tata bahasa, dan struktur kalimat sangat berbeda antar bahasa, membuat string yang digabungkan menjadi tidak bisa diterjemahkan.
['Jangan pernah menggabungkan kalimat melalui penggabungan fragmen terjemahan', 'Gunakan placeholder bernama ('{name}') daripada posisi ({0}) untuk kejelasan', 'Sediakan komentar konteks untuk penerjemah yang menjelaskan isi setiap placeholder']
Jangan pernah membangun kalimat dengan menggabungkan fragmen terjemahan
Gunakan placeholder bernama ('{name}') daripada posisi ({0}) untuk kejelasan
Sediakan komentar konteks untuk penerjemah yang menjelaskan apa isi setiap placeholder
Skenario tipikal.
Pengembang menulis: 'You have ' + count + ' items in your ' + cartType + ' cart' — berfungsi sempurna dalam bahasa Inggris.
Penerjemah Jerman menerima tiga fragmen terpisah dan tidak bisa membentuk kalimat tata bahasa yang benar karena susunan katanya harus diubah.
Hasilnya: Pengguna Jerman melihat 'Sie haben 5 Artikel in Ihrem Warenkorb Standard' — terdengar canggung dan tidak profesional.
Mengapa itu masalah
Setiap string yang dihubungkan adalah bom waktu yang berdetak. Dengan 20 bahasa dan 50 string yang dihubungkan, Anda memiliki 1.000 potensi kesalahan tata bahasa yang harus diperbaiki secara manual.
Penggabungan string seperti 'Willkommen ' + userName + ', du hast ' + count + ' neue Nachrichten' mengharuskan susunan kata tertentu. Penerjemah menerima fragmen yang tidak memiliki konteks sehingga tidak bisa mengatur ulang.
Pengguna melihat kalimat yang secara gramatikal salah. Dalam bahasa Jerman, kata kerja sering berada di akhir kalimat. Dalam bahasa Arab, seluruh strukturnya terbalik. Hasilnya terdengar seperti omong kosong.
Begini cara mengatasinya
Gunakan pesan terparametris dengan placeholder bernama, agar penerjemah bisa menyusun ulang seluruh kalimat.
Ganti penggabungan dengan satu kunci pesan dengan placeholder: 'cart.summary': 'Anda memiliki {count} item di keranjang '{cartType}''.
Serahkan variabel sebagai parameter ke fungsi terjemahanmu: t('cart.summary', { count: 5, cartType: 'Premium' }).
Penerjemah sekarang dapat mengatur ulang secara bebas: 'Di keranjang '{cartType}', terdapat {count} item' — bahasa Jerman yang gramatikal.
Fehler #3: Pluralisierung ignorieren
Inglese hat zwei Pluralformen: Singular und Plural. Entwickler nehmen oft an, alle Sprachen funktionieren genauso. Tun sie nicht. Polnisch hat 4 Formen, Arabisch hat 6, und selbst Sprachen wie Französisch behandeln die Null anders als Englisch.
['Gunakan selalu ICU MessageFormat atau pustaka ekuivalen untuk konten yang bisa dihitung', 'Jangan pernah menulis logika jamak sendiri — percayai aturan CLDR', 'Uji jamak dengan nilai seperti 0, 1, 2, 5, 21, dan 100 untuk mencakup semua kategori']
Selalu gunakan ICU MessageFormat atau perpustakaan setara untuk konten yang dapat dihitung
Jangan pernah menulis logika jamak sendiri — percayalah pada aturan CLDR
Uji bentuk jamak dengan nilai seperti 0, 1, 2, 5, 21 dan 100 untuk mencakup semua kategori
Ein typisches Szenario
Pengembang menulis: count + (count === 1 ? ' Datei' : ' Dateien') — menangani bahasa Jerman dengan benar.
Penerjemah Polandia membutuhkan 4 bentuk: 1 plik, 2–4 pliki, 5–21 plików, 22–24 pliki. Operator ternary sederhana tidak bisa mengekspresikannya.
Hasilnya: Pengguna Polandia melihat '5 pliki' (bentuk salah) daripada '5 plików' (bentuk benar), dan aplikasinya terasa rusak.
Mengapa ini menjadi masalah
Setiap kata benda yang bisa dihitung dalam aplikasimu membutuhkan penanganan bentuk jamak. Dengan 50 string seperti itu dan 20 bahasa, itu berarti 1.000 aturan jamak — mustahil untuk dikelola secara manual.
Pemeriksaan if/else sederhana (count === 1 ? 'Datei' : 'Dateien') hanya menangani bahasa Jerman/Inggris. CLDR mendefinisikan hingga 6 kategori jamak: zero, one, two, few, many, dan other. Setiap bahasa menggunakan subset yang berbeda.
Pengguna melihat teks yang secara gramatikal salah seperti '1 pesan' atau bentuk jamak yang sepenuhnya salah. Dalam konteks formal, ini merusak kredibilitas.
Begini cara mengatasinya
Gunakan ICU MessageFormat, yang mendukung semua aturan jamak CLDR secara bawaan.
Tetapkan pesan dengan sintaks ICU: 'fileCount': '{count, plural, one {# Datei} other {# Dateien}}'.
Penerjemah menyediakan semua bentuk jamak yang dibutuhkan untuk bahasanya. Polandia: '{count, plural, one {# plik} few {# pliki} many {# plików} other {# pliku}}'.
Pustaka i18n-mu secara otomatis memilih bentuk yang benar saat runtime berdasarkan aturan CLDR dari locale yang aktif.
Kesalahan #4: Lebar elemen UI yang tetap.
Desainer membuat tata letak pixel-perfect dalam bahasa Inggris, dan pengembang mengimplementasikannya dengan lebar tetap. Namun teks terjemahan bisa sangat panjang atau sangat pendek. Teks Jerman sekitar 30% lebih panjang daripada Inggris, sedangkan teks bahasa Tiongkok bisa sekitar 50% lebih pendek.
['Jangan pernah menggunakan lebar piksel tetap pada elemen dengan teks yang bisa diterjemahkan', 'Rencanakan peningkatan teks sekitar 40% sebagai baseline — beberapa bahasa bisa berkembang lebih banyak', 'Gunakan CSS Flexbox atau Grid untuk tata letak yang menyesuaikan panjang konten variabel']
Jangan pernah menggunakan lebar piksel tetap untuk elemen dengan teks yang dapat diterjemahkan
Rencanakan peningkatan teks sebesar 40% sebagai baseline — beberapa bahasa mungkin lebih berkembang
Gunakan CSS Flexbox atau Grid untuk tata letak yang menyesuaikan panjang konten variabel
Skenario tipikal
Desainer membuat navigasi bar dengan 5 tombol, masing-masing persis 100px lebar — terlihat oke dalam bahasa Inggris.
Terjemahan bahasa Jerman: 'Settings' menjadi 'Einstellungen' (13 berbanding 8 karakter), 'Submit' menjadi 'Absenden' (8 berbanding 6). Navbar melampaui batas.
Hasilnya: Pada perangkat seluler tombol-tombol saling tumpuk satu sama lain atau teks terpotong, membuat navigasi bagi pengguna Jerman tidak dapat digunakan.
Mengapa ini menjadi masalah
Setiap elemen dengan lebar tetap adalah potensi titik pecah. Aplikasi tipikal memiliki ratusan tombol, label, dan kartu yang semuanya harus mampu menampung perluasan teks.
Container dengan lebar tetap (width: 120px) dan tombol berukuran tetap terpotong atau meluap ketika teks membesar. CSS overflow: hidden secara diam-diam menyembunyikan konten, sedangkan overflow: visible menghancurkan tata letak.
Pengguna melihat label yang terpotong seperti 'Einstellu...' bukan 'Einstellungen', atau tombol-tombol yang tumpang tindih elemen di sekitarnya. Tindakan penting menjadi tidak bisa dibaca atau tidak dapat diklik.
Begini cara mengatasinya
Gestalte dan implementiere flexible Layouts, die sich an die Inhaltslänge aller Locales anpassen.
Ganti lebar tetap dengan min-width, max-width dan tata letak Flex. Gunakan CSS Grid atau Flexbox untuk membagi ruang secara dinamis.
Atur wadah teks agar membungkus: gunakan overflow-wrap: break-word dan hindari white-space: nowrap pada konten yang bisa diterjemahkan.
Uji UI Anda dengan lokalisasi palsu yang memperpanjang semua string sekitar 40% untuk mensimulasikan kasus terburuk — bahkan sebelum Anda mengirim string ke penerjemah.
Kesalahan #5: Pemformatan tanggal dan nombor.
Data dan angka tampak universal. Tetapi 01/02/2025 berarti 2 Januari di AS dan 1 Februari di Eropa. Koma dan tanda titik dalam angka memiliki arti berbeda: 1,000.50 (AS) vs 1.000,50 (Jerman). Melakukannya salah dapat membingungkan, menyebabkan kesalahan data, dan kehilangan kepercayaan.
['Jangan pernah memformat data atau angka secara manual dengan template string — selalu gunakan API Intl', 'Simpan semua data dalam ISO 8601 dan mata uang dalam satuan terkecil (sen) secara internal', 'Uji dengan Locales yang menggunakan pemisah desimal, urutan tanggal, dan sistem kalender yang berbeda']
Jangan pernah memformat data atau angka secara manual menggunakan template string — selalu gunakan API Intl
Simpan semua data dalam ISO 8601 dan mata uang dalam satuan terkecil (sen) secara internal
Uji dengan locale yang menggunakan pemisah desimal, urutan tanggal, dan sistem kalender yang berbeda
Ein typisches Szenario
Pengembang memformat tanggal sebagai MM/DD/YYYY dan harga sebagai $1,234.50 — benar untuk pengguna AS.
Pengguna Jerman melihat tanggal 03/04/2025 dan membacanya sebagai 3 April (konvensi DD/MM/YYYY). Harga $1,234.50 terlihat seharusnya menjadi 1.234,50.
Hasilnya: Pengguna memesan penerbangan untuk tanggal yang salah dan mempertanyakan format harga. Tiket dukungan naik di pasar Jerman sebesar 15%.
Mengapa ini menjadi masalah
Format tanggal dan angka memengaruhi setiap tampilan data di aplikasi Anda: tabel, diagram, formulir, faktur, laporan. Perbaikan global mencakup ratusan instance.
String format yang di-hardcode seperti toLocaleDateString('en-US') atau pemformatan manual dengan template-literals mengabaikan locale pengguna yang sebenarnya. Bahkan locale yang benar pun bisa bermasalah jika sistem kalendernya salah (Gregorian vs Hijri).
Pengguna membaca data salah dan memasukkan data dalam format yang salah. Pengguna Eropa yang melihat 03/04/2025 mungkin menginterpretasikannya sebagai 3 April, bukan 4 Maret — janji temu yang terlewat atau pemesanan yang salah.
Begini cara mengatasinya
Gunakan API Intl bawaan atau pustaka pemformatan yang sensitif terhadap lokal untuk semua tanggal, waktu, angka, dan mata uang.
Ganti pemformatan manual dengan Intl.DateTimeFormat(locale) untuk tanggal, dan Intl.NumberFormat(locale, { style: 'currency', currency }) untuk harga.
Simpan data secara internal dalam format ISO 8601 (YYYY-MM-DD) dan formatkan hanya untuk tampilan dengan locale pengguna.
Uji tampilan tanggal/angka yang kritis dengan setidaknya 5 lokal yang berbeda: en-US, de-DE, ja-JP, ar-SA dan zh-CN, untuk mencakup varian-format yang paling penting.
Kesalahan #6: RTL-Sprachen vergessen.
Deskripsi kesalahan: Bahasa RTL seperti Arab, Ibrani, dan Persia digunakan oleh lebih dari 500 juta orang. Namun sebagian besar aplikasi masih dirancang hanya untuk tata letak kiri-ke-kanan (LTR). Dukungan RTL tidak berarti hanya membalik teks — seluruh antarmuka pengguna harus dicerminkan.
['Gunakan sejak hari pertama properti CSS logis saja (inline-start/end, block-start/end)', "Tes aplikasi Anda dengan dir='rtl' pada elemen HTML di setiap tinjauan sprint", 'Buat checklist uji RTL untuk navigasi, ikon, formulir, dan indikator kemajuan']
Gunakan sejak hari pertama properti CSS logis saja (inline-start/end, block-start/end)
Tes aplikasi Anda dengan dir='rtl' pada elemen HTML di setiap tinjauan sprint
Buat checklist uji RTL untuk navigasi, ikon, formulir, dan indikator kemajuan
Skenario tipikal
Pengembang menggunakan margin-left: 16px dan text-align: left di seluruh aplikasi — praktik standar LTR.
Aplikasi dimulai di Arab Saudi. Tombol kembali menunjuk ke arah depan, sidebar muncul di sisi yang salah, dan data numerik tidak teratur.
Hasilnya: Pengguna Arab meninggalkan aplikasi setelah 30 detik. Tim membutuhkan 4 minggu refactoring CSS darurat untuk mengatasi masalah ini.
Mengapa ini menjadi masalah
Dukungan RTL mencakup setiap komponen di aplikasi Anda. Memperkenalkan RTL secara bertahap biasanya memerlukan penulisan ulang 30-50% dari semua aturan CSS dan pemeriksaan setiap ikon serta tata letak.
Properti CSS seperti margin-left, padding-right, text-align: left dan float: left meng-hardcode arah. Ikon dengan arti arah (panah, indikator kemajuan) menunjuk ke arah yang salah. Bahkan nilai border-radius perlu dicerminkan.
Pengguna Arab melihat navigasi di sudut yang salah, bilah kemajuan berjalan ke belakang, dan teks yang bertabrakan dengan elemen UI. Aplikasi terasa asing dan tidak dapat digunakan.
Begini cara mengatasinya
Gunakan properti CSS logis dan uji dengan tata letak RTL sejak awal.
Ganti semua properti CSS fisik dengan padanan logis: margin-left → margin-inline-start, padding-right → padding-inline-end, text-align: left → text-align: start.
Setel atribut dir pada elemen root HTML Anda berdasarkan Locale yang aktif. Gunakan pseudokelas CSS :dir(rtl) untuk override khusus RTL.
Periksa semua ikon untuk arti arah. Ganti ikon yang bergantung pada arah dengan versi yang dicerminkan atau gunakan CSS transform: scaleX(-1) untuk konteks RTL.
Kesalahan #7: Bilder mit Text
Menyisipkan teks ke dalam gambar — baik di hero banner, tombol, infografis, atau screenshot — adalah mimpi buruk lokalisasi. Setiap gambar dengan teks harus dibuat ulang untuk setiap bahasa, yang menggandakan biaya desain dan menunda rilis.
['Jangan pernah menempatkan teks yang dapat diterjemahkan secara langsung ke dalam gambar raster (PNG, JPG)', 'Gunakan overlay teks CSS pada gambar latar untuk hero banner dan CTA', 'Otomatiskan pembuatan screenshot untuk listing App Store dan halaman pemasaran']
Jangan pernah menempatkan teks yang bisa diterjemahkan langsung ke gambar raster (PNG, JPG)
Gunakan overlay teks CSS pada gambar latar belakang untuk hero banner dan CTA
Otomatisasikan pembuatan screenshot untuk listing App Store dan halaman pemasaran
Skenario tipikal
Seorang perancang membuat banner promosi dengan teks 'Start Your Free Trial' yang disisipkan langsung ke dalam gambar.
Tim Lokalisasi menerjemahkan semua string UI, tetapi banner pada halaman bahasa Jerman masih menampilkan teks Inggris.
Hasilnya: Halaman pendaratan Jerman memiliki banner bahasa Inggris yang membingungkan. Membuat banner yang dilokalkan untuk 15 bahasa memerlukan 3 hari pekerjaan desain dan akan menunda peluncuran.
Mengapa ini menjadi masalah
Sebutan halaman pemasaran tipikal memiliki 5-10 gambar dengan teks. Dalam 15 bahasa, itu berarti 75-150 variasi gambar yang harus dibuat, dipelihara, dan diperbarui setiap kali ada perubahan desain.
Teks yang tertanam dalam gambar (PNG, JPG, SVG dengan teks tertanam) tidak bisa diekstrak oleh alat terjemahan. Setiap versi lokal memerlukan desainer untuk mengedit file sumber secara manual, mengekspor, dan mengunggahnya.
Pengguna melihat gambar dengan teks dalam bahasa asing, atau lebih buruk lagi, campuran antara antarmuka terlokalisasi dan gambar yang belum diterjemahkan. Hal ini terasa tidak konsisten dan merusak kepercayaan terhadap merek.
Begini cara mengatasinya
Separasikan teks dari gambar dengan overlay CSS, SVG dengan elemen teks yang dapat diterjemahkan, atau generasi gambar dinamis.
Gunakan CSS untuk menempatkan teks yang bisa diterjemahkan di atas gambar latar: posisikan lapisan teks dengan posisi absolut di atas wadah gambar.
Untuk infografis atau diagram, gunakan SVG dengan elemen <text> yang merujuk pada kunci terjemahan, daripada menempatkan string mentah.
Untuk screenshot aplikasi dalam materi pemasaran, otomatisasikan pembuatan screenshot dengan alat seperti Fastlane (Mobile) atau Playwright (Web), yang mengambil screenshot dalam setiap locale.
Kesalahan #8: Terjemahan yang hilang tidak ditangani
Dalam pengembangan, terjemahan selalu tidak lengkap. Fitur baru menambahkan string lebih cepat daripada penerjemah bisa menerjemahkannya. Tanpa mekanisme fallback yang tepat, terjemahan yang hilang menyebabkan crash, elemen UI kosong, atau kunci terjemahan mentah yang ditampilkan kepada pengguna.
['Selalu konfigurasikan setidaknya satu bahasa fallback dalam pengaturan i18n-mu', 'Catat kunci terjemahan yang hilang ke sistem pemantauan untuk pelacakan', 'Tetapkan tingkat cakupan terjemahan minimum sebelum suatu locale dapat dirilis']
Selalu konfigurasikan setidaknya satu bahasa fallback dalam pengaturan i18n Anda
Lacak kata kunci terjemahan yang hilang ke sistem pemantauan Anda untuk pelacakan
Tentukan tingkat cakupan terjemahan minimum sebelum locale dapat ditayangkan
Skenario tipikal
Pengembang menambahkan area 'Premium Features' baru dengan 15 kunci terjemahan baru. Versi Inggris langsung dirilis.
Terjemahan bahasa Prancis belum selesai. Halaman Prancis menampilkan kunci mentah: 'premium.feature1.title', 'premium.feature1.description'.
Hasilnya: Pengguna Prancis melihat halaman yang rusak dengan banyak nama kunci yang bersifat pengembang. Tim dukungan menerima puluhan laporan bug.
Mengapa ini masalahnya
Semakin besar aplikasi Anda, semakin besar celah antara string bahasa Inggris dan terjemahan dalam bahasa lain. Aplikasi dengan 100 bahasa dan 2.000 string bisa memiliki lebih dari 10.000 terjemahan mancanti setiap saat.
Tanpa logika fallback, sebuah kunci terjemahan yang hilang akan mengembalikan undefined, null, atau string kunci mentah (misalnya 'checkout.confirmButton'). Mesin template dapat menghasilkan error, halaman bisa crash, atau tidak merender apa pun.
Pengguna melihat UI yang rusak: tombol kosong, label hilang, atau string yang membingungkan seperti 'nav.settings.title' alih-alih teks asli. Ini membingungkan dan tidak profesional.
Sei
Configura una robusta catena di fallback e monitora la copertura delle traduzioni in tutte le località.
Atur rantai bahasa fallback dalam konfigurasi i18n Anda: kunci bahasa Prancis (fr) yang hilang secara otomatis akan kembali ke Inggris (en).
Tambahkan pengelola Missing-Key yang mencatat kunci yang belum diterjemahkan ke sistem pemantauan Anda (misalnya Sentry, Datadog) tanpa mengganggu pengalaman pengguna.
Buat dashboard cakupan terjemahan yang melacak tingkat penyelesaian per locale dan memblokir rilis jika cakupan turun di bawah ambang batas (misalnya 95%).
Kesalahan #9: Zeichenkodierungsprobleme
Masalah pengkodean karakter adalah pembunuh diam-diam lokalisasi. Semuanya tampak baik dalam bahasa Inggris dan bahasa Eropa, tetapi begitu Anda menambahkan Tionghoa, Jepang, Korea, Arab, atau emoji, karakter-karakter terdistorsi muncul (Mojibake). Bug-bug ini terkenal sulit dilacak.
['Gunakan pengkodean UTF-8 di mana-mana — berkas sumber, basis data, respons API, dan tag meta HTML', 'Gunakan utf8mb4 di MySQL (bukan utf8) untuk mendukung seluruh rentang Unicode termasuk emoji', 'Uji dengan konten asli dalam CJK, Arab, dan Emoji untuk mendeteksi masalah pengkodean sejak dini']
Gunakan pengkodean UTF-8 di mana-mana — berkas sumber, basis data, respons API, dan tag meta HTML
Gunakan utf8mb4 di MySQL (bukan utf8) untuk mendukung seluruh rentang Unicode termasuk emoji
Uji dengan konten asli dalam CJK, Arab, dan Emoji untuk mendeteksi masalah pengkodean sejak dini
Skenario tipikal
Pengembang mengatur basis data MySQL dengan kolasi latin1 (standar lama). Kode sumber aplikasi menggunakan UTF-8.
Pengguna Jepang mendaftar dengan nama asli mereka. Basis data menyimpan '田中太郎' sebagai bytes yang rusak.
Hasilnya: profil pengguna menampilkan teks yang rusak. Yang lebih buruk: pencarian dan pengurutan untuk semua nama CJK rusak, yang melibatkan ribuan pengguna.
Mengapa ini masalah
Masalah pengkodean menyebar ke seluruh stack Anda. Kolasi basis data yang salah bisa merusak jutaan entri data — pemulihannya memerlukan migrasi basis data yang mahal.
Koding yang tidak konsisten di seluruh stack — UTF-8 di berkas sumber, Latin-1 di basis data, dan Windows-1252 di respons API — merusak karakter multibyte. Satu lapisan yang salah konfigurasi bisa mengubah '日本語' menjadi '????' atau '日本èª'.
Pengguna melihat teks yang terpotong, tanda tanya, atau kotak kosong, di mana bahasa mereka seharusnya muncul. Dalam kasus terburuk, entri formulir bisa rusak secara permanen di basis data.
Begini cara mengatasinya
Tegakkan pengkodean UTF-8 secara konsisten di setiap lapisan tumpukan aplikasi Anda.
Setel semua berkas sumber ke UTF-8 (sesuaikan editor dan .editorconfig Anda). Tambahkan <meta charset='UTF-8'> ke HTML Anda dan 'Content-Type: application/json; charset=utf-8' pada respons API.
Konfigurasikan basis data Anda ke utf8mb4 (bukan hanya utf8, yang merupakan subset 3-byte di MySQL). Atur kolasi koneksi ke utf8mb4_unicode_ci.
Pilih font yang mencakup skrip target Anda: Latin, Kiril, CJK, Arab, Devanagari. Gunakan tumpukan font sistem atau Google Fonts dengan subset bahasa untuk pemuatan yang optimal.
Uji implementasi i18n Anda.
Pengujian Perluasan Panjang
Perluas semua string terjemahan 30-40% untuk mensimulasikan peningkatan teks yang terjadi pada bahasa yang kaya kata seperti Jerman, Finlandia atau Yunani. Ini mencakup wadah dengan lebar tetap, label yang terpotong, dan tombol yang meluap sebelum Anda mulai menerjemahkan. Banyak alat pseudo-lokalization menyediakan ini sebagai fitur bawaan.
"Kirim" → "Ṡééééñðéñ_éxpáñðéð" (40% lebih panjang)
Pseudo-Lokalisierung
Lokalisasi semu menggantikan setiap karakter dengan padanan beraksen (mis. 'a' → 'á') dan membungkus string dengan penanda seperti [!! dan !!]. Hal ini membuat segera terlihat string mana yang hard-coded dan mana yang berasal dari sistem terjemahan. Jalankan lokalisasi semu sebagai bagian dari pipeline CI Anda untuk menangkap regresi secara otomatis.
각 화면의 텍스트 중 [!! !!]로 둘러싸여 있지 않은 모든 텍스트는 하드코딩되어 있으며 외부화해야 합니다. 이 테스트는 보이지 않는 문자열의 약 95%를 1분 이내에 포착합니다.
"Kirim pesan" → "[!! Ñáçḥŕíçḥṫ ṡéñðéñ !!]"
Uji Tata Letak RTL
Selain tanpa terjemahan Arab atau Ibrani, Anda dapat menguji tata letak RTL dengan menambahkan dir='rtl' ke elemen akar HTML Anda. Ini segera mengungkap bug tata arah CSS: ikon yang salah orientasi, margin di sisi yang salah, kaputte Navigation dan item Flex yang disortirnya salah. Jadikan ini sebagai pemeriksaan standar di setiap sprint review — memerlukan sekitar 10 detik untuk beralih dan menangkap masalah yang biasanya butuh berminggu-minggu untuk diperbaiki di produksi.
Daftar periksa i18n
['Semua string yang terlihat pengguna dipindahkan ke file sumber daya', 'Jangan menggunakan konkatenasi string untuk membuat kalimat', 'Tetapkan aturan jamak dengan ICU MessageFormat atau setara', 'Format tanggal, waktu, dan angka menggunakan API yang peka lokal', 'Uji tata letak RTL dengan konten bahasa Arab atau Ibrani', 'UI fleksibel tanpa lebar tetap untuk elemen berisi teks', 'Konfigurasikan bahasa fallback dan uji pada kunci yang hilang', 'Pengkodean UTF-8 konsisten di seluruh file dan basis data', 'Metadat App Store dan Play Store dilokalisasi untuk setiap pasar', 'Tangkapan layar dan aset pemasaran untuk setiap bahasa diperbarui']