Лично меня смущает использование i18n внутри мидлвари, просто потому что

видимо не нет опыта достаточного в программировании что бы понять что там происходит.

Но вообще я думаю что i18n отдельный модуль что позволяет ему выполнять задачи "перевода по славою" и без всяких мидлварей, я так понимаю что оно там использовалось что бы "на лету" определять установленную локаль пользователя в БД или брать ее в ТГ профиле. (сейчас посмотрел код мидлвари в силу своих возможностей и да так и есть, мидлварь и вся хурма написана ради получения одной единственной "локали" пользователя)

Отсюда и все ограничения исходят, что если локаль получать в мидлвари.

Я считаю что лучшим решением это будет оставить в мидлвари получение и запись в контекст локали.

А gettext и остальное вынести в отдельный модуль из которого его импортировать по необходимости, в нем же и получать нужную локаль из контекста.

Такое возможно?

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

Поиск по чату ничего не дал, поиск по гуглу аналогично, есть мнение что "тут конь не валялся" 😂

Возвращаясь к вопросу о i18n, я изучил один мануал, посмотрел устройство кода в разных примерах и самого модуля и насколько позволяет мне говорить отсутствие опыта, я все же скажу: Пихать сначала в i18n диспетчер что бы просто получить локализацию, это критическая ошибка была изначально, а потом возвращать gettext из мидлваря это "фишенка на торте" другими словами полная херня, так как все мероприятие теперь зависимо от диспетчера предаваемого, а также возвращение gettext в место регистрации мидлваря порождает самую большую ошибку что урезает большую часть возможностей архитектуры бота, порождая ошибки "цикличного импорта" . Другим словами я понял как работает и предварительно настраивается i18n и ответственно заявляю что не понимаю что побудило столько народа, писать такой говнокод и советовать другим.

Чел, никто твои мемуары не читает. Циклические импорты говорят только о том, что ты не подумал

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

Уже посмотрел aiogram/bot?

Снова ты свою жопу не жалеешь с и18н, да?

дело чести сдохнуть в сторону цели )

Уважаемый, а напомните мне о аналоге что вы мне давеча предлагали, супротив богомерзкого i18n? Дело в том что никакой магии не было обнаружено в предложенных исходников, они просто используют регистрацию хендлеров через декораторы, что в принципе разумно.

Пуще прочего меня бесит _() Я уж лучше буду писать свой вариант вида: async def cmd_help(...texts: ...): m.answer(texts.cmd_help.lang(...) Хотя бы нейминг выживает А в идеале выходная мидлварь

Название метода у gettext может быть любым, _ это общепринятое название, если не нравится - юзай любое другое и при экспорте укажи его же

m.answer(_("Hello ?")...) Или m.answer(texts.cmd_help.lang(m.lang), *аргументы для форматирования*)

m.answer(gettext("hello"))

Дело ваше Использовать отточенный за 31 год инструмент к которому его множество инструментов или сооружать собственный

Кстати, насчёт отточенных инструментов. Как тебе fluent?

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

Я хуй знает что там отточено, не юзаю, но сдаётся мне что там история вроде "Можно и вилкой суп хлебать научиться, и говорить что удобно" Может я и неправ, опять же, не использовал эту срань после прочтения примера из доки

Про консистентность поподробнее

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