На чем лучше написать сервис интернационализации и админку
Что проверяют
Не список библиотек, а умение задать правильный вопрос до выбора технологии. Задача сформулирована размыто нарочно: сильный кандидат сначала выясняет, кто и как часто редактирует переводы, кто пользуется админкой и какие там права, и только после этого называет стек.
Как отвечать
Начните с развилки, она определяет всё остальное.
Переводы меняются редко и правят их разработчики: хватает подхода с gettext и файлами .po и .mo. В Django это встроенный слой перевода с командами makemessages и compilemessages, во Flask обычно связка с Babel. Дёшево и быстро, но каждая правка запятой уезжает в релиз.
Переводы правят не разработчики и правят постоянно: нужен сервис. Хранение по ключу вместе с локалью и пространством имён, выдача готовых бандлов с версией, кэш и ETag, фолбэк на язык по умолчанию при отсутствии ключа, история изменений и откат.
Дальше содержательные детали, которые отличают опыт от теории: множественные числа по правилам CLDR (в русском четыре формы, а склейка строк руками ломается на первом же языке), подстановки через ICU MessageFormat, форматирование дат, чисел и валют через Babel, псевдолокализация для поиска строк, забытых без перевода.
Про админку ответ простой: если бэкенд на Django, встроенная админка закрывает CRUD, права и аудит почти без кода, и городить SPA ради этого не нужно. Если стек на FastAPI, берите готовую админку или отдельный интерфейс поверх API, но закладывайте время на роли и журнал правок.
Где спотыкаются
Первое: начинают с выбора фреймворка вместо вопроса про процесс. В итоге проект с ежедневными правками текста получает переводы в файлах, и контент-менеджер ходит к разработчику.
Второе: советуют Django вместе с Babel как единый рецепт. У Django собственный слой интернационализации поверх gettext, Babel там лишний, а вот для Flask он как раз уместен.
Третье: забывают про эксплуатацию. Нет версий бандлов, нет отката, нет отчёта о непереведённых ключах, и пользователь однажды видит голые ключи вместо текста.