the best approaches for logging localization using c++

Question

I am working on a multinational project where target audience for logs might be from two nationalities. Therefore it is becoming important to log in more than one language , I am thinking about writing to 2 different log folders based on language every time I am logging something, but I am also wondering if there's some out of the box functionality that is coming along with logging frameworks like log4cpp?

Logs are for developers and they should be in English. That will save you work when someone who don't understand the other language would have to debug a problem. — Rafał Rawicki, Apr 03 '12 at 04:55
@RafałRawicki perhaps there are many groups of developers who want to look at the logs — Preet Kukreti, Apr 03 '12 at 04:56
@RafałRawicki: my experience forcing everyone to use English in a team where nobody's first language was English taught me that uniformity is not worth sacrificing communication. Use whatever language the team knows best. Besides, many applications, including web servers, provide logging facilities for end-users (e.g. the system admin) whose first language might not be universally English. — André Caron, Apr 03 '12 at 05:03
in our system logs are for technicians and maintenance staff, it's not guaranteed that they will always know english, companies who are involved in this project speak two different european languages. until product stabilizes mostly our technicians will support the system, after it's stabilized customers tech staff will support it, that makes me think I might need 3 different log files... — erin c, Apr 03 '12 at 05:20
@AndréCaron: It may not only depend on your team. Communication with other teams is important too so (for logs) it's at least a company-wise decision if you want any help in your investigations. It's hard to stay away from English. Now, for internal communication *within* the team, things are different. — Matthieu M., Apr 03 '12 at 06:23
@MatthieuM.: take "team" to mean "organization" or "companby". It's just that I've worked for a Japanese company where one of the larger (and standalone) teams was composed of mostly Japanese people who didn't speak English. However, they forced each other to write code, comments and commit logs in English following the same reasoning as Rafal's. The result was that they couln't understand each other's comments and commit logs and native English speakers like myself couldn't understand the crap they wrote either. — André Caron, Apr 03 '12 at 14:46
@MatthieuM.: **TL; DR**: we're saying the same thing. The language of choice for logging is a company decision, and English is definitely not always the best choice. — André Caron, Apr 03 '12 at 14:47

score 2 · Accepted Answer · answered Apr 03 '12 at 15:40

As other commenters have mentioned, it sounds like you are going down the wrong track by looking to do multilingual logging.

My recommendation would be to use English (which is the standard for technical information, and which I guess is the language you know best) and to make sure that the language you use is clear, grammatically correct and unambiguous. Then if one of the technicians cannot understand it, they can very easily and efficiently run it through a machine translation engine such as Google Translate. Or indeed they could process the logs and run everything through Google Translate to append translated text, particularly if you annotate the logs to mark the language content.

Assuming that the input language is well-written, machine transation usually gives a good result which the end user can understand. If the message isn't clear, has typos or abbreviations, then that's where machine translation fails spectacularly.

I would add one further point to this answer. Give each log message a unique ID. That way, even if you do not understand the log message, you can be 100% certain that you have identified the line of code that generated the log entry. — Michael Shaw, Oct 02 '13 at 14:20

score 0 · Answer 2 · answered Apr 03 '12 at 05:27

Writing log naturally brings down the speed of execution due to file open, seek and write operations involved as part of it.

This is one primary reason why many developer and architects suggest to write log at different levels.Increasing the depth of log entries as level increases to trace down the problems better. At higher level, you will notice that your process speed drops due to more log entries getting generated.

Rather suggest you to use services that can translate from one language to other. I'm sure there are libraries free or paid which does this translation. You can create a small utility program that runs in the background and does this conversion during process idle time.

score 0 · Answer 3 · answered Apr 03 '12 at 07:22

Well one suggestion is you can use a different process/thread which listens for your log messages, which you can log it from there ..

This reduces I/O logging time in your main process/thread and you can make all changes related to Logging language over there..

For multi - Lingual support I think you can try writing with widechar string .. though I am not sure..

SigTerm · Answer 4 · 2012-04-03T16:33:38.803

the best approaches for logging localization using c++

Install Qt 4 and use QObject::tr/ tr() macro for strings. Write strings in whatever language you want. Hire/Get a translator to localize strings using QT Linguist.

Please note that perfect translation is impossible, so there will be many "amusing" misunderstandings, even if your translator is a genius. So it might be a better idea to select main language for programming team.

--EDIT--

Didn't notice this part before:

in more than one language

One way to approach it is to implement log reader. Instead of writing plaintext messages, you could dump message ids (generated by some kind of macros) and string arguments if strings are formatted. "Log reader" will allow user to select desired language while viewing log file, and translate messages based on their ids/arguments using mechanism similar to QTranslator. The good thing about this approach is that you'll be able to add more languages later - so it'll be possible to retranslate old logs. The bad thing is that this format will be harder to read for "normal human", although you can add plaintext messages in addition to message ids and arguments and you'll need to write log viewer.

Qt 4 has most of this framework implemented (there are routines for dumping variants into text/data streams, and so on) along with translation tool. See QTranslator documentation and Linguist manual for more info.

If you are talking about localizing the log messages, then you'd get one language in the logs, not both. The OP is asking about how to log so that messages in both languages are available. — Clafou, Apr 03 '12 at 15:28

the best approaches for logging localization using c++

4 Answers4