Untuk menerapkan dukungan multi-bahasa dalam model data Anda, Anda tidak perlu menemukan kembali kemudi. Artikel ini akan menunjukkan kepada Anda berbagai cara untuk melakukannya dan membantu Anda memilih salah satu yang paling sesuai untuk Anda.
Konsep lokalisasi sangat penting untuk pengembangan aplikasi perangkat lunak, terutama ketika cakupan aplikasi tersebut bersifat global. Dukungan untuk berbagai bahasa adalah aspek utama yang perlu dipertimbangkan; desain database yang mendukung aplikasi multi-bahasa memungkinkan Anda untuk mendiversifikasi target pasar Anda dan dengan demikian menjangkau lebih banyak pelanggan. Selain itu, desain basis data seperti itu dapat menjadi bagian dari strategi jangka panjang Anda untuk merancang sistem yang siap-lokalisasi.
Kunci untuk memasukkan dukungan multi-bahasa ke dalam aplikasi Anda adalah melakukannya dengan cara yang tidak secara drastis meningkatkan biaya pengembangan atau pemeliharaan. Karena pemodelan basis data merupakan bagian tak terpisahkan dari proses pengembangan perangkat lunak, Anda perlu memikirkan strategi desain model data terbaik untuk memberikan dukungan multibahasa pada aplikasi Anda.
Model data yang tepat harus memungkinkan Anda untuk memodifikasi aplikasi atau menambahkan fungsionalitas baru sambil mempertahankan dukungan multi-bahasa – tanpa menambahkan usaha atau biaya ekstra. Itu juga harus memungkinkan Anda untuk memasukkan bahasa baru tanpa menyentuh aplikasi; Anda hanya perlu menambahkan data terjemahan yang sesuai ke database.
Implementasi Sederhana vs. Fleksibilitas dan Fungsionalitas
Ada pendekatan yang berbeda untuk membuat desain database untuk aplikasi multi-bahasa. Masing masing punya kelebihan dan kekurangan. Yang lebih mudah diimplementasikan menawarkan lebih sedikit fleksibilitas dan fungsionalitas yang lebih sedikit; yang menawarkan lebih banyak fleksibilitas dan fungsionalitas memiliki implementasi yang lebih kompleks.
Saran saya di sini adalah untuk selalu pilih yang menawarkan fungsionalitas dan fleksibilitas lebih banyak , bahkan jika mereka lebih mahal untuk diterapkan. Terkadang kita membuat kesalahan dengan berpikir bahwa sebuah aplikasi terlalu kecil, bahwa tidak ada gunanya menerapkan skema kompleks untuk menyelesaikan hal-hal seperti dukungan multi-bahasa. Namun pada akhirnya, aplikasi tersebut akan berkembang dan kami akan menyesal memilih pendekatan "cepat dan kotor" yang tampak lebih sederhana dan lebih murah.
Ideal untuk mengimplementasikan fungsionalitas aksesori ke aplikasi – baik itu dukungan multi-bahasa, perubahan logging, otentikasi pengguna, atau yang lainnya – adalah agar fungsionalitas tersebut memiliki subskemanya sendiri dan logikanya dienkapsulasi dalam komponen yang dapat digunakan kembali. Dengan cara ini, baik fungsi aksesori dan subskemanya dapat digabungkan ke dalam aplikasi baru apa pun dengan sedikit usaha.
Desain database yang cerdas dan alat pemodelan data seperti Vertabelo sangat membantu untuk pengelolaan skema dan subskema Anda yang efisien. Juga, lihat tips ini untuk desain database yang lebih baik dan pastikan Anda mengikuti semuanya. Sebelum Anda mulai menggambar diagram ER Anda, saya sarankan Anda mempertimbangkan rangkaian tips pemodelan basis data yang penting ini.
Beberapa Solusi Desain Database Multi-Bahasa yang Menarik (Tapi Tidak Disarankan)
Termudah – Tapi Paling Tidak Direkomendasikan
Mari kita mulai dengan cara yang paling tidak direkomendasikan tetapi termudah untuk mengimplementasikan database aplikasi multi-bahasa. Ini memungkinkan Anda dengan cepat menyelesaikan kebutuhan untuk mendukung aplikasi multi-bahasa, tetapi itu akan membawa Anda masalah ketika aplikasi tumbuh dalam fungsionalitas atau dalam cakupan geografis.
Strategi sederhana ini terdiri dari menambahkan kolom tambahan untuk setiap kolom teks yang membutuhkan terjemahan dan untuk setiap bahasa yang teksnya harus diterjemahkan.
Misalnya, di Movies tabel di bawah ini, ada OriginalTitle bidang. Kolom judul tambahan ditambahkan untuk setiap bahasa yang akan diterjemahkan:
| MovieId | Judul Asli | Title_sp | Title_it | Judul_fr |
|---|---|---|---|---|
| 1 | Mati Keras | Duro de matar | Trappola di cristallo | Piege de cristal |
| 2 | Kembali ke Masa Depan | Volver al futuro | Ritorno al futuro | Retour vers le futur |
| 3 | Taman Jurassic | Parque jurásico | Giurassico parco | Parc jurassique |
Aplikasi harus mendapatkan data deskripsi dari kolom yang sesuai dengan bahasa yang dipilih oleh pengguna. Saat Anda perlu menambahkan bahasa baru, Anda harus menambahkan kolom tambahan ke tabel untuk memuat teks yang diterjemahkan ke bahasa baru. Anda juga harus menyesuaikan aplikasi untuk mengakui bahasa dan kolom yang ditambahkan.
Solusi ini tidak memerlukan JOIN yang rumit untuk mendapatkan teks yang diterjemahkan, juga tidak memerlukan rekaman duplikat – hanya replikasi kolom konten teks. Namun penerapannya terbatas pada situasi di mana hanya beberapa tabel yang perlu diterjemahkan.
Misalnya, Anda memiliki Products tabel dan Processes meja. Masing-masing memiliki bidang Deskripsi yang perlu diterjemahkan; sepertinya cukup mudah bukan? Tetapi jika seluruh aplikasi (termasuk semua opsi menu, pesan kesalahan, dll.) perlu multi-bahasa, solusi ini tidak dapat diterapkan.
Lebih Serbaguna, Tapi Juga Tidak Disarankan
Melanjutkan gagasan untuk menyimpan terjemahan dalam tabel yang sama, alternatif dari opsi sebelumnya adalah memperbesar bidang teks. Ini akan memungkinkan kita untuk menyimpan semua terjemahan di bidang yang sama, mengaturnya dalam struktur data (misalnya dokumen XML atau objek JSON). Di bawah ini kami memiliki contoh:
Id Film
Judul Asli
Terjemahan
1
Mati Keras
[
{"language":"sp", "title":"Duro de matar"},
{"language":"it", "title":"Trappola di cristallo"},
{"language":"fr", "title":"Piège de cristal"}
]
2
Kembali ke Masa Depan
[
{"language":"sp", "title":"Volver al futuro"},
{"language":"it", "title":"Ritorno al futuro"},
{"language":"fr", "title":"Retour vers le futur"}
]
3
Taman Jurassic
[
{"language":"sp", "title":"Parque jurásico"},
{"language":"it", "title":"Giurassico parco"},
{"language":"fr", "title":"Parc jurassique"}
]
Opsi ini tidak memerlukan kolom tambahan, tetapi menambah kerumitan. Kueri data sekarang harus dapat memproses dan menafsirkan struktur data yang digunakan untuk dukungan multibahasa dengan benar. Misalnya, jika JSON atau XML digunakan untuk menyimpan terjemahan, kueri SQL harus menggunakan versi SQL yang mendukung tipe data yang dipilih.
Perintah SQL berikut menggunakan MS SQL Server OPENJSON() berfungsi untuk menggunakan konten Translations bidang sebagai tabel subordinasi:
SELECT m.MovieId, m.OriginalTitle, t.TranslatedTitle FROM Movies AS m CROSS APPLY OPENJSON(m.Translations) WITH ( language char(2) '$.language', TranslatedTitle varchar(100) '$.title’ ) AS t WHERE t.language = 'fr';
Karena tidak ada fungsi atau operator untuk memanipulasi data berformat JSON atau XML dalam SQL standar, Anda terpaksa menulis kueri untuk RDBMS tertentu jika Anda ingin menggunakan teknik ini untuk menyimpan teks terjemahan. Misalnya, kueri sebelumnya tidak didukung oleh MySQL. Jika Anda perlu membaca data JSON di Movies tabel dengan MySQL, Anda akan menulis kueri ini:
SELECT m.MovieId, m.OriginalTitle, JSON_EXTRACT(m.Translations, '$.title') AS TranslatedTitle FROM Movies AS m WHERE JSON_EXTRACT(m.Translations. '$.language') = 'fr';
Menyimpan Teks yang Diterjemahkan dalam Rekaman Berbeda
Anda juga dapat memilih untuk menggunakan catatan yang berbeda untuk setiap bahasa. Namun, Anda harus mengundurkan diri dari kehilangan normalisasi:data yang sama diulang dalam beberapa catatan, di mana hanya terjemahannya yang bervariasi.
| MovieId | BahasaId | Judul |
|---|---|---|
| 1 | id | Mati Keras |
| 1 | sp | Duro de matar |
| 1 | itu | Trappola di cristallo |
| 1 | fr | Piege de cristal |
| 2 | id | Kembali ke Masa Depan |
| 2 | sp | Volver al futuro |
| 2 | itu | Ritorno al futuro |
Dengan opsi ini, Anda dapat membuat tampilan setiap tabel yang hanya menampilkan baris dalam bahasa tertentu:
CREATE VIEW Movies_en AS SELECT MovieId, Title FROM Movies WHERE LanguageId = 'en'; CREATE VIEW Movies_sp as SELECT MovieId, Title FROM Movies WHERE LanguageId = 'sp';
Kemudian, untuk mengkueri tabel, Anda bisa menggunakan tampilan yang berbeda sesuai dengan bahasa terjemahan target. Tetapi normalisasi model hilang dan pemeliharaan tabel menjadi tidak perlu rumit.
Menyimpan Teks yang Diterjemahkan dalam Tabel Terpisah
Salah satu cara untuk menyimpan teks yang diterjemahkan tanpa merusak model relasional adalah dengan memiliki tabel detail untuk setiap tabel yang berisi teks yang akan diterjemahkan. Tabel bawahan yang berisi terjemahan harus memiliki bidang kunci yang sama dengan tabel induk, ditambah bidang yang menunjukkan bahasa terjemahan.
Tabel bawahan dengan terjemahan harus memiliki bidang kunci yang sama dengan tabel induk, ditambah bidang yang menunjukkan bahasa terjemahan.
Opsi ini memungkinkan penggabungan bahasa baru tanpa mengubah struktur tabel. Itu tidak memerlukan menghasilkan informasi yang berlebihan atau melanggar normalisasi model.
Kelemahan untuk opsi ini adalah membutuhkan pembuatan tabel bawahan untuk setiap tabel yang menyimpan data tekstual yang memerlukan terjemahan. Namun, ide menyimpan terjemahan dalam tabel terkait membawa kita lebih dekat ke cara yang paling disarankan untuk merancang database multi-bahasa.
Solusi Universal:Subskema Terjemahan
Agar aplikasi dan basis datanya benar-benar multibahasa, semua teks harus memiliki terjemahan dalam setiap bahasa yang didukung – bukan hanya data teks dalam tabel tertentu. Hal ini dicapai dengan subskema terjemahan di mana semua data dengan konten tekstual yang dapat menjangkau mata pengguna disimpan.
Dalam aplikasi web yang dimaksudkan untuk digunakan dalam berbagai bahasa, subskema terjemahan adalah kebutuhan, bukan pilihan. Hal lain akan menyebabkan kerumitan yang membuat pemeliharaan aplikasi menjadi tidak mungkin.
Kunci menjaga terjemahan dalam skema terpisah adalah memelihara katalog terindeks dengan semua teks yang membutuhkan terjemahan, baik itu deskripsi entitas, pesan kesalahan, atau opsi menu. Idenya adalah bahwa tidak ada teks yang dapat menjangkau mata pengguna yang disimpan di tabel mana pun di luar subskema ini.
Salah satu cara untuk mengatur katalog terjemahan adalah dengan menggunakan tiga tabel:
- Tabel bahasa utama.
- Tabel teks dalam bahasa aslinya.
- Tabel teks terjemahan.
Skema untuk katalog terjemahan universal.
Di tabel master bahasa, kami cukup memasukkan catatan untuk setiap bahasa yang didukung oleh model data. Masing-masing memiliki kode ID dan nama:
| LanguageId | NamaBahasa |
|---|---|
| id | Bahasa Inggris |
| sp | Spanyol |
| itu | Italia |
| fr | Prancis |
Tabel teks mencatat semua teks yang memerlukan terjemahan. Setiap record memiliki ID arbitrer, teks asli, dan ID bahasa aslinya.
Dalam TextContent tabel, teks asli dan ID bahasa asli tidak sepenuhnya diperlukan. Tetapi mereka menyederhanakan kueri yang tidak memerlukan terjemahan. Misalnya, saat melakukan analisis statistik atau kueri kontrol manajemen (yang biasanya hanya tersedia bagi pengguna yang memahami bahasa aslinya), kueri tersebut dapat disederhanakan dengan menggunakan teks default (tidak diterjemahkan).
Teks asli juga berguna bagi mereka yang harus mengisi tabel teks terjemahan. Entri data terjemahan dapat dilakukan melalui aplikasi mini yang menunjukkan teks asli dan terjemahan dalam semua bahasa yang tersedia. Dimungkinkan juga untuk menghasilkan informasi untuk subskema terjemahan melalui proses otomatis menggunakan API terjemahan.
Menghubungkan dengan Skema Utama
Dalam skema utama aplikasi, kolom dengan nilai teks yang perlu diterjemahkan diganti dengan ID yang mengarah ke tabel teks terjemahan:
Skema utama ditautkan ke skema terjemahan melalui tabel dengan teks yang perlu diterjemahkan.
Anda dapat meninggalkan bidang teks asli di beberapa tabel skema utama untuk memfasilitasi kueri di mana terjemahan tidak diperlukan, meskipun ini menghasilkan informasi yang berlebihan. Misalnya, kami mungkin menyimpan ProductDescription bidang di Products tabel untuk memfasilitasi kueri statistik atau untuk mengisi dimensi gudang data, mengesampingkan subskema terjemahan jika tidak diperlukan.
- Desain Basis Data Multi-Bahasa:Lakukan Sekali dan Lakukan dengan Benar
Kami telah melihat beberapa alternatif untuk membuat desain database multi-bahasa. Beberapa lebih mudah dan lebih cepat untuk diterapkan. Solusi terakhir sedikit lebih kompleks, tetapi memberi Anda lebih banyak fleksibilitas. Ini juga akan menyelamatkan Anda dari masalah ketika tiba saatnya untuk memelihara aplikasi dan database. Dengan demikian, dalam jangka panjang, biayanya akan jauh lebih murah.
Terkadang, jalur terpendek dalam desain database menggoda Anda untuk percaya bahwa Anda akan menghemat waktu dan tenaga. Tetapi ketika Anda memilihnya, Anda mengabaikan fakta bahwa Anda mungkin harus turun beberapa kali. Jika Anda mengabaikan praktik terbaik untuk desain database multibahasa, Anda mungkin akan melakukan pekerjaan yang sama berulang kali.
