On Thu, Jan 31, 2013 at 10:18 AM, Eduard Moraru <[email protected]> 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 <[email protected]> wrote: > >> >> On Jan 16, 2013, at 10:37 AM, Thomas Mortagne <[email protected]> >> 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 >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
