7

I have a rest api and a reactjs front end, in some cases, the api will send an error to the front end and I need to display that error. My app will support multiple languages, so the error must be translated, but what confuses me is how should I send that error so it can display the correct translation?

How should I do that? The back end should translate the error and send to the front end? The front end should get the error message and somehow translate it? Is there any pattern for this?

Improve this question

1 Answer 1

Reset to default
9

Error Codes

Essentially you need to mark every error with an error code, and that error code needs to have a language specific translation/format string.

The backend as such is unaware of language. Any error message generated alongside it is purely for internal consumption by dev and support.

Where the error code is translated into a consumer language specific error message depends on largely on taste.

  • It can be translated at the api layer. This requires that the server is aware of the language the user is using, which may not be knowledge that it has.
  • It can be translated at the client layer. This requires that the client have the full list of possible errors - which can be quite large and may require frequent updates.

I'd recommend two tables for translation.

  • The first table translates from source error code to a client error code.
  • The second table translates from client error code to human readable language text.

Don't forget to have a general error, error so that new errors added by devs always have some presentation for the user.

As Ralf Kleberhoff has pointed out below, the Error Code does not need to be an integer. It can for example be a short string.

eg: IRS_DISCOUNT_NOT_APPLICABLE

You don't even have to capitalise it as I did, but it is generally a good idea to have a naming convention.

Improve this answer
4
  • 2
    That's the way to go. And pay special attention to the "translates from source error code to a client error code" part, recalling the YAGNI principle. Probably, many internal error types can be mapped to one client error code.
    – Ralf Kleberhoff
    Jul 30, 2020 at 7:57
  • 1
    One more remark: error code doesn't necessarily mean an integer. A short symbol does the same job and is so much more readable when debugging.
    – Ralf Kleberhoff
    Jul 30, 2020 at 7:59
  • 1
    @RalfKleberhoff Very often, many internal error types should be mapped to one client error. And most errors fall into the categories "It didn't work, no idea how to fix it". "It didn't work, it might work in a few minutes". "It didn't work, call your administrator and send him the complete text of the error", and sometimes "It didn't work, follow these instructions to make it work".
    – gnasher729
    Jul 30, 2020 at 8:31
  • 1
    A possible translation option which keeps human-readable error strings out of both API and client would be to have a separate error translation service that takes a pair of (language_code, error_code) and returns a translated string. Such a service might even allow for more frequent updates than the backend, so changing error messages to be more helpful may be possible when deploying a new back-end or client is not an option.
    – Hans-Martin Mosner
    Jul 30, 2020 at 11:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.