Сценарият
Вие сте собственик на онлайн магазин, намиращ се в Полша. По-голямата част от вашите клиенти са от Полша и говорят полски. Но вие искате да продавате продуктите си и в чужбина и вашите международни клиенти говорят основно английски. Така че искате вашият онлайн магазин да е наличен и на полски и английски . Очаквате също, че вашите продукти ще се продават добре във Франция, така че предвиждате, че ще трябва да подготвите френски версия на магазина също (и може би испански също, защото защо не?).
Искате вашите потребители да могат да преминават от полската версия
до английската версия и обратно.
И очевидно искате подробностите за продукта да преминат от полски към английски.
Как се прави многоезично уеб приложение?
Във вашето приложение има два типа текст. Единият е статичен данни:етикети на бутони, заглавки на таблици, графики (които често съдържат текст). Другият е дефиниран от потребителя данни, като име на продукт, цена на продукта, описание на продукта и т.н. Данните обикновено се вземат от базата данни.
Статичните данни са това, което бихте искали да запишете като низов литерал във вашия изход. Дефинираните от потребителя данни са данни, които взимате от вашата база данни.
Днес няма да говоря за статични данни. Всяка разумна уеб рамка ще се справи с интернационализацията на статичните данни. Консултирайте се с документацията на рамката на вашето уеб приложение за подробности. Потърсете ключови думи като „интернационализация“, „i18n“, „локализация“ или „преводи“.
Днес ще говоря за структурата на базата данни, която обикновено използваме тук в e-point, за да обработваме многоезични данни. В базата данни за вашия магазин вероятно имате product таблица, която съхранява информация за всички продукти, налични в магазина.
product таблицата има колони като name , description и price . Когато превеждате информацията за продукта на други езици, трябва да преведете само някои колони. Тук ще преведете само name и description , но price не се променя, когато превключите езиците.
Когато добавяме поддръжка за множество езици, добавяме нова таблица, наречена language_version , който съхранява всички езикови версии, налични в магазина. Обикновено добавяме колона, наречена code и един, наречен is_default (с подходящо ограничение:само една версия може да бъде по подразбиране).
След това разделяме product таблица на две таблици:таблица product и таблица product_lv . За всеки продукт ще има един ред в product таблица и няколко реда в product_lv маса; един ред за всяка езикова версия. Таблицата product_lv съдържа само колони, които трябва да бъдат преведени:name и description . Колоните, които са независими от езика (като price , защото продавате на една и съща цена, независимо дали клиентът ви говори английски или полски) останете в таблицата product .
Правим същото за всяка таблица, която съдържа преведени данни. Преведените данни отиват в table_lv таблица, независимите от езика данни остават в основната таблица.
Плюсове и минуси
Очевиден недостатък е, че всички операции за създаване, извличане, актуализиране или изтриване (CRUD) стават малко по-сложни. Винаги трябва да се присъедините с допълнителна таблица с езикови версии, за да получите правилното описание.
Предимството на този дизайн е, че не е нужно да променяте схемата на базата данни, когато добавяте нова езикова версия. Не казвам, че добавянето на нова езикова версия е лесно. В крайна сметка трябва да преведете ВСИЧКИ описания на продукти. Това е организационно предизвикателство, но от гледна точка на базата данни е доста лесно:много вложки.
Как проектирате своите многоезични бази данни?
