pro.jvm

22 Dec 2024 12:00

И при баге в одном месте, нужно будет править каждый клиент.

pro.jvm

22 Dec 2024 12:00

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

pro.jvm

22 Dec 2024 11:59

Вы писали для фронта календарики когда-нибудь или какие-нибудь инпуты для чисел?

pro.jvm

22 Dec 2024 11:58

Задайте себе кучу вопросов и попробуйте с точки зрения Бека на рендеринг ошибки взглянуть. Там в дурку не долго уехать

pro.jvm

22 Dec 2024 11:58

А - если в тексте ошибки даты - то да - я бы перевел

pro.jvm

22 Dec 2024 11:57

Как? Вы же рендерить ошибку на беке будете

pro.jvm

22 Dec 2024 11:57

Не - вот это не надо. Это на фронте в одном месте один раз пишется. Иначе там будет пздц с визуальными компонентами для редактирования дат и чисел.

pro.jvm

22 Dec 2024 11:54

Нет человека - нет проблем. (с) Сталин

pro.jvm

22 Dec 2024 11:51

А если его родной язык - Javascript - то пусть лучше увольняется, реально от таких "разработчиков" только одни проблемы.

pro.jvm

22 Dec 2024 11:50

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

pro.jvm

22 Dec 2024 11:50

Это не его работа переводить.

pro.jvm

22 Dec 2024 11:49

Ладно. Делайте как хотите. Я просто свой взгляд на проблему описал и попытался аргументировать. Не претендую на истинность.

pro.jvm

22 Dec 2024 11:47

Почитайте https://jsonapi.org/format/#error-objects пожалуйста

pro.jvm

22 Dec 2024 11:46

Отвечать на ангийском тогда - действительно будет гемор с арабами и так далее

pro.jvm

22 Dec 2024 11:45

Ну кстати, как вариант, не моноязык - а отвечать всякими кодами языковых фраз, типа: auth.error.dateExpired

pro.jvm

22 Dec 2024 12:00

Да, но там уже реализация визуальных компонентов своя

pro.jvm

22 Dec 2024 11:59

Представьте что у вас с бека может прийти для одного языка в одном формате, для другого в другом

pro.jvm

22 Dec 2024 11:59

Зачем ещё тут фронт примешивать?

pro.jvm

22 Dec 2024 11:58

А если в данных для форм например - то нет.

pro.jvm

22 Dec 2024 11:58

А если там внутри дата или денежная единица?

pro.jvm

22 Dec 2024 11:57

Ну дак подготовит он для en/ru локали.
Для остальных, кмк, переводчики должны заниматься. С контекстом, т.е. не просто прогнать через сервис перевода и получить ошибки: отменить/отменить для cancel/discard changes.

pro.jvm

22 Dec 2024 11:56

А. Ещё. Вы ещё бек научите даты правильно в сообщении об ошибке рендерить. А то эти иностранцы напридумывал форматы mm-dd, dd/mm и т.д.

pro.jvm

22 Dec 2024 11:53

Все проблемы от разработчиков. Лажают. Зп требуют. Спорят. Не могут без багов писать.

pro.jvm

22 Dec 2024 11:51

И до того как это попадет на бой - надо чтобы переводы были сделаны. Поэтому фолбек тут в принципе не нужен.

pro.jvm

22 Dec 2024 11:50

Так это не его зона ответственности, а переводчика.

pro.jvm

22 Dec 2024 11:49

Спор это хорошо, в нем в любом случае рождаются и новые идеи:)

pro.jvm

22 Dec 2024 11:47

Там не должно быть отсутствия перевода - если ты написал какую-то ошибку, у нее должен быть осмысленный текст. Если бекендер готов уволиться из-за того, что его заставляют описать текстом ошибку которую он выкидывает - то я считаю пусть лучше уволится.

pro.jvm

22 Dec 2024 11:46

Человекочитаемый текст в любом случае нужен чтобы фолбечится в него в отсутствии перевода в сервисе локализации

pro.jvm

22 Dec 2024 11:46

Тогда да, это можно вынести куда-то в отдельный сервис для переводов как-то...

pro.jvm

22 Dec 2024 11:44

Исправлять будешь только в сервисе локализации загружая новый xliff текстовый файлик