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. I would lover, however, to see what tools are used that use the deprecation. paul _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
