Какие есть средства локализации на уровне MySQL?

Question

[Александр Стрелов]

Возможно я не знаком с таким велосипедом, но есть БД на MySQL, есть приложение на PHP, есть задача сделать прозрачную работу с данными с учетом текущего языка пользователя, т.е. организовать поддержку мультиязычности сайта, причем число языков должно расширяться без перепахивания БД. На уровне PHP все ясно, это gettext() и файлы локализации, а как быть с базой? Возможно уже есть какие-то готовые решения, которых я не смог нагуглить? Буду признателен за указатель.

Answer 1

[Shedal]

Как вариант, можно создать таблицу translations (text, culture, translation).

Определить функцию translate(text, culture), которая будет возвращать или перевод, если он есть, или изначальную строку, если перевода нет.
Использовать её можно будет с любой таблицей:

SELECT Id, translate(Value), translate(Value2) ...

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

Comments

[Shedal]

Конечно же, translate(Value, 'en-GB'). Забыл добавить второй параметр.

Answer 2

[Vampiro]

А еще можно сделать отдельные таблицы, и тогда производительность не будет зависеть от количества языков в системе.

Answer 3

[Jurik]

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

Answer 4

[rPman]

Если не перелопачивать базу данных, простенько, для галочки… то вместо текста в поле храните сериализованный массив {ru:'Бла, бла, бла',en:'Blah, Blah, Blah',..}…

Но в общем случае это не решит проблем, которых на самом деле гораздо больше появляется при переходе от одноязычного сайта к мультиязычному. Они все специфичные, вида что делать с данными, смысл которых 'перевод'… нужна ли новая сущность на них со ссылкой на оригинал или достаточно связи 1к1 и т.п.

Comments

[rPman]

Не дописал… вместо сериализации конечно можно почти автоматически скриптиком перелопатить базу, заменив все текстовые поля на следующие:
table{id,descr} -> table{id,en_descr,ru_descr,fr_descr,..}

Понятно что представление должно уметь работать с этими данными, подставляя текущий язык в имя параметра и проверяя, есть ли там значения (если нет, выдавать язык по умолчанию… или другое какое условие)

[Shedal]

Хранить JSON в базе данных — ужасное решение. Для любого изменения данных прийдётся их вытягивать в приложение, изменять и записывать обратно.
К тому же, такой подход очень плохо расширяем — в том плане, что при добавлении нового языка нужно будет изменять данные во всех строках многих таблиц.

[rPman]

Эээ… для речь ведь шла про не перелопачивание всей БД?!!! А после я привел похожее решение, но уже без сериализации.

json кстати для случая введения нового языка идеален… нет элемента в массиве — нет перевода, появится перевод, обновят поле. Все равно 'представление' обязано проверять, есть ли у поля соответствующее языковое значение например так isset('en').

[Shedal]

>> json кстати для случая введения нового языка идеален… нет элемента в массиве — нет перевода
Этим свойством обладает, фактически, любой подход. Это не плюс использования JSON'а.
JSON в базе данных это ужасный code smell. Зачем таким способом денормализовывать данные, если их можно хранить нормализованно?

[rPman]

Охохо… это философский вопрос, мешать ли разные подходы к хранению данных sql/nosql или нет.
Маниакальное следование какой то одной парадигме в любом случае до добра не доводит. Не забываем, инструменты призваны помогать решать наши проблемы, а не создавать новые.

Ваяю сейчас небольшой проект… в одном основном бизнеспроцессе встречается сложный блок данных (который кстати будет активно апгрейдиться в будущем, это важно), который мог бы быть реализован в реляционной базе минимум десятью таблицами и сложными транзакциями, работа с блоком многопользовательская (но пользователей на блок мало, считанные единицы). Мне реально проще (во всех смыслах) вместо серии таблиц сериализовать эти данные в одном поле (не забывая про параметр 'версия', на будущее), а доступ к нему на чтение сделать блокируемым! Кода меньше на порядок, вероятность ошибки падает на порядок, данные несвязные, даже если будет ошибка, она будет локализована на конкретном поле а не всей таблице (ну это маловероятные ошибки, при обновлении можно пропустить дополнительное поле фильтрации, хотя я обычно стараюсь обновления делать только по PK)

[rPman]

p.s. кстати, я был готов реализовать работу с блоком через процедуры внутри самой БД, чтобы она же и следила за целостностью, но есть еще ряд требований, которые повысят сложность их реализации именно в БД

[Shedal]

Я не исключаю, что есть задачи, для которых оптимальнее хранить в таблицах сериализованные объекты. Но я не считаю, что в случае с локализацией это уместно.

«JSON в базе данных это ужасный code smell» — code smell не всегда говорит о том, что что-то не так. Но в своей практике я ни разу не встречал JSON/XML в базе, которые бы со временем не начинали создавать проблем. Да, изначально с такой структурой проще работать. Да, кода писать меньше. Но сам факт того, чтобы вы не сможете работать с данными при помощи базы данных, уже накладывает слишком много ограничений. Ни вам foreign keys, ни выборочных быстрых апдейтов по индексам… в подавляющем большинстве случаев лучше написать немного больше кода изначально, чтобы не страдать впоследствии, при поддержке системы.
И я считаю, что локализация — как раз хороший пример, когда данные нужно хранить нормализованно. Тем более, что это совсем не сложно.

Answer 5

[Xenkok]

deleted

Answer 6

[Станислав]

Хм, я конечно дико извиняюсь, но какая суть в локализации на стороне dbms? Разве этим не «отображение» должно заниматься?

Comments

[Max B]

Видимо автор говорит не про интерфейс, а про текстовые аттрибуты. Например описание товара или текст новости.

Answer 7

[strib]

dictionary_id|string_id|lang|value — тоже неплохо работает.

Answer 8

[Валентин]

Доброї ночі! Як на мене можливий такий варіант:
1)робите копію таблиці ( включаючи дані) певної таблиці додаючи префікс який буде вказувати на мову.. Наприклад products_ua.
2)в sql запитах де є вибірка з даної таблиці додаєм префікс до назви таблиці.. ('SELECT * FROM products_'. $_SESSION[`lang`]. ' WHERE product_id=1' )
3)відомо що колонки не текстового типу не потрібно переводити а вони можуть бути присутні в таблиці і щоб все вірно працювали потрібно прикріпити трігери які будуть визивається при update і вставці полів в таблицю оригінал... Подальший опис механізму можу обговорити з вами в skype: webstd.studio