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

Как обычно, надежда на нормальный диалог с тобой - бессмысленна. Тебе не лень писать про свои обидки, но ты не в состоянии привести 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 и никакой огород не надо городить

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

lang name value autoload

ru mentors учителя 1

ru mentees ученики 1

pl subject blabla 0

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

lang=ru and autoload=1

Детские обидки это у тебя, всё ждёшь что тебе взрослые опять конфетку дадут.. Взрослеть пора, начинать своей башкой думать.

От тебя мне точно никогда никакой пользы не было. А что касается тебя, то это как раз будет уроком, либо начнёшь сам думать, либо так и будешь по готовым примерам всё делать..

Да, можно так хранить. Но я сразу  вижу несколько сложностей, одну из которых ты уже привел - разные запросы под разные меню. Мне нужно универсальное решение с минимумом запросов, тут цикломатическая сложность на выходе должна быть О(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>

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

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

Сначала нужно иметь исходные данные. Вы хотите написать универсальное решение? Это большой проект? Кто занимается добавление новых и переводом?

Я для себя так сделал мультиязычность (и там не 3 языка):

На файлах. Идет масив $L_ar_main [ название1 => текст1, название2 => текст2,  ].

Для каждого языка есть своя директория, в ней отдельные файлы: основной (те слова что везде на сайте используются), а дальше например для раздела 1, раздел 2 и т.д. (чтобы лишние файли не подключать)

На пхп подставляются в шаблон (ну и кэш есть на отдельные страницы).

Сделал EN версию словаря, а потом написал код который взял слова с англ. списка и сформировал список с разделителем:

слово 1 @@
слово 2 @@
слово 3 @@
и т.д.

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

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

Если бы делал таблицу (или наверное разделил на несколько таблиц), то по столбцам было бы:

уникальное название переменной / en / ru/ и т.д. где идет переведенный текст (при необходимости нового языка добавляем новый столбец)

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

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

это никакая не сложность, чтобы не засорять оперативную память ненужными данными, которые  для отрисовки данной страницы не нужны, нужно ввести в указанной таблице поле с идентификатором меню и вытаскивать записи по нему и по языку

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

Респект вам 👍 Всё таки не перевелись ещё здравомыслящие люди.

Обращение к файлам же намного быстрее, чем к БД. Просто не нужно пихать все в один файл. В зависимости от версии и места подключаем en_menu, en_shop (как тот же идентификатор в БД) и т.д. json_decode php преобразует в объект или массив. Берем переменную и подставляем.

Тогда зачем придумали БД по вашему? Хранили бы всё в файлах, зачем БД нужно тогда? 😆