AT:

• all hardcoded error messages in the backend are replaced with unique error codes for which entries are added to our localization files
• an API error reponse contains separate fields for:
  • errorCode to be used in the FE to localize the error message
  • errorMessage that reflects the fallback locale entry for the {errorCode}
  • and an optional non localized detailMessage field that is not used for user display purposes but rather serves API debug purposes providing detailed information on the error in English (the content will probably be the current message we often pass to the Exceptions on throwing)
• a german translation is provided

Hint:
This is a rather broad scoped task, as a first step we should identify error message classifications to separate runtime errors from actual user/usage related errors. For runtime errors a generic error message like "An unexpected error has occurred, please contact your administrator" would be suffice while for errors like OptimizeValidationException or OptimizeConflictException it's worth defining error codes for particular cases either by subclasses or by a parameter. We could split that work up into subtasks whenever feasible.

In the front-end we assign each label that needs to be translated a localization key, which is then, depending on the translation file, converted to right text. You can find the current translation files here.