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

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

Ну вот даже если каждому элементу из базы присваивается префикс, где он будет использоваться (main, menu, news, art, shop), это же нужно знать из каких модулей состоит страница и подгружать составным запросом, сохранять в переменные, а потом уже использовать в каждом модуле. Или в каждом модуле делать запрос к бд для слов интерфейса этого модуля. Тем самым плодить количество запросов к бд. А смысл в этом? На шаред хостинге вообще есть ограничения по процессорному времени и времени запросов к бд.

Я уже убежден больше чем полностью, что сторонник баз вообще не сталкивался с такой задачей. Прочитал что-то где-то в 2005 году, не понял что и теперь опирается на это. 

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

Ровно так же и с размерами. Гений не понимает, что такое обьект, како он хранится в памяти, как создается и когда удаляется. Опять же - все легко проверяется на практике. 

Файл в памяти остается? При таком ответе я бы уже закончил собеседование, отправил бы кандидата домой и пометку поставил - без права повторного интервью. Не думаю что большие отличия, но в питоне есть такие контекстные менеджеры, декораторы, использование которых  позволяет автоматически закрывать файл, после того как из него получены нужные данные или записано в него что-то. Да и вообще, если уж считаешь себя самым лучшим разработчиком - ну разберись ты в вопросе, как управляется память! Это же база! 

Ну как я и говорил, это уже особенности реализации. Мне неудобно хранить кучу супермелких файлов, потому что в моем случае, как я упоминал, размер общего будет в пределах пары килобайт. А с правкой - еще проще. Если проект выстрелит и не останется домашним развлечением - я потрачу полчаса и напишу простой декодер, который будет из обычного экселевского файла выгружать инфу и формировать рабочий JSON.

Что еще надо для переводчика? Чат ГПТ  с эти справится на раз))
По поводу хранения данных в коде, а если ты хранишь переводы в пхпшном формате, то это неизбежно, То у нас в питоне за такое отбивают руки.
Никакие данные не могут быть захардкожены. Для замены одного слова нужен программист, а это сильно дорого.

Я кстати уже немного продвинулся, прикрутил регистрацию, доделаю создание расписания и уже можно будет показать, кому интересно.

Да вроде бы здесь даже не обсуждается идея прописывать в шаблоне. Спорим как реализовывать динамическую подгрузку в шаблон

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

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

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

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

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

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

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