Thats planned for the new translation module since it's a long time voted need for rendering.
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 >> > >> > >> > >> > -- >> > 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 >> > _______________________________________________ > 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
