15 Mar
2013
15 Mar
'13
2:27 p.m.
You seems to forget an important thing here: it's not all about
velocity. We used to have to use velocity to display translations but
it's not true anymore and you should always use the macro as much as
possible because it's a lot safer and also a bit better for
performances.
On Fri, Mar 15, 2013 at 2:23 PM, Eduard Moraru <enygma2002(a)gmail.com> wrote:
The proposal about XWikiMessageTool was just a thought
on how we could
preserve the current behaviour.
Practically, there are 2 main aspects to consider:
1) Ease of use:
Internationalization is a key aspect in the platform, not just another
service that may or may not be important, so I think that in the past, when
using $msg, it was given the proper importance and ease of use. We must not
lose that to flexibility.
Also, consider the fact that non-technical users are already confused by
the $msg.get() calls in a document's title and content, seeing a longer
technical string won't help them much.
Scripting also needs to be quick an fun. Over-engineering it throws people
away.
2) Semantics:
I am not fond of the render() method when it concerns translation keys. I,
as a regular dev that wants to script something, do not care about the fact
that the XDOM is involved and that the translation is first retrieved and
then rendered and all that mumbo-jumbo. For me, a translation is something
that is retrieved by providing a key, in a more or less Map(/Hashtable)
oriented manner, with a get() action. I understand that when you add
translation parameters and choices in the translation's content things
could get a bit funkier, but IMO we don`t need to get that technical for no
reason. IMO render is a bit confusing and, since a "public Translation
get(String key)" method exists on the service, it will be the cause for
many useless errors.
Anyway, these are my concerns. If they are not shared, then I guess we`ll
just let time decide if they were justified or not.
Thanks,
Eduard
On Fri, Mar 15, 2013 at 3:00 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
--
Thomas Mortagne
On Fri, Mar 15, 2013 at 1:45 PM, Vincent Massol
<vincent(a)massol.net>
wrote:
accepted. My proposal was: $services.l10n
I don't exactly see that in http://markmail.org/message/mv7psxctupfjkcu2;)
key="…"/}}
features
binding name
and here you start to say that you want to go back to
XWikiMessageTool?
reuse
"script service alias") but in xwikivars.vm add a velocity variable named
$l10n:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs Hi,
On Mar 15, 2013, at 1:21 PM, Eduard Moraru <enygma2002(a)gmail.com> wrote:
about $msg but about all bindings. If we allow "shortcut aliases for
bindings" we need to make this general and allow any services binding to
offer shortcuts.
Are we sure we want to drop the $msg binding in
the future [1]?
IMO yes, for consistency, but it's a good question to ask. It's not just
One reason we introduced $services was to keep the xcontext namespace
free for
applications to use.
s/xcontext/script context/
The idea was to keep the script bindings at a minimum so that it's not
a nightmare to find names for variables you want to use in your
script.
Compared to other services,
$services.localization would be used heavily
I had personally proposed "l10n" to make it a bit shorter but it wasn't
> 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')
3. Use the translation macro if you're in wiki pages: {{translation
> 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?
@Edy, we really need to commit the auto completion feature ;)
> I understand and agree that the new localization module is more powerful
> and flexible than the XWikiMessageTool, but I feel that those new are not
required in day to day use and unnecessarily crowd/pollute the
regularly used API.
You're loosing me here. I thought you were only talking about the This transition should IMO be smoother
Smoother than what?
> 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 > 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.
I don't understand what you mean. If your idea is to get $msg.get()
rather
than $msg.render() which is the new API then I don't agree. If what
you propose is just to have a generic "script service alias" notion where
$msg would be the same as $services.localization then I'm more inclined to
think about it :)
BTW I would not want to reuse the same name ($msg) because it's
misleading.
Basically, I`m proposing to apply the KIS(s)
principle. :)
Another option is to not change anything at the level of java (i.e. no #set ($l10n = $services.localization)
This is basically your option 2) above but made generic by putting it in
xwikivars.vm.
Thanks
-Vincent
If your "proposal" if to keep XWikiMessageTool it's a big -1 for me,
it simply does not make any sense.
I'm OK to vote some shortcut binding for $services.localization but that's
it.
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
WDYT?
Thanks,
Eduard
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs