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

Ну тут конечно на правах ИМХО (по моему скромному мнению).  Это скорее по ощущениям, особенно если json храниться в одну строку. (а стандартная phpшная функция упаковки массива/объекта в json именно в одну строку формирует.)  можно сказать "Основное"  для меня это нет необходимости декодировать и кодировать. т.к. код в конечном итоге все равно с массивом будет работать.

Синтаксис можно проверить повесив валидацию на git хук (в прочем json тоже так же можно обработать). 

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

Опять же, даже если мы забьем на gitхуки и валидацию - есть же обработка ошибок. Перехватили - и дальше поступаем согласно бизнес логики проекта.

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

Ну тут не совсем так. Ведь в условном текстовом редакторе json править без ошибок сложнее :)  Естественно этот массив не хранится в файле где есть логика. Просто это читать как разновидность "формата хранения текстов" :) Ну, а если прикручивать интерфейс для тех, кто по своим обязанностям имеет право править эти тексты - тут вообще становится пофиг как оно хранится

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

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

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

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

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

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

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

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

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

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

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

У меня были проекты где и побольше было, да даже вот как раз на моем  проекте (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...)  тоже на файлах