LINUX.ORG.RU

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

 


0

1

Добрый день, вопрос скорее по «архитектуре» приложения. В общем, есть некое приложение фронт ReactJS, бэк Aiohttp (хотя какой именно стек, скорее всего, не важно). Aiohttp используется только для REST ессно. Где лучше размещать переведенный текст? Львиная доля текста есть только но фронте, но есть всякие сообщения об ошибках, которые приходят от бэка (ошибка сервера, ошибки валидации форм и т.п). Натыкался на совет, что на сервер вообще не должен выдавать «человеческие» строки, а выдавать только их коды, что-то типа «E_ERROR_MESSAGE_VALIDATE_FORM_NAME», а фронт уже сам у себя все разбирает. Как принято сейчас это делать?

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

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

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

vvn_black ★★★★★ ()
Последнее исправление: vvn_black (всего исправлений: 1)
Ответ на: комментарий от vvn_black

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

hell_wood ()

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

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

crutch_master ★★★★★ ()

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

Legioner ★★★★★ ()

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

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

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

dimuska139 ()
Ответ на: комментарий от dimuska139

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

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

static_lab ★★★★★ ()
Ответ на: комментарий от static_lab

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

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

dimuska139 ()
Ответ на: комментарий от dimuska139

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

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

static_lab ★★★★★ ()
Ответ на: комментарий от static_lab

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

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

dimuska139 ()
Ответ на: комментарий от dimuska139

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

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

HIS ()
Ответ на: комментарий от HIS

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

HIS ()

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

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

Octagon ()
Ответ на: комментарий от HIS

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

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

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

HIS ()

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

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

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

HIS ()