Да после фронтенда не подумал по началу что там ничего сложного) За минут 15 нагенерил i18n модуль с плюрализацией

Потом часа 4 переносил всю эту бурду на классах в tfunctions формат. Плюс сделал ещё три скрипта

• Парсинг и проверка наличия всех переводов
• Проверка все ли ключи в переводах используются (нет ли лишних)
• Очистка лишних ключей

Прошлый разработчик прям блещет странными решениями и копипастой В целом у него в переводах хранились тарифы для оплаты в боте, прям объектами. А потом если бонус x2 к пополнению - для этого в коде ещё одни тарифы были… Тоже подготовил модуль нормальный, туда i18n этот прикрутил, готов к миграции, осталось бонусы прописать.

А так для питона я посмотрел варианты i18n, тоже пришел к выводу, что лучше самому сделать с тем функционалом, который нужен, чем привязываться к библиотекам. Если нормально сделать - то поддержка и обновления не особо нужны, механизм простой очень же.

А вот на фронте, с SSR - я бы предпочел библиотеку. Если хочется единую базу ключей иметь - то можно в Python модуле сделать эндпоинт чтобы отдавать из этих yaml файлов, но я сторонник модульности, пусть у фронта лучше свои переводы будут. Только фронта пока нет, чисто flask HTML+js — заменил jquery на alpine пока…

Работы много еще

Если вкратце, то i18n и есть самописный модуль. А locales - это структура из захардкоженной структуры классов, хоть и типизированной. Но чот замудрено, слишком много логики и ответственности на них.