4

I have a software which logs various events into a database (SQLite). Currently the stored datas are :

  • Message
  • Date
  • Category
  • Criticality

The logs are written in the current software language. Which mean that the message :

User "admin" logged in

can become

L'utilisateur "admin" est connecté

if the software is in french.

That's perfect for the user, but sometimes users sends us their log file for analysis and it suddently become very complicated if it's a language that's nobody in the team can understand.

Which lead to my question , what strategy should we use to be able to display the logs in any language supported by our software independently of the original language ? knowing that :

  • Using a database is mandatory
  • The number of parameter in a logs message can go from 0 to a lot
  • The logs message should be understandable into the code
  • Exporting or displaying logs should be fast

Currently to write a logs message we are doing something like (C++)

std::string message = translate("User %s logged in"); // using Gettext
message = String::Format(message,userName);
LogsManager::Info(message);

Thanks

Edit The problematic is not to know if we should or not translate logs message but how to make them language independent. Meaning if user switch language during the use of the software ,messages should be displayed/exported in the current language and not in the previous one.

  • 2
    Possible duplicate of Is ok to leave untranslated advanced log? – gnat Feb 3 '17 at 14:00
  • I'd suggest using error codes, and then have something which checks their 'translation' in the currently used language – Orangesandlemons Feb 3 '17 at 14:21
  • I think the important part from the question linked by gnat is that the formatting should happen as late as possible – instead of writing the formatted message to the log database, write a message key plus any arguments (perhaps encoded as a JSON blob) into the DB. Create a simple log viewer that can view the database in a localized manner, and also give you the raw data for analysis. – amon Feb 3 '17 at 14:38
  • @Orangesandlemons: there are good reasons why one can decide to use error codes instead of error messages, but localization is not one of those. – Doc Brown Feb 3 '17 at 14:56
4

So you wrote you have

  • log messages in the database

  • as well as a log file which can be viewed and send per mail

That means there is a process from getting the messages out of the database into the file, for example, a button or menu feature Show Log (or at least, you could add such a feature).

The solution to your problem is to do the translation there, not earlier. Then the user can get a log file in his preferred language, and produce the same log file afterwards in a different language (for example, in english), before sending the log to you.

Of course, that will also mean you need to store

  • the english message templates in the database (instead of the final messages)
  • the parameters of each log message in the database (for this use case, one column with a comma separated aggregate of parameters will be sufficient).

So the logging table needs an additional column Parameters, and your logging code will look like this

  LogsManager::Info("User %s logged in", userName);

where the "Info" function has a variable parameter list, just like String::Format. The former calls to translate or String::Format should instead be moved to the "ShowLog" feature, and that feature then can get an additional option "output language".

We did something similar in a reporting tool where the input data was a complex XML file, containing a log section. The reports are produced in PDF, and the output language can be switched any time afterwards. All textual log messages are stored as templates + parameters, and get translated and combined as part of the PDF generation process - works like a charme.

  • Actually when i say that they send us a logfile , it's the database. But indeed the idea is to delay the translation and formating until display is needed. I'm just concerned by the performance. – grunk Feb 3 '17 at 14:42
  • 1
    @grunk I doubt that string formatting and looking up translations is likely to be a performance bottleneck. – amon Feb 3 '17 at 14:44
  • @grunk: honestly, why? Do you think one additional column, when storing log messages into the db, makes a big performance difference? You also gain a little bit of performance since template replacement and translation are done later, not immediately in your production code. – Doc Brown Feb 3 '17 at 14:49
  • That's not the column that i'm worried about but more the parsing/translation part which have to be done on potentially thousands of lines at once (we can export up to 10k logs line). It's faster to just dump the data into a file or into a list (for display) than to have to parse the paramters and format/translate the messages. But i guess it's worth it :) – grunk Feb 3 '17 at 15:11
  • If you save a message ID and the parameters, you can have a dictionary for each language and just merge then with parameters in an export simple process. It seems the same process of translate message to UI using resources files and parameters. – Pagotti Feb 3 '17 at 15:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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