In a past life, I was tasked with localization support for a product we were working on.
One of the major challenges was localizing error messages. Since the system was heterogeneous and packed with legacy code, there wasn't really a good way to get the org to adopt a framework for localizing the error strings that myriad backends would emit. So any localization we'd do would end up being some form of "heuristic-match the plain English representation of the error (the only representation we could assume every error supported) and transform it into a localized string."
But we eventually abandoned the task for a simple and very specific reason: someone brought us data that showed that most of our users figured out what to do about our error messages by querying StackOverflow, and we were therefore doing the users a disservice... Since SO can't language-translate one topic to another, we'd undesirably balkanize the aggregated knowledge space if we vended different users different error strings to plug in as search queries!
So for maximum usability, we settled on the surprising solution where much of our UI was localized, except for the error messages, which were intentionally kept in English for maximum concentration of search results.
If you want to avoid this problem in your org, my recommendation (from the position of pretending I was working in an ideal greenfield project with zero legacy code) would be to take the Microsoft-style approach of maintaining a global namespace of unique error code identifiers and emit those identifiers to the user along with ther plain-language error description. It's ugly and "computer-y," so you might get pushback from your UX team, but if you're going to support multiple languages, it provides a hook for services like StackOverflow (and other fora) to aggregate knowledge of an error across different human languages via a language-agnostic representation. At least until StackOverflow solves the hard problem of translating search queries so it can vend answers in a language-agnostic way, and I'm not going to hold my breath on that happening.
One of the major challenges was localizing error messages. Since the system was heterogeneous and packed with legacy code, there wasn't really a good way to get the org to adopt a framework for localizing the error strings that myriad backends would emit. So any localization we'd do would end up being some form of "heuristic-match the plain English representation of the error (the only representation we could assume every error supported) and transform it into a localized string."
But we eventually abandoned the task for a simple and very specific reason: someone brought us data that showed that most of our users figured out what to do about our error messages by querying StackOverflow, and we were therefore doing the users a disservice... Since SO can't language-translate one topic to another, we'd undesirably balkanize the aggregated knowledge space if we vended different users different error strings to plug in as search queries!
So for maximum usability, we settled on the surprising solution where much of our UI was localized, except for the error messages, which were intentionally kept in English for maximum concentration of search results.
If you want to avoid this problem in your org, my recommendation (from the position of pretending I was working in an ideal greenfield project with zero legacy code) would be to take the Microsoft-style approach of maintaining a global namespace of unique error code identifiers and emit those identifiers to the user along with ther plain-language error description. It's ugly and "computer-y," so you might get pushback from your UX team, but if you're going to support multiple languages, it provides a hook for services like StackOverflow (and other fora) to aggregate knowledge of an error across different human languages via a language-agnostic representation. At least until StackOverflow solves the hard problem of translating search queries so it can vend answers in a language-agnostic way, and I'm not going to hold my breath on that happening.