Skenario
Anda adalah pemilik toko online yang berlokasi di Polandia. Mayoritas pelanggan Anda berasal dari Polandia dan mereka berbicara bahasa Polandia. Tetapi Anda juga ingin menjual produk Anda ke luar negeri dan pelanggan internasional Anda kebanyakan berbahasa Inggris. Jadi, Anda ingin toko online Anda tersedia dalam bahasa Polandia dan Bahasa Inggris . Anda juga berharap produk Anda akan laku di Prancis, jadi Anda mengantisipasi bahwa Anda harus menyiapkan bahasa Prancis versi toko juga (dan mungkin Spanyol juga, karena mengapa tidak?).
Anda ingin pengguna Anda dapat beralih dari versi Polandia
ke versi bahasa Inggris dan sebaliknya.
Dan tentunya Anda ingin detail produk beralih dari bahasa Polandia ke bahasa Inggris.
Bagaimana Cara Membuat Aplikasi Web Multi-Bahasa?
Ada dua jenis teks dalam aplikasi Anda. Salah satunya adalah statis data:label tombol, header tabel, grafik (yang sering berisi teks). Yang lainnya adalah ditentukan pengguna data, seperti nama produk, harga produk, deskripsi produk dan sebagainya. Data biasanya diambil dari database.
Data statis adalah apa yang ingin Anda tulis sebagai string literal dalam output Anda. Data yang ditentukan pengguna adalah data yang Anda ambil dari database Anda.
Saya tidak akan berbicara tentang data statis hari ini. Kerangka kerja web apa pun yang masuk akal akan menangani internasionalisasi data statis. Lihat dokumentasi kerangka aplikasi web Anda untuk detailnya. Cari kata kunci seperti “internasionalisasi”, “i18n”, “lokalisasi”, atau “terjemahan”.
Hari ini saya akan berbicara tentang struktur database apa yang biasanya kita gunakan di sini di e-point untuk menangani data multi-bahasa. Dalam database untuk toko Anda, Anda mungkin memiliki product tabel yang menyimpan info tentang semua produk yang tersedia di toko.
product tabel memiliki kolom seperti name , description , dan price . Saat Anda menerjemahkan info produk ke bahasa lain, Anda hanya perlu menerjemahkan beberapa kolom. Di sini Anda hanya akan menerjemahkan name dan description , tapi price tidak berubah saat Anda berganti bahasa.
Saat kami menambahkan dukungan untuk beberapa bahasa, kami menambahkan tabel baru bernama language_version , yang menyimpan semua versi bahasa yang tersedia di toko. Kami biasanya menambahkan kolom yang disebut code dan satu bernama is_default (dengan batasan yang sesuai:hanya satu versi yang dapat menjadi default).
Selanjutnya, kami membagi product tabel menjadi dua tabel:tabel product dan tabel product_lv . Untuk setiap produk, akan ada satu baris di product tabel dan beberapa baris di product_lv meja; satu baris untuk setiap versi bahasa. Tabel product_lv hanya berisi kolom yang harus diterjemahkan:name dan description . Kolom yang tidak bergantung pada bahasa (seperti price , karena Anda menjual dengan harga yang sama tidak peduli apakah pelanggan Anda berbicara bahasa Inggris atau Polandia) tetap di tabel product .
Kami melakukan hal yang sama untuk setiap tabel yang berisi data yang diterjemahkan. Data yang diterjemahkan masuk ke table_lv tabel, data bahasa-independen tetap berada di tabel utama.
Pro dan Kontra
Kerugian yang jelas adalah bahwa semua operasi buat, ambil, perbarui, atau hapus (CRUD) menjadi sedikit lebih rumit. Anda harus selalu bergabung dengan tabel versi bahasa tambahan untuk mendapatkan deskripsi yang tepat.
Keuntungan dari desain ini adalah Anda tidak perlu mengubah skema database saat menambahkan versi bahasa baru. Saya tidak mengatakan bahwa menambahkan versi bahasa baru itu mudah. Lagi pula, Anda harus menerjemahkan SEMUA deskripsi produk. Ini adalah tantangan organisasi, tetapi dari sudut pandang basis data, ini cukup mudah:banyak sisipan.
Bagaimana Anda mendesain database multibahasa Anda?
