Last modified: 2014-03-31 23:00:53 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 7865 - Enable extension VariablesExtension
Enable extension VariablesExtension
Status: RESOLVED WONTFIX
Product: Wikimedia
Classification: Unclassified
Site requests (Other open bugs)
unspecified
All All
: Lowest enhancement with 6 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: shell
: 8570 13443 13894 63324 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-10 22:45 UTC by Carl Fürstenberg
Modified: 2014-03-31 23:00 UTC (History)
9 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Carl Fürstenberg 2006-11-10 22:45:20 UTC
I would like to request the the extension "VariablesExtension"
([[m:VariablesExtension]]) or something similar to be enabled on the english
wikipedia etc... This to reduct meta template calls on more advance templates
and/or reduce the amount of duplicated text in said templates.
Comment 1 Brion Vibber 2006-11-11 07:55:32 UTC
Would strongly recommend against this sort of meta-programming features in wikitext.
Comment 2 Rob Church 2006-11-11 13:04:59 UTC
Ditto.
Comment 3 Rob Church 2006-11-11 13:33:39 UTC
Look, get it into your head that this isn't a bloody programming language; it's
a simple text markup language. The poxy little wars over meta-templates and
parser functions and the associated bullshit are totally pointless. What real
good is a variable system going to do for normal articles?
Comment 4 Carl Fürstenberg 2006-11-11 13:38:49 UTC
(In reply to comment #3)
> Look, get it into your head that this isn't a bloody programming language; it's
> a simple text markup language. The poxy little wars over meta-templates and
> parser functions and the associated bullshit are totally pointless. What real
> good is a variable system going to do for normal articles?

Could you try to be a bit civil? this isn't a war.
Comment 5 Rob Church 2006-11-11 13:41:45 UTC
(In reply to comment #4)
> Could you try to be a bit civil? this isn't a war.

Really? That's not what you and dear old Adrian wotsisname screamed at me, the
last time I took a load of abuse from you on dear old enwiki.
Comment 6 Carl Fürstenberg 2006-11-11 13:52:30 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > Could you try to be a bit civil? this isn't a war.
> 
> Really? That's not what you and dear old Adrian wotsisname screamed at me, the
> last time I took a load of abuse from you on dear old enwiki.

I don't really understand what you are talking about, you are sure you are not
overreacting about something that happened a long time ago?
Comment 7 Andrew Garrett 2006-11-11 13:54:08 UTC
Bickering aside, I think that when three developers, one of which is the CTO for
the Wikimedia Foundation, say they won't fix a bug, the bug is unlikely to be
fixed. WONTFIX, and don't reopen without significant futher discussion.
Comment 8 Carl Fürstenberg 2006-11-11 13:58:35 UTC
Why I reopened the bug, is because Rob Church seems to have a personal vendetta
against me. Aside from that, the reason I think this could be a "Good thing", is
that it will enable some of the more used and complex templates to reduce their
complexity and their size. I can't see a reason from a technical point of view
why this couldn't be added.
Comment 9 Rob Church 2006-11-11 14:01:18 UTC
I would welcome some input from Tim Starling on probable performance costs.
Comment 10 Tim Starling 2006-11-12 14:30:06 UTC
I wrote a long rant last night on this bug report about how evil this extension
is, but it isn't here! I must not have saved it properly. I'm against it on the
grounds of interaction with caching, the need to maintain flexibility of parser
implementations, and expected application (wikitext is not a programming
language). Sure, performance costs too, why not. As if you needed more
ammunition anyway. 
Comment 11 Rob Church 2006-11-12 15:45:24 UTC
Don't I get a scientific analysis? :(
Comment 12 jquinn 2007-01-17 10:05:55 UTC
Hey, with much respect to Tim Starling, and understanding that some people may
want this just for the heck of it, which is evil, here is a simple and, in my
mind, very appropriate usage case for this extension:

I have created [[en:Template:Subclade]] (works, but needs polishing), which
creates a horizontal clade tree in a single table, for better alignment (see
[[en:Talk:Mayan Languages]] for the case that inspired me, and a comparison with
the older clade template). This tree is accomplished by nested calls to the same
template. The outer calls (tree roots, main branches) need to have a rowspan
which is the sum of their inner calls (subbranches). There is currently no way
to do this except manually, which is error-prone for complex trees. With this
extension, this is a simple matter of formatting, which is one of the main and
most legitimate uses of templates. 

(This case could also be easily solved with StringFunctions, but I suspect that
inspires similar hostility. I actually suspect that, in the well-justified
absence of DynamicFunctions, VariablesExtension would not lead to much abuse - I
can't see any use other than nested templates, and these have uses which don't
tend to be any more illegitimate than templates in the first place. Which is not
to say of course that there would be NO frivolity.)

If this extension has ill effects on caching or parser implementation, obviously
that needs fixing before this extension can be activated. So I would welcome
some more comments on those aspects. But really some of us who want this
functionality, want it in good faith, for use in improving regular articles (or
books!)
Comment 13 jquinn 2007-01-17 10:09:33 UTC
*** Bug 8570 has been marked as a duplicate of this bug. ***
Comment 14 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-01-25 23:38:08 UTC
(In reply to comment #12)
> I have created [[en:Template:Subclade]] (works, but needs polishing), which
> creates a horizontal clade tree in a single table, for better alignment (see
> [[en:Talk:Mayan Languages]] for the case that inspired me, and a comparison with
> the older clade template). This tree is accomplished by nested calls to the same
> template. The outer calls (tree roots, main branches) need to have a rowspan
> which is the sum of their inner calls (subbranches). There is currently no way
> to do this except manually, which is error-prone for complex trees. With this
> extension, this is a simple matter of formatting, which is one of the main and
> most legitimate uses of templates.

I don't see why you can't calculate the number directly with {{#expr:}} and pass it as a template 
parameter.

> (This case could also be easily solved with StringFunctions, but I suspect that
> inspires similar hostility. . . .

It doesn't.  We're kind of leery of enabling them, maybe, but we're not ruling them out or 
anything.  Likely they (or equivalents) will get bundled with ParserFunctions sooner or later.
Comment 15 jquinn 2007-02-01 03:45:08 UTC
The calculation isn't difficult - it's a matter of 
counting - but I don't want to enter values in more than 
one place (the #expr and the subtemplate) because that 
gives chances for errors, especially when somebody comes 
and edits a subtemplate. Also, in the long run, there 
may be more formatting options (single or double-spaced) 
which would complicate the calculation.
Comment 16 Robert Leverington 2007-03-05 17:55:46 UTC
Would it be possible to move this bug into the extensions category a reopen?
Comment 17 Robert Leverington 2007-03-05 17:59:37 UTC
Ignore my previous comment
Comment 18 Ryan Schmidt 2008-03-20 02:59:06 UTC
*** Bug 13443 has been marked as a duplicate of this bug. ***
Comment 19 Dan Bolser 2008-12-05 15:23:25 UTC
I think the more like a programming language MW becomes, the better. Sure there is a whole heap of problems related to performance and decidability, but saying 'ooh, its only for markup, oooooh!' is a bit like sticking your head in the ground and ignoring the future. 

By all means, keep WP stable! But don't get confused between WP and MW.

The internet is becoming a giant GUI / API / Application, that's the future (thinking of Google charts for example) MW can continue to contribute to this future, no?

Looking at the function it just looks like an array, is it really that insidious and evil?

Just my 1c as people say (not forgetting inflation).
Comment 20 Minh Nguyễn 2008-12-05 19:40:20 UTC
(In reply to comment #19)
> I think the more like a programming language MW becomes, the better. Sure there
> is a whole heap of problems related to performance and decidability, but saying
> 'ooh, its only for markup, oooooh!' is a bit like sticking your head in the
> ground and ignoring the future. 
> 
> By all means, keep WP stable! But don't get confused between WP and MW.

This bug isn't about integrating the extension into MediaWiki; it's about installing it at the English Wikipedia.
Comment 21 dohnp5a1 2009-02-24 13:37:49 UTC
The extension would be almighty useful, not only in the English Wikipedia. Ex. I wanted create a global citation template for citing all types of sources in the Esperanto Wikipedia but have had to stop the work because of the error ''Expansion depth limit exceeded'' (http://eo.wikipedia.org/w/index.php?title=%C5%9Cablono:Fontindiko/monografio&oldid=2183672). Nevertheless, in such a complicated template I cannnot avoid creating of deep condition trees, if it isn't able to use variables. They would help and besides simplify the work extremely.
Comment 22 Mike.lifeguard 2009-03-19 16:00:32 UTC
Closed as WONTFIX per comments from people who matter :)
Comment 23 Conrad Irwin 2010-03-12 01:13:44 UTC
*** Bug 13894 has been marked as a duplicate of this bug. ***
Comment 24 badon 2011-09-23 02:20:10 UTC
For the record, I agree with comment 19. MediaWiki can be very simple, and/or very complex. The more of both, the merrier. I understand this bug is specific to wikipedia, but we're keeping it all in the family, right? :)
Comment 25 Bawolff (Brian Wolff) 2014-03-31 22:27:39 UTC
*** Bug 63324 has been marked as a duplicate of this bug. ***
Comment 26 andré 2014-03-31 23:00:53 UTC
Since this bug was posted and closed over 7 years ago for reasons probably no longer valid, am reopening bug 63324.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links