I am working in a .NET environment where the system occasionally generates log entries for a customer. Messages are then appended to a customer log which can be reviewed at a later time.
For example, if a customer is subscribing to a new service, or a customer has a failed payment attempt, these messages gets appended to the customer log.
At the moment, all messages are hardcoded into the code, e.g ‘Customer failed to finish payment of XX’.
The problem is now that these messages need to be localized in a smart way, such that when a English user reviews the customer log, he gets the messages in English, and when a foreign user reviews the log, he gets them in his language.
What would be the best way to handle this scenario?
The problem you’ll run into is if you try to insert dynamic data into the messages in a conversational fashion. For example, if you have to write ‘No messages found’ vs. ‘One message found’ vs. ‘X messages found’ is problematic – in English we have different pluralities for zero, one, and more than one… but it’s not necessarily like that in other languages. Things like numbers or dates are less problematic to insert in String.Format form, but you don’t want to get in the business of trying to dynamically generate real language in a localized fashion.
I’d recommend following a pattern a lot like the Windows Event Log where you output an event ID, a localized message based on the event ID, and then capturing certain ‘fields’ where you’ll localize the field name and the display format of the field, like ‘Amount: $2.00’ or whatever. It may not be the prettiest way to go, but unless you’ve got a full-time linguist dedicated to this and you intend on accounting for all the little nuances of every language, I’d punt and go with a simpler log output format.
In your given example, you’d separate the log message from the data, like:
Customer failed to finish payment.
Amount: XX
You’d log a message ID, like ‘13579’ might be the unique ID for the event when a customer fails to finish a payment. Finally, you could store the value as a separate field.
How you go about figuring out how many fields to allocate to an event or how to store the data is… well, an exercise best left to the reader.