Александр Воробьев

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

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

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

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

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

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

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

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

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

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

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

- не загружается лишнее - ведь посетитель открывает на одном хите сайт только на одном языке

- переводчик трогает только один языковой файл и нет причин проверять, а не сделал ли он чего либо не то в другом языке (что то типа из мира СОЛИД :)  - файл отвечает за, например, китайский, а русский - это зона ответственности другого файла)

Прошу прощения, не обратил внимания сразу на вопрос.

Сразу оговорюсь я про PHP.  Самое "простое" пишем массив в файл

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

Точнее,  если возвратиться к модульности, то

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

Далее простой include и этот файл(ы) сразу интерпретируется.

В случае json (или любого другого  формата) уже выполняется больше шагов:

1. Читаем файл
2.  json_decode
3. интерпретация

Кстати, несколько в сторону, но о том же.  В Qt (C++, питон, etc...)  тоже на файлах

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

Не совсем понял. Какая разница скинуть  и json и массив в файл нет же сложностей - т.е. организовать редактирование из админки вообще не проблема.  

Хм. Почему это? Мне кажется тут вообще солид как то с натяжкой к этому вопросу подходит.

У меня есть проект где ежегодно в один прекрасный день могут заходит   140тысяч активных пользователей (и это даже "лайтовый" вариант) в остальное время это сайт с которым справится даже "минимальный тариф любого хостинга". Так вот я как бы посмотрев на то как ведут себя сервера, решил эти интерфейсные тексты выкинуть в файлы. (правда они были в основной бД).  База становится узким горлышком.  А эти языковые фразы - которые безболезненно можно оттуда убрать.    Текст, который, по сути, статика. Меняется, но достаточно редко.   Добавлять еще базу -  а какой смысл? Все равно заметно большая  часть закеширована. Удобство редактирования - это интерфейс, стоит ли его вот так любому "контент менеджеру" править по 100 раз на дню?  Да и скорость доступа на серверных файловых системах  сейчас вполне себе.  (тем более не забываем, что один фиг в бд если грубои  на холодную - это все те же файлы :)

А зачем json? Почему не обычный массив?

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

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

Я не пробовал. Но. А стоит ли оно того. Это необходимо если каждая страница каждый раз генерируется на каждом хите. В остальном кеширование (страницы полностью или блоками) или SSG. Т.е. получится ли в итоге значимый профит от скорости БД.