pro.jvm

22 Dec 2024 11:23

Удачи. Особенно когда вы выйдите на новый рынок. Вместо того чтоб подсунуть в сервис локализации новый перевод вы будете шаманить с беком

pro.jvm

22 Dec 2024 11:21

Фолбек на английский если нет перевода в сервисе локализации.

pro.jvm

22 Dec 2024 11:21

А необработанные переводятся один раз: Упс что-то пошло не так. И логи на английском.

pro.jvm

22 Dec 2024 11:20

Это жуткий гемор, несопоставимый с тем, что на беке просто сразу все свои обработанные ошибки пеерводить.

pro.jvm

22 Dec 2024 11:20

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

pro.jvm

22 Dec 2024 11:20

https://jsonapi.org/format/#error-objects тут под это есть все поля

pro.jvm

22 Dec 2024 11:19

А переводить должен тот кто занимается отображением

pro.jvm

22 Dec 2024 11:18

Потому что текстовый код нагляднее - понимаешь сходу и не надо в доку лезть.

pro.jvm

22 Dec 2024 11:17

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

pro.jvm

22 Dec 2024 11:17

status: the HTTP status code applicable to this problem, expressed as a string value.

gspdee

pro.jvm

22 Dec 2024 11:03

Зачем переводить бек? Берешь https://jsonapi.org/format/#error-objects . Код ошибки уникально идентифицирует паттерн перевода (например xliff). В meta суешь мапу с плейсхолдерами. На клиенте определяешь язык и все для перевода уже выше описано.

pro.jvm

22 Dec 2024 10:46

Для начала я бы вообще отделил ошибки от некорректного запроса

pro.jvm

22 Dec 2024 10:36

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

pro.jvm

22 Dec 2024 10:36

Ну кстати как вариант - использовать имя класса исключения.

pro.jvm

22 Dec 2024 10:33

Кстати хорошая мысль сейчас родилась. Можно в API публиковать отдельным методом все коды ошибок и что они значат.

pro.jvm

22 Dec 2024 11:23

В чем данный подход лучше того же ResourceBundle с текстом ошибок для каждой локали?

pro.jvm

22 Dec 2024 11:21

А где тут база знаний?

pro.jvm

22 Dec 2024 11:20

Чтобы смапить код ошибки на шаблон перевода под конкретный язык. В шаблон вставлять плейсхолдоры из мета

pro.jvm

22 Dec 2024 11:20

Мы проектируем апи для приложения или приложение под апи? Карго-культ.

pro.jvm

22 Dec 2024 11:20

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

pro.jvm

22 Dec 2024 11:19

Зачем нужен код ошибки для перевода? Где и как переводчик его использует?

pro.jvm

22 Dec 2024 11:19

Я не отрицал что в ошибке надо вернуть человекочитаемое описание. Я считаю что с бека оно должно лететь на en-us

pro.jvm

22 Dec 2024 11:17

Зачем она нужна, когда ты прямо там можешь написать, в чём проблема?

pro.jvm

22 Dec 2024 11:17

Профит для кого? Для бекендера, который слентяйничал? А ничего что потом трудозатрат больше переводить это на всех фронтах?

pro.jvm

22 Dec 2024 11:13

Бек ниче не знает про переводы. Профит. Ошибку рендерит фронт. Профит. Xliff пишут переводчики. Профит. А то начинается, в логах бека ошибки на русском, испанском, китайском...

pro.jvm

22 Dec 2024 10:47

В случае с первым код не нужен, потому что ошибку обрабатывать не имеет смысла
Во втором случае код не нужен, потому что пользователю надо вывести описание

pro.jvm

22 Dec 2024 10:42

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

pro.jvm

22 Dec 2024 10:36

Для этого есть openapi документация

pro.jvm

22 Dec 2024 10:35

Кмк, enum для ошибок - анти-паттерн.

pro.jvm

22 Dec 2024 10:30

Enum я считаю лучше всего