Wikipedia:Templates for deletion/Log/2006 May 3

From Wikipedia, the free encyclopedia

You have new messages (last change).
< May 2 May 4 >

[edit] May 3, 2006

The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review). No further edits should be made to this page.

The result of the debate was delete Circeus 17:47, 13 May 2006 (UTC)

[edit] Template:Infoboxelement Orbitersim Spaceport Nav

Template:Infoboxelement Orbitersim Spaceport Nav (edit|talk|history|links|watch|logs)
It's had a TfD notice on since March. Looks like it was meant to be part of this debate which closed as delete. No vote SeventyThree(Talk) 21:56, 3 May 2006 (UTC)

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 template'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 template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review). No further edits should be made to this page.

The result of the debate was Delist the nominator has left the project, not enough consensus for delete/keep. — xaosflux Talk 01:58, 27 May 2006 (UTC)

[edit] Template:ISLEAPYEAR

Template:ISLEAPYEAR (edit|talk|history|links|watch|logs)
Unnecessary dupe/fork of {{IsLeapYear}}. —Locke Cole • t • c 09:02, 3 May 2006 (UTC)

  • Delete. —Locke Cole • t • c 08:30, 3 May 2006 (UTC)
  • keep. The separation from current datetime and other cases should be considered, notably because templates that depend on current time have performance impact on wiki caches. There are ongoing work for enhancing the cache performance for pages that do not depend on current time, depending on whever a CURRENTxxx macro has been used in the page; if the page does not use it, it should live longer in the cache, whilst CURRENTxxx will reduce the computed lifetime in caches. This template is not a duplicate, as it takes NO default parameter (no it does not take CURRENTYEAR as the default and this is expected. verdy_p 09:21, 3 May 2006 (UTC)
    note: I will subdivide the templates that depend of current datetime from the others that don't depend on it in the basic date computing templates, using two subcategories. The performence of servers greatly depend on correct lifetime in caches. The longer the lifetime for all pages and articles, the best it is on the web site. But a long lifetime will be necessarily limited if any CURRENTxxx is used, so the server will initialize the lifetime to very long bydefault and will adjust the lifetime when it will parse any builtin CURRENTxxx macro, according to their meaning: CURRENTDAY should reducethe lifetime to the end of UTC day, CURRENTMONTH should reduce the lifetime to the end of UTC month, and so on. Let's preserve the possibility for saving computing resources on servers, and maximize the use of caches. This was alreadytested onFrench Wikipedia from which these templates were imported, and these basic templates have better performance and are computationally correct, unlike most of the templates currently in category Datemath. verdy_p 09:29, 3 May 2006 (UTC)
    • Then it's a fork. If there's some problem with having the default of CURRENTYEAR (which I'll wait for you to show me where the devs say this is a problem) then you discuss it. You don't create a second template with an identical name (except for all uppercase) to circumvent discussion. —Locke Cole • t • c 09:58, 3 May 2006 (UTC)
      • Note: your formula is not exact in all cases, for general date computing. There are subtle things in ISLEAPYEAR regarging rounding issues (that affect the mod operator as well as round). Additionally there are missing parentheses for evaluating parameters that include some simple arithmetic, to avoid calling extra #expr when this is not needed. verdy_p 11:56, 3 May 2006 (UTC)
      • I created this template long before, as part of a collection, seeing that most existing date templates are beta with lots of inaccuracies, or that were very disorganized. I also expect that the server may provide built-in templates (all uppercase like the existing CURRENTxxxx templates) to avoid expressions, so the calc templates would be avoided. From what I have seen, pagesthat use any CURRENTxxxx templates have very short lifetime, whatever the type of CURRENTxxx is used. Iwould militate to avoid mixing all uses that depend on current time from others (at least as long as all templates will be fully evaluated even when they are not used such as default values when a parameter is actually provided and the default CURRENTxxx discarded). verdy_p 11:51, 3 May 2006 (UTC)
  • Delete The recent duplication of templates in Category:Date math into Category:Date computing template doesn't make alot of sense to me. It creates confusion on what the differences are and when to use one or the other. I'd rather combine the best of both groups into one category. Apparently the motivating factor is avoiding use of 'current' time: various 'Date math' templates allow the user to include the time as a parameter or default to current if no parameter is set - while 'Date computing template' templates are split so there is one which allows a parameter and another which assumes the current time. I find one template better than two in most cases (and certainly better than three). The reason for this 'category fork' is apparently 'page caching' concerns. Do we know that these are a valid/significant issue? This particular fight is over 'leap year' calculation. Which looks at 'CURRENTYEAR'. Even supposing that the calls which include a parameter would have their cache invalidated when 'CURRENTYEAR' (the default if they DIDN'T specify a parameter) changes... that happens once a year. This cannot possibly be a significant server load concern. I'd guess that 95% of uses are going to be for 'CURRENTYEAR' anyway with the specified year parameter being the exception. If evidence of a real 'page caching' issue can be shown I might understand some of the other forks, but this one just seems needless. --CBDunkerson 11:36, 3 May 2006 (UTC)
    • This was not a duplication of categories, this was a separate clean collection (exact, and without assuming lots of specific defaults that are page-specific).
    • I think that lots of cleanup is needed in the existing "Date math" category which includes various things more or less tested, and that mix Wikipedia specific templates for some particular pages (with limitations on the acceptable values) with other general purpose date computing templates. There are some of them which are horrors, full of switches, hard to maintain in sync, and only a few should use calc (others should use the generic calc templates, that shoulod be kept to a small number without specializations).
    • Of course, when cleanup of working and bad-working templates is finished, the two categories "Date math" and "Date computing template" should be merged into a single one, keeping the best of them. verdy_p 11:51, 3 May 2006 (UTC)
      • The 'Date math' category predates the introduction of ParserFunctions and thus includes some older implementations... most of the really scary stuff (believe me, you have no idea) has been replaced but it is still in transition. Being a 'clean collection' does not make 'Date computing template' any less of a duplication... the better course would have been to work with the existing templates rather than creating forks which now have to be sorted out. The central issue you need to address is why do you believe it is neccessary to split 'current time' vs 'parameter set time' into separate templates? How much does it 'save' in server resources? Note also that your versions are more often 'meta templates'... which cause some people around here to have fits because of the supposed 'server load' they cause. Instead of the single {{JulianWeekday}} you have {{WEEKDAYNAME}} which calls {{WEEKDAYNUMBER}} to do the same thing. Likewise, all of your 'CURRENT' templates call the 'non-current' versions with the parameter set to the current time. Is the 'server load' you are theoretically saving by having separate templates greater or less than the 'server load' you are theoretically increasing by having nested templates where a single call would suffice? And is any of it more significant than a few nanoseconds here and there... which aren't worth the added complexity of multiple templates? --CBDunkerson 12:19, 3 May 2006 (UTC)
        • The workload on servers is not much about the time to compute the template, but the time to compute the pages that use them (notably large pages that include lots of date references, date navigation panels used in various articles, and so on). Most articles that include date navigation panels do not depend on current time: we go from one knowndate to the other one, and the result is cachable for long, until there's a real change in their content (not in the navigation panel itself which remains cached).
        • The split between CURRENTxxx and xxx is to facilitate maintenance: the complex formula is in only one calc template, and the CURRENTxxx use them, instead of duplicating the formulas. Those formulas are complex enough to create and fix that I have simplified things by not considering variants such as optional parameters.
        • If you think that CURRENTxxx should import the formula directly, then let's do that, but we'll have now two templates to edit for these formulas instead of one, and both will have to be listed in Templates using ParserFunctions.
        • If ParserFunctions ever change, we'll need twice the job to patch both...
        • If you merge the two templates into only one with CURRENTxxx defaults (if those defaults are effectively universal and do not depend on pages using them that would prefer other defaults), it will be even more difficult to edit it if ParserFunctions change. That was my idea when I did that: keep things simple and easily maintenable.
        • As much as possible, I have tried to adapt to existing templates by keepoing the return values and formats compatible with each other, and keeping the possibility to use the same parameters. But I did not want to modify immediately all the date templates in transition, because they are already heavily used. So this transition is smoother like this, by substituting templates only when the compatibility has been verified. verdy_p 13:11, 3 May 2006 (UTC)
          • According to Brion VIBBER, magic words like CURRENTTIME (and by extension, I'd suspect, CURRENTYEAR) do not affect page caching. So unless you know something the lead developer doesn't, I don't see the point in these forks. I think the matter of potential code complication by having default values should be discussed by template editors rather than making a decision about that here. Perhaps you could start a discussion at Category talk:Date math or Category talk:Conversion templates (and post pointers to wherever you start a discussion at Village pump (technical))? —Locke Cole • t • c 21:09, 3 May 2006 (UTC)
            • It was proposed in the past, to allow the Wikipediaservers to increase the lifetime of pages in caches, instead of generating short lifetime; this would save resources on the servers (where cache misses is the most critical as it affects their workload, and it could allow increasing the number of cachesand their efficiency, including remote caches using intercontinental links to the servers in Florida); and it was experimented with success on some other non-Wikipedia wikis that can benefit from many caches evenif there's a small central Apache/PHP server. When the server crashes, caches will still maintain a copy of the pagesfor long. When the server finally restarts, it will inform the caches gradually to purge their content cached since the restart, avoiding the restart nightmare with lots of traffic from all caches. I think that the correct management of cache capabilities (by issuing long lifetime for almost all pages and resources delivered by the server(s)) should be part of the "website survival kit", notably during database maintenance, or after a power failure or other severe failure. 13:15, 5 May 2006 (UTC)
Delete Unnecessary duplication--Runcorn 19:52, 25 May 2006 (UTC)
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 template's talk page or in a deletion review). No further edits should be made to this page.
Retrieved from "http://en.wikipedia.org../../../t/e/m/Wikipedia%7ETemplates_for_deletion_Log_2006_May_3_450d.html"