MSC4176: Translatable Errors #4176
Conversation
turt2live
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- Server
- Client (to demonstrate interest/need)
| This could potentially be an undesirable feature. Users could instead prefer to have `error` simply | ||
| use their language. | ||
|
|
||
| ## Alternatives |
There was a problem hiding this comment.
Is having more specific errcode values another alternative?
There was a problem hiding this comment.
For some use cases, yes. I'm expecting to publish an MSC soon which uses translatable errors, but a more specific error code would not help.
(sorry, that future MSC's content is a bit sensitive, so avoiding direct mentions for the moment)
There was a problem hiding this comment.
@ara4n says (in context of the whole MSC):
I'm dubious about this. The original intention for these error codes is that the client would expand them out clientside - if anything, shouldn't we be providing structured errors (like structured logging) to do so? Worst case, folks could optionally implement Accept-Language in order to internationalise the errors on the server, but do we really want servers to have to sprout a translation framework, and then get out of sync with the supported translations on the client; etc? It feels much cleaner for the client to worry entirely about the presentation problem of i18n.
There was a problem hiding this comment.
@ara4n says (in context of the whole MSC):
I'm dubious about this. The original intention for these error codes is that the client would expand them out clientside - if anything, shouldn't we be providing structured errors (like structured logging) to do so? Worst case, folks could optionally implement Accept-Language in order to internationalise the errors on the server, but do we really want servers to have to sprout a translation framework, and then get out of sync with the supported translations on the client; etc? It feels much cleaner for the client to worry entirely about the presentation problem of i18n.
the thing with that is that errors currently are server defined freetext often as so many things are just "M_UNKNOWN". Making it really annoying to error handle that. So the current way isnt feasible. Though I agree that lets say a 1MB overhead on every response also feels wrong if it were a dict of possible translations or having "non deterministic" responses across endpoints. Especially as it would be kinda annoying to get an error report with errors in russian when you dont speak it.
There was a problem hiding this comment.
IMO the truly correct and hygienic answer here is to identify every place where the existing M_ error codes are insufficient and define proper error codes for every single one of them.
Presentation of those well-known errors should be the responsibility of clients. Perhaps at some point some centrally agreed translations of those error codes can be provided open-source to all client authors, but it definitely shouldn't be down to the server to dictate what those are.
It's already a pretty horrible layering violation that server-dictated errors are surfaced directly to the user like this and server-side translations would just cement this mistake into place rather than address it.
The only time M_UNKNOWN with freeform text should happen is if the server needs to surface an error that is actually specific to the implementation and not to spec-driven behaviour, i.e. a database connection or transaction error that can't be translated, for example.
|
|
||
| ## Alternatives | ||
|
|
||
| Request headers may give hints as to what language the user/client prefers, and could be used to |
There was a problem hiding this comment.
Accept-Language seems like an appropriate header for this use.
|
|
||
| ## Alternatives | ||
|
|
||
| Request headers may give hints as to what language the user/client prefers, and could be used to |
There was a problem hiding this comment.
Another Alternative could be an optional query Parameter for the requests. Not the prettiest since it would have to be everywhere(ish) but it's also a thing I have seen elsewhere before.
| Servers might end up incorporating relatively complex translation frameworks, or require extensive | ||
| changes to support multiple written languages. | ||
|
|
||
| This could potentially be an undesirable feature. Users could instead prefer to have `error` simply |
There was a problem hiding this comment.
I'd be a bit concerned it's going to increase the per-request (for a given amount of errors in a clients session) footprint by quite a bit. I'd be tempted to say that if your client provides an Accept-Language header then we should populate messages with that (and keep the original error as English for backwards compat). If the server doesn't support any langauges suggested by your client then it falls back to English via just providing error.
My understanding is the header usage is fairly widespread?
Rendered
In line with matrix-org/matrix-spec#1700, the following disclosure applies:
I am Director of Standards Development at The Matrix.org Foundation C.I.C., Matrix Spec Core Team (SCT) member, employed by Element, and operate the t2bot.io service. This proposal is written and published as a Trust & Safety team member allocated in full to the Foundation.