Как смоделировать многоязычную базу данных с Zend, l18n mysql?

Второй вариант будет не ремонтопригоден (это следует добавить к минусам). Чтобы действительно добавить еще один язык, вам потребуется изменить уровни абстракции таблицы и. Звучит как кошмар.

Первый вариант кажется гораздо более перспективным, но, к сожалению, многое еще предстоит сделать, чтобы заставить его работать. Однако, по моему опыту, это довольно типичное решение, поэтому я бы не стал изобретать велосипед.
Что я должен добавить, так это то, что откат языка должен выполняться на стороне Zend, в базе данных будет пропущена какая-то информация. Вы можете придумать какую-то индексную таблицу для хранения такой информации, как уникальный идентификатор содержимого и доступные языки. Если вам нужно что-то обслуживать, вы должны прочитать такую ​​запись, сравнить ее с Accept Languages ​​​​и снова запросить базу данных для действительного содержимого (используя наиболее подходящий язык). Единственная проблема заключается в том, что вам нужно будет каким-то образом создать такую ​​индексную таблицу (лучшим способом, который я вижу, будет триггер при вставке содержимого в вашу таблицу содержимого).

Работы много, но задача не из легких.

Я сейчас работаю над точно такой же проблемой.

Как-то мне не имеет смысла складывать все в одну базу. Допустим, я хочу пойти на крайние меры и поддерживать около 50 языков, это просто раздует мою БД. Итак, я склонен сохранять свою основную БД на своем основном языке, а затем вводить в нее некоторую концепцию Zend_Translate. Zend_Translate должен предоставить вам запасное решение, которое вы ищете. Хотя основная навигация и основной дизайн не являются большой проблемой для моего веб-сайта, сейчас меня больше всего беспокоит то, как хранить весь основной контент и как его переводить, потому что эти элементы, среди прочего, содержат HTML. Для основного контента я, вероятно, буду использовать альтернативный подход и использовать отдельную БД с таблицами для каждого языка.

Моя платформа будет базой данных, управляемой сообществом. Так что я на самом деле буду полагаться на людей, переводящих это. Вы все равно должны хранить информацию, поэтому меня в первую очередь беспокоит не размер базы данных или производительность, а удобство использования. Пока моя идея состоит в том, чтобы реализовать некоторую структуру, как описано выше, еще не уверен, сделаю ли я это в доктрине или нет.

Языковое решение: запуск, приложение получает заданный пользователем язык, дополнительный язык, родной английский язык статьи. Извлекая статью из базы данных, я проверю для каждого столбца следующее: 1. Доступен ли основной язык? 2. Доступен ли дополнительный язык? 3. Если ни один из них, отобразите статью на родном или английском языке и предложите пользователю перевести ее с предложениями из API Google Translate. Я предполагаю, что для этого потребуется немного покрыть и манипулировать контроллерами или построить бизнес-модель.

@tawfekov что-то подобное или подобное легко реализовать с помощью доктрины?