Netoholic and Thebainer want to have the sentence "One of the most common reasons meta-templates are created is to add functions that mimic conditional expressions". I disagree with having this sentence in his guideline and I don't see why we need a section for conditionals at all. This might have been true before we had m:Parserfunctions. But nobody needs metatemplates for conditional logic anymore, so WP:AUM doesn't have to do anything anymore with conditional logic. How are metatemplates needed to implement conditionals? Could you show me where metatemplates are needed or used for conditional logic, let alone as "most common reasons"? --Ligulem 15:04, 22 October 2006 (UTC)[reply]

I've rewritten the section describing the use of metatemplates for conditionals as historic. But I don't think this section is needed anymore, as conditionals now don't have anything to do with metatemplates anymore. --Ligulem 15:24, 22 October 2006 (UTC)[reply]

That version's better, it emphasises the historical use. Although they aren't used for that purpose now, it makes perfect sense for this page to explain why that is so, and what is to be used instead. --bainer (talk) 00:26, 23 October 2006 (UTC)[reply]

Netoholic reinserted "Meta-template schemes are sometimes created using many layers of nested templates to mimic conditional expressions". Again, this is not correct. Meta-templates are no longer used to mimic conditional logic. I have thus reverted to the version which Thebainer agreed on. --Ligulem 07:58, 23 October 2006 (UTC)[reply]

You are missing the point. While YOU may not create meta-template schemes... it is still a very common practice by template neophytes who don't know a thing about m:Parserfunctions, and so "One of the most common reasons meta-templates are created is to add functions that mimic conditional expressions". That statement, and the mention of the practice here is not an endorsement... the page title says to avoid such things. The point is to describe the practice so that people can recognize what's being discussed and be shown alternatives. In other words "Here's a common practice, and it should be avoided in favor of x, y, & z". -- Netoholic @ 07:59, 23 October 2006 (UTC)[reply]

Can you show me such practice? --Ligulem 08:02, 23 October 2006 (UTC)[reply]

Template:Flag. Please to enjoy. -- Netoholic @ 08:11, 23 October 2006 (UTC)[reply]

Well known. Anything else? But Template:Flag does not serve as an example of "common practice". --Ligulem 08:27, 23 October 2006 (UTC)[reply]

Those teeny-tiny flags are on hundreds pages, and there are several variations of the basic flag template. Category:Flag templates and Wikipedia:WikiProject Flag Template cover all the related ones (Olympic, ISO, etc.). An extremely common practice (relatively on an encyclopedia of almost 1.5 million articles), and still is a convoluted meta-template scheme. You can see some of the hundreds of related templates here. Because of how these are set up, Whatlinkshere is highly unreliable. The flag templates were my main inspiration for WP:AUM. I'd help fix them, but... -- Netoholic @ 17:56, 23 October 2006 (UTC)[reply]

In general, I agree with this wording. Although I do think "Conditionals should generally be avoided, unless there is a significant advantage in their use" is a bit dense. But as long as "Generally avoided" is not misrepresented as "do not use {{#if:...}} at all cost", I can live with that wording. Common practice is that even the "few template gurus" don't insert #if's if they are not needed. --Ligulem 08:27, 23 October 2006 (UTC)[reply]

Overall, I don't think there is enough of a 'problem' here to require a policy/guideline. If individual templates (e.g. the flags) could be better structured then we should address that directly on a case by case basis rather than setting up an 'official policy'. The latter can only serve as a 'club' to force people to change something which has consensus... and, as I said, I don't see any problems here which I think would necessitate that. The fact is that people generally aren't creating "convoluted meta-template schemes" since the introduction of parser-functions. The flags are a relic from pre 'conditional template' days that have never been updated to more recent methods. Maybe there are reasons for that... or maybe it is just that nobody ever put in the effort, but that is one of a handful of cases and not any sort of widespread or significant problem. --CBD 12:56, 26 October 2006 (UTC)[reply]

You'd probably be surprised with just how many conditionally-based nested template schemes there are out there. This page can be a guideline which explains the issues, so that the same arguements aren't repeated. -- Netoholic @ 20:57, 27 October 2006 (UTC)[reply]

So point them out and I'll be happy to talk with the people there about simplifying them. Heck, you could talk to them yourself, work out a consensus, develop an alternative in your user space, and get someone to implement it. Which would probably go a long way towards getting your ArbCom probation on the matter rescinded. I just think it is a bad idea <tm> to go down the road of 'this type of template is a bad design... see there is a page which says so... so you have to change/abandon/delete it' again. There is not enough of a 'problem' here to justify ANY sort of cudgel... whether it be labeled 'guideline' or not. If there is really a way to simplify things people will usually jump at the chance. --CBD 13:11, 6 November 2006 (UTC)[reply]

A rejected page is any proposal for which consensus support is not present. Consensus need not be fully opposed; if consensus is neutral on the issue and unlikely to improve, the proposal is likewise rejected. Making small changes will not change this fact, nor will repetitive arguments. Generally it is wiser to rewrite a rejected proposal from scratch and start in a different direction.

— Policies and guidelines

This page and its fundamental concept have been rejected over and over. Neto is the only one trying to revive this. The content you want to add is fine, but not policy material. It belongs on an informative page like Wikipedia:Template namespace; not here. — Omegatron 00:10, 4 November 2006 (UTC)[reply]

So feel free to add a summary on that page, but let this be the expanded -guideline- (not "policy"). I cannot tell from the above whether YOU YOURSELF reject this page, or are only acting out of some sense of obligation becuase you believe that it oresently is rejected. IF you say the wording is fine, and Ligulem does, and me, and CBDunk doesn't have major objections... then what is the problem? It is a proposed guideline, nothing more. LEt it evolve, let more people read it without the stigma of that giant red "X" on the top. -- Netoholic @ 07:21, 4 November 2006 (UTC)[reply]

I believe there are a few pages that were edited in anticipation of WP:AUM. Some (probably not all) of these pages may warrant reverting. Are there any guidelines, or priorities or concensous was to what to revert first? I am of the mind to simply do the ones I know about.

Sumburgh 08:49, 5 November 2006 (UTC)[reply]

Of course other pages should reflect the fact that this is rejected, but can you give some more concrete examples of what you're talking about? — Omegatron 09:29, 5 November 2006 (UTC)[reply]

People who rejected this page 9 months ago did so because they felt that it threatened a poorly implemented hack involving Template:If and such. Now that scheme is deprecated in favor of ParserFunctions, and all RECENT indications about are that the main people who lead the rejection of this page are now of the mind that, with some updates to reflect the present situation, that the content of it is good. To repeatedly say this page is rejected while ignoring recent consensus is not accurate. I do not care about the past, I care that this page makes some excellent observations and suggestions. People "get" what this page is about, as I see the subject come up often and I see people working under the principles given here. Nested "meta-template" schemes are being wiped out. This page is current, and reflects wide consensus. I remain open to discussing specific parts, but Omegatron is not the decider of what is rejected or not. To do so he needs to show this page does not currently hold consensus. -- Netoholic @ 09:51, 5 November 2006 (UTC)[reply]

It seems this is a very touchy subject, so I suggest further discussion before making any changes on the actual project page. -- Ned Scott 10:46, 5 November 2006 (UTC)[reply]

And discussion is happening. It is only "touchy" because people assume it must be "touchy". In reality, the page's function is simple and generally agreeable. -- Netoholic @ 09:50, 7 November 2006 (UTC)[reply]

It would help if you gave some examples of this "general agreement" you keep talking about. Who has said they want this page revived besides you? — Omegatron 17:19, 7 November 2006 (UTC)[reply]

What you're not getting is that you and other people are "saying" that this page has no agreement, but not speaking for yourself. Do you yourself believe that meta-template schemes should be avoided? I really want everyone on this talk page to answer this question, rather than assume they are acting on behalf of some shadowy faction that oppses this page. -- Netoholic @ 17:52, 7 November 2006 (UTC)[reply]

So you can't? — Omegatron 02:37, 8 November 2006 (UTC)[reply]

instructions creep, because it's not a big issue in the first place? -- Ned Scott 03:31, 8 November 2006 (UTC)[reply]

Why not make a workshop page, or a new proposal along similar lines? - A Man In Bl♟ck (conspire | past ops) 03:13, 6 November 2006 (UTC)[reply]

Because we've been down that road before, and this is the right title and place to discuss this very minor consideration in the template space. Besides, the content of the page is largely uncontroversial, except when people assume it is controversial. -- Netoholic @ 09:50, 7 November 2006 (UTC)[reply]

Ugh. Do you ever feel like you're the needle running over a broken record? Edit warring, disputed page protections, blocks, et cetera. We've all been here before and we all know how it turns out... badly for Wikipedia. Can we please not fight this war again?

Netoholic, you are not wrong that some templates are set up less efficiently than they could be. We should indeed encourage people to use different methods where appropriate. However, this page is not needed to do that. There is nothing preventing direct contact with people involved in various templates that could be re-designed. No, you can't then point at a page and say, 'all the reasons why this must be done are there'... but that's a good thing. It forces us to examine the individual needs of the template and the people using it and work with them to come up with a replacement they are comfortable with. So that we are the 'good guys' not just in terms of improving templates for Wikipedia as a whole, but also to the individual users impacted.

Why not work on improving the templates collaboratively... rather than fighting to enshrine a framework which can serve no purpose but to over-ride collaboration with 'established practice'? --CBD 13:38, 6 November 2006 (UTC)[reply]

I don't think that approach will help in more than a few cases. I prepared the first version of this page only after dozens of individual meta-template arguments and deletion votes. This page centralises many of the points, so why would we want to expend effort re-explaining this each and every time? No, this is not the biggest problem on Wikipedia - I never said it was. Far more often then not, people have been directed to this page, read it, and come away with a greater understanding and a desire to make their templates less cumbersome. Why take that away? -- Netoholic @ 09:45, 7 November 2006 (UTC)[reply]

I just stumbled here looking for template content. I come from a strong background in C++ template meta-programming and I've witnessed this same debate play out over a decade with larger armies, better trained, and better equiped. I would say the debate was more complex than the meta-programming techniques themselves. The autoptr<> saga raged forever. In my view, this page is not the right forum to achieve its purpose: advocating a judicious use of complexity for the betterment of the community as a whole. Far more useful would be a page or collection of pages concerning Recommendations on avoiding unnecessary complexity in general, with portions applied to templates, and meta-templates, in particular; and from there, as others have suggested, work with people to adopt this material to their specific situation so far as it makes sense.

I lost what sympathy I had when I saw the prominent link to protected pages are bad(tm). That's the kind of innocuous-on-the-surface wolf-in-sheeps-clothing that makes this page dangerous and far from uncontroversial. The same facility that these semi-protected deep-infrastructure meta-templates provide could just have easily have been incorporated into the MediaWiki code base as custom PHP. Does that end up making the facility less-protected? The C++ community went through endless heartache to push complexity away from the core compiler by making the template infrastructure sufficiently powerful that the same complexity could be handled as a deep systems library provided by the compiler vendor or by means of a battle-hardened primitives library (e.g. Boost). At the end of the day, it benefits the entire ecosystem not to code more policy into the compiler itself than absolutely necessary. For C++, the equivalent of the parse-functions extension is coded in a Boost library and you wouldn't want to be mucking with this down in the sub-basement unless you feel up to the challenge of performing a successful self-amputation. Most likely it was of great value that the community could explore the use of this facility before it was formally codified as Mediawiki extension. Experience has shown that new C++ coders often learn faster and make fewer mistakes programming on top of the Boost library, rather than cooking from scratch in a notoriously unsafe kitchen. The issue is about packaging the complexity appropriately, not whether it exists somewhere in a basement that eats children.

The point here is that there is certainly no consensus in any policy page that the use of protected pages to promote the general safety of Wikipedia while wrangling with how to best dispatch complexity taints such an endeavour intrinsically, which is the wolf-in-sheeps clothing that invoking the trappings of a consensus formed about the abuse of a mechanism in a broad political context rather than this hillybilly-esoteric technical backwater. In so far as the reader comes away informed, it could be achieved better by other means.

A good book to consider is Getting to Yes which talks at length about the need to argue from interests rather than positions. The interest here is that Wikipedia complexity be managed in the best possible way across the broad swath of the Wikipedia ecosystem, from casual contributors to hard-core MediaWiki hackers. IMO the existence of this page subtley biases the debate away from the interest of managing complexity and toward the position that template meta-programming can be tarred with one brush. That makes this page plenty controversial in my estimation. MaxEnt 18:18, 7 November 2006 (UTC)[reply]

Wow, that was.. really well put :) -- Ned Scott 03:35, 8 November 2006 (UTC)[reply]

The text alone from United States is 500 KB of meta-templated goodness, not counting javascript, stylesheets and of course images. I clocked five various diffs (with "time wget" from the shell) at between 43 and 48(!) seconds just now. The second try of each was about 5 seconds. When a particular version of an article with enough meta-templates in it gets bumped from the caches, you wait. And wait. I disbelieve the developers when they say nested transclusion isn't a performance penalty. That depends on having an effectively much larger cache than we do now. 1of3 03:40, 6 October 2007 (UTC)[reply]

from Rob Church on the mailing list:

The "technical team" is not responsible for checking that content is correct, nor is it responsible for checking page load times for each article and pruning them in the dumps. If a page contains obvious abuses of markup which cause significant problems for large numbers of users, then we'll kill it off, but of course, we haven't had a large number of reports of that in recent months, although as other threads on the list imply, the problem is resurfacing, and will likely be looked into.

We can't really help it if our users are silly enough to insist upon abusing a markup language as if it were pure code, nor if they insist upon continuing to use fragile-looking template constructs which will end in tears.

— xaosflux ^Talk 11:27, 26 October 2007 (UTC)[reply]