If I am localizing a piece of software that uses an external API, how should I handle error messages that originate in this API? I do not control the API, I only consume it. The error responses are not very structured: some contain error codes, some contain verbose details in the text, others almost nothing. Some errors can be fixed by the user (incorrect configuration), some are caused by the external service (server overload), some could be caused by a bug in my software (of course, this would be very unlikely...).

I would like to provide a smooth experience to my end-users, so they know what went wrong and what they can do to fix it. What is the best strategy to use here?

(This is a generalization of a question from the WordPress Stack Exchange. I thought it would be worth re-asking here, because it is not limited to WordPress plugins.)

1 Answer 1


You're looking for the Adapter Pattern. I always wrap an external API otherwise it leaks into the rest of the application (your problem with error codes is a good example).

  • One caveat is that the error messages of the API could improve over time. So maybe now I get the same string "Error" for five different types of errors, and can only map this to "Unspecified error in the API". If they later change this to include more detailed information, how should I structure my adapter so that my application does not hide this info?
    – Jan Fabry
    Mar 1, 2011 at 14:09
  • @Jan - first, make the translation data driven. You could have a list of pairs of (regular expression, translation). That will make it easy for you to change the translation when the API changes. Also, I would not completely hide the underlying error message from the user; I would display the explanatory text, and also the original message. Mar 1, 2011 at 14:53
  • @kevin: (regex, translation) or (regex, translatable_string)? I would think the latter, so you don't have different regexes per language you translate to?
    – Jan Fabry
    Mar 1, 2011 at 15:09
  • Messages from an API are not usually what you'd want to display to the user. What you'd probably want to do is check for errors from your calls into the API and create a message that makes sense to your users. For example if you get an error authenticating with the web service make a message stating that effect. Again, relying on the errors from the API for display purposes is a leaky abstraction. Mar 1, 2011 at 17:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.