Если не ошибаюсь, в примере было в одном json все языки, тут в одном файле только один язык. Это удобнее , на мой взгляд, т.к.:
- не загружается лишнее - ведь посетитель открывает на одном хите сайт только на одном языке
- переводчик трогает только один языковой файл и нет причин проверять, а не сделал ли он чего либо не то в другом языке (что то типа из мира СОЛИД :) - файл отвечает за, например, китайский, а русский - это зона ответственности другого файла)
Прошу прощения, не обратил внимания сразу на вопрос.
Сразу оговорюсь я про PHP. Самое "простое" пишем массив в файл
<?php$dict = ['someKey1' => 'someValue1','someKey2' => 'someValue2',];
Точнее, если возвратиться к модульности, то
<?php$dict['someKey1'] = 'someValue1';$dict['someKey2'] = 'someValue2';
Далее простой include и этот файл(ы) сразу интерпретируется.
В случае json (или любого другого формата) уже выполняется больше шагов:
Кстати, несколько в сторону, но о том же. В Qt (C++, питон, etc...) тоже на файлах
Не смотрел как в DLE. Но про разные "заметил". Я сторонник разных. Т.е. у модуля или компонента (в общем некоей сущности которую можно подключать) свой набор файлов, по количеству языков. Шаблоны разные (если это речь про шаблон некоей единицы страницы) нет необходимости. Один шаблон к нему языковых файлов по количеству поддерживаемых языков.
Не совсем понял. Какая разница скинуть и json и массив в файл нет же сложностей - т.е. организовать редактирование из админки вообще не проблема.
Хм. Почему это? Мне кажется тут вообще солид как то с натяжкой к этому вопросу подходит.
У меня есть проект где ежегодно в один прекрасный день могут заходит 140тысяч активных пользователей (и это даже "лайтовый" вариант) в остальное время это сайт с которым справится даже "минимальный тариф любого хостинга". Так вот я как бы посмотрев на то как ведут себя сервера, решил эти интерфейсные тексты выкинуть в файлы. (правда они были в основной бД). База становится узким горлышком. А эти языковые фразы - которые безболезненно можно оттуда убрать. Текст, который, по сути, статика. Меняется, но достаточно редко. Добавлять еще базу - а какой смысл? Все равно заметно большая часть закеширована. Удобство редактирования - это интерфейс, стоит ли его вот так любому "контент менеджеру" править по 100 раз на дню? Да и скорость доступа на серверных файловых системах сейчас вполне себе. (тем более не забываем, что один фиг в бд если грубои на холодную - это все те же файлы :)
А зачем json? Почему не обычный массив?
Кто тебе такой бред сказал? Ни разу из за этого не приходилось дисковое пространство расширять. Картинки небольшого интернет магазина "потребляют" заметно больше. Ты по прежнему надеешься обойтись без кеширования? (хотя да, для не запущенных сайтов и для не посещаемых - кеширование не нужно)
Ну т.е. ты еще раз прямым текстом называешь даунами разработчиков всех современных фреймворков. Имеющих огромный опыт работы с реальными проектами... ну да ну да.. у нас "каждая кухарка" иксперт. Прям становится очень жалко всех вебраработчиков мы ж мучаемся тут без твоего "прорывного" фреймворка.....
Я не пробовал. Но. А стоит ли оно того. Это необходимо если каждая страница каждый раз генерируется на каждом хите. В остальном кеширование (страницы полностью или блоками) или SSG. Т.е. получится ли в итоге значимый профит от скорости БД.
Только в том случае, если сделано это не правильно. Так ни кто не делает.
