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.
Version: unspecified
Severity: enhancement
robchur wrote:
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?
(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.
robchur wrote:
(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.
(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?
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.
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.
robchur wrote:
I would welcome some input from Tim Starling on probable performance costs.
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.
jquinn wrote:
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!)
ayg wrote:
(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.
jquinn wrote:
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.
lcarsdata wrote:
Would it be possible to move this bug into the extensions category a reopen?
dan.bolser wrote:
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).
(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.
dohnp5a1 wrote:
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.
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? :)
andr55 wrote:
Since this bug was posted and closed over 7 years ago for reasons probably no longer valid, am reopening bug 63324.