Last modified: 2014-03-31 23:00:53 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.
Would strongly recommend against this sort of meta-programming features in wikitext.
Ditto.
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.
(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.
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.
Don't I get a scientific analysis? :(
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!)
*** Bug 8570 has been marked as a duplicate of this bug. ***
(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.
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.
Would it be possible to move this bug into the extensions category a reopen?
Ignore my previous comment
*** Bug 13443 has been marked as a duplicate of this bug. ***
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.
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.
Closed as WONTFIX per comments from people who matter :)
*** Bug 13894 has been marked as a duplicate of this bug. ***
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? :)
*** Bug 63324 has been marked as a duplicate of this bug. ***
Since this bug was posted and closed over 7 years ago for reasons probably no longer valid, am reopening bug 63324.
