Sly32

Спасибо за комментарии, не думал что python код так сложен для понимания, поясняю. Все данные никогда не выгребаются. Вот есть условный роутер, обрабатывающий запросы типа

site.com/{lang}/users/profile   когда пользователь в меню выбирает язык ru происходит переадресайия на  урл 

site.com/ru/users/profile

Соотвтетсвенно роутер идет в этот мой большой JSON:

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

И по ключу "ru" выгребает только  данные для русского интерфейса:

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

Fastapi умеет кэшировать  данные и пока пользователь не сменит язык - ему будет подгружаться  интерфейс из "ru" интерфейса. 
То есть в шаблонизатор приходит малюсенький обьект только с тем что нужно.

так и есть:

def get_language(lang: str = "en") -> dict:
    file_name = "lang_settings.json"
    file_path = "".join((os.getcwd(), "/src/settings/", file_name))
    with open(file_path, "r") as f:
        data = json.load(f)
        lang = data.get(lang)
        if not lang:
            return data.get("en")
        return lang

Ну, выше, я вроде уточнил свой вопрос. В дискуссии принято исходить от высшего уровня к нижнему. Архитектура приложения. Сначала интерфейс, потом детали реализации. в данном случае интерфейс(хранение  в файлах( пусть даже и в коде) предпочтительнее  хранения в базе. Это слишком дорого. Да, в коде - самое быстрое, но чревато проблемами, описанными выше. Ну и хранение в разных файлах противоречит как SOLID так и DRY - не повторяйся. У меня один роутер  будет обрабатывать  все языки, соответственно если мне нужно поменять что-то, мне нужно поменять что-то в обработчике  и в языковом файле, а не в 6 разных файлов для 6-ти языков.

пока что срач устраиваешь ты и Арбнет, остальные хоть как-то  аргументируют свою позицию.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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