--- Comment #8 from andré <and...@laposte.net> ---
(In reply to Brad Jorsch from comment #6)
> (In reply to andré from comment #4)
> > > *** This bug has been marked as a duplicate of bug 7865 ***
> > Not appropriate, for a very old bug rejected for circumstances which likely
> > have changed.
> Circumstances have in fact changed.
> However, they've changed such that closing this as anything other than
> WONTFIX is even more unlikely: VisualEditor and Parsoid require the ability
> to reparse fragments of the page and then merge the new HTML into the
> previously-rendered HTML, meaning that new wikitext that affects other parts
> of the page will not be added (and it's even difficult to fix bugs in Cite
> due to this issue).
So you are saying that problems with the implementation of these new features
interfere with this extension ?
I don't understand.
I'm assuming that all this extension does is scan the page, taking the variable
definitions and replacing all instances using the defined variables, before any
other parsing of the page. The result is a page that shows no evidence of the
Is there something that prevents it from processing before any other parsing ?
Maybe there needs to be a processing priority established ?
Maybe you can explain how any problems with the new VisualEditor and Parsoid
are not orthogonal to this extension ?
I haven't used VisualEditor yet as I am very comfortable with the older editor,
so I'm not aware of any problems there.
BTW, to facilitate the use of this extension, WP could always make some
supplementary requirement such as the use of the extension be signaled by a
definition at/near the beginning of the page. Or maybe restrict it to user:
space initially, for testing purposes.
I'm not trying to distract you from solving VisualEditor problems, but we have
a pre-existing editor which works very well, and extension:Variables is an
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
Wikibugs-l mailing list