Sly32

Это не ответ.  Или ты не прочитал всю дискуссию.  Гениальный Арбнет сказал что все запросто можно хранить в одной талице, я усомнился, попросил доказать. Ни от тебя ни от него ответа я не увидел - как?

безграмотность  - это не понимать какой инструмент и для чего,  пытаться давать советы, не зная темы.  В итоге отказ от хранения языковых файлов в базе оказывается правильным даже с твоей точки зрения. Люблю критику, когда она на чем -то основывается. 

Ну вот и стоило бы прочитать сначала, о чем речь, прежде чем приходить и демонстрировать отсутствие понимания вопроса.  Для моих проектов нормально использование нескольких ресурсов для хранения данных - Mongo/Dynamo,  Postgresql/Oracle, Redis,  теперь вот на горизонте Neptune графовый.
Мне неинтересно нарисовать сайтик под Adwords, мне интересен сервис, который будет полезен. И повторюсь, по свои задачи - свой способ.  Для авторизации и хранения данных пользователя лучше  sqlDB  ничего не придумано.  А например  создать курс какой то по предмету с квизами, задачами - тут уже noSql.  И так далее. 

Забавно. сначала ты агитируешь за 

а потом оказывается, что 

WebStorm #:
языковые файлы, если вы не в курсе, они есть во многих популярных cms (например DLE) и хранятся также, как и у меня в  отдельных пхп файлах

По сравнению с чем? Сделать запрос в базу, хранить в коде, хранить в файлах?  Вы уж определитесь. В Питоне тоже весь код компилится в байт-код. Хранить настройки в коде - bad practice, почитайте может книги по чистому коду. Причин изменения кода может быть две -  обнаружение  бага и изменение функциональности. Если мне для расширения меню нужно менять данные в коде - это не код а мусор.

Gettext - тарая и известная штука, полезная, но в моем случае избыточная. С таким же успехом я могу AI использовать для перевода. 
Моя цель - с наименьшими расходами перевести интерфейс.

Это их право. Я не пишу сайты, я занимаюсь сервисами.  Тут немножко другие амбиции. Упираться в одну базу не вижу причин.

Вот интересно, что? Это очень дилетанские подход. Хранить прямо в коде можно данные, которые гарантированно никогда не изменятся после выхода в прод. И даже в этом случае это лучше хранить в переменных окружения, вычитывая их из .env файла. 

и расходы на чтение файла и на работу интерпретатора одинаковые

Однозначно. Просто тут вебмастера, воспитанные на жутком вордпрессе, котором все собирается из базы. А вместо оптимизации начинается игра с кэшами...

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

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

Я не вижу обоснований, можно тут поподробнее? Почему правильнее? Каждый раз ходить на сервер, чтобы собрать менюшку из 20-30 значений? Думать как реализовать вложеность? 

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

{
    "en": {
        "subjects": {
            "subjects": {
                "chemistry": "chemistry",
                "math": "mathematics"
            }
        },
        "mentors": "mentors",
        "scheduler": "scheduler",
        "news": "news",
        "adverts": "adverts"
    },
    "ru": {
        "subjects": {
            "предметы": {
                "chemistry": "химия",
                "math": "математика"
            }
        },
        "mentors": "преподаватели",
        "scheduler": "расписание",
        "news": "новости",
        "adverts": "обьявления"
    }
}

И отдельный метод соберет не просто перевод, а из ключей второго уровня создаст меню сразу с переводом. Также добавил уровнеь вложености.  Пока только один, но ничего не мешает сделать их сколько угодно. 
Если из этого вырастет коммерческий проект - редактирование  меню будет проходить в админке, не нужно будет руками править что-то в json-е, при этом будет сразу валидироватся правильность добавления данных. И скорее всего подключу тут уже AI - отдаешь ему структуру  меню  и язык и он сам собирает переводы. 

PS. Отстаньте уже от Arbneta,  он в очередной раз показал что ничего из себя не представляет, не вижу смысла загаживать техническую тему  

Ответ простой, скука. Все пытаюсь выжать из него хоть что-то дельное.

Это как раз не самое страшное. Хуже что и ума для того чтобы его сделать у него тоже не сильно много.

На чудик, можешь посмотреть, как это работает в личку линку отправил.
Если кому интересно пишите, покажу