The following discussion is an archived debate of the proposed deletion of the miscellany page below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the page's talk page or in a
deletion review). No further edits should be made to this page.
First off, I need to explain why this is on MfD, not TfD. {{qif}} is not just any old template; it's one of the most commonly used templates on Wikipedia. It's effectively become a piece of Wikimarkup in itself. As such, I feel listing this on TfD would be inappropriate; {{qif}} does not fit the mold of traditional templates.
This template should now be deprecated so that we can use the {{#if:}} syntax available in Wikimarkup. Doing so would put considerably less strain on the servers, slightly reduce exposure to vandalism (if a rogue admin decides to crash Wikipedia, he can't do it by editing a meta-template), etc. Some people appear overly attached to {{qif}}, so I feel getting a broader consensus on this would be appropriate. To me, it is obvious that we now have something better, so why not officially deprecate {{qif}}?
Johnleemk |
Talk15:50, 18 April 2006 (UTC)reply
Delete. Obsolete, redundant, a total fire hazard. — Apr. 18, '06 [15:54] <
freakofnurxture|talk>
Question: how is this a fire hazard once it is deprecated and orphanned? Why can't we keep it as a historical template, duly marked as deprecated and with a thick pointer to the docu of
m:ParserFunctions? --
Ligulem20:52, 18 April 2006 (UTC)reply
Addendum: qif was the central target of
WP:AUM. WP:AUM was said to not be deleted because it was once a policy, as policies do not get deleted (I was told). As WP:AUM was primarily created against qif, shouldn't qif be kept in the same way as historical as WP:AUM? --
Ligulem20:59, 18 April 2006 (UTC)reply
Pardon me for assuming bad faith, but I don't think keeping it in the template namespace would be a good idea. It wouldn't stop people from using it. I'm just barely gaining ground in the orphaning process as it is. — Apr. 19, '06 [02:31] <
freakofnurxture|talk>
Factually equally untrue as qif is the successor of deleted
template:if, which was blanked and protected by you while I was in the middle of migrating hundreds of templates to the server friendlier qif. So much per the history. --
Ligulem21:27, 18 April 2006 (UTC)reply
Another problem: We do have a set of once highly used
category:Deprecated citation templates which are no longer used but in talk archives and the like. These break when qif is deleted. What should be done with them? Please note that they cannot be substed because qif cannot be substed. As a side note: a template using #if looks equally awful when substed. --
Ligulem 21:07, 18 April 2006 (UTC)--
Ligulem21:52, 18 April 2006 (UTC)reply
Cosmetics are only a concern in the article namespace. Ideally, no templates should be substed into the article namespace anyway. Using parser functions we can reduce these some of these ridiculous 5+ layer deep templates to a single call, and use them, as Pathoschild puts it, practically for free. — Apr. 19, '06 [02:31] <
freakofnurxture|talk>
Delete. We no longer have a use for it, and it's a massive potential problem. I'm happy to proffer the services of my bot to substitute it.
James F.(talk)15:56, 18 April 2006 (UTC)reply
Delete (see below); many of the developers have expressed a significant preference for the native wikimarkup syntax over the conditional metatemplates. As I understand it, the conditional metatemplates use multiple calls to the database, which is expensive in terms of server resources. On the other hand, ParserFunctions are performed entirely by the Parser, and with cacheing they would be literally free in terms of server resources for most operations. // [
admin]
Pathoschild (talk/map)
15:57, 18 April 2006 (UTC)reply
Keep for now. Yes this should absolutely be deprecated... after the new '#if:' feature is no longer in a trial period. It has only been a week and
m:ParserFunctions has had several features added, removed, or changed. The #if: function itself has been changed to work differently than it did originally. Further, the supposed 'server load' problems of qif simply aren't problems... at least according to the lead developer and the observed reality of qif now being used vastly more than it was in the past and yet causing no trouble. Wait until the new methodology is stable and then deprecate the old. --
CBDunkerson16:03, 18 April 2006 (UTC)reply
Yes. That's so that we get an actual decision made, and that people other than those who created the template (and so would prefer to keep it, probably) get to see the discussion; the VP is useless for such things, and has been for years.
James F.(talk)21:56, 19 April 2006 (UTC)reply
Ahem. For the record, the above statement and Johnleemk's, "Some people appear overly attached to {{qif}}" are both completely uncalled for. The creator of this template was AzaToth... who then went and put together a MediaWiki alternative very similar to what Tim eventually installed. Other leading proponents of 'qif' have been Locke Cole and myself... both of whom were also very involved in supporting the #if: replacement prior to it's installation and amongst the first to start converting templates over to it. I believe my
response to the initial proposal should sufficiently establish 'support' for the idea. Contrary to various innuendos and outright insults the only person I have seen arguing against the use of #if: is Netoholic... the leading opponent of QIF. I did suggest that it would be prudent to hold off on mass conversions until the 'trial period' was over, but since some users are determined to save us from the (largely fictional) evils of 'qif' that ship has sailed and we'll just have to hope that there are no further format changes to #if: or other issues with it. So to sum up... this is not the 'great crusade against the promoters of QIF' that you paint it. The promoters of QIF were actively involved in testing and implementing #if: as a means of replacing QIF. We were the ones who lobbied for this change. Please drop the attitude. --
CBDunkerson22:38, 19 April 2006 (UTC)reply
Deprecateand Keep. This is a historic template and access to it should be fully preserved. I will happily help with
WP:AWB orphanning. I trust Tim not to pull the plug on #if. #if works and it's time to use it. --
Ligulem16:54, 18 April 2006 (UTC)reply
(*fD is showing us what a straitjacket it is again :). Here the logical thing to do is to 1) get the word from Tim that the expression syntax is stable (we don't care about implementation but syntax is important) and then 2) migrate slowly but surely across to the new syntax (using e.g. JamesF's bot) making sure everything works as expected. So that's somewhere in between keep and delete I suppose :).
Pcb21Pete17:41, 18 April 2006 (UTC)reply
Neutral I think this nomination is premature until Tim Starling has completely and fully tested m:ParserFunctions so it is 100% more stable and efficient than qif.
Zzyzx11(Talk)18:05, 18 April 2006 (UTC)reply
Keep. As I understand it, the
ParserFunctions are still on trial (debug?) mode, so they're not completely stable, so start slowly deprecating it while keeping the template for backup purposes. I've got no objection to deleting it once it is reasonably safe to assume that any potential bugs have been quashed.
Titoxd(
?!? -
help us)21:22, 18 April 2006 (UTC)reply
Repeat after me: NOONE IS SUGGESTING THAT THIS BE DELETED WITHOUT FIRST BEING MIGRATED TO PARSERFUNCTIONS AND THOROUGHLY ORPHANED. Go on, repeat it. -
Splashtalk21:31, 18 April 2006 (UTC)reply
NOONE IS SUGGESTING THAT THIS BE DELETED WITHOUT FIRST BEING MIGRATED TO PARSERFUNCTIONS AND THOROUGHLY ORPHANED. Done. --
Ligulem21:36, 18 April 2006 (UTC)reply
Then why are we bothering with a delete discussion? Templates can be migrated without a discussion to delete qif. There is also the historical compatibility issue, which is a further argument to migrate and deprecate, but KEEP. So, repeat after me, IT IS PREMATURE TO DISCUSS DELETION AT THIS POINT. Contrary to what some people seem to think, the Wikipedia servers are not going to spontaniously combust if this template isn't immediately deleted. —
Doug Belltalk•contrib23:22, 18 April 2006 (UTC)reply
Keep -- I hate to say this, since by all accounts the new syntax is what we've been demanding. But the heavy use of this tool positively asserts its importance. By all means, deprecate its use -- as publicly as possible. Every possible place where an editor might go to learn about writing templates should have clear instructions that point out the currently accepted method and the interactions with substitution. Blank {qif} once orphaned, replace it with an obvious colored banner box notice: Do Not Use. But retain the page itself; it's not as if it consumes resources that way. It's earned its quiet retirement. Orphan of course; but that is non-trivial. I suggest that the first step is to deprecate, so the problem does not grow. A trusted team should set out to migrate templates to the new syntax -- and please avoid making other "improvements" meanwhile, despite temptation. Leave a clear record. Go slow while orphaning and allow time for problems to emerge. This is not an emergency.
John Reid22:02, 18 April 2006 (UTC)reply
Deprecate, replace all uses with the new syntax, and delete immediately after that is done. All the other bizarre programming-type meta-templates should be given the same treatment as soon as the new parser functions allow. --
The Anome23:18, 18 April 2006 (UTC)reply
Comment for the records: CBD is referring to the removal of the random function by Tim
[1]. It is pretty obvious that there is no way back for Tim to remove #if. If he would remove #if why would he have created ParserFunctions then? Also the removal of #if would be fixed within 24h by the community by restoring qif (or under what name ever). --
Ligulem07:24, 19 April 2006 (UTC)reply
Comment: this template deletion discussion is currently the top item on the community portal. As such, I feel it is my duty to raise my hand and say that I have no idea what this template does. Can someone please explain it in case other clueless non-developer people are coming here? If I had just stumbled across this in some random corner of Wikipedia, I'd be inclined to just mutter "not my business" and stumble on my way - but since someone put this in such a prominent place, I think we need to explain this to the
hoi polloi.
Johntex\talk02:23, 19 April 2006 (UTC)reply
Because some people do not want to understand how qif works, doesn't mean it uses black magic. qif uses current functionality of the template system. It uses
m:Help:Parameter default and template paramaters, and template inclusion. Nothing else. The correctness of qif can be mathematically proven. Simple thing for basic logic. Some people were just surprised that these basic things can be used to create qif. qif has already been there. Because it is possible to create it. And it's no virus, no hack and it does not rely on shaky features. Just for the records. Come on. Wikipedia is not a kindergarten. We also have articles about quantum physics. I'm sure nobody requests the removal of them only because they are not understood by the masses :-) --
Ligulem07:43, 19 April 2006 (UTC)reply
Keep the new code is not mature or well tested enough. Even then, I see little reason to actually delete it once it is not used.
Kotepho01:03, 20 April 2006 (UTC)reply
Keep - it's working as designed, and it's fully documented. Alternative solutions will find their way when they are debugged and documented. --
Omniplex01:48, 20 April 2006 (UTC)reply
Comment: It's actually still buggy and breaks a number of templates that require outputting the text {{{1}}} conditionally to function. Until this is resolved, it can't replace {{
qif}}. —
Saxifrage✎20:45, 21 April 2006 (UTC)reply
Oh, don't get me wrong: I'm not arguing that qif is better. I'm only making the point that #if is not currently working as designed and so isn't yet ready to replace qif. I think ParserFunctions is a fabulous improvement and I hope that bug gets squashed soon so we can start using it without breaking templates. —
Saxifrage✎23:35, 21 April 2006 (UTC)reply
Nor me. But I'm not yet sure about the parser functions, some string functions would be very nice, and that would get us near server side scripting. --
Omniplex14:27, 22 April 2006 (UTC)reply
Keep This MfD is putting the cart before the horse. Testing of #if should finished first, then the template should be deprecated. --TheFarix (
Talk)
22:41, 20 April 2006 (UTC)reply
Delete - Conditionals are evil, because they present a barrier to template editors who don't have advanced programming knowledge. Simple is good. --
Netoholic@19:33, 21 April 2006 (UTC)reply
I take your point, but please look at
my contribs for a whole bunch of templates which incorporate conditionals (and other calculations). I'm doing the programming, so that editors withou advanced programming knowledge don't have to. :-) --
Uncle Ed19:36, 21 April 2006 (UTC)reply
Ignoring the fact that I support deprecating {{qif}}, conditionals actually make things less complicated, not more. The biggest reduction in complexity is that things can be done in fewer templates (since many optionals that would have formerly spawned offshoots of existing templates can now be included in the main template; see {{Mtnbox start}}, {{Mtnbox climb}}, {{Mtnbox topo}}, {{Mtnbox coor dms}}, {{Mtnbox finish}}, {{Mtnbox geology}}, {{Mtnbox start nopic}}, {{Mtnbox coor dm}}, {{Mtnbox volcano}}, {{Mtnbox UK}}, {{Mtnbox start norange}}, {{Mtnbox start nopic norange}}, {{Mtnbox prom}} as compared to the single template {{Infobox Mountain}} which handles everything those thirteen templates did). Further, the barrier of entry for new editors to learn is reduced thanks to articles like
Wikipedia:Qif conditionals (recently updated to document #if). IMO if you think conditionals are too hard for new editors, you could help expand the existing documentation for #if (and the other
m:ParserFunctions) to make it simpler for them to learn. Finally, see Ed's comment above; many new editors won't touch templates because most of them cover everything they want them to do already. —
Locke Cole •
t •
c21:32, 21 April 2006 (UTC)reply
The MediaWiki software is a little complicated for the average user, but fortunately, most don't need to worry about it. I haven't looked at the code that supports {{PAGENAME}} or {{CURRENTDAY}}, but I feel pretty comfortable using them nonetheless. I think "keep it simple" is a very good goal. Having conditionals that allow some fraction of the editors to create templates that simplify editing for others is not creating a barrier to editing, but rather is providing a valuable level of customization between "developer" and "editor". Conditionals are actually helping "keep it simple" by providing a (very minimal) macro language for extending the wiki. I think #if: is a very positive step forward in acknowledging this need and providing a better means to support it—and I hope that the
m:ParserFunctions are extended somewhat—it's just a bit premature to discuss deleting{{qif}} until the issues with the current implementation are shaken out. —
Doug Belltalk•contrib16:29, 24 April 2006 (UTC)reply
Keep the new code is not mature or well tested enough. Even then, I see little reason to actually delete it once it is not used — Preceding
unsigned comment added by
Megan 189 (
talk •
contribs) 2006-04-23 22:20:46
Delete--I tend to think that if this is deleted then we just will use #if ... I wouldn't think they'd want to mess up thousands of pages by not. Then again... it may be interesting.
grenグレン16:56, 27 April 2006 (UTC)reply
Defer to developer(s). An unusual vote I know, but this is something that should be their decision, since they know what they're talking about.
the wub"?!"23:20, 27 April 2006 (UTC)reply
Change to use the current syntax and keep as a mnemonic alternative to #if, possibly move to {{if}}. Parser functions are a great tool for producing automagic templates, which provide increased functionality and code readability. We should provide automagic templates for basic conditional behaviour, which should be used in settings where non-programmer editors are likely to need to read and understand the code without learning yet another syntax. The template will never be changed, so its effect on resources will be negligible. In any case, keep the history to preserve a record of a time when Wikipedia community showed its collective intelligence and resourcefulness and created a complete set of new useful behaviour out of almost nothing.
Zocky |
picture popups17:49, 28 April 2006 (UTC)reply
Conditional keep. However, to discourage rogue admins, establish a rule that if anyone vandalizes the template, they will be immediately blocked for a certain amount of time. --
King of♥♦♣♠04:17, 1 May 2006 (UTC)reply
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the page's talk page or in a
deletion review). No further edits should be made to this page.
The following discussion is an archived debate of the proposed deletion of the miscellany page below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the page's talk page or in a
deletion review). No further edits should be made to this page.
First off, I need to explain why this is on MfD, not TfD. {{qif}} is not just any old template; it's one of the most commonly used templates on Wikipedia. It's effectively become a piece of Wikimarkup in itself. As such, I feel listing this on TfD would be inappropriate; {{qif}} does not fit the mold of traditional templates.
This template should now be deprecated so that we can use the {{#if:}} syntax available in Wikimarkup. Doing so would put considerably less strain on the servers, slightly reduce exposure to vandalism (if a rogue admin decides to crash Wikipedia, he can't do it by editing a meta-template), etc. Some people appear overly attached to {{qif}}, so I feel getting a broader consensus on this would be appropriate. To me, it is obvious that we now have something better, so why not officially deprecate {{qif}}?
Johnleemk |
Talk15:50, 18 April 2006 (UTC)reply
Delete. Obsolete, redundant, a total fire hazard. — Apr. 18, '06 [15:54] <
freakofnurxture|talk>
Question: how is this a fire hazard once it is deprecated and orphanned? Why can't we keep it as a historical template, duly marked as deprecated and with a thick pointer to the docu of
m:ParserFunctions? --
Ligulem20:52, 18 April 2006 (UTC)reply
Addendum: qif was the central target of
WP:AUM. WP:AUM was said to not be deleted because it was once a policy, as policies do not get deleted (I was told). As WP:AUM was primarily created against qif, shouldn't qif be kept in the same way as historical as WP:AUM? --
Ligulem20:59, 18 April 2006 (UTC)reply
Pardon me for assuming bad faith, but I don't think keeping it in the template namespace would be a good idea. It wouldn't stop people from using it. I'm just barely gaining ground in the orphaning process as it is. — Apr. 19, '06 [02:31] <
freakofnurxture|talk>
Factually equally untrue as qif is the successor of deleted
template:if, which was blanked and protected by you while I was in the middle of migrating hundreds of templates to the server friendlier qif. So much per the history. --
Ligulem21:27, 18 April 2006 (UTC)reply
Another problem: We do have a set of once highly used
category:Deprecated citation templates which are no longer used but in talk archives and the like. These break when qif is deleted. What should be done with them? Please note that they cannot be substed because qif cannot be substed. As a side note: a template using #if looks equally awful when substed. --
Ligulem 21:07, 18 April 2006 (UTC)--
Ligulem21:52, 18 April 2006 (UTC)reply
Cosmetics are only a concern in the article namespace. Ideally, no templates should be substed into the article namespace anyway. Using parser functions we can reduce these some of these ridiculous 5+ layer deep templates to a single call, and use them, as Pathoschild puts it, practically for free. — Apr. 19, '06 [02:31] <
freakofnurxture|talk>
Delete. We no longer have a use for it, and it's a massive potential problem. I'm happy to proffer the services of my bot to substitute it.
James F.(talk)15:56, 18 April 2006 (UTC)reply
Delete (see below); many of the developers have expressed a significant preference for the native wikimarkup syntax over the conditional metatemplates. As I understand it, the conditional metatemplates use multiple calls to the database, which is expensive in terms of server resources. On the other hand, ParserFunctions are performed entirely by the Parser, and with cacheing they would be literally free in terms of server resources for most operations. // [
admin]
Pathoschild (talk/map)
15:57, 18 April 2006 (UTC)reply
Keep for now. Yes this should absolutely be deprecated... after the new '#if:' feature is no longer in a trial period. It has only been a week and
m:ParserFunctions has had several features added, removed, or changed. The #if: function itself has been changed to work differently than it did originally. Further, the supposed 'server load' problems of qif simply aren't problems... at least according to the lead developer and the observed reality of qif now being used vastly more than it was in the past and yet causing no trouble. Wait until the new methodology is stable and then deprecate the old. --
CBDunkerson16:03, 18 April 2006 (UTC)reply
Yes. That's so that we get an actual decision made, and that people other than those who created the template (and so would prefer to keep it, probably) get to see the discussion; the VP is useless for such things, and has been for years.
James F.(talk)21:56, 19 April 2006 (UTC)reply
Ahem. For the record, the above statement and Johnleemk's, "Some people appear overly attached to {{qif}}" are both completely uncalled for. The creator of this template was AzaToth... who then went and put together a MediaWiki alternative very similar to what Tim eventually installed. Other leading proponents of 'qif' have been Locke Cole and myself... both of whom were also very involved in supporting the #if: replacement prior to it's installation and amongst the first to start converting templates over to it. I believe my
response to the initial proposal should sufficiently establish 'support' for the idea. Contrary to various innuendos and outright insults the only person I have seen arguing against the use of #if: is Netoholic... the leading opponent of QIF. I did suggest that it would be prudent to hold off on mass conversions until the 'trial period' was over, but since some users are determined to save us from the (largely fictional) evils of 'qif' that ship has sailed and we'll just have to hope that there are no further format changes to #if: or other issues with it. So to sum up... this is not the 'great crusade against the promoters of QIF' that you paint it. The promoters of QIF were actively involved in testing and implementing #if: as a means of replacing QIF. We were the ones who lobbied for this change. Please drop the attitude. --
CBDunkerson22:38, 19 April 2006 (UTC)reply
Deprecateand Keep. This is a historic template and access to it should be fully preserved. I will happily help with
WP:AWB orphanning. I trust Tim not to pull the plug on #if. #if works and it's time to use it. --
Ligulem16:54, 18 April 2006 (UTC)reply
(*fD is showing us what a straitjacket it is again :). Here the logical thing to do is to 1) get the word from Tim that the expression syntax is stable (we don't care about implementation but syntax is important) and then 2) migrate slowly but surely across to the new syntax (using e.g. JamesF's bot) making sure everything works as expected. So that's somewhere in between keep and delete I suppose :).
Pcb21Pete17:41, 18 April 2006 (UTC)reply
Neutral I think this nomination is premature until Tim Starling has completely and fully tested m:ParserFunctions so it is 100% more stable and efficient than qif.
Zzyzx11(Talk)18:05, 18 April 2006 (UTC)reply
Keep. As I understand it, the
ParserFunctions are still on trial (debug?) mode, so they're not completely stable, so start slowly deprecating it while keeping the template for backup purposes. I've got no objection to deleting it once it is reasonably safe to assume that any potential bugs have been quashed.
Titoxd(
?!? -
help us)21:22, 18 April 2006 (UTC)reply
Repeat after me: NOONE IS SUGGESTING THAT THIS BE DELETED WITHOUT FIRST BEING MIGRATED TO PARSERFUNCTIONS AND THOROUGHLY ORPHANED. Go on, repeat it. -
Splashtalk21:31, 18 April 2006 (UTC)reply
NOONE IS SUGGESTING THAT THIS BE DELETED WITHOUT FIRST BEING MIGRATED TO PARSERFUNCTIONS AND THOROUGHLY ORPHANED. Done. --
Ligulem21:36, 18 April 2006 (UTC)reply
Then why are we bothering with a delete discussion? Templates can be migrated without a discussion to delete qif. There is also the historical compatibility issue, which is a further argument to migrate and deprecate, but KEEP. So, repeat after me, IT IS PREMATURE TO DISCUSS DELETION AT THIS POINT. Contrary to what some people seem to think, the Wikipedia servers are not going to spontaniously combust if this template isn't immediately deleted. —
Doug Belltalk•contrib23:22, 18 April 2006 (UTC)reply
Keep -- I hate to say this, since by all accounts the new syntax is what we've been demanding. But the heavy use of this tool positively asserts its importance. By all means, deprecate its use -- as publicly as possible. Every possible place where an editor might go to learn about writing templates should have clear instructions that point out the currently accepted method and the interactions with substitution. Blank {qif} once orphaned, replace it with an obvious colored banner box notice: Do Not Use. But retain the page itself; it's not as if it consumes resources that way. It's earned its quiet retirement. Orphan of course; but that is non-trivial. I suggest that the first step is to deprecate, so the problem does not grow. A trusted team should set out to migrate templates to the new syntax -- and please avoid making other "improvements" meanwhile, despite temptation. Leave a clear record. Go slow while orphaning and allow time for problems to emerge. This is not an emergency.
John Reid22:02, 18 April 2006 (UTC)reply
Deprecate, replace all uses with the new syntax, and delete immediately after that is done. All the other bizarre programming-type meta-templates should be given the same treatment as soon as the new parser functions allow. --
The Anome23:18, 18 April 2006 (UTC)reply
Comment for the records: CBD is referring to the removal of the random function by Tim
[1]. It is pretty obvious that there is no way back for Tim to remove #if. If he would remove #if why would he have created ParserFunctions then? Also the removal of #if would be fixed within 24h by the community by restoring qif (or under what name ever). --
Ligulem07:24, 19 April 2006 (UTC)reply
Comment: this template deletion discussion is currently the top item on the community portal. As such, I feel it is my duty to raise my hand and say that I have no idea what this template does. Can someone please explain it in case other clueless non-developer people are coming here? If I had just stumbled across this in some random corner of Wikipedia, I'd be inclined to just mutter "not my business" and stumble on my way - but since someone put this in such a prominent place, I think we need to explain this to the
hoi polloi.
Johntex\talk02:23, 19 April 2006 (UTC)reply
Because some people do not want to understand how qif works, doesn't mean it uses black magic. qif uses current functionality of the template system. It uses
m:Help:Parameter default and template paramaters, and template inclusion. Nothing else. The correctness of qif can be mathematically proven. Simple thing for basic logic. Some people were just surprised that these basic things can be used to create qif. qif has already been there. Because it is possible to create it. And it's no virus, no hack and it does not rely on shaky features. Just for the records. Come on. Wikipedia is not a kindergarten. We also have articles about quantum physics. I'm sure nobody requests the removal of them only because they are not understood by the masses :-) --
Ligulem07:43, 19 April 2006 (UTC)reply
Keep the new code is not mature or well tested enough. Even then, I see little reason to actually delete it once it is not used.
Kotepho01:03, 20 April 2006 (UTC)reply
Keep - it's working as designed, and it's fully documented. Alternative solutions will find their way when they are debugged and documented. --
Omniplex01:48, 20 April 2006 (UTC)reply
Comment: It's actually still buggy and breaks a number of templates that require outputting the text {{{1}}} conditionally to function. Until this is resolved, it can't replace {{
qif}}. —
Saxifrage✎20:45, 21 April 2006 (UTC)reply
Oh, don't get me wrong: I'm not arguing that qif is better. I'm only making the point that #if is not currently working as designed and so isn't yet ready to replace qif. I think ParserFunctions is a fabulous improvement and I hope that bug gets squashed soon so we can start using it without breaking templates. —
Saxifrage✎23:35, 21 April 2006 (UTC)reply
Nor me. But I'm not yet sure about the parser functions, some string functions would be very nice, and that would get us near server side scripting. --
Omniplex14:27, 22 April 2006 (UTC)reply
Keep This MfD is putting the cart before the horse. Testing of #if should finished first, then the template should be deprecated. --TheFarix (
Talk)
22:41, 20 April 2006 (UTC)reply
Delete - Conditionals are evil, because they present a barrier to template editors who don't have advanced programming knowledge. Simple is good. --
Netoholic@19:33, 21 April 2006 (UTC)reply
I take your point, but please look at
my contribs for a whole bunch of templates which incorporate conditionals (and other calculations). I'm doing the programming, so that editors withou advanced programming knowledge don't have to. :-) --
Uncle Ed19:36, 21 April 2006 (UTC)reply
Ignoring the fact that I support deprecating {{qif}}, conditionals actually make things less complicated, not more. The biggest reduction in complexity is that things can be done in fewer templates (since many optionals that would have formerly spawned offshoots of existing templates can now be included in the main template; see {{Mtnbox start}}, {{Mtnbox climb}}, {{Mtnbox topo}}, {{Mtnbox coor dms}}, {{Mtnbox finish}}, {{Mtnbox geology}}, {{Mtnbox start nopic}}, {{Mtnbox coor dm}}, {{Mtnbox volcano}}, {{Mtnbox UK}}, {{Mtnbox start norange}}, {{Mtnbox start nopic norange}}, {{Mtnbox prom}} as compared to the single template {{Infobox Mountain}} which handles everything those thirteen templates did). Further, the barrier of entry for new editors to learn is reduced thanks to articles like
Wikipedia:Qif conditionals (recently updated to document #if). IMO if you think conditionals are too hard for new editors, you could help expand the existing documentation for #if (and the other
m:ParserFunctions) to make it simpler for them to learn. Finally, see Ed's comment above; many new editors won't touch templates because most of them cover everything they want them to do already. —
Locke Cole •
t •
c21:32, 21 April 2006 (UTC)reply
The MediaWiki software is a little complicated for the average user, but fortunately, most don't need to worry about it. I haven't looked at the code that supports {{PAGENAME}} or {{CURRENTDAY}}, but I feel pretty comfortable using them nonetheless. I think "keep it simple" is a very good goal. Having conditionals that allow some fraction of the editors to create templates that simplify editing for others is not creating a barrier to editing, but rather is providing a valuable level of customization between "developer" and "editor". Conditionals are actually helping "keep it simple" by providing a (very minimal) macro language for extending the wiki. I think #if: is a very positive step forward in acknowledging this need and providing a better means to support it—and I hope that the
m:ParserFunctions are extended somewhat—it's just a bit premature to discuss deleting{{qif}} until the issues with the current implementation are shaken out. —
Doug Belltalk•contrib16:29, 24 April 2006 (UTC)reply
Keep the new code is not mature or well tested enough. Even then, I see little reason to actually delete it once it is not used — Preceding
unsigned comment added by
Megan 189 (
talk •
contribs) 2006-04-23 22:20:46
Delete--I tend to think that if this is deleted then we just will use #if ... I wouldn't think they'd want to mess up thousands of pages by not. Then again... it may be interesting.
grenグレン16:56, 27 April 2006 (UTC)reply
Defer to developer(s). An unusual vote I know, but this is something that should be their decision, since they know what they're talking about.
the wub"?!"23:20, 27 April 2006 (UTC)reply
Change to use the current syntax and keep as a mnemonic alternative to #if, possibly move to {{if}}. Parser functions are a great tool for producing automagic templates, which provide increased functionality and code readability. We should provide automagic templates for basic conditional behaviour, which should be used in settings where non-programmer editors are likely to need to read and understand the code without learning yet another syntax. The template will never be changed, so its effect on resources will be negligible. In any case, keep the history to preserve a record of a time when Wikipedia community showed its collective intelligence and resourcefulness and created a complete set of new useful behaviour out of almost nothing.
Zocky |
picture popups17:49, 28 April 2006 (UTC)reply
Conditional keep. However, to discourage rogue admins, establish a rule that if anyone vandalizes the template, they will be immediately blocked for a certain amount of time. --
King of♥♦♣♠04:17, 1 May 2006 (UTC)reply
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the page's talk page or in a
deletion review). No further edits should be made to this page.