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.

  • 2
  • 8
    Logs in a language other than english makes it harder to find help online, becausse it reduces the amount of matching results in Google. Commented Apr 22, 2016 at 17:12
  • 4
    I spend hours of my day using various filtering rules on logs. Obviously internationalizing the entries makes that much harder
    – user53141
    Commented Apr 22, 2016 at 18:28
  • I wonder if some people downvote when they actually mean "no, doing this is wrong"... That's not what downvoting is for :/
    – Andres F.
    Commented Dec 12, 2016 at 14:01
  • @AndresF. If your comment were attached to an answer, I'd strongly disagree with you, actually. While this question is indeed answerable, it is also on the opinion-based side of things. One downvote is not so bad.
    – jpaugh
    Commented Dec 12, 2016 at 16:07

2 Answers 2


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.

  • You make a good point. Using a logging framework to send (internationalized) messages to the end-user makes sense; why reinvent logging when it's already there?
    – jpaugh
    Commented Apr 23, 2016 at 12:23
  • 1
    I guess it's matter of customizations. We need/want an extra feature. But we often "reinvent the wheel" :-)
    – Laiv
    Commented Apr 23, 2016 at 12:29
  • 2
    I have a wheel, which I made myself. It is the best wheel, ever! It is shinier, rounder than any other. But, it does not fit on any existing car. I need to make a car to fit my wheel... ;-)
    – jpaugh
    Commented Apr 23, 2016 at 12:37

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:

enter image description here

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:

enter image description here

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.

  • You're coming from my perspective. But, reusing the existing logging API to send status messages to the user makes tons of sense, now that I think about it. It's easier to add internationalization to logging than to create a custom ad-hoc logger for the UI.
    – jpaugh
    Commented Apr 23, 2016 at 12:29
  • 1
    Imagine you have a bug that only happens in a version localized to Japanese. And your devs have added logging that would make it very easy to locate and fix the bug. Except your logging is in Japanese, and none of your devs can understand it :-(
    – gnasher729
    Commented Dec 12, 2016 at 21:31
  • No problem, tell me the error code and the input data that caused the error. :-)
    – Laiv
    Commented Dec 13, 2016 at 17:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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