Реализация мультиязычности на сайте

Хороший вопрос, попробую обяснить свое решение. Речь идет  о реализации перевода интерфейса, не всего сайта. Это главное меню, названия подразделов.. Примерно 50-100 слов на один язык. то есть файл будет в пределах одного килобайта. В моем случае мне не нужно будет предусматривать загрузку разных файлов. я обращаюсь к одному файлу кажлый раз, из него по ключу достаю нужный мне язык и только его отправляю на фронт. Если мне нужен будет интерфейс для переводчика - я точно также дам ему уже отфильтрованный  обьект и запишу его только в измененную часть. Он не сможет  ничего лишнего изменить. Солид это про ООП больше. В моем случае тут L - Liskov substitution не нарушается -  я пишу интерфейс и ожидаю одинаковое поведение как родителя так и  наследника.  Single responsibility не нарушается. Но в принципе это вопрос удобства - можно и так и так.  

Можно Машку и козу на возу 😁

Что интерфейс, что не интерфейс, закинул ключи и переводы по разным языкам в базу, надо на странице какие-то слова и фразы с переводом, сделал запрос в базу и вставил в страницу.

Но нет, лучше же всё запихнуть в файл, потом каждый раз его читать и выбирать нужные и тд. забивать оперативку.. так проще конечно же..

ЗЫ. Оказывается мегагуры до сих пор не умеют с БД работать.. 🤡

Это само собой

Тут с оговорками: как минимум заметная часть меню это уже "динамический контент"

Я скорее про кнопки, технические сообщения, и т.п.

У меня были проекты где и побольше было, да даже вот как раз на моем  проекте (SaaS, САПР), я его планирую переводить на несколько языков (есть пользователи иностранные), так вот, например, там же сообщения об ошибках с краткой инструкцией о дальнейших действиях, надписи на выкройках (считай на чертежах), ну т.е. достаточно текстовой статической информации. Да и на других проектах тоже бывает накапливается. Так то вроде кажется не заметно, но как делаешь мультиязычный и, к тому же к которому нет "из коробки" языковых файлов - сразу ощущаешь :)

Тут я сторонник отдельного, что по сути даже интерфейс особо не нужен, грубо говоря могу отдать файл переводчику, и он  в любом текстовом редакторе поправит :)..  Но, главное, я считаю это независимость языковых файлов. Т.е. как раз в этом плане я и делал отсылку к СОЛИД.(понятно что там в первую очередь про ООП, но если вдуматься в эти принципы они вполне себе применимы и полезны не только  в ООП). В данном случае у нас есть задача изменить, к примеру, итальянский перевод - мы и правим тот файл, который несет за эту ответственность. И тут же накладывается и что не просто файл конкретного языка, но и конкретного модуля (или иной "единицы") - не трогая прочие.

Соответственно все файлы под git. можем принимать правки и пуллреквестами и патчами. Да, кончено, и для json все это работает, но в ситуации с простым массивом diff более читабелен.

Ну, я тут конечно не агитирую :)  но все же я для себя склоняюсь именно к массивам в разных файлах.  Собственно я даже к модным для конфигов yaml  так же более скептически отношусь (уточню, что я скорее про PHP, для других ЯП в каждом случае может быть и иное решение).

Поясните с какого перепуга текст взятый из БД занимает меньше оперативки чем взятый из файла?  Только технически  поясните. БД, чтоб работать быстро, и запросы кешируют, а бывает и вообще таблицы, а т.к. интерфейс нужен всегда, то это будет считаться важная таблица - возможно она вся будет в оперативке, далее для каждого запроса  свой кеш, далее результат запроса попадает в ваш фреймворк и точно так же занимает оперативку.  При этом, в моем варианте с отдельными фалами, точно так же будут только нужные фразы с очень небольшим овером.  Исходя из того, что  вашем фреймворке из коробки нет кеширования, в оперативке таблица и результаты ваших запросов будут висеть "постоянно".

База данных это здорово и круто,  беда (ваша) только в том, что это вс однозначно для сайтов где маленькая посещаемость. Понятно, что вам трудно это представить пока ни один сайт не довели до посещаемости, но вы всегда можете нагрузить сайт свой практически любой нагрузкой при помощи Yandex Load Testing   (если денег нет на аренду серверов на время теста, можно конечно локально развернуть яндекс Танк, но не получится нагрузить прям совсем нормально. но лучше чем ни чего. Я вам уже, на другом форуме, приводил пример, когда простенький запрос к по сути статической таблице из 6 записей (без каких либо  фильтров, сортировок и т..п), про который забыли и забили, думая что это "фигня" по сути поставил на колени сервер БД. При чем процессора там было выше крыше - он не напрягался, оперативки было - еще хоть 10таких баз загрузи. А база стояла колом  - поизучайте как реально работает СУБД - реально много нового узнаете.  А всего то на сайт зашли пользователей за несколько десятков тысяч. Можно конечно решить это на железном уровне: например несколько серверов БД в кластер, балансировка нагрузки - главное чтоб финансово  это было оправдано

Т.е. просто надо еще оценивать ситуацию: если ваш сайт рассчитан на малую посещаемость, он мало кому нужен, вы даже потенциально не планируете делать сайт популярным - по сути без разницы. (хотя решение сделать более гибко по сути ни чего не стоит)...  Но если у вас большие планы или вы делаете фреймворк, который по задумке должен взорвать и захватить интернет - уверяю это задачей придется заниматься. 

Поясняю.

1. Сначала загружается файл в оперативку

2. Затем этот файл обрабатывается и создаются переменные, которым присваиваются значения, нужны не нужны на странице не важно, ваш подход будет каждый раз загружать память этими данными

Итого: допустим файл килобайт + чуть меньше на запоминание переменных * на количество запросов = ~ гиг оперативки.. это я грубо, но суть не меняется. К тому же ещё лишние телодвижения чтения и обработки файла это дополнительное время ожидания пользователем и др. накладные..

Теперь если как я работать с БД. Собираются ключи какие нужны на странице для перевода слов\фраз, делается запрос, память не загружается файлами и переменными т.е теми данными которые не нужны на странице, только самые нужные данные приходят из БД. Затем эти данные вставляются в страницу. Вот и всё. Неужели это до вас никак не дойдёт?

Я вам тоже и там пытался объяснить.. всё бестолку..

Вот этим вы и убиваете сервак.. По нормальному не делается кэш для каждого запроса, делается только для часто запрашиваемых страниц\данных.

Попробуйте все это на практике. У меня есть сайты которые спокойно живут на хостингах с 2 гигами оперативки. (при этом активно используется кеширование для подготовленных данных)  Далее, что значит обрабатывается.? Вы выше мой код видели? Какие там переменные создаются - идет сразу работа с переменными. К тому же в нормальной ситуации работает opcache - который кеширует опкоды. В случае подключения массива это простой статичный и даже без ветвления php код.  Идем далее современные фреймворки это много файлов. Даже ваш, который еще совсем не оброс функционалом (даже для простейшего из типичных ныне сайтов) уже достаточно много файлов. И там несколько дополнительных файлов - капля в море.  Кстати, я не вдавался в подробности ка креализовано у вас, но вы божились, что css у вас только нужный подключается на каждой странице в заисимости от ситуации и даже для этого есть у вас специальные опции... Чтож вы  css то не втащили в базу? Собственно и xml храните в базе - у вас вообще тогда по вашей теории сайты реактивными станут. :)

Естественно. Ваши мысли не подтверждают ни практика, ни то как работают те или иные сервисы (в т.ч. СУБД).

Изучите уже как работает СУБД. Вы даже не поняли о чем я написал.  Уточню, этот кеш, о котором я сказал, регламентируется и управляется СУБД. Из кода я на него не влияю.  Далее интерфейсные языковые фразы это то, что требуется всегда,  т.е. это "часто  запрашиваемые данные". Т.е. даже по вашим словам они будут  в памяти. 

Кстати, вот выше в пояснении нашему суперразарбу вспомнился еще один  аргумент в пользу файлов содержащих простые массивы. Аргумент правда касается PHP, в питоне не смотрел как устроено в этом плане.  В итоге у меня получается обычный PHP код, который, как я полагаю (глубоко я в механизм работы OpCahce не погружался) так же как и прочий постоянно используемый код один раз парсится и уже хранится в памяти в виде опкодов.

Так как вы делаете я делал в самом начале создания своих движков для сайтов. Но потом отказался, и не помню уже на каком форуме, очень давно ~2005г., но мне просто сказали зачем хранить и загружать переводы для слов\фраз из файлов, когда есть БД. Я тогда подумал и сделал всё через БД и с тех пор всегда так делаю. А у вас мышление начинающего кто просто не умеет работать с БД, всё же делается элементарно если вы умеете работать с БД.

Такие переменные

<?php
$dict = [
'someKey1' => 'someValue1',
'someKey2' => 'someValue2',
];

<?php
$dict['someKey1'] = 'someValue1';
$dict['someKey2'] = 'someValue2';

Сразу идёт работа с переменными 😆 по вашему они где находятся? PHP сначала резервирует в куче оперативки память под переменную, потом вставляет в эту память её значение и так с каждой...

И только потом после обработки кода уже использует эти переменные беря из памяти их значение. Вы вообще не понимаете как работает компьютер оказывается..

Эта тема не о моём фреймворке. Да и вы несёте полнейшую чушь, смешивая в одну кучу, файлы стилей которые по сути статичны и не требуют модификаций с генерацией страницы в которой, в зависимости от параметров запроса нужно генерировать содержание. И xml, который у меня выполняет роль не только как шаблонизатор, но и как программный код фактически. Я уже вам триллион раз всё объяснял, как об стену горох..

Это вам не мешало бы изучить и не заниматься тем чем вы занимаетесь.., файлами для мультиязычности.. 🤡

Еще раз повторю: попробуйте все на практике. Не на сайте с посещаемостью "ты, да я, да мы с тобой". А на сайте на котором есть посетители. И который имеет контент.  

Ну т.е. из БД вы минуете эту стадию и тексты волшебным образом попадают в html минуя стадию создания переменной?  Сколько преобразований получается по пути из текста записанного в файле базы данных, до html? посчитайте на холодную, да и на горячую. А далее сравнивайте.

Просто внимательно посмотрите трезво на фреймворк свой, вы там тоже пользуетесь файлами, более того суете в xml то, что потом приходится "если грубо" преобразовывать в PHP - и при этом считаете его мего быстрым и не жрущим ресурсы, а тут простой инклуд, по вашему убивает память..... смешно. где логика то?

Если бы я не пребывал, то сейчас не утверждал, что работа с БД в данном случае для мультиязычности будет намного эффективнее работы с файлами.

Да у меня при получении данных из БД тоже создаются переменные, но только те что необходимы, а я ссылаюсь на ту область оперативки, которая у вас тратится в холостую при работе с файлом, невзирая нужны будут переменные или нет они всё равно будут созданы, тем самым занимая память + сам файл(который тоже будет занимать часть оперативки) + накладные при обработке этого всего..

Ничего в xml не сую, есть некоторые функции просто для удобства и они не затратные, преобразования сведены к минимуму, всё делается на лету. И да из-за простого инклуда может быть утечка памяти, если вот так бездумно делать как вы.. 

ЗЫ. Я сделал иначе, я посмотрел как реализовано в существующих решениях, понял что мне это не подходит и поэтому сделал свой инструмент, много раз объяснял вам зачем и почему, но "тупому объяснять, только время терять.."

Можете озвучить характеристики и условия стенда?  "намного" это сколько?