Field ids are not (necessarily, especially when doing localization) something shown in the UI. The point made by the original commenter is that a field in the error should refer directly to which field has an issue. It does, via an id that happens to be "email". It's still up to the clients to decide how to represent that to the user, but they're given a distinct field rather than needing to infer which field an error code refers to.
(While the comment I replied to can be read differently, I assume we all know that changing actual field names (in APIs) depending on localization is nuts)
No doubt they exist, but I’ve never seen an api that localised identifiers.
My view is that apis should simply return a number when an error occurs. The vendor should supply a list of error codes to its consumers, translated into as many languages as necessary. The developers who are consuming the api can then determine how best to present the error to its end users. A set of error numbers is tied to the version of the api that is being consumed so there should be no surprises.
In other words, if a set of people don't understand the message, make sure that no one understands the message (not even the people that normally just press the Google Translate button).
Is that what you're saying? Or did I misunderstand you?
You need codes because the field isn't going to be 'email' for much longer than it takes for your management to realize that people outside of the US also have wallets.