Самое простое в такой ситуации, по-моему, просто дублировать поля, которые надо переводить, что-то вроде:
id: integer, required
title_ru: string, required
body_ru: text, required
title_en: string
body_en: text
и изменять в зависимости от урла имена полей для выборки. Схема простая, легко реализуется, практически нет накладных расходов, но главный недостаток — очень негибкая
Как правило, в английской версии должны быть англоязычные страницы, тексты, новости и т.п. В Русской — конечно же русский. Devman правильно посоветовал, в обычный перечень полей в бд (как если бы это был одноязычный по архитектуре сайт) добавьте поле, отвечающее за язык. А дальше все просто, в админке делаете переключатель-фильтр — который будет показывать записи либо с одним значением поля, либо с другим. Во фронтенде тоже просто используем этот фильтр. Достаточно гибко, языков может быть хоть сколько, по сути можно из даже динамически добавлять из админки) Главное — база пухнуть избыточными полями не будет.
Вот давеча как раз такой модуль и реализовал методом дописывания в существующие таблицы полей для локализации:
name_locale
content_locale и т.д.
В карточке редактирования данных в админке добавилась закладка «Язык», куда вынеслись поля для редактирования данных локализации. Локализацию добавил в страницы, новости, тестовые блоки. Так же вынес в настройки подключения отдельного шаблона дизайна для второго языка, который включается при смене языка.
Лучшая модель для перевода данных представлена, например, в плагине globalize для AR. github.com/svenfuchs/globalize3 — если интересно.
Вариант с отдельной таблицей для всех переводов — это перевод строк, например. Но придётся заморачиваться с кешированием, поскольку это дело будет делать ну очень много запросов.
My<cod/>.net
