Неужели я который ничего не умеет и не знает, тебя мега гуру учить должен.
Не надо учить и выяснять кто гуру. Мы обсуждаем технические вопросы. Я тебя не звал, но раз ты пришел, давай говорить конструктивно. Приведи пример, как бы ты это организовывал через БД. Как организовать таблицу для хранения даннах, как будет выглядеть sql-запрос, словие я привел - пять слов в меню, которые нужно переводить на 5 языков. Как потом будет обрабатываться на фронте.
1 запрос, 1 таблица
ЗЫ. Делай как знаешь, если не знаешь как по нормальному делается.
Можешьипривести пример таблиц? Допустим в меню 5 пунктов и нужно 5 вариантов языков. Как хранить, как вызывать?
Что ты делал-то? Есть примеры? И в данном случае я спрашивал про опыт графовой БД а не как собрать шаблон.
Скорее это вариант 1. При этом будет оперативка загружаться и если будет много запросов одновременно, то сервак будет не справляться. Даже если на странице только одну фразу надо перевести в операционную всё равно целый файл всех слов будет грузится и для каждого запроса..
А вариант 2 ещё хуже первого.. так как все переводы в одном файле если я правильно понял.
ЗЫ. Так что вариант 3 самый лучший.
Я тебя вообще не понимаю, ты пишешь:
Не вдаваясь в терминологию твою - так работает любой шаблонизатор. Я же привел вариант хранения данных выше. Это результат ответа из базы данных. Которые шаблонизатор, как ты говоришь по меткам, хотя это контекстные переменные матчит по шаблону страницы. Сколько в твоем варианте нужно запросов в реляционную базу? В каких таблицах это будет храниться? И сколько запросов будет в моем варианте?
Именно так у меня реализовано на многих сайтах
Не понимаю, зачем городить огород с кучей шаблонов, когда достаточно одного.Вот еще счас смотрю в графовую базу данных типа AWS Neptune. Она сверхбыстрая и не только под шаблоны подойтет. Кто-нибудь пробовал?
Arbnet, ты же там хотел соцсеть свою создать, значит должен был с такой знаком - как оно - стоит выделки?
Ты бы прочитал сначала внимательно. Это не вариант3 а вариант 2 у меня. И я уже выразил консерн свой - это лишний запрос в базу данных. Поэтому и планирую использовать Монгу.
Да все просто для шаблонов.
1 шаблон, к которому подключается нужный файл в зависмости от нужного языка include ('../lang/ru.php'); include ('../lang/en.php'); а нужные слова в самом шаблоне в виде переменных $L['glavnaj'] и .т.д.
зачем мне разные шаблоны? достаточно одного с разным контекстом.
<a class="nav-link {%if not context.username %}disabled {%endif%}" href="/subjects"><i class="bi bi-list-columns-reverse"></i> {{context.menu.mentor}}</a>
По вопросу домен или подкаталог не скажу - это вопрос не технический.
По реализации, чаще делают на файлах - это касается текстов интерфейса. (битрикс, symfony, yii, django) Контент по прежнему в базе остается. Так же это решается, на сколько я помню (но сам не пользовался локализацией), в фронтендовых UI фреймворках.
Больше тут "сложность", точнее какой вопрос надо решать где хранить перевод контента - в той же таблице отдельная колонка, или отдельная колонка.
Про динамическую подгрузку контента не понятно. Если на серваке собирается страница полностью с контентом - так и надо собирать далее, если собиралась в браузере - так и остается.
На этом этапе меня интересует только интерфейс.
В зависимости от выбранного языка должен меняться. КАк я говорил есть два варианта - или просто хранить 1-2-3-4 шаблона с разными языками или подгружать в переменные шаблонизатора в зависимости от выбранного языка. Второй правильный но тут надо как-то избежать лишних запросов в базу. Понятно что кэширование будет. Пока идея - спользовать DynamoDb/Mongo. Вроде как самое то. Запросы очень быстрые, все храниться в json-ах:
{ "ru": { "mentor": "Преподаватель", ... } "by": { "mentor": "Настаунik" }}
Нужен трафик
сайт/ру/
сайт/англ/
сайт/укр/
не нужен трафик - как угодно
Да, принято, спасибо, об этом не думал.
-deleted, moved separate topic?
Кстати, не поделишься ссылкой на свой топ ресурс? У меня есть вопросы по Ngnix, может ты уже знаешь. Можно в приват, обещаю не разглашать публично и не критиковать, если ты против.
