Sly32

У меня примерно похожее решение. Только роутинг в fastapi не требует создавать папки. 

В любом случае Хранить нужно в json - это самое удобное и масштабируемое решение

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

Дальше. Простой запрос по языку типа SELECT * FROM table WHERE table.lang='ru',  мне выдаст n-ое количество строк, как мне потом обрабатывать это? Jinja2 шаблонизатор  использует очень простой конструктор работы с контекстом в виде словарей и мне не очень хотелось бы городить огород с сериализацией.
то есть  если мне в респонсе пришел такой словарь {"ru": {"mentee": "ученик"}}, то я просто в шаблоне использую:

<ul class="navbar-nav me-auto mb-2 mb-lg-0">
   <li class="nav-item">
        <a class="nav-link href="/mentee/{{user_id}}">{{lang.mentee}}</a>
   </li>

И все. Если это обьект респонса из базы - мне нужно будет в цикле найти все нужные значение. Такие вещи не стоит отдавать на фронт, с бэка уже должен приходить ответ в нужном формате.

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

Как обычно, надежда на нормальный диалог с тобой - бессмысленна. Тебе не лень писать про свои обидки, но ты не в состоянии привести 2 строки кода - как ты думаешь, это не говорит о твоем уровне?Может у тебя когнитивный диссонанс? потому что сначала это

но потом

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

Пока что ты демонстрируешь не то что утрату, а полное отсутствие.

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

[json]
{
    "en":{
        "home": "home",
        "subjects": "subjects",
        "mentors": "mentors",
        "scheduler": "scheduler",
        "news": "news",
        "adverts": "adverts",
        "search": "search"
    },
    "ru": {
        "home": "домой",
        "subjects": "предметы",
        "mentors": "преподаватели",
        "scheduler": "расписание",
        "news": "новости",
        "adverts": "обьявления",
        "search": "поиск"
    }
}
и обработчик в 10 строк
[lang.py]
import os
import json
from fastapi import Depends, Path

def get_language_dependency(lang: str = Path(...)) -> dict:
    return get_language(lang)

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 = {"lang": data.get(lang)}
        if not lang:
            return {"lang": data.get("en")}
        return lang

При этом при переходе на БД и переделывать ничего не надо. Монго и так работает с джейсонами, в постгрес тоже есть поле типа json и никакой огород не надо городить

Побьешь мое решение  своим?

Докажи хоть раз что ты не пустозвон. Приведи пример. Пока я вижу так. Чтоб было проще, базовый текст, на английском - так будет проще строить роутинг. Есть вкладки для en: ['mentor', 'mentee', 'schedule', 'subject', 'news']. Пока что все прекрасно кладется в одну таблицу:

Все вроде как прекрасно. Но тут я решил добавить радел, например, реклама. Добавлять новый столбик?
А если раздел предметы содержит подразделы - Математика, История, Химия.... Куда их пихать?
Жду твои варианты.
И давай без надувания губ. Чисто техникал дискуссия. Может, я что-то упускаю, усложняю, а ты видишь простой путь.

То есть ты не знаешь как? Мне вот почему то кажется что хранить все данные в одной таблице не получится

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

Можешьипривести пример таблиц? Допустим в меню 5 пунктов и нужно 5 вариантов языков. Как хранить, как вызывать?

Что ты делал-то? Есть примеры? И в данном случае я спрашивал про опыт графовой БД а не как собрать шаблон.

Я тебя вообще не понимаю, ты пишешь:

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

Не понимаю, зачем городить огород с кучей шаблонов, когда достаточно одного.
Вот еще счас смотрю в графовую базу данных типа AWS Neptune. Она сверхбыстрая и не только под шаблоны подойтет. Кто-нибудь пробовал?

Arbnet, ты же там хотел соцсеть свою создать, значит должен был с такой знаком - как оно - стоит выделки?