Лучший способ перевести контент, управляемый базой данных

Question

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

В основном у меня есть CMS, которая использует систему шаблонов для анализа всех данных из базы данных на экран. Я зашел так далеко, чтобы «разделить» мои шаблоны в разных папках, чтобы иметь возможность переводить вещи, которые являются «статичными», как изображения с текстом, нижними колонтитулами и т. Д.

Однако существует много модулей (страниц, новости, продукты), которые имеют несколько полей, которые требуют перевода метода, основанного на базе данных. Я начал с таблицы «Языки», которая описывает языки (id, iso_code, name). Это до тех пор, пока я пришел. Поскольку было несколько проектов, которые нужно было сделать, я пока не уделяю больше времени этому вопросу.

Моя первая мысль («быстрое исправление») заключалась в том, чтобы добавить несколько полей внутри таблиц (например, «title_nl», «title_en»), но это фактически делает базу данных более переполненной, чем нужно, на мой взгляд.

Моей второй мыслью было создать таблицу «news_translations», например. В котором содержится код языка iso, news_id, поля, которые требуют перевода. Очевидно, что news_id связывает перевод с его оригиналом, а язык iso-код используется для получения правильного языка из базы данных. Затем в моем интерфейсном коде я бы сначала проверил, выбран ли язык по умолчанию (=> выберите из таблицы «новости») или таблицу трансляции (=> check in translations). Если второй случай не возвращает никаких результатов, отображается сообщение «Извините, недоступен перевод» и отображается по умолчанию (или сообщение об ошибке, наиболее подходящее для клиента).

Но тогда есть третий вариант. На моих веб-сайтах используются поисковые системы (www.domain.com/pagename/ или www.domain.com/news/1-news-item-here.html). Было бы намного лучше, если бы у меня была возможность также «переопределить» URL SEF в моей таблице переводов. Но я предполагаю, что в этом случае мне всегда понадобится 1 дополнительный запрос к таблице переводов (так как мы сначала хотим проверить переведенную страницу) ... думаю, это не так уж и важно, но стоит подумать, я думаю.

В конце концов, я думаю, опираясь на мои варианты, номер 3 - это то, что мне нужно. Но я хотел бы получить и другие мнения по этому вопросу! Это то, что я пытаюсь достичь:

• Создание системы CMS с поддержкой нескольких языков
• Нет языковых файлов (очевидно, именно поэтому я использую шаблоны)
• Будучи в состоянии перевести оригинальную страницу/статьи новостей/продукт
• Необязательно: для изменения URL SEF в соответствии с языком

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

1. Создать таблицу _translation для каждого элемента (или, возможно, даже в оригинала путем добавления 2 новых месторождения «translation_to» (содержащий PrimaryKey) и «translation_is» (содержащий код ISO) - однако .. в в этом случае все поля должны быть отредактированы (что не всегда необходимо .. плюс, создав вторую таблицу, я сохраняю оригиналы , деленные на их переводы, не так ли?)

2. Если выбран язык по умолчанию НЕ выбраны, сначала запросите таблицу переводов, чтобы найти перевод, если он найден, отобразите перевод . В противном случае уведомите/сообщите пользователю и/или покажите исходный текст (на основе URL SEF ... если SEF не найден в переводах или исходной таблице, то, очевидно, отображается ошибка ).

Любые предложения? :-)

Спасибо за размышление!

Answer 1

Я хотел бы посмотреть, как выглядит ваша структура таблицы. Вероятно, самое лучшее, что вы можете сделать, это создать две отдельные новые таблицы с именем «CONTENT_MULTI_LANG« & «SITE_LOCALES».

Затем в коде, который выводит ваш контент, выполняется первоначальная проверка флажка языка. Я бы создал два отдельных класса для загрузки статического контента, например «Content_LoadStandard» и «Content_LoadMultiLang». Итак, ваше условное будет выглядеть так.

if ($this->site_locale == 'standard'){ 
    $contentLoader = new Content_LoadStandard(); 
} else { 
    $contentLoader = new Content_LoadMultiLang($this->site_locale); 
} 

$content->blah($cheese); 

Вашей «CONTENT_MULTI_LANG» таблица должна быть сужена версией вашей стандартной таблицы CMS объекта, содержащая только соответствующее содержимое поля (ы), которые должны быть в альтернативных языках.

// PSEUDO SQL 
    CREATE TABLE `LOCALE` (
     `id` int(11), 
     `locale` varchar(16), // name of locale (language) 
     ...    // any other fields 
) 

    CREATE TABLE `CONTENT_MULTI_LANG` (
     `id` int(11), 
     `pcid` int(11), // parent content id 
     `lid` medint(), // locale id 
     `content` {$type}, // whatever type you use (varchar, text, bin, etc) 
     ...    // any other fields 
) 

В вашем Content_LoadMultiLang класса, создать методы для запроса альтернативного контента с помощью объединения.

СОВЕТ. Может быть хорошей идеей установить отношения в вашей таблице, чтобы делать каскадные удаления в строках контента, таким образом, если вы удалите контент в стандарте, ваши многоязычные версии также будут удалены.

Answer 2

Из того, что я видел из Drupal, третий вариант заключается в том, как они справляются с этим, с помощью нескольких настроек. Они хранят все это в одном столе и поле называется языком. Затем есть отдельная таблица, которая сопоставляет, какие элементы связаны.

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