5916
Сообщество разработчиков Java Scala Kotlin Groovy Clojure Чат для нач-их: @javastart Наш канал: @proJVM Вакансии: @jvmjobs @jvmjobschat ⚠️ Оффтоп -> @flood ❌Переход на личности ❌Троллинг ❌Реклама ❌HH (вакансии) ❌Варез
Ну или когда ты сам себе фронтендер и знаешь точно что у тебя тебе твой бек ответит
Читать полностью…
Выходить на новые рынки и надо за счёт зашаманивания бэкенда, клиент должен быть максимально тупым и не страдать от старых версий с ограниченной совместимостью
Читать полностью…
Внезапно да. Но ты должен в твоём случае заставить бек перевести каждый код ошибки. По мне ситуации монопенисуальны
Читать полностью…
В чем данный подход лучше того же ResourceBundle с текстом ошибок для каждой локали?
Читать полностью…
Чтобы смапить код ошибки на шаблон перевода под конкретный язык. В шаблон вставлять плейсхолдоры из мета
Читать полностью…
Мы проектируем апи для приложения или приложение под апи? Карго-культ.
Читать полностью…
Тогда ты должен переводчику дать все варианты, что у тебя в принципе может ответить бек. Иначе потом появляются фронты, у которых часть ошибок не выодится, или часть на другом языке
Читать полностью…
Зачем нужен код ошибки для перевода? Где и как переводчик его использует?
Читать полностью…
Я не отрицал что в ошибке надо вернуть человекочитаемое описание. Я считаю что с бека оно должно лететь на en-us
Читать полностью…
Зачем она нужна, когда ты прямо там можешь написать, в чём проблема?
Читать полностью…
Профит для кого? Для бекендера, который слентяйничал? А ничего что потом трудозатрат больше переводить это на всех фронтах?
Читать полностью…
Бек ниче не знает про переводы. Профит. Ошибку рендерит фронт. Профит. Xliff пишут переводчики. Профит. А то начинается, в логах бека ошибки на русском, испанском, китайском...
Читать полностью…
В случае с первым код не нужен, потому что ошибку обрабатывать не имеет смысла
Во втором случае код не нужен, потому что пользователю надо вывести описание
Вот чего точно не стоит делать, так это кишки имплементации отдавать. И Боже упаси стектрейсами швыряться. И с сообщениями об ошибках с авторизацией-аутентификацией тоже осторожнее
Читать полностью…
Вообще нет, монопенисуальны они только когда у тебя один фронт, и вы с фронтендером в губы целуетесь сидите с утра до ночи.
Читать полностью…
Ну, зато я день потрачу и переведу нормально, чем иметь в китайском стиле сайты, чтобы клиенты поржали.
Читать полностью…
Удачи. Особенно когда вы выйдите на новый рынок. Вместо того чтоб подсунуть в сервис локализации новый перевод вы будете шаманить с беком
Читать полностью…
Фолбек на английский если нет перевода в сервисе локализации.
Читать полностью…
А необработанные переводятся один раз: Упс что-то пошло не так. И логи на английском.
Читать полностью…
Это жуткий гемор, несопоставимый с тем, что на беке просто сразу все свои обработанные ошибки пеерводить.
Читать полностью…
А главное дать возможность / объяснить, как воспроизвести все кейсы, чтобы протестировать можно было
Читать полностью…
https://jsonapi.org/format/#error-objects тут под это есть все поля
Читать полностью…
Потому что текстовый код нагляднее - понимаешь сходу и не надо в доку лезть.
Читать полностью…
Почему? Если у тебя есть база знаний по кодам ошибок, их описанию и способам решения, то это очень помогает поддержке. Плюс кейс выше по маппингу кода на перевод. Но код может быть и не числовым
Читать полностью…
status: the HTTP status code applicable to this problem, expressed as a string value.
gspdee
Зачем переводить бек? Берешь https://jsonapi.org/format/#error-objects . Код ошибки уникально идентифицирует паттерн перевода (например xliff). В meta суешь мапу с плейсхолдерами. На клиенте определяешь язык и все для перевода уже выше описано.
Читать полностью…
Для начала я бы вообще отделил ошибки от некорректного запроса
Читать полностью…
Ну в принципе да, там ведь у каждого метода итак ошибки описаны быть должны.
Читать полностью…