Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Заказчик хочет магазин с небольшим оборотом товаров + блог. Админка будет на одном, дефолтном языке, но весь контент (название/описание товаров, статьи блога, ну кроме комментов, наверное) должен быть на 3-х языках.
Допустим, маршруты по контенту имеют вид */{lang?}, а контроллер использует переменную $lang, чтобы делать подходящую выборку из базы.
Как лучше - дублировать поля в таблицах (content_ru, content_en ит.п) для каждой модели или же иметь отдельные таблицы и может даже отдельные модели для каждого языка (posts_ru, posts_en)? Чутье подсказывает, что первый вариант явно лучше, но может вообще есть какое-то решение по-умнее, ведь в первом варианте все равно попахивает дублированием кода.
Шаблоны представления: всякие фразы для кнопок типа "Купить" хранить в отдельном классе и
прописывать типа {{ Words::buy($lang) }} Есть еще рациональные варианты?
Да, и это важно, добавление языков на сайт не планируется.
PS. Знаю, про мультиязычность часто спрашивают, но я хочу об этом поговорить тоже :-)
Не в сети
- Как лучше — дублировать поля в таблицах (content_ru, content_en ит.п) для каждой модели или же иметь отдельные таблицы и может даже отдельные модели для каждого языка (posts_ru, posts_en)?
Рисковая идея заводить поля, так как есть вероятность, что кроме 3-х уже известных языков потом нужно будет прикрутить ещё один, а то и несколько. Да и вообще языки по определению — изменчивая характеристика, поэтому я бы завёл отдельную таблицу только со строками, вида:
- lang - язык - text - локализованный текст - table - исходная таблица - field - поле в этой таблице - id - объект, к которому относится text
Структура может быть другой в зависимости от структуры проекта/БД. Если сделать иднекс PRIMARY KEY на lang, table, field, id (композитный), то по идее скорость при работе должна быть нормальной. Единственный недостаток — при выборке надо будет делать JOIN’ы на все поля со строками, но зато не нужно будет перестраивать схему БД при добавлении нового языка.
Но это что касается именно переводимых пользовательских строк (названий товаров, статей и пр.). Что касается интерфейса — это всё есть смысл хранить в стандартном для Laravel виде (.php) и получать через Lang.
- Да, и это важно, добавление языков на сайт не планируется.
Если бы все уверения заказчика сохраняли свою силу в течении жизни проекта, то мы бы жили в идеальном мире
Не в сети
Спасибо за вариант.
Я размышлял, читал, и тут вдруг наткнулся на чудесный туториал.
Все-таки дополнительные поля в таблице с префиксами языка - field_en, field_fr итп
Затем добавляем методы в Модель:
public function getTitleAttribute()
{
$locale = App::getLocale();
$column = "title_" . $locale;
return $this->{$column};
}
public function getContentAttribute()
{
$locale = App::getLocale();
$column = "content_" . $locale;
return $this->{$column};
}
Тогда в шаблоне можно пользоваться переменными вот так:
<h1>
{{ $post->title }}
</h1>
<p>
{{ $post->content }}
</p>
Ну а для фраз, к-рые касаются только представлений (и не хранятся в БД) есть методы trans() или Lang::get(..)
Если добавится язык - то придется добавить поля в таблицы, да, но это не так страшно, как дублирование кода и излишняя проверочная логика. Как тебе такое решение?
PS вот туториал https://medium.com/laravel-4/laravel-4- … cdc75e4810
Не в сети