7 Mar
2012
7 Mar
'12
6:59 p.m.
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 :
deprecation.
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
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.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
paul
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs