On Thu, Jan 31, 2013 at 10:18 AM, Eduard Moraru <enygma2002(a)gmail.com> wrote:
  See point "5. Thy log shalt be written in
English" in this "logging how to"
 [1]
 I`d be +0.5 for option 2) only because it allows the DW UI to choose if it
 wants the translated version of the log, but it leaves all the other
 logging events untouched. We`re barely internationalizing our UI, I would
 not want to see an effort towards translating logs :)
 I understand the need of DW, but maybe we can establish a certain level at
 which these translated logs are application (DW) specific messages and not
 raw logs that any involved component or dependency spits out. So maybe we
 can consider the log messages from various components as technical details
 (in english) and DW-specific forkflow(/error) messages as
 internationalizable and displayable to the user interface. Is this not
 possible? 
This is the whole point of 2), nobody is forced to provide a
translation key, it's totally optional and we don't even introduce any
new API. This mail is not about introduce a rule to always provide a
translation key with a log, I just want that we agree on how to make
some log translatable.
 Regarding the general topic of translating generic logs, I`m -0, close to
 -1.
 Thanks,
 Eduard
 ----------
 [1] 
http://www.masterzen.fr/2013/01/13/the-10-commandments-of-logging/
 On Wed, Jan 16, 2013 at 7:16 PM, Vincent Massol <vincent(a)massol.net> wrote:
 On Jan 16, 2013, at 10:37 AM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
 wrote:
  Hi devs,
 A missing peace of Extension Manager UI is the fact that the log
 associated to a task is not translatable right now. So I'm working on
 making easy to translation log in general since that's actually what
 EM is displaying: just plain standard slf4j log (see
 
http://jira.xwiki.org/browse/XCOMMONS-304).
 = Possibilities =
 Here are several possibilities:
 1) translate the message before giving it to the log event, so it's up
 to the log producer to translation its log based on the context
 language
 2) provide an additional translation key along with what will now be
 the default message when logging
 3) generate a translation key based on the default message
 Here is what I think of those:
 1) is a bit better for the user than the current situation but not
 that much, instead of behind stuck with english he will be stuck with
 another language with stored logs. It also make anyone that produce
 log depends on many things to actually translate that message so it's
 a -1 for me
 3) sounds very fragile
 = The actual proposal =
 Here is a detailed proposal for 2):
 The idea would be to pass the translation key using slf4j Marker API.
 We introduce a TranslationMarker which implements Marker and is passed
 with the log when you want to associated a translation key to a log.
 Here is an example:
 producer (for example the install job):
 ""
 logger.error(TranslationMarker.getMarker("some.translation.key"), "A
 default error message generally in english with a [{}]", "parameter",
 exception)
 ""
 displayer (for example the Extension Manager UI, should be a logging
 module UI element btw reused by Extension Manager ;)):
 ""
 #set($translationKey = $logEvent.marker.translationKey)
 ""
 WDYT ? 
 So it would be up to the user of the log to generate the translation based
 on the key it retrieves?
 Is it not interesting to have LogEvent.getMessage to return the translated
 message (it would check if a TranslationMarker exists and if so it would
 get the translation)?
 Alternatively we could provide a getTranslatedMessage() API too.
 +1 for 2) in general.
 Thanks
 -Vincent
 _______________________________________________
 devs mailing list
 devs(a)xwiki.org
 
http://lists.xwiki.org/mailman/listinfo/devs
  _______________________________________________
 devs mailing list
 devs(a)xwiki.org
 
http://lists.xwiki.org/mailman/listinfo/devs 
--
Thomas Mortagne