Локализация web приложения

Проблема то в чём? )

Как ни крути, в итоге, у тебя будет «словарь» с переводами строк на фронте. Можешь его встроить сразу в SPA, можешь подтягивать его с бэка при старте (если не хочешь на каждое исправление перевода деплоить заново приложение).

Т.е. однозначно на фронте переводы должны быть, но при этом хорошо бы предусмотреть RPC для получения свежего при старте.

Да проблемы, то нет) Спрашиваю, кто как делал такое, привел пример, что сервер возвращает не «человескую» строку, а ее некий код, а фронт уже подставляет нужно значение, это если говорить, про сообщения, которые сервер выдается (опять же сообщения об ошибках валидации и т.п).

Как принято сейчас это делать?

Какая разница что там принято. Сегодня модно так, а завтра будет по-другому - пойдешь всё переписывать? Пиши как так чтобы это решало проблемы, а не создавало их ровном месте из-за того, что так пишут все, например.

Логичное замечание) Но я имел ввиду,best practice, и услышать мнения тех, кто уже с таким сталкивался.

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

best practice

Не сталкивался, но сделать бы на клиенте. Какой смысл тащить её на бек?

Можно отталкиваться от gettext, в котором кодом переменной перевода является сам текст на английском языке. Какой смысл придумывать свои коды поверх?

То есть отправили на сервер форму, допустим, с полями name, email, а при ошибке возвращается Json вида {«errors»: {«email»: «User already exists»}}. В данном случае «User already exists» - это не просто текст ошибки, но и ключ в переводах. То есть если у юзера локаль fr, например, то по этому же ключу в массиве переводов выбирается текст ошибки на французском языке.

Считаю, исходя из своего опыта, что все переводы должны на бэке быть, чтобы была возможность переводчикам их редактировать, исправлять косяки в переводах и т.п. Как они на фронт будут попадать - отдельный вопрос. Например, при деплое фронта будет формироваться Json-файлы (свой для каждой локали) с переводами. Когда будет грузиться страница, будет этот Json-файл подтягиваться. Ну или прямо в тело страницы переводы в виде js переменной в index.html впихивать при деплое фронта.

все переводы должны на бэке быть, чтобы была возможность переводчикам их редактировать, исправлять косяки в переводах и т.п.

Вы не заносите переводы в систему контроля версий?

Нет, у нас вообще немного по-другому сделано. Сервис переводов (отдельный микросервис с веб-интерфейсом для переводчиков) формирует артефакт, который при деплое проектов, использующих переводы, распаковывается. То есть там хранятся переводы вообще для всех проектов. Когда именно формируется артефакт (архив с переводами для разных языков в разных форматах для разных приложений) не скажу, т.к. не помню. Сделано так (возможно, это странный подход, не спорю) потому, что переводы постоянно новые появляются или старые обновляются. Так разраб просто заносит фразу в админку сервиса переводов и ждет, когда переводчики ее на кучу языков переведут. После чего делает редеплой своего проекта - переводы подтягиваются.

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

Не совсем правильно написал. В одном артефакте не переводы от всех проектов, а переводы на разных языках одного проекта.

Мы пока сами отдаём новые строки для перевода и коммитим результат. В будущем команда переводчиков будет сама коммитить переводы в проект.

Хранить переводы в проекте удобно тем, что обеспечивается воспроизводимость сборки: хоть когда собери — результат тот же; и строки синхронизированы с кодом фичи. Просто иногда приходится не только добавлять новые, но и удалять устаревшие строки.

Это да, согласен, синхронизация с кодом фичи удобна, я не подумал об этом.

Я правильно понял, что вы решили обучать переводчиков гиту? А не запарно, если их много, как и языков в проекте? И насколько безопасно переводчикам добавить доступ к репозиторию с кодом?

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

К стати, точнее это тема не про локализацию, а про интернационализацию веб приложения.

Нет сейчас вспоминаю, таки в файлах. Но всё равно веб интерфейс для правки переводов я сделал и не только. Там почти целый CMS маркетологи попросили сделать для правки индексных страниц. Но в БД тоже ничего не мешает хранить.

Да, совет правильный.

У API есть коды ошибок, которые они возвращают, а клиенты (браузерные или другие приложения) их разбирают самостоятельно. Как, например, в API чата Matrix.

Память просветляется. Было это примерно 15 лет назад.

Вспомнил ещё детальнее.

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

Натыкался на совет, что на сервер вообще не должен выдавать «человеческие» строки, а выдавать только их коды, что-то типа «E_ERROR_MESSAGE_VALIDATE_FORM_NAME», а фронт уже сам у себя все разбирает. Как принято сейчас это делать?

Это и сейчас так принято и 20 лет назад тоже.

Так легче делать мультиязычность.

Команда переводчиков не зависит от нас, и мы не в курсе что там и как. Возможно, там есть технические специалисты для работы с гитом.