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

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

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

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

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

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

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

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

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

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

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

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

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

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