Hi André, thanks for taking the time to report this!

(In reply to andré from comment #0)

I would like the extension:variables installed.

On which site? For any configuration change, a local consensus is required. Could you discuss the matter on the Village pump page of your wiki to confirm that this change is wanted by the community, and paste the link to the discussion here?

Also, please see https://www.mediawiki.org/wiki/Review_queue for a checklist of steps how to proceed before marking this as blocking bug 31235.

This was rejected way back in the day (bug 7865). I assume the rejection still stands.

2. It keeps this string local to the only page where it will be used, thus not polluting the template namespace, and avoiding potential name conflicts with other templates.

Fun fact, there are 74106937111882365071085430405560261026092790186009960985252853765064
40296955904 possible template names, (This is an under-estimate, I didn't count most non-english letters). You could easily use Template:PageNameHere/Specific_string_name, or even just make it a subpage of the actual page not in the template namespace, etc. Now namespacing things might be nice just generally, but we're not running out of template names.

It is rated as stable.

Just for the record, those ratings are done by the extension author. There are lots of extensions marked unstable which are actually more stable than the stable extensions. So the rating is pretty much meaningless. (Which isn't necessarily to say anything bad about this particular extension, I have no idea how stable it may or may not be)

• This bug has been marked as a duplicate of bug 7865 ***

andr55 wrote:

(In reply to Andre Klapper from comment #1)

Hi André, thanks for taking the time to report this!

(In reply to andré from comment #0)

I would like the extension:variables installed.

On which site? For any configuration change, a local consensus is required.
Could you discuss the matter on the Village pump page of your wiki to
confirm that this change is wanted by the community, and paste the link to
the discussion here?

Also, please see https://www.mediawiki.org/wiki/Review_queue for a checklist
of steps how to proceed before marking this as blocking bug 31235.

Thanks for the feedback.
The page in question is a template on the English WP.
I've already had contact with someone on the Village pump page, who wasn't aware of this extension.
I'll get back when I have the confirmation.

andr55 wrote:

(In reply to Bawolff (Brian Wolff) from comment #2)

This was rejected way back in the day (bug 7865). I assume the rejection
still stands.

It is a very bad assumption that a 7 year old rejection is still valid.
In case you hadn't noticed, both Mediawiki and extension:variables have changed since then.

---

2. It keeps this string local to the only page where it will be used, thus

not polluting the template namespace, and avoiding potential name conflicts
with other templates.

Fun fact, there are
74106937111882365071085430405560261026092790186009960985252853765064
40296955904 possible template names, (This is an under-estimate, I didn't
count most non-english letters). You could easily use
Template:PageNameHere/Specific_string_name, or even just make it a subpage
of the actual page not in the template namespace, etc. Now namespacing
things might be nice just generally, but we're not running out of template
names.

Assuming a 2-letter name, that gives only 676 possibilities.
But that is not the point.
It is not unreasonable to assume that many short names will conflict. Disambiguation pages don't exist for nothing.
One advantage of variables local to a particular page is that such variables can be short, thus easier to type, without any ambiguity. As noted above.

It is rated as stable.

Just for the record, those ratings are done by the extension author. There
are lots of extensions marked unstable which are actually more stable than
the stable extensions. So the rating is pretty much meaningless. (Which
isn't necessarily to say anything bad about this particular extension, I
have no idea how stable it may or may not be)

OK. But note that this extension existed in 2006, and was last modified in 2011. So it has been around for a while. And the last 2 (recent) versions are installed on 170 sites.

> *** 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.

(In reply to andré from comment #3)
I don't know what this refers to, but so far it looked like the bug report was about deploying an extension instead.

Not appropriate, for a very old bug rejected for circumstances which
likely have changed.

Please provide proof for the "likely".

(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).

andr55 wrote:

(In reply to Andre Klapper from comment #5)

(In reply to andré from comment #3)
I don't know what this refers to, but so far it looked like the bug report
was about deploying an extension instead.

Exactly. I was responding to your comment #1

Not appropriate, for a very old bug rejected for circumstances which
likely have changed.

Please provide proof for the "likely".

Evidently there have been considerable changes to WP since 2006.
As well, looking at the changelog of extension:Variables, there was a major re-write for version 2.0.0. (It is now at 2.0.1)

andr55 wrote:

(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 extension.
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 important enhancement.

(In reply to andré from comment #8)

So you are saying that problems with the implementation of these new
features interfere with this extension ?

It's not a problem with those features, it's a design requirement.

We had to deal with that requirement when creating Scribunto, too.

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 extension.

I haven't checked, but I'd imagine the model is more that when the parsing process calls the hook for #vardefine it sets some internal state, and when it calls the hook for #var then it returns that internal state. Much like how with Cite a <ref> sets some internal state and <references> uses that to construct a list of references.

Maybe there needs to be a processing priority established ?

Let's not add even more passes to the parser. The Parsoid folks already want to do that for Cite (and do do it in Parsoid).

Maybe you can explain how any problems with the new VisualEditor and Parsoid
are not orthogonal to this extension ?

Because wikitext needs to be parsed?

I'm not trying to distract you from solving VisualEditor problems,

Not my department anyway.

andr55 wrote:

(In reply to Brad Jorsch from comment #9)

(In reply to andré from comment #8)

So you are saying that problems with the implementation of these new
features interfere with this extension ?

It's not a problem with those features, it's a design requirement.

We had to deal with that requirement when creating Scribunto, too.

Evidently. And it works very well, at least on pages I've seen using it. Such modules can be a tremendous improvement over pure templates.

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 extension.

I haven't checked, but I'd imagine the model is more that when the parsing
process calls the hook for #vardefine it sets some internal state, and when
it calls the hook for #var then it returns that internal state. Much like
how with Cite a <ref> sets some internal state and <references> uses that to
construct a list of references.

It would be setting a value for a token, and replacing tokens with that value. Simple text replacement, as it passes through the page. There are some more complicated options, but they could be ignored by WP if difficult to implement. For instance, there could be a bar to using recursion.

Maybe there needs to be a processing priority established ?

Let's not add even more passes to the parser. The Parsoid folks already want
to do that for Cite (and do do it in Parsoid).

But additional passes can be a very effective way of simplifying the problem. Often with little or no cost in performance.

Maybe you can explain how any problems with the new VisualEditor and Parsoid
are not orthogonal to this extension ?

Because wikitext needs to be parsed?

Logically, the simplest solution for extension:Variables is to have a priority parsing pass to itself. Once that is done, the resulting page shows no evidence of the extension.
If there is a relatively straight-forward way to signal the use of the extension in the page (such as a definition near the beginning of the page), the performance hit for other pages should be minimal if any.
Maybe the parser could do an initial scan of the page to enumerate all the extensions/modules used in the page (if it doesn't already), and then do parsing passes according to an appropriate priority. Many but not all could be done in parallel. Extension:Variables being an obvious exception.
It's not rocket science. (To experienced programmers, at least.)

If there is a problem with how extension:Variables is implemented, I'd be interested in writing a similar very simple equivalent, that does nothing more than act as a preprocessor, replacing one or more variables with literal text in a single pass. In my mind that is all that most uses of such an extension would be anyway. And it does fill a void, between templates and modules created with Scribuntu/Lua

It was marked as a verified duplicate of T9865 while in Bugzilla: http://bugs.wmflabs.org/show_bug.cgi?id=63324