Работаю в роли Software Architect/TL в megogo. За 6 лет жизни проекта довелось немало повидать, накопил много интересного опыта. С удовольствием читаю канал с записки, много дельных мыслей. История с переводами и gettext - больная мозоль с который мы немного намучались, но в итоге перешли на хранение в БД + rest api для работы с переводами и забыли о проблемах. Поэтому решил отписать дабы другие люди не наступали на те же грабли 🙂 К сожалению даже у нас не все команды внедрили получание фраз от API и продолжают деплоить приложения для изменений UI-фраз. Те кто перешел - сняли с себя часть проблем + дали возможность бизнесу вносить правки в тексты прямо из админки. Win-win.

Очень надеюсь, что будем видеть здесь ещё не раз Твои замечания! Мне кажется без них этот чатик будет уже совсем другим!

И ещё вопросик, а приложения каждый раз при запуске запрашивают, есть ли обновления по переводам? Или вы шлёте их принудительно пушами?

мне кажется, нормальная тема на уровне протокола вести версию перевода и при необходимости обновлять) вин-вин

Можно проэксплейнить вот это "на уровне протокола вести версию перевода"?

вместе с результатом обращению к сервису, гейтвей (или сам сервис) добавляет текущую версию перевода. если она неактульна - клиент запрашивает новую версию

ребята, а про фронтэнд никто не поддержит тему?

Могу рассказать как работает для бекенда веба: на старте выкачиваются переводы по всем активным локалям(их не более 10) и кешируются в памяти, далее в фоне крутится крон который раз в N мин обновляет для всех локалей переводы. Если переводы не менялись(получили 304 по etag) - ничего не происходит. Можно не выкачивать все локали, делать ленивую подгрузку - они будут загружены при потребности.
Для фраз где есть склонения и plurals используется стандарт icu - поэтому после выгрузки из api еще происходит первичная обработка библиотекой. Для java мы применяем icu4j, на фронтенде есть FormatJS

Этот же подход можно применить для любого клиентского приложения

Важный момент - в приложении все фразы имеют идентификаторы и дефолтный перевод, в случае если не удалось подгрузить переводы или переводчики еще не перевели на нужный язык - будут использоватся дефолтные которые поставляются с приложением. Также этот подход у нас позволяет автоматизировать добавление новых фраз в базу - при сборке происходит сканирование исходников, находятся все фразы для переводов, новые добавляются в БД, после чего уже включаются в работу переводчики.

Вариант с пушем тоже будет работать - в случае если у вас архитектура построена на основе pub sub

profi.ru построил свой сайт на таких микросервисах, но ребята плюются.  Вместо одного большого монолита получили десяток маленьких монолитов :)

десяток маленьких монолитов это прикольно) мы микросервисы строили по прикладным областям, пока полёт нормальный)

у нас это wfm, тут всё про работников, тут про точки планирования, тут про графики.. и т.д.

https://medium.com/@dolphin278/-1d6ac1747515

Обнаружение сервисов и конфигурация:
- Я спросил у ясеня: где моя любимая?
- Ясень мне ответил: Я ЕСТЬ ГРУТ!

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

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

мы просто пару лет гоняли монолит и вот-вот переведём всё на микросервисы

Вот так они и выглядят, ваши микросервисы — каждый в отдельности простой и симпатичный парень, но все вместе они могут разнести все в клочья раньше, чем вы успеете понять, что произошло. Из-за случайно попавшего к ним в руки банана (с) Егоров Борис