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

Question

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

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

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

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

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

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

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

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

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

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

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, третий вариант заключается в том, как они справляются с этим, с помощью нескольких настроек. Они держат все это в одной таблице и поле, называемое языком. Тогда есть отдельная таблица, которая отображает, какие элементы связаны.

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