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). >> 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... 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... I'm just trying to see the big picture of the future before settling on the knowledge representation... paul _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
