All geek questions in one place

Internationalizing api error messages on the front or back side?

My team is currently working on a web project where the front end uses the json api provided by the back end. The technology we use is Spring Boot and AngularJS. Api has a standard error format that looks like this:

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

The error response may also contain an optional list of field validation errors. The question is, where should we translate user error messages? If the return end returns an already translated message based on the request locale, or if the front end uses the errorCode and i18n mechanism. We have i18n mechanisms both on the back panel (w761 support> i18n) and the front part (angular translation).

What is the best practice? What are the pros and cons of each approach? Any advice is appreciated.

+6
source share
2 answers

If I had to do this, I would do it in the background, primarily because, because the backend has a locale and also generates errors, it makes sense to expect localized errors from it. It will also shut down the systems, so if there is any new function / change on the back panel and a new error is added, you do not need to free the front part just for the error.

In addition, as soon as it scales and you have several backend systems, the above approach works well, since all error generators are responsible for their respective localizations.

+6
source

I would do this by localizing everything on the interface. Backend will send identifiers that client applications then translate into strings.

Note that in order to support multiple client applications, you may need to convert resx during the build phase in your assembly. It will create resource files in the format required by the client so that you can save a single translation source

Benefits:

  • the only source of translation for everyone is buttons, hints, etc. and error messages
  • formatting support - you may need to make some parts of the message bold / clickable / etc. that need to be executed on the interface
  • Validation only for clients - error messages for validation on the client side should be the same as server ones for the same error (if you have internal localization, you can duplicate some translations)
  • language agnostic testing is possible
  • language agnostic backend is possible - there is no need for a locale on the backend just for the sake of translation
  • in accordance with the general recommendation of localization as close to the client as possible
  • eliminates the incentive to do more backend translations in the future

Disadvantages:

  • translation of new errors is not possible. If the error was detected on the backend after the client applications were bundled, clients had to display a general message (but if necessary, a new error identifier can be displayed).
  • more complex union
0
source

Source: https://habr.com/ru/post/986773/

More articles:


All Articles