Scenariusz
Jesteś właścicielem sklepu internetowego zlokalizowanego w Polsce. Większość Twoich klientów pochodzi z Polski i mówi po polsku. Ale Ty też chcesz sprzedawać swoje produkty za granicą, a Twoi międzynarodowi klienci mówią głównie po angielsku. Więc chcesz, aby Twój sklep internetowy był dostępny zarówno w języku polskim i angielski . Spodziewasz się również, że Twoje produkty będą dobrze sprzedawać się we Francji, więc przewidujesz, że będziesz musiał przygotować francuski wersja sklepu również (i może hiszpańska też, bo czemu nie?).
Chcesz, aby Twoi użytkownicy mogli przełączyć się z polskiej wersji
do wersji angielskiej iz powrotem.
I oczywiście chcesz, aby szczegóły produktu zmieniły się z polskiego na angielski.
Jak stworzyć wielojęzyczną aplikację internetową?
W Twojej aplikacji istnieją dwa rodzaje tekstu. Jeden jest statyczny dane:etykiety przycisków, nagłówki tabel, grafika (które często zawierają tekst). Drugi to zdefiniowany przez użytkownika dane, takie jak nazwa produktu, cena produktu, opis produktu i tak dalej. Dane są zwykle pobierane z bazy danych.
Dane statyczne są tym, co chciałbyś zapisać jako literał ciągu w swoim wyjściu. Dane zdefiniowane przez użytkownika to dane, które pobierasz z bazy danych.
Nie będę dziś mówić o danych statycznych. Każdy rozsądny framework sieciowy poradzi sobie z internacjonalizacją danych statycznych. Aby uzyskać szczegółowe informacje, zapoznaj się z dokumentacją struktury aplikacji sieci Web. Szukaj słów kluczowych, takich jak „internacjonalizacja”, „i18n”, „lokalizacja” lub „tłumaczenia”.
Dzisiaj opowiem o tym, jakiej struktury bazy danych używamy tutaj w e-point do obsługi danych wielojęzycznych. W bazie danych Twojego sklepu prawdopodobnie masz product tabela, w której przechowywane są informacje o wszystkich produktach dostępnych w sklepie.
product tabela zawiera kolumny takie jak name , description i price . Kiedy tłumaczysz informacje o produkcie na inne języki, musisz przetłumaczyć tylko niektóre kolumny. Tutaj przetłumaczyłbyś tylko name i description , ale price nie zmienia się po zmianie języka.
Kiedy dodajemy obsługę wielu języków, dodajemy nową tabelę o nazwie language_version , który przechowuje wszystkie dostępne w sklepie wersje językowe. Zwykle dodajemy kolumnę o nazwie code i jeden o nazwie is_default (z odpowiednim ograniczeniem:tylko jedna wersja może być domyślna).
Następnie dzielimy product tabela na dwie tabele:tabela product i tabela product_lv . Dla każdego produktu będzie jeden wiersz w product tabela i wiele wierszy w product_lv stół; jeden wiersz dla każdej wersji językowej. Tabela product_lv zawiera tylko kolumny, które należy przetłumaczyć:name i description . Kolumny niezależne od języka (np. price , ponieważ sprzedajesz za tę samą cenę bez względu na to, czy Twój klient mówi po angielsku czy po polsku) pozostań w tabeli product .
To samo robimy dla każdej tabeli zawierającej przetłumaczone dane. Przetłumaczone dane trafiają do table_lv tabeli, dane niezależne od języka pozostają w głównej tabeli.
Wady i zalety
Oczywistą wadą jest to, że wszystkie operacje tworzenia, pobierania, aktualizowania lub usuwania (CRUD) stają się nieco bardziej skomplikowane. Zawsze musisz dołączyć z dodatkową tabelą wersji językowych, aby uzyskać właściwy opis.
Zaletą tego projektu jest brak konieczności zmiany schematu bazy danych po dodaniu nowej wersji językowej. Nie mówię, że dodanie nowej wersji językowej jest łatwe. W końcu musisz przetłumaczyć WSZYSTKIE opisy produktów. Jest to wyzwanie organizacyjne, ale z punktu widzenia bazy danych jest to dość łatwe:mnóstwo wstawek.
Jak projektujesz swoje wielojęzyczne bazy danych?
