20 Jan
2012
20 Jan
'12
11:41 a.m.
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 :
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.
that's philosophical: I meant we need to envision the usages to make sure the
knowledge representation is good engouh.
I did mean this indeed.
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 ?
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
Fits me perfectly!
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 ;)
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne