Как реализовать мультиязычную поддержку ERM - PullRequest
1 голос
/ 06 ноября 2011

Я хотел бы знать, верен ли мой подход для веб-сайта, который предлагает свой контент, управляемый CMS, на разных языках.

Сама страница: Люди могут забронировать маршруты с путеводителем. Очень просто. Теперь компании необходимо добавить маршруты в базу данных на разных языках.

Я подумал, что он в основном создает маршрут и затем может добавлять описания на разных языках. Таким образом, я бы в основном сохранил содержание и название маршрута в отдельной таблице с идентификатором маршрута и кодом языка.

Что ты думаешь?

Вот изображение моей ERM в MySQL Workbench.

http://imageshack.us/f/194/witchrouteerm.png/

Кто-нибудь имел подобные проекты и думает, что этот подход приведет к проблеме или вы думаете, что это правильный путь? Я не могу думать о другом. Поскольку я не хочу давать маршруту дополнительный столбец, такой как "lang_code". Как и мне, чем нужно было бы создать сам маршрут несколько раз. Это, очевидно, возможно, но сложнее в управлении и требует больше времени для установки дат и так далее.

Я с нетерпением жду получения здесь комментариев от людей, которые должны были принять аналогичные решения о поддержке мультиязычности.

Всего наилучшего, Ричард

1 Ответ

0 голосов
/ 12 декабря 2011

Разделение описания для конкретного языка будет типичным. «Языковой стандарт» описаний данных должен совпадать с «языковым стандартом» пользователя. В вашей ERD у вас есть два столбца (страна и язык) в пользовательской таблице, но только один столбец (lang_code) в таблице содержимого. Вы хотели бы сделать их последовательными. Перейти на две колонки, язык и страну, и следуйте стандарту. Весь текст должен быть разделен (неужели «заголовок» в «сложности» также должен быть привязан к локали?)

Стандарт будет зависеть от того, как вы определяете локаль пользователя (заголовок http Accept-Language? User input?). Локалем может быть двухсимвольный код языка (ISO 639) и двухсимвольный код страны (ISO 3166). Итак, en_US, en_GB, en_CA, fr_CA, ...

Возможно, вы захотите ввести в действие бизнес-правило, согласно которому описание американского английского языка должно всегда существовать для маршрута. Тогда у вас может быть иерархия предпочтительных языков для пользователя. Например, если предпочтение пользователя определено как португальская Бразилия (pt_BR), но у вас нет описания маршрута для этого, вы можете вместо этого попробовать португальскую Португалию (pt_PT), а если этого не существует, вернуться к английскому US ( en_US). Сохраняя язык и страну в виде двух отдельных столбцов и вводя другое поле для пометки описания по умолчанию для языковой группы (т. Е. Помечая pt_PT в качестве языка pt по умолчанию, если другие варианты не найдены), вы можете немного упростить эти виды операций. выполнять.

...