This is why my company decided to go with a logging/messaging mechanism that stores messages by ID with parameters. We can get a log file from customers in France who see the error message in French, but we can read their log file in English because it's in a neutral format.
This isn't a panacea, as it means that there's a bit more work involved to integrate with tools like Splunk, and we obviously don't log to anything like syslog. But it makes it easier for our support people to support customers who prefer to see their messages in their native language.
It's sort of funny how that works; older computer systems only provided numeric error codes to save memory. Then Moore's Law caught up and we went for all-natural-language messages. But given the multilanguage problem, now it looks like it's actually more usable to provide numeric codes. (in addition to natural language)
On Windows, if you use the new manifest-based Event Log APIs, it will automatically translate Event Log messages for you based on the language (you provide the actual translations in the manifest of course, Event Log just knows how to decode the correct one). IT Admins who open up a log generated on a French-language machine will see the messages all in English, not French.
Why would your customers even need to see the log file? For general errors we have a language table that spits out the local copy to the screen. Common errors are translated (~100). Behind the scenes, the logs are in english for internal errors, and the language of the OS for everything else. We rely on .NET so exceptions are tied to the OS.
We have some older components that do spit out error codes. (like COMS, error -84413994005!) Sometimes the codes aren't specific at all and I have to install a debug version to get the information I need, or rely on a graybeard programmer to help me out.
These days programs are far too complex to rely on a limited set of error codes.
Our logs aren't just error messages; they're all sorts of messages that the user of our (backup) software may be interested in. I'm trying to figure out ways to reduce our messages so that our customers only see the details that they will really be interested in, but there is a large subset of our customers who want to be able to review how their backups went (and not just with the email summary that we send, which is generated from the log messages, BTW).
Our tracing facility, on the other hand, is purely English.
One helpful company could actually publish that language table, so that with a Polish message, you can find out what is the corresponding English message and use Google with that.
This isn't a panacea, as it means that there's a bit more work involved to integrate with tools like Splunk, and we obviously don't log to anything like syslog. But it makes it easier for our support people to support customers who prefer to see their messages in their native language.