On Thu, Jan 19, 2012 at 11:36 AM, Paul Libbrecht <[email protected]> wrote: > Thomas, > > > Le 19 janv. 2012 à 10:57, Thomas Mortagne a écrit : >>> I'm surprised, though, that you have the renaming scenario in mind only, it >>> is rarely needed while the "fuzzy renaming" is quite often needed to my >>> experience. >> >> It's not the only thing I have in mind, it's the only thing I plan to >> do shortly because me have a need for it right now: most of the XE >> translation keys are going to be renamed while we move the page to >> separate applications. > > That's clear to me. > >> What do you mean by "fuzzy renaming" ? > > It happens more often than it should that some message translations usages > need to be refactored to the usage of different keys because of their > environment (in this section, one should say it this way, in this section one > should say it that way). > 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 ;) 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 > >>> What is the flow of deprecation, how would a developer or tester be warned >>> of a deprecated message? >> >> This is not going to change, the current rule is that when you need to >> rename a translation key you move the old one in a deprecation section >> of the translation file and we are supposed to remove the key when >> it's not used anymore in any active branch (we actually forgot to >> remove lots of older translations when deleting branches). >> >> The proposal here is not about how do we deprecate translations, I >> just want to propose a syntax to indicate what is the new name of a >> deprecated translations which is not a new concept itself. > > The encoding is bound to the target usages and vice versa... Not sure I understand what you mean. > > 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'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 ;) > > 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
