Wikipedia talk:Avoid using meta-templates/Archive 3

From Wikipedia, the free encyclopedia

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Contents 1 Accessiblty concerns with css class hiddenStructure 2 Weeble Implementation 3 Why only on enwiki? 4 Random 5 Proposed renaming 6 Transitioning and alternatives 7 Conversion Template 8 Banning meta-wiki to stop vandalism?? 9 Misnomer 10 CSS hack reduces accessibility 11 On Babel 12 Complete rewrite 13 Forcing Substitution? 14 Server load and developers 15 Policy status 16 Developer statement 17 Alternatives to "logical" or "conditional" meta-templates 18 Protected 19 Brion's comment 20 General comments 21 What I need from you 21.1 Simplest possible codeset 21.1.1 Looping construct 21.2 Conditionals are not really needed 22 Policy/Guideline status 23 Page focus 24 Yet another kludgy hack 25 Conditionals in codeset 26 Reverted again 26.1 Rewrite 27 It will never end 28 From main page 29 minor change request 30 Test 31 Red herring 32 Proposal? 33 Classification 34 Happy Anniversary! 35 Protected 36 Use of conditionals in infoboxes 37 Feb 11 changes by CBD 38 Policy is too extreme 39 Netoholic citing this page again 40 Guideline 41 Straw poll 41.1 Accepted (guideline or policy) 41.2 Rejected 41.3 None of the above 41.4 Polls are still evil 41.5 End date 42 Which is better: {{qif}} or subtemplates? 43 Example 44 Wikipedia:Avoid conditional templates 45 Rejected 46 Pages to watch 47 Mathematical expressions and conditional constructs

Accessiblty concerns with css class hiddenStructure

User:Netoholic is advocating that lines in tables be hidden with class="hiddenstructure{{parameter|}}", rather than using more complicated parameter hacks. I wish to raise a number of concerns I have over the accessibilty of this technique.

Firstly, and most easily fixed, this uses visual styles only. The style rule speak:none should be added as well display:none so that it remains "hidden" for screen readers.

The second is this does not work for users on non-css browsers or for users who have CSS enabled. I know some do not feel that it is worth taking these users into consderation, but noting the accessibily features coded into wikipedia (if you turn off style sheets you get headings over the various navigation menus, such as "Views" and "Personal Options") I know that I am not the only one who thinks that they should in some way be catered to.

The third is similar to the second in that it fails when the stylesheet is not present, for instance on mirrors. http://www.1bx.com/en/ARY_Digital.htm is a mirror of ARY Digital, a page that uses the hiddenStructure css hack and the "hidden structure" is clearly visible as that site does not use our stylesheets. I am concerned that reliance on such a style rule is tantamount to being a self-reference (unless there is instructions linked off http://download.wikimedia.org/ or somewhere to indicate that it is necesary to use these stylesheets) – MrWeeble Talk Brit tv 14:06, 3 January 2006 (UTC)

For what it's worth, this concerns me as well, but it seems to be getting lost in the "Great Meta Template Purge of 2005/2006". I know Ævar had concerns about Lynx users and screen readers as well, which he expressed here. A screenshot (also provided by him) pretty well showed how horrible the CSS hack was: [1]. —Locke Cole • t • c 14:18, 3 January 2006 (UTC)

Content control is not what CSS is designed for: the hiding of document content is more than a 'style' issue. We cannot expect mirrors of Wikipedia content to adopt Wikipedia style sheets: the content should remain independent of style. The CSS kludge could be reworked into inline CSS, but that would look really horrible. I tink it's fair to say that we do not yet possess a viable alternative to 'meta-templates'. --Gareth Hughes 14:33, 3 January 2006 (UTC)

I think we do have a viable alternative. 'WeebleCode'. Yes, it requires an '|if=' statement or other blank parameter to be added to the template call. I don't consider that a big deal compared to the complete rewrite of many template calls which is going on. And, as per the example I just added to #Comparison CSS trick/Weeble code above, I think it is at least as simple to write this in templates as the CSS hiddenStructure trick. --CBD _☎ ^✉ 16:14, 3 January 2006 (UTC)

Not sure it could be done inline except as style="display:none{{parameter|}};speak:none{{parameter|}}". unfortunately, setting a style property to a non-existant value results in invalid CSS, whereas calling an non-exisiting class is not invalid. – MrWeeble Talk Brit tv 14:44, 3 January 2006 (UTC)

That's a very good point about using the CSS trick inline: it creates invalid CSS. Your code is good. but has the draw back of requiring the dummy parameter to be defined in every calling article, and of not allowing table pipe syntax. I'm not so sure that this is such a viable alternative. --Gareth Hughes 18:45, 3 January 2006 (UTC)

Indeed, I am not specifically advocating the dummy parameter hack over any other option, there seems to be real disadvantages with them all. Just hoping that we can either find a decent alternative (preferable) or at least reach a consensus as to which evil is the lesser. I suppose it comes down to which is deemed more important by the community, accessibilty of output or usability of input. – MrWeeble Talk Brit tv 20:00, 3 January 2006 (UTC)

For the very high use templates we'll need a bot to add the dummy parameter to all the template calls. This would make this hack a little less 'evil'! --Gareth Hughes 23:23, 3 January 2006 (UTC)

I did a complete conversion of {{taxobox}} to dummy parameter format (no hiddenStructure) at User:CBDunkerson/Sandbox3. A few different calls to this can be seen (along with some other ongoing projects) at User:CBDunkerson/Sandbox. It would be interesting to see whether the browsers which had trouble with CSS can handle this better. The calls to the template were left unchanged from the current format except for requiring the extra '|if=' parameter. Note that I used wiki-table markup except I used <td> for the newlines... which could then be included inside the default parameter to prevent blank lines. I don't think this format is particularly more complicated than hiddenStructure style. The need to add the extra parameter is the biggest issue. --CBD _☎ ^✉ 00:31, 4 January 2006 (UTC)

This thread is nothing more than more stonewalling against this policy. The hiddenStructure tricke is not perfect, but we must do everything we can to eliminate meta-templates. Lacking anything better, and "Weeble" is definitely not better), we must implement what we have. In a couple months, if the syntax changes or someone discovers something better, I'll be back at it, updating all the templates I'm working on right now. I don't care. What cannot happen is for people to delay or impede these conversations on the grounds that CSS isn't perfect. Let's get to work. If you don't want to do the work, then at least don't iuterrupt those that do. -- Netoholic @ 01:04, 4 January 2006 (UTC)

No, this thread is discussion on the best ways to implement this policy. Compared to hiddenStructure, the 'MrWeeble' method offers greater accessibility and greater portability with only the cost of having to add '|if=' to each call to the templates. For many templates that seems like a reasonable tradeoff to me. There are over a thousand 'taxobox' template calls, so that's a little daunting to add all those 'ifs', but most templates don't get called that many times. --CBD _☎ ^✉ 01:34, 4 January 2006 (UTC)

you should have wikified discussion - it seems Netoholic does not know what this is. Tobias Conradi (Talk) 15:58, 4 January 2006 (UTC)

Netoholic, I am not "stonewalling against this policy". Indeed I agree with this policy. If something harms the servers and contributes to downtime then I say "kill it; kill it with a big stick". However, now we've accepted this policy, we need to determine what to do next to replace templates that use meta-templates for the hiding of lines that show. While there is some merit in going ahead and making unilateral changes, for something as important as this, I believe there should be consensus. At the moment there is not consensus, hence I thought I should raise my concerns about the hiddenStructure method in the hope that these can be resolved. In the interests of fairness and objectveness here are some Usability concerns with dummy parameter method:

• Requires a dummy parameter in each call of the template. This could be laborious to do manually, but should be relatively trivial to do with a bot.
• The code does not look pretty making it very hard for a newbie to edit.
• Due to both wikitables and templates using pipes, table structures need to be done in html, again this reduces options and thus reduces usability for editing it. – MrWeeble Talk Brit tv 12:07, 4 January 2006 (UTC)

I think any one of those reasons is enough to shelf "WeebleCode" in favor of the CSS solution. CSS does work well, and really only marginally looks bad on lynx, which is less than 0.03% of our hits. The solution for lynx is to limit the number of optional fields. I'd love to discuss alternatives, but people are starting to believe that WeebleCode is gaining consensus. Neat trick, but bad implementation. -- Netoholic @ 16:03, 4 January 2006 (UTC)

Actually, I think the major problem with hiddenStructure is that it doesn't work on Wikipedia mirrors unless each and every mirror individually includes hiddenStructure in its stylesheets. A large proportion of people reading Wikipedia content read it on a mirror site. --Gareth Hughes 17:12, 4 January 2006 (UTC)

Mirrors have always had to adapt, so I'm unconcerned about them too much. But really, what do you think a mirror can do with WeebleCode anyway? It's based of a function that's built into the pre-alpha version of MediaWiki that Wikipedia runs. Moreover, it's entirely reliant on the way the MediaWiki software handles those default parameters. Mirrors get copies of the page and template sources, but most don't even use MediaWiki. You're telling me that adding a CSS class to their implementation is harder than rewriting their parser code?

I'd be more worried about people who want to use content containing WeebleCode on the older (stable) 1.5.x and below versions of MediaWiki. Default parameters have not been activated on those releases and so WeebleCode has no chance of working. There is a chance it will never work, since 1.6.x isn't even in alpha state yet. hiddenStructure does work on the current stable/public version of MediaWiki. -- Netoholic @ 17:38, 4 January 2006 (UTC)

An alternative CSS trick that doesn't depend on a specific stylesheet is to use <span style{{{parameter|}}}="display:none;speak:none;">. I've recently used it in Template:Starsx, and it appears to work fine (even in lynx, though that's a bit of a special case). —Ilmari Karonen (talk) 19:12, 7 January 2006 (UTC)

That solution doesn't produce valid HTML, since styleFoo isn't an allowed attribute. It's OK to call undefined class names, as in the hiddenStructure method. I'm also curious why you say it works in lynx, when the point of that template is displaying images. -- Netoholic @ 19:56, 7 January 2006 (UTC)

True, but it seems Tidy strips the bogus attribute away — and even if it didn't, user agents are supposed to ignore unrecognized attributes. As for lynx, it works in the sense that it displays a meaningful alt. text. As I said, though, this template is a special case since its main purpose is to show images; it may or may not be possible to make other templates using such tricks work in lynx. —Ilmari Karonen (talk) 21:15, 7 January 2006 (UTC)

Weeble Implementation

I belive the portability and validity criteria really do turn us away from the hiddenStructure technique, and there seems to be gathering consensus that it not be used. I think we are fully aware of the drawbacks of the WeebleCode, but it seems CBD managed to work out how to retain the majority of template in pipe syntax with the WeebleCode. If we can have an agreed method of implementation and a few bots to add the dummy parameter, we could do some good work in reducing the use of meta-templates. --Gareth Hughes 12:41, 4 January 2006 (UTC)

I can not see how CBD's code works. I have tried to implement it, but it does not remove the lines, mereley removes the label from the line, leaving blank lines. I could be wrong, I suck at pipe syntax tables (been coding HTML tables for years - old dogs, new tricks). CBD, could you show us a test implementation?

The code at User:Adrian_Buehlmann/work/Infobox TV channel/2006-01-02 is a whole lot neater than my original version, and hopefully should be easier to edit.

As an additional comment, I feel that any templates that we hack in either of these ways should be tagged with a category (in noinclude of course), so that when a better method is implemented we can go through and re-reimplement them all. – MrWeeble Talk Brit tv 13:55, 4 January 2006 (UTC)

I segmented this out from the previous pros/cons section as both are getting large.
MrWeeble - definitely agree on the categorization. Both of these methods are kludges and we ought to keep track of them for later repair if a better methodology becomes available.
Take a look at the template:User Infobox which I just cobbled together and it's use on my User:CBDunkerson page. It makes extensive use of WeebleCode along with tables within tables. Still needs alot of polishing / expansion, but shows that the methodology is viable. As noted before, there's also User:CBDunkerson/Sandbox3 for a translation of {{taxobox}}... compare the coding on those two. They produce essentially identical output and have nearly the same coding, except that taxobox uses hiddenStructure and my Sandbox3 uses WeebleCode. Examples of Sandbox3 in use can be seen at User:CBDunkerson/Sandbox.
There is a blank line issue with this method, but you can usually work around it. The '!' symbol and <td> can be used inside a parameter default section to create horizontal and vertical cells... '!' being a header indicator means that it's use isn't always appropos, but I've been able to kludge something through for each situation I've encountered so far. I'll try to take a look at your latest 'Infobox TV channel' to see if I can figure out how to adjust it to this format. --CBD _☎ ^✉ 14:35, 4 January 2006 (UTC)

That looks good. It's obviously not a straight substitution, and some thought is needed to convert existing templates to WeebleCode. As no real solution seems to be on the horizon, it seems that this is the best kludge we have. To focus minds, the way forward seems to be:

1. Develop draft versions of existing meta-template templates rewritten with WeebleCode.
2. Ask others to cross-check and test them.
3. Get a few bots to carry out the insertion of dummy parameters into articles (offers please!).
4. Switch the template to the draft version, and tweak if necessary.

We can start on phase 1 right away. --Gareth Hughes 15:09, 4 January 2006 (UTC)

Why only on enwiki?

If this is a policy for technical reasons, why is it an enwiki-only policy? --Pjacobi 23:18, 3 January 2006 (UTC)

Good question. My best guess is that meta-templates haven't been implemented as extensively on other wikis or the server load is just less in general. --CBD _☎ ^✉ 14:15, 4 January 2006 (UTC)

plus en is just a lot bigger and busier than the others, so meta templates there are less likely to get hit. I guess on the other sites they are hoping that perfomance issues can be fixed in mediawiki before it becomes a problem for them. – MrWeeble Talk Brit tv 15:54, 4 January 2006 (UTC)

Because I haven't translated it into Latin. Phil Sandifer 16:35, 6 January 2006 (UTC)

For starters: devitatote subformulae! --Gareth Hughes 16:56, 6 January 2006 (UTC)

Random

I've come up with two (related) ways of building a 'random number' generator in Wiki-markup. However, one method would require thousands of parameters to be evaluated (with all but one being unpassed). The other method could cut that to hundreds of parameters, but would require the template to be manually updated every few days. Is evaluating hundreds (or thousands) of unset parameters in a template resource intensive? That is, if I had a template which lists parameters 1 to 1000, returning a different number for each, but I only passed in parameter 732 would the template take significantly longer to evaluate than if 732 were the only parameter it was anticipating? Assuming that parameter switching isn't a computational drain... do I dare go there? Once something like this is developed it could easily be converted to a generic {{random}} template which might then be called by other templates (meta-templating) or fed into other templates as a parameter (multi-templating). Is this too much of a 'genie out of the bottle' issue or can it be implemented in a limited fashion without hurting anything? And yes... I know I'm evil. --CBD _☎ ^✉ 15:33, 6 January 2006 (UTC)

We have no use for this. Go write an encyclopedia. -- Netoholic @ 16:02, 6 January 2006 (UTC)

Setting aside the usual pleasant attitude... I disagree. I think this could be useful to 'us' in building an encyclopedia. Part of our effort is showcasing the work we have done. That's why we have a 'Main Page', 'Portals', and 'Featured' content. The ability to randomly display different 'showcased' material each time someone views a page would unquestionably be beneficial in promoting the encyclopedia. The question is whether it is computationally sound or not. --CBD _☎ ^✉ 17:01, 6 January 2006 (UTC)

1000 Parameters? This is definitely "over-egging the pudding". I agree with Neto, though as usual he could have been a little bit more diplomatic :-). Ligulem 17:06, 6 January 2006 (UTC)

Uncyclopedia solves this problem the way it should be solved, with an extension. -- Cyrius|✎ 20:58, 6 January 2006 (UTC)

That would undoubtedly be the very best solution. Ligulem 21:39, 6 January 2006 (UTC)

Proposed renaming

I propose this be renamed to Wikipedia:Never use meta-templates (with the shortcut being WP:NUMT). Having it named "Avoid using meta-templates" implies there are cases where meta-templates are okay, and that's just a little too confusing for people being hit over the head with this I imagine. —Locke Cole • t • c 07:38, 8 January 2006 (UTC)

Indeed. Ligulem 08:13, 8 January 2006 (UTC)

I've been thinking about that myself, but not how you are. The term "meta-template" is the source of a lot of confusion. I'm thinking something like "Don't use nested templates", although with that, we're really approaching the point where people may ask why that isn't removed from the software completely. -- Netoholic @ 09:04, 8 January 2006 (UTC)

Agreed. The meaning of the word is not clear.

I thought the whole point of making this policy was to make a temporary kludge because these changes couldn't be made to the software. — Omegatron 09:38, 8 January 2006 (UTC)

Perhaps one way to better educate people (such as myself, I admit) would be to point to examples of where meta/nested templates are OK/good for the encyclopedia. Or, just turn the feature off in software if there aren't any OK/good examples. —Locke Cole • t • c 09:31, 8 January 2006 (UTC)

I agree... move to Wikipedia:Don't use nested templates and make the shortcut WP:DONT.  ALKIVAR™ 10:56, 8 January 2006 (UTC)

Agreed. Ligulem 12:45, 8 January 2006 (UTC)

I think it's too strong. Heck, the Main Page uses nested templates. Avoid and don't mean different things. If anything I'd think we should just add more text to the policy to explain that it is extensive template nesting linked to many pages which causes problems... not simple cases of double transclusion which appear on one page. --CBD _☎ ^✉ 14:21, 8 January 2006 (UTC)

We could list the allowed exceptional cases. Ligulem 16:31, 8 January 2006 (UTC)

If only identified exceptions are 'allowed' then what you are talking about is a significant, and in my opinion unwise, policy change. Is there really any reason to go after all the users who have 'Babel' templates (which are meta-templates after all) on their user-pages? All those who put Babel and other template calls on a sub-page and then transclude that into their user page? Meta-templates... but absolutely insignficant in terms of server load. The policy is "Avoid"... there are uses of meta-templates which can cause unspecified but significant strain on the servers. We should be tracking those down and eliminating them. Not changing the policy to "Don't" and hassling a much larger population for no good reason. The problem is that 'Joe user' doesn't know which meta-templates are likely to cause significant drain and which aren't. Right now a bunch of people (mostly on this page) are figuring that out for them. Maybe we ought to have a 'Wikiproject templates' to help sort out these and other conditional template issues. --CBD _☎ ^✉ 11:58, 10 January 2006 (UTC)

I agree with you. But it will be a hard job. And there is no consensus yet what qualifies as acceptable meta template and what not. I assume that Neto wants to extinct every meta template. I fear there will be a lot of stressy edit wars over this, which also harms the servers. People may say: "Oh that's not fair. Group X over there is allowed to that meta and we are not!". But we could give it a try. Ligulem 13:05, 10 January 2006 (UTC)

Wikipedia:Avoid nested templates, an explanation of what "nested template" means, what it doesn't mean, examples of templates that have been modified because of it ("Template X did nothing but format messages boxes. It has been replaced by CSS class Y, which provides the same functionality but with the following benefits and none of the server load problems"), and examples of templates (like those on the main page) that won't be modified. — Omegatron 17:21, 8 January 2006 (UTC)

Nope. Avoid avoid. Ligulem 18:48, 8 January 2006 (UTC) Change my mind. Seems to be the least evil for now. Nested templates is better than "meta templates". I see there is consensus to keep the word "avoid" but to use "nested templates". So I support that now. Ligulem 13:08, 10 January 2006 (UTC)

Another idea, move this page and use it as a seed for a Wikipedia:Template policy. -- Netoholic @ 17:41, 9 January 2006 (UTC)

No. Too broad. Ligulem 13:05, 10 January 2006 (UTC)

Transitioning and alternatives

OK, now that this has escalated to an official policy then what are the plans for transitioning and converting existing meta-templates? One alternative to m:Help:Array may be the data storage tool which Jimbo mentioned last year; what is the implementation status of that? I think one example was to store information such as the current capitol or president of a country. (SEWilco 10:03, 10 January 2006 (UTC))

There are a couple of 'in the works' changes which might allow meta-templates to be replaced with a built-in implementation. However, no clue when/if those will happen. In the mean-time two methods of replacing meta-template functionality have been developed. However, neither is perfect and both have benefits/drawbacks the other does not. Unfortunately, they might both break if the default handling for unset parameters changes. Extensive commentary on the 'CSS trick' and 'WeebleCode / parameter default trick' can be found on this page. There are also a number of more flexible variations on each (inline CSS, doing 'or/and/not' parameter checks, et cetera) which probably ought to be collected somewhere for reference. Several major meta-templates have already been transitioned over to these methods. --CBD _☎ ^✉ 12:13, 10 January 2006 (UTC)

Conversion Template

Currently there are some discussions about Conversion Templates [[2]] . In particular the following convertions template have been ruled as "disallowed by policy" in WP:AUM.

• Template: {{Born|1919|7|20|region=NZ}} that correctly puts Edmund Hillary into the Category:New Zealand people and Category:1919 births. And correctly formats the dates as per wiki standard.

Also:

• Template: {{Locale length|1000}} that Converts meters to feet eg. {{Locale length|10}} gives 10 m (33 ft) and {{Locale length|1000}} gives gives 1000 m (3281 ft), useful when globalising metric measurments (without imperial feet) are encountered in some pages. Also can be used to insert no-line-break space after the between number and unit. eg 1000 m, this is commonly missed and leads to messy pages.

I am thinking that we need more of these kind of template, not less. Can someone point me to some stats on how these kind of template effect the performance of mediawiki (I don't have mediawiki installed on any of my machines).

There is a comment c.f. that states that template encourage vandalism by forcing the vandal to manually change many pages. This "protection" comes at a cost as it means that real contrubutirs must also update the same pages manually. Fortunately we still have more contributors then vandals (for the foreseeable future). Can we drop the comment Wikipedia:Avoid_using_meta-templates#Vandalism as it is a bit self defeating? An alternative would be to stop anonymous (or new) contributors from creating Templates.

NevilleDNZ 11:48, 11 January 2006 (UTC)

I have stroked and nowikied the template transclusions in the above posting due to a massive amount of text transcluded into here. Ligulem 12:07, 11 January 2006 (UTC)

$10 CASIO calculator to the rescue... I have manually added the standard height calculation required in the example. NevilleDNZ 12:20, 11 January 2006 (UTC)

Ok :-). See also my posting on Template talk:Locale length. --Ligulem 12:24, 11 January 2006 (UTC)

(triple edit conflict)Sorry, my fault. I was converting the template, but hadn't updated the call yet. I changed this from a meta-template which calls one of 10,000 other templates to a single template which triggers one of 10,000 parameters. To do so the call has to change from {{Locale length|7}} to {{Locale length|7=m}}. The 'm' isn't really relevant, you can set it equal to anything... just need to define one parameter as the only one being set. This now begs the question... is this massive parameter switch as bad (or worse) than the massive meta-template in terms of server load? I'm assuming they're both ugly, but worth exploration. --CBD _☎ ^✉ 12:26, 11 January 2006 (UTC)

Um. Could you please confirm: 10,000 (in words: ten thousand) templates/parameters? --Ligulem 12:31, 11 January 2006 (UTC)

You heard (ok, read) me. That's how the conversion works. It calls a template P1, P2, P3... P10000. There are no mathematical functions in Wiki so each instance (1-10000 meters) must be identified and responded to independantly. BTW, it takes so long to sort out the parameters that if you have three of these calls on the same page it just gives up. I'm reverting to the other version and think we should definitely kill this thing. However, it makes me wonder if the parameter switching we are using to replace meta-templates isn't actually worse. --CBD _☎ ^✉ 12:36, 11 January 2006 (UTC)

As I already said a longer time ago on this matter: "Premature optimization is the source of all evil" (reference: Premature optimization) :-) Ligulem 12:43, 11 January 2006 (UTC)

Just a possibility. This is a pretty unusual case. It's really only 'double transclusion', but the second layer can be one of any 10000 templates... but that's set with a single parameter. So this isn't that bad as meta-templates go... but monstrous as parameter switches go. Something we need to keep in mind - in some cases the meta-templates are better. Especially if this one is subst'd in. --CBD _☎ ^✉ 12:48, 11 January 2006 (UTC)

Indeed I cant believe it. Patrick made template P1..P3 and NevilleDMZ continued them up to P10000. So we have now 10000 templates for that on Wiki:en. Grumble.... Looking for my big stick... (Oh boy, if Neto sees that :-) --Ligulem 12:51, 11 January 2006 (UTC)

Who do you think put it on TfD? :] --CBD _☎ ^✉ 12:56, 11 January 2006 (UTC)

NevilleDNZ, I like the concepts but the way these templates work is problematic. The country one might be convertable to a non-meta format. Take a look at what I did at User:CBDunkerson/Sandbox for the distance conversion templates. It can all be done in a single template call... the problem is that the distance conversion has so many possible parameters that it just takes forever to evaluate. Countries shouldn't be as bad. Also, if these are subst'd in rather than pasted as templates they wouldn't cause much disruption, but that would have to be watched carefully. --CBD _☎ ^✉ 12:48, 11 January 2006 (UTC)

Bloody hell. IF YOU WANT A NEW FUNCTION (like conversions) ADDED TO WIKIPEDIA, SUBMIT A FEATURE REQUEST. Stop misusing the template namespace as programming tool! -- Netoholic @ 18:31, 11 January 2006 (UTC)

 :-) --Ligulem 18:45, 11 January 2006 (UTC)

Groan... if wikipedia STILL does not have a calculator/conversion tool (as per my $10 CASIO calculator), what hope does any desperately needed "FEATURE REQUEST" have... seriously? Besides mediawiki is not paper, we can take advantage of the computer to do some of the more mundane tasks. (eg standard conversions)

subst "Groan" for "Bloody" Hell if you want more sound effects. NevilleDNZ 21:29, 11 January 2006 (UTC)

Well said. If there are restrictions on the syntax, try thinking why they are there and working with them, rather than trying to poke holes in them in the manner of a high school hacker. [[Sam Korn]] 23:49, 11 January 2006 (UTC)

Banning meta-wiki to stop vandalism??

There is a comment c.f. that states that template encourage vandalism by forcing the vandal to manually change many pages. This "protection" comes at a cost as it means that real contrubutors must also update the same pages manually.

It fall into the category of "to cut ones nose of inspite of ones face".

Fortunately we still have more contributors then vandals (for the foreseeable future). Can we drop the comment Wikipedia:Avoid_using_meta-templates#Vandalism as it is a bit self defeating?

An alternative would be to stop anonymous (or new) contributors from creating Templates.

NevilleDNZ 21:29, 11 January 2006 (UTC)

Hmmm... Stopping anons from editing in the Template: namespace seems like a good idea at first glance, just like regular users are prevented from editing in the Mediawiki: namespace.

Did you see Wikipedia:High-risk templates? — Omegatron 21:39, 11 January 2006 (UTC)

Restricting the Template space is sounding better to me all the time. After all, NevilleDNZ only had been here two months and made only a couple hundred edits before creating his templates. -- Netoholic @ 21:44, 11 January 2006 (UTC)

Hey... that was my idea... Are you trying to shoot the messanger? :-) NevilleDNZ 23:42, 11 January 2006 (UTC)

Misnomer

Can we start calling them "nested templates", "conditional templates", "style templates", and so on instead of "meta-templates"? "Meta-templates" would technically be templates about templates; not within, and it's being used for every different type at the same time. "Nested" is a much better word for the term meant here.

And yes, that's an article name change request, too, regardless of whether we prepend it with "avoid", "never use", or whatever.

I'm itching to just move it to Wikipedia:Avoid using nested templates, but I fear even this small change would lead to a vicious edit war. If another admin agrees, just move it, and the severity of the title can still be fought about in the above section. "Nested template", though, is a more accurate term for the object described in the first paragraph. — Omegatron 22:31, 11 January 2006 (UTC)

Wikipedia:Avoid nested templates would be more succint, but yes, I agree. —Ilmari Karonen (talk) 22:50, 11 January 2006 (UTC)

I agree with the rename to "Avoid nested templates". "Avoid using nested templates" is also ok. I would prefer "Avoid nested templates" over "Avoid using nested templates".--Ligulem 22:57, 11 January 2006 (UTC)

Is it an insect or a female relative? --Gareth Hughes 23:13, 11 January 2006 (UTC)

Heh. Fun with acronyms. :] --CBD _☎ ^✉ 23:48, 11 January 2006 (UTC)

prefer the female relative :) Tobias Conradi (Talk) 00:48, 12 January 2006 (UTC)

I prefer the insect. That also describes quite well my position in relation to WP:AUM :-). --Ligulem 10:07, 12 January 2006 (UTC)

Prefer to keep at present location over both those options. -- Netoholic @ 23:16, 11 January 2006 (UTC)

Note: I added template:Moveprotected on top of the project page because it is protected against moves. --Ligulem 09:34, 12 January 2006 (UTC)

Nope. reverting myself. Sorry. --Ligulem 10:29, 12 January 2006 (UTC)

CSS hack reduces accessibility

I just learned about the CSS hack being added to a number of templates, to compensate for a changed policy on template transclusion. I understand that there is an alternative, but this is being implemented because its easier.

This hack injects junk code into the body of the page, then hides it from most visual browsers using CSS. This makes Wikipedia less accessible for users of assistive technologies, like web page readers for the handicapped, and text readers. This is sloppy programming and bad practice from the point of view of usability and accessibility. Wikipedia is an open encyclopedia; please lets not start treating the minority who has the most difficult time reading like second-class citizens. —Michael Z. 2006-01-16 17:51 Z

Having web sites which are inaccessible also violates assorted corporate policies and laws, which might affect who is able to host mirrors. A related side effect is that if the MediaWiki does not support an accessible version of a desired feature then MediaWiki will be less likely to be used for non-Wikipedia sites. (SEWilco 19:04, 16 January 2006 (UTC))

EVERYONE - in order to quash this ForestFire, please follow-up discussion at MediaWiki talk:Common.css#CSS hack reduces accessibility. -- Netoholic @ 19:08, 16 January 2006 (UTC)

On Babel

Somewhere way up there on this talk page — someone who doesn't find the whole debate headache-inducing can find exactly where — it was remarked that the Babel templates break this rule/guideline/sharp note from the developers. Simply substing the Babel templates does not appear to break them — does this solve the problem, and if so, who volunteers to go and gently explain this to the folks over at the relevant WikiProjects, taking into account the fact it has, briefly and fruitlessly, been brought up before? ～J.K. 08:25, 17 January 2006 (UTC)

It's worth noting that the Babel templates aren't really any worse than other userboxes in terms of server load. In fact, using the Babel-N metatemplates even saves one template call compared to using {{Boxboxtop}} and {{Boxboxbottom}} and directly including the Babel boxes in between. —Ilmari Karonen (talk) 13:20, 17 January 2006 (UTC)

That said, an underlying problem is that Babel boxes on the English Wikipedia have their styles hardcoded into the templates. On some other Wikipedias (such as Italian) the styling is done with CSS classes, which makes the boxes much more cleanly substable. —Ilmari Karonen (talk) 13:31, 17 January 2006 (UTC)

As Ilmari Karonen explains, this is an example of a situation where something is a 'meta' (nested) template, but it really doesn't cause any notably greater strain to the servers than a non-meta template would. The difference between {{Babel-3 |en-4|de-1|qu-2}} and {{Babel-N |1={{User en-4}}{{User de-1}}{{User qu-2}}}} (or the 'boxtop' / 'boxbottom' method) in terms of server load is infintessimal. I'd like to see the numerous 'Babel-#' templates cut down to just a few, but in terms of server load I really don't see a significant problem with them. --CBD _☎ ^✉ 13:57, 17 January 2006 (UTC)

Complete rewrite

I think this policy needs to be re-written. The way it is currently written and applied are completely different and the issues are not spelled out properly. For instance, the policy defines meta-templates as "those that are created and used to keep other templates in a standard format". The 'meta' acutally makes sense for that definition, but it has since become common to call virtually any 'nested' template a 'meta-template'. The original true "meta" templates were generally just double transclusions like those on the Main page to keep templates being called in a standard size/format. At that time this was just a 'guideline' because there were some concerns that excessive use of such might cause problems if some standard formatting template were changed. Since then much bigger issues have been introduced by templates which don't 'format' anything, but instead handle conditional logic. Technically, these aren't even covered under the policy as currently worded... though they were actually the reason for upgrading it to a policy in the first place.

Further, the root problems driving the policy really have nothing to do with 'meta' or 'nested' templates per se... it is only the utility of those applications which makes them somewhat more likely to run afoul of the server issues. A 'simple' template can cause 'update' and 'rendering' problems every bit as great as any 'nested' template. As such, I'd suggest redoing this policy as something like Use templates wisely and specifically explaining the problems caused by updating templates which are linked from numerous pages and rendering templates which contain alot of template calls and/or parameter conditions. We should be working towards making less server intensive templates in general rather than trying to eliminate a certain (incorrectly defined) class of templates which are often, but not always, the biggest problems. --CBD _☎ ^✉ 12:47, 17 January 2006 (UTC)

Agreed. — Omegatron 23:49, 17 January 2006 (UTC)

Forcing Substitution?

UPDATE: Please see User:DCrazy/Force Static for a complete proposal. I realized that merely auto-subst'ing templates isn't enough to reduce the server stress induced by meta-templates. --DCrazy talk/contrib 21:03, 17 January 2006 (UTC)

Alright, why don't we cut a comprimise? Create a keyword like __FORCE_SUBST__, and whenever a template including that keyword is used, it is automatically substituted. Then someone who vandalizes, say, Template:User wikipedia, will not cause any damage whatsoever to existing pages nor cause additional server load by invalidating the cache. To make editing easier, templates could offset their content with comments, like < !-- Begin/End Template:Babel -- > (comment deliberately broken, for obvious reasons). We get to keep one of the most powerful features of Templates while eliminating most of their risk -- a fair tradeoff in my book. --DCrazy talk/contrib 14:20, 17 January 2006 (UTC)

Looks damned interesting. Um, you broke that comment here because it was too tedious for you to write <!-- Begin/End Template:Babel-->, right? --Ligulem 16:00, 17 January 2006 (UTC)

Heh. Forgot about HTML entities. Yes, that is what it would look like. --DCrazy talk/contrib 16:57, 17 January 2006 (UTC)

Next question: you mean that a template X that contains __FORCE_SUBST__ would then behave exactly as if one had writen {{subst:X}} in the edit window, even if one writes just {{X}} into the edit window? --Ligulem 17:12, 17 January 2006 (UTC)

That's the idea, though I'm not entirely sure if {{subst:X}} inserts X's source or its output given any parameters. The latter is preferable, because that means that, for example, all issues with templates that use {{qif}} aren't a problem if they are __FORCE_SUBST__ed. --DCrazy talk/contrib 18:30, 17 January 2006 (UTC)

Note that templates that use qif cannot be substed. --Ligulem 19:25, 17 January 2006 (UTC)

I've seen suggestions for this before and it would absolutely be a good thing to have - particularly for templates which are intended as once-offs ('welcome', 'test1', et cetera). As such... yeah it would be great if someone were to develop such a thing. It would probably do more to reduce server load than all of the 'meta-template removal' work going on now. However, there is another aspect of templates which this wouldn't address. Many, possibly even most, templates are used to create a common format for certain types of information. If those templates are subst'd then any future change to the format has to be made individually in each instance... rather just than the template being adjusted and all existing uses automatically updating. --CBD _☎ ^✉ 14:32, 17 January 2006 (UTC)

Yes but in one of the cases mentioned above the Welcome template for example... even if it changes in the future there is no need to update it on previous talk pages. Just as there is no need for updating a vandal warning. The point is across and while there will always be minor tweaks to the content the general message has made it across.  ALKIVAR™ 15:01, 17 January 2006 (UTC)

That's a great idea. Some templates are just fine subst'd, or should be in every case, but many should not be. The long-term damage done by subst'ing all those templates and removing their auto-updatability is worse than the short-term damage caused by server load. If we can offset the server load by always substing templates that should always be substed, we can relax about the others. — Omegatron 15:09, 17 January 2006 (UTC)

Using templates mainly for formatting suggests to me that there needs to be better usage of CSS classes for formatting and styling, as mentioned above by Ilmari Karonen. At present it is easier to create a template to do the formatting than to get anything added to one of the stylesheets as they are protected and the template namespace is not. Looking at common.css, changes are proposed at Wikipedia:Village Pump rather than any specific policy or discussion area. Maybe there should be a specific method whereby rules can be proposed by users, checked by admins to ensure that nothing breaks, that they degrade well and comply with accessible rules and added as per the request. just my €0.02 worth. – MrWeeble Talk Brit tv 15:17, 17 January 2006 (UTC)

Well, a lot of "formatting" issues aren't really formatting issues... {{Locale length}} is kind of both, in that it standardizes the style used for measurements but also provides content above beautification. {{Locale length) is an incredibly easy and obvious candidate for something along the lines of __FORCE_SUBST__. The more complicated a template gets, the less of a candidate it is for forcing substitution. But the great thing is that a lot of templates are complicated on the inside, but their output is not. Take, for example, {{Wikipedia:Babel}}. The source for that is hideous, but its output is a standard wikitable. This brings the question, does subst'ing a template insert its source or its output given its parameters? I really hope it's the former, because that makes all of our problems go away if we force subst'ing on numerous templates. --DCrazy talk/contrib 16:56, 17 January 2006 (UTC)

A "__FORCE_SUBST__" option has been proposed a few times in the past. The problem seems to be that you can't control where it gets inserted, and the vast majority of templates are on very few watchlists. If someone say added "__FORCE_SUBST__" to a highly-used but rarely-edited/low-watchlisted template, every time a downstream page was edited after that point, the template would be subst'd in. Editors may not notice for hours or days, at which point many articles would no longer be linked to that template. There's not much chance of recovery if that happens. -- Netoholic @ 18:45, 17 January 2006 (UTC)

I think the proper solution in this case would be to lock the Template namespace from editing by anons, but that's a WHOLE other can of worms. From a strictly technical point of view I think that __FORCE_SUBST__ is a good idea. Overall, taking things like vandalism into account, the picture gets muddier. --DCrazy talk/contrib 18:50, 17 January 2006 (UTC)

I'm not really saying this would only happen when a vandal/new user does it. Anyone who thinks innocently (but wrongly) "This template is better subst'd" could cause unrecoverable problems. -- Netoholic @ 18:55, 17 January 2006 (UTC)

Hrmm. Well, in that case maybe forcing substitution would be an admin-only privilege. That seems to work well with protection/semi-protection. And actually this is where the two problems merge: the technical issue is that meta-templates cause additional server load whenever one of the contributing templates is modified. Plain-old subst won't help since that creates a mess in the page's source and doesn't actually remove the conditions and other things associated with the template, offering zero benefit. The problem increases with the popularity of the meta-template. This catches the attention of admins.

But since the only real problem is posed by popular templates, and admins will be more aware of those (meta-)templates than the more obscure ones, giving admins control over forcing substitution (actually pre-rendering, as determined below) would offer a solution for the templates that cause the biggest problem.

The only remaining issue is what to do if page X includes force-subst'd template Y, someone vandalizes template Y, and then someone edits page X. This is an unrecoverable situation, which can only be mitigated (preventing anons from editing in the Template namespace, for example) but never eliminated. Proper guidelines would help immensely; templates that are extremely unlikely to change, such as {{Locale length}}, would be great candidates for force-substitution, and would need little to no debate before being implemented as such. --DCrazy talk/contrib 19:34, 17 January 2006 (UTC)

BLAST! Apparently subst: copies the template's source, not its output (just tried it on the sandbox using {{X1}} which included {{X2}} -- net result was {{X2}} in the source of the sandbox). So __FORCE_SUBST__ would require a different behavior than just mimicking subst: in order to be truly effective. --DCrazy talk/contrib 18:50, 17 January 2006 (UTC)

Nevertheless your idea goes in a good direction. See also my talk with Rick Block on a similiar theme. --Ligulem 19:25, 17 January 2006 (UTC)

• Note that WP:SUBST maintains a list of tempaltes which are bot-subst'd on a regualr basis. This is not the same as a would-be "__FORCE_SUBST__", but in many cases it does the job well-enough. Would it serve the desired purposed here, at least pending a feature implemetation? DES ^(talk) 20:45, 17 January 2006 (UTC)
  • Not really... see my article on the matter for why subst: doesn't cure all the ills inflicted by meta-templates. Bots that auto-subst are a great resource, but don't do everything necessary (unless someone were to write a bot that parsed the template and inserted its final, processed wikitext into the page). Still, it's a start. --DCrazy talk/contrib 21:03, 17 January 2006 (UTC)
    • If a bot running around updating all subst'd templates is more efficient and better for the servers than an actual template, why not just modify templates to make them behave like a bot? — Omegatron 22:29, 17 January 2006 (UTC)
      • Timing, consistency, surprised editors? But the general idea is marvelous. Just needs some further timbering. --Ligulem 22:36, 17 January 2006 (UTC)
      • I think what you're suggesting is that doing {{X}} would copy the end result of X into the document in all instances, and any changes to X would cause the software to spider through the encyclopedia and update the text. This is a few major problems: it would involve a full-text search of every page of Wikipedia, in all namespaces. Obviously this is not a good idea. Also, if someone changes a template to consist of the word "the", and then changes it to something else, the software will wind up altering every instance of the word "the". Cataclysmic, especially because this still means that changes are not revertable. Wikipedia would be irreversibly destroyed in literally less than one second. --DCrazy talk/contrib 23:13, 17 January 2006 (UTC)

        That's only a little bit crazier than the things people are doing right now.

        But that's not what I meant anyway. I meant that when a template is updated, the instances in each article's rendered version aren't updated instantaneously, or only updated when the page is edited, or something. Jamesday once suggested that a "feature" could be added to Mediawiki to turn off template transclusion completely during periods of intense server load (like search is turned off sometimes):

        The short-term technical expedient which is likely to work is adding a switch to turn off template expansion and flipping that switch, causing template text values to be displayed instead of template contents.

        So it doesn't seem unlikely to make an intermediate emergency switch that only turns off or staggers the template updating instead. The problem isn't the fact that templates exist, it's that the cache updating, in Jamesday's words, is "all grouped together in one big lump".

        Any technical kludge that saves the dependencies and structure of the templates while reducing server load would be better than these css-hack/weeblecode/subst'ing-everything-in-sight crocks. If the intermediate "switch" couldn't be written, I'd rather have the template expansion switch written, honestly. Turn off templates completely for short periods of time rather than go through all this fighting, revert warring, horrible kludges, and hostility. I wouldn't be surprised if the revert warring of templates over this page contributes more to the server load than the original problem. — Omegatron 02:33, 18 January 2006 (UTC)

    • Hmm. We could write a client side compiler for Wikipedians and use a higher level language to craft wiki pages. For article X we could put our new language ("wiki++"?) source under X/src and edit that, compile to article X with wiki++ templates expanded (of course wiki++ has "if", "or", "not" "switch", local constants and whatever we'd love to have). What exciting times this could be... (I'm a wanna be coder :-) --Ligulem 22:13, 17 January 2006 (UTC)
      • I'm sure you could do this quite easily with a java application. (NB I don't write java) [[Sam Korn]] 22:32, 17 January 2006 (UTC)
        • And then someone edits X and now X and X/src are out of sync. Recompiling X/src destroys X. --DCrazy talk/contrib 23:08, 17 January 2006 (UTC)
          • Yup, I know. Make a policy to only edit X/src? Or implement it in MediaWiki (a compile button!). --Ligulem 23:13, 17 January 2006 (UTC)
            • So basically all that does is replace wikitext with a different language. Users would edit in 'wiki++', which would be compiled to wikitext, which upon first page request would be converted to HTML and cached. That buys us nothing at all. --DCrazy talk/contrib 23:15, 17 January 2006 (UTC)
              • My idea would be along the line: Have wiki source to edit (includes template calls). Save expands all templates, store result and build html from that. So templates would only be updated to an article per editor request. Hyper luxory substing.--Ligulem 23:21, 17 January 2006 (UTC)
                • That seems ridiculously complicated. It would become far too difficult for newbies to edit pages. --bainer (talk) 23:24, 17 January 2006 (UTC)
                  • Why? The wiki source could be the same as today (with template calls). But we could use meta-templates because they would no longer hurt the servers. --Ligulem 23:29, 17 January 2006 (UTC)
                    • If you ban editing X directly, and instead make users edit X/src, and compile that to HTML on demand, how is that different from merely editing X? Currently users edit X, the wikitext gets stored in the DB, and gets compiled to HTML on first access (which is usually right after clicking the Save Changes button). So in effect, all you are doing is adding meta-templates and other good stuff to wikitext directly (whether the resulting set of features is called something else is irrelevant). To tell you the truth that would be the best idea, as the PHP engine would do ifs and stuff far better and faster than the wikitext parser. But barring addition of new tags to wikitext (<if condition=""> and the like -- would be nice and neat and lovely and fast and so on), forcing-static is the best soluition I can see. Wikitext would continue to function exactly as is right now, but the potential damages would be mitigated.
                      • Forget about that ugly X/src. That was just a crap solution I used to show my idea. I think it would be worth to spin our ideas to more detail. I also fear we might to some degree misunderstand each other and based on that reject an idea prematurely. What about working together on a page under my user space. For example: User:Ligulem/Lazy templates? I invite you (and anyone interested) to edit with me there. --Ligulem 23:48, 17 January 2006 (UTC)
          • That shouldn't matter. Auto-substing should only happen on templates that need to be substed. Templates that don't get substed (or wouldn't benefit thereby) will remain as now. [[Sam Korn]] 23:35, 17 January 2006 (UTC)
• Well, it may not be a force-subst, but if you check Wikipedia:Subst we do have a bot that auto-substs selected templates. Radiant_>|< 17:59, 18 January 2006 (UTC)
  • What I don't get is, if there is a bot, how can there be so many of the 'welcome' and 'test' type templates listed at WP:HRT? --CBD _☎ ^✉ 18:02, 18 January 2006 (UTC)
    • Probably because at the time HRT was written, those tls were still transcluded in many places (and at any rate, they're frequently used; a vandal could have a good laugh by messing up a test-template and it would be some time before the RC'ers might notice that their warning was off). WP:BEANS, I know. Radiant_>|< 18:10, 18 January 2006 (UTC)

Have a look at http://magnusmanske.de/wikipeerdia. This has the concept of stable versions. I suppose a stable version "freezes" a page and makes it immune against changes in transcluded templates. Looks very interesting (Although there's currently some bad error right now with that stable version thing). Stable versions also apply to templates, but I haven't yet figured out how that works. --Ligulem 19:48, 20 January 2006 (UTC)

Server load and developers

saved from Wikipedia:Village pump (technical)/Archive

"Policy" shouldn't really concern itself with server load except in the most extreme of cases; keeping things tuned to provide what the user base needs is our job. --Brion 01:01, 21 January 2006 (UTC)

I'm curious about something sort of related: have you seen WP:AUM? Is this not a case where a technical solution should be provided before we go off killing/changing tons of templates (in ways that increase bandwidth usage, or render poorly on certain browsers)? —Locke Cole • t • c 01:32, 21 January 2006 (UTC)

You should avoid metatemplates if they're ugly, hard to use, or fragile. That's just common sense; don't worry about "server load" for them.

For some very complex templates, people should probably be thinking about replacements for them such as proper data tables that will be easy for people to use and maintain, rather than hacking up ugly templates.

If someone's advising against "metatemplates" because they're ugly, fragile, and likely to break, listen to them. If someone's advising against them because they "increase server load", ask them for their benchmarks. I'd love to see them. --Brion 01:52, 21 January 2006 (UTC)

Jamesday has been widely interpreted (or perhaps overinterpreted) as suggesting meta-templates should be eliminated and his comments are responsible almost entirely for making WP:AUM into policy. Though I don't know for sure, the above questions may have been provoked by other recent comments Jamesday made about limiting image use in templates. It seems like Jamesday plus a number of non-devs have been pushing for editting policies (such as WP:AUM) based on minimizing server load, but your comments above seem to indicate we should not be worrying about server issues. So which is it? Dragons flight 02:05, 21 January 2006 (UTC)

I have to date refused requests to advocate the AUM "policy" based on server load because nobody's yet produced any evidence for this server load claim. While in a basic sense, calling two templates will involve twice as many template data loads as calling one, I've not seen any indication that this is significantly burdensome at realistic levels. If you can get James to produce a solid test for it, we'll talk about it. --Brion 02:12, 21 January 2006 (UTC)

Jamesday's concern in this area was more about invalidating page caches due to sub-sub-sub-templates being modified, and that change invalidating many pages. This, together with the level of complexity, fragility, and maintenance nightmare, are together why the WP:AUM is policy. -- Netoholic @ 02:26, 21 January 2006 (UTC)

Since our software doesn't actually do that at this time, and to do it we'd first want to set up a background process for invalidations which will make it easy and inexpensive, I don't see that as a strong argument from the load perspective. --Brion 02:32, 21 January 2006 (UTC)

First of all, this is not policy. No consensus of Wikipedians agreed upon it, and clearly not even a consensus of developers agree upon it. Second of all, the sub-sub-sub templates you speak of (such as {{qif}} should never (or only rarely) be modified). If the issue is only with sub-sub-sub templates, then it's a non-issue as far as I'm concerned. And in any event, server/technical issues should not influence editorial decisions except in the most extreme of cases (which it appears this is not). —Locke Cole • t • c 02:33, 21 January 2006 (UTC)

Just let me ask, what developer proposed this idea? How many developers have said it's a good idea? How can ordinary Wikipedians who nothing about the software deign to talk about making drastic changes to solve performance problems? You haven't made any measurements to evaluate the impact of this change and have no means of doing so, and so this is all just an elaborate theory that is more likely than not premature optimization in the wrong place. Deco 02:23, 21 January 2006 (UTC)

As far as I know, just Jamesday. If he's done any measurements he hasn't shown them to me. --Brion 02:32, 21 January 2006 (UTC)

Brion: can you go tell that to the people on the talk page there and remove the policy tag then since its a policy pushed against any attempt at votes etc.

Netoholic took a vauge set of statements from jamesday that weren't phrased at all as a demand and that he seemed to have little interest in substatiating with more details and used it to push that "policy" and it seems managed to get sufficiant support from gullible members of the admin team to push it into getting the policy tag against the wishes of much of the wider community. Plugwash 02:27, 21 January 2006 (UTC)

I've said that numerous times in the past. --Brion 02:32, 21 January 2006 (UTC)

BTW i think you really need to consider some promotions, the reason we get stuck with hacks like the if templates (and now the arguably worse hiddenstructure css) and css and javascript hacks everywhere is because we have a lot of sysops and very few developers. The result is that its much faster to get things done in a way a sysop can do through hacks involving css and javascript than it is to actually get them done properly (moderately important patches can take weeks to get committed even if a patch is written, nice to have stuff takes even longer. Plugwash 03:23, 21 January 2006 (UTC)

We've had a couple new devs come on recently; Rob Church has been applying fixup patches and such. --Brion 19:01, 21 January 2006 (UTC)

Wheee. Rob Church (talk) 07:48, 25 January 2006 (UTC)

Policy status

In these two edits:

1. 02:12, January 21, 2006
2. 01:52, January 21, 2006

Brion makes it fairly clear that server issues shouldn't affect editors like this, and as well, seems to indicate that he doesn't buy the server load argument presented by Jamesday.

Until such time as the developers agree, this absolutely must not be considered policy (and should not be "enforced"). —Locke Cole • t • c 02:28, 21 January 2006 (UTC)

I think you're reading into Brion's comments what you want them to say. I see him, especially in this comment, agreeing that there are several practical and technical reasons to avoid using nested templates, where one will work. WP:AUM is not built on any one factor... it is based on experience and precedent from WP:TFD, where we routinely vote to delete nested templates that are used in convoluted and impractical ways. Brion also does not comment on Jamesday's main complaint, about page caches becoming invalidated. There is also one other reason, that deeply-nested templates are rarely on more than a couple watchlists, making vandalism harder to watch for. -- Netoholic @ 02:54, 21 January 2006 (UTC)

That's a circular argument. AFAIK the deletion of nested templates at TFD hit full swing when you unilaterally (and without community consensus) promoted this to policy (under the guise of "developer approval"). Clearly not all developers (let alone Brion!) agree this is an issue. Note Brion's response: If someone's advising against "metatemplates" because they're ugly, fragile, and likely to break, listen to them. If someone's advising against them because they "increase server load", ask them for their benchmarks. I'd love to see them.. And I agree, if the argument is that they're ugly/fragile/likely to break, I'd give it some consideration. However, as Brion says, if the argument is that they "increase server load", it's a non-starter right now. If this is so slam-dunk obvious, it's bothersome that someone like Brion wouldn't want to endorse AUM. (But at the same time, he seems willing to consider it if someone will show him benchmarks proving the claims made).

Until these issues are resolved, and given the lack of community consensus in making this "policy", I strongly suggest keeping the policy tag off this page. I also suggest, as before, not "enforcing" this until the technical issues have been argued out. —Locke Cole • t • c 03:13, 21 January 2006 (UTC)

I did not promote this to policy - three separate Arbitrators did that, and other members of the Committee have said they agree completely. So, if you think you're reverting me, you've got it wrong. I can re-write the page to balance the server load issues described by Jamesday with other concerns. This is still a fine policy. -- Netoholic @ 03:28, 21 January 2006 (UTC)

This seems to address the server load issues, though. —Kirill Lokshin 03:39, 21 January 2006 (UTC)

anyone got a link to the arbitrators statements? i seem to remember they basically bought into the interpretations based on that single vauge statement from jamesday and promoted this to policy based ont that alone. With that basically shot down by the lead developer '"Policy" shouldn't really concern itself with server load except in the most extreme of cases; keeping things tuned to provide what the user base needs is our job'. IF it is believed that this should still be policy (or perhaps just guideline) based on other reasons then imo it needs to be rewritten based on those other reasons alone and then decided on as a per new policy. Plugwash 03:48, 21 January 2006 (UTC)

No links here, but IIRC it happened exactly as you described. Arbitrators bought into the argument (sans evidence) and were convinced to promote this to policy. I do think however that it was initially promoted by a non-arbitrator though... I'll have to go digging later. —Locke Cole • t • c 03:53, 21 January 2006 (UTC)

Developer statement

{moved from main page)
There's a lot of talk about this 'policy' which attempts to divine meaning from things other people have said rather than just asking for details.

Complicated templates-within-templates generally ought to be thought twice about before being used, because they can be confusing and fragile. There are some good notes about that on this page; please don't go all willy-nilly with illegible code just because it sort-of works.

There are other notes on this page about server performance which are not necessarily clear or well-supported. In particular, there's no known evidence that moderate usage of meta-templates has any noticeable impact on server performance.

While there are potential issues with cache invalidation, that's a separate issue which can be separately solved -- and is little better with "regular" templates.

I'd like to ask that anyone fighting against ugly, fragile meta templates at this time do so based on their ugliness and fragility. Please don't go around claiming "the developers" laid down the law and said nobody can use meta-templates because they hurt the servers; that just isn't true. --Brion 03:25, 21 January 2006 (UTC)

i have restored this statement to the main page and imo it should stay there until such time as the process arround this is restarted from scratch based arround the other issues. If developers really need us to change something they have direct contact with jimbo and the board so it should be a non-issue for them to implement it through proper channels with official statements. lets do as brion suggests and stop self crippling based arround vauge statements from a single developer or guesses by users as to what causes server load. Plugwash 04:34, 21 January 2006 (UTC)

Agreed. —Locke Cole • t • c 04:44, 21 January 2006 (UTC)

Feel free to take it off once it's served its purpose, but I think this page desperately needs some rewrite lovin', so replace it with something appropriate... --Brion 04:52, 21 January 2006 (UTC)

Thank you for your statements here. Though they have clarified some things, I think a lot of things are still heavily unclear. I have been forced by this policy and important wikipedians to work implement it (which I did working quite hard). I have started doing that by using the proposal of Netoholic, which has had his ArbCom ban lifted to push this to the "misguided masses". Now, could you please guide us? Abstract statements do not help here. We have ben said to be "wanna be" coders because we put up template:qif. Now we use the trick most favored by Netoholic as described in my doc. I agree that qif is ugly and I also agree that the CSS is ugly and I also agree that the weeble code trick is ugly. So which one shall we take? What shall we do with template:book reference? What with template:Infobox President and what with template:language? Your's puzzled and tired out, --Ligulem 09:45, 21 January 2006 (UTC)

Alternatives to "logical" or "conditional" meta-templates

I really, really think we should push for support of one of the ideas presented here. This would likely make templates (such as Template:Language) easier to read, and perhaps even provide a way for MediaWiki to optimize page creation. I'm not sure how we'd handle other forms of meta-template use, but this would probably address the most offensive use to those concerned. —Locke Cole • t • c 05:41, 21 January 2006 (UTC)

Another possibility (though the syntax is ugly IMO): m:User:AzaToth/Logic. —Locke Cole • t • c 07:50, 21 January 2006 (UTC)

Protected

We tried unprotection. Now we're back to an edit war. Work it out. --Woohookitty^{(cat scratches)} 07:41, 21 January 2006 (UTC)

I'll unprotect. Might've been a bit hasty. --Woohookitty^{(cat scratches)} 08:00, 21 January 2006 (UTC)

Brion's comment

General comments

It is worth noting that Brion continues to condemn meta-templates for being ugly and fragile - which they are - and falls miles short of endorsing them. It is questionable whether "should policy be crafted to reduce server strain" is something that falls within the realm of things the developers get to set automatically for us. It remains the case that Jamesday has said what he has said, and he did say to depricate qif, not start using more meta-templates, and that meta-templates cause noticable server load.

Since depricating the meta-templates we have has been COMPLETELY HELLISH, until this actually gets sorted out so that the developers are on the same page, since meta-templates do not add any functionality that can't be achieved other ways, since they are messy, since they are fragile, and since there remains a fair chance that they're a significant server problem, we still should not be using them, because we are sensible people who like playing it safe when it comes to asking if we should make big messes that take days to clean up. And when Brion and Jamesday present a unified answer, we can deal with that. But until then, we have clear comments from the lead database admin, and questions about whether that's the best reason to kill meta-templates, or whether they should just be killed for more superficial reasons from Brion. This is not grounds to add a giant box to the top of the page, and it is especially not grounds to start using meta-templates actively again. In fact, doing so would be SUPREMELY stupid, since there are clear alternatives. Phil Sandifer 17:53, 21 January 2006 (UTC)

Those 'clear alternatives' are equally 'ugly and fragile'... and not all that clear. Which is a good portion of why the efforts to force them through have been 'completely hellish'. That said, stopping all activity and getting some real/complete answers before proceeding makes sense... and would have a month ago too. --CBD _☎ ^✉ 18:09, 21 January 2006 (UTC)

I put a box on the page because there's been a lot of hysteria based on the false belief that there is an order from on high; just a quick skim of this gigantic talk page will show you that. I'd rather see this defused, and have people think for themselves and use some common sense. --Brion 18:10, 21 January 2006 (UTC)

Yes. Unfortunately, I suspect in practice you set off edit wars on about two dozen pages, 23 of which will be high-profile templates. Phil Sandifer 18:35, 21 January 2006 (UTC)

Agreed. Without some very clear, incontrovertible statements in a very visible place about what is allowed and what is not, the edit wars will continue and probably get even worse. These people will try to minimize your comments and do anything they can to misinterpret them in their favor.

The "ugliness and fragileness" will become the next bloody battleground. We need some clear direction here. The box was a good thing. — Omegatron 19:31, 21 January 2006 (UTC)

In my opinion, it's the most important reason. It's the main reason I cite when I ask for meta-templates to be removed. Where they're unnecessary ({{Main}} is an obvious example), they shouldn't be used because their effect can be achieved so much more easily in another way. [[Sam Korn]] 19:53, 21 January 2006 (UTC)

• How is that a meta-template??
• Other than server load, what's wrong with it? — Omegatron 20:19, 21 January 2006 (UTC)

Several things, off the top of my head. First, it's using a CSS hack to hide structure elements, which can fail for text browsers, plaintext renderings of articles, and any HTML display of the article that doesn't use the stylesheet on this site. This harms both the primary site's accessibility and offsite reuse of material. Second, as you can see its source is simply very ugly; it would benefit from a conditional or array construct. --Brion 20:28, 21 January 2006 (UTC)

What Brion said. Apart from that, it's really an unnecessary template. How hard is it to write a one line message to get the point across? It will almost always be more useful to the reader. [[Sam Korn]] 20:30, 21 January 2006 (UTC)

Um... let me just see if I understand this right Sam. You agree with what Brion said? That the current non meta version of Template:Main is very ugly, that it is harmful to accessibility and reuse due to the CSS hack method, and that it would benefit from a 'conditional or array construct'... which traditionally has been accomplished using meta-templating. So, would it be better to go back to the meta version? Or implement a 'weeble' variant? --CBD _☎ ^✉ 20:47, 21 January 2006 (UTC)

Once again, thank you for pointing this out. This is actually a bad example, because it shouldn't really be a template at all. As it is, I guess I'm not really that opposed to some simple additions to the code, so long as they are simple. I don't see the need for anything more than if/elseif/else. [[Sam Korn]] 20:55, 21 January 2006 (UTC)

So you agree that the CSS hack is bad? Me too.

Why do you say it shouldn't be a template at all? — Omegatron 21:48, 21 January 2006 (UTC)

{(Main}} is the perfect example of a template which is ridiculously over-thought. It shouldn't use meta-templates, it should not have to use CSS... It should be changed to work exactly like Template:Further - that is, to take exactly one paramter, and let people put howevermany and whateverdamn wikilinks they want. -- Netoholic @ 05:45, 22 January 2006 (UTC)

What is it hurting? — Omegatron 05:51, 22 January 2006 (UTC)

Have you read this thread? {(Main}} uses complex code (whether CSS or meta-template) where none is needed because the function can be done without any of that. -- Netoholic @ 12:41, 22 January 2006 (UTC)

You're operating under the assumption that complex code is inherently evil. How would you implement the function of {{main}} "without any of that"? — Omegatron 14:52, 23 January 2006 (UTC)

What I need from you

What I'm going to need from you guys is some feedback on what is and isn't needed/wanted. In particular:

• Conditional "if"-like constructs can be very easily done in the software, and should be more reliable than wacky template tricks. What other constructs are needed that don't boil down to a conditional include?
• Are there any genuinely useful constructs that would break if we limited the depth of includes to, say, two levels of templates? (Article -> Template1 -> Template2)
• We're never going to turn templating into a full-fledged programming language, but template constructs can sometimes benefit from array-like data where each item is processed identically. What are some examples of attempts to do this, and how could we more cleanly replace them?

Keep in mind that clean, legible use at the article source text level should be paramount. Scary complex templates can be quite intimidating for non-technical editors -- and even for highly technical editors who aren't familiar with a given 'extreme' template. At some point in the future we're likely to move towards more WYSIWYG-style editing as well, so minimizing complex 'magic' is good future-proofing. -- Brion 20:23, 21 January 2006 (UTC)

legible use at the article source text level should be paramount. Scary complex templates can be quite intimidating for non-technical editors

This could be rephrased as "complex template source is preferable to complex article source", right? If a template is easier for non-technical editors to use in articles, this is preferable, even if the template source code is more difficult to edit. — Omegatron 20:29, 21 January 2006 (UTC)

Clear article source and clear template source are most preferred! If you must make one or the other ugly, an ugly template source is better than ugly article source, since the template code will be edited more rarely and by fewer, probably more technical, people. Don't consider that a license to be unnecessarily ugly, though. :) --Brion 20:33, 21 January 2006 (UTC)

That's exactly what I meant. Some are interpreting this to mean that complicated markup should be put into the article source instead of the template source, because server load is more important than editability of articles, which seems obviously wrong to me. — Omegatron 21:51, 21 January 2006 (UTC)

Out of curiosity, is that WYSIWYG style of editing going to be like WordPerfect, with a "reveal codes" function? If so, I think that would be an exceptional way of doing things. [[Sam Korn]] 20:36, 21 January 2006 (UTC)

Brion, that's really great. I think the minimum set we need is:

• A string expression function "if". It takes two string parameters S1 and S2. The resulting value should be S2 if S1 is non-empty, the empty string otherwise. I do not care about syntax and name of the function.
• An expression function "not" with one parameter S. Returns a non-empty string if S is empty, the empty string otherwise.
• An expression function "or" with two parameters S1 and S2. Returns a non-empty string if S1 or S2 are non-empty.
• An expression function "and" with two parameters S1 and S2. Returns a non-empty string if S1 and S2 are non-empty.

The functions should be able to be nested. If needed we can limit the levels of if's. I have not seen more than an if inside an if. So I would set a limit to four levels (if needed).

article -> template1 -> template2 sounds reasonable to me, especially if we have built-in conditionals. --Ligulem 21:18, 21 January 2006 (UTC)

Just a sidenote: dbenbenn brought up the idea to strip <span class="hiddenStructure"></span> with MediaWiki from the html source (extending tidy). Maybe this could be used as a fast intermediate step? At least it would produce decent html without any syntax change. --Ligulem 23:04, 21 January 2006 (UTC)

That would be possible, but it's a rather slow procedure, so if implementing it's better to implement a faster construct instead. _→AzaToth 23:08, 21 January 2006 (UTC)

You're right. --Ligulem 23:10, 21 January 2006 (UTC)

Ehh, this is like logic gates; you don't even need all that. Or can be implemented simply by concatenating the strings (i.e. {{if|{{{par1|}}}{{{par2|}}}|result}}. And is similarly implementable by using a combination of nots around an if.

Strictly speaking, though, 99% of the current uses could be implemented with a simple if. —Kirill Lokshin 22:40, 21 January 2006 (UTC)

Well, yes and no. We already have a 'simple if' feature based on the 'blank parameter' trick. An example of this can be seen at Template:Language/familycolor. Because an empty parameter ('|if=') is passed in we can evaluate to see which other parameter exists and only display results for that one... a switch built on a simple 'if exists'. That can be used to replace pretty much every meta-template we have currently... but people have been very resistant to doing so. Largely because it involves changing existing template calls (as any new conditional implementation presumably would as well). However, it is also just a long way to go to get some results... for instance, you can do a 'not' condition if you have some parameter which is always passed by using {{{if{{{requ{{{optional|}}}ired|}}}|Text to display if 'required' parameter exists and 'optional' parameter does not}}}... but if you don't have any parameters which are always required for that template there's no way to do a 'not'. Likewise, the 'switch' example above has to perform the 'if' logic over and over again. You can do most things with a 'simple if', but we've already got that and while possible it isn't always easy/pretty. --CBD _☎ ^✉ 23:36, 21 January 2006 (UTC)

I made an example implementation for some extended syntax at m:User:AzaToth/Logic. My primary objective was to make a fast parser with monomal overhead. If none of the extended constructs are used the only overhead is a simple strpos. Othervise is rather simple in it's parsing, it just split the string and run it throught a switch statement. My reason to use a different syntax than ordinary wiki syntax is becaus then I can ignore the semantic of the wikicode and use the extended syntax as a preparser. I tried to create "functions" that are usefull for a wiki, the map-construct I made for the purpouse for use in for example Template:Main (edit|talk|history|links|watch|logs). _→AzaToth 20:44, 21 January 2006 (UTC)

I think AzaToth's implementation ideas above would make it possible to do virtually anything we currently do (and some things we don't) with a single template level (Article > Template). That said, even if it were possible to do everything with one level of transclusion (and no CSS hack or blank parameter trick) I'd think we would want to keep at least a few deeper levels available... even if they are not 'needed' they are still 'useful'. Without deeper transclusion levels the template functionality would have to be 'cloned' for each new template rather than just calling an existing template. Things like Template:clear could be used in articles, but not in other templates. That's a simplistic (and largely unneccessary) example, but the concept extends to all sorts of formatting/utility templates. The contents of Template:Oh My Goddess Infobox-Generic/Text could just be written out each time, but making it a template allows it to be called multiple times by two different templates... simplifying the template instruction code considerably while keeping the format consistent. Et cetera. Not required. Same capabilities can be done without the second/third/et cetera template layers, but it is often 'easier' / 'prettier' if you use sub-templates. --CBD _☎ ^✉ 21:28, 21 January 2006 (UTC)

Agreed. It's good to use a simple formatting/heavy markup/functionality template inside another to keep all the related templates consistent and easy to edit. Just like you would use include statements to put standard libraries in a bit of source code instead of typing all the standard functions in by hand, or use functions to perform the same operation over and over instead of retyping it manually each time.

It removes the "maintenance nightmare" of editing each template manually to change their style or fix a browser-specific problem with the markup, for instance.

We can certainly do without it, but it's tremendously useful if we can afford it. — Omegatron 21:59, 21 January 2006 (UTC)

On the subject of levels of includes: is there any distinction in MediaWiki between template transclusion and transclusion of pages from other namespaces. For instance, if we limit nesting to two levels, will Wikipedia: and Portal: space constructs like project page → project subpage → template1 → template2 fail? —Kirill Lokshin 22:57, 21 January 2006 (UTC)

All transclusion is treated the same. --Brion 23:31, 21 January 2006 (UTC)

"Are there any genuinely useful constructs that would break if we limited the depth of includes to, say, two levels of templates?" Hm. Template:USA uses Template:Country uses Template:Country flagcountry uses Template:Country flag alias USA, Template:Country alias USA, and Template:Country shortname alias USA. You could easily cut that down to 2 levels, by substing in Template:Country then in Template:USA. Anyway, that's the deepest level of nesting I could think of off hand. dbenbenn | talk 23:22, 21 January 2006 (UTC)

I agree with the idea below. We need equivalents of {{qif}}, {{switch}}, and {{booleq}}. If these aren't created, I'll have to continue using the current templates for them. -Xol 23:01, 25 January 2006 (UTC)

Simplest possible codeset

Unless I'm completely mistaken, the simplest possible set of options we need are:

• the equivalent of {{qif}}, a simple IF…THEN…ELSE implementation (which could even be implemented by hard-wiring the contents of {{qif}} into the transcluder) which supplies the contents of the "then" parameter iff the "test" parameter is a non-blank string, and the "else" parameter otherwise:

{{#if
 | test =
 | then =
 | else =
}}

• the equivalent of {{switch}}, a simple CASE…SELECT…DEFAULT implementation (which could even be implemented by hard-wiring the contents of {{switch}} into the transcluder) which chooses a parameter based on the first parameter, with a default:

{{#switch
 | test-string
 | case: foo =
 | case: bar =
 | default = 
}}

• the equivalent of {{booleq}} which supplies the string(s) being tested if they are equal, and a blank string otherwise:

{{#equal
 | test-string-1
 | test-string-2
}}

I'm suggesting using the {{#… construct because AFAIK this is not a legal name for a template (if I attempt to transclude {{#if}} it fails as you can see), so it wouldn't break anything already in place and it could easily be intercepted.

I think that this fulfils the requirements for the simplest possible set of constructs which would be useful, whilst avoiding the risk of becoming Turing-complete which I believe is what has some developers worried (and rightly so).

umm... if the current template system allows recursion (I haven't seen anything to the contrary yet...), would it not qualify as Turing-complete already? Latex, m4 and tcl are (or were) substitution-based turing-complete languages... --Martin Rudat(T|@|C) 15:30, 28 February 2006 (UTC)

I'm not certain that we need anything that "do[es]n't boil down to a conditional include", and I'm actually having a hard time imaging any such thing :-). As for looping constructs, I'm not convinced that these wouldn't become a handy vector for some sort of DOS attack. HTH HAND —Phil | Talk 08:33, 23 January 2006 (UTC)

Easy enough to prevent/curtail a DOS with a turing-complete template language... implement a step-count limit, like LPMUDs do to stop bugs (or malicious users) from locking up the driver. --Martin Rudat(T|@|C) 15:30, 28 February 2006 (UTC)

This is a very good proposal which I fully support. Thank you Phil. As for the simplicity and ease of reading of template code I would propose, if possible, to add logical functions as "not" "or" and "and" at least. These can be mimicked if we have that qif (but needs the "else" capability with empty "then" part, which is not supported by the actual qif hack template), but that leads again to unreadable template code. --Ligulem 08:47, 23 January 2006 (UTC)

I also support this. —Locke Cole • t • c 12:22, 23 January 2006 (UTC)

I can imagine plenty of uses for more flexible logic, but understand the 'Turing complete' concerns and would be willing to settle for something like the above. That said, more 'intelligent' templates could actually reduce server load and template complexity. For instance, the mathematical functions AzaToth suggested could do things like the 'meters to feet' conversion template as a simple one step calculation rather than a massive template nesting or huge parameter switch. Essentially, the simpler the codeset the more complex the templates need to be to produce the same functionality... and the more likely (some) people are to say that templates are too complex and launch crusades against them. --CBD _☎ ^✉ 12:34, 23 January 2006 (UTC)

a potential flaw in this code is that it can not output wikitable code, as that contains pipes which conflicts with the delimiters of the conditional template. Could an alternate delimiter be chose to enable syntax such as:

{{#if
  %test =  {{parameter}}
  %then = |-
          !The Heading:
          |{{parameter}}
  %else =
}}

<nowiki> is no good as of course we do want it to be wikified, but as a table, rather than as a parameter break - I chose % as it is (to my knowledge) not used for anything and can therefore be nowikied if it is needed. Plenty of other keys on the keyboard though – MrWeeble Talk Brit tv 18:55, 23 January 2006 (UTC)

In my example m:User:AzaToth/Logic, I'm using a optional delimiter diefined as {#[delimiter]func...#}, for example {#[$]if$foo$bar#} _→AzaToth 19:00, 23 January 2006 (UTC)

How about a variation:

{{#if
 ## test =
 ## then =
 ## else =
 #}}

(note the altered final token "#}}") Would "##" be a reasonable token to use to separate the parameters? Is it so vital that we replaicate the existing template syntax completely? —Phil | Talk 09:27, 31 January 2006 (UTC)

From my point of view the main thing that I think is most urgently needed is a conditional in the MediaWiki template language. I managed to implement that using ordinary templates midway through last year, and the result was hard to maintain (any subtractions or additions broke the template on multiple pages) and also very hard to input things into without precisely following instructions. The version with QIF functionality looks a little daunting at first when the template source code is viewed, but that is why {{esoteric}} is on the template page as a warning against editing the source without understanding what is going on. The implementation on the main namespace pages is clean, consistent and easy to understand. The QIF version is easier to maintain, since additions do not automatically break the template.

I would say that main thing that we are look for here is ease of use in the main namespace. That is where most newbies will edit and if we can get rid of table markup there and replace it with easy to understand template markup then it will actually be a boon to newbies. I would doubt that many newbies particularly know or care about the template namespace, and by the time that they do know and care they have generally acquired enough of an understanding of MediaWiki syntax and markup to have a decent shot at editing things without breaking even complicated templates.

Netoholic seems to be engaged on a crusade about this matter. Since the main pillar of support for the crusade has been significantly undermined Netoholic has even started to claim "ownership" over pages, which is against Wikipedia policy in and of itself. That is a serious problem.

I would appreciate it if IF functionality was incorporated at a language level in MediaWiki template markup asap, and I look forward to the day that it is implemented (since Netoholic aside there seems to be a consensus that it is a needed feature). David Newton 13:31, 24 January 2006 (UTC)

The good point that David has just brought up is that conditionals often allow us to make the in-article template call a lot cleaner. Of course, the price is paid in the wikitext of the template. However, people are more likely to view and edit the wikitext of the template call rather than the template itself. For example, template:language has a box to display the language's genetic classification. Before the use of conditionals, the entire family tree was plugged into a single parameter with lots of &nbsp; in the template call to provide formatting. Conditionals allowed us to move all of the formatting into the template and provide each line of the family tree with a separate parameter. Conditionals were needed because the number of lines in the family tree differs from language to language. --Gareth Hughes 13:54, 24 January 2006 (UTC)

Surprise, surprise, Netoholic has reverted my reintroduction of QIF to Ship table claiming in the edit summary comments that, "developer comments still ask us to avoid meta-templates - they are ugly and fragile". I have posted to Netoholic's talk page pointing a version of Ship table from before QIF came along. THAT was ugly and fragile. The current conditionals, within the syntax of the MediaWiki template language and table code, are elegant in their implementation. I would not want to touch the conditional templates themselves, but once they are feature complete (and at the moment that is pretty much the case for those that remain), they should be protected until those that are appropriate can be hardcoded into the system. I agree with those who say that we don't want to be Turing-complete, but it is a tribute to those who originally conceived the template syntax that we can even talk in those terms!

If we are to have complexity beyond the ken of some people (and given computer systems that is bound to happen at some point) then make sure that it is documented well and coded well. {{esoteric}} is also an extremely useful warning to those who try and go beyond their depth. David Newton 16:45, 24 January 2006 (UTC)

Looping construct

I have just discovered a situation at the Help desk which would seem to indicate a possible application for some sort of looping construct. This is for where you have the following kind of situation:

---Header---
---Row 1 ---
---Row 2 ---
---Row 3 ---
---Row 4 ---
………………………………
---Row n ---
---Footer---

where each of the Row i parts is structured the same and depends on the same number of parameters.

The example they give is like this:

{{User:Jnothman/tiZom_olymp/top}}
{{User:Jnothman/tiZom_olymp/gold|[[1992 Summer Olympics|1992]]|Barcelona|Athletics|Men's 4x400m Realy}}
{{User:Jnothman/tiZom_olymp/gold|[[1996 Summer Olympics|1996]]|Atlanta  |Athletics|Men's 200m}}
{{User:Jnothman/tiZom_olymp/gold|[[1996 Summer Olympics|1996]]|Atlanta  |Athletics|Men's 400m}}
{{User:Jnothman/tiZom_olymp/gold|[[2000 Summer Olympics|2000]]|Sydney   |Athletics|Men's 400m}}
{{User:Jnothman/tiZom_olymp/gold|[[2000 Summer Olympics|2000]]|Sydney   |Athletics|Men's 4x400m relay}}
{{User:Jnothman/tiZom_olymp/bottom}}

wihch yields:

Gold medal	1992 Barcelona	Athletics Men's 4x400m Realy
Gold medal	1996 Atlanta	Athletics Men's 200m
Gold medal	1996 Atlanta	Athletics Men's 400m
Gold medal	2000 Sydney	Athletics Men's 400m
Gold medal	2000 Sydney	Athletics Men's 4x400m relay

where as you can see there's a top, a bottom, and a variable number of rows, each structurally identical (even if the actual details vary from row to row). What, if anything, would be a sensible way to approach this? HTH HAND —Phil | Talk 16:36, 26 January 2006 (UTC)

Think Babel boxes. There are a few different ways to construct them which map directly to this scenario;

1. {{boxboxtop}}{{User en-1}}{{boxboxbottom}} - Same structure as the above; separate templates for top, bottom, and rows. The rows then just get called however many times are needed. Requires multiple template calls.
2. {{Babel-1}}, {{Babel-2}}, et cetera - Separate templates for each variable number of rows. By setting a 'count' type parameter you could set up a call to {{Babel-{{{count}}} |parameters}} which would always call the correct sub-template. However, the count and the number of parameters passed need to be kept in synch or you get rows being ignored or blank rows being displayed.
3. {{Babel-N}} - Similar to item 1 above except that the rows are passed as a parameter to a template which then builds the top and bottom around them. Just as long as option one, but all the template calls are in one long stream.
4. {{Babel-X}} - Similar to item 2 above except that it adds conditional logic to suppress any unused rows. Requires use of 'qif', '|if=', 'display: none', or other conditional logic to suppress the extra rows.

None of these options are perfect, but they handle these types of scenarios pretty well currently. --CBD _☎ ^✉ 17:35, 26 January 2006 (UTC)

Conditionals are not really needed

I do not support any proposal to add conditionals. People are over-thinking how templates are used, and I can describe, for any potential usage of conditionals, options which are easier on both template geeks and editors. I challenge anyone to come up with something that actually requires conditionals. -- Netoholic @ 12:18, 23 January 2006 (UTC)

Boy, no one saw that one coming... — Omegatron 14:52, 23 January 2006 (UTC)

Uhm, an infobox which wants to allow optional parameters. —Locke Cole • t • c 12:20, 23 January 2006 (UTC)

Solution: remove those parameters that are not common enough, or split the template into multiple similar ones with different options. Selective hiding of empty data rows is a "nice to have", but the infobox should make complete sense with them visible. -- Netoholic @ 12:27, 23 January 2006 (UTC)

Multiple similar templates == confusing. Removing parameters == disappointing to editors affected. I'm sorry, your solutions are totally unacceptable. —Locke Cole • t • c 13:09, 23 January 2006 (UTC)

Only confusing if there is lack of documentation. Only disappointing if the editors adding the extra optional parameters lose focus of what the infobox is designed to do -- display data consistently across related articles. If an option is not common enough, remove it and document in article text. We already have several infoboxs about "people" (politician, wrestler, adult film star...) - these are not confusing or disappointing to the editors. -- Netoholic @ 13:25, 23 January 2006 (UTC)

Netoholic, the CSS hack is not a viable option. It is causing problems for people with Lynx browsers, people with screen-readers, people on other language Wikipedias who copy over templates but haven't updated the common.css, et cetera. It is a complete mess. That leaves 'qif' style meta-templates or the '|if=' blank parameter trick... and you've ranted about both of those often enough for it to be clear you aren't advocating them here. So the only other options are built-in conditionals or scrapping hundreds of templates which make life much easier for the users in favor of doing everything manually. The latter is a non-starter... so get behind built-in conditional logic, 'qif', or '|if=', because one (or more) of those is going to be used extensively going forward. --CBD _☎ ^✉ 12:26, 23 January 2006 (UTC)

Edit conflict, see my 12:27 response above. Give me a specific template and I will describe how precisely we can go about making it better. -- Netoholic @ 12:29, 23 January 2006 (UTC)

Template:Taxobox. It would be absolutely ridiculous to have a separate template for Kingdoms, Phylums, Families, Genuses, Species, et cetera OR to show each of the different classifications as blank for every life form/group. One template with conditional text is vastly superior to any 'alternative'. --CBD _☎ ^✉ 12:39, 23 January 2006 (UTC)

Solution: Has already been solved. Blank (hiddenStructure) classification rows are presently used and are perfect for that template. Looks only mildly large on lynx, but that has been improved lately. The rate at which that is being accepted by editors is amazing, and I anticipate one day that a bot will make a run against the articles and convert them all to it. (added: Note also the talk page, where it's mention that it's being copied to the Turkish Wikipedia. Expect more.) -- Netoholic @ 13:25, 23 January 2006 (UTC)

Note also my comment on reverting it back to the meta-template version which worked fine long before you came along, and rendered wonderfully in Lynx without CSS. Also note that the person copying it to the Turkish Wikipedia had to have the deal with CSS hacks explained to him before he could get the template to work there... expect to meet a lot of resistance with these CSS hacks, let alone any attempts at running a bot to mass convert anything. —Locke Cole • t • c 13:35, 23 January 2006 (UTC)

So, you start out claiming that conditional logic is not needed and then, when faced with proof that it is, claim that the 'hiddenStructure' CSS hack solves the issue... despite the numerous problems with it. Yes, after adjustments were made to get the CSS version of taxobox working right in CSS compatible browsers it has been widely used... which doesn't mean anything. The 'qif' template is widely used too... anything which works for most people will be widely used. The 'qif' approach has the advantage of being easier to follow and working for more people than 'hiddenStructure'. People have used 'hiddenStructure' only because it has been claimed that they have to. Now that they don't... there is no good reason to use something which doesn't work right. --CBD _☎ ^✉ 13:51, 23 January 2006 (UTC)

Resistance? Are you kidding? I find templates all over now that I never touched, yet have on their own incorporated the hiddenStructure method. It is editor-friendly. The Turkish contributor needed some guidance, but he obviously still likes it and has put in a request to change common.css on his home wiki. Some centralized documentation may help in the future, but that's all. -- Netoholic @ 13:45, 23 January 2006 (UTC)

I see you're so confident in this that you're resorting to personal appeals to Brion to try and stop conditionals from being added to MediaWiki. If these conditionals are handled right, they'll result in less complexity than we have with meta-templates so my question to you is: why are you fighting this? You bemoan the need for less complexity, while pushing CSS hacks that are arguably as complex as the meta templates (code-wise anyways) that result in more complex output for browsers to deal with. So why fight this? It's good for the servers, it's good for editors, and it's good for browsers. Win/Win/Win. I do not see the problem here at all.. —Locke Cole • t • c 15:47, 23 January 2006 (UTC)

hiddenStructure is incredibly simple in a typical Infobox scenario, as evidenced by the self-proliferation it's inspired. -- Netoholic @ 17:26, 23 January 2006 (UTC)

Yes, it's so simple that if you use it properly, it spews out a bunch of crap in the output. If you use the more recent "clever" method where you trash the HTML tag attribute, you get rid of some of the crap being output, but you place a burden on Tidy (or alternately risk outputting non-standard XHTML). And don't be proud of the proliferation it's inspired; this method is an accessibility nightmare, and you should be ashamed of yourself.

I sincerely hope we can undo the damage done and have hiddenStructure removed from MediaWiki:Common.css. It's an abomination. —Locke Cole • t • c 02:13, 24 January 2006 (UTC)

The accessibility argument again. How very... dramatic. I've been thinking of accessibility for a long, long time - even started the Wikipedia:Accessibility page itself. You should be ashamed for even insinuating that I don't care. The accessibility issue is only a factor because there is no editable stylesheet available for non-visual displays. -- Netoholic @ 04:17, 24 January 2006 (UTC)

Not dramatic at all; a point of fact that you claim to be concerned with but frequently ignore. You "started" Wikipedia:Accessibility barely three weeks ago. I'd hardly call that proof that you've been "thinking of [it] for a long, long time". And if you really do think about it so much, how on Earth could you promote something that others have told you is broken for disabled readers? —Locke Cole • t • c 05:15, 24 January 2006 (UTC)

Just for completeness, here are Blue Whale in Links: _→AzaToth 17:44, 23 January 2006 (UTC)

And a w3m session for comparision: _→AzaToth 17:52, 23 January 2006 (UTC)

With all due respect, the CSS hack is inadquate for the needs of many infoboxes. Might the supposed consensus of usage that you are seeing, perhaps be caused by the fact that you unilaterally revert alternate methods without discussion? I am not saying that those alternate methods are any better, but to say they are un-needed is patently ridiculous. – MrWeeble Talk Brit tv 18:36, 23 January 2006 (UTC)

The acceptance of the CSS hack is also partly because the users most affected by it, text-only browser users, blind users, search engines, non-editors of Wikipedia, don't have much of a voice in how templates are coded. Nevertheless, they constitute an important minority. The fact that editors have to make special requests to alter their local Wikipedia's style sheets to hide junk text in the page content indicates what an appalling hack this technique is. —Michael Z. 2006-01-23 19:49 Z

Policy/Guideline status

I think we need to edit this down a bit before we slap {{guideline}} on it. Specifically, the section titled "Use of meta-templates" likely needs to be totally rewritten in light of the dispute over server effect/load. I propose we work on a rewrite at Wikipedia:Avoid using meta-templates/Temp, then move that in place once we're in agreement (and then place {{guideline}} back on it). —Locke Cole • t • c 00:54, 22 January 2006 (UTC)

Do we even need this page? If the server load issue isn't really an issue, then this page should have a {{historical}} tag. That's the only reason it existed in the first place.

The parts that are still applicable can go to Help:Template or How to use templates efficiently or something like that. — Omegatron 01:25, 22 January 2006 (UTC)

I think we can all agree that overly complex meta-templates (be it complexity from multiple levels, or complexity from nesting calls to templates within other templates) should be avoided (emphasis there, not outlawed, not banned, not disallowed, but avoided). I just think the language in use now leans too much in favor of zero-tolerance for meta-templates. Certainly if there's agreement though we could place {{historical}} on it. But we should probably wait for Jamesday to have a chance to respond with the information Brion requested. —Locke Cole • t • c 01:34, 22 January 2006 (UTC)

I've taken what's on the main page now, hacked off a good chunk of it, and started a rewrite at Wikipedia:Avoid using meta-templates/Temp. (I've also redirected the talk page there back here). Feel free to discuss changes or edit as you see fit (we can discuss any issues that crop up as we go). —Locke Cole • t • c 09:51, 22 January 2006 (UTC)

I think we should stop fiddle around with this page until we know more from Brion. Ugliness and fragility is not that helpful as a guideline. The policy tag is gone and I'm also happy with the removal of the guideline tag. I think that's it for the moment. If we edit here too much we just end in another useless content dispute. The comments about meta-templates from Brion and his expression to implementent conditionals in MediaWiki speek for itself. These are the most important two things. --Ligulem 10:18, 22 January 2006 (UTC)

I'm not comfortable with that. Brion is a paid developer. He's paid to make Wikimedia work well. Of course he is going to defend how well Wikimedia is working because anything else reflects on him. Jamesday is a database developer and knows full well how "costly" database reads are over other operations. Both agree that we should reduce template calls where necessary. The developers are not disagreeing - Jamesday describes the theory behind it all, and he's right. Brion wants to be shown proof that Wikipedia is actually being affected, and he's right. Both are in total agreement that complex code should be avoided for the editor's sake. This page is just one more guideline for good use of templates. -- Netoholic @ 12:25, 23 January 2006 (UTC)

Brion has specifically stated that editorial decisions should not be driven by speculative technical considerations. If you think that a specific nested template is ugly, badly written, etc., then that is a perfectly reasonable ground to oppose it. But, given the new clarification, it is no longer reasonable to say to get rid of all nested templates simply on the ground that they are nested. It is simply an editorial decision at this point, not policy. There was a community consensus that we would do what was necessary to protect the servers; there was never a consensus that nested templates were bad in and of themselves. The only justification for banning them as a policy was that database dev James Day asked us to stop, and this has since been seriously questioned by the lead developer. Crotalus horridus (TALK • CONTRIBS) 21:24, 24 January 2006 (UTC)

We all seem to agree they should be avoided where possible. what we don't agree on is at what cost. we've already had at least one complaint from a screen reader user about the hiddenstructure css. its really hard to move away from meta templates (and other structures that cause lots of template invocations like that currently used for taxoboxes) without proper if support or creating a maintinanace nightmare. Plugwash 15:15, 23 January 2006 (UTC)

That screen reader's problem seems rooted in the current fact that the main.css (and any other downstream like Common.css) are of type "media: screen, protector" - and aren't applied. MediaWiki may need to change to make available editor-controlled CSS for screen readers. -- Netoholic @ 15:49, 23 January 2006 (UTC)

If were talking changing the source we may as well just do "if" right and then we can eliminate both abominations of {{qif}} and "hiddenstructure" (which no matter what excuses you make is misusing css to do something that should be done at page-build time). Unfortunately getting changes into the source is a damn hostile process. First you have to deal with a large virtually undocumented (at the code level) project written in a crappy web scripting languge. then once you've managed to actually change it you have to try and get the devs to look at the patch and apply it (even with much nagging and a fairly imporant patch this can take weeks). Plugwash

Brion has expressed openness to including conditionals in the MediaWiki engine. This is almost certainly a better solution in the long run than either template hacks or CSS kludges. Crotalus horridus (TALK • CONTRIBS) 21:24, 24 January 2006 (UTC)

Page focus

This (policy/guideline/proposal) page is named "Avoid using meta-templates". Its predecessor was named "Meta-templates considered harmful". If you do not agree with the statement in the title, you should not be editing this page to present your alternate view. People have asked for a re-write which tempers Jamesday's and Brion's statements, yet I can't make a change to this page without it being reverted within five minutes by people who advocate using meta-templates. -- Netoholic @ 15:09, 23 January 2006 (UTC)

That's a goofy argument: so where should people go who disagree with, for example, the blocking policy? Someplace else? Maybe your changes are getting reverted because you lack consensus? —Locke Cole • t • c 15:17, 23 January 2006 (UTC)

Indeed, it's circular reasoning. Both the current and prior titles listed above fail to adequately describe the situation. As such, the title will likely need to be changed (to something like 'Use templates carefully') once the particulars have been sorted out. --CBD _☎ ^✉ 15:38, 23 January 2006 (UTC)

This page's history (I know cause I wrote most of it) is on the assertion that meta-templates are bad. This page will stay that way. Go start another page if you want to evangelize bad template practices. The subject of this page is clear - only it's status as a policy/guideline or just proposal is determined by the consensus of editors. It should not be renamed; instead, those that like meta-templates should create an equivalent page. -- Netoholic @ 15:46, 23 January 2006 (UTC)

If you want it to stay here, and to remain a one-sided argument against meta-templates, then it will have to be marked {{rejected}} on the grounds of lack of community consensus. Crotalus horridus (TALK • CONTRIBS) 21:32, 24 January 2006 (UTC)

Wrong. The page will be shaped into what the consensus agrees with. If you want to write an essay on the evils of meta-templates, do that; but note well, even there, you are still subject to consensus. —Locke Cole • t • c 15:48, 23 January 2006 (UTC)

THIS PAGE is my "essay" on the evils of meta-templates. -- Netoholic @ 15:49, 23 January 2006 (UTC)

Yeah we remember when you were forming it all the revert wars you got into pushing your interpretation of jamesdays statement into this "essay" and eventually managing to convince the arbitrators into accepting it. It shows what a strong enough revert warrior can achive with regards to getting what they wan't on a wiki especially one thats as reluctant to block as wikipedia.

Pages in the project namespace (with the exceptions of things like the village pump which are essentially talk pages in all but name) should represent either descisions from the board or jimbo (or possiblly at a push the head developer if its urgent) or community consensus. This "policy" never did either it reflected one persons interpretation of a few vauge and certainly not official seeming statements from jamesday. —The preceding unsigned comment was added by Plugwash (talk • contribs) 2006-01-23 17:04:22 CET.

And, as I mentioned, even an essay would be subject to consensus. —Locke Cole • t • c 16:11, 23 January 2006 (UTC)

No, it is perfectly reasonable to have contradictory pages in the Wikipedia: namespace - and there are already several. Consensus is important only when you want to move a particular page into the guideline/policy realm. -- Netoholic @ 17:23, 23 January 2006 (UTC)

Netoholic, please reconsider in light of WP:OWN. If you want a 'personal essay' it should be in your own user space. So long as this is out here in the Wikipedia namespace your claims of ownership are completely inappropriate. --CBD _☎ ^✉ 17:06, 23 January 2006 (UTC)

Don't quote that page to me. I wrote this page and have welcomed additions which assert the position in it's title. Go work on another page. -- Netoholic @ 17:23, 23 January 2006 (UTC)

Neto, what's the problem with you? _→AzaToth 21:33, 23 January 2006 (UTC)

Personal editorials belong in user space. If the consensus dictates moving, rewriting, or changing the message of a page in Wikipedia space, so be it. —Michael Z. 2006-01-23 20:26 Z

This is by no means "personal" as other editors here agree with "avoid using meta-templates". The problem is that some are basically turning this page into "We ♥ Conditionals" rather than presenting solutions to the scourge of meta-templates based on the present feature set of MediaWiki. -- Netoholic @ 20:35, 23 January 2006 (UTC)

Having converted this from an essay into a policy page (without broad consensus, on the claim that this was mandated by the developers, which now seems to have been a misunderstanding) and used it to force or try to force the deletion of many conditional templates, and the editing of many other templates not to use conditional or nested constructs, IMO this has become the proper page for whatever policy finally attains consensus (within the limits of board or developer mandated restrictions, if any). If that policy ultimately favors the sue of conditionals either broadly or within narrow limits, this page should IMO become the place to say so. If you want to create Wikipedia:Arguments against conditional and nested templates, anc to copy onto such a page much content that has been on WP:AUM, feel free. DES ^(talk) 20:59, 23 January 2006 (UTC)

A signifant number of pages refer to this page from a very specific standpoint and context. Conditionals have nothing to do with meta-templates, except that proponents of conditionals used meta-templates. Instead, any talk of the benefits or drawbacks of conditional templates should be moved to Wikipedia:Conditional expressions. -- Netoholic @ 21:56, 23 January 2006 (UTC)

I seem to recall that not so long ago you were defining "meta-templates" to include any conditional template, however implemented. Perhaps I misunderstood. In any case the arguments in favor or agaist both nested tempaltes and conditional templates seem reasonably to belong here as much as anywhere. I note that Wikipedia:Conditional expressions is at the moment simply a how-to page on implemeting the CSS Hiden structure method of implemtign limited conditional functionality. This makes it IMO a poor place to discuss the merits and costs of conditional structures in general, and of implementing such in the mediawiki software, unless the current content is moved to some other location (which might be a good idea, as it currently gives the incorrect impression that Hidden Structure is the only way to achieve such effects).

This page's title is "Avoid using meta-templates" ... it is off-topic to advocate them on this page and it sure as hell would result in fewer goddam reverts by those who support meta-template use. Let's each side document our position and let time tell. -- Netoholic @ 22:15, 23 January 2006 (UTC)

If you want to write a personal essay about templates, it goes in your userspace. This page will be about the best use of meta-templates in Wikipedia, and is subject to consensus. The title will be changed if the content changes from an "avoid" stance. — Omegatron 22:42, 23 January 2006 (UTC)

To call what you are doing "consensus" is nonsense. This is just another way to undermine the intended purpose of this page. It's a dirty tactic, when a lot of grief would be avoided by working on parallel guideline proposals. -- Netoholic @ 04:13, 24 January 2006 (UTC)

Do you understand what consensus means? It means working together to make a page that represents everyone's views (or the developers' views on purely technical matters, as you were so happy to point out a few months ago). You don't own the page just because you wrote the first revision. It's in the Wikipedia: namespace; it doesn't matter what your "intended purpose" of the page originally was. You can't just edit it to remove everyone else's viewpoints and include only your own. If you want to write an opinion piece, it goes in your userspace. You do understand this, right? Do you?

Regarding "parallel" guideline proposals: What are you suggesting? You want to write up an anti-meta-template proposal and have others write a pro-template proposal and have them duke it out in the arena of popular opinion? Seriously, who do you think would win? What does that imply about your viewpoints? — Omegatron 05:14, 24 January 2006 (UTC)

I don't care about winning. I care that people coming to this page in the future hear a coherent position which matches the "Avoid using meta-templates" title. -- Netoholic @ 05:32, 24 January 2006 (UTC)

Probably that title should be altered to a more neutral one such as "guidelines on the sue of conditional and nested templates". DES ^(talk) 16:51, 24 January 2006 (UTC)

I don't think the policification of AUM was based on a misunderstanding. It was based on the opinion of a developer. There was no misunderstanding. Whether it is now contested is a different matter. Sam Korn ^(smoddy) 21:45, 23 January 2006 (UTC)

Unless I have misunderstood, the policy designation was based on the impression that there had been a fairly absolute dictat from one of the key developers, and that this was supported by all the other key developers. The second point of this now, seems, at a minimum to be no longer true, if it ever was. DES ^(talk) 22:11, 23 January 2006 (UTC)

I don't think you'll disagree, though, that it was the correct enterpretation to make based on the evidence at hand. That was what I was saying. Sam Korn ^(smoddy) 17:25, 24 January 2006 (UTC)

(after edit conflict): Actually i thought at the time that it was being interpreted as more final and definate than the wording of Jamesday's coment justified. Others also thought so and said so. But the reason I used "misunderstanding" is that that interpetation seems to have been incorrect, which may have been casued by unclear communication on the part of Jamesday, or a disagreement on this subject betweem Jameday and Brion, or some other failure of communication or intrepretation. I presume that Netholic and others who took Jamesday's statement as a basis for applying apolicy tag were acting in perfect good faith, accodign to their best understanding of the evidence at hand. Whether that was fully justified by the evidence then at hand is now moot, since we have Brion's later statemetn, which contradicts the previosu interpretation on which a policy of "all conditional and most nested templates must be removed" was based. IMO this page should now be used to give ourt current guideleines and sugestions on when and how to use conditional and nested templates, adn when and why to avoid their use. As such it ought to reflect consensus, or if there is no consensus, all significant points of view. Perhaps it should be renames to Wikipedia:Conditional and nested templates or some similar neutral title. DES ^(talk) 17:56, 24 January 2006 (UTC)

Agree with the suggested move. — Omegatron 19:51, 24 January 2006 (UTC)

Not really. In case you didn't notice, a lot of people opposed the attempts to make it policy, even though they had read Jamesday's statements (1, 2, 3) themselves. All we had to go on were his statements, which he didn't follow up on, and which did not mandate any policy or claim the support of all the developers or set out a clear statement of what should be done. Most were of the "I think we should avoid things as a temporary expedient"/"using excess resources is bad" flavor. Netoholic made up his own interpretation of those statements, and ArbCom members apparently interpreted this as a clear absolute mandate from all of the developers and gave him license to do whatever he wants.

Whatever. In the meantime, any attempts to rewrite the page are kind of pointless. We still need clear statements from both Brion and Jamesday to figure out exactly how much complexity the servers can handle. If there really is no problem with the servers (as Brion has stated), then it goes back to the matter of whether the increase in template complexity (including future changes to the software) is worth the article editing advantages, which can be decided by community consensus between regular editors. — Omegatron 17:47, 24 January 2006 (UTC)

Agreed, this is why I haven't really touched the rewrite much (though I think I've cut it down to just the concerns that will be relevant if the server load issue turns out to be irrelevant). —Locke Cole • t • c 17:54, 24 January 2006 (UTC)

Netoholic, if you want this page to remain a straightforward argument against meta-templates, I see one clear way to do this. We can mark it with a {{rejected}} tag, given its lack of community consensus, and you may express your opinions there. (Alternatively, we could userfy it to your user space.) Then, after that, we could create a more general page, maybe Wikipedia:Template guidelines or something of that nature, where the meta-template issue would be handled in a more reasonable manner in accordance with community consensus. My concern with your above statements is that you seem to be attempting to force a rule against meta-templates into guideline or policy status despite the lack of any community consensus to this effect. I realize that you had a good-faith reason to believe that this was what the developers wanted, but that now appears highly questionable and has been explicitly denied by the lead developer. What you may not do is exercise ownership on this page while forcing it into guideline status in defiance of the will of the Wikipedia community. Crotalus horridus (TALK • CONTRIBS) 21:30, 24 January 2006 (UTC)

I don't want to own this page... trust me, it's been full of grief. What I do want is for people who like meta-templates to document their reasons elsewhere to prevent conflict. It is perfectly reasonable for pages that document differing views to be in Wikipedia: space. Jamesday, Brion, and several other editors have expressed the view that meta-templates should be avoided (whether for server-related reasons or "ugliness and fragility"), so this isn't a personal essay - it is now a guideline proposal. -- Netoholic @ 21:51, 24 January 2006 (UTC)

If this is a guideline proposal, than it must be open to the arguemntes for other views, and it must be open to editing that will not merely change the wording but significantly transform the suggested rule of action. A proposal is or should be open to all in order to allow a consensus to be formed. If it in some way isn't open, then I will at least oppose its acceptance, and possibly propose its deletion at WP:MFD.

Yet another kludgy hack

I had a thought, and while I'm sure I'll regret sharing it:

<span style="display: no{{{subst:test|}}}ne; speak: no{{{subst:test|}}}ne;">Text to be displayed if 'test' is not blank.</span>

How does this stack up in terms of accesibility? No wacky class names and/or stripping out of wacky classes, doesn't require changes to the 'common.css' (or whatever) of each place it is ported to, et cetera... but still sending stuff and then retroactively saying 'ignore that text behind the curtain'. It's not the prettiest code, but it works. Can be presented slightly nicer with the form display: {{{subst:test|none}}};, but then it doesn't work if test is set blank ('|test=') or if it is actually set to the word 'none'. Thoughts? Feelings? Rotten vegetables? --CBD _☎ ^✉ 21:03, 24 January 2006 (UTC)

I don't understand—is that the actual code generated? Will it be "display:none" for hiding the text and "display:no{{{subst:test|}}}ne" or "display:notestne" otherwise? Neither is a valid value for a CSS display or speak property, so the page's CSS will not validate; results in any particular browser are unpredictable. In terms of accessibility: hiding text with CSS is still not the same as removing it. This is the same technique as the other CSS hack, which has been shown to fail in older versions of Jaws and in Lynx, and that's without doing any formal testing at all.

Folks: the page's content is in the HTML. Anything done with CSS is just styling, and it is completely optional. The WCAG accessibility guideline requires that all pages work properly without any of their CSS being displayed. This is a priority one checkpoint, and ignoring it is not acceptable.

The template's output is broken. Please let's put energy into fixing the template or replacing it (see {{wikicite}}), not into using CSS to make it look okay to the sighted MSIE users, and forget about everyone else. —Michael Z. 2006-01-25 04:45 Z

Given that the devs have committed to implementing something in the code to handle these basic situations, it would be better to just avoid these tricks for the time being. I agree with Michael's comments about accessibility also. --bainer (talk) 07:49, 25 January 2006 (UTC)

Sorry, I should have explained better. The information above is an example line of code for making text conditional. If the 'test' parameter is not set or is set blank then the span tag evaluates to: <span style="display: none; speak:none;"> and everything between that and the </span> tag is suppressed. If the 'test' parameter is set to 'frogs' or anything else then it gets inserted like so: <span style="display: nofrogsne; speak: nofrogsne;">... which is not a valid style and thus does nothing - allowing the text to appear/be spoken. An example of this in use can be seen at User:CBDunkerson/Sandbox... there I have set up a test1 parameter which is set and a test 2 parameter which is not. Each parameter is checked by the method above and text generated if the parameter is set. Only the Test1 text should be displayed... the Test2 text and all of the logic suppressing it should be 'invisible'. This differs from the earlier 'CSS hack' in that it doesn't require an update to the stylesheet for special classnames or need 'Tidy' to strip out the bad classnames. Obviously the goal was to see if this option would work with the browsers/screen-readers which 'hiddenStructure' breaks on... the tag has been incorporated into HTML 4, but I don't know if that is recognized by these browsers or not. As for a code implementation of conditionals... when it exists I'll use it. In the meantime the 'hiddenStructure' CSS hack has already been implemented on dozens of templates and I think we ought to be replacing it as quickly as possible. Efforts to do so by restoring the meta-template versions and/or using '|if=' have led to revert wars and other nastiness. Hence my questions about whether this option meets accessibility criteria. It clearly makes less of a mess than 'hiddenStructure', but I don't know if it would still fail in some circumstances. --CBD _☎ ^✉ 12:34, 25 January 2006 (UTC)

From what I can tell it would behave exactly as the CSS hack does (well, the modified CSS hack Netoholic was using anyways). —Locke Cole • t • c 12:44, 25 January 2006 (UTC)

It would still fail for anyone working with a browser that ignores css completely (e.g. some text browsers). Plugwash 12:40, 25 January 2006 (UTC)

So it's styles in general, even when set in an HTML 'span' tag rather than the stylesheet. Oh well. Was worth a shot. Though... that tells me that alot of things which use 'span' and 'div' tags for formatting (like... just about every table on wikipedia) are just ignoring the styling. Guess that doesn't matter much for things like alignment, colors, font-size, et cetera... it all just gets displayed in plain text or spoken normally. Only these 'suppression' styles run into real trouble. --CBD _☎ ^✉ 12:53, 25 January 2006 (UTC)

Right, there's nothing inherently wrong with styles, it's just the principle that they don't change the content of a page, merely style it. Local styles in a style attribute override an imported style sheet, but are still not guaranteed to be applied. HTML should be authored with its semantics in mind. For example, a table has structure, a table header (th) labels table contents, but span and div tags in particular are meant to be semantically meaningless and used for subdivision and styling only.

Some screen readers try to emulate a visual browser by skipping items that have display:none or visibility:hidden style applied, but others don't. Note that there are rare screen readers and braille readers, and we have no way of testing every one, so we shouldn't take anything for granted.

Accessibility is not that hard: just use HTML tags logically, keep the code tidy, and avoid what seems like a patent workaround. Lynx is handy for testing because it reduces the text of a page to its most basic form: if a web page makes sense in Lynx, then it probably makes sense in other alternative browsers including screen readers. —Michael Z. 2006-01-25 15:09 Z

Another quick check is to just turn off css in your browser. Not as "reduced" as lynx, but still useful. There's a bookmarklet here that will do it, and there are probably better solutions that I don't know about. — Omegatron 18:45, 25 January 2006 (UTC)

I agree that with regard to portability across projects it is better.--Patrick 14:24, 25 January 2006 (UTC)

Accessibility with the Wikipedia:HiddenStructure method is not a problem, so long as the infobox/whatever makes sense when the information is unhidden. Using hiddenStructure for things like Template:Book reference is not the way to got. It's perfectly fine to use it for hiding a few lines in Infoboxs. Design templates to look good and make sense both with and without the hiddenStructure, and you're fine. -- Netoholic @ 17:12, 25 January 2006 (UTC)

True, it can work acceptably when the revealed text is obviously a list of empty fields, and may be acceptable as an interim solution for a technical problem which we know will be solved. But there are two different aspects in which this is still poor practice:

1. The principle of adding a layer of HTML and CSS code to hide inadequate template output: unnecessary complexity, fragility, bloat, misuse of standards.
2. The principle of fixing it for the majority of sighted visual browser users, but saying it's "good enough" for the disabled or users of alternative browsers: not real accessibility, could be interpreted as disrespectful, easily extended to cases where it really matters.

If having a list of empty fields in an infobox really is good enough, then why don't we skip the hack, and just show those fields in visual browsers? This would put everyone on as equal a footing as possible, and helps remind us that something still needs to be fixed properly. The answer, of course, is that it really isn't good enough, but we choose to ignore it because it only makes the experience worse for a minority. This is especially sad, because the only affect on us is that it would look kind of ugly, but for some disabled users who already have to overcome difficulties using the Internet, it makes it even harder. —Michael Z. 2006-01-25 17:29 Z

Nobody wants to make things less accessible, and if you can convince editors of infobox templates that it's better to not use hiddenStructure, go for it. I think it's acceptable to hide some empty rows ("Died" in Template:Infobox President, for example), and I doubt that a visually-challenged readers mind that we do it. We do a lot for their convenience (and can do more), and hiding these rows is just a convenience. -- Netoholic @ 17:42, 25 January 2006 (UTC)

Convincing editors is part of my point: we, that is the consensus lets this happen due to inertia, resistance to difficulties, nimby, etc. Changing back may be difficult or impossible. This is why hacks relying on poor programming and authoring practices, especially ones affecting accessibility, shouldn't be introduced in the first place.

The presidents infobox is a very good example where this should definitely not be used. The text of the page pretty clearly states that George W. Bush died, although it leaves out the date: "Born — July 6, 1946 New Haven, Connecticut — Died — Political party — Republican". —Michael Z. 2006-01-25 17:48 Z

I say again, make the template readable and make sense, and there is no problem. -- Netoholic @ 18:13, 25 January 2006 (UTC)

Better, but if there were no problem then you wouldn't be adding code to hide that line and the empty signature from visual browsers. I challenge you to make those two lines visible, and see how many complaints from sighted editors mount, or how quickly another editor reverts it, just because it doesn't look right. Then keep in mind that for some disabled readers the extra text isn't just an aesthetic problem, it makes the page measurably more difficult to read. —Michael Z. 2006-01-25 18:28 Z

I'm not going to perform an experiment I know will fail. Editors hate to see the "Died" line when someone is alive. I do not agree with you that it makes it "measurably more difficult to read". -- Netoholic @ 18:46, 25 January 2006 (UTC)

I'm sure disabled people hate to see the "Died" line when someone is alive, too.

Screen readers linearize a web page; like a text-only web browser with a one-line window. They are relatively tedious and fatiguing to use, even in properly-built web pages (Clark 2003:150). Screen reader users have a measurably significantly harder time completing basic tasks[3]. This is why many sites including Wikipedia add "skip" links for accessibility, to jump past or to the navigation links, depending on whether they're at the top or bottom of the page.

Adding a dozen superfluous lines to the taxobox makes it still more tedious to actually find the fields that are present. Adding "Signature [[Image:{{{signature}}}|128px]]" to the President Infobox or "and [[]], and [[]], and [[]], and [[]]" after a Main Article link is confusing. As you say, editors won't settle for this rubbish, and it's wrong to force a disabled minority to suffer through it. Breaking priority-1 accessibility guidelines[4] like this just makes it worse. —Michael Z. 2006-01-25 22:03 Z

Conditionals in codeset

I was reviewing the different ideas for implementing conditional logic in the codeset and noticed a common issue which should be considered. They all put the conditional identifier in the template call. This is similar to the current '|if=' parameter method and will have the same issues. Namely, it is increasing the complexity (granted by a relatively small amount) on the article side and it would require all existing template calls to be updated. If possible it would be better to implement the conditionals on the template side to avoid these two issues. For instance, we could make {{{if|{{{A}}}}}}, {{{ifnot|{{{A}}}}}}, {{{and|{{{A}}}|{{{B}}}}}} 'magic word parameters' available to every template to evaluate (respectively) whether parameter 'A' exists, whether 'A' does not exist, and whether both 'A' and 'B' exist. Et cetera. Same concepts, but I think it would be much better to have all the logic on the template side to avoid needing to teach general users how to set up conditionals and having to update all the existing calls. --CBD _☎ ^✉ 12:41, 27 January 2006 (UTC)

Hmm. Trying to understand: if we have a template X that contains "{{{if|{{{A}}}}}}". When I then write "{{X|A=blue}}" the transclusion results to? --Ligulem 15:27, 27 January 2006 (UTC)

The format really doesn't matter, but keeping with the idea of basing it on a 'magic parameter' setup it would actually be something like: {{{if{{{A|}}}|Text to show if 'A' exists}}}, {{{ifnot{{{A|}}}|Text to show if 'A' does not exist}}}, {{{and{{{A|}}}{{{B|}}}|Text to show if 'A' and 'B' exist}}}. However, the markup could be done any which way ({{{if|{{{A}}}|Text to show if 'A' exists}}} or ##purple#A#Text to show if 'A' exists)... I wasn't trying to show a complete markup system here. Just suggesting that the markup changes should be in the template rather than the article. --CBD _☎ ^✉ 17:22, 27 January 2006 (UTC)

I still feel I haven't synced my slow stupid brain onto your idea (which does not mean your idea is bad or should be changed - I just can't say anything about it if I haven't understood it completely). I have especially problems with your "They all put the conditional identifier in the template call" (scratching my head). Very strange. If we take Phil's proposal for a qif function in MediaWiki: I think this is intended to be used in, for example, template:book reference (my beloved example :-) instead of calls to that much debated qif. So as soon as we have a MediaWiki-built-in qif we just need to change template book reference, not the calls to book reference. I do not think that a single article that includes book reference would need to be changed. What am I missing? --Ligulem 17:53, 27 January 2006 (UTC)

Hmmm, ok ignore me... both Phil's and AzaToth's versions could be used in the template rather than the article. They just looked like 'template calls' so I was thinking they were 'top level' settings. The idea (which I wasn't understanding) is to have the markup in the template (as I was suggesting)... the markup is just written so that it looks like you are calling a template. --CBD _☎ ^✉ 18:38, 27 January 2006 (UTC)

Yes that's it. it looks like template calls but they are built-ins. Maybe we could even have templates built into MediaWiki (but I do not mandate that, I will happily use any syntax we can have from the devs :-). I will certainly not ignore you as I am always on the lookout for new ideas. If I say no to something I haven't understood, I'm a plain idiot. Thanks for your presentation anyway. I think we really need every idea and must carefully check we have understood everything. Never mind. --Ligulem 18:51, 27 January 2006 (UTC)

Reverted again

I really don't understand what it takes in order to make an edit here. I am really feeling like shit because I spent a long time on a rewrite, which removed Jamesday's comments about how a pages are handled, reorganized the page, concentrated several ideas down, and added a section describing problems with all three conditional methods. I feel like shit because it was reverted within 10 minutes. It is very hard to assume good faith when people snap-revert like that. I doubt there was even enough time for him to read it, let alone see what had changed. Nobody else has worked on this in six days, and if there were specific objections, the article is editable by anyone or you could bring those objections here. I just feel sick in my stomach right now. -- Netoholic @ 22:51, 30 January 2006 (UTC)

See below. --Ligulem 22:54, 30 January 2006 (UTC)

Obviously the problem is that we disagree on what the page should say. You decreased the 'slant' of the page, but is still very much present. Note that 'qif' and '|if=' are listed as 'not useable with subst:'... but 'hiddenStructure' isn't... when in reality it has exactly the same problem with evaluated parameters. Or that '|if=' is described as "often very hard to understand". For comparison:

|if= version
|- valign=top {{{if{{{superphylum|}}}|
! Superphylum:
<td> {{{superphylum|}}}<br><small>{{{superphylum_authority|}}}</small>}}}

CSS version
|- valign=top class{{{superphylum|}}}="hiddenStructure"
! Superphylum:
| {{{superphylum|}}}<br><small>{{{superphylum_authority|}}}</small>

Seems like a vanishingly small difference to me... and that's using table structure, where '|if=' is weakest. Make it conditional formatting styles instead and hiddenStructure gets very messy in comparison. The page should mention that there is already discussion of a built-in Wiki conditional method to solve these problems. Also the 'vandalism' and 'page update' issues really have little to do with meta-templates per se... single templates linked to the same number of pages are equally vulnerable to either issue. That ought to be explained so people don't do alot of work to 'de-meta' templates for no real gain.

However, ultimately the issue here is whether we listen to Brion when he says that we shouldn't be making policy (or 'guideline') decisions based on hypothetical server load. He has said that if/when it becomes an issue it would be dealt with on the software side. This page inherently attempts to deal with it (presuming that it exists) on the user side. I'd rather see a page which describes the potential issues around templates in general and the pros/cons of various methods than this repackaged 'meta-templates are evil' presentation. I've seen ways to bring Wikipedia as a whole to a grinding halt with templates that wouldn't require a single 'meta' (nested) layer. In some cases removing meta-templates could actually be 'harmful'. It should be about understanding how templates work so informed decisions can be made. --CBD _☎ ^✉ 23:22, 30 January 2006 (UTC)

If you read my rewrite, I dramatically reduced the scary "server load" text. I preserved the undisputable concept that meta-templates do requiremore database reads/processing.... but balanced with Brion's comments as to the actual impact of that. This page's focus is to stop using complex meta-templates and the replacements like CSS. Avoid them all. -- Netoholic @ 01:42, 31 January 2006 (UTC)

This is an editorial decision, however, and it is one that the community consensus appears to be against. Using two (or more) templates rather than one template with conditionals, which seems to be what you're advocating, means unnecessary complexity and added maintainence. I know of no programmer who would consider doing subroutines that way. Crotalus horridus (TALK • CONTRIBS) 04:04, 31 January 2006 (UTC)

Please don't speak for what you think I advocate. I do not support any blanket statement on how any template should be handled. At various times I've used conditional CSS, merged templates, forked templates, nominated templated for deletion, and created new templates from scratch. I look at each situation as it comes up and decide what I think is the best course of action. I also ask that everyone refrain from speaking on behalf of the "community consensus". I find that to be of little help, since I and other supporters of "Avoid using meta-templates" are also part of the community. Instead, voice your opinion, provide rationales, undertand that others may disagree, and be open to new ideas. -- Netoholic @ 06:42, 31 January 2006 (UTC)

You have specifically requested that conditionals not be included in MediaWiki [5]. This is, quite frankly, a bizarre position, and I'm not aware of any other users who share it. I don't think anyone is arguing that {{qif}} is the best solution. What is being argued is that it is the least bad solution until we can get support for true conditionals at the engine level. My statement stands: I don't see why anyone would consider the existing arrangement of kludges, hacks, and forks to be superior to genuine support for the conditional syntax that some layouts badly need. Crotalus horridus (TALK • CONTRIBS) 07:26, 31 January 2006 (UTC)

For the sake of our non-template-geeky editors... life without conditionals is preferable in my opinion. I do not want to see the template namespace gain some "elite" status where only the privileged few can make a template or even make a change. It's already happening on some pages. Templates should be very simple contructs. This "consensus" you're so fond of citing is the result of several very clever folks converging on this talk page. The only thing I think about is how many people out there will stop creating, maintaining, correcting, and improving templates because they've become too complex. If I could convince the developers to even remove the default parameter function, I would. It's led to no ending of headaches in this namespace, which was already a maintenance nightmare. -- Netoholic @ 07:48, 31 January 2006 (UTC)

"For the sake of our non-template-geeky editors". Ah. And no doubt the lurkers support you in email, too. Look - article editors outnumber template editors by a significant margin. And, ultimately, the articles are what Wikipedia is all about. Using conditionals, we can make articles easier to edit (by increasing the flexibility and ease of use for infoboxes, etc.), at the cost of making some templates (arguably) more difficult to edit. This is a tradeoff we should make without hesitation. If someone wants to edit the formatting of a complicated template and doesn't feel comfortable wrestling with the code, then they can ask on the Talk page for assistance from someone more technically minded. The alternative is to put the burden on article editors, which is far more onerous. Crotalus horridus (TALK • CONTRIBS) 07:57, 31 January 2006 (UTC)

Rewrite

Netoholic made a proposal for a rewrite. I reverted it and moved it to Wikipedia:Avoid using meta-templates/rewrite for general editing. Please work there until there is consensus to move that to WP:AUM. --Ligulem 22:53, 30 January 2006 (UTC)

And what happens when six days pass on that with no edits? We already had one temp page which was not being used either. It's silly that we can't just work on the main page... because right now it looks like trash. Of course, that fact may be why its always reverted to the version with that huge ugly message box. -- Netoholic @ 22:57, 30 January 2006 (UTC)

Please note that Adrian's been doing some substantial neutering of that rewrite page. Here is my original rewrite. Judge for yourself which one better expresses the statement "avoid using meta-templates". -- Netoholic @ 23:18, 30 January 2006 (UTC)

No it is not silly. We still have that disagreement between Brion and Jamesday and the page should best stay as it is until we have further info. If you want to propose such a huge change in one step, let's do that on the side. By the way I have edited your proposal and am still working on it. The initial version corresponds to your proposal. --Ligulem 23:20, 30 January 2006 (UTC)

By the way I think the current title is bad. But we already had that discussion. Need to discuss again? I would say no. Let's first put the new contents in shape then talk about the title. --Ligulem 23:30, 30 January 2006 (UTC)

Well, personally, I think this page should be moved to Wikipedia:Meta-templates (or something more neutral sounding), since obviously it's no longer correct that we should "avoid" them. —Locke Cole • t • c 00:27, 31 January 2006 (UTC)

Agreed. Or Wikipedia:Special templates or something, since conditionals aren't necessarily "metas". — Omegatron 06:10, 1 February 2006 (UTC)

Moved to Wikipedia:Meta-templates. --Ligulem 09:33, 1 February 2006 (UTC)

I will always be an endorser of the idea "Avoid using meta-templates" and for the forseeable future there will be a page at that title because I, Jamesday, Brion, and several others agree with that position. If you want a "Wikipedia:Meta-templates", please create it from scratch to avoid disrupting this page's edit history. -- Netoholic @ 01:39, 31 January 2006 (UTC)

Neto, your public position has in various places and at various times been that we should "avoid using templates", particularly in the context of citing sources and references (and IIRC infoboxes). It is therefore difficult to imagine that this is not part of your apparent crusade against the use of templates, given that the templates against which you have railed most strongly just happen to be those which use condition syntax most heavily. HTH HAND —Phil | Talk 09:17, 31 January 2006 (UTC)

No. We do not want a page "Avoid using meta-templates". You can do so on your user space. --Ligulem 09:40, 1 February 2006 (UTC)

In fact, this is not true. Brion did not say "avoid using meta-templates". He said "try to avoid ugly and fragile templates, and let me worry about the server load issues." (Not an exact quote, but this is the essence of what he said in several places, including WP:AUM.) The question, now, is whether it's more "ugly or fragile" to (A) use a conditional template like {{qif}}, (B) use CSS hacks for optional data hiding, or (C) fork templates into two or more versions and get rid of the conditionals entirely. You favor approach C. However, this is not the community consensus. The consensus for now appears to be that we should use (A) for now, and that hopefully we will soon have real conditionals embedded in the MediaWiki engine so that no hacks have to be used to get them. Approach C seems to me, as a programmer, to be horrible coding practice, and I know of few coders who would disagree with this. Crotalus horridus (TALK • CONTRIBS) 04:08, 31 January 2006 (UTC)

(C) defeats the whole purpose of templates (especially with the amount of forking that would probably need to be done to cover all the possibilities). It also adds complexities for regular editors (keeping track of the various forks). And when it's time to update the appearance or functionality of a group of forked templates? Further complexity because you need to update all the forks as well. (C) is just a total non-starter from any angle you approach it from... —Locke Cole • t • c 04:28, 31 January 2006 (UTC)

Please stop trying to WP:OWN this article. And please don't speak for Brion (or even Jamesday) in the future; if you believe they support you, have them post here themselves. Regardless, as it's no longer a "server issue" with unanimous developer backing, it's back to the community to decide if the costs of meta-templates (generally ugly) outweighs the benefits (simpler use of templates (no forks), better rendering and accessibility). And so far the community seems to be for meta-templates as opposed to the alternatives. —Locke Cole • t • c 04:25, 31 January 2006 (UTC)

These users have posted here expressing specific desires to avoid using meta-templates... Jamesday: "Please instead work at reducing the use of qif to reduce the harm."[6] Jamesday: "Using resources unnecesssarily is not helpful" [7]. Brion: "Complicated templates-within-templates generally ought to be thought twice about before being used, because they can be confusing and fragile." [8]. Sam Korn: "In my opinion, ["ugliness and fragileness" is] the most important reason. the main reason I cite when I ask for meta-templates to be removed." [9]. Snowspinner: "we still should not be using them" [10]. I am willing to make sure this page reflects the ambiguity around the server impact, and my rewrite covered that well, but the core idea is to avoid making templates any more complicated than they already are. Just because you can do a thing, does not imply we should do a thing. -- Netoholic @ 06:42, 31 January 2006 (UTC)

These users were almost without exception working under the impression that JamesDay's original pronouncement was the result of unanimous agreement between the developers: the fact that this has now been shown to be incorrect rather dents the impregnability of the arguments. HTH HAND —Phil | Talk 09:20, 31 January 2006 (UTC)

I wasn't arguing under that assumption. I consider server load to be important, but not as important as accessibility. Sam Korn ^(smoddy) 18:14, 31 January 2006 (UTC)

First of all, Sam Korn and Snowspinner are not developers at all (AFAIK), so their opinions should be given the same respect as those of any other editor - no more, no less. Citing them as authorities holds little meaning. We're already aware of Jamesday's statements, but Brion's claims appear to run counter to his, and Brion is, after all, the lead developer. Furthermore, even taking Jamesday's statements at face value, "reducing" does not mean "eliminating", and if there is no other effective way to get the effect we need, it's not an "unnecessary" use of server resources. I agree we shouldn't use nested templates just for the hell of it. But we already have "thought twice" - and three, and four, and five times - about them. For some things, you need conditionals. This can be done with CSS hacks, but that creates accessibility problems for some users, and generates ugly code. It can be done via {{qif}}, which is probably the least bad option we have open to us now. Ultimately, it will be done via server-side implementation of conditional functions, and this is the optimal solution. In the meantime, we'll muddle through with what we have, and there's no point in trying to limit the use of our most effective current tool. Crotalus horridus (TALK • CONTRIBS) 07:32, 31 January 2006 (UTC)

Hey, hang on. I do still get to have an opinion! Netoholic's point wasn't that I had more authority, only that it was a misrepresentation to claim that there was a complete consensus for keeping such templates. Sam Korn ^(smoddy) 18:14, 31 January 2006 (UTC)

If I were to use your rationale, that the opinions of these editors somehow weighs less than the developers, when we're talking strictly about usability vs. server issues. You joined WP in May 2005, so how exactly should I rank your opinion on this matter? Where does my opinion rank, since I've got a couple thousand edits just in the Template space? On your other point... it is a fallacy to think that there is any "need" for conditionals or meta-templates. Wikipedia managed just fine before last October (?) when the parameter default function was first put in, leading to things like Template:Qif. The truth is that it's only because that function now exists that we're inventing new ways to use it. Some of those ways are good, and some are very bad. -- Netoholic @ 07:48, 31 January 2006 (UTC)

By your argument, if Wikipedia managed perfectly well before templates were added to Mediawiki, then we should still be managing fine without them, and all these pesky users inventing new ways to use these troublesome beasts should be disciplined and shown the door. —Phil | Talk 09:23, 31 January 2006 (UTC)

The way the community "managed" it before that was to create multiple templates. That caused an even bigger maintainence problem when something had to be changed, since redundant changes had to be made to a bunch of different boxes one at a time. Now that we have a better way, we ought to use it. And, again, none of this increases complexity for article editors in any way. Wiki-syntax is not rocket science, with or without conditionals. And of course people are going to invent new ways to use the functionality we have. I can't think of a single programming platform where that wasn't the case. Was the C-64 demo scene evil? Should the authors of BASIC 8 have been taken out and shot for daring to enable the 640x200 hi-res functionality that Commodore's BASIC didn't support (and was officially undocumented)? I could go on with these examples all night. Crotalus horridus (TALK • CONTRIBS) 08:06, 31 January 2006 (UTC)

(unindenting, reply to Crotalus horridus)
Your grand examples don't apply because, as Wikipedians, we are not computer programmers for Wikipedia. Several of us may be in real life, but that only means we have to understand and plan for the significant majority that are historians, linguists, biologists, etc. Yes, we ought to use templates in simple ways for the benefit of those non-technical editors among us. Using conditionals goes against that premise - wikitext is not a programming language, it is markup. Let's get creative, and actually talk about solutions to specific templates and decide on a strategy for each one on it's own accord. Sometimes, two templates instead of one is a fine option. Sometimes, using notemplate is the right way to go. The community has not expressed a desire for conditionals... as far as I see, only about five people on this talk page have -- five people that are probably excellent programmers, but are missing perspective on how such template monstrosities are completely unintellible to the average Wikipedian. I fault myself for making things more complex than necessary, just as much as I fault you all. -- Netoholic @ 17:14, 31 January 2006 (UTC)

As I've commented before: 99% of "conditionals" and "nested templates" and who knows what else is essentially doing the same thing "hiddenStructure" is. In fact, we can probably narrow it even more: the overwhelming majority of conditional use is in place to hide empty rows in infoboxes.

Therefore, the vast majority of users—particularly non-programmer ones—don't really care what the underlying implementation is; they just want their infoboxes to work properly. The hiddenStructure method has some flaws (discussed at great length all over the 'pedia now); these could be easily solved by introducing a server-side version of it. —Kirill Lokshin 17:51, 31 January 2006 (UTC)

I completely disagree. Conditional logic is most important for those who are not programmers. In the past they would have to learn table markup and attempt the impossible task of maintaining consistency across dozens or even hundreds of pages. Now they just need to know how to fill out the template call with the right parameters. All of the table rows and CSS formatting is handled by the templates... thanks in large part to conditional logic. Two templates is not better than one for the users... because then they have to know the names and parameters of the two different templates and when to use each rather than always being able to use one. The more different templates they have to call the more like a programming language it is for the users. Greater 'programming flexibility' in the templates leads directly to less 'programming' being required to use the features. The extreme of your position would be to eliminate templates entirely... at which point all those general users have to learn table markup and HTML/CSS formatting code... all of which is in the article itself as a big mess. Adding templates removed the need for general users to learn that stuff. Adding conditional logic to templates removed the need for general users to understand an array of closely related template forks. Yes, the general users have a hard time understanding the code itself of complex templates... but that's no different than when they had a hard time understanding tables and formats directly in the articles. Templates have removed the complexity from the article space and consolidated it into fewer locations for easier management. --CBD _☎ ^✉ 17:57, 31 January 2006 (UTC)

You are completely wrong, as always in this matter. Behind the people that take care to work on WP:AUM and its implications are a whole bunch of wikipedians that actually do like to use simple templates like those that actually contain conditionals. The use of qif makes these templates actually much simpler as any set of sub-templates that need to be put together to get something useful. It is also amazing how fast people understand how to use qif and those that are interested also are fast in understanding how qif is implemented, though that is not needed in order to use any template that uses qif. You simply waste a lot of time of editors with your WP:AUM pushing, especially now that Brion has it downgraded to an essay. I see people going willy nilly all around on wikipedia and doing stupid downgrades of templates rooted in your silly WP:AUM. Brion has stated that we will get conditionals in code and as far as I and others can see you are the only person opposing that. Please stop your pushing of WP:AUM now and your crusade against templates and your pushing of that ridiculous CSS against Brion and consensus. You are clearly disruptive to Wikipedia with this of your stampedes. I acknowledge that you are very intelligent and that you nearly got your message through with that WP:AUM. But now is the time to stop. If you don't do this now I must assume that you act in bad faith. This is about writing an encyclopedia not about pushing one's own technical POV, which is not based by developer or community consensus. Stop it now. You are simply wasting our time. Finally accept that Brion has vaporized your "beloved" WP:AUM and stop hurting the servers by revert warring on the templates. --Ligulem 17:58, 31 January 2006 (UTC)

You know how there's Godwin's law? I'm beginning to think we need a similar guideline about when a discussion should go into time-out based on the indentation level and paragraph length on talk page. ;)

Neto asked me to take a look at [11]. I skimmed it quickly; it doesn't look terribly offensive, though I would play down the alleged "server load" and play up the "currently cache clearing of multi-level templates doesn't really work" a touch.

I'd still like to get some basic conditionals into the software, along with hopefully some better definitions on _how_ things like templates expand so we can start nailing down the syntax for future versions and software compatibility. Hopefully we can get that done sooner rather than later. --Brion 02:01, 1 February 2006 (UTC)

It will never end

I propose to stop working on this page here and on the talk for all that do not agree with Netoholic on this. This page here is simply Netoholics private pamphlet and he will continue to use it at as a banner to remove templates and push his CSS hack. It's best to ignore him and this page here. The discussion with him will never end until he has reached his goals. It's simply a waste of time and harddisk space. Good luck to all! --Ligulem 16:07, 1 February 2006 (UTC)

Ignoring him would be good for our wikistress levels; but harmful for the encyclopedia. — Omegatron 17:48, 1 February 2006 (UTC)

Provided conditional logic is built into the system some time soon this will all be largely irrelevant. I'd prefer to get rid of the 'hiddenStructure' method in the interim because we know it is bad for accessibility (as opposed to 'qif' which is only hypothetically a 'server load' issue), but if the change is going to be "sooner rather than later" as Brion says the short-term disenfranchisement of users shouldn't do too much damage. If/when conditionals are built in, most 'meta' templates will simply go away as they are replaced by single level 'conditional' templates and even the hypothetical need for this page will end. So, based on the hope that we will get built-in conditional logic soon, I agree with Adrian that we should just ignore it. This page is an issue desperately attempting to achieve relevance as it slides into obscurity. --CBD _☎ ^✉ 18:03, 1 February 2006 (UTC)

Introducing conditional logic will help in some cases to "Avoid using meta-templates", but there are plenty of other awful implementations out there that have nothing to do with "conditionals". This page will be relevant as long as it's possible to nest templates. -- Netoholic @ 18:05, 1 February 2006 (UTC)

Your view on this matter is decidedly in the minority. Let it go. There's no shame in having one's policy proposal rejected by the community. As long as productive discussion happened, then something worthwhile was accomplished. However, this particular discussion is no longer productive at this point, and the same old points are being rehashed ad infinitum. That's why I favor archiving and protection to avoid more sterile arguments. Crotalus horridus (TALK • CONTRIBS) 18:35, 1 February 2006 (UTC)

From main page

This page is still an active proposal, contrary to whatever tags are being inserted or removed by the non-neutral opponents of it. -- Netoholic @ 23:49, 2 February 2006 (UTC)

I've revert back to the one Brion OK'd above. (I see also that Radiant has protected this page) Brion said there are some things that could be improved, and I'm willing to unlock it to that end, but tagging it as historical is simply unacceptable. Raul654 04:29, 3 February 2006 (UTC)

Attempts to improve it (for one, by moving it to a less damning page name) have met with fierce resistance by Netoholic. One need only peruse the talk above and the page history to see that Netoholic is simply pushing AUM as an agenda despite Brion disputing the server load argument (and thus reducing the argument against meta-templates to the more subjective "they're ugly" (can be difficult to read/understand) or "they're fragile" (can break easily if vandalized). If you haven't kept up with the discussion here (or the edits to the page), I strongly suggest you do so before calling the {{historical}} tag "nonsense". —Locke Cole • t • c 04:37, 3 February 2006 (UTC)

My understanding is that Brion disagrees with the specific reasons (avoid using metatemplates because they create an undo load on the servers), but agrees with the general principle (avoid using metatemplates) for other reasons. If that is in fact the case, then I agree with Netoholic that the name should stay. (and, for the same reason, that the historical tag is absolutely inappropriate) Raul654 04:45, 3 February 2006 (UTC)

Your understanding is a deliberate misinterpretation pushedadvocated by Netoholic. The crux of Brion's statements (which actually were initially about image use on userpages; WP:AUM came up later in that conversation) was that editorial considerations should not be driven by speculation on server load or other technical issues. Brion said (paraphrasing) "Let me worry about the servers, and you worry about creating a great encyclopedia." He went on to say that if specific meta-templates were ugly or fragile, then argue against them on that ground, not just because they're meta-templates. Netoholic simply refuses to accept this. Crotalus horridus (TALK • CONTRIBS) 06:50, 3 February 2006 (UTC) Struck out statement that was on the borderline of WP:CIVIL. Sorry about that. Crotalus horridus (TALK • CONTRIBS) 07:15, 3 February 2006 (UTC)

Brion also acknowledged that there are still non-subjective technical problems with meta-templates, that being related to the Template links problems. He read the page, and directly said he had no strong objections, so it's not appropriate to say Brion has done anything to "vaporize" this proposal. For example, you interpret "they're fragile" as "can break easily if vandalized". I read his comments and it seemed to me he means "very likely to break if template syntax changes". Stop saying what you think he means and get his actual input. He seems very responsive. -- Netoholic @ 06:12, 3 February 2006 (UTC)

Sigh. You just don't want to hear anything that contradicts your fixed views. The most important part of Brion's statement, IMO, is that editorial considerations shouldn't be driven by speculation about server loads, that this was the job of the developers and that our job is to create an encyclopedia. If nested templates help us do that, then we should use them. It should be possible to reduce their use soon when we get conditionals in the software, but until then, {{qif}} is the best solution we have. The community does not want this as either a policy or a guideline. We can either use {{historical}}, {{rejected}}, or {{essay}}, but any tag that suggests that this has any binding effect on Wikipedians is wholly inappropriate. You are already using this page as an excuse to make changes against consensus [12]. So far, you've gotten your way on this issue by making a lot of noise and refusing to take "no" for an answer. This must stop, and immediately. You aren't in charge here - the community is. Crotalus horridus (TALK • CONTRIBS) 06:48, 3 February 2006 (UTC) Comment redacted; it is not likely to help advance this discussion in a productive way. My apologies for this ill thought out statement. Crotalus horridus (TALK • CONTRIBS) 07:14, 3 February 2006 (UTC)

Based on Brion's comments cited by Crotalus (esp "You should avoid metatemplates if they're ugly, hard to use, or fragile. That's just common sense; don't worry about "server load" for them.") I've unprotected this page. I don't think a historical or rejected tag is in order, but a major cutdown probably is. Raul654 18:52, 3 February 2006 (UTC)

This page is expressly against templates, and Neto won't let it be altered to anything else. The only reason this page was ever accepted or made policy was because of the server load issue, which wasn't really an issue in the first place. It should be marked as historical. Anything still related to nested templates or conditionals belongs on Help:Advanced templates. — Omegatron 19:32, 3 February 2006 (UTC)

It's not anti-template, and neither am I. The page is a style/usage recommendation, not a "how to use" Help: page. -- Netoholic @ 19:56, 3 February 2006 (UTC)

minor change request

anyone mind changing "It fails if CSS is disabled or not supported" to "It fails if CSS is disabled, not supported or simply fails to load due to server/network issues". Browsers (at least firefox) don't seem to throw any error if the stylesheets fail to load but simply go right ahead and render the page without css! Plugwash 04:47, 3 February 2006 (UTC)

"Fails to load"? How often does that happen? I suppose much of the website would not work properly if that happened. -- Netoholic @ 05:04, 3 February 2006 (UTC)

All of the web site would work if that happened (apart from templates using the CSS hack)—it's called Myskin.

It has happened to me on individual page loads on very rare occasions. —Michael Z. 2006-02-03 06:59 Z

If you access wikipedia for the first time from a machine whilst its in its glacial state it seems to be pretty likely for the first page load. its rare after that because once in the browser its cached for quite some time. Plugwash 16:02, 3 February 2006 (UTC)

Seems like this is a fairly minor/rare issue that isn't directly related to the hiddenStructure method itself. Adding it would require even more clarification on how it "fails to load", which distracts from the real point - that not all browsers support CSS. -- Netoholic @ 19:56, 3 February 2006 (UTC)

Test

I have suggested that we perform a test to settle once and for all whether edits to widely used templates pose a significant server load risk. If we edit several 'high risk' templates (and then revert them right back) we will see once and for all the truth of the situation. Please share your views on the talk page linked above. --CBD _☎ ^✉ 19:45, 3 February 2006 (UTC)

This type of stress testing isn't the best thing to throw at a production system just to prove a point. The developers can try this on a test system if they want to benchmark. xaosflux ^Talk/_CVU 23:29, 3 February 2006 (UTC)

Yeah. That's pretty obvious disruption to (test) a point, isn't it? We certainly wouldn't want someone "testing" whether the system could handle DoS attacks. Brion said to leave server load problems to the developers and not concern ourselves with them. They can run benchmarks on a test wiki. — Omegatron 00:04, 4 February 2006 (UTC)

As someone who develops production server applications for a living and routinely performs 'live' stress tests this seems very strange to me, but it also appears to be the common reaction so... oh well, we will continue 'reading tea leaves' on whether nested-templates cause significant server load issues or not, hypothetically 'unsafe' numbers of transclusions, et cetera. On the 'POINT' bit... look around. We've got disruption. Rather a lot of it. Any disruption caused by a stress test would be insignificant in comparison and might serve to finally settle the matter... and that's only assuming the test failed and actually caused some noticable level of disruption. --CBD _☎ ^✉ 00:09, 4 February 2006 (UTC)

Didn't this already happen, when {{if}} was "blanked" back in December 2005? IIRC the time taken for the servers to recover from the hit caused by that was about 15 minutes. HTH HAND —Phil | Talk 12:12, 6 February 2006 (UTC)

Red herring

How long goes it this time until we have a policy tag on this instruction creep: "All new policies should be regarded as instruction creep until firmly proven otherwise"? Please do not anser me. I'm a troll. I usually try to vote away server load. This is round #2. --Ligulem 23:55, 3 February 2006 (UTC)

Proposal?

I see this is again tagged as a proposal. if this is an active proposal, we all have had lots of time to see the implications and effects. I call for an immediate poll on it, and the application of {{rejected}} should consensus not be achieved. DES ^(talk) 23:59, 3 February 2006 (UTC)

• I vote away the server load as instruction creep. --Ligulem 00:07, 4 February 2006 (UTC)
• A poll right now would probably be a bad idea: the page presents the lopsided view that meta-templates are still evil. It would be nice if the page owners would let another view be shown besides their own. FWIW, I strongly support {{rejected}} being on the page.. —Locke Cole • t • c 00:30, 4 February 2006 (UTC)
• If it's a propoal that eitehr it should be editable to find a consensus view (which it seems it is not at the moment) or else it is ribe to determine whether consensus currently exists for this. (I think it alomst surely does not.) If anyone can suggext a better way to determine consensus in this isntance than a poll i am very intersted. DES ^(talk) 00:37, 4 February 2006 (UTC)
  • I withdraw my objection to a poll. Feel free to set one up, anything to put an end to this (for good or ill) would be warmly welcomed. —Locke Cole • t • c 00:50, 4 February 2006 (UTC)

I would prefer we wait on hold a poll until the page can be stabilised on a version which represents the premise in all its glory. Let me and others who actually support the proposal work on it without interference. If people think it is doomed to fall on its face, then there is no harm in letting us misguided folks work on it. We can only make it worse, right? -- Netoholic @ 01:30, 4 February 2006 (UTC)

Classification

From only having a slight interest in this page, it seems that:

• There is not a consensus or foundatin issues for making this a policy.
• There are at least some portions of this page that describe best practices.
• There are portions of this page that may no longer be needed.
• This page belongs in a category related to our proceedures.
  • There is no consensus as to what category this may be.
  • This categorization may be dependant on edits relating to the prior bullet points.

xaosflux ^Talk/_CVU 00:04, 4 February 2006 (UTC)

Personally, I think that what ever is not disuted by the developers still makes sense (ie. using a meta tempalte where equal functionality can be had without using it is a good thing) should be left in, and this should be a style guideline for templates. xaosflux ^Talk/_CVU 00:04, 4 February 2006 (UTC)

I disagree. The only problem I see with complex templates is their complexity (and the imaginary server load problem, which Brion has said is not our responsibility anyway). I think the benefits (simpler article source code) far outweigh the complexity argument. — Omegatron 00:08, 4 February 2006 (UTC)

Forget about server load... no one is pushing this based on server load anymore, so that's a false premise. You're also making a hasty generalization about how this guideline proposal applies and presenting a false choice between article source simplicity and complex template code. Template come in many varied forms, and the solutions to template complexity do not always lead to complex article source. Each template use must be examined on its own, and the options weighed based on some general good practices. The option of using nested meta-templates has some drawbacks that are not immediately apparent, and if we are going to accept those drawbacks it needs to be after we've examined many alternatives. That's all this page is meant to suggest as an approach. -- Netoholic @ 04:56, 4 February 2006 (UTC)

Personally I don't see any of the other issues as particularly serious. Drawbacks yes, but I'd take them over the decreased accessibility of 'hiddenStructure' any day. Also, the page seems to have rather alot about the 'server load' that no one is pushing anymore. --CBD _☎ ^✉ 05:19, 4 February 2006 (UTC)

Even Brion didn't ask to remove all of the server load section. He's confirmed that certainly two templates use more database reads than one, and that any edit of a high-use template could cause short-term problems. Jamesday, who is a database developer and really shouldn't be ignored, also expressed this. Brion hasn't seen proof of a problem, and he wants to own the problem if it presents itself. The question is one of scale and it is still not answered fully, so still has a (tasteful) place on this page. It is no longer #1 reason to AUM, but it's in there as a concern. Templates aren't vandalised too terribly often either, but the concept is one to be wary of... the same goes for server load. -- Netoholic @ 05:31, 4 February 2006 (UTC)

Each template use must be examined on its own, and the options weighed based on some general good practices.

This looks like a veiled attempt to shift this debate to every template you come across and dispute. Forest fires anyone? No thanks. —Locke Cole • t • c 05:23, 4 February 2006 (UTC)

That is an assumption of bad faith. The best way to prevent a ForestFire is to have a central place to talk. This page serves that purpose, or a "Template workshop" WikiProject could work, too. -- Netoholic @ 05:31, 4 February 2006 (UTC)

You've exhausted all good faith I had in your intentions, I'm sorry I didn't specify earlier: I am no longer assuming good faith in regard to any of your actions. And you're right, the best answer is a central location, but you insist on owning it with your favored version. That is unacceptable. —Locke Cole • t • c 05:35, 4 February 2006 (UTC)

Your best practices aren't needed. Use my common sense. --Ligulem 00:06, 4 February 2006 (UTC)

Happy Anniversary!

I'd just like to point out that this page was created on February 4th, 2005.

We've been fighting about this for an entire year now. How time flies... :-) — Omegatron 00:23, 4 February 2006 (UTC)

Protected

I'm sure we all have something better to do than argue over whether this is policy, guideline, essay, historical, rejected, controversial, or smelling faintly of roses. Kindly stop edit warring about it. >Radiant< 00:57, 4 February 2006 (UTC)

My edits were to re-add the changes which Brion suggested after he reviewed it. CBD changed the premise and substantive content of the page in several places. LockeCole is just baiting a revert war (read the edit summaries). -- Netoholic @ 01:01, 4 February 2006 (UTC)

And you were engaging in a revert war. You always have a choice. Sam Korn ^(smoddy) 01:05, 4 February 2006 (UTC)

We don't need your, or Brion's, permission to modify this page. Please keep that in mind. Brion did not rubber-stamp your version, nor did it get stamped with some magical gold seal that stops others from being able to contribute. You do not own this page. Maybe you missed it, but there's a lot of people who disagree with the basic premise of this page. I see now that your request for a review by Brion was just an attempt to get that "developer mandate" back that you lost two weeks ago... —Locke Cole • t • c 01:12, 4 February 2006 (UTC)

So which is it.... is this page my essay (if so, why are you worried about what it says?). Criticisms were raised that several people were misinterpreting the devs words, so I asked for his input directly. -- Netoholic @ 01:25, 4 February 2006 (UTC)

(edit conflict-twice) Netoholic, please stop 'interpreting' Brion, speaking for him, and/or claiming to be acting on his behalf or instructions. If Brion wants something done or said I'm certain he is more than capable of doing so himself. As to my edits... I was correcting what appear to me to be inaccuracies and biases in the page. I listed the page as a proposed policy and left in place the suggestion that nested templates be 'avoided' just not to the extent (excessive in my view) you are arguing for. In any case, please AGF and follow NPA. --CBD _☎ ^✉ 01:13, 4 February 2006 (UTC)

I am not speaking for Brion. I asked him to review this, and he did. He also suggested some changes, which my edit incorporates. Your edits are designed to muddle this page, and change the the focus away from the suggestion to "avoid using meta-templates". Go write up a Wikipedia:Weeble page and expound on its virtues, don't use this page to advertise a technique which is in opposition to the premise. -- Netoholic @ 01:25, 4 February 2006 (UTC)

If this is to be a focused essay with a single premise, then fine. but then it cannot be a proposed guideline. A guideline is soemthing seeking broad community consensus, adn is open to changes, even fundamental changes in persuit of consensus, IMO. DES ^(talk) 01:32, 4 February 2006 (UTC)

Setting aside the usual claims of 'nefarious motives'... Netoholic, I was not seeking to 'promote' weeble. I barely touched the 'weeble' section of the page and, at that, added information about it's most significant drawback. Your statement that it is "in opposition to the premise" of 'avoid using meta-templates' is incomprehensible to me, as you are well aware that the '|if=' parameter (aka 'weeble') method can vastly reduce or completely eliminate meta-template usage. That and my other edits were entirely consistent with 'avoid' using meta-templates. I think meta-templates should be avoided... but not banned for all but the rarest of circumstances. --CBD _☎ ^✉ 01:51, 4 February 2006 (UTC)

Avoiding meta-templates by using a more complex and harder to implement method is not a recommendation this page should make. As I said, please document that method somewhere else, and add a link here. -- Netoholic @ 05:35, 4 February 2006 (UTC)

Please cease the ownership campaign you've undertaken on this page. It's not your playground. Telling people to "go to another page" is being ignorant of your opposition and is totally unacceptable. —Locke Cole • t • c 05:37, 4 February 2006 (UTC)

How nice. People have accused me of promoting hiddenStructure, and yet what I wrote on this page was critical of the method. By splitting the arguments about that method out of this page, it makes things much better. If Weeble were so documented, this page would be critical as well, but provide a link to that documentation. -- Netoholic @ 05:55, 4 February 2006 (UTC)

Listen, seriously, some people really need to take a step back and chill the hell out before this is discussed anymore. This isn't about who won x and x a fight x and x weeks ago and who's interpreting for whom or any of the venom that is being back and forth here. Take a step back from the keyboard, grab a beer, a shot, Pepsi, I don't care what the heck it is but just friggin relax. You would think the Earth would tumble off its axis if this was one way or the other if you took the time to kill brain cells reading this. --Wgfinley 01:35, 4 February 2006 (UTC)

Use of conditionals in infoboxes

Note: This has been posted both to Template talk:Infobox and WT:AUM. I've done several reverts on Template:Infobox, and I want to make my own position on the matter clear, rather than just blindly reverting without an explanation. Most of the general talk about "meta-templates" obscures a simple fact. The overwhelming majority of meta-template usages are conditional templates, chiefly {{qif}}, and the overwhelming majority of conditional usages are for one single purpose: to hide empty sections in infoboxes. According to Brion, there is currently work underway to add native support for conditionals into the MediaWiki software; when this is done, it will clearly be the preferred way to do this, and {{qif}} can then be deprecated. Until that happens, though, we need to have a backup plan. There are currently three primary options:

1. Use qif.
2. Use the hiddenStructure hack.
3. Fork a single infobox into multiple templates.

(2) is unacceptable because it generates horrendous HTML and breaks some client software, including screen readers. (3) is even more unacceptable because it results in a maintainence nightmare (whenever someone wants to change the base infobox design, they have to remember to do so across multiple pages). Furthermore, (3) places more of a burden on article editors. With a well-designed conditional infobox, empty fields will simply be ignored, so users of the infobox need only omit the parameters that are unused; this is quite intutive. In contrast, forking means that editors must remember multiple template titles and spend time figuring out which one to use. By optimizing for ease of editing on the templates themselves (and, as pointed out above, it doesn't even do that very well) we are hurting ease of editing on articles, which affects far more editors.

Therefore, option (1) is the best alternative we currently have. It's not that difficult for an intermediate HTML programmer to understand, and it offers by far the best experience to the article editor and end user - who ultimately must take precedence. This will hopefully all be moot before long, but this is why the references to qif should stay in Template:Infobox. Crotalus horridus (TALK • CONTRIBS) 06:38, 4 February 2006 (UTC)

To avoid a MeatBall:ForestFire, please follow-up discussion about whether to use conditionals at Template talk:Infobox. -- Netoholic @ 06:45, 4 February 2006 (UTC)

As a wanna-be coder and consensus fool I support this. But I have said this numerous times already. This eassay here is just a masterpiece of techno-FUD, desinged to be used to win edit wars on templates with edit summaries like "rm meta-templates per WP:AUM. Don't revert! This is a policy!". Make some unproven FUD claims ("meta-templates are evil"), hack them up on an WP page, slap "proposal for guideline on it", let the fools fight and demonstrate how they are unable to prove that your claims are wrong, wait until some admin slaps "policy" on it and then you have the perfect sledge hammer. Neto, I must say you are a genious, honestly. But you fail on one important point: the duty of prove is on your side that this essay here is needed. Until then it is pure instruction creep. This whole thing is no longer about writing an encyclopedia. Happy birthday WP:AUM! --Ligulem 08:12, 4 February 2006 (UTC)

It was also, on the basis of the evidence available at the time, fully justified. Your incivil tone may be indicative of the level of the controversy and of the dispute, but it is not thereby justified. Sam Korn ^(smoddy) 17:06, 5 February 2006 (UTC)

I apologize for the tone. But not for the content. The leniency that has been shown in the past on tonality was indeed remarkable. One might even argue that tonality does not count when enforcing policy. Thank you for reminding me that this is not the "house" style. I'm confident that you will keep an eye on this aspect on all involved parties equally well. Per the evidence, I could say that in fact there was none. The whole crusade was based on hearsay like "the devs have said: beat qif with a stick", which seems not to be much of a convincing evidence. Deriving policy from ugliness on a technical matter is not such a good idea. But that would be rather something for the wiki-forensic departement, given the willingness of Brion to incorporate a conditional function into MediaWiki. I think we have enough fuel for this perpetuum immobile here even when restricting our views to the future only. --Ligulem 19:15, 5 February 2006 (UTC)

Developer User:Jamesday said directly - "Please instead work at reducing the use of qif to reduce the harm.". There is no hearsay, and he spoke specifically about Qif. I know for a fact that I have pointed this out several times, so will you please confirm that you've read this? This was the mandate we had at the time. If I hear anyone say anything different, I am going to (FIGURATIVELY) stamp this quote onto my shoe and kick them in the face until they can read it in a mirror. Before we can move forward on this page, people need to stop assuming bad faith on the part of the Arbitrators that promoted this to policy-status, and those that worked to educate people and enforce the policy, based on this direct developer request. You are flat out wrong that any "hearsay" was involved. That being said, we have new information and are trying to move forward. Dredging up an incorrect version of the past in order to fuel current disagreements is unwelcome. -- Netoholic @ 07:28, 6 February 2006 (UTC)

Ok then, wiki-forensic again: Yes, Jamesday requested to work reduce the harm of qif. But may I ask you to look carefully when this happened and what happended before? And what did I do after he had said this? And as per Jamesday: what is the harm caused by qif? It is not the fact that it is a meta-template as Brion said we shall not care about server load and templates. And as per the tonality: thank you for your "kick in the face" (I dispense with further evidences from my talk page as I do not waste my time with this kind of kindergarten). As per "Dredging up an incorrect version of the past in order to fuel current disagreements is unwelcome": besides the "incorrect" I agree with you. May I ask you to stop taking this thing here personally? I have saveral times explicitly agreed with you on technical claims that you brought up. I'm looking forward to having conditionals in MediaWiki as Brion has announced (and which you oppose). In the mean time, please do what ever you think is needed for the well-going of Wikipedia. I reserve the right to review your work as soon as we have built-in conditionals. Thank you. --Ligulem 08:54, 6 February 2006 (UTC)

Everyone who worked based on the "server load" directive from Jamesday was absolutely correct in that what they did at the time. The fact that Brion later provided new information does not suddendly discredit or devalue that previous work. Using new information to attack old actions is the historian's fallacy. Please stop bringing it back up over-and-over again, because you are misinforming new readers of this page, and just plain being divisive. -- Netoholic @ 09:13, 6 February 2006 (UTC)

Feb 11 changes by CBD

In this edit, CBD removed a section describing a problem which has not been fixed. While recently improvements were made to how Whatlinkshere works, in general, with templates, this does not change when speaking strictly about meta-templates. Please read the section carefully, and do your own experiment.

In this edit, he removed several bits about server load. The processing that is required on the back-end is completely supported by dev comments -- what is unclear is to what degree that extra processing actually affects things, please don't confuse the two ideas. The current page already touches very lightly on the server load subject, without going overboard.

In this edit, CBD changed the "POV" of the section. NPOV rules only apply to articles, not this page which is describing a specific position. The difficulty "to implement in conjunction with Wiki table markup" is tangential at best. In the "Blank parameter (aka "Weeble")" section, CBD changed this from being critical of that practice to one describing how easy it is to implement. That is the wrong perspective for this page, since we are seeking to keep both article source and template source as simple as possible. I've ask CBD many times to create a descriptive page (like Wikipedia:hiddenStructure), which we could then link from here. -- Netoholic @ 05:00, 14 February 2006 (UTC)

*still amazed you think you can drive your opposition off to another page when it's clear there's little, if any, consensus for this page* —Locke Cole • t • c 05:05, 14 February 2006 (UTC)

Are you going to just attack me and revert war, or actually present some argument about the topics above? I would not be posting here on talk if I wasn't seeking consensus. -- Netoholic @ 05:07, 14 February 2006 (UTC)

Is it your intent to continually bring this "issue" up every few days/weeks until you get your way? —Locke Cole • t • c 05:13, 14 February 2006 (UTC)

Which issue are you referring to - one of the ones I posted above about the content of the page, or my comment about you? -- Netoholic @ 05:17, 14 February 2006 (UTC)

The content of the page, of course. I'm not the one with a problem here.. —Locke Cole • t • c 05:48, 14 February 2006 (UTC)

I see no point in creating another page for the '|if=' method. That, like the 'hiddenStructure' writeup and this page itself, would eventually be made obsolete by true conditionals. In the meantime I was simply correcting inaccuracies and biases in how information was presented on this page. Even if another (redundant) page were created there would still be no reason to show false or slanted information here. You say 'NPOV' doesn't apply because this is a 'position' document... how can a biased position be made policy? If it isn't balanced/accurate there is no point. If you want this page to simply reflect your opinion rather than facts or consensus then don't list it as a proposed policy... it is an essay and really belongs in your user-space. On 'Whatlinkshere' the remaining issues seem fairly trivial. The continued insistence on including (and exaggerating) the 'server load' issues seems wholly contrary in the face of your prior claim to no longer be concerned with those in regards to WP:AUM... if you no longer think they are a reason driving this proposed policy then why are they such a major, and inflated, part of the write-up? --CBDunkerson 09:28, 16 February 2006 (UTC)

It's really impractical to reply to multiple things at once. How about picking one issue at a time and discussing it? One general point that I want to reply to is your idea of "bias". While I agree a policy page should be accurate, I disagree that policy must be balanced. Take WP:NPA, some people, I'm sure, have different opinions on what constitutes a personal attack and what is tolerable (from rudeness to swearing to threats). Should a policy page describe all the opinions? I think that would make any policy page's message most confusing. This page's assertion is focused on saying solidly "Don't use confusing and fragile meta-template schemes. Here's why. There are other methods, but they all have problems too. Consider carefully." I do not ultimately care whay "status" (guideline/policy/nothing) people will eventually assign this ... all I care is that its position is clearly presented. Your "balanced" ideas might be better on Wikipedia:Transclusion costs and benefits - a page that is descriptive and takes no position. -- Netoholic @ 09:44, 16 February 2006 (UTC)

No one has replied to this last comment above in 10 days, so I've re-done my changes. I remain willing to discuss them point-by-point to find common ground. -- Netoholic @ 15:00, 28 February 2006 (UTC)

Policy is too extreme

This policy is too extreme. Crazy even. I agree with using meta-templates as little as is practical - but sometimes it is much better to use them than not. For instance, {{qif}} is in templates necessary because it so much better than the alternatives. Any CSS-hack like Wikipedia:hiddenStructure is not an option, since it breaks the site for many browsers. Every other alternative makes templates even harder to maintain. ··gracefool |☺ 12:28, 10 February 2006 (UTC)

You're working off a broad assumption that conditionals are "necessary" and that the only alternative is the CSS hack. We all want templates that are easier to maintain, but the solution is not going to be the same across the board. Each case is different and requires solid planning and investigation. -- Netoholic @ 15:40, 15 February 2006 (UTC)

True. I was thinking of complex meta-templates (which should be as easy to read as possible). Yes, I think complex meta-templates are a good idea. ··gracefool |☺ 03:39, 16 February 2006 (UTC)

I don't know if you've kept up with recent changes, but this is no longer policy, it's not even a guideline. Any changes made with this page as justification should be disputed for the reasons you set out above. (Read up this talk page for details on how this page was demoted from policy, as well as the arguments since then addressing your concerns with browser breakage/accessibility). —Locke Cole • t • c 08:49, 15 February 2006 (UTC)

Thanks, I've read it. It's a proposed policy — a kind of policy, though disputed :p ··gracefool |☺ 03:39, 16 February 2006 (UTC)

Netoholic citing this page again

As I feared, Netoholic is again using this page as an excuse for reverting to poorly implemented CSS hacks, as seen in this diff. Unless there is significant objection, I will be placing {{rejected}} on this page in the next day or so, because there's been zero activity recently, and for as long as this page has existed it's been rejected repeatedly by other editors. —Locke Cole • t • c 06:59, 28 February 2006 (UTC)

I think you know there is significant objection to marking this rejected... until you can show the community has made such a determination. I see plenty of people citing this as a guideline on TFD and in the course of regular template editing... I only see a few people opposing it. As for whether or not I cite this page... I will continue to do so to raise awareness among fellow template authors. It is better than cluttering up the summary or the template talk page with an explanation that is better presented here for centralized discussion. -- Netoholic @ 07:15, 28 February 2006 (UTC)

You've manipulated the system long enough, Netoholic. You claimed that you wanted this to serve as a new proposal, and I believed you. Since then, you've made no attempt to gauge consensus, because you prefer to coast by on ambiguity (knowing that the proposal has little chance of succeeding).

You're well aware of the fact that the page's primary reason for existence (the developers' supposed stance) has been removed from the equation, so you've attempted to retrofit your creation into something that can remain afloat (while staying as close as possible to the original text, against the wishes of those who would prefer a broader focus).

You have no legitimate basis for citing your personal essay as a de facto guideline. If you wish to save your baby, please assemble a straw poll. (I'm giving you the opportunity to do so, thereby avoiding accusations of unfair wording on my part.) If you refuse to comply, I'm afraid that {{rejected}} is the only tag that fits. It's your call... —David Levy 14:11, 28 February 2006 (UTC)

I'd love to. The only problem I see is that the opposers of this page simultaneously water it down and insist on a formal polling process. I also hate the idea that this is seen as "my" page and "my" responsibility. I never promoted it beyond "proposal" - that was done by others. I want this to be widely accepted, the only problem is that it's an esoteric concept and had to find people who feel strongly enough to get involved. By it's nature, the only passionate people that come here are those who've created bad template schemes. (note: I've only commented on tyour last point, because your first two are either completely false or simply ad hominem.) -- Netoholic @ 14:49, 28 February 2006 (UTC)

What do you suggest? That this page should serve as a permanent "proposal" (while carrying the weight of a guideline), because most of the community is incapable of recognizing its wisdom? That's unacceptable.

This is perceived as "your" page because you behave as though you own it—attempting to retain strict editorial control and attributing its failure to the interference of others.

At this point, I fully support the idea of allowing the community to judge your preferred version of the page (or both versions, if the alternative version's proponents wish to proceed). Otherwise, there's no justification for stringing this along as a "proposal," as you aren't really proposing anything. (It's more of a declaration than anything else.) —David Levy 15:25, 28 February 2006 (UTC)

I agree with David. Just how long, Netoholic, do you plan on keeping the "proposed" tag in place? It can't be indefinitely; that's unacceptable. Ultimately it will either have to be accepted as {{policy}}, which is very unlikely to happen given the lack of community consensus or developer mandate, or it will have to be {{rejected}}. Alternatively, it could be branded an essay, and in that case it should probably be userfied, especially given Netoholic's desire to WP:OWN the page. The current situation is untenable. Crotalus horridus (TALK • CONTRIBS) 17:11, 28 February 2006 (UTC)

Also, can someone explain to me why Netoholic's probation is not being enforced? He's not supposed to be editing here at all until May 2006. If he was making useful and productive edits, I could understand overlooking the literal terms of his probation, but all I've ever seen him do on any Wikipedia: and Template: related pages is revert war – which is the exact behavior that got him that remedy in the first place. Crotalus horridus (TALK • CONTRIBS) 17:15, 28 February 2006 (UTC)

In fact, he's just been blocked for 48 hours. —David Levy 17:22, 28 February 2006 (UTC)

That's good to know. I'm glad that his probation was enforced this time, and I hope that he will refrain from attempts at policy pushing against consensus in the future, especially by means of revert warring. Crotalus horridus (TALK • CONTRIBS) 17:37, 28 February 2006 (UTC)

I object to the rejected tag - there is still some important content to this page. The CSS hacks are not good either, but the fact that we ought avoid meta-templates, CSS hacks, and other non-transparent things does remain true and important. Wikipedia is supposed to be editable by anyone, not just coders. Phil Sandifer 18:40, 28 February 2006 (UTC)

That's your opinion. However, many others disagree with you on this, and since there is no longer a mandate from the developers (nor does this relate to any core Foundation issues), community consensus must control. And there's no evidence that the community consensus is, or ever will be, in favor of this proposal. There seem to be about half a dozen staunch supporters, maybe a dozen strong opponents, and the rest of Wikipedia really doesn't much care. This amounts to no consensus. Crotalus horridus (TALK • CONTRIBS) 20:27, 28 February 2006 (UTC)

The forthcoming native support for conditional templates will render this entire issue moot. In the meantime, Netoholic is using stall tactics as a means of keeping this "proposal" alive along enough to cite it as a basis for forcing the adoption of the aforementioned CSS hacks (which are far more harmful). —David Levy 18:55, 28 February 2006 (UTC)

You're reading Netoholic's mind now? Phil Sandifer 18:58, 28 February 2006 (UTC)

No, I'm stating facts. Netoholic has resisted all attempts to gauge consensus (or lack thereof), and he is citing this page in his edit summaries when restoring the CSS hack (which Brion Vibber has deemed harmful) to templates: 1 / 2 —David Levy 19:22, 28 February 2006 (UTC)

Guideline

I've hacked out the inaccurate stuff from this page and set it to guideline - simply put, there is widespread concern and sense that making pages uneditable except to experienced users and vandalism magnets is BAD. If the sole problem with the page is that Netoholic is using it inappropriately, the page is not the thing to change. Phil Sandifer 19:03, 28 February 2006 (UTC)

Until it's established that this page is backed by consensus, it is not a guideline. I'm not certain, but I believe that some of the remaining claims are disputed. —David Levy 19:22, 28 February 2006 (UTC)

I would like to see some dispute - transparent editing and avoidance of disastrous vandalism seem to me very fundamental issues. Phil Sandifer 19:25, 28 February 2006 (UTC)

These are editorial decisions. Since this page is no longer a developer mandate, it's inappropriate to elevate it to "guideline" (much less "policy") status without any community consensus. I'd like to see some actual evidence of the "widespread concern" that Snowspinner cites. Crotalus horridus (TALK • CONTRIBS) 20:27, 28 February 2006 (UTC)

I might be mistaken, but I seem to recall someone claiming that some or all of the statements from the "Template links" section are outdated and no longer applicable. —David Levy 19:31, 28 February 2006 (UTC)

I thought I'd killed that section. There. :) Phil Sandifer 19:38, 28 February 2006 (UTC)

Edit warring over the status of this page, and the tag used to describe it, is very, very silly. I attempted to compromise on a "tag" that would capture the current state of dispute, but that didn't last long. How about some discussion on the merits of the whatever-it-is before any more reverting? android79 19:40, 28 February 2006 (UTC)

I like your tag quite a bit, actually. Phil Sandifer 19:55, 28 February 2006 (UTC)

Fine with me. Now let's see if it cools off Netoholic's disruptive editing. Crotalus horridus (TALK • CONTRIBS) 20:27, 28 February 2006 (UTC)

I have reworded it to be less clunky. Sam Korn ^(smoddy) 23:01, 28 February 2006 (UTC)

making pages uneditable except to experienced users is BAD

So you agree that using templates to simplify complex markup and insertion of content is a good thing? :-) — Omegatron 00:29, 1 March 2006 (UTC)

Exactly. {{Qif}} is *less* opaque than its alternatives. Obviously, native conditionals, when implemented, will be better still. Crotalus horridus (TALK • CONTRIBS) 00:52, 1 March 2006 (UTC)

Straw poll

Which is better: {{qif}} or subtemplates?

There are two ways I have seen for doing conditionals - using {{qif}} (or similar conditionals) or using subtemplates (like {{routeboxca2/Interstate}}, where Interstate is an argument of the main template). Which way is better on the servers? Or can these not be easily compared, as they have different uses? --SPUI (talk - don't use sorted stub templates!) 00:56, 3 March 2006 (UTC)

Any 'server load' issues with this are generally insignificant, but for templates which vary on a single parameter I like the '/' method. The 'User wikipedia' templates are a good example. These used to be 'User Wikipedia|RCP', 'User Wikipedia|NPA', et cetera. They were replaced with 'User Wikipedia/RC Patrol' and the like. This allowed some minor reduction in server load, but also made the templates easier to update/maintain... users can just create a new template with the right name rather than having to work it into the switching logic at the single 'User Wikipedia' template. On the other hand, for templates with multiple parameters like Template:Taxobox multiple sub-templates is messy and conditionals work better. --CBDunkerson 01:16, 3 March 2006 (UTC)

I favor whatever is easiest for the article editors, as they vastly outnumber template editors and the articles is what this project is all about anyway. In many cases, using {{qif}} to hide empty parts of boxes or structures makes things far easier for article editors since all they then have to do is omit the unused fields, not juggle around different templates for different purposes. Crotalus horridus (TALK • CONTRIBS) 06:55, 3 March 2006 (UTC)

Concur strongly with the first sentence of this; the rest seems reasonable. Septentrionalis 18:03, 5 March 2006 (UTC)

Despite the noise about the server load, that does not appear to be the current concern of this policy, which has changed to other issues. Per CBDunkerson on the rest, good question. But hopefully the developers will continue to make mediawiki easy and easier for editors to edit I think. Augustz 07:27, 3 March 2006 (UTC)

Subtemplates in infoboxes are a historical legacy, they were invented because nothing else was possible at the time. I see no reason not to replace them with {{qif}}. _R_ 01:32, 6 March 2006 (UTC)

Transparency; consider example below. This page is in any case an attempt to deprecate {{qif}}, so _R_'s comment resolves very little. Septentrionalis 16:17, 6 March 2006 (UTC)

Example

Netoholic has been asking above for an example for which meta-templates are necessary. This is an extreme demand; any functionality can in principle be done in other ways. A computer is a Turing machine, after all.

The following example (and I choose a fictitious, but quite plausible, one intentionally) is of an example of a reasonable and natural use of a meta-template, which does not involve a high percentage of our million articles:

Suppose the following consensus:

• All Canadian navigation templates should have a base marking them as Canadian
• This base should be identical in all the templates, and contain some minimal symbols and data on Canada.
• Nevertheless, the base will be changed from time to time, either to reflect evoloving WP consensus on Canadian issues, or political changes ouside WP.

One way to implement this is to have the Canadian templates call a common subtemplate Template:Canada template base. Let us consider the harmful effects of this:

• Any editor who can edit a template at all should be able to understand this. It is rather easier to edit and maintain than (e.g.) the templates that would result by transcluding the common area into the individual nav templates.
• "What links here" will be only slightly worse than usual. Any confusion could be managed by, for example, keeping a list of Canada nav templates on Template talk: Canada template base
• This is not a target for vandalism. This whole structure would only affect those pages which are so strongly involved with Canada to have nav templates. This may well be a thousand pages, but not ten thousand.

Septentrionalis 18:03, 5 March 2006 (UTC)

To use your example... making a change to a series of related templates is no more difficult than making a changes to a series of pages using any one template. If whatever common text needs to be changed, it can be done fairly quickly. The question is first - how often is "Template:Canada template base" to be changed? Are those changes important or frivolous? Is the template base important or frivolous? Should we be using lists ot categories instead of navigation boxes? .... and a dozen more questions that need to be thought about. Using a meta-template scheme is often a lazy shortcut to avoid a good design discussion. -- Netoholic @ 04:58, 6 March 2006 (UTC)

• How many Canadian nav templates are there? Of course having to alter all of them is more difficult and time-consuming than altering one common text; and making sure that they are all altered the same way would be another and yet more troublesome step.
  • If this logic were valid, it would lead to having no templates at all, for altering each article separately would be no more trouble that altering the template.
• Lists and categories are useless in this example; we are considering common elements in already existing templates.
• I chose Canada because I have seen three Wikipedia controversies which would cause changes in such a base template:
  • Quebec v. the rest of Canada
  • Clear representation of the Canadian provincial flags, which are heraldic and quartered.
  • The nature and status of the Crown in Canada.
• Outside WP, such a template might well change at
  • The fall of a Canadian government.
  • The prospect of a Canadian election.
  • The death of Queen Elizabeth.
• No change which averts a revert war is frivolous; and all of these have the potential to involve one. A revert war involving most of the Canadian templates would be at least as damaging to WP as, and a greater load on the servers than, changing the base template (which might well be protected). Septentrionalis 16:07, 6 March 2006 (UTC)

Wikipedia:Avoid conditional templates

Netoholic has created a similar version of WP:AUM at Wikipedia:Avoid conditional templates, which I have listed at Wikipedia:Miscellany for deletion as a fork. Wikipedia:Miscellany for deletion/Wikipedia:Avoid conditional templates --Reflex Reaction (talk)• 22:12, 7 March 2006 (UTC)

That's resolved (= deleted) now. Unrelated, my removal of Category:Wikipedia templates was wrong, the articles there are in fact also about templates, the subcategories are only for templates. Omniplex 16:00, 14 March 2006 (UTC)

As a side note, I've nominated Wikipedia:HiddenStructure for deletion. See that at Wikipedia:Miscellany for deletion/Wikipedia:HiddenStructure. —Locke Cole • t • c 21:50, 16 March 2006 (UTC)

Rejected

• Endorse John Reid 18:59, 14 March 2006 (UTC)

Pages to watch

I've created two pages recently that people concerned with AUM (or more specifically, hiddenStructure) may find worth watchlisting:

• WP:QIF — This page contains examples of using {{qif}} in infoboxes/templates.
• WP:DUH — This page (formerly at User:Locke Cole/Don't use hiddenStructure, now at Wikipedia:Don't use hiddenStructure) describes reasons to not use hiddenStructure.

I suspect those who favored WP:AUM may attempt to inject their own point of view into one or both of these pages, and would appreciate it if people could keep an eye on them in my absence. And of course, if you can think of ways to improve the pages (make them easier to understand, or correct anything that is (later proven) incorrect, etc.) do that too. =) —Locke Cole • t • c 02:05, 24 March 2006 (UTC)

Mathematical expressions and conditional constructs

The protagonists here may be interested in [13], [14] and this. Or they may not be. Or they may already have heard. -Splash^talk 22:16, 5 April 2006 (UTC)

Aye, heard about it on IRC last night. But thanks for the handy collection of links. =) —Locke Cole • t • c 23:30, 5 April 2006 (UTC)