Re: [xwiki-devs] [PROPOSAL] Automatic translations copy of renamed translation keys

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 <enygma2002(a)gmail.com> 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 > "(a)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 > deprecated.key=(a)new.key > > 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 <paul(a)hoplahup.net> 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 <paul(a)hoplahup.net> >> 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