Интернационализация сообщений об ошибках API на интерфейсе или на сервере?

Моя команда в настоящее время работает над веб-проектом, в котором внешний интерфейс использует json api, предоставляемый серверной частью. Мы используем технологию Spring Boot и AngularJS. API имеет стандартный формат ошибки, который выглядит следующим образом:

{
    "errorCode": "1111",
    "message": "Error occurred: some error message",
    "developerMessage": "message for developer"
}

Ответ об ошибке также может содержать необязательный список ошибок проверки полей. Вопрос в том, где делать перевод сообщений об ошибках пользователей? Если серверная часть возвращает уже переведенное сообщение на основе локали запроса или если интерфейсная часть использует errorCode и его механизм i18n. У нас есть механизмы i18n как на задней части (опора Spring i18n), так и на передней (угловой-переводной).

Какая лучшая практика? Каковы плюсы и минусы каждого подхода? Любой совет приветствуется.


java spring angularjs internationalization angular-translate
person fkn    schedule 07.05.2015    source источник

Ответы (2)


arrow_upward
19
arrow_downward

Я бы сделал это, локализуя все на веб-интерфейсе. Серверная часть будет отправлять идентификаторы, которые клиентские приложения затем переводят в локализованный текст.

Преимущества:

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

Недостатки:

  • перевод новых ошибок невозможен. Если ошибка была определена на бэкэнде после того, как клиентские приложения были объединены, клиентам необходимо будет отобразить общее сообщение (но при необходимости может отобразить новый идентификатор ошибки).
  • более сложная комплектация

Для поддержки нескольких клиентских приложений вам может потребоваться преобразование resx на этапе объединения в сборку. Он создаст файлы ресурсов в формате, требуемом клиентом, чтобы вы могли сохранить единый источник переводов.

person andreister    schedule 27.07.2017
comment
Я бы добавил меньшие полезные нагрузки, в нашей настройке пользовательский интерфейс может изменять его локально на лету, поэтому серверная часть не знает языковой стандарт, ему придется отправлять полный перевод для каждого языка. - person Keegan 82; 13.06.2018
comment
У обоих подходов есть свои плюсы и минусы. См., Например, этот ответ для получения мнения backend. - person Cornel Masson; 14.05.2020

arrow_upward
10
arrow_downward

Если бы мне пришлось это сделать, я бы сделал это на бэкэнде, в первую очередь потому, что поскольку бэкэнд имеет локаль и также генерирует ошибки, есть смысл ожидать от него локализованных ошибок. Это также разъединит системы, так что, если есть какая-либо новая функция / изменение, сделанное на задней стороне, и добавлена ​​новая ошибка, вам не нужно отпускать переднюю часть только для ошибки.

Кроме того, когда это масштабируется, и у вас есть несколько серверных систем, вышеуказанный подход просто работает хорошо, поскольку все генераторы ошибок несут ответственность за заботу о своих соответствующих локализациях.

person Sandeep Kaul    schedule 07.05.2015
comment
Этот подход хорош, но серверная часть накладывает ограничение на количество языков, которые может ожидать клиент. Если клиент может полагаться на коды ошибок, он может бесплатно использовать собственный пакет перевода и может использовать любой язык, какой пожелает. - person falcon; 07.11.2018