Jump to content

Wikipedia:Templates for discussion/Log/2015 August 24

Add links
From Wikipedia, the free encyclopedia
< August 23 August 25 >

August 24

[edit]

Template:Florence tournaments

[edit]
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 section.

The result of the discussion was relisted at Wikipedia:Templates for discussion/Log/2015 September 11#Template:Florence tournaments. Alakzi (talk) 23:16, 10 September 2015 (UTC)[reply]

A template with zero links other than one to the parent article. ...William, is the complaint department really on the roof? 22:46, 24 August 2015 (UTC)[reply]

  • Keep Tennis tournaments usually have a navbox with this design. See Category:ATP Tour tournaments navigational boxes and Category:WTA Tour tournaments navigational boxes for numerous examples. In addition to providing navigation (when there are actually blue links), it shows which years the tournament was played and which of those years have articles. Even if that is currently no years, it does give useful information at the bottom of the main article. Tennis tournaments often change name for sponsorship reasons so it's sometimes difficult to figure out which editions have an article. As a tennis reader I'm so used to these systematic navboxes that it's annoying when an article doesn't have it. PrimeHunter (talk) 04:03, 27 August 2015 (UTC)[reply]
Comment A template that doesn't link to anything serves absolutely no purpose. The tournament articles need to be done first, then the template. This is a classic case of the cart before the horse....William, is the complaint department really on the roof? 13:18, 28 August 2015 (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 template's talk page or in a deletion review). No further edits should be made to this section.

Template:NTFA (1886-1986) seasons

[edit]
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 section.

The result of the discussion was delete - uncontested. (non-admin closure) Alakzi (talk) 19:26, 3 September 2015 (UTC)[reply]

All redlinks, doesn't navigate anything. Can be recreated in the event that any articles for NTFA seasons are written. Jenks24 (talk) 21:58, 24 August 2015 (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 template's talk page or in a deletion review). No further edits should be made to this section.

Archive navigation templates

[edit]
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).

The result of the discussion was Keep all While there is considerable support to merge these templates, the consensus seems to be that it would hinder more than it would help.--Aervanath (talk) 20:31, 26 October 2015 (UTC)[reply]

Propose merging all of the above.

Identical purpose. No need for more than one template. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:10, 24 August 2015 (UTC)[reply]

I've struck {{Archive banner}} - wrong type, sorry. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:24, 25 August 2015 (UTC)[reply]
I've added {{Talk archive}}, which I'd previously overlooked. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:27, 25 August 2015 (UTC)[reply]

Alakzi (talk) 23:13, 24 August 2015 (UTC)[reply]

  • I think I agree with Alakzi here on the particulars. --IJBall (contribs • talk) 04:05, 25 August 2015 (UTC) Rethinking this based on SilkTork's comments... --IJBall (contribs • talk) 23:50, 25 August 2015 (UTC)[reply]
  • Please note that {{Talkarchivehist}} offers unique functionality, ensuring better understanding and transparency of the archive method, somewhat blending the 'cut-and-paste' and permalink archiving methods. See Help talk:Archiving a talk page/Archive 3#Cut-and-paste archiving: Increasing transparency for more info. Cainamarques (talk) 05:38, 25 August 2015 (UTC)[reply]
    • I've never seen that before and it's highly desirable functionality that should definitely be baked into a unified navigator. The inconsistent use of the two methods (and the pros and cons of both) frequently weighs on my mind.  — Scott • talk 16:48, 19 September 2015 (UTC)[reply]
  • As someone who frequently archives talkpages, and consults the archives, I have a strong preference for the functionality of Template:Talk archive navigation - it contains a redlink to facilitate speedy and accurate creation of the next archive page, and it allows scrolling back and forth one page at a time, which is all that is required. For me, Template:Automatic archive navigator is limited, as it does not contain forward linking to the future archive, and at the same time has too many links, set out in an unhelpful and distracting manner. There are six links. They don't display the first and last archive - it's a mix of the next two in either direction, plus - after skipping two archives in either direction - the archives five pages forward and five pages back: Wikipedia talk:WikiProject College football/Archive 10. The most usual form of scrolling is one page at a time. To go to a particular page, it's quicker and easier to go back to the talkpage, and select the page number from there. aan gives a disjointed navigation scheme that offers confusion and wastes time. If some users wish to keep six links, then I would oppose a merge, if it's agreed that after the merge it is the functionality of tan that is kept along with just one link forward and back, then I have no objection. SilkTork ✔Tea time 20:55, 25 August 2015 (UTC)[reply]
I'd rather keep tan as it is. My position at the moment is that I don't see an advantage in having six links - especially of the complex type currently used by aan, though am open to hearing arguments for the desirability of having six links. SilkTork ✔Tea time 21:33, 25 August 2015 (UTC)[reply]
  • I myself currently use {{Talk archive navigation}} – is there a parameter that can be added to the merged template that could allow the user to control how many Archive pages links are displayed by the template? And I agree with SilkTork that I too find the "forward" linking functionality useful, and would prefer that stayed in the merged version (as least as a parameter 'option', if not automatically)... Also, as a practical matter, I think the final merged template should be at {{Talk archive navigation}}, not at {{Automatic archive navigator}}, as I find the former name much more intuitive than the latter name. --IJBall (contribs • talk) 23:54, 25 August 2015 (UTC)[reply]
  • That parameter already exists: |links=3. Both templates have "forward" linking functionality. Are you referring to the red link? My proposal is that it be made the default. I'd suggested {{Automatic archive navigator}} as the name for no other reason than that's what the module's called; it makes no functional difference so long as the two templates are merged. And I tend to agree that "Talk archive navigation" is a better name. Alakzi (talk) 00:15, 26 August 2015 (UTC)[reply]
Recalling the previous discussion on this - Wikipedia:Templates for discussion/Log/2013 November 12#Template:Talk archive navigation - the consensus was to merge aan into tan (as tan describes what it is: a talk page archive with navigation), and to keep the link forward into the future archive. Looking at the technical aspect of that discussion, I suspect the merge didn't take place because of the concern that merging the six link functionality of aan would result in potentially three forward red links, and the unknown consequence of that. Unless there is a strong preference for keeping six links I think the best option would be to simply redirect aan to tan, and keep tan exactly as it is. It works well, and is the most popular choice for human editors. SilkTork ✔Tea time 21:30, 25 August 2015 (UTC)[reply]
This is false. Module:AutomaticArchiveNavigator, which both {{Aan}} and {{Tan}} use as a backend, is programmed to only show one red link at all times: Special:Diff/677842701. ... and is the most popular choice for human editors. As shown by all metrics. Alakzi (talk) 21:35, 25 August 2015 (UTC)[reply]
  • Keep All - As redundant as many of these may seem to the nom and others, let's face it; Not every type of archive tag works for every user. I originally used {{archive box}} when I started archiving my messages. I can't expand it, and it crowds up one side of my talk page, so it doesn't serve me anymore. {{archive box collapsible}} helps me avoid that. Other users might feel differently about this, and for them it or some other archive tag might be alright. ---------User:DanTD (talk) 03:04, 31 August 2015 (UTC)[reply]
    • "Not every type of archive tag works for every user" Indeed not; but these templates are not for individual users with odd proclivities; they are for communal use on shared talk pages. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:01, 3 September 2015 (UTC)[reply]
    • The template namespace is a communal space, as are the talk namespaces; and archive navigation templates are intended to be usable by everyone, and need not align with the idiosyncrasies of whoever might've had the opportunity to first create an archive. It is remarkable that some editors believe that they're entitled to their own archive navigation template. Alakzi (talk) 14:27, 3 September 2015 (UTC)[reply]
  • Keep all - Per previous user's reasoning. Safiel (talk) 02:45, 1 September 2015 (UTC)[reply]
  • Keep all per DanTD. We could have one super-template with lots of links and configuration options, but the current choices of functionality, which are quite varied among these templates, should be preserved, and replacing current instances with a new version with specific parameters would be an unnecessarily time-consuming task. BethNaught (talk) 13:23, 1 September 2015 (UTC)[reply]
  • Merge: As per nom, all templates have same purpose. Andy usually nominates many templates for "merge" or "delete" and many people don't like it, even me too don't like it, but almost all time Andy's nominations are really worth. These are really redundant templates. --Human3015Send WikiLove  22:31, 2 September 2015 (UTC)[reply]
    • They serve the same purpose, but they do it slightly differently. In this and the previous merge discussion there has been some uncertainty about the value of the multi-link function of aan. In the previous merge discussion the consensus was to merge aan into tan, but I think the merging was held up because of some uncertainty about the multi-link function. I would prefer not to have multi-linking, and there is some support for removing it, but also some opposition. Would you assist this discussion by giving your views on that. At the moment, because there is some doubt about what will happen regarding that multi-linking if a merge is agreed, I am inclining to Keep all as a more desirable outcome. For me, tan is fine - it's the most popular template out of the bunch, and offers the best combination of functions - a Keep all outcome would allow tan to continue. If there could be clear clarity among those looking to merge, that tan is kept as it is as the default template, I would support a merge. !voting "merge" without comment on the functions of the templates may result in some loss or distortion of the current functionality of tan, and that concerns me. SilkTork ✔Tea time 20:19, 4 September 2015 (UTC)[reply]
  • Keep {{tan}} as is. I have no opinion on what happens to the rest as long as tan is kept in its current form. SilkTork ✔Tea time 12:39, 5 September 2015 (UTC)[reply]
  • Very strong keep for {{Archive navigation}}. It serves a different purpose than, for example {{Talk Archive}}. Instead of serving as a notice of what the archive is (as Talk Archive and several others do), it serves to navigate from one archive to the next. I get it, that there are now other templates that also provide that function, but so what. It's widely used, and merging it simply serves the purpose of causing headaches for a lot of editors in order to have fewer templates. I am fine with some sort of merge of {{Automatic archive navigator}}, {{Talk archive}}, and {{Talk archive navigation}}, because their default outputs look identical on the page. I would not object to deleting {{Archive-index}}, because it is so rarely used, but I also do not see a particular need to delete it, other than slavish devotion to orderliness as opposed to creating an encyclopedia. Otherwise, I would keep all. --Tryptofish (talk) 20:35, 7 September 2015 (UTC)[reply]
  • Keep as each template serves a unique function, even if the nominator does not find this useful the wide adoption of these templates shows that many other editors do find this of use. - Dravecky (talk) 20:41, 8 September 2015 (UTC)[reply]
  • Merge per nom. Stranger195 (talk • contribs • guestbook) 02:42, 12 September 2015 (UTC)[reply]
  • Keep all per DanTD and others. — Preceding unsigned comment added by MarnetteD (talk • contribs)
  • Merge all. No-brainer: this is absolutely the right thing to do, for everyone, forever. People reading talk archives will benefit from being able to expect the same features and behavior wherever they are. People creating talk archives will benefit from not having to choose one of several similar but not functionally equivalent templates, or having to pick one that isn't the one that they prefer because whoever set up the earlier archives chose a different one. As others have commented above, these templates are for everyone, not individual editors. If people have preferences as to what they see when navigating talk archives, no doubt there's some gadget doohickey way that could be accomplished; but the core experience should be universally consistent.  — Scott • talk 16:48, 19 September 2015 (UTC)[reply]
    • Thanks to Andy for setting up a demo of these templates. Specific comments, a la Ais523 below: {{UserTalkArchive}} is {{Talk archive navigation}} with namespace detection - that should be an easy candidate for merging immediately. The tools on {{Talkarchivehist}} should be added to {{Talk archive}} in a collapsed panel - not everybody needs to see power tools, but having them a click away would be highly useful. After doing that, you're basically left with {{Talk archive}} and {{Talk archive navigation}} / {{Automatic archive navigator}}. The latter two are essentially the same thing; they should be merged. After that, it's two versions of the same thing that only differ as to whether navigation is present. I am personally of the opinion that it should always be present. Lua can probably cope with doing the right thing if navigation isn't needed to be shown (archive 1 of 1). The end: one template.  — Scott • talk 18:46, 6 October 2015 (UTC)[reply]
  • Keep all Every template serves a different purpose, even if slight. Merging them into a single template can cause unintended effects on the pages themselves. The proposals to merge/change templates that don't currently use an automatic archive navigation system to ones that do will break navigation on some pages. Not everyone uses the same naming format. Avicennasis @ 10:13, 8 Tishrei 5776 / 10:13, 21 September 2015 (UTC)[reply]
    • Any time that you say a change "will break" something, you're essentially saying that our template coders are stupid. Give them the credit that they deserve, please, and assume that every template problem can be solved.  — Scott • talk 11:11, 21 September 2015 (UTC)[reply]
  • Keep all per Dan and per the same fundamental argument extensively laid out here. Different people prefer different templates for different purposes, and the point of merging redundant templates is to make things easier and to reduce confusion by eliminating the duplicate templates that go by different names. This does not mean that slightly varying templates that serve the same fundamental purpose but are not identical must be forcibly standardized into one master template, so that the users who want to achieve the varying purposes of any specific version need to learn to configure customizable parameters or simply go without. In short, merging does not actually achieve anything positive for the project. It does not reduce confusion nor does it make the project easier to use. It just eliminates editor options for no reason. This proposal is a non-solution to an invented problem. Swarm ♠ 05:07, 22 September 2015 (UTC)[reply]
    • Many of these points are already addressed - and refuted - above. You say "Different people prefer different templates", but usually nobody asks the people affected by the choice of template what is their preference; it's simply the whim of whoever first implements archiving. Any issue with "need to learn to configure customizable parameters" exists just as much currently as "need to choose and learn which template to use". No cogent arguments are made, that different archiving styles are needed in different places. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:02, 22 September 2015 (UTC)[reply]
      • I'm making a comment that is partially a reply to what's just above, and partly a reply to the comment immediately below. I understand the concept of redundancy as it applies here, and I do realize that merging would result in a situation where everyone could still get it to work correctly. But here we are of course discussing templates rather than articles, and so concepts like not having duplicate pages on essentially the same subject do not apply. What does apply is what makes it easiest for editors to get on with the business of improving content, instead of spending time reconfiguring archives. It's not a matter of "liking" so much as the fact that there is no good reason to create more work for editors without a corresponding benefit in article content. It's not like there is a lack of server space for the templates, so cleaning them up isn't an issue. Certainly, an editor can choose to use another version of the template and make use of its features, but that should not mean that editors must do that. --Tryptofish (talk) 23:11, 22 September 2015 (UTC)[reply]
        • there is no good reason to create more work for editors without a corresponding benefit in article content This is short term thinking. You should always be working for the benefit of those interacting with this project in the decades or generations after you've gone.  — Scott • talk 11:31, 23 September 2015 (UTC)[reply]
          • In that case, those future editors would have access to the templates we are discussing here. Having access to fewer templates might not necessarily hurt them, but I can't see how it would help them, unless the point is that it would "help" them because somehow having fewer templates would make Wikipedia less "cluttered". There's a consensus that WP:Redirects are cheap, and I would argue that templates are similarly cheap. --Tryptofish (talk) 22:12, 23 September 2015 (UTC)[reply]
            • @Tryptofish: Templates are most certainly not cheap, as they must be maintained as the standards of the encyclopedia evolve. ~ RobTalk 22:15, 23 September 2015 (UTC)[reply]
              • Yes, that's a valid point. But I'm not seeing an argument here that these templates no longer work and need to be revised. If we got to a point where some of the templates stopped working but others worked well and could substitute for them, then I'd support deleting the broken ones (and please remember that I'm partly supporting some of the merges now). A "merge all" decision here would require quite a few of us to go and reconfigure some archive pages, even though nothing is currently broken. --Tryptofish (talk) 22:21, 23 September 2015 (UTC)[reply]
                • The issue is not that the templates "no longer work" or are "broken". The issue is that they don't work well enough. Well enough is defined as producing a reliable, consistent experience for all editors and readers, so that nobody is ever confused, or has to think twice, or decide which one of several inconsistent templates with differing option styles is "right" for what they're doing - forever.  — Scott • talk 13:50, 5 October 2015 (UTC)[reply]
                  • Thank you for that helpful clarification. I can sort of see how editors may have to decide which option they want to use, but I don't think that this is causing any significant amount of confusion. It's arguably kind of nice to have a choice, and anyway, it isn't like making a "wrong" choice in this regard results in a messed up archive page. I do not see any evidence that, once an editor has chosen to use one of these templates, other editors coming to read the archives end up running into trouble because a sub-optimal template results in hampered navigation. As such, I'm just not seeing a problem that needs to be repaired (although, again, please remember that I've taken what I hope is a nuanced position that does support some merging). If the problem is that some editors believe that there needs to be a single uniform template for all archives, and they find it troubling that there is not just one, well, that seems to me to not be a real problem. --Tryptofish (talk) 14:19, 5 October 2015 (UTC)[reply]
                    • Consistency (more specifically, avoiding unnecessary inconsistency) is a basic principle of designing usable interfaces. Why should a novice user be presented with a different style of archiving on the second talk page they visit than the first? The only arguments for doing s have been "ILIKEIT". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:37, 5 October 2015 (UTC)[reply]
                      • I guess it comes down to a balance between consistency and choice. I don't think that the English Wikipedia recognizes, as a matter of policy, any requirement that one should trump the other. After all, there are plenty of interface issues where we explicitly allow some pages to be formatted one way, and other pages to be formatted another, with WP:ENGVAR being just one of many examples. --Tryptofish (talk) 14:43, 5 October 2015 (UTC)[reply]
                        • ENGVAR isn't about interface design. We don't, for instance, allow users to move the search box or edit links on individual articles. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:33, 5 October 2015 (UTC)[reply]
                          • From a reader's perspective, "color" versus "colour" is part of how they experience what they see on our pages. To me, that's part of the interface; your mileage may differ. --Tryptofish (talk) 21:36, 5 October 2015 (UTC)[reply]
                            • I have to disagree completely with you here - the issue of variation in content is not related to UX. ENGVAR exists because we've long agreed there's no "right" default for this international project to use for English, but many strong arguments exist for the value of standardization in UI, most of which have already been mentioned here. (FWIW, I've been saying for years that we have the technological ability to allow our users to choose a display language, and we could avoid ENGVAR entirely simply by the careful use of templates. But that's a discussion for another day!) Also, you say that we explicitly allow some pages to be formatted one way, and other pages to be formatted another - that's a variant of our old friend from AfD, the "other stuff exists" argument, and isn't a reason to prevent a standardization effort in any particular area.  — Scott • talk 10:59, 6 October 2015 (UTC)[reply]
  • Merge all. "But I like it" has never been an appropriate rationale for a keep, and "redundant" is an explicitly acceptable rationale for a merge or delete. Creating one template with a few parameters to allow collapsing, etc, makes a whole lot more sense even for those users who like to use different templates. When you need to convert from non-collapsed to collapsed, for instance, you'd just need to edit one parameter rather than change the whole template, which would involve going out and finding something new. No editor options need be deleted in a merge; that's a red herring. ~ RobTalk 10:18, 22 September 2015 (UTC)[reply]

  • Merge some (although IMO this TfD should be abandoned and replaced with a more specific one talking about specific merges; in its current state, it's going to be pretty much impossible to close sanely because it's trying to do too much in one TfD). Part of the problem here is that we have two different functionalities involved here. One is a feature that allows you to easily move from one talk page archive to another, as typified by {{archive navigation}}. The other is a warning explaining what a talk archive is, as typified by {{talk archive}}. Some templates combine the functionality of these two, and/or add extra functionality.

    The template that's the biggest offender here is {{archive-index}}, because it's being used on Talk: pages but has the wrong formatting for the purpose. I can't see anything that would be lost by replacing {{archive-index}} with a redirect to {{talk archive navigation}}, which performs exactly the same purpose (AFAICT), and better.

    For the rest of the templates, I'd like to see the internals reworked to call into a smaller set of templates, mostly for maintainability reasons. In particular, IMO Module:AutomaticArchiveNavigator should concern itself only with producing the navigation part of the archive (like {{archive navigation}} does), and {{archive navigation}} changed to #invoke the module. Templates like {{talk archive navigation}} and {{automatic archive navigator}} should be maintained (merging them more completely, as the previous TfD suggested), but implemented as simply {{talk archive}}{{archive navigation}}, passing on parameters as needby; that way, the two parts of the template can be globally fixed independently, and people don't need to mess about with Module:AutomaticArchiveNavigator/config in order to be able to make changes to {{talk archive}} (as they do currently).

    Of the remaining two templates, {{UserTalkArchive}} feels like it's bundling together multiple funcitonality that should really be separate, but as it has a different purpose from the other templates, that isn't so much of a problem (its header should probably be {{talk archive}} with a parameter, though, and perhaps the box on the right can be taken from an existing archive template that isn't part of this nomination). Meanwhile, {{talkarchivehist}}'s functionality looks like it would be very useful if it were used more (and should be added to the archivebots!), but is currently (due to the way the templates are designed) incompatible with most of the others; I'd like to see its functionality merged into {{talk archive}} as a parameter (which could then be passed through from most of the others), thus allowing it to be (e.g.) used with {{aan}}-style navigation, although I feel like that's something that can safely be done via normal editing rather than needing to be discussed at TfD. I think that's everything, right? (And I hope this TfD ends up being split into a sequence of smaller TfDs so that the multiple unrelated issues here can be discussed separately.)

    — Preceding unsigned comment added by Ais523 (talk • contribs) 01:50, 5 October 2015‎
  • Keep. In general, it is undesirable to merge all these templates into one. And in some cases, touching the template is the recipe for trouble. Specifically:
  1. {{Automatic archive navigator}} (20814 transclusions) and {{Talk archive navigation}} (37673 transclusions) are just Lua wrappers. They are necessary evil: It is a fact that Lua modules in Wikipedia need wrappers. Now merging aan and tan functions in the underlying Lua module is another matter that is out of the scope of this discussion. (Is it even possible without repercussions?) But doing this certain 37673 replacements in Wikipedia is an exercise without benefit.
  2. {{Archive navigation}}, {{Archive-index}} and {{UserTalkArchive}} are so different in function that merging them is like merging any two arbitrary templates.
  3. Any merger with {{UserTalkArchive}} is out of question because it is one of those low-performance templates that must either become a Lua module or be deleted.
  4. I have no prejudice against local actions like doing something for {{Talkarchivehist}} (71 transclusions) and {{Talk archive}} (110583 transclusions), as they look very similar to {{Talk archive navigation}} and {{Automatic archive navigator}}. Or perhaps a deletion/merger discussion for {{Archive-index}} (12 transclusions) is constructive. Actually, I think the nomination would have had much more success if the nominees were more carefully chosen.
Best regards,
Codename Lisa (talk) 10:03, 6 October 2015 (UTC)[reply]
So your recent, overturned, closure of this discussion as "keep" was a supervote. Your claims that these templates cannot be merged is utterly bogus; as is your claim that discussion of the underlying lua code is out of scope; and as is your claim of the need for "37673 replacements". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:12, 6 October 2015 (UTC)[reply]
@Codename Lisa: in some cases, touching the template is the recipe for trouble - I refer you to my reply above to Avicennacis.  — Scott • talk 11:06, 6 October 2015 (UTC)[reply]
  • The merger is change for the sake of change, with trouble and no benefits.
  • Some of these templates are entirely dissimilar.
The supporters of a merger have not addressed these concerns satisfactorily. There are lots and lots of opportunities for a compromise and an actual reduction in the complexity which could appease everyone. But, at this stage it is too late. Too many hearts are broken. Fleet Command (talk) 04:28, 11 October 2015 (UTC)[reply]
This comment has no informational content. I can only hope that whoever closes this discussion assigns it appropriate weight.  — Scott • talk 20:20, 12 October 2015 (UTC)[reply]
The first bullet point is an outright falsehood; the second ignores the fact that, while the opposite ends of the spectrum may be dissimilar, each of these templates is close to the next. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:52, 12 October 2015 (UTC)[reply]
Yes, yes, it has no informational contents and at the same time it is falsehood. Like I said, lots of opportunities for compromises, but you two just break hearts and squander it. I couldn't help but noticing: Ais523 and Codename Lisa said the same things above, only Scott thanked one and attacked the other. It makes me think Scott didn't read beyond the bolded words. He who says "Merge" gets thanked, but they who say "keep" get attacked, even if they relax it by "#I have no prejudice against [~snip~]" or "There are lots and lots of opportunities for a compromise [~snip~]". Fleet Command (talk) 10:39, 13 October 2015 (UTC)[reply]
No. Your vacuous comment bears no relation to Ais523's.  — Scott • talk 15:19, 13 October 2015 (UTC)[reply]
That's self-contradictory. If my comment was really "vacuous", then my second comment should be taken as a clarifying comment. But you label it as "Misrepresenting another editor. Nice." Seriously, all this combat-mindedness is completely unlike an admin who has been here since 2003. Has this person's account been taken over? Fleet Command (talk) 18:54, 16 October 2015 (UTC)[reply]
I won't pander to your apparent attempt to get a rise out of me. Bye.  — Scott • talk 16:01, 17 October 2015 (UTC)[reply]
As a matter of fact, I was attempting quite the opposite. So, great!
By the way, it is rather the first time I see someone using a verb like "pander" (literary and metaphorical) with a phrase like "get rise out of" (street talk). So, I guess our communication wasn't entirely fruitless. Fleet Command (talk) 06:57, 20 October 2015 (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 template's talk page or in a deletion review).

Template:MWSS

[edit]
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).

The result of the discussion was delete. Alakzi (talk) 18:44, 13 September 2015 (UTC)[reply]

Promotes an arbitrary categorization based on original research (see also Talk:Outlook.com#Requested_move_17_August_2015), redundant to other navboxes such as {{MSN services}}, {{Microsoft Office}}, {{Windows Live}} ViperSnake151  Talk  18:54, 24 August 2015 (UTC)[reply]

Delete, per nom. Not great on the formatting either. {{MWSS/collapsed}} should go too. Cloudbound (talk) 19:07, 24 August 2015 (UTC)[reply]
Keep, we are currently having a discussion over at the Outlook.com Talk Page. Also, Window Live is no longer a brand used by Microsoft, Microsoft Office does not encompass Outlook Mail, Outlook Calendar, Outlook People, Outlook Tasks, OneDrive, MSN, Bing, etc. And the Microsoft navbox is too general for this purpose. It can be kept at the bottom of the page, but does not serve this purpose exactly. Anyways the template is a work in progress. Ians18 (talk) 23:01, 24 August 2015 (UTC)[reply]
Comment This is not Original Research these are the items that appear in the app lists of each of the products. Please see here Ians18 (talk) 17:19, 25 August 2015 (UTC)[reply]
How? Microsoft officially announced that Outlook.com, Windows Live Contacts, Windows Live Calendar, and Microsoft SkyDrive would be parts of Microsoft Office Online, and this by extend added OneDrive Groups, Windows Live Profile, and others, Docs.com is also officially a part of Microsoft Office Online, and the Outlook brand is a part of Microsoft Office, if you'd go to this page you can see Outlook.com and Microsoft OneDrive listed among Microsoft Office Online applications. --Hoang the Hoangest (talk) 03:39, 27 August 2015 (UTC)[reply]
  • Delete both. Nominator is right on both accounts. First, we have an excess of navboxes already. {{Microsoft Office}} works admirably well. (Our navigation is deliberately not aligned or compatible with Microsoft's scheme.) Second, yes, it is a special kind of original research better known as WP:SYNTH. I think the original author, Ians18, has acted too soon based on what I perceive as his own fancy. He keeps showing me the same sources over and over again, but no matter how many times I look at them, I don't see what he claims to be in them. Best regards, Codename Lisa (talk) 17:53, 25 August 2015 (UTC)[reply]
Comment Are you serious? Outlook.com and Microsoft Account are not even part of Microsoft Office at all! This is a simple, cleaner template for Microsoft Web Services only. I do, however, agree we have an excess of navboxes, which we should consider reducing. However, this is relevant. We should keep it at least until the preview is over then we can decide what to do with this template. Please look at this again I did not randomly make this grouping up. Also, I didn't make this up either Ians18 (talk) 19:17, 25 August 2015 (UTC)[reply]
Comment Though the Windows Live brand is no longer officially in use, the templates Microsoft Windows Components and Microsoft Office already fill in what's gone, as for all the current services that used to be listed under Windows Live are now either bundled with Windows and Windows Phone (and are in those templates) or are a part of Microsoft Office Online and are well-represented in a lot of Microsoft templates (and I'm serious when I say that Microsoft articles have a lot of them), for some reason every time I add the Outlook Web App it keeps getting removed, if it doesn't fit in the context of this template then what Microsoft services should be included and what Microsoft services should be excluded? Microsoft accounts also work with the likes of Microsoft Photosynth and other Microsoft Research projects, but these wouldn't qualify as Microsoft Web Services.
I added the comment "Don't {{Windows Live}} and {{Microsoft Office}} fill in its purpose for Outlook Mail, Microsoft OneDrive and other services, and Microsoft has a lot of seemingly unrelated online services and web services that could be (potentially) listed but wouldn't make any sense in or even out of context (think Photosynth), while others would like Docs.com. --Hoang the Hoangest (talk) 01:40, 20 August 2015 (UTC)[reply]
We could list those in an other section after I add O365 and fill in the web apps under that section Ians18 (talk) 09:13, 20 August 2015 (UTC)" and out of all honesty this template simply seems to unorganized and with all the present Microsoft templates I don't see why this would fit. --Hoang the Hoangest (talk) 03:31, 27 August 2015 (UTC)[reply]
Extra comment as Microsoft accounts are indeed a part of every Microsoft Office application since Microsoft Office 2013, shouldn't they be mentioned in the template? and as Windows Live in general has been discontinued the template can better be rearranged to fit the service-types as to whether they're active or not (desktop applications with desktop applications, web services with web services, Etc.) though this is probably not the page to discuss it, but these templates can really use some improvements and I can see why Ians18 created a separate template, anyhow this alone does not justify a new web services template, but it does call for the improvement of the present templates. --Hoang the Hoangest (talk) 10:54, 27 August 2015 (UTC)[reply]
@Hoang the Hoangest: Microsoft Office integrates with Microsoft Account, Facebook, Linkedin, Google account and Dropbox. In addition, other Microsoft products that are not part of the Office family also integrate with Microsoft Account, like Microsoft Visual Studio, Microsoft Azure, Visual Studio Online, Microsoft Dynamics, Windows Store, Xbox Live. So, no, Microsoft Account is not part of the Microsoft Office family; Office only integrates with it. Best regards, Codename Lisa (talk) 14:19, 27 August 2015 (UTC)[reply]
@Codename Lisa which is the exact reason we should keep this template, correct? Microsoft Account and Office 365 accounts are now HUGE parts of Microsoft. @Hoang the Hoangest, is Bing or MSN part of Office? No. However Outlook.com, MSN, and Office Online are listed there. Office.com is a start page for the MSA Web Services. Why again should this be deleted? The "arbitrary" grouping is becoming more and more evident. Ians18 (talk) 01:23, 28 August 2015 (UTC)[reply]
Keep Still The WP:CLN clearly describes navboxes with "The grouping of articles by one method neither requires nor forbids the use of the other methods for the same informational grouping." Ians18 (talk) 01:26, 28 August 2015 (UTC)[reply]
  • Technical delete for MWSS/collapsed. Its effect can be achieved by adding a parameter to MWSS. I am not going to add an explicit "Delete" !nv for the other template, cause I have to explain why, but yeah, I think it should be deleted. Fleet Command (talk) 02:53, 28 August 2015 (UTC)[reply]
How exactly do you do that? My knowledge of template creation is limited Ians18 (talk) 06:19, 28 August 2015 (UTC)[reply]
Simple. Do nothing. Comparison diff says {{MWSS|collapsed}} is already supported. Fleet Command (talk) 08:24, 28 August 2015 (UTC)[reply]
Delete but only the mwss/collapsed one. I have moved all of them to {{MWSS|collapsed}} Ians18 (talk) 03:29, 29 August 2015 (UTC)[reply]
 Transclusions replaced with {{MWSS|Collapsed}}. Best regards, Codename Lisa (talk) 21:44, 29 August 2015 (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 template's talk page or in a deletion review).
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Templates_for_discussion/Log/2015_August_24&oldid=1146625297"