On Mar 15, 2013, at 2:23 PM, Eduard Moraru <[email protected]> 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. Again that's why we have the translation macro… > Scripting also needs to be quick an fun. Over-engineering it throws people > away. I wouldn't call clear variable naming over-engineering... > 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. TBH I was also a bit thrown off by the render() method when I saw it. Thanks -Vincent > 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 > <[email protected]>wrote: > >> On Fri, Mar 15, 2013 at 1:45 PM, Vincent Massol <[email protected]> >> wrote: >>> Hi, >>> >>> On Mar 15, 2013, at 1:21 PM, Eduard Moraru <[email protected]> wrote: >>> >>>> 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 >> 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. >>> >>> 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 >> accepted. My proposal was: $services.l10n >> >> I don't exactly see that in http://markmail.org/message/mv7psxctupfjkcu2;) >> >>> >>>> 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 >> 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? >>> >>> @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 >> features >>>> 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 >> binding name and here you start to say that you want to go back to >> XWikiMessageTool? >>> >>>> 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 >> 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. >>> >>> 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 >> "script service alias") but in xwikivars.vm add a velocity variable named >> $l10n: >>> #set ($l10n = $services.localization) >>> >>> This is basically your option 2) above but made generic by putting it in >> xwikivars.vm. >>> >>> Thanks >>> -Vincent >>> >>>> WDYT? >>>> >>>> Thanks, >>>> Eduard _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
