Не смотрел как в DLE. Но про разные "заметил". Я сторонник разных. Т.е. у модуля или компонента (в общем некоей сущности которую можно подключать) свой набор файлов, по количеству языков. Шаблоны разные (если это речь про шаблон некоей единицы страницы) нет необходимости. Один шаблон к нему языковых файлов по количеству поддерживаемых языков.
Не совсем понял. Какая разница скинуть и json и массив в файл нет же сложностей - т.е. организовать редактирование из админки вообще не проблема.
Хм. Почему это? Мне кажется тут вообще солид как то с натяжкой к этому вопросу подходит.
У меня есть проект где ежегодно в один прекрасный день могут заходит 140тысяч активных пользователей (и это даже "лайтовый" вариант) в остальное время это сайт с которым справится даже "минимальный тариф любого хостинга". Так вот я как бы посмотрев на то как ведут себя сервера, решил эти интерфейсные тексты выкинуть в файлы. (правда они были в основной бД). База становится узким горлышком. А эти языковые фразы - которые безболезненно можно оттуда убрать. Текст, который, по сути, статика. Меняется, но достаточно редко. Добавлять еще базу - а какой смысл? Все равно заметно большая часть закеширована. Удобство редактирования - это интерфейс, стоит ли его вот так любому "контент менеджеру" править по 100 раз на дню? Да и скорость доступа на серверных файловых системах сейчас вполне себе. (тем более не забываем, что один фиг в бд если грубои на холодную - это все те же файлы :)
А зачем json? Почему не обычный массив?
Кто тебе такой бред сказал? Ни разу из за этого не приходилось дисковое пространство расширять. Картинки небольшого интернет магазина "потребляют" заметно больше. Ты по прежнему надеешься обойтись без кеширования? (хотя да, для не запущенных сайтов и для не посещаемых - кеширование не нужно)
Ну т.е. ты еще раз прямым текстом называешь даунами разработчиков всех современных фреймворков. Имеющих огромный опыт работы с реальными проектами... ну да ну да.. у нас "каждая кухарка" иксперт. Прям становится очень жалко всех вебраработчиков мы ж мучаемся тут без твоего "прорывного" фреймворка.....
Я не пробовал. Но. А стоит ли оно того. Это необходимо если каждая страница каждый раз генерируется на каждом хите. В остальном кеширование (страницы полностью или блоками) или SSG. Т.е. получится ли в итоге значимый профит от скорости БД.
Только в том случае, если сделано это не правильно. Так ни кто не делает.
По вопросу домен или подкаталог не скажу - это вопрос не технический.
По реализации, чаще делают на файлах - это касается текстов интерфейса. (битрикс, symfony, yii, django) Контент по прежнему в базе остается. Так же это решается, на сколько я помню (но сам не пользовался локализацией), в фронтендовых UI фреймворках.
Больше тут "сложность", точнее какой вопрос надо решать где хранить перевод контента - в той же таблице отдельная колонка, или отдельная колонка.
Про динамическую подгрузку контента не понятно. Если на серваке собирается страница полностью с контентом - так и надо собирать далее, если собиралась в браузере - так и остается.
Я перешел от разработки ПО к вебу - есть на чем сравнивать.
1. Это скорее зависит от конкретики проектов. Везде могут быть свои особенности. Там где нужна многопоточность, реальное время - тоже головняка хоть отбавляй. Во всех предметных областях тоже есть свои "приколы". Единственно чем разработка ПО легче (правда у меня опыт разработки только для энергетиков) - там на проектах чаще подробное ТЗ, а то и ГОСТы. В вебе чаще "сделай мне звездато".
2. Все знания, что описываете это скорее для тех кто "несколько в одном". Но таких проектов становится меньше. Но в целом все так, правда не так страшен черт как его малюют.
Знаний нужно везде много где проект с достойным бюджетом.
В общем все очень сильно зависит от проекта. Ведь есть проекты где "вебмастера" достаточно с поверхостными знаниями того же WP, html,css ну чутка php/js :)
Сама страница студии открывалась долго (ну как обычно в последнее время). Ролик залился примерно как всегда (пока я на другие площадки заливал). Но у меня ролики до 10 минут в основном.
Без ВПН, с компа
