Open osnard opened 6 years ago
Yeah good point. (And sigh at the design of this code)
Ideally this component would not need to deal with i18n at all, since that is a presentation layer concern. So yeah, having errors codes sounds good. I'd for for string error codes rather than numbers.
Error messages that can be accessed from
Processor::getErrors
come directly from the exceptions thrown byValueParser
s. Those messages are unlocalized and can not be used in the user interface.Would it be possible to make the emitted message customizable through the
ParamDefinition
? Or a least to have some error code, that can be mapped to an interface message by the client code?