Internationalization of api error messages on front end or back end?

Question

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

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

The error response can also contain optional list of field validation errors. The question is where should we do the translation of user error messages? Should the back end return already translated message based on request's locale or should the front end use the errorCode and it's i18n mechanism. We have i18n mechanisms both on back end (Spring i18n support) and front end (angular-translate).

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

Schizoid

Answer 1

I would do it by localizing everything on the frontend. Backend would send ids which client apps then translate to localized text.

Benefits:

• single source of translation for everything - buttons, tooltips etc and the error messages
• formatting support - you might need to make some parts of the message bold/clickable/etc which needs to be done on the frontend
• client-only validation - error messages for client side validation should be the same as the server side ones for the same error (with backend localization you might end up duplicating some translations)
• language agnostic testing is possible
• language agnostic backend is possible - no need for locale on the backend just for the sake of translation
• in sync with the general recommendation of localizing as close to the client as possible
• removes the incentive of doing more backend translations in future

Drawbacks:

• translation for new errors is not possible. If an error was defined on the backend after the client apps had been bundled, clients would need to display the generic message (but if necessary can display the new error id).
• more complex bundling

To support multiple client apps you might need resx transformation during bundling step in your build. It will create resource files in the format required by the client so you can keep a single source of translations

Heaney

I would add smaller payloads, in our setup the UI can change it's local on the fly so the back end doesn't know locale, it would have to send full translation for every language. – Pothunter

There are pros and cons to both approaches. See e.g. this answer for a backend opinion. – Melantha

4 years late to the party here, but @Heaney - when you say your backend should send IDs/codes to the front end, does that mean I need a dictionary I store somewhere on the front end that maps said IDs to their translatable strings? – Vashtivashtia

Answer 2

If I had to do this, I would have done it on the back end, primarily because since the backend has the locale, and is also generating the errors, it does make sense to expect localized errors from it. It would also de-couple the systems, such that, if there is any new feature/change done on the back end, and a new error is added, you do not need to release the front end piece just for the error.

Also, once this scales up, and you have multiple backend systems, the above approach just works well, since all the error generators are responsible for taking care of their respective localizations.

Rolf

This approach is good but the backend puts a restriction on the number of languages that the client can expect. If the client can rely on the error codes, it is free to use its own translation bundle and can use any language they desire. – Kiakiah

Answer 3

TLDR: If you have mobile clients - both (due to forward compatibilty)

Sometimes it is impossible to have a dictionary with all codes of errors in frontend, because of mobile clients. Some of mobile clients will never update your app. It means that backend may send new errors, which is not registered on client.

To build reliable apps, we should implement error-protocol with "forward compatibility". It means that clients should be able to recognize and show error message for those errors, which is not currently known.

This point leads us to "fallback messages". It means - all errors from backend should contain error and errorFallbackMessage for old clients. And the errorFallbackMessage should be localized (for example, based on Accept-Language header).

Dominican