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 > > > > -- > Thomas Mortagne > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
