Are we sure we want to drop the $msg binding in the future [1]? Compared to other services, $services.localization would be used heavily inside scripts and we would basically have 2 options: 1. use $services.localization.render('key') (you fall asleep writing this every time) 2. always declare a variable in your script like #set ($keys = $services.localization) and then do $keys.render('key') AFAIK, we have already considered in the past that a similarly used service like $services.model is already becoming a bit annoying having to write the oh-so-very-long "$services.model.createDocumentReference(wiki, space,name)"; do we want to get the same effect with the new localization module? I understand and agree that the new localization module is more powerful and flexible than the XWikiMessageTool, but I feel that those new features are not required in day to day use and unnecessarily crowd/pollute the regularly used API. This transition should IMO be smoother and with less impact than what is currently being proposed. If the new localization module can provide all the features of the XWikiMessageTool, then I propose that we simply reuse the $msg binding as it is and, in the background, transform XWikiMessageTool into a facade (as I see we have already pretty much done to preserve backwards compatibility), but agree that we *keep* $msg as the simplified translations binding, to be used in day to day operations and, for more complex tasks, the dev needs to use $services.localization instead. Basically, I`m proposing to apply the KIS(s) principle. :) WDYT? Thanks, Eduard ---------- [1] http://markmail.org/message/atrshzt3mlscfedc