There needs to be clarity which party is expected to translate the message. Leaving this undefined can lead to problems in practice.
a) If both client and server try to translate, it can cause chaos.
b) Generic usage of a third party server API - which is the goal of an IETF spec - means that the client cannot possibly know all the error types.
c) Even if all error types were known, all clients would need to translate the same strings
d) The server may need to add new error types at any time.
(See also next point 4 for importance.)
Current spec: "title" is defined as a short, human-readable summary of the problem type, and "detail" is defined as human-readable explanation specific to this occurrence of the problem. It allows localization of "title" by stating it SHOULD NOT change..., except for localization, but it's only an allowance.
Implication: Therefore, a client cannot rely on the error messages to be useful for the user. Given that for many errors, the only possible recourse is to show the error to the end user, translation is a real world problem. The client needs to rely on the error string to be useful for the user.
Recommendation:
If error strings are translated at all, it is expected that the localization happens on the server side
and the server sends localized strings for "type", "detail" and custom fields, based on the
"Accept-Language:" HTTP header sent by the client.
Rationale: The server is better suited to perform language-specific variable insertion in the "detail" field.
It allows for processing of errors from generic third party servers, and allows the server to add new
error types without prior arranging with the client.
There needs to be clarity which party is expected to translate the message. Leaving this undefined can lead to problems in practice.
a) If both client and server try to translate, it can cause chaos. b) Generic usage of a third party server API - which is the goal of an IETF spec - means that the client cannot possibly know all the error types. c) Even if all error types were known, all clients would need to translate the same strings d) The server may need to add new error types at any time. (See also next point 4 for importance.)
Current spec: "title" is defined as
a short, human-readable summary of the problem type, and "detail" is defined ashuman-readable explanation specific to this occurrence of the problem. It allows localization of "title" by statingit SHOULD NOT change..., except for localization, but it's only an allowance.Implication: Therefore, a client cannot rely on the error messages to be useful for the user. Given that for many errors, the only possible recourse is to show the error to the end user, translation is a real world problem. The client needs to rely on the error string to be useful for the user.
Recommendation: