Bagaimana Mendesain Sistem yang Siap-Lokalisasi

Di era globalisasi ini, perusahaan – termasuk pengembang perangkat lunak – selalu tertarik untuk melakukan ekspansi ke pasar baru. Ini sering berarti melokalkan produk mereka untuk area yang berbeda. Dalam artikel ini, kami akan menjelaskan beberapa pendekatan untuk merancang model data Anda untuk pelokalan – khususnya, untuk mengelola konten dalam berbagai bahasa.

Apa itu Lokalisasi?

Lokalisasi adalah proses mengadaptasi produk ke berbagai pasar. Ini adalah faktor utama dalam mencapai pangsa pasar maksimum dalam hal penjualan produk. Ketika pelokalan dilakukan dengan benar, pengguna akan merasa bahwa produk tersebut diproduksi untuk bahasa, budaya, dan kebutuhan mereka.

Di tempat-tempat di mana bahasa Inggris bukan bahasa pertama yang umum, survei membuktikan bahwa bahasa lokal lebih disukai untuk produk perangkat lunak. Artikel MediaPost ini memuat beberapa angka menarik tentang perlunya bahasa selain bahasa Inggris dalam hal penjualan internasional.

Apa yang Bisa Hilang Jika Anda Tidak Melokalkan?

Mari kita pertimbangkan contoh non-lokalisasi yang tidak menguntungkan. Untuk kenyamanan pelanggan, portal e-niaga memungkinkan pelanggan untuk menggabungkan pembelian individu ke dalam kelompok yang terdiri dari empat orang. Sayangnya, pengucapan kata "empat" dalam bahasa Jepang terdengar seperti kata mereka untuk "kematian." Orang Jepang biasanya menghindari segala hal yang berhubungan dengan angka ini karena dianggap sial. Tak perlu dikatakan, penjualan produk tersebut tidak berjalan dengan baik di pasar Jepang.

Jadi, untuk menjawab pertanyaan di atas, Anda bisa kehilangan banyak uang jika tidak merencanakan target pasar dengan cermat.

Terjemahan Konten sebagai Pelokalan

Ketika kita memikirkan pelokalan, terjemahan konten sering kali menjadi pikiran pertama yang muncul di benak kita. Pikiran kedua adalah “Kami membutuhkan model database yang kuat dan efisien untuk menyimpan konten yang diterjemahkan dalam berbagai bahasa”.

Misalkan kita diminta untuk merancang model data untuk aplikasi e-commerce multibahasa. Kami perlu menyimpan bidang teks seperti product_name dan deskripsi produk dalam berbagai bahasa. Kami juga perlu menyimpan bidang teks di tabel lain, seperti customer tabel, dalam semua bahasa ini.

Untuk memahami bagaimana merancang model data kami dengan mempertimbangkan terjemahan konten, kami akan memeriksa pendekatan yang berbeda dengan menggunakan dua tabel ini. Masing-masing pendekatan ini memiliki pro dan kontra. Pendekatan yang ditunjukkan di bawah ini dapat diperluas ke tabel lain dalam model data Anda. Tentu saja, pendekatan tepat yang Anda pilih akan didasarkan pada kebutuhan Anda sendiri.

Pendekatan 1 – Menambahkan Kolom Bahasa Terpisah untuk Setiap Bidang yang Dimaksud

Ini adalah pendekatan paling sederhana dalam hal pengembangan. Ini dapat diimplementasikan dengan menambahkan satu kolom bahasa untuk setiap bidang.

Pro

• Sangat mudah untuk diterapkan.

• Tidak ada kerumitan dalam menulis SQL untuk mengambil data dasar dalam bahasa apa pun. Misalkan saya ingin menulis kueri untuk mengambil detail produk dan pelanggan untuk pesanan tertentu dalam bahasa Prancis. Kodenya akan terlihat seperti ini:

  Pilih p.product_name_FR, p.description_FR, p.price, c.name_FR, c.address_FR, c.contact_name dari order_line o, produk p, pelanggan c Dimana o.product_id =p.id dan o.customer_id =c .id Dan id =;

Kontra

• Tidak ada skalabilitas:setiap kali bahasa baru ditambahkan, lusinan kolom tambahan perlu ditambahkan di seluruh tabel.
• Ini bisa memakan waktu, terutama jika banyak bidang harus memiliki banyak bahasa.

• Pengembang akhirnya menulis kueri yang ditunjukkan di bawah ini untuk mengelola semua bahasa yang ada. Jadi, semua SQL di aplikasi Anda harus berubah saat bahasa baru diperkenalkan. (Catatan: @in_language menandakan bahasa aplikasi saat ini; parameter ini berasal dari ujung depan aplikasi, sedangkan ujung belakang mengambil catatan.)

  PILIH KASUS @in_language KETIKA 'FR' MAKA p.product_name_FR KETIKA 'DE' MAKA p.product_name_DE DEFAULT MAKA p.product_name_EN, p.price, CASE @in_language KETIKA 'FR' MAKA c.name_FR KETIKA 'DE' LALU c .name_DE DEFAULT KEMUDIAN c.name_EN, c.contact_nameFROM order_line o, product p, customer c WHERE o.product_id =p.id AND o.customer_id =c.id AND id =;

Pendekatan 2 – Membuat Tabel Terpisah untuk Teks yang Diterjemahkan

Dalam pendekatan ini, tabel terpisah digunakan untuk menyimpan teks terjemahan; pada contoh di bawah ini, kami menamakan tabel ini translation . Ini berisi satu kolom untuk setiap bahasa. Nilai yang telah diterjemahkan dari nilai bidang ke semua bahasa yang berlaku disimpan sebagai rekaman. Alih-alih menyimpan teks terjemahan yang sebenarnya di tabel yang mendasarinya, kami menyimpan referensinya ke translation meja. Implementasi ini memungkinkan kita untuk membuat repositori umum teks yang diterjemahkan tanpa membuat terlalu banyak perubahan pada model data yang ada.

Pro

• Ini adalah pendekatan yang baik jika pelokalan akan diterapkan pada model data yang ada.
• Satu kolom tambahan dalam translation tabel adalah satu-satunya perubahan yang diperlukan saat bahasa baru diperkenalkan.
• Bila teks asli sama di seluruh tabel, tidak ada teks terjemahan yang berlebihan. Misalnya:misalkan nama pelanggan dan nama produk identik. Dalam hal ini, hanya satu catatan yang akan dimasukkan ke dalam tabel terjemahan, dan catatan yang sama dirujuk di kedua customer dan product tabel.

Kontra

• Masih memerlukan perubahan model data.
• Mungkin ada NULL yang tidak perlu dalam tabel. Jika 1.000 bidang diperlukan hanya untuk satu bahasa yang didukung, Anda akhirnya membuat 1.000 catatan – dan banyak NULL.

• Kompleksitas penulisan SQL meningkat seiring bertambahnya jumlah gabungan. Dan ketika ada banyak catatan dalam translation tabel, waktu pengambilan lebih lambat.

  Mari kita menulis SQL untuk pernyataan masalah manajemen bahasa lagi:

  PILIH KASUS @in_language WHEN 'FR' THEN tp.text_FR WHEN 'DE' THEN tp.text_DE DEFAULT THEN p.product_name_EN, p.price, CASE @in_language WHEN 'FR' THEN tc.text_FR WHEN 'DE' THEN tc .text_DE DEFAULT KEMUDIAN c.name_EN, c.contact_nameFROM order_line o, product p, customer c, translation tp, translation tc WHERE o.product_id =p.id AND o.customer_id =c.id AND p.name_translation_id =tp.id AND c.name_translation_id =tc.id AND id =;

Varian pada Pendekatan Tabel Terjemahan

Untuk mendapatkan performa yang lebih baik saat teks terjemahan diambil, kita dapat membagi translation tabel menjadi beberapa tabel. Kita dapat mengelompokkan record berdasarkan domain, yaitu satu tabel untuk customer , satu lagi untuk product , dll.

Pendekatan 3 – Tabel Terjemahan dengan Baris untuk Setiap Bahasa

Implementasi ini sangat mirip dengan pendekatan kedua, tetapi menyimpan nilai untuk teks yang diterjemahkan dalam baris daripada kolom. Di sini, translation id tabel tetap sama untuk nilai bidang dalam bahasa terjemahan apa pun. Kunci utama gabungan {id , language_id } disimpan di tabel terjemahan, dan menyimpan translation_id . yang sama untuk setiap bidang terhadap beberapa language_id .

Pro

• Implementasi ini memungkinkan pengembang untuk menulis SQL pengambilan data dengan cukup mudah.
• Menulis OEM untuk model ini juga mudah.
• Tidak diperlukan perubahan model data saat Anda menambahkan bahasa baru; cukup masukkan catatan untuk bahasa baru.
• Tidak ada konsumsi memori yang tidak perlu saat sekumpulan bidang tidak berlaku untuk suatu bahasa.

• Kompleksitas pengambilan data SQL berkurang. Perhatikan contoh di bawah ini:

  SELECT tp.text, p.price, tc.text, c.contact_nameFROM order_line o, product p, customer c, translation tp, translation tc, language l WHERE o.product_id =p.id AND o.customer_id =c .id DAN p.name_translation_id =tp.id AND c.name_translation_id =tc.id AND tp.language_id =l.id AND tc.language_id =l.id AND l.name =@in_language AND id =; 
   

Kontra

• Jumlah gabungan yang relatif tinggi diperlukan untuk mengambil data yang diterjemahkan.
• Pada waktunya, sejumlah besar catatan berpotensi disimpan dalam translation meja. Karena hanya ada satu tabel terjemahan, semua teks terjemahan akan dibuang ke dalamnya. Bila Anda memiliki jutaan bidang untuk diterjemahkan dan aplikasi Anda mendukung banyak bahasa, maka kueri satu tabel untuk terjemahan akan menjadi aktivitas yang memakan waktu. Namun, Anda dapat membagi tabel terjemahan berdasarkan bahasa atau bidang subjek, seperti yang kami tunjukkan pada kesimpulan pendekatan kedua.

Bagaimana Jika Kita Menggabungkan Pendekatan 2 dan 3?

Secara khusus, kami akan menggabungkan varian Pendekatan 2 – memisahkan translation tabel – dengan ide menggunakan baris dalam tabel. Kami dapat dengan mudah mengatasi kelemahan memiliki catatan besar dalam translation tabel dengan membuat beberapa tabel berdasarkan domain, seperti yang kami lakukan di varian Pendekatan 2. Jika ada cukup banyak catatan dalam tabel terjemahan berbasis domain, kita dapat membagi tabel lebih lanjut berdasarkan bidang individu.

Pendekatan #4 – Membuat Lapisan Entitas untuk Bidang yang Diterjemahkan dan Bidang yang Tidak Diterjemahkan

Dalam solusi ini, tabel entitas yang berisi satu atau lebih bidang yang diterjemahkan dibagi menjadi dua lapisan:satu untuk bidang yang diterjemahkan, dan satu lagi untuk bidang yang tidak diterjemahkan. Dengan cara ini, kami membuat lapisan terpisah untuk masing-masing.

Pro

• Tidak perlu bergabung dengan tabel terjemahan jika hanya bidang yang tidak diterjemahkan yang bersangkutan. Oleh karena itu, bidang yang tidak diterjemahkan mendapatkan kinerja yang lebih baik.
• Jumlah gabungan yang relatif lebih sedikit diperlukan untuk mengambil teks terjemahan.
• Menulis OEM itu mudah.
• SQL untuk mengambil teks terjemahan itu sederhana.
• Ini adalah pendekatan yang terbukti untuk menggabungkan beberapa bahasa di seluruh entitas.

Untuk menunjukkan maksudnya, berikut adalah contoh kueri yang akan mengambil teks terjemahan:

SELECT pt.product_name, pt.description, p.priceFROM order_line o, product p, product_translation pt, language l WHERE o.product_id =p.id AND AND p.id =pt.product_non_trans_id AND pt.language_id =l. id DAN l.name =@in_language AND id =;

Lokalisasi – Melampaui Terjemahan Konten

Pelokalan tidak hanya menerjemahkan konten aplikasi Anda ke bahasa lain. Ada parameter budaya dan fungsional yang perlu diperhatikan juga. Misalnya, nilai tanggal diformat sebagai 'MM/DD/YYYY' di Amerika Utara, tetapi di sebagian besar Asia ditulis sebagai 'DD/MM/YYYY'.

Contoh lain berkaitan dengan menampilkan nama pada header aplikasi. Di AS, memanggil seseorang dengan nama depannya dapat diterima atau bahkan disukai; dalam budaya ini, nama depan pelanggan ditampilkan di header segera setelah pelanggan masuk. Namun, di Jepang, keadaannya terbalik:memanggil seseorang dengan nama depannya tidak sopan atau bahkan menghina. Lokalisasi akan mempertimbangkan hal ini dan menghindari penggunaan nama depan untuk audiens Jepang aplikasi.

Parameter pelokalan mungkin perlu disimpan di bagian belakang aplikasi. Ini sangat sering terjadi ketika Anda harus merancang beberapa logika program seputar pelokalan. Kita mungkin dapat mengkategorikan semua parameter tersebut ke dalam kategori budaya dan fungsional, dan membangun model data di sekitarnya.

Satu Lagi Pemikiran Tentang Pelokalan

Lokalisasi diperlukan ketika merek global menembus pasar lokal. Untuk melokalisasi aplikasi, lihat gambaran besarnya. Lokalisasi lebih dari sekadar kinerja yang sempurna secara teknis. Ini juga berarti memiliki penguasaan budaya lokal, perilaku, bahkan cara berpikir dan hidup.

Apa lagi yang bisa dilakukan untuk membuat aplikasi dapat beradaptasi secara lokal? Beri tahu kami pendapat Anda di komentar.