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