19 Jan
2012
19 Jan
'12
12:06 p.m.
On Thu, Jan 19, 2012 at 11:36 AM, Paul Libbrecht <paul(a)hoplahup.net> wrote:
The encoding is bound to the target usages and vice versa...
Not sure I understand what you mean.
Thomas,
Le 19 janv. 2012 à 10:57, Thomas Mortagne a écrit :
That's clear to me.
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
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. 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 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne