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

Sly32 #:льшой JSON: я не знаком с python, но Fastapi кэширует в итоге этот  "малюсенький объект" в каком виде? снова в json?, если да, то всё равно он его будет снова и снова парсить, уверен, что этот малюсенький объект со временем разрастётся во что-то более весомое, а если скомпилировать в байт код, то такой проблемы не будет

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

Я тут не понял. Речь о клиентских шаблонах?

Сначала рассмотрим серверные шаблоны. В них добавляется содержимое из трех мест:

1. основное содержимое из баз данных; 
2. нуждающиеся в многоязычном представлении элементы шаблона из "языковых" конфигурационных файлов шаблона* (в файле шаблона каждый такой элемент определяется символьным англоязычным ключом);
3. общие данные, которые обычно не нуждаются в многоязычном представлении, из общих конфигурационных файлов* (может быть один или несколько файлов, причем "несколько" необязательно связано с многоязычностью; в файле шаблона каждый элемент данных определяется символьным англоязычным ключом).

* обычно я использую программные файлы (PHP), но можно, наверное, и разбираемые программно; и точно можно SQL/NoSQL.

Клиентские многоязычные шаблоны генерируются из одного серверного с пропуском основного содержимого (т.е. за вычетом пункта 1). В итоге получается ваш вариант 1. Здесь используется обычное серверное кэширование.

Всю тему не читал.

Просто такая реализация - это когда сам занимаешься проектом. А так должна быть защита от дурака.

Это же меню нужно связать со страницами. Для страницы обычно должны определяться подключаемые модули. Есть вероятность рассинхронизации страниц и меню.

По любому нужно связывать меню со страницами даже если это на файлах организовано (или писать админку или руками править файл). В меню должен быть или ID страницы (но это снова обращение в базу чтобы узнать урл страницы) или прописывать сразу полный урл (но в таком случае при его смене в базе можно получить 404).

Поэтому там разные варианты могут быть в зависимости от проекта и кто его будет вести.

Как вариант все в 1 таблице (меню и страницы), при ее изменении делать экспорт в файл (тот же джосн) и быть уверенным, что работаешь с актуальными данными. и т.д.

Да там 100500 способов реализации. Выбор конкретного способа зависит от конкретного проекта. И да, в файлах тоже хранят, но нет так, как у тебя, а переводы фраз.

тогда я приношу извинения, реализация нормальная

все верно, и свои консерны к этому способу я уже высказывал, но да - он самый быстрый

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

Спасибо за интересную дискуссию

Основных вариантов с БД - два:
1) Создать в таблице меню колонки с языковыми вариантами.
2) Создать дополнительные таблицы с языковыми вариантами.
Я полагал, что тебе эти варианты известны. Вариантов с файлами переводов я не касаюсь. Мне они не нравятся в силу более сложного редактирования и использования.
И ещё раз: выбор конкретного варианта зависит от конкретного проекта.

Невозможность расширения, выше уже писал.

необходимоссть  джойнить таблицы - сложный запрос для простой задачи - неоправданный расход ресурсов и время.

Спасибо, твой вариант я рассматривал имеет место быть