Does it make sense to internationalize logs?

Question

What are the valid use case for internationalizing logs? Especially, are there any uses that make sense for a web application.

I'm working on converting the logging API used by a web application from log4j to slf4j, and noticed that the interface used to abstract over the log4j implementation supports internationalization; I also noticed that both log4j and slf4j support internationalization, which means it must be useful to someone.

Now, internationalization might be useful when programming a desktop application, in which the logs might be viewed by the end-user, but this logging facade is only used server-side for several web applications, by developers who are required to use English in general.

Answer 1

The answers given here are too bound to the developer point of view. However, software is made to be used (and read) by humans (users) whose most of them have no idea about debugging, log patterns, standards, etc...

Let's say we have a product that logs its activity at different levels. It's required the product to have a dashboard or control panel where users are able for monitoring the activity. In consequence, the log traces are required to be readable by users instead of developers or technicians.

Moreover, the users could be from different locations. What means, that logs date formats, numeric and currency symbols, etc should go accordingly with the user's location.

In such situation, why logs shouldn't be localised?

While it's true that logs should be machine readable, nothing prevents us from implementing a parallel logging process a little bit more user-friendly.

I agree with English being the standard language for logs. But all these kind of "standards" are De Facto Standard. So at this point, we have to be flexible.

That being said, if you find a good reason for using slog4j localisation feature, go ahead. It was made for a good reason.

One of these reasons could be that today's applications run on a worldwide context, and not everyone speaks/read/write your language (or English). Maybe, not even your product's helpdesk does.

Answer 2

When developers talk about "logs", they're most often referring to plain text files containing information that is meaningless outside the context of the specific code that logged them and has no intended purpose other than troubleshooting that code when something goes wrong.

When developers talk about "internationalization", they most often mean "when the user is a speaker of language X use the string translated to language X instead of the default string".

Given those specific definitions, internationalized logs are almost always a bad idea, because:

1. Usually, the set of languages that all of your developers can speak fluently is a lot smaller than the set of languages that any of your users might be native speakers in. Thus, if you internationalize logs, it's more likely than not that your developers will not be able to understand them.

2. Usually, most of your users are not active maintainers of the software they're using. Thus, your non-English-spekaing customers wouldn't be able to understand the logs even if they were internationalized, because most of the log messages will be about specific pieces of code and various implementation details they simply don't and shouldn't ever know about.

3. Internationalization of a message completely defeats the ability to do text searches for that message, be it developers searching their code or users searching the internet for workarounds.

4. Internationalization introduces the possibility of translation errors or subtle ambiguities, which are completely unacceptable in the context of software troubleshooting. It's the same problem as logging timestamps without an explicit timezone; you constantly have to waste time figuring out what it actually means.

---

Of course, if we relax those definitions and assumptions I started with, then there are some valid use cases.

In general, "internationalized logs" are potentially useful when there's an easily-identifiable subset of log messages which are meaningful to the average user, and when "internationalization" means a separate log in the user's language alongside the default language log for the developers.

In practice, if something you could call an "internationalized log" actually is useful, then it'll probably be a feature of the application anyway.

Some kinds of video games do this, particularly ones that behave like board games:

_{Source: Blood Bowl, screenshot taken from https://www.youtube.com/watch?v=UyQB4kDMZzE}

If the "logs" are considered extremely useful or a critical feature, they're more likely to end up in a proper database rather than mere text files. Sales tracking software is a typical example of this:

_{Source: http://www.everlogic.com/i-want-to/see-screenshots/}

Whether or not you would call these "logs", the text you see in these images is clearly something we'd want to internationalize if we were maintaining these problems.