есть заранее ограниченный набор сигналов. О том, как эти сигналы будет обрабатывать фронт, он знать не должен.
У нас бэк вообще по своей специфике обновляется довольно редко. Мы, например, мини-игры делаем, и по бэку там один раз написал, запустил, забыл навсегда. Пишешь следующую.
А локализации новые добавляются иногда.
Если микросервис каждой мини-игры заставить отдавать локализованные нотики, что уже само по себе неудобно, так как логика одинаковая, а кодовые базы отдельные. Надо извращаться монорепой либо самописной библиотекой в приватном npm registry. А если добавили локаль - надо лезть в каждый микросервис и обновлять её там. Более того, тебе же для переводчика надо иметь набор всех фраз сразу, то есть их в любом случае надо где-то централизованно хранить.
Это вариант, который предложили вы. Я не понимаю, где тут преимущество.
Ещё тут предлагали вариант выделить специально-обученный микросервис, который отдаёт переводы в нужной локали. Чем это принципиально отличается от перевода на клиенте я не особо понимаю. Это просто размазывание одной и той же функциональности по двум разным местам. Можно с таким же успехом абсолютно всю интернационализацию, даже статическую, переместить на сервер. Из пустого в порожнее. Абсолютно не понимаю зачем.
А можно использовать функционал, который уже есть. На фронте и так настроена поддержка i18n. Там всё продумано, все процессы налажены. Добавляем локаль - отдаём переводчику весь словарь с фронта и этого достаточно. Он назад отдаёт перевод - мы его вставляем как есть в одно место и всё круто.
Так где в этом подходе проблема?
я думал мы говорим о локализации словарей а не сигналов
Обсуждают сегодня