On Mar 8, 2012, at 8:15 AM, Thomas Mortagne wrote: > Thats planned for the new translation module since it's a long time > voted need for rendering.
Yes it's a good idea that Thomas and I have discussed a few times already. It was mentioned on: http://xwiki.markmail.org/thread/v5sslam4fjmlpx73 Thanks -Vincent > > On Wed, Mar 7, 2012 at 6:59 PM, Eduard Moraru <[email protected]> wrote: >> Hi, >> >> I`m not entirely sure if this is relevant to the topic at hand or if a >> similar solution already exists, but since this is the best place for it, >> I`ll just say it here: >> >> Another cool option that Marius suggested, in an offline talk, would be to >> be able to reference translation keys inside a translation's value. >> >> One usecase when this would be very handy is when you create a livetable >> you have to specify your translation prefix for all the livetable, while >> you still would have liked to reuse action translations for things like >> "Delete", "Edit", etc. Instead of adding a new key in your translations >> that has the value "Delete", you could just say >> "@platform.index._actions.delete" and reuse an existing key. >> >> Back to the deprecation issue of renamed keys at hand, this would be useful >> as well because you would no longer need to carry the old translation's >> value and you could just do a: >> >> #@deprecated >> [email protected] >> >> This would be very easy to detect in the $msg code and to do a get to the >> referenced property instead. >> >> You could see this as an addition to what you have already >> proposed/implemented, and not a replacement. I think that, for some >> usecases, it will make the translations document smaller and less error >> prone. >> >> WDYT? >> >> Thanks, >> Eduard >> >> On Fri, Jan 20, 2012 at 6:34 PM, Paul Libbrecht <[email protected]> wrote: >> >>> This looks good to me, >>> >>> I would love to see the second proposal, maybe that'd be a GSOC project if >>> done really completely (including all the workflows, role definition, >>> disrupting/non-disrupting modes...). >>> >>> My +1. >>> >>> paul >>> >>> >>> >>> >>> Le 20 janv. 2012 à 11:41, Thomas Mortagne a écrit : >>> >>>> On Fri, Jan 20, 2012 at 10:24 AM, Paul Libbrecht <[email protected]> >>> wrote: >>>>> >>>>> Thomas, >>>>> >>>>> Le 19 janv. 2012 à 12:06, Thomas Mortagne a écrit : >>>>>>> A deprecation mechanism should be able to support the developer into >>> actualizing to the right keys, chosen from a finite set of suggestions (the >>> new keys). >>>>>> >>>>>> Examples would be nice ;) >>>>> >>>>> Think of redoing a part of "my blabla profile" where "my contributions" >>> are displayed so that it can speak to the third person when the user is not >>> the same: you'd start with a copy of the profile velocity views (pages, vm >>> files), then modify them progressively. >>>>> >>>>> The keys, maybe they were prefixed with "myblabla" would be refactored >>> to be either with "ownblaba" and "othersblabla". >>>>> Ideally, this should be done in one shot, so no real need of >>> deprecation, but I do not think this can be ensured. >>>>> >>>>>> Do you mean that the old key is refactored in severals ? In this cases >>>>>> as a key cannot contains a white space in Properties specs we could >>>>>> have: >>>>>> >>>>>> #@deprecated new.key.subname1 new.key.subname2 >>>>>> old.key.name=Default translation >>>>> >>>>> Fits me perfectly! >>>>> >>>>>>> The encoding is bound to the target usages and vice versa... >>>>>> Not sure I understand what you mean. >>>>> >>>>> that's philosophical: I meant we need to envision the usages to make >>> sure the knowledge representation is good engouh. >>>>> >>>>>>> The restricted view of a key-renaming appears to me as something that >>> could be easily automated leading to an automatic refactoring of the >>> sources. >>>>>>> Other deprecation mechanisms cannot be so: the deprecation without >>> replacement can only lead to a developer warning, the deprecation with >>> multiple alternatives can only lead to a warning with suggestion... >>>>>> >>>>>> Sure it's hard to automate translation copy to the new key when there >>>>>> is 0 or more that one new keys. Do you mean that we need a syntax >>>>>> advanced enough to explain to the l10n wiki or any other tool how to >>>>>> cut the key in peaces to put it in the right keys ? >>>>> >>>>> I did mean this indeed. >>>>> >>>>>>> I'm just trying to see the big picture of the future before settling >>> on the knowledge representation... >>>>>> >>>>>> Sure, that's why this proposal is for: make sure we go in the right >>>>>> direction. But does not mean we have to do everything at once, just >>>>>> that we need to make sure we don't block the future ;) >>>>> >>>>> We're on the same wavelength. >>>>> >>>>> I think at this point, considering all the cases we've considered, I >>> can say: >>>>> >>>>> +1. >>>> >>>> Ok thanks. >>>> >>>> I will go for >>>> >>>> #@deprecated new.key.subname1 new.key.subname2 >>>> old.key.name=Default translation >>>> >>>> as first implementation. >>>> >>>> I will also make sure of the following: >>>> * the type of syntax is indicated by a {syntaxid} at the beginning, >>>> default being a list of new keys >>>> * skip unknown syntax type without complaining. So it allows a large >>>> choice of syntaxes to extend the current syntax without breaking >>>> anything. >>>> >>>> For example: >>>> >>>> #@deprecated {regexp} match="(.*) and (.*)" new.key.subname1=1 >>>> new.key.subname2=2 >>>> old.key.name=Default translation >>>> >>>> WDYT ? >>>> >>>>> >>>>> I would lover, however, to see what tools are used that use the >>> deprecation. >>>> >>>> As I said the first one will be l10n wiki: the goal is to make sure we >>>> don't loose translation assigned to the old key when renaming it. When >>>> l10n import the default language and see a new deprecated key it's >>>> going to copy the translations assigned t the old key on the new key >>>> so that when you export again translation from l10n wiki all the >>>> translations are now both on the old and new key. >>>> >>>> On XWiki itself we can imagine printing warning indicating which key >>>> to use instead when some code try to get deprecated key translation >>>> and even get the translation from the new key instead. >>>> >>>>> >>>>> paul _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
