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

Question

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

Ситуация Я проектирую реляционную базу данных MySQL, которая позже должна содержатьмногоязычный контент.Вы знаете это из Википедии или страниц технической поддержки Microsoft.Содержание должно быть одинаковым для каждого языка.Например, если переводы отсутствуют, сайт предлагает вам тот же контент, который автоматически переводится или на языки, на которых эта информация доступна. Если некоторые значения не заданы, он должен использовать второй язык браузера или язык по умолчанию или перевести его, например, через Google.Средой разработки является Zend.

Мои идеи пока что предназначены для решения проблемы:

Два основных ключа: (ID, язык) Преимущество: легкий доступ к базе данных через абстракцию базы данныхслои.Проблема: внешние ключи, корабли отношений, запасные варианты

Столбцы с суффиксом языка: Преимущество: производительность БД, нет проблем с отношениями.Проблема: Слои абстракции базы данных не могут справиться с этим?

Подтверждена ли какая-либо концепция или она предпочтительнее другой?Кто-нибудь уже создал что-то подобное и может поделиться со мной своим опытом?Существует ли измененный контроллер Zend DB для этой ситуации?Как вы связываете эту информацию с формой?

Спасибо за вашу помощь, советы и предложения!

С уважением,

Мануэль

Answer 1

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

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

Много работы, но проблема не слишком проста.

Answer 2

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

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

@ tawfekov - это что-то вроде этого или подобное, легко реализуемое с доктриной?

Answer 3

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

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