Language Dependency 

Use

The language dependency is an issue mainly for log messages, which are related to specific logical areas. These messages are mostly to be read by administrators, end-user support groups, consulting groups, and so on, for diagnosing application problems at runtime. Therefore, except for the meaningful text that must be logged, a message translation mechanism must also be supported since the application can be deployed worldwide.

ResourceBundle

The SAP Logging API supports language dependency with the use of the ResourceBundle (java.util.ResourceBundle) provided in Java. The basic concept is that the message text, logged by the user in his/her application, is “neutral”. It is similar to a message code/ID. A resource bundle file for each language exists to map the message code to the text of the respective language. During the application runtime, the resource bundle file is monitored.

As a result, the message text is translated and localized.

More APIs

A few more output methods API exist under the Category class, which are used to enable the translation feature for the log messages. These do not appear under the Location class.

Before using these additional output methods to enable translation, make sure you have read the Section output methods descriptions.

More information: Enable Output Messages .

Basically, these methods:

●      have identical corresponding method names, but end without a ‘T’.

●      replace the “String message” argument with the “Object msgCode” one.

The table below shows a few commonly used methods, compared with the ones previously presented.

Common Output API with Support of Translation

Category  (‘xxxx’ stands for the severity level)	Translation supported
xxxxT(Location loc, String message)	xxxx(Location loc, Object msgCode)
xxxxT(Location loc, String subloc,           String message)	xxxx(Location loc, String subloc,          Object msgCode)
xxxxT(Location loc,          String message, Object[] args)	xxxx(Location loc,        Object msgCode, Object[] args)
xxxxT(Location loc, String subloc,           String message, Object[] args)	xxxx(Location loc, String subloc,          Object msgCode, Object[] args)
logT(int severity, Location loc, String message)	log(int severity, Location loc, Object msgCode)
logT(int severity, Location loc, String subloc,         String message)	log(int severity, Location loc, String subloc,       Object msgCode)
logT(int severity, Location loc, String message,         Object[] args)	log(int severity, Location loc, Object msgCode,         Object[] args)
logT(int severity, Location loc, String subloc,         String  message, Object[] args)	log(int severity, Location loc, String subloc,         Object msgCode, Object[] args)

 

MsgCode is the message ID specified in the resource bundle.

If there are two resource files, the transactions will be similar to the one below. In this example, the MsgCode is specified in the left column.

(1) DBProblem         = Problem with Database. ProcessCanceled   = Process {0} canceled. WrongColor        = Wrong Color: {0}. (2) DBProblem      = Problem with Database. ProcessCanceled   = Process {0} cancelled. WrongColor     = Wrong Colour: {0}.

In the application, the code is turned into:

_cat.error(_loc, "ProcessCanceled");

 

At runtime, depending on the specified locale (or the default locale of the platform), the output is either:

Process #### canceled.

or,

Process #### cancelled.

 

Invalid Translation

If the MsgCode is invalid, a MissingResourceException is thrown. In this case, the exception is caught and logged by the logging framework itself without jeopardizing the flow of the application. The value string of MsgCode itself is used as the translated string. This is the best substitute in this situation.

More information: Administrative Issues.

You can also specify a meaningful message string as a backup to get around with the invalid MsgCode problem. In that case, the logging framework does not need to guess a substitute value, and this backup string can provide a more meaningful message (although non-translated), than the MsgCode. This option is supported by the use of an additional argument MsgClear.

Note, that the same set of method APIs is overloaded again with this additional argument.

This is a fallback option applied only in cases when the use of MsgCode is not consistent. When the MsgClear argument is available, its value always exists in parallel with the MsgCode. This option becomes useful when log viewers are involved.

In most cases, the assumption is that MsgCode is used by the log viewer and the translation is done at the time of viewing whenever the MsgCode is valid. Otherwise, the MsgClear can be used as a backup.

Fallback Supported

xxxx(Location loc, Object msgCode, String msgClear)

xxxx(Location loc, String subloc, Object msgCode, String msgClear)

xxxx(Location loc, Object msgCode, Object[] args, String msgClear)

xxxx(Location loc, String subloc, Object msgCode, Object[] args, String msgClear)

Log(int severity, Location loc, Object msgCode, String msgClear)

Log(int severity, Location loc, String subloc, Object msgCode, String msgClear)

Log(int severity, Location loc, Object msgCode, Object[] args, String msgClear)

Log(int severity, Location loc, String subloc, Object msgCode, Object[] args, String msgClear)