Jump to content

Wikipedia talk:Categories, lists, and navigation templates

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Curb Chain (talk | contribs) at 05:05, 26 August 2015 (→‎{{tl|clarify}}: r). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

WikiProject iconLists Project‑class
WikiProject iconThis page is within the scope of WikiProject Lists, an attempt to structure and organize all list pages on Wikipedia. If you wish to help, please visit the project page, where you can join the project and/or contribute to the discussion.ListsWikipedia:WikiProject ListsTemplate:WikiProject ListsList articles
ProjectThis page does not require a rating on the project's quality scale.


Links to templates in navboxes

As far as I know its not recommend to add links to other navbox templates in navboxes?. But I cant find anything about it on this page (or other pages). Only that external links should not be included. Christian75 (talk) 10:15, 28 March 2015 (UTC)[reply]

WP:SELFREFERENCE is pretty close to what you're looking for but doesn't call this out either. Basically we don't want to direct people away from the mainspace if we can avoid it. --Izno (talk) 17:43, 28 March 2015 (UTC)[reply]
@Izno: - thanks, but it could be nice if it was written like the external links. Im not sure how to write it, and if it is consensus. Its diffucult to say "we don't want ..." in a discussion (at Template_talk:Medicine_navs) Christian75 (talk) 10:37, 30 March 2015 (UTC)[reply]
@Christian75: Sometimes editors will put together nav templates to navigate between templates. This is sometimes useful when you have a lot of related templates. So long as the template doesn't end up in the mainspace, I don't see an issue. It's really just a handy organizational element at that point. --Izno (talk) 02:20, 4 April 2015 (UTC)[reply]
@Izno: Okey. All the templates you see at that page are used in main space (its not just a collection). E.g. see template:Amino acids; all links below "Index of biochemical families" are to other templates... Christian75 (talk) 08:05, 4 April 2015 (UTC)[reply]
@Christian75: I'm not sure I understand. I checked Special:Whatlinkshere/Template:Medicine navs and found no mainspace pages. Is your query resolved? --Izno (talk) 19:49, 4 April 2015 (UTC)[reply]
@Izno: All the "subitemplates" at Template:Medicine navs (its just a list) contains links to other templates, and are used by theese templates: Category:Templates that use a Medicine navs subtemplate which are used be theese articles Category:Articles that use a Medicine navs subtemplate. E.g. template:Amino acids (which transclude template:Biochemical families navs which is purely links to other templates) and therefore the amimo acids template has a lot of links to other templates. About the query - I just gave up - two other editors likes the idea to navigate between templates. Christian75 (talk) 20:49, 4 April 2015 (UTC)[reply]
@Christian75: Just realized your issue (with your link to T:Amino acids). Yes, that's an inappropriate use of navboxes, basically for WP:SELFREFERENCE reasons. --Izno (talk) 14:14, 29 May 2015 (UTC)[reply]
I have nominated one for deletion as a test case. Please follow up at Wikipedia:Templates for discussion/Log/2015 May 29#Template:Infestation navs. --Izno (talk) 14:30, 29 May 2015 (UTC)[reply]

The inclusion of 'Commons', 'Wikiquote', and 'Wikisource' on appropriate templates

Proposal to include the words "with the exception of 'Below' links to Wikipedia sister projects such as Commons, Wikiquote, and Wikisource" within the sentence concerning no outside links. Robsinden is removing links to these appropriate additions (surely a good exception to the guideline if any exemptions exist) from our sister projects, projects which have been contributed to by probably thousands of Wikipedians. To add 'Category' 'Commons', 'Wikiquote' etc. to the Below sections of authors and other templates enhances the value of the templates, and these have existed on hundreds of templates for many years without a single complaint. I've asked Rob Sinden to stop removing the data until it's discussed, and have wrongly accused him of vandalism (he's following the letter of the law when the law is bendable regarding what I see as a common sense addition which should be encouraged, not discouraged). Thanks. Randy Kryn 12:57, 29 May 2015 (UTC)[reply]

  • Strong oppose. The purpose of a navbox is to provide navigation within Wikipedia. Linking to external sites does not serve this purpose. --Rob Sinden (talk) 13:02, 29 May 2015 (UTC)[reply]
  • Strong Support - one of the problems with Wikipedia is that it looms over the powerful other opportunities that the Wikimedia movement has to influence free, open, public knowledge. We need to create visibility for our sister projects, because they share the same focus, and many of them connect directly back to our ecosystem of materials. Robsinden's incredible isolating approach seems very innapropriate, when our goal is to introduce our readers to the "Sum of human knowledge"- when we know some of our other projects are better at accessing that human knowledge, Sadads (talk) 13:17, 29 May 2015 (UTC)[reply]
That's not what a navbox is for though. It's merely a tool to aid navigation between related, existing articles on this project. --Rob Sinden (talk) 13:19, 29 May 2015 (UTC)[reply]
@Robsinden: That's the thing sister projects are part of this project: they developed organically from Wikipedia because we needed allied, but differently organized spaces, to do all the same things we wanted to do with Wikipedia: share free public knowledge. Sadads (talk) 20:48, 1 June 2015 (UTC)[reply]
"Navigation templates are a grouping of links used in multiple related articles to facilitate navigation between those articles within English Wikipedia". --Rob Sinden (talk) 10:42, 3 June 2015 (UTC)[reply]
  • Oppose naveboxes are for navigating this wiki....we have special boxes for the other 12 projects....having them all in a navboxes would be overwhelming. -- Moxy (talk) 13:31, 29 May 2015 (UTC)[reply]
    Hi Moxy. Well, can we limit which ones? For example, 'Commons', 'Wikiquote', an 'Wikisource' are invaluable on author's templates, major elected official templates, and many others. How about if the words "such as" in the proposal are removed? I'll do that in anticipation of a consensus forming. Sound okay? Randy Kryn 13:53, 29 May 2015 (UTC)[reply]
The problem we have is that external links (links that take you away for this wiki) should be clearly indicated to our readers. This is the reason we have special boxes for sister projects because they indicate to our readers that they are leaving this wiki....thus like the arrow on normal external links, it indicates the link may not be to a mobile version or may contain so many images that there may be loading problems for many. -- Moxy (talk) 14:15, 29 May 2015 (UTC)[reply]
  • This proposal tears at my soul of what WP:PAG are. On the one hand, these have snuck/creeped/been added willfully by certain editors (but not necessarily with a priori consensus of the project) into navboxes, and in my editing experience have not been removed. OTOH, they are plainly not what a navbox is for [on the English Wikipedia]. My general feeling is that this should not be an exception or provided for in policy or guideline and should in fact be removed from the many navboxes which have them now. I think an (full) RFC on that point would make sense. --Izno (talk) 14:09, 29 May 2015 (UTC)[reply]
  • @Randy Kryn: You seem to be saying that it's been long accepted practice to include sister project links in templates, even if a guideline (apparently) hasn't expressly said that. The opposition so far has not commented on that, but is instead focusing on whether it's a desired practice. I'd like to see more discussion on that point, basically what is the status quo? What templates have used these links and for how long, what prior discussions there have been, etc. @Robsinden: Why is this coming up as an issue now? Are the links you're removing recent changes to those templates, and if not, why is that a change you've decided to make at this time? postdlf (talk) 14:41, 29 May 2015 (UTC)[reply]
I usually remove external links when encountering them in navboxes per this guideline, like I would clean up anything else I encounter that is against a guideline. The ones I removed today were ones which Randy had recently added and he objected to their removal. --Rob Sinden (talk) 14:46, 29 May 2015 (UTC)[reply]
Then you have not looked at any of the templates I've added the "Below" onto. I can't recall when I started, quite a long time ago, and nobody has objected to any of them. I've put at least a hundred if not more (I have no idea). Taking into account the visibility of the subjects I've put them on, the unlikelihood of you not looking at any of those templates, and the fact that nobody else has removed any of them, nobody has complained about any of it, brings it into the realm of "accepted practice". Robsinden took it off of Martin Luther King's template and others on which the data has been on there for a long long time. Using them seems a nice share between sister projects, projects which most readers probably don't even know exist so it has never hurt any of them - nobody has complained - so apparantly it doesn't hurt them to fall into one of those projects every now and then. Besides, the "takes a viewer off-site" reasoning is handled by the names themselves - Wikiquotes and Wikisource texts, both quite identifiable as an off-site link if read correctly. Keeping the templates as is would be harmless. Removing them, or the capability of adding that treasure trove of data provided by our sister projects (I see them as one and the same, so my personal view of Wikipedia includes those sites) would be, in my opinion, an error. Just go to one of the templates the links are on, all of them extant because I really don't remember anyone removing any until now (is there a Grandfather-in clause somewhere in the vast rulebook/guidebook for an accepted practice declared unaccepted?). The templates now contain the large, inclusive, and well-cared for information created on those subjects by editors at Wikiquote, Wikisource, and the rest, who I personally consider Wikipedians (and, since nobody has complained, so do a whole lot of other editors and readers. In fact every reader who has ever used one of those links, because not one of them has complained about their side trip to the sites forests.). Randy Kryn 18:12, 29 May 2015 (UTC)[reply]
Have there been other editors also adding sister site links to navboxes, or just you? postdlf (talk) 18:25, 29 May 2015 (UTC)[reply]
Hi. I've seen others in my 'travels'. Don't know how many have done it, as I don't frequent recent changes. Haven't thought much about it, as I've been adding them to templates of elected officials, writers, and other major subjects for a long time now, has been one of my joys on Wikipedia and a gateway to checking each item on the templates I've put them on for errors and added edits, and until now the practice hasn't been questioned while existing on prominent templates and being passed through recent changes with the words 'add Below, add 'Commons', 'Wikiquotes', 'Wikisource texts'. Thinking about it further I must have put them on a couple hundred or more well-seen templates, both existing and newly created. Randy Kryn 2:18, 29 May 2015 (UTC)
  • Oppose per Rob Sinden and Moxy's comments above. Dirtlawyer1 (talk) 17:11, 29 May 2015 (UTC)[reply]
  • Comment and analysis. Maybe another and accurate way of looking at this is that it was an inadvertent long time study in the next slight expansion of allowing sharing between these sister projects ("We Are Family" playing in the background). Allowing the three links on appropriate templates has been the inadvertent result of nobody complaining, so they stayed (on very prominently seen templates) and....nobody complained! Not an editor, a reader, anyone who minded taking the link to a trove of further information as a result of the work of our brothers and sisters, gave a hoot. The inadvertent (I wasn't ignoring rules, I wasn't reading every guidebook in the library and never gave it a second thought until Moxy's comment above. I never thought of the projects as being separate, not for a moment. When I read Moxy's comment I added a reasoning above why this addition might not confuse people about off-site projects as we might think. So this proposal, in essence, becomes based on approving or disapproving a slight expansion of the links allowed to Commons, Wikiquote, and Wikisource. Because I don't think anyone objects to the amount of information being provided at the other end of those series of tubes (by the way, I usually make the last one visible as "Wikisource texts" in order to give more of an "ah ha!" moment when a very interested reader stumbles upon them and first understands what they lead to). There's nothing wrong with this proposal except it allows a slight expansion-creep, an expansion which has proven both harmless and beneficial, from allowing sister links to be contained only in stand-alone boxes. Those valuable boxes may or may not end up under the external links section, although the guidelines direct sister project links to be under the 'External links' section, which is where templates are placed. So the proposal does not allow an expansion very far from those off-site-boxes which are often placed only on main pages, thus allowing a slight inter-wiki link on the majority of pages linked on the templates, pages which aren't linked to the sister projects anywhere else on the page except for the template. Randy Kryn 14:52, 30 May 2015 (UTC)[reply]
  • Additional thought, while we're at it. Linking to "Category:" namespace is pretty pointless too (which is something else I've seen but have often left alone), as you'd hope that the articles would be in the relevant categories anyway, rendering the additional link redundant. Personally, I'm of the mindset that we should only be linking to article space from the navboxes, but I see that there are sometimes links to "Book:" and "Portal:". Oh, and Wikiprojects, which I really don't think should be encouraged. --Rob Sinden (talk) 15:16, 1 June 2015 (UTC)[reply]
Books and portals are overviews of the topics like outlines and indexes (thus are great links).... as for projects...its the only area the projects can advertise for editors in main space....and also will let our readers see how topics are organized. -- Moxy (talk) 15:25, 1 June 2015 (UTC)[reply]
Sorry, my post was more about categories, I just wandered off topic a bit after that! Just my personal taste - I dislike seeing the row of icons on navboxes such as this. --Rob Sinden (talk) 15:35, 1 June 2015 (UTC)[reply]
That does look bad...should remove the external links and the kid like icons. Icons is a problem...they mean nothing to readers...its not like there are some internationally recognized symbol. As for cats they are an antiquated system that most reades find very confusing.....but so many people work hard on them, thus many must find them useful. -- Moxy (talk) 15:50, 1 June 2015 (UTC)[reply]
Yeah, I think it says on the guideline that navboxes should not be arbitrarily decorative, or words to that effect. So the icons and the external links should go. What is your feeling about the category links in the navbox? --Rob Sinden (talk) 08:57, 2 June 2015 (UTC)[reply]
The key word is guideline, not policy. This exception to the guideline has already proven successful, and non-controversial up until this point, and has proven itself to be useful, well regarded, and functional. Randy Kryn 3:00, 3 June 2015 (UTC)
"Proven"??? How? --Rob Sinden (talk) 12:32, 3 June 2015 (UTC)[reply]
Proven specifically because of the fact that they've been on the templates and nobody has complained. Your (Robsinden) argument seems to imply that nobody ever looks at the bottom of the templates, where those links are, or clicks on them. Because if they have, and nobody has complained, at least some of them must have liked it and it helped them, possibly, in the case of a subject student, researcher, or writer, helped them quite a bit. We don't know, but since nobody has complained it seems to be doing fine. And, take a look at all the oppose here and at the other question. Very few have even answered the question, which is should we add a little to an existing policy, and allow these valuable family connections, or not, and if not, why not. Most of what people are saying is "It's existing policy, so I oppose". Well, that wasn't the question. Moxy answered the question well, by saying, paraphrasing, that it would provide an outside link where such a link wasn't expected, and that the size of the file might overwhelm a mobile phone or tablet. From his comment I removed "Commons" from the overall question (and would change it above if that's allowed), because "Commons" doesn't provide near-essential information about a subject for a reader or researcher to add to their knowledge base. "Wikiquotes" and "Wikisource" do, which are the ones I'm aware of, and haven't personally looked very much at the others. Those two seemed appropriate for the templates, I added them to Below without a second thought, kept adding them, put more on, then lots more, kept adding them, without a second thought that there was anything wrong with it. Nobody complained, not a reader, not a researcher, not a Wikipedia admin, it seemed fine to everyone. Then you objected because it actually falls outside of policy. See? This question is not about if it falls outside policy, it does, granted, it is a question about changing that policy and providing perfectly fine reasons why this slight expansion shouldn't be allowed and encouraged. Read the answers, almost nobody has been able to think outside the box and notice that the box has already grown larger. What has been and is presently sitting on many of the most prominent templates here are links to a few sister-project links which have expanded awareness both of the subject and of the sister-project data treasure troves, pieces of eight sitting there to be useful and appreciated. Please answer the question about how this hurts Wikipedia enough to remove all of those long-term links which have not proven harmful to anything or anybody and, unless nobody has ever looked at any of them, as you hint, they have very likely proven useful to at least some students who have either wholeheartenly chosen or were grudgingly assigned a research a subject covered by the template. If it ain't broke, etc. Robsinden, I know you are dug in on your position on this, but maybe part of you feels that the Keep points have merit to change to at least a neutral on the question. That would be cool (its not you changing "sides" - consensus has no sides). Then how about we have a consensus to work on the guideline language to perfect it. That would be very cool. If not, why not, with good reasons and not just arm waving and pointing at a guideline which has essentially been violated for almost a year now with no negative results reported, nobody reverting, and nobody questioning what now could arguably be called an already accepted appropriate exception to the guideline. Randy Kryn 14:56, 5 June 2015 (UTC)[reply]
FFS, do you really expect me to bother to read this? I've had a quick scan, and I don't think you're making any new points that I haven't dealt with elsewhere. Surely this thread is dead now anyway, as we have the RFC below. And to repeat what another editor has pointed out to you, please have a read of WP:BLUDGEON and let the RFC run its course. --Rob Sinden (talk) 15:07, 5 June 2015 (UTC)[reply]
  • Oppose: Nav templates are for WP-internal navigation. Sister-project links go in "See also", so adding them to nav templates would be redundant as well as inappropriate.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  02:36, 3 June 2015 (UTC)[reply]
    Incorrect, sister project links don't go into 'See also' but into external links, which would include templates. They would also not be redundant, as most pages, a vast majority of pages, on these templates will not have a sister-project link. As for inappropriate, they have proven to be very appropriate by the lack of reverts, comments, or complaints in the 10 or 11 months they have appeared on many of the most prominent subject templates on the site. Randy Kryn 2:54, 3 June 2015 (UTC)
    When you say that "external links" includes templates, are you referring to navboxes? If so, that's a bizarre assumption. Sister links actually have their own template: {{Sister links}} - that's where they belong. You also seem to be forgetting that unlike some of us, the vast number of editors don't care much about navboxes, so they are painfully neglected and misused, which is probably why the addition of the external links has gone unnoticed/unchallenged. --Rob Sinden (talk) 08:09, 3 June 2015 (UTC)[reply]
    To clarify, the templates - navboxes - go underneath but are not a part of 'external links'. The sister links template is not seen on each appropriate page, and has nothing to do with this discussion. Acceptance of this positive change (don't you agree that the data in Wikiquote and Wikisource texts fits perfectly with the appropriate templates?) would enhance the navboxes usefulness. This proposal is for that guideline expansion, not if it violates the wordage of an existing guideline. If you do agree they would be useful, why not support it? You seem to love these critters as well, so please consider 'switching sides' on this one. Randy Kryn 10:18, 3 June 2015 (UTC)[reply]
    Absolutely not! I cannot see it as a "positive change" or "useful". I love navboxes for what they are - a means of navigation between existing articles on the English Wikipedia. Anything that does not facilitate this function does not belong in a navbox. It's that simple. Linking to sister projects (or any other external links) is not the function of a navbox, for that we have the {{Sister project links}} (or {{Sister project}}) template, and that is the function of that template. Using a navbox to link anywhere outside of Wikipedia (or away from article space for that matter) defeats its purpose, in the same way that using the {{Sister project links}} template to provide internal navigation defeats its purpose. --Rob Sinden (talk) 10:34, 3 June 2015 (UTC)[reply]
  • Support I think the external links aid the reader.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 02:56, 3 June 2015 (UTC)[reply]
  • Support. While true external links need not be included, sister projects 'Commons', 'Wikiquote', and 'Wikisource' should be welcome rather than portrayed as contributing to clutter. All projects work as part of the whole. There is no benefit to withholding from users easy access to these sources. —Roman Spinner (talk)(contribs) 18:56, 7 June 2015 (UTC)[reply]

Turn into RFC?

@Moxy, Robsinden, Postdlf, Izno, and Randy Kryn: This seems like a really closed two way conversation, with only a few voices voicing ideas, and each position has radically different assumptions about what navboxes are for, and the value of sister projects on Wikipedia. Are there any strong objections to turning this into an RFC today? I am going to do a summary of the concern this evening, if I can, and turn it into an RFC, Sadads (talk) 20:53, 1 June 2015 (UTC)[reply]

Approve. If you can include somewhere the fact that this was a fairly large inadvertent experiment, a very small inclusionary step allowing links to at least three sister projects within templates. It has resulted in much information being included on templates for a long time without anyone complaining, anyone reverting, or without anybody from the admin end objecting. So arguably these links are already an accepted practice. They've hurt no one, have done only good, and I question that anyone can argue that the practice does not link valuable information. After lasting so long without a murmur of dissent, maybe you can say in a summary that it's become a logical extension of the placement of sister project links placed within or below the 'External links' line (I believe that's the current guideline, which this one doesn't break). Thanks. Randy Kryn 22:37, 1 June 2015 (UTC)[reply]
This whole statement is wrong....the reason we have the guideline is because this has been talked about in the past many times. Again its why we have templates for sister projects that are big and more predominate then normal nav templates. If you think its best all the related pages should link to the same sister projects then add the sister box to the navbox template so it can be trascluded...this way your sister project links are in a big box that can been seen. I have noticed that when people see sister projects in navboxes they will remove the sister boxes claiming over links (as in dont need the same links 2 times at the bottom of a page). Want people to see the link use the right box...better then guessing at what 3 of 12 random sister projects to included.-- Moxy (talk) 00:04, 2 June 2015 (UTC)[reply]
Looked up a date, I added one to Thomas Jefferson's template right near the start. That was July 28, 2014, and I've been doing this on a consistent basis from that time forward. As mentioned, must have done between a hundred and two hundred of them on very prominent templates. Not quite a year, but close. Thanks again. Randy Kryn 22:42, 1 June 2015 (UTC)[reply]
Wow those presidential templates are really bloated and have mini text (both MOS points). Would be better to have an index or outlines to link to. Its not about adding all to templates... its about helping navigation to main articles.,,,not linking to all including off wiki sites.--Moxy (talk) 01:02, 2 June 2015 (UTC)[reply]
The presidential templates present a complete map to the subject on Wikipedia. In your opinion they seem bloated, in others opinion they're good templates with full information. Again, nobody has complained, which shows that they are doing the job of presenting a navigation of the subject. I've actually had an off site compliment about the completeness of one of the templates from a person who works with test scoring. Randy Kryn 11:07, 2 June 2015 (UTC)[reply]
They still have issues though. Encyclopedic information such as dates of birth doesn't belong in a navbox. --Rob Sinden (talk) 11:34, 2 June 2015 (UTC)[reply]
(Edit: Done)The dates of birth and death are borderline, and you're probably right on this. I added them to the presidential templates I created because they were on the already existing presidential templates, but remember having second thoughts about them. I'll remove them and see if anyone reverts. Randy Kryn 12:30, 2 June 2015 (UTC)[reply]
There doesn't seem any point in RFCing this, just because a couple of editors don't understand what navboxes are for. --Rob Sinden (talk) 08:54, 2 June 2015 (UTC)[reply]
Pretty much two viewpoints, both of which should be presented to a wider audience of editors. Randy Kryn 11:12, 2 June 2015 (UTC)[reply]
Rob: your unwillingness to treat the reasonableness of our argument, is pricesely why we need more opinions: I am pretty sure that the assumptions behind our arguments are accepted by a larger number of editors, in the same way a larger number of edits accept yours. I will do an equitable summary this evening, and get that together. ended up working a lot later yesterday than expected, Sadads (talk) 16:31, 2 June 2015 (UTC)[reply]
Would everyone agree that maybe we can leave 'Commons' off the templates? Commons contains mostly pictures, not really that important for a data link and, as Moxy said above, some mobile devices may not be equipped to handle large amounts of images. But Wikiquote - a collection of quotes by the subject of the template - and Wikisource texts, which, for the older subjects, provides the option to read their works very easily, seem, to me, essential if we have sister projects which have provided them. Would that be a consensus, that we recommend that Wikiquote and Wikisource texts be allowed, thus extending the reach of sister project links that much? Another point made above, that of editors removing the boxes if they see a link on the template. On many main pages, such as US presidential, etc., the template will not be open, so the links will not be apparent and cause no problem with duplication of already existing boxes. The value picks up on the other pages that the templates are placed upon. Thoughts on the consensus option? Thanks. Randy Kryn 19:29, 2 June 2015 (UTC)[reply]
No, navboxes are supposed to be for navigating among existing English language Wikipedia articles, not outside content. That's what "external links" are for, not navboxes. Please feel free to initiate your proposed RfC. Please make sure that you apply for project-wide bot notices. I can assure you that I will personally notify the several WikiProjects of which I am a member. Y'all have gone outside the existing guidelines and are now trying to present it as a fait accompli. Well, that may or may not be accepted by a new wide-ranging consensus, but until then, you're out on the metaphorical limb. Dirtlawyer1 (talk) 21:53, 2 June 2015 (UTC)[reply]
  • This is clearly stated enough that we don't need to RFC it. If you want more eyes on it, just post to WP:VPPRO. I did already.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  02:36, 3 June 2015 (UTC)[reply]
    That's a page I've never heard of, so in the case of more eyes, my eyes would have missed it. Editor Sadads has already mentioned his intention to post it on RFC. This will create an expansion of the policy, an expansion which has had an inadvertent 10 month experiment and come up with some very good results for including the data. More eyes on a page where it can be seen is the best way to go on this (and I notice you are opposed to the idea, so your suggestion and post should carry that data into the discussion). Randy Kryn 2:49, 3 June 2015 (UTC)
    I'm skeptical that anyone who doesn't even know about the existence of the WP Village Pump is in a good frame of reference yet to be launching proposals to change Wikipedia policies and guidelines; one must actually understand WP process before one's ideas for changing it are likely to be sensible.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  19:59, 5 June 2015 (UTC)[reply]
    Just saw this in the wall of text. This idea which has already been successfully tested (you never seem to acknowledge that this is already an accepted exception to the guideline, it's been implemented for almost a year now on some of the most prominent templates on the site) and expands our valuable sister-project relationship just a little, to the 'Below' section of appropriate templates, seems very sensible. Randy Kryn 23:08, 7 June 2015 (UTC)[reply]
    I have started the RFC per the conversation here. I have tried to do an equitable summary of the main positions about the topic. Feel free to tweak my summary of the positions below if you think I am missing something, or something hasn't been covered correctly. I don't have time for notifying other talk space right now, but will do so this evening or tomorrow morning, when I get time: feel free to do so ahead of that time, Sadads (talk) 15:04, 3 June 2015 (UTC)[reply]

RFC: Should Sister Project links be included in Navboxes?

NO ACTION
(non-admin closure) There seems to be insufficient support for a change to the WP:NAVBOX guideline. I'll mark the WP:ANRFC request to close this discussion as "done". --Francis Schonken (talk) 05:16, 6 July 2015 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

"Should Sister Project links be included in Navboxes when they are appropriately within scope of the navboxes topic?"Sadads (talk) 15:01, 3 June 2015 (UTC)[reply]

Positions in previous discussions

Currently, in the section above, there has been a serious disagreement on the purpose of Navboxes as relates to navigation between sister projects (see definition of Wikipedia:Wikimedia sister projects ), that boils down to two positions with two different sets of assumptions:

Remove sister project links from navigational boxes

The first position, says that in the Navigational Templates policy clearly creates a restriction on including external links in Navigational boxes, and thus sister projects, which are outside of English Wikipedia proper shouldn't be linked. The main arguments defining this position include:

  • Navigational boxes are only intended for navigation within En.Wikipedia - and shouldn't direct users beyond the project
  • Sister projects don't share the same fundamental mission and environment of Wikipedia, thus are "external links" - sending users their muddles navigation within Wikipedia
  • Navigational boxes shouldn't include more information than absolutely necessary for successful navigation within English. Thus the navigational boxes shouldn't include sister projects.
  • Templates like {{Sister project links}} (or {{Sister project}}) serve the purpose of these links, and including links in Navboxes creates unnecessary redundancy of both links and function of boxes.
Include sister project links in navigational boxes

The other position, to allow for Sister Project links in Navigational boxes when they point to resources within the topical scope of the Navbox, came to light because of an unintentional experiment in including links to Commons, Wikisource, and WikiQuotes by User:Randy Kryn. Examples include Template:Harry S. Truman, Template:Franklin D. Roosevelt, and Template:Ronald Reagan. He has been adding these for at least the last 10 months, with no significant reversions until recently. The main arguments defining this position include:

  • Navigational boxes are intended to further reader awareness of useful information within the ecosystem of free knowledge projects that are related to Wikipedia
  • Sister projects share the same fundamental mission of Wikipedia, and thus should be readily promoted within project templates
  • Navigational boxes provide a structured set of links where users can go to find "like information" - not including the sister projects weakens their ability to support that promotion of like information
  • Including sister projects in Navigational Boxes does not interfere with use of: {{Sister project links}} (or {{Sister project}}. Those are more targeted on particular topics of the pages, whereas additions to navboxes have been around the broad topic of the Navigational box.
  • The spirit of the current guidelines was to prevent external links to other websites, not Wikimedia projects.

The RFC boils down to the simple question: "Should Sister Project links be included in Navboxes when they are appropriately within scope of the navboxes topic?" Sadads (talk) 15:01, 3 June 2015 (UTC)[reply]

I oppose inclusion of sister project links in navigational boxes

When signing your support, please provide a justification beyond the current policy: RFCs are a mechanism to question and refine our current policy.

  • Oppose inclusion of direct links to websites outside the English language Wikipedia within navboxes, including so-called Wikimedia "sister" projects. This is clearly contrary to the spirit, intent and express language of the current guideline. Dirtlawyer1 (talk) 15:07, 3 June 2015 (UTC)[reply]
    • @Dirtlawyer1: Can you please provide additional reasoning beyond "its contrary to current guideline" . This discussion should make substantive arguments about the assumptions behind the policy, not simply affirmation of the current language, Sadads (talk) 15:11, 5 June 2015 (UTC)[reply]
      • Because I firmly believe that navboxes are supposed to link to other existing English Wikipedia content. When we direct readers away from English Wikipedia without warning, it is confusing and disconcerting to many of our readers, and I might add, somewhat deceptive. Wikiquote, Wiktionary, and foreign language Wikipedias, etc., are not Wikipedia. Moreover, we already have systems in place for linking to "sister" projects, including "external links" sections and the link boxes that are specifically designed for "sister" project links. Bottom line: English Wikipedia navboxes are for links to existing English Wikipedia articles. Our current guideline is a good one, and the folks who have taken it on themselves to add outside links to Wikipedia navboxes have gone a bridge too far. Dirtlawyer1 (talk) 15:19, 5 June 2015 (UTC)[reply]
    Dirtlawyer1, the linking was totally innocent, and has turned out to be totally non-controversial until now. The sister projects are only linked on the main pages, not the sub-pages which are the bread and butter of templates. A good template maps out our total holdings on a subject in a coherent manner. Do you also oppose the use of photographs on appropriate templates (When I see a template get too large I remove the image, but have seen many templates with photos which seem fine)? I would think you, Robsinden, and others would be arguing that photographs are not appropriate on templates, and why haven't you acted to remove them? Randy Kryn 17:07, 5 June 2015 (UTC)[reply]
    @Randy Kryn: If you want to discuss the use of photos and icons in navboxes, please start that discussion either on my talk page or yours. I am happy to engage with you on that topic, but I do not want to start a thread here that is tangential to this RfC. Dirtlawyer1 (talk) 20:18, 5 June 2015 (UTC)[reply]
  • Oppose. While I think it makes sense to treat sister project links differently than external links generally, including them in navboxes just spreads them to articles to which they do not directly correspond but are merely topically related, thus cluttering navboxes with links of little utility. It's obvious that a typical Wikipedia reader would want an easy way to navigate between related Wikipedia articles, but I don't see why anyone would want to directly navigate from Article A to the Commons category corresponding to Article B without even looking at Article B. We already have numerous templates for making sister project links prominent within their corresponding articles and these are quite sufficient for connecting resources. postdlf (talk) 15:25, 3 June 2015 (UTC)[reply]
    This now has nothing to do with the "Commons" category. The question is about an extension of the placement of appropriate sister project links on only the appropriate templates. I've come to see, by the above discussion, that Commons should probably not be linked to many of them, if any, as it is mainly a collection of pictures. But on the template 'William Shakespeare' there now is a link to our sister project Wikiquote, and its very good collection of quotes by William Shakespeare. What harm can that do? None. What good can it do? Plenty. That is an appropriate use of a link to a sister project. Commons really isn't and I'll remove that from Shakespeare's template right after posting this note. If we can accept that "Wikiquote" is appropriate on William Shakespeare's template then we are expanding, by just a little, the interconnection between sister projects on Wikipedia. Those sister projects are being shared in one other way, by the boxes on a limited number of pages. Is there anything really wrong with sharing that wealth of knowledge in two different ways? It's been going on for awhile, and this is the first time anyone has complained, and all they are complaining about is that a current guideline prohibits it and a template cannot link to an external link. These are sister projects providing information to readers, researchers, and students, and this is one more small way of sharing that information. Randy Kryn 23:57, 4 June 2015 (UTC)[reply]
  • Oppose. Navboxes are a means of navigation between existing articles on the English Wikipedia. Navigation templates are a grouping of links used in multiple related articles to facilitate navigation between those articles within English Wikipedia. Anything that does not facilitate this function does not belong in a navbox. It's that simple. Linking to sister projects (or any other external links) is not the function of a navbox, for that we have the {{Sister project links}} (or {{Sister project}}) template, and that is the function of that template. Using a navbox to link anywhere outside of Wikipedia (or away from article space for that matter) defeats its purpose, in the same way that using the {{Sister project links}} template to provide internal navigation defeats its purpose. --Rob Sinden (talk) 15:53, 3 June 2015 (UTC)[reply]
  • Oppose. As with the others. Navboxes exist for internal navigation within the English Wikipedia, and they are already abused and overused enough as it is. We should not be making a habit of adding external links - and that is what sister projects are - in them. We already appropriately place those links in the external links sections of articles. Resolute 13:11, 4 June 2015 (UTC)[reply]
    This proposal is for an extension of the definition of what templates can or cannot do. There may be an external link box on the main page of a subject, but not on all the pages concerning the main subject which are linked on the templates, thus the value of including those in the 'Below' section. Randy Kryn 18:00, 4 June 2015 (UTC)[reply]
    I understand what this proposal is for, thanks. And I oppose broadening that definition. Also, please don't WP:BLUDGEON the debate by responding to every single comment that opposes your proposal. It will stand or fail on its own merit. Resolute 13:53, 5 June 2015 (UTC)[reply]
  • Oppose. We have sister project boxes to indicate to our readers that they are leaving English wiki. --Moxy (talk) 13:36, 4 June 2015 (UTC)[reply]
    "Wikiquote", "Wikisource" texts, and "Commons" have been on prominent templates since July of 2014, with no complaints. "Commons" probably isn't appropriate on those templates, but "Wikiquote" and "Wikisource texts" probably are. So if some readers are surprised when they find themselves in a new realm called "Wikiquote", they've more than likely enjoyed the experience and expanded their knowledge of what Wikipedia is part of, and if they haven't enjoyed it, and it made them think that Wikipedia is untrustworthy and meant them deliberate harm, at least none of them has ever complained about it. Since no complaints up until now, a net positive value there, being sister projects and all, no? Randy Kryn 00:19, 5 June 2015 (UTC)[reply]
  • Oppose. Each article (and template) is "standalone." We do not rely on other articles. We have no control over sister projects or their policies. That is why they are sister projects and not part of Wikipedia. If it were me, I wouldn't reference sister projects at all except for an occasional Wiktionary pipe in the text where Wikipedia has no article. Why rely on something we're not involved in? Why reference something we have no control over? Once we lose control over sister projects, then we seem to open the door to other external links as well. What about the NY Times? US government sites? I don't don't want to be opposing these one at a time. Just draw the line now and leave it. Student7 (talk) 13:48, 5 June 2015 (UTC)[reply]
    @Student7:I can empathize with many of the other arguments (despite very much disagreeing with them), but you are comparing apples and oranges: Wikimedia projects are as much a part of our work, as Wikipedia is. Without the support of those projects, we wouldn't have the kind of community we have nor the impact (Commons, in particular, is idespensible because it provides both visibility and modern impact of our project (without images, especially freely licensed one, Wikipedia wouldn't have the number of readers it has)). This kind of insularity not only ignores the importance of sister projects in capturing our overflow pieces of free knowledge, but also our share mission and principles as well as many of the same editors (for example, I have several thousand edits on Commons and Wikisource). External links to the New York Times, and similar, would be directing someone to a completely other body of work: Wikimedia projects share the exact same purpose and movement supporting it. I would be very disappointed in our community, and its ignorance of a larger movement, if this we the reason we (as a community) felt that links are innapropriate, Sadads (talk) 14:49, 5 June 2015 (UTC)[reply]
    Sadads, in the last 24 hours, I have had the opportunity to compare several existing English Wikipedia articles to those of foreign language Wikipedia articles on the same subject. As much as we may bitch about the quality of some Wikipedia articles, I can tell you that we are generally light years ahead of the others in terms of sourcing and general quality. Frankly, I would be far more comfortable linking to news articles in The New York Times than I am linking to an article on the same subject in, for example, Spanish Wikipedia. Dirtlawyer1 (talk) 15:25, 5 June 2015 (UTC)[reply]
    @Dirtlawyer1: the other language Wikipedias are not sister projects (they are the same project, with a different community of focus - based on language and community standards within that language). See WP:Sister projects. And yes, I agree with you: the sourcing standard on English is much higher than other projects: however, in some ways, those projects are also seeing better opportunities for retaining new editors, because they are easier to contribute too: in some ways, it might be more beneficial to the English community if we did direct multilingual readers that. That being said, there are very few reasons to include non-English Wikipedias as links within navboxes, and in general, I don't support other language links. However, sister projects in English (or in the case of commons operated in English), are what this proposal is focused on, Sadads (talk) 14:23, 8 June 2015 (UTC)[reply]
  • Oppose largely in agreement with Dirtlawyer's sound reasoning in his follow up to his original post. oknazevad (talk) 16:59, 5 June 2015 (UTC)[reply]
  • Oppose: Nav templates are for WP-internal navigation. Sister-project links go in "External links", so adding them to nav templates would be redundant as well as inappropriate. PS: They go in "External links" because they are not WP resources, subject to the same policies and editorial control as WP articles. The fact that other WMF projects are tied to WP in various ways is essentially irrelevant.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  19:48, 5 June 2015 (UTC) Updated: 07:50, 8 June 2015 (UTC)[reply]
  • Oppose—Although I'm a Wikisourceror and want to see greater exposure to enWS over here, this is not the way to do it. Wikisource's purpose is to provide RS for the articles that are written here. Links to Wikisource belong either in the Infobox (in the case of articles about a work) or in the special template for our Author pages and subject Portals. Links to the works are not navigational, which is the purpose of all three presentation forms grouped at this page. Beeswaxcandle (talk) 19:18, 6 June 2015 (UTC)[reply]
    LOL@Beeswaxcandle: "Wikisourceror" - one of the funnier bad wiki-puns I've seen in a long while. Dirtlawyer1 (talk) 20:24, 6 June 2015 (UTC)[reply]
  • Fundamentally mistakes the purpose of a navbox. I think others above lay out the details in more depth than I care to. --Izno (talk) 17:28, 8 June 2015 (UTC)[reply]

I support the inclusion of sister project links where appropriate to navigational boxes

When signing your support, please provide a justification beyond the current policy: RFCs are a mechanism to question and refine our current policy.

  • As starter of the RFC: I strongly support the inclusion argument summarized in the first section above, Sadads (talk) 15:23, 3 June 2015 (UTC)[reply]
  • Strong Support Allowing this slight extension of policy allows the vast amount of data contained in our sister projects "Wikiquote" and "Wikisource" (especially on templates of authors, elected officials, or other prominent individuals or topics) to be quickly shared with readers, students, and researchers. This type of valuable data may or may not already be linked on the main page of the article, but not on the other pages on the template, which is another point in favor of the value of this. The two sister projects have already been placed on many if not most of the most seen templates on the site, have been there, in many cases, for as long as ten months, without one complaint or one reversal. They have proven to have been a favorable addition, to have caused no disruption, and to have given both more insight to the subject and more exposure of the availability of these valuable sister project contributions. "If it ain't broke don't fix it" comes to mind, and this one, an inadvertent but successful experiment, has proven to be without flaw or problem. Randy Kryn 11:23, 4 June 2015 (UTC)[reply]
Where is your evidence that they have "proven to have been a favorable addition" and that this is "a successful experiment, [...] proven to be without flaw or problem"? --Rob Sinden (talk) 11:30, 4 June 2015 (UTC)[reply]
The lack of complaints and the lack of reverts. None whatsoever. It "ain't broke". I have a "Watch" on the vast majority of the templates I added the three links to (this proposal asks for only two to remain, "Wikiquote" and "Wikisource", although you inaccurately keep trying to insist that it's about all sister project links) and none have been reverted or, as far as I know, complained about. Your complaint is the first, a long time after they have probably already become an accepted practice. Randy Kryn 11:42, 4 2015 (UTC)
So absolutely no proof whatsoever that they have been favourable, successful, or without flaw or problem. You cannot make these claims without being able to back them up. What seems more likely is that they were met with indifference or went unnoticed. --Rob Sinden (talk) 11:45, 4 June 2015 (UTC)[reply]
No proof? No reverts, total acceptance. I really can't understand why you are so gung-ho against this, it benefits Wikipedia, our sister projects, and readers, researchers, and students. It's a slight expansion of tools provided by our Sister projects, increases template data-strength greatly, and it hurts nothing or no one. This change may have been so obvious that it has gone "unnoticed". Randy Kryn 11:56, 4 June 2015 (UTC)[reply]
No reverts does not imply that your changes were "favourable", "successful", or "without flaw or problem". --Rob Sinden (talk) 12:01, 4 June 2015 (UTC)[reply]
A disagreement about the positive implications of no reverts or no complaints? A couple of pings, TonyTheTiger, INeverCry. Randy Kryn 12:50, 4 June 2015 (UTC)[reply]
Nice of you to ping supporters to try and help your cause out. Regardless, your claim of "total acceptance" is already patently false, as every comment in opposition on this page easily demonstrates. Resolute 13:13, 4 June 2015 (UTC)[reply]
  • Support Both sides have submitted cogent and well-argued positions with many elements of previous chasms between inclusionists and deletionists. Ultimately, the practical as well as philosophical divide cannot be reconciled. On the philosophical side, having examined the navigation templates in question, as far as this vote is concerned, the strong presentations of Sadads and Randy Kryn in particular, have proven to reflect my view. —Roman Spinner (talk)(contribs) 03:24, 8 June 2015 (UTC)[reply]
  • Support Continue to evaluate sister project links on a case-by-case basis, which seems to have worked fine up to now. Many of the 'oppose' comments have simply cited the 'purpose' from the guideline, which is a circular argument. --Hroðulf (or Hrothulf) (Talk) 17:40, 9 June 2015 (UTC)[reply]

Comments and other opinions/approaches

This should be closed quickly, per WP:SNOWBALL.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  19:48, 5 June 2015 (UTC)[reply]

  • Snowball? You have to take into account the comments and Supports in the original section of this proposal, which is ongoing above this one. Some people may not know to comment here as well. Long way from 'Snowball', and the reasoning for the change is still growing, and I'll post more on that soon (busy days). Randy Kryn 22:47, 7 June 2015 (UTC)[reply]
Whatever. Another day has passed with no additional support, but additional opposition. I.e., the snowball has grown. The "reasoning for the change" isn't really growing, the avoidance of addressing the reasons against it is what's growing, especially if you go back to the pre-RfC discussion. You and Sadads have been responding to oppose after oppose with comments that just restate your assertions without addressing any of the issues raised. PS: Remember I suggested not turning this into an RfC, and instead just advertising the existing discussion? This illustrates why. There was no point to Sadads opening a new RfC when there's already a running poll full of !votes. It just doubles the amount of work for the closer, and wastes a lot of people's time re-commenting.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  07:46, 8 June 2015 (UTC)[reply]
Editor Roman Spinner supported the proposal today. It may seem I keep repeating the same reasons because you and others really haven't answered some of the main points that we are making, especially "How does it hurt the project?" How does it harm the reader, researcher, or student looking at {{Mark Twain}}'s template to click on Wikiquote or Wikisource texts and come upon a treasure trove of information from sister projects which Wikipedia trusts enough to allow box-templates on some pages (boxes not present on the vast majority of articles listed on most templates)? What harm does it do? None, that I can tell, whereas the benefits, detailed throughout this proposal, seem to permit allowing this beneficial practice to continue. Is your only real concern that this slightly changes the definition of these templates, a definition which some people opposing this seem to point to as the only reason to not formalize the wording to allow this almost year-long practice? Again, how does this hurt, and to be fair, can you look at it from the researchers point-of-view and at least admit that it might just be a fine practice? These are sister-projects, not some blog, and they do good work (see the Twain quote page and wikisource page, this is an example of what they've accomplished), we can continue to share that work with interested readers, and not harm anyone or the encyclopedia in the process. Randy Kryn 1:20, 9 June 2015 (UTC)
@Randy Kryn: Ah, OK. I see where this is coming from. There is no principle anywhere that something must "hurt" the project to not be an optimal idea. See WP:HURT; this has been an argument-to-avoid on Wikipedia for years and years. We simply already have a prescribed way to include the links you want to include; they go in ==External links==. The nav templates are for WP-internal links. By way of analogy, we have a process for deleting/merging articles, WP:AFD; proposals to delete articles do not go in WP:VPPRO. We have a place for listing reference citations in articles, the ==References== or ==Notes== section; they do not go in the infobox. Etc. There would be benefits, perhaps, to listing articles for deletion in VPPRO (e.g. people take VPPRO seriously, so they might pay especial attention to your deletion idea), or to including a short bibliography of key references in the infobox, to highlight just how good the sources are. Similarly, we could also argue that the sister-project links should also go in the infobox, and in the lead, and at the top of every section, because it's really important that people have access to these links. But none of these WP:ITSUSEFUL (another argument-to-avoid) feelings are persuasive, and we already have a sufficient mechanism in place for giving people these links. There are even rather in-yo'-face templates for highlighting them in that section. No one argues that they aren't sister projects, and are just some blog. As everyone's already pointed out, they have different editorial policies that affect their reliability, so they are not internal links. This is looking at it from the researcher's perspective. We distinguish between external links, that have differing standards, and internal ones that follow our core content policies, which researchers have particular expectations about. We do admit that providing these links is a fine practice – in the external links section, where readers understand "these are off WP itself". We know they do good work, or we wouldn't link to them there, either. But we do, and thus we do continue to share that work with interested readers. "Slightly changes the definition of these templates" doesn't appear to be anyone's concern. Why would anyone care about that? People do care that the specific purpose of nav templates is to aid navigation to non-redlink. on-en.wiki, content-policy-compliant resources; changing that to something else is major shift, not a "slight change of definition". We slightly change the definition of things all the time. This construction does not parse: "the benefits ... seem to permit"; whether something is permitted is a matter of consensus; benefits vs. "costs" of various sorts are part of the analysis to come to consensus but they are not consensus by themselves. I think that addresses all the questions and hypotheses you raised, but I'll try again if I missed something.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  20:06, 17 June 2015 (UTC) PS: But see below about the |below= idea.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  20:21, 17 June 2015 (UTC)[reply]
  • Allow sister projects only in the below= section Most (all?) navboxes have title and above sections that all editors to place a name at the beginning and maybe a couple of the most pertinent links before navigating through a chronology or typology or some other kind of structured and logical listing. Similarly, there is a below option for the final line which allows for links that are most tertiary (e.g. linking to the navbox of the next season of a television series or in {{Wikipedia}} where it is used for searching sister projects about Wikipedia). I think it's completely appropriate to use it there and its functionality would not necessarily be redundant to {{sisterlinks}}. E.g. if you are discussing a literary character (e.g. Sancho Panza), then it would be appropriate to use {{sisterlinks}} for information related uniquely to that character (d:Q630823, c:Category:Sancho Panza, s:The_Encyclopedia_Americana_(1920)/Sancho_Panza) but the literary work in general can be linked from the navbox. I think this is useful information that would also encourage working between our sister projects. —Justin (koavf)❤T☮C☺M☯ 03:03, 6 June 2015 (UTC)[reply]
    You are a scholar and a gentleman. The 'Below', that's where the 'Wikiquote' and 'Wikisource' links have been placed over the eleven months. Thank you for creating a new proposal, because the first one was seldom addressed by the 'Opposed' group, who kept pointing out that we can't do this because the guidelines say we can't do this. This proposal is for a change to the guidelines, originally a proposal focused on three sister projects. Look at any writer from before 1930 and you will probably come upon those sister project links in the 'Below' section of the writer's template. They've been just fine there since mid-2014. The guideline has already been stretched to include 'Wikiquote' and 'Wikisource' links, it's now just a matter of asking Wikipedia to make the language fit the already accepted exception to the guideline text. Randy Kryn 22:56, 7 June 2015 (UTC)[reply]
    Actually, that's not what the oppose commenters are saying at all, and it's disingenuous as well as uncharitable to straw man their positions as simply argument from authority. The principal objections are: 1) nav templates are for on-WP navigation, not off-WP pointers; 2) we already have templates for linking to sister projects, which are done in the same section as other external links; 3) and that's because WP has no control over sister projects' policies and editorial control (the fact that they originated as offshoots of the same project is irrelevant – they remain external resources not subject to the same standards as WP articles.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  07:46, 8 June 2015 (UTC)[reply]
    Given this some extended thought. I think I well-developed proposal to include links of this sort in the |below= section of nav templates, if they are wrapped in a template that identifies them as off-site, sister-project links, might actually fly. I think that could maybe be seen as a "slight change of definition", or rather of scope. Not a proposal to include external links misleadingly in the template, but actually have a micro-==External links== section equivalent in the navbox. I may be smokin' crack, though. It's quite possible all the opposers above would oppose this as well. I'd be faintly inclined to support it, given a sandboxed example of the external-links-segment subtemplate, in a navbox, with example external links, and navbox content above it – a full demo, so people can evaluate the effect and impact. I would suggest that it be separately collapsible. Whether it can be collapsed by default or not would be fairly likely to affect the outcome of the proposal.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  20:21, 17 June 2015 (UTC)[reply]
  • Question Would this proposed policy allow or disallow links to a foreign equivalent article in the absence of an English one, as made possible by the {{ill}} template? Because if its mention is appropriate in a navbox, it is more useful (and user-friendly) than Filippo Bubbico (red link), itself more useful than Filippo Bubbico (no link). Place Clichy (talk) 17:47, 10 June 2015 (UTC)[reply]
    • @Place Clichy: It raises the exact same issues. The other Wikipedias have different core content policies (and often very lax enforcement of them), so they are external not internal resources. Also, the nav template guidelines are pretty clear that including redlinks is not useful at all. It is in other contexts sometimes, since it tends to inspire some amount of stub creation, but (see similar arguments above) the exact and only purpose of nav templates is to assist navigation to existing on-site resources (and not all of them, only those subject to the core content policies; wikiprojects do not go in nav templates, nor in article categories).  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  20:14, 17 June 2015 (UTC)[reply]
  • Hold the Horses, Stop the Presses, and Overnight the Results..., the Wikipedia template, {{Wikipedia}} , has included these sister links since late 2009. If nobody has taken those out yet, when the data they link to is about Wikipedia and people seem fine with that data continuing on the template about this site itself, may I submit for your approval the suggestion to at least let the Wikiquotes and WikiSource links stand in the templates under discussion here. For all our American Cousins, Happy 4th! Randy Kryn 20:58, 3 July 2015 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

WP:EXISTING

I've been tidying up a number of templates per WP:EXISTING (removal of unlinked text and redlinks), only to have them reverted. See {{John Banville}}, {{Beryl Bainbridge}}, {{Anthony Trollope}}, {{James Fenimore Cooper}}, {{Richard Bean}}, {{Colin Bateman}}, among others. How do we feel about these? --Rob Sinden (talk) 07:55, 3 June 2015 (UTC)[reply]

These templates are different than a typical navbox, because they document all of the notable works of authors's works that should have articles. Thus, removal of the topics from these navboxes suggests to readers that the bluelinks are the only notable works by that authors, and that they didn't produce anything else (the {{Anthony Trollope}} and {{James Fenimore Cooper}} templates are perfect of examples of this: we know that all of those articles should be created, because there is plenty of scholarship on both). If we leave out the redlinks, it makes it look like Wikipedia's coverage of these authors is complete: which is blatently false. These links operate like other WP:Redlinks in that I have seen articles created on these redlinks for several of the author templates. Similar work has been done by authors like Gobonobo on templates like Template:Oklahoma Women's Hall of Fame (which if we excluded redlinks, would look like it doesn't include a wide range of notable women each year). It seems to be common practice on navboxes which cover a concrete list of notable subjects, that we yet to have articles about, and using WP:EXISTING to justify removal of this information from navboxes does a disservice to our readers, and miscommunicates the gaps on Wikipedia's coverage of these concrete groupings of notable topics, thus discouraging participation from people who could fix the gaps, Sadads (talk) 15:13, 3 June 2015 (UTC)[reply]
I'd strongly disagree with the application of these arguments - take {{Anthony Trollope}} for example - there are entire sections (short stories, non-fiction, and plays) which consist purely of redlinks. Are these really likely to be created? And how can you apply the same argument of scholarship to {{Colin Bateman}}? --Rob Sinden (talk) 15:58, 3 June 2015 (UTC)[reply]
When there aren't sufficient sources to justify a stand-alone article, I think it's reasonable to unlink the entries. @Robsinden: Since most of the navboxes you were working on are literary works, it should be noted that WP:NBOOK has a relatively low bar with its requirement of just two published reviews. I think {{Works by Flannery O'Connor}} is a good example with both redlinks for notable works that don't yet have articles and unlinked entries for non-fiction collections that are probably not independently notable. gobonobo + c 23:23, 3 June 2015 (UTC)[reply]
But unlinked text in navboxes is worse than redlinks. Navboxes are not supposed to contain encyclopedic information. They are here for one reason only - to aid navigation between existing articles. Navigation templates are a grouping of links used in multiple related articles to facilitate navigation between those articles within English Wikipedia. Redlinks and unlinked text bloat navboxes, and as such hinder navigation. These are not articles, something that a lot of editors seem to forget. This is why Flannery O'Connor bibliography exists. The simple question is this - "How do redlinks and unlinked text aid navigation?". And the simple answer: "They don't". --Rob Sinden (talk) 07:48, 4 June 2015 (UTC)[reply]
Incidentally, I was only going through them as a lot of author templates have erroneously been added to Category:Works by writer, and was tidying them up as I was removing the category. --Rob Sinden (talk) 08:00, 4 June 2015 (UTC)[reply]
Gosh, look at the state of {{L. Frank Baum}}!!! How does this provide useful navigation? Yet it seems pointless trying to tidy it up, as in the current climate, my changes will no doubt be reverted. --Rob Sinden (talk) 08:03, 4 June 2015 (UTC)[reply]
The reasoning for including the non-linked is sound, although the red links are eye-candy in the worse way. How about just black non-links on the more prominent books missing from Wikipedia's article collection? This would allow data to be added while making the templates less unattractive with a profusion of red-links, and would give a place for new editors to see which books are in need of an article. Randy Kryn 11:30, 4 June 2015 (UTC)[reply]
Absolutely not. Unlinked text is worse than redlinks. Navboxes should not include encyclopedic content, that's what articles are for. --Rob Sinden (talk) 11:32, 4 June 2015 (UTC)[reply]
Re. {{L. Frank Baum}}: suppose this should be transformed into something like Isaac Asimov bibliography (chronological) (or something using tables like Theodor W. Adorno bibliography), then the template itself should be reduced to something of {{Stephen King}} length (or shorter, e.g. by grouping novels in a separate template). --Francis Schonken (talk) 07:07, 5 June 2015 (UTC)[reply]
Agreed with Rob Sinden (and the guidelines, and Francis Schonken's suggestions). Like categories and disambiguation pages (and unlike lists), Nav templates are only for navigation to existing material. They are not bibliographies or any other form of encyclopedic presentation of information, nor are they "article creation farms". Even lists should not be redlink farms, and MOS:SAL says this really clearly.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  19:55, 5 June 2015 (UTC) PS: Clarification: I agree that when a) it's a complete list of something finite and non-subjective (all Prime Ministers of Canada, all Ford sports cars) and all are unquestionably notable, or b) it's list (maybe incomplete because divided between multiple templates, or because WP's coverage will only go so far) of a sequential series (years, decades, centuries) and we will definitely have an article on all the ones included in the list, then redlinks are okay. All novels by someone, and similar categories should not, since there's no guarantee that novel or whatever is necessarily notable; AfD tells us that many assumptions that something will be notable are wrong. See RfC link below for proposal on this question; I have a more detailed version of this "these two cases" rubric.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  22:27, 17 June 2015 (UTC)[reply]
I think it's best to include a second bar at the top of such a navbox as {{L. Frank Baum}} containing scrutable linknames and associated targets such as All articles [eponymous category, if any], Bibliography [complete or complete for books, if any, perhaps an embedded list], and Portal [eponymous, if any]. Baum is so important to Oz that I would put Oz portal in that bar. The subsection label "Novels including Oz" should not link the Oz portal, as it does now, but might link a list of all Oz books or an Oz bibliography [works by Baum and by others] with a label such as "Novels including Oz books". The notice '(chronological)' is redundant given those encyclopedic dates; anyway it should be relegated to the end of the label.
Thus the navbox design would include links to both Baum bibliography and Oz bibliography that are prominent, as bluelinks in top and left-side framework, and scrutable. The body of the navbox would include only those redlinks that are pleas for articles, and no plain titles of works. --P64 (talk) 15:44, 19 June 2015 (UTC)[reply]

TFD related to linking navboxes in article space via navbox

Please consider commenting at Wikipedia:Templates for discussion/Log/2015 June 7#Template:Infestation navs. --Izno (talk) 18:35, 8 June 2015 (UTC)[reply]

Proposal to allow redlinks in navboxes

Please see Wikipedia talk:Red link#Guideline revision urgently needed. --Rob Sinden (talk) 12:59, 17 June 2015 (UTC)[reply]

Tweak bidirectionality

Per some of the problems that were raised by the (now on wikibreak) editor who seems to take guidelines literally and make mass changes based on his interpretation, I added the following refinement of the bidirectionality standard. (diff here)

An article that transcludes a given navbox should normally be included as a link in the navbox so that the navigation is bidirectional. However, this is not required, and particularly where inclusion of every article transcluding the navbox could result in hundreds of links, a link to appropriate lists or general topic overviews with links to the articles in question is acceptable. A navbox in an article that cannot be accessed from the navbox within two clicks is inadvisable.

I think this clarifies actual use; having hundreds of links in a navbox is generally not desirable in the eyes of most folks here, but at the same time, a navbox in an article that is not necessarily in the navbox can help readers get back to a main topic from a more obscure article. Montanabw(talk) 23:10, 27 June 2015 (UTC)[reply]

I really don't understand the purpose of the above edit. It waters down bidirectionality to the point that it becomes meaningless. Since this edit does not yet have consensus, I have reverted it. Full bidirectionality would require:

Every article that transcludes a given navbox should normally also be included as a link in the navbox so that the navigation is bidirectional. Likewise, to achieve this bidirectionality, every article linked in the navbox should normally have the template transcluded. Exceptions to this general guideline include but are not limited to navbox headings and footers that need not transclude the navigation template.

The whole purpose of navboxes is to aid navigation between related articles and that navigation is easiest and most natural when the links are bidirectional. A navbox without bidirectionality is a badly designed navbox.

navbox can help readers get back to a main topic from a more obscure article How did the reader get to this obscure article? If this article is not contained as a link in the navbox, then the reader obviously wasn't using the navbox. So why would a reader look to a navbox to get back to the main topic? Worse yet, if the reader did use the navbox to get back to the main topic, then the navbox itself can not be used to get back to the obscure topic. Wikilinks in the article text or in a "see also" section will be much more likely be noticed by the reader and hence a more effective way to leading the reader back to the main topic. Including navboxes in hundreds of articles where the articles are not contained in the navbox defeats the purpose of having a navbox. It would be far better to have a navbox dedicated to the related obscure topics with a title or footer in the navbox that leads back to the main topic. Boghog (talk) 00:51, 28 June 2015 (UTC)[reply]

The following discussion is relevant: Template talk:Aviation lists#‎RfC: Should this navbox be removed from non-mentioned articles?. The conclusion of that RfC is that at least for {{Aviation lists}}, it is not appropriate to include this navbox in articles where the article is not included as a link. Boghog (talk) 00:57, 28 June 2015 (UTC)[reply]

I respectfully disagree; full bidirectionality is an extreme - the caveat "normally" is being ignored by editors who go around removing navboxes from articles and so on. Your argument for see also lists or article text links is really an argument to not have any navboxes at all for anything. (I presume that isn't your view) Everyone has a different web surfing style, one gets to the end of an article on a specific topic, then moves on to something else relevant to the general topic, but a person doesn't always use inline links to access related material - link can go far beyond the topic or category to totally unrelated topics. And a see also list is not supposed to get too long, and those of us who create content are actually strongly encouraged to keep them to a minimum, particularly when cross-referencing. Montanabw(talk) 06:55, 28 June 2015 (UTC)[reply]
The aviation lists drama was a poor outcome and an example of yet more problems caused by the same (now on wikibreak) editor who confuses guidelines with policy. Frankly, no one is going to remove that template from thousands of articles if that's how many it's on ... When you actually create content, you see how there is a need for certain types of navigability and the reality of how navboxes are used in the real world is quite different from these guidelines, which need some clarification. ({{The Beatles}} is a great example) I'm really quite serious; I don't particularly want to be hre, but I'm tired of now a second round of one editor using these guidelines ad a bludgon. Time to fix them. Montanabw(talk) 06:55, 28 June 2015 (UTC)[reply]
Bidirectionality is not extreme, it is common sense. By your logic, all guidelines should be abolished because some editors may confuse guidelines with policy. If an editor is using a guideline as a bludgeon, the problem lies with the editor, not the guideline. The "poor outcome" was the result of consensus which I strongly support. Several of the editors who supported removing {{Aviation lists}} from articles which were not included as a link quoted bidirectionality as one of their arguments. Clearly these same editors support the principle of bidirectionality. Your proposed changes to the bidirectionality guideline directly contradicts that consensus.
  • Frankly, no one is going to remove that template from thousands of articles if that's how many it's on – {{Aviation lists}} was transcluded in 17,000+ articles which has now been reduced to 245 (see Wikipedia:Bot_requests#Template:Aviation_lists for the bot that removed the template from thousands of articles).
  • Your argument for see also lists or article text links is really an argument to not have any navboxes at all for anything. Not at all. All I was suggesting is that there are better alternatives. Another alternative is {{main}}. I also suggested a much better way to link back from obscure articles to the main subject is by creating a navbox that links related obsurce articles and has the main subject in the heading or footer of the navbox (see the "exceptions" clause in my proposed wording above). Boghog (talk) 08:58, 28 June 2015 (UTC)[reply]
      • The "balkanization" of navboxes isn't helpful, though, it's the same problem as content forking articles. For example, {{Equidae_extinct_nav}} was a fork of {{Equus}} and, frankly, I think they both are unreadable and busy. An infobox that summarizes the key articles in a given project allows the reader to move not just within a highly specialized topic, but into articles that are within the scope of the project, such as moving from, for example, domestication of the horse to the article on horse equipment (horse tack). Montanabw(talk) 19:48, 28 June 2015 (UTC)[reply]
This "balkanization" nothing to do with content forking, but rather creating walled gardens. This "balkanization" of articles and navboxes can easily be prevented by adding bidirectional links between project navboxes. Navbox headers allow readers to move move from specialized topics back into the main topics of the subject area. Conversely footer links from the main project navbox the more specialized project navboxes allow readers to find more specialized subtopics. You see, bidirectionality is useful! {{Equidae_extinct_nav}} is not a fork of {{Equus}} and it was very appropriate to separate the two. Boghog (talk) 04:53, 29 June 2015 (UTC)[reply]
{{The Beatles}} is a great example because of its full bidirectionality and as a consequence, it really can be used as a navigational tool to quickly navigate between related articles of related importance. This is how a navbox should look and function. It previously did not conform to bidirectionality because of its huge size that in turn was due to the template transcluding several other large navigation templates. Such templates should be used very sparingly because of the excessive number of links. The template was split into its component parts greatly reducing its size and thus allowing full bidirectionality. Boghog (talk) 09:44, 28 June 2015 (UTC)[reply]
Sincere question, though? Wouldn't a lot of people say that the current Beatles navbox is still way too large and horribly bloated? Particularly those who argue for a "small" number of links, as in my other suggestion below? Montanabw(talk) 19:48, 28 June 2015 (UTC)[reply]
No, I don't thinks so nor do I think a lot of other people would think so either. (Note: using {{Navbox with collapsible groups}} is one way reducing the size of the displayed template while retaining all of the content) One should always keep in mind that "Policies and guidelines should always be applied using reason and common sense." per WP:GUIDELINE. If there is a disagreement on the appropriate size of an individual template, this should be resolved like all other disagreement are resolved, through obtaining consensus. Boghog (talk) 05:18, 29 June 2015 (UTC)[reply]
  • Comment: After a RfC that goes overwhelmingly in one direction (aviation lists), rewriting the applicable guideline in the opposite direction reeks of WP:SNOW. Maybe think of it this way: most guidance is already based on what editors generally want. WP:CCC and all that, but it doesn't seem the time that this is going to happen on this particular issue. --Francis Schonken (talk) 09:38, 28 June 2015 (UTC)[reply]
    • "What editors generally want" is an open question: is it what the content creators who actually have to use and navigate between articles want, or is it what the people who concern themselves only with the technical aspects of navboxes want? There is a disconnect here. Clearly, there needs to be slightly stronger language than the word "normally" to allow for the exceptions to the general bidirectionality rule, as some literal-minded editors have no common sense and try to remove templates from all articles that aren't linked in the navbox, even though it's obvious that the navbox belongs on those articles, particularly when they are covered in a list article and would be highly impractical to put into any sort of comprehensive working template. Montanabw(talk) 19:48, 28 June 2015 (UTC)[reply]
    • What I'm after here is basically to be sure we clarify that a navbox can be placed on an article that is not linked in the navbox under certain, limited circumstances, and specifically where the navbox link goes to a list article that contains the article that transcludes the navbox. So how do we get there? Montanabw(talk) 19:48, 28 June 2015 (UTC)[reply]
      • Writing out such detailed clarification is actually rather something for guideline hogs. The current recommendation is sufficiently flexible for the odd exception in practical circumstances. Not for applying the aviation lists template to hundreds of articles. Editors generally don't want it that way, and that is reflected in the guideline. Aspersions against editors who don't appear to see it your way isn't really helpful. --Francis Schonken (talk) 03:01, 29 June 2015 (UTC)[reply]
        • Francis, unfortunately, you are (believe it or not) wrong. A need for detailed clarification occurs when vague and nonspecific guidelines are misinterpreted. And here they have been, I've had to deal with two incidents, about six months or more apart, both involving an interpretation of bidirectional that ignores the caveat "normally" and IAR. I think a "two click" rule to allow lists to be in a navbox and the navbox transcluded on each article contained in the list, on a limited basis, is actually a very good way to handle a topic with large numbers of items; a 200-link navbox is really most suitable for date series articles ( {[tl|The Boat Race}}, for example) or things that are numbered (like Bach composition) and it is more problematic for things like vehicle models and such—or the works of L. Frank Baum; how much simpler would that navbox be if there could simply be a link to "List of Oz books by L. Frank Baum." Montanabw(talk) 03:33, 29 June 2015 (UTC)[reply]

Well, Francis, you don't agree, but you are not a consensus of one. Sadly, the walls of text have made it difficult to even have a rational discussion at this point. Montanabw(talk) 07:02, 2 July 2015 (UTC)[reply]

Concerning this proposal to tweak bidirectionality, I agree with Francis, so that is at least a consensus of two. If one includes the consensus at the aviation lists RfC, then the consensus is overwhelming against this proposal. The wall of text is a direct result of your failure to WP:LISTEN. Boghog (talk) 09:55, 2 July 2015 (UTC)[reply]
Actually, I WP:HEAR you loud and clear. But a lack of traffic at this page and a drama board RfC that only pings people who haunt RfC (and not the relevant wikiprojects) is not anything close to a community-wide assessment of the issue. All I see here is a pair of bullies who WP:OWN this page and will not accept any form of change or compromise, let alone discuss anything in good faith without resorting to bullying, condescension and personal attacks. That said, I'll walk away from this one for now, I need to make a choice where my energy will go, and it isn't here. But if the literalness problem coupled with an inability to IAR or to note the word "normally," comes up again on a template or article where where I think it important, I now know what is apt to happen and will be prepared to respond appropriately. Montanabw(talk) 04:12, 3 July 2015 (UTC)[reply]

'One click' advantage

How about this: "navboxes work best when exploiting the 'one click' advantage they have over categories and over linking to a list: these last two need at least two clicks to get to a similar article" – I don't propose this as a replacement of the bi-directionality guidance, but as something sketching the wider context explaining the sense of leaning towards bidirectionality for navboxes. --Francis Schonken (talk) 07:36, 3 July 2015 (UTC)[reply]

I like it since it explains why bidirectionally is useful. We could add to this "With bidirectionally, the article's self-link will be bolded in the navbox which provides the reader with an immediate visual clue as to where in the navbox the current article is located and what are the most closely related articles." Boghog (talk) 10:56, 3 July 2015 (UTC)[reply]
Both are actually helpful additions that clarify this guideline, though perhaps just, "... over categories or lists." (Keeping in mind that a small number of category or list links may well be included in a navbox and even the existing guideline doesn't prohibit that, according to how you have interpreted the present guideline). You have to be aware that I am not opposed to bidirectionality in general, I merely believe there are exceptions; but I am here because I've had trouble on two separate occasions, about six months apart, with a user who seems to have trouble with exceptions... WP:IAR is to be applied carefully and with good reason, but it CAN be applied. I simply seek acknowledgement of that. Montanabw(talk) 03:34, 10 July 2015 (UTC)[reply]

"Small"

Per this edit, I removed the word "small" from the sentence "Navigation templates are particularly useful for a small, well-defined group of articles; templates with a large numbers of links are not forbidden, but can appear overly busy and be hard to read and use." I did this because the word "small" is open to drama; some navboxes, particularly dealing with a series, may have over 100 links. Others, such as {{Gravitational wave observatories}} may require a couple dozen links to be complete. One covering a topic, such as {{Special relativity}}, also could require dozens of links. (and note: Category:Physics_templates - dozens of navboxes!) Hence, "well-defined" is useful phrasing; "small" is drama fodder. I don't see a need for a hard and fast rule, as it is clear that size is really a case-by-case situation. (Example: {{The Beatles}} ) Montanabw(talk) 23:21, 27 June 2015 (UTC)[reply]

Yeah, "Navigation templates are particularly useful for a small, well-defined group of articles", in a comparison with categories, the latter work better for large well-defined groups. --Francis Schonken (talk) 23:43, 27 June 2015 (UTC)[reply]
Um, {{Johann Sebastian Bach}} ?? And frankly, the category people are often hell-bent on diffusing stuff into dozens of teeny-tiny categories too (I lost a battle once with someone who wanted to split a category with maybe a couple dozen articles into several with 2 or 3 articles each). It's a no-win. Seriously, define "small." Bach and the Beatles ain't small by anyone's standard! I really think that categories and navboxes have different navigational uses; the navbox shows interrelated articles, not all of which may be in the same category (i.e. {[tl|Equine}} shows topics in multiple subcategories within both Category:Horses and Category:Donkeys) . Categories show related articles that may not all be in the same navbox. (example, {{mammals}} is a dramatically different group of articles than the main page of Category:Mammals Montanabw(talk) 00:07, 28 June 2015 (UTC)[reply]
Re. "Seriously, define "small"." – from {{Bach violin concertos}} to {{Johann Sebastian Bach}} for someone "who ain't small by anyone's standard"
Define large: {{L. Frank Baum}} (see discussion above in #WP:EXISTING) --Francis Schonken (talk) 00:48, 28 June 2015 (UTC)[reply]
Well, someone else mentioned {{Transformers}} as unquestionably large! That's the point, the guideline says large navboxes aren't forbidden, it just points out the problems with them. I'm Ok with that. And yes, the Baum one is kind of a nightmare, I'd agree. Montanabw(talk) 07:09, 28 June 2015 (UTC)[reply]
What part of "Navigation templates are particularly useful for a small, well-defined group of articles" is a "hard and fast rule"? I do not see a rule, only a suggestion. Boghog (talk) 01:15, 28 June 2015 (UTC)[reply]
Well, I didn't either, but some other editors see things differently from you and I, and in an attempt to enforce a guideline as policy can take phrasing like that and make life miserable for those of us who are working on navigability issues. Montanabw(talk) 07:09, 28 June 2015 (UTC)[reply]
If you didn't interpret this way, why have you raised this as an issue? You are proposing solutions to problems that don't exist. Bloated templates are a real problem that degrades their usability. The suggestion of "small" templates is a concrete solution to this problem and hence clearly belongs in the guideline. Boghog (talk) 13:30, 28 June 2015 (UTC)[reply]
See my answer to the question just above. Montanabw(talk) 03:16, 29 June 2015 (UTC)[reply]
You have not answered the question. Please answer the question. Your non-responses are becoming trollish. Boghog (talk) 20:14, 2 July 2015 (UTC)[reply]
What question? If I think the current language is a "Hard and fast rule"? As I said, the problem is not what I think, it's how I've seen others deal with these guidelines. What you call a "suggestion" is ill-defined and taken too literally. Seems you need to either define "small" or just eliminate it and leave "well-defined," which allows for both adequate restriction and flexibility. My original suggestion here was simply to remove one word. If you think that is "trollish," then ANI is thataway. Let's not be ridiculous. I think I've made my position clear. Montanabw(talk) 04:23, 3 July 2015 (UTC)[reply]
Removing the word "small" does not provide "adequate restriction" as to the size of the template. By not defining precise boundaries between "small" and "large" leaves "adequate flexibility". If you insist, we could suggest a soft limit of 200 links as was done below (btw, {{KentuckyDerby}} has exactly 154 links and would not be considered large by this definition). Templates that have grown too large is a real problem that deserves mention in the guideline. Ignoring the issue does not make it go away. The need to alert editors of this issue trumps any hypothetical problems you may run into with other editors. It will not be the end of the world if the consensus is that a particular navbox should be split up because it has grown too large and you disagree. Also, why do you assume that you are always right in these disagreements? Perhaps the editors that you are have disagreements with have a legitimate point. Boghog (talk) 15:48, 3 July 2015 (UTC)[reply]
It should also be kept in mind that weakening the guidelines can "make life miserable for those of us who are working" to increase the usability of navigation templates. Boghog (talk) 10:36, 4 July 2015 (UTC)[reply]
I'm on the fence.

Part of the reason for "small" is that (a large number of) large navboxes can negatively impact pages that load them from a technical perspective. I like small included for this reason alone.

The other reason is that it's probably a good rule of thumb. In practice, some templates get really large (like Template:Transformers for example). As an example, I tend to agree that T:Transformers has the problem of being "overly busy and hard to read and use".

How about moving the use of the word small?

Navigation templates are particularly useful for a well-defined group of articles. Smaller sets of articles (and thus navboxes) help avoid issues associated with large templates, such as potential technical issues where many navboxes are transcluded, as well as larger templates being overly busy.

Wordsmith as desired. --Izno (talk) 01:36, 28 June 2015 (UTC)[reply]

Navigation templates are particularly useful for a well-defined group of articles. Templates with a large numbers of links are not forbidden, but can appear overly busy and be hard to read and use. Additionally, navbox templates with smaller sets of articles avoid technical issues associated with large templates, such as slowed loading time for pages where many navboxes or large navboxes are transcluded.

I think we actually can nuke the phrase small if we add a verb to the next phrase (now sentence). Also a tweak to that next phrase; I don't think it's necessary to dive into the exact tech problems. I'm not sure we need the word can, so proposing without the word:

Navigation templates are particularly useful for a well-defined group of articles. Avoid templates with a large number of links, since they 1) appear cluttered 2) can be are hard to read and use, and 3) present technical problems in rare cases.

--Izno (talk) 18:38, 28 June 2015 (UTC)[reply]

Added one word, struck another, I think you intended it to be there? Either way, I'm good with that. But I think we should keep something akin to the old "Templates with a large numbers of links are not forbidden but shoudl be avoided" language ,as this version will create similar drama amongst the literal-minded who have no common sense. Montanabw(talk) 19:22, 28 June 2015 (UTC)[reply]
"Avoid" is not "always remove or do not do". And in fact "avoid" is also clearly in the previous revision. --Izno (talk) 19:59, 28 June 2015 (UTC)[reply]
I wish others saw it your way. Tell that to the editor who confuses guidelines with policy and uses this guideline as a bludgeon to remove everything that isn't perfect. That's why I'm here, it's now happened twice. Montanabw(talk) 00:45, 29 June 2015 (UTC)[reply]
There's no benefit in "nuking the phrase", at least none that has been demonstrated. "Navigation templates are particularly useful for a small, well-defined group of articles" expresses the helpful guidance just fine. --Francis Schonken (talk) 19:00, 28 June 2015 (UTC)[reply]
Francis, that is just your own WP:IDONTLIKEIT opinion. I like Izno's version. Unless you think civilization as we know it will come to an end if one word of the existing guideline is changed, can you give the nod to this clarification? I am very serious that the previous version is open to misinterpretation by those who have no common sense. Montanabw(talk) 19:22, 28 June 2015 (UTC)[reply]
Well, show me a benefit, otherwise the wining and complaining resumes to "I don't like it". The template format doesn't work very well for the current {{L. Frank Baum}} (as was more or less the consensus in the #WP:EXISTING section above, recommending to move to a list and/or split in smaller templates), thus it has a benefit to keep "small" in the guidance, so that people don't put a lot of energy in something that in the end doesn't work very well. --Francis Schonken (talk) 20:07, 28 June 2015 (UTC)[reply]
I mean, I'm just trying to make Montana happy without moving from my own position, which might be described by the same Montana as one of "those who have no common sense". ;)

My opinion is that, after having thought about it, "small" in the context of the first phrase isn't necessary if you already have the second phrase in its entirety. But I don't care enough to push for changing the status quo. In general, that entire line in the guideline is really more of a topic-sentence for the following bullets, which are more useful for turning bad navboxes into good (as I did at the discussion on Template talk:Aviation lists). --Izno (talk) 19:59, 28 June 2015 (UTC)[reply]

Izno, I think we are making progress, Francis' incivil comment below notwithstanding. I think an improvement is possible, though the simple solution would be to keep "well-defined" and toss "small." The rest was my attempt to find a middle ground with you folks!  ;-) \ Montanabw(talk) 00:53, 29 June 2015 (UTC)[reply]
Still not showing a single benefit of tossing "small", all we got thus far is "I don't like it". --Francis Schonken (talk) 02:34, 29 June 2015 (UTC)[reply]
Re. "trying to make Montana happy" – been there, done that. Doesn't really work. Sorry for the energy you put into it.
Without the "small" the sentence doesn't really work as a recommendation for how to improve {{L. Frank Baum}}, notwithstanding the next sentence. So, no I'd need more to get convinced "small" would be redundant. --Francis Schonken (talk) 20:07, 28 June 2015 (UTC)[reply]
*smirk*

The problem with the example template has 0 to do with "large" and a lot more to do with "you put stuff in the navbox template that shouldn't be there". The dates are unnecessary except where needed for disambiguation (though for some reason the books and films projects disagree; something about making the sorting choice obvious to a reader), and you have a whole bunch of crap which isn't blue linked (see of course the RFC at WT:Red link). One of the ways you might also improve the template is to breakdown each bucket into a "by decades" subbox or a "by phase of writer's life". None of the problems with the template are "fixed" by the word small being either in or not in the template, so I'm not sure why you're defending the word in that case, and in fact the phrase which does make the example template an issue is the one I'm noting duplicates the intent of "small" i.e. it's "busy". To my eye, everything in the template looks normal, aside from the already-stated problems. --Izno (talk) 20:24, 28 June 2015 (UTC)[reply]

You forgot to indicate why the removal of "small" would be beneficial in the {{L. Frank Baum}} case. All you illustrate is that according to you it doesn't stand in the way of anything – I maintain that it's a good first approach to recommend the editor who wants to build a navbox on the complete works of an author with say 100+ works is probably going to end up with something not half as useful as a list article on the same (if the intention is to list all these works separately). That's the kind of ideas this guideline comparing cats, lists and navboxes is built upon. --Francis Schonken (talk) 02:30, 29 June 2015 (UTC)[reply]
My original position is that the removal of "small" duplicates the intent of the following statement regards lots of links, which is to avoid cluttered-looking navboxes (which harm the eye scanning, I suppose). Saying something twice when we could say it once is just good writing because it avoids (among other things) making conflicting points.

That said, with say 100+ works is probably going to end up with something not half as useful as a list article on the same is interesting to me; if that's how you're reading its meaning and use, I certainly wasn't. Could/Should we give this idea more prominence then? --Izno (talk) 03:27, 29 June 2015 (UTC)[reply]

Re. ...duplicates...: well it doesn't: "Avoid templates with a large number of links, ..." gives no useful recommendation regarding {{L. Frank Baum}} which has most of its content unlinked, so does not contain a "large number of links". The more general "Navigation templates are particularly useful for a small, well-defined group of articles" is better in showing the direction. --Francis Schonken (talk) 03:48, 29 June 2015 (UTC)[reply]
Francis, avoid personal attacks. Just because we have tangled before (where, in fact, the end result was a community consensus mostly in favor of my position, by the way, so don't be a sore loser) doesn't mean I don't compromise. I just think you are wrong. Montanabw(talk) 00:53, 29 June 2015 (UTC)[reply]
  • Also oppose the rewrite proposals. There is simply no need for it. The current version in the guideline is fine. Boghog (talk) 19:31, 28 June 2015 (UTC)[reply]
    • All I asked was to remove the word "small" here. Nothing more. It was, I had hoped, an opportunity to reduce drama elsewhere. Montanabw(talk) 00:53, 29 June 2015 (UTC)[reply]
      • See WP:FORUMSHOP advising against moving drama from one place to another. However well-intentioned it usually doesn't work very well. --Francis Schonken (talk) 02:30, 29 June 2015 (UTC)[reply]
        • Francis, please read WP:AGF - where the heck else would I take an issue about navboxes but to the navbox page? The "elsewhere" is about 10 assorted navbox templates (that I know of) where a certain editor who takes everything literally shows up to screw up multiple navboxes. It's hardly "forum-shopping" when I know I'm going to run into hostility. Sheesh. Montanabw(talk) 03:16, 29 June 2015 (UTC)[reply]
          • Montanabw, Francis is spot on. Forum-shopping is exactly what you are doing. What we have here is a disagreement between two editors. The "other editor" has no doubt has cited WP:Bidirectional. The Aviation list RfC demonstrates that bidirectionality has strong support. Instead of weakening the guideline to the point where it becomes meaningless, we need to strengthen the guideline by making clear why bidirectionality is important. Boghog (talk) 18:24, 29 June 2015 (UTC)[reply]
            • Boghog, assume good faith! What other "forum" is there to address the bidirectionality guideline but here? Seriously. And I have no intention of "weakening the guideline until it becomes meaningless," I am trying to make a couple logical and practical suggestions that reflect how the real world works. Montanabw(talk) 07:51, 1 July 2015 (UTC)[reply]
              • Unfortunately you are still WP:NOTGETTINGIT. The first proposed change to the guideline is [bidirectionality] is not required, and particularly where inclusion of every article transcluding the navbox could result in hundreds of links. This was precisely what the Aviation lists RfC was about and the consensus reached at that RfC is that placing a navbox in large numbers of articles that were not included as links in the navbox is inappropriate. Hence consensus is strongly against the first part of your proposal. A second proposed change is A navbox in an article that cannot be accessed from the navbox within two clicks is inadvisable. This language is a non-starter because it completely breaks bidirectionality. For navboxes to be fully functional, it is important that one is able to navigate between related articles using only the navbox and not have to go through a "list article". Of course, if the "list article" and all the articles contained in the list are included as links in the navbox and conversely if the navbox is transcluded in "list article" and all the articles on that list, then the navbox is fully bidirectional and the problem is solved without having to invoke the "two click" exemption. In other words, the "two click" exemption is completely unnecessary. Neither of the suggestions proposed at the top of the tweak bidirectionality thread are logical (because they are in fact not needed) nor are they practical (because they seriously degrade the usability of the navbox). Finally the proposed changes are in conflict with "real world" Wikipedia consensus. Boghog (talk) 15:59, 1 July 2015 (UTC)[reply]
  • Hey, y'all. What the heck is the argument about here? While I tend to agree with Montanabw that the word "small" is ill-defined, I also tend to agree that there are plenty of existing "large" navboxes that are well organized. I know of well-organized navboxes that include more than 200 links. The emphasis here should be on describing what is appropriate, and providing particularly good examples of "well organized." So let's dial this discussion down a notch or two, and see where we agree. I think there are some useful changes we could make here on which we may all agree after some back and forth. Dirtlawyer1 (talk) 01:31, 29 June 2015 (UTC)[reply]
    • Yes, thank you Direlawyer1, you are correct. My goal was to remove the word "small" from this section, as I clearly do think there are navboxes that need to have well over 100 links. ({[tl|Kentucky Derby}} as an example) The section isn't terribly clear or well-written, particularly in light of the discussion immediately below. Montanabw(talk) 03:16, 29 June 2015 (UTC)[reply]
  • Small is a measure of the infobox's size, and not its number of links; some, like {{Bach cantatas}}, have got hundreds of links but remain easily navigable. Alakzi (talk) 03:03, 29 June 2015 (UTC)[reply]
    • OK, now that doesn't make sense - if you mean in terms of bytes or bandwidth, then this is why you need to say so clearly, I'm not a programmer, my background in this respect is in graphic design (as a side to many jobs I've had, not my main profession), my focus is on the reader or observer, thus I presume "small" means "little in size/doesn't take up much room at the bottom." When you say you transclude one navbox inside another, I have no idea what that even looks like and wouldn't have the slightest interest in doing this, as far as I know... collapsable sections, sure, but just links to articles or categories, maybe portals and a wikiproject, perhaps... Montanabw(talk) 03:16, 29 June 2015 (UTC)[reply]
    • The guidance is about a "small ... group of articles" (quoted from guideline, bolding added), not about limited surface. E.g. {{Bach cantatas}}: limited surface, some 250 linked articles, falls out of the "particularly useful" according to the guidance (although "well-defined" is not a problem here). I agree. --Francis Schonken (talk) 03:25, 29 June 2015 (UTC)[reply]

Again, the main objective of this guideline is to compare grouping techniques:

(showing most useful grouping technique) Small collection Large collection
well-defined group of articles navbox category
somehow related topics, not all of them articles (none of the discussed grouping techniques particularily useful) list page

Leaving out "small" ignores the navbox/category distinction.

(note: none of this implies there shouldn't be cooperation among the grouping techniques, and multiple coverage by different grouping techniques, that's why I put the symphonies list/category/navbox example in the last paragraph of the lede of this guideline many, many years ago – the table above only gives some indication which one would best be done first: for instance, when wanting to group L. Frank Baum's oeuvre, large collection / not all of them articles yet, build the bibliography list first instead of a huge navbox full of red and black, and expand, and later maybe split, the navbox as more articles become available) --Francis Schonken (talk) 12:52, 1 July 2015 (UTC)[reply]

Francis, that compares apples to oranges. Here's how I see it: Montanabw(talk) 07:01, 2 July 2015 (UTC)[reply]
Navbox List Category
template article classification scheme
well-defined group of articles, may fall into multiple categories, basically an organized collection of related links well-defined group of articles, not merely a laundry "list" but a list with annotations, often images and citations, often uses chart or table structure. Has WP:FLC criteria for finest work broadly-defined group of articles, link collection, occasional guidelines for inclusion.
About 80% width of screen x a few cm high. Generally starts to look a bit unwieldy after about 50-60 links, but can hold over 100 if well-designed No significant length restriction, but gets unwieldy beyond a few hundred items Navigation aid limited to single-purpose, hierarchical "tree" structure with as few as 2 (not-advised, but they exist) to thousands (also not advised but they exist) of article links.
  • Calling the question: Rather than go into full-fledgd drama and call an RfC over one word, let me outline and recap my proposal:

1) I think the word "small" should be removed from the phrase "small, well-defined set of articles." My reasoning is that some well-defined sets of articles, as noted above, could still number in the hundreds; even those who oppose my proposal seem to agree that templates such as {{Beatles}} are acceptable even though quite large. Montanabw(talk) 04:23, 3 July 2015 (UTC) 2) In the alternative, I would support someone else's proposal for a rewording of the paragraph in question to achieve the same goal, so long as the same intent is kept.[reply]

Nothing more complicated than that. Montanabw(talk) 04:23, 3 July 2015 (UTC)[reply]

Oppose 1) and 2) for reasons given in detail above. Re. Montana's table above: I prefer the one above that, which imho is closer to what this guideline wants to convey (although of course not giving the full detail of what is in the guideline). --Francis Schonken (talk) 04:29, 3 July 2015 (UTC)[reply]
Oppose both (1) and (2). Size does matter. Navboxes that have grown too large are a real problem that degrades their usability. This issue needs to be explicitly dealt with in the guideline. Boghog (talk) 06:30, 4 July 2015 (UTC)[reply]
Anything that changes the template {{Thomas Jefferson}} one iota, a template which was mainly created and placed on the site July 3rd and July 4th of last year, I'd Oppose. Anything that gives a template more freedom to educate the public, and shares the accumulated information with the widest possible audience, I'd Support. I started to read this question and it starts off well and then a very few editors go back and forth, and I can't really tell what's what and what this will do. Count me either for or nay, depending. Randy Kryn 14:14, 4 July 2015 (UTC)[reply]
  • Please note that the guideline currently states Navigation templates are particularly useful for a small, well-defined group of articles. Hence this is a suggestion, not a requirement. With 169 links, I think {{Thomas Jefferson}} is a border-line large template, but still less than the 200 links that have been suggested elsewhere as a cutoff. This template might benefit converting it to a {{Navbox with collapsible groups}}. This would preserve all of the links, but only the most closely related links would be uncollapsed by default. To give you an idea of how this would work, see {{Transcription factors and intracellular receptors}}, a template with 737 links, but IMHO still quite manageable because it uses collapsible subgroups. Boghog (talk) 17:00, 4 July 2015 (UTC)[reply]
  • Please also note that the in the very same sentence, it states templates with a large numbers of links are not forbidden. This language was add on 27 February 2008. So I really do not understand why such a big deal is being made about one word that is a suggestion and not a requirement and is immediately qualified in the same sentence. This is completely bizarre. Boghog (talk) 17:35, 4 July 2015 (UTC)[reply]
Wikipedia, by its very nature, is bizarre, if bizarre contains the attribute of attempting something that's never been done before and apparently pulling it off. Thanks on the Jefferson. On many articles it appears quite nicely opened up, on longer ones its collapsed or should be. Depends on the page, and the context of how much the page could lead a reader into the "Wonderful World of Thomas Jefferson" as presented on the template. Readers and other students might really get to know this important fellow if they took the time to explore what Wikipedia has to offer on the subject. Happy 4th (just got back from a parade)! Randy Kryn

Proposal to extend WP:CATDEF to navigation templates

I propose that, due to the prominence of navboxes and sidebars, criterion numero 5 in Wikipedia:Categories, lists, and navigation templates § Navigation templates be reinforced with:

  2. The subject of a navigation template should be of a defining nature to the articles that the navigation template is placed in.

Rationale

  • Navigation templates, and navboxes in particular, are often placed in articles they're peripherally relevant. One recent example would be {{Black Lives Matter}}, the subject of which, Black Lives Matter, is only mentioned in passing in all of the shooting articles. Navigation templates are visually distinctive and thus demand the attention of the reader; the reader may be left with the impression that the subject is of import to the article. This is tantamount to a WP:UNDUE violation.
  • Non-defining navboxes clutter the footer of articles. Take, for instance, the international organisation country membership navboxes, which are themselves contained in navbox containers, in China or Japan.

Alakzi (talk) 12:50, 4 July 2015 (UTC)[reply]

Survey

  • Oppose based on structure; neutral pending discussion on concept. The rationale below clarifies your intent, which I think is, basically, "don't put navboxes into articles where they aren't relevant (though the bidirectionality standard we are debating above also requires this, as a general rule) but the phrasing above is pretty vague and fuzzy. I think that this is a new criterion based on when navboxes are added to an article (and how many, and if they are collapsed, etc.). The wording "of a defining nature" is kind of meaningless and should be rephrased or clarified. — Preceding unsigned comment added by Montanabw (talk • contribs)
  • Oppose, WP:DEFINING is a difficult to handle concept, even in the context where it's used currently (categorization). Also it doesn't prevent articles to be flooded with dozens and dozens of categories. So not a good idea to use this concept as an instrument to limit the number of navboxes (we'd get hopelessly trivial navboxes e.g. tenthousands of people born in the same year, doubling the existing category). The "Defining" concept is on a root level incompatible with navboxes. "Re-interpreting" the concept for use with navboxes would even give more mess in the categories departement (where the concept is regularly disputed, giving new ammunition to the disputants). --Francis Schonken (talk) 13:00, 13 July 2015 (UTC)[reply]

Discussion

  • What does "defining nature" mean? I think those are the words your suggestion focuses on. To me defining nature would be anything which defines a subject further, a subject which is related closely enough so that a reader may find the template educational and useful. Randy Kryn 14:07, 4 July 2015 (UTC)[reply]
    • I think that's probably too open-ended. I'd define it as a core theme or attribute, or a distinctive characteristic; it would be something you might expect to find in the lead of the article. See the rules of thumb at WP:NON-DEFINING - we won't be copying them verbatim, I presume, but it's a good starting point. Alakzi (talk) 18:05, 4 July 2015 (UTC)[reply]
  • The current criterion #5 says, "If not for the navigation template, an editor would be inclined to link many of these articles in the See also sections of the articles." I think you are actually discussing a different concept—the inclusion of the navbox in an article, not the contents of the navbox. Also, navboxes are not categories; a navbox might encompass topics in multiple categories and a category might encompass many things not in a particular navbox ... — Preceding unsigned comment added by Montanabw (talk • contribs)

Reference links within Navbox templates

An editor has removed the stat_ref value from at least one instance of the Largest cities template (i.e. {{Largest cities of Maryland}}) because it's a NAVBOX, and the unofficial WP:NAV guidance and archived discussions forbid external links in NAVBOXes.

While I interpret the prohibition as applying to external navigation links, the opposing editor applies a literal interpretation that any external source link (including usually government data in a source) is forbidden, stating that "Navboxes across wikipedia aren't sourced" and that the linked "articles have the sources". To the contrary, NAVBOXes that include Template:Largest cities template are sourced across Wikipedia, via the stat_ref parameter. Some example articles: Algeria, Andorra, Azerbaijan, Belgium, Brazil, Bulgaria, Bangladesh, Benin, Demographics of Canada, China, Chile, .... There are hundreds of such articles.

What are others' opinions on the validity of including external source links in such templates and NAVBOXes? —ADavidB 03:00, 13 July 2015 (UTC)[reply]

{{Largest cities}} is a very confusing template. It appears to be a hybrid between an infobox and a navbox. A pure navbox should only contain links to Wikipedia articles each of which in turn is already sourced so it should not be necessary to include sources within the navbox. Also the placement of {{Largest cities}} (e.g., {{Largest cities of Maryland}}) is sometimes like an infobox (e.g., Maryland in the body of the article uncollapsed), or as navbox (e.g., Columbia, Maryland at the bottom of the article and collapsed). In addition, a pure navbox should not contain information other than links and explanatory headings. {{Largest cities of Maryland}} contains graphics which is appropriate for an infobox, but not a navbox. Finally the consensus is to delete many of the instances of this template. Since most of the instances of the {{Largest cities}} template is as an navbox (i.e., placed at the bottom of the article), it would be better to convert {{Largest cities}} template into a pure navbox by removing |stat_ref= and extraneous information such as graphics. Boghog (talk) 04:28, 13 July 2015 (UTC)[reply]
I just noticed that {{Largest cities}} has an optional parameter |class=nav(box). One alternative would be to modify the template so that it accepts a |class=info(box)/nav(box) option that controls the display of the template. This way, one could use the template either as a infobox (uncollapsed and displays both |stat_ref= and |img_n=) or as a navbox (collapsed and suppression of the source and graphics). Problem solved. Boghog (talk) 06:37, 13 July 2015 (UTC)[reply]
Even in infoboxes I would suggest that external links (or at least references) are discouraged since everything within the navbox, like the lead itself, should be sourced somewhere in the article-proper. An infobox is a summary. --Izno (talk) 13:46, 13 July 2015 (UTC)[reply]
This navbox uses a particular template, as described above. Templates are used by design to simplify addition of content. Why require a list of largest cities to be identified and referenced again outside the navbox when the template content itself otherwise fully suffices? The main subject of the articles that include these lists is the country or other encompassing government body. —ADavidB 05:37, 14 July 2015 (UTC)[reply]
If you are putting non-en.Wikipedia links in a navbox, you're probably failing to use a navbox for its expected purpose. I see little reason why the numbers should be listed, or for that matter the images, in this navbox, and the county isn't relevant to a topic of "largest cities". Suggest stubbing it down to the simple links. --Izno (talk) 13:45, 13 July 2015 (UTC)[reply]
The template is used broadly as a means of listing largest cities and providing a non-en.wikipedia source reference. As I see it, the numbers quickly give a relative difference between populations and help avoid disputes or edits that might otherwise result in incorrect reordering of the list (even more likely if a source reference is disallowed). —ADavidB 05:37, 14 July 2015 (UTC)[reply]
What you are describing is an infobox, not a navbox. A navbox is designed to facilitate navigation between closely related articles. Nothing more. Graphics and sources do not belong in navboxes but may be appropriate for infoboxes. Adding a reference to a navbox that is placed at the end of an article is awkward because it creates a new reference section below the navbox separated from all the rest of the references. I still think the best solution is to add support to {{Largest cities}} for a |class=info(box)/nav(box) parameter that would control whether the template behaves like a navbox (displaying only links) or as an infobox (displaying links + graphics + sources). Boghog (talk) 06:16, 14 July 2015 (UTC)[reply]
I have no problem with the solution you describe. I believe the template is more often used/intended as an infobox. —ADavidB 06:35, 14 July 2015 (UTC)[reply]
The {{Largest cities}} template is much more often used as a navbox (positioned at the bottom of the article collapsed) than as a infobox (in the body of the article uncollapsed). For example, the {{Largest cities of Maryland}} is used only once as an infobox in Maryland and in the remainder of the articles, as a navbox. Hence I think the default |class)= should be set to navbox. Boghog (talk) 11:02, 14 July 2015 (UTC)[reply]
@Adavidb: Suggested the above change here. Boghog (talk) 12:39, 15 July 2015 (UTC)[reply]

Images in navboxes

Do we have any specific guideline or prior consensus regarding the use of images in navboxes? The issue is not dealt with here at all. Personally, I'm dead against them, as they provide no navigational value, they bloat the navboxes making them less compact, they give WP:UNDUE weight to a certain aspect of the topic, and they often repeat an image that could be found elsewhere on the page, or they show a tangentially related image. The only thing I can find is at the essay WP:NAV#Navigation templates are not arbitrarily decorative. I usually remove them if I come across them, unless there is a really iconic and strong tie to the topic, and especially if they force the navbox to be bigger than it need be, but I fail to see how this image enhances {{Ken Kesey}} for example. --Rob Sinden (talk) 15:06, 21 July 2015 (UTC)[reply]

You are correct very small images are discouraged ..this is covered at Wikipedia:Manual of Style/Images#Size "Images should be large enough to reveal relevant details" ...images in footer navboxs are simply to small to be of value to most readers (like mini icons) and generally say nothing about the image (no caption)....let alone how many of these images cause people to have to side scroll. This type of problem usually gets fixed during GA and FA reviews. In the case mentioned above the image in question is of very very low quality and should not even be used in an article let alone as a mini image. -- Moxy (talk) 15:45, 21 July 2015 (UTC)[reply]
This is the usual conflict between a raw technical view and a graphic design and layout view. Similar to use of color, an image in a navbox can draw the reader's eye to the navbox and thelinks it contains. This is particularly useful for non-sophisticated readers who are not familiar with the usefulness of navboxes and also useful to catch the eyes of people with slight vision problems (yours truly included). What image to include is often a debate that is needed, but, to give the example of {{Tibetan Buddhism}}, use of icons and imagery (as well as color) helps a navbox do what it is supposed to do - draw the reader to other articles on the topic. Montanabw(talk) 00:09, 22 July 2015 (UTC)[reply]
Above are great points.... but not what we're supposed to be doing in my opinion. All templates should have the same prominence on a page in an ideal situation. if links within a template are that Important that should be in the see also section or better yet incorporated into the article itself. just my opinion--Moxy (talk) 00:57, 22 July 2015 (UTC)[reply]
I can see the point in a sidebar, which can function like an infobox and help identify the topic, and there's only likely to be one on the page. But in the footer navboxes, I think they're unnecessary, clumsy, and can actually draw focus from other "equal" navboxes, hence my mention of WP:UNDUE. Not to mention they serve no navigational purpose. --Rob Sinden (talk) 07:58, 22 July 2015 (UTC)[reply]
Images in templates are fine. They draw the eye to the template itself, and one of the purposes of an image, if done appropriately (and the image at Ken Kesey is very good and fits the subject well, any of you guys know the history of the 1960s?), is to give the reader a look at the template so they can familiarize themselves with what Wikipedia has to offer. Too many people I know are ignorant of both the existence of footer templates and the treasures they have in terms of an information map. Images work well for that purpose. This seems, once again, a clash of cultures in terms of "What a template/navbox is", and so is a wider question. In the last two months or so Robsinden has tried to get rid of long-time established sister-project links in the below section, red links in the template, long-time established dates in the title, and now the long-time established use of accenting images. All of which, in the opinion of some other editors, enhance the templates and the information flow. Literally two views of template-nclusion, but the problem is that all of the items in a limited templates are included in the slightly-expanded templates, and so these discussions always center on removing data which other people like but keeping all of the data the exclusionists like, thus missing a sense of balance in a final consensus. Randy Kryn 9:49, 22 July 2015 (UTC)
If all the navboxes weren't all collapsed, the image of the bus in the {{Ken Kesey}} template is completely irrlevant and out of place at, say the One Flew Over the Cuckoo's Nest (film) article, and also puts WP:UNDUE weight on the Kesey template over the {{Milos Forman}} template. --Rob Sinden (talk) 10:11, 22 July 2015 (UTC)[reply]
And as far as your other points go, this is not the forum for it, but adding sister project links is editing against the guidelines, so they are not "long-time established", quite the opposite in fact, same with adding redlinks until very recently. Please keep to the point in hand Randy, rather than trying to drag separate issues into the mix. Your posts have a tendency to drift off-topic and muddle the argument anyway. WP:WALLOFTEXT. --Rob Sinden (talk) 10:14, 22 July 2015 (UTC)[reply]
As for the manual of style, the full statement is "Images should be large enough to reveal relevant details without overwhelming the surrounding article text". The images under discussion are fine and not overwhelming. Randy Kryn 9:54, 22 July 2015 (UTC)
"Article text" Randy. A template is not an article. There is no provision for images in navboxes in the guidelines as far as I can see, this seems to be a practice that has snuck in. And people creating new templates often copy similar ones, warts and all. --Rob Sinden (talk) 10:11, 22 July 2015 (UTC)[reply]
Snuck in? Probably been present since the inception, although I have no proof of that. The text means the same thing, the reason the images in templates are smaller is that they are not there to overwhelm the text, but to accent the subject just enough to draw attention to the template. We all realize that templates, especially footers, are not well-known by the average general reader (the same with sister-projects), and each reader has to have the "ah ha" template moment where they find these gems. Not every template needs an image, but some are small enough or important enough so that the image fits perfectly and accents the "template experience". I'd suggest that if one or a few editors are in favor of a particular image staying, and can point out in a coherent and reasonable way why it should remain, that should carry the weight of reason and allow for their continued inclusion. Randy Kryn 10:28, 22 July 2015 (UTC)[reply]
What should be asked in this case is does a very small out of focus image help our readers or make them wonder what the image about or who is cut off in the image...is it Ken Kesey? The image is simply not of value and posses more questions then it solves....let alone the other reasons for its exclusion. . -- Moxy (talk) 13:26, 22 July 2015 (UTC)[reply]
Or, "Why is there a picture of a bus on the bottom of the One Flew Over the Cuckoo's Nest (film) article?" --Rob Sinden (talk) 13:34, 22 July 2015 (UTC)[reply]
  • I've just removed the image from {{Martin Luther King}} too. I cannot understand why, when you have a navbox of that size, anyone would want to make it at least 20% bigger and add a little picture? --Rob Sinden (talk) 15:18, 22 July 2015 (UTC)[reply]
    Good removal, in my opinion as well. The King navbox, which I've worked on quite a bit, does look better without the image - I didn't put it there and never even looked at it with all text. It's a large template, folded up, so it's a good call. On smaller templates a picture does the opposite, it often adds to the experience (check out the fine picture on the {{Nikola Tesla}} template). On the Kesey expanded template on the Cuckoo's Nest film, it shouldn't be expanded there, so I'll swing by and collapse it if it is (EDIT: It wasn't, in fact all of the templates are locked up and hidden in one of those template-limiting "Links to other articles" cages). Randy Kryn 2:20, 23 July 2015 (UTC)
That Tesla image is exactly my point. By removing the image, we can reduce the size of the navbox by about 50%... --Rob Sinden (talk) 11:58, 23 July 2015 (UTC)[reply]
I imply I like something and you run over to remove it. The template is not reduced in size by 50 percent if the fine image is removed, you must be viewing your screen at some percentage that stretches the template very wide, maybe that's your problem with images. I put it back and reduced the size of the picture a little. Randy Kryn 13:02, 23 July 2015 (UTC)[reply]
Small resolutions are decreasing in usage; I see the same size as Rob. That said, I'm okay with a little whitespace in the groups myself. I think he removed it as an example (and I certainly would not have expected the edit to stick ;). --Izno (talk) 15:12, 23 July 2015 (UTC)[reply]
  • Case-by-case basis, as always. I don't see a reason to include the notion of images in the guideline (above and beyond "hi this is a thing that you can do", if that).

    Images have been present in navboxes since at least 2007, so saying they've creeped in is a mischaracterization of fact.

    On the general, my feeling is that one image, properly representing the topic of a navbox, is acceptable. For example, this edit of T:MLK I would disagree with under this principle. Another such item might be Template:Half-Life series, which uses the Half-Life logo. --Izno (talk) 17:04, 22 July 2015 (UTC)[reply]

    • I agree. I don't see any reason (nor a demonstrated consensus) for a rule either way, other than the default "it isn't forbidden". postdlf (talk) 18:13, 22 July 2015 (UTC)[reply]
      • There is no hard and fast guideline on images in navigation templates. Obviously, there's nothing to say they must use images, but there is also nothing to say they can't or shouldn't use images. Common sense would seem to be the mandate here. Removing the image from {{Martin Luther King}} was a good call, as the template looks much better without it (which I think is a good general rule-of-thumb for template with collapsible sections, such as, for example, {{William Blake}}. There are literally thousands of images we could use on that template, but to do so would look awful). A similar situation can be found at {{Romeo and Juliet}}. No sections, but before it became the ungodly orgy of links to everything in the history of the world that has ever had anything whatsoever to do with the play, it used to have an image, but when it ballooned in size, the image was rightfully removed. Same thing for {{Hamlet}}. Many smaller templates, however, use images much more effectively. And I can see little problem with that, short of WP:IDONTLIKEIT. Bertaut (talk) 02:56, 23 July 2015 (UTC)[reply]
        • I agree, they have their place and disputes are best handled on a case-by-case basis. I am quite concerned with this overall "movement" that Randy Kryn noted and share his concerns - it would be counterproductive to somehow make all navboxes some sort of rigid, uniform, rather dull, obscure boring things... They have multiple uses, and making things too narrow and too rules-focused isn't helpful. Montanabw(talk) 03:40, 23 July 2015 (UTC)[reply]
          • Navboxes are for navigation not decoration. Graphics have no place in navboxes. Boghog (talk) 05:35, 23 July 2015 (UTC)[reply]
          • People differ in what they find most satisfactory. Personally I think it is a plus if navboxes are not purely functional devices for navigation, but also are good to look at and, if possible, have a well-chosen graphic capturing something central about the navigation topic. --Epipelagic (talk) 05:51, 23 July 2015 (UTC)[reply]
        • The problem with some of the smaller templates having images, is that they expand the navboxes unnecessarily. What could be a single line navbox becomes 4-5 times larger if an image is included. Yes, there are arguments that they have their place if appropriate (like the {{Half-Life series}} example - image doesn't distort the navbox size too much, wholly identifies the topic, etc.), but I'm concerned that sometimes it's just an image for the sake of having an image in there. I'm coming across a lot of writer navboxes with a (sometimes massive) picture of the author in it. And sometimes the only reason for inclusion is WP:ILIKEIT or WP:PRETTY. --Rob Sinden (talk) 10:15, 23 July 2015 (UTC)[reply]
        • Many here are confusing navboxes with infoboxes. Navboxes do not have multiple uses, they have one use, navigation. An exception might be navigational sidebars at the top of an article that look and function somewhat like infoboxes. Cramming distracting items like graphics into a navbox that is at the bottom of an article interferes with its primary purpose by unnecessarily increasing its size and therefore is not helpful. It is better that the navbox focus on its primary function (navigation) so that it performs that job optimally rather than several jobs poorly. Boghog (talk) 15:24, 23 July 2015 (UTC)[reply]
  • There's a comment floating around in my head regarding size of templates which "best suit images". Generally, templates with less than N groups with M links/group and an image look bad on large screens (vertical spacing in the groups); templates with more than I groups and J links/group look bad on both large and small screens (whitespace through the image cell).

    There's another comment floating around my head that the inclusion of these pictures bloats the total page size for small articles (for large articles, it's "just another image", maybe) which I can be fairly certain a large number of users (especially the writers) have issues with. --Izno (talk) 15:27, 23 July 2015 (UTC)[reply]

  • If you examine a number of navboxes with and without images you will find the addition of the image generally adds little to the size of the navbox, and often adds no increase. Some of us are visually oriented and appreciate how an appropriate image can evoke a navigation topic and add to the visual aesthetics. Others are less visually oriented and simply don't care for the images. It's perhaps more a matter of accepting that different genes are involved than trying to change the genetic makeup of our opponents by arguing. That said, if we must argue we should stick at least to logical argument. There is no logic in Boghog's view above that adding an image mysteriously causes the navbox to then perform poorly for the purposes of navigation. --Epipelagic (talk) 16:33, 23 July 2015 (UTC)[reply]
  • If they are sectioned off, properly and/or well, then templates don't become harder to use the larger they become. If done well they provide a better map, yet if they become harder the larger they are then it might be a result of poor template construction and language. The images do increase the size horizontally, so very large ones may not be suitable for an image, but on smaller and medium size templates adding an image doesn't hinder the template but provides a visual to attract the many readers who don't yet know what a template is (or those who have a better experience with an image sitting there, like comfort food with a face). Maybe all of us should bring that defect a little more into focus, that it's probable a small percentage of people coming here don't yet know to look at the templates to obtain a map to the subject. Images help and do not hinder that aspect of template awareness. Randy Kryn 18:44, 23 July 2015 (UTC)[reply]
As numerous people have stated, there are no guidelines against navigation templates utilising images. Mr. Sindon's personal distaste for them is precisely and exclusively that, his personal distaste. All the rhetoric in the world will not change the fact that this is the definition of WP:IDONTLIKEIT and there are no grounds for removing images from templates which use them. Obviously, this is to be managed on a case by case basis, with reasonable employment of, as Mr. Bertaut says, common sense (a picture of Joyce on a Woolf template would be ridiculous, for example). Not sure what else needs to be said really. Five Antonios (talk) 19:04, 23 July 2015 (UTC)[reply]
The fact that there are currently no guidelines on the use of graphics in navboxes does not mean that we should not develop one. Furthermore Rob's distaste for graphics in navboxes is neither exclusive (I and several other editors share his concern) nor is it simply WP:IDONTLIKEIT [the issues of (1) bloat, (2) undue, and (3) redundancy are legitimate grounds for removal of graphics from templates]. Finally as with any guideline, there are exceptions and common sense should always be applied. Boghog (talk) 01:49, 24 July 2015 (UTC)[reply]
It's a little unfair to say that my motivation here is WP:IDONTLIKEIT, seeing as in my first comment I state "they provide no navigational value, they bloat the navboxes making them less compact, they give WP:UNDUE weight to a certain aspect of the topic, and they often repeat an image that could be found elsewhere on the page, or they show a tangentially related image" when you're not actually giving a reason for them to remain. --Rob Sinden (talk) 07:55, 24 July 2015 (UTC)[reply]
Sigh...that's not a remotely accurate way to characterise the pro camp Rob. Again, if you must keep arguing, please stick to facts and don't set up straw men. It has already been established that, apart from small navboxes, the inclusion of an image generally adds little or nothing to the size of the box. Images that are only "tangentially related" or are already included in the articles may not be appropriate images, and no one here has argued that the images should be inappropriate. --Epipelagic (talk) 08:24, 24 July 2015 (UTC)[reply]
Your claim simply isn't true. The {{Martin Luther King}} example (and there are many others) shows how a large template can be greatly increased in size by the addition of an image. It's only the medium sized navboxes which aren't particularly compromised. And see my comments above regarding Ken Kesey's bus at {{Ken Kesey}} being tangential to One Flew Over the Cuckoo's Nest (film). No straw men here. And I don't see any argument from you for keeping them other than WP:PRETTY. --Rob Sinden (talk) 09:11, 24 July 2015 (UTC)[reply]
That is not a remotely accurate way to characterize Rob's response. He was merely pointing out there was considerably more to his argument than WP:IDONTLIKEIT. Furthermore you are directly contradicting yourself when you write there are no grounds for removing images from templates which use them and Images that are only "tangentially related" or are already included in the articles may not be appropriate images. Finally it has not been established that image generally adds little or nothing to the size of the box. To reiterate, navboxes become harder to use the larger they become and graphics do increase the size of navboxes. Boghog (talk) 09:19, 24 July 2015 (UTC)[reply]
Yes, I agree Rob that a sectioned navbox like {{Martin Luther King}} shouldn't have an image. On the other hand {{Commercial fish topics}} has three images that do not increase the size much at all. In general images don't seem a good idea on small or sectioned navboxes, but generally have much less effect, or even no effect on the size of navboxes which are grouped. Boghog, in your rush to find a counter-argument you claim that I wrote there are no grounds for removing images from templates which use them. I said nothing of the sort... that's another straw man. Of course discrimination is needed. Some navboxes should not have images, and even if a navbox is a suitable candidate for an image then the image needs to be appropriate. --Epipelagic (talk) 10:35, 24 July 2015 (UTC)[reply]
Actually, in {{Commercial fish topics}} viewed at 1024 x 768, the images take up about 25% of the template, forcing a much larger navbox than is necessary. --Rob Sinden (talk) 11:30, 24 July 2015 (UTC)[reply]
Epipelagic, Not another strawman, but rather Five Antonios who wrote that. Sorry. At the same time, I think you owe Rob an apology. Five Antonios wrote there are no grounds for removing images from templates which use them, to which Rob responded you're not actually giving a reason for them to remain, to to which you wrote that's not a remotely accurate way to characterise the pro camp. Rob was specifically replying to Five Antonios and not to the entire pro camp, hence your characterization of his response is unfair. In addition you still have not established that adding graphics does not increase the size of the template. In a narrow window for example that might be displayed on a mobile device, {{Commercial fish topics}} becomes almost twice as long with the graphics as compared to without. Boghog (talk) 13:19, 24 July 2015 (UTC)[reply]
To give Epipelagic the benefit of the doubt, I did amend my earlier post moments after writing it, which had claimed that all we were seeing from the pro camp was WP:ILIKEIT and WP:PRETTY, but decided it was a little confrontational. Maybe they were looking at an older version, even though half an hour had elapsed between my post and theirs. (That said - have we seen much else from the pro-camp?) --Rob Sinden (talk) 13:49, 24 July 2015 (UTC)[reply]
Size matters. I've removed quite a few images off larger templates. But since templates are maps to the subject (navbox is almost literally the definition of "map"), many maps have illustrations. They enhance or identify the subject even further for the casual reader, many of whom are tuned-into graphics and relate to the world through images. To correctly answer an objection above, there is actually a whole template for "One Flew Over The Cuckoo's Nest", and it does not have an image on it. The image is on "Ken Kesey", where the topic focuses on the author's complete works and life and not on an individual work. Readers can tell that the bus image, which as in icon defines Kesey, does not specifically refer to 'Cuckoo's Nest' (although what do you think the boat trip stylized?). Randy Kryn 1:23, 26 July 2015 (UTC)

Even as this is being discussed Rob is going around removing images from templates. I asked him to please stop this but he's continuing. Please see the current discussion at the {{Émile Durkheim}} template, which I've worked on recently. Randy Kryn 13:27, 28 July 2015 (UTC)[reply]

Template talk:Émile Durkheim#Remove the image. --Rob Sinden (talk) 13:33, 28 July 2015 (UTC)[reply]

Category "easter eggs" in navboxes

How do we feel about linking to categories in navboxes? I'm finding a lot of writer templates that link [[:Category:Novels by Xxxxxx Xxxxxx|Novels]] as a group heading. Per WP:EGG or WP:SURPRISE, I don't think your average reader would expect to end up at a category from this link, rather they'd be expecting to stay in article space and be directed to [[Bibliography of Xxxxxx Xxxxxx|Novels]] or similar article instead. Which leads me on to linking to categories from navboxes in the first place. With rare exception, most of the articles would be in the said categories, so is there even any benefit to include links to them in the navboxes? --Rob Sinden (talk) 12:46, 23 July 2015 (UTC)[reply]

This discussion has been had before, has been had before, and can be found in more than one page's archives. The consensus has uniformly been to not do this, for the reasons you outlined, among others. I don't remember every one of these discussions and surely missed some, but I don't recall there being a total condemnation of including a category link. As you point out, it doesn't do anything useful for the reader. The whole point of a navigation box is to provide an alternative "window" on a category (or some subset of it that is relevant to narrower purposes of the specific navbox), so using the category in the navbox is kind of "logic loop".  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  06:56, 24 July 2015 (UTC)[reply]
People browse differently, and that's one of the points of this guideline. In the context of the headers, I think egg/surprise is the dominant guideline/policy. In the context of the footer, where it is now common to include links to categories, books, and a handful of other on-wiki non-mainspace links, I see little issue. Someone may actually be interested in scanning alphabetically rather than by grouped or temporal sorting. --Izno (talk) 13:26, 24 July 2015 (UTC)[reply]
Concur.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  03:09, 27 July 2015 (UTC)[reply]
Seems to work better to explicitly link categories at the bottom of a navbox without the EGG element. In that context, they can be helpful if someone wants to browse categories. Montanabw(talk) 09:17, 27 July 2015 (UTC)[reply]
One other thing that seems related: I've seen a handful of "more..." showing up at the end of a set of items in a particular group, which disturbs me somewhat more. I have the same issue here. --Izno (talk) 03:18, 27 July 2015 (UTC)[reply]
Yeah, that's the same WP:EGG situation. I think if we're going to direct people away from mainspace, this should be explicit. And I won't mention linking to other templates from within templates. --Rob Sinden (talk) 08:02, 27 July 2015 (UTC)[reply]
Concur with Montanabw, Izno, Robsinden.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  00:14, 28 July 2015 (UTC)[reply]
  • Rob asks "Is there any benefit to including them (categories) in the first place". Of course there is. If a writer doesn't have a bibliography page then a link in the section title "Novels" to "Category:Novels by Joe Smole" expands the navigation within Wikipedia (Categories are within Wikipedia space). It seems beneficial to the project to include categories in this way. Randy Kryn 13:34, 28 July 2015 (UTC)[reply]
Hi Randy, you've answered part two of my question with an answer for part one. As you can see, per WP:EGG and WP:SURPRISE this is not acceptable. Any move out of mainspace to category space should be explicit. Hiding a link to categories it in group titles like this will not be where the reader expects to go. --Rob Sinden (talk) 13:35, 28 July 2015 (UTC)[reply]

Template/navbox cages

On my sojourn to templates I've often found one of these cages:

and have long-thought that they do not give templates the respect that other parts of a page receive. Templates often seem to be second-class nephews of third-class citizens, and in terms of collapsed space a boatload of templates take up the same room as Categories, External links, notes, or many other article sections. There are only five templates on the Ireland page (only four added if you take away the "Articles related" cage, which I've done), and, for example, a recent discussion at the Lincoln Memorial page brought a solution of one template showing with three in a box labeled 'Memorials'. I believe that if templates are presented well that many can be shown without having to hide them away. Six or seven templates, easily, can be shown collapsed and not take up very much room, and some pages can use many more. One of my favorites, and I won't mention it for fear of someone caging it, has nine templates in an accidently beautiful design. I've often even found the template of the prime topic of a page hidden in one of those template-black-holes. My question: Can we guideline many of these 'Related article' cages out of existence and allow a good amount of space for collapsed appropriate templates on appropriate pages? Thanks. Randy Kryn 20:12, 28 July 2015 (UTC)[reply]

Guidelines are descriptive. ;)

That said, I typically remove these where I see them surrounding 4 or 5 or so, but once past that count you're at the point where the question you should really be asking yourself is whether all of the navboxes on the page in question are appropriate. Bidirectional helps in this case. --Izno (talk) 20:22, 28 July 2015 (UTC)[reply]

I agree with Izno. 4-5 templates don't normally need to be "caged", but that navbox wouldn't belong on Ireland anyway because of WP:BIDIRECTIONAL. --Rob Sinden (talk) 07:58, 29 July 2015 (UTC)[reply]
Per WP:LTAB, tables should not be used for layout purposes. If {{Navboxes}} is to be kept, it should be rewritten to use proper markup. Alakzi (talk) 09:53, 29 July 2015 (UTC)[reply]
Layout in the context of the guideline is in the same context as in the HTML specifications, not in the more general understanding of "layout". For example, using a table to position an image next to some text or another is what is banned. T:Navboxes is fine, unless you have a problem with navboxes (lowercase) as a whole from a semantic point of view (since navboxes would more properly be lists of lists, not a table). --Izno (talk) 16:25, 29 July 2015 (UTC)[reply]
{{Navboxes}} is simply a container for {{Navbox}}es. Unlike a navbox, {{Navboxes}} is not a data table. Alakzi (talk) 16:28, 29 July 2015 (UTC)[reply]
T:Navbox is really a layout table, not a data table (and just about everyone familiar with HTML specs in the context of Navbox recognizes that). The problem you would face in attempting to see the html structure of T:Navboxes changed would be that there are a good number/chunk of users who use T:Navboxes without encapsulating all of the relevant navboxes on a page inside of it (which is a valid use case). Good luck. --Izno (talk) 16:31, 29 July 2015 (UTC)[reply]
I'm not sure why that should matter. Alakzi (talk) 17:23, 29 July 2015 (UTC)[reply]
"That" is ambiguous. The use case? You upset the set of users without any particular good reason (you can argue semantic HTML, but 1. navboxes as a whole are offensive on this point and 2. the users in question don't care so long as the reader-facing implementation is the same). So if you can demonstrate that item 2 is satisfied, I don't foresee an issue, but a "this should change" without knowing whether it can be changed is a little off-the-mark. --Izno (talk) 17:43, 29 July 2015 (UTC)[reply]
{{Navbox}} can be liberally described as a data table. At the very least, it's got key–value pairs. I'm not sure where I might've suggested that the behaviour of {{Navboxes}} would change. Alakzi (talk) 17:50, 29 July 2015 (UTC)[reply]
Conservatively, it can be described as a layout table, since it is (most commonly) a list of lists (which would more properly use list markup).

You nowhere explicitly made that suggestion, but I'm however unsure that you considered the implications of the broad "thou shalt be Semantic" edict. As I suggested, if you think you can duplicate T:Navboxes's behavior (presumably using <div>)s, have a go at making the suggestion; otherwise you're going to get shot down since the template uses a well-established metatemplate. --Izno (talk) 12:51, 30 July 2015 (UTC)[reply]

I don't recall having asked for lessons in consensus-building, nor do I hold any edict dear. Collapsible boxes can be built with <div>s, though we'd probably need to make some changes to the navbox class in MediaWiki:Common.css. Alakzi (talk) 12:57, 30 July 2015 (UTC)[reply]

Just took away a template cage which held two templates. The main reason I brought this up was to point out that the main purpose of these one-line template-holders, especially if there are six or less collapsed visible templates, is to hide templates/navboxes. Should they be hidden? Of course not, they are a valuable part of the articles, and appropriately used they expand the readers options to learn much more about a subject than a single article, no matter how good the page is, will give them. So it's a bottom-line matter of template respect. For those of us who enjoy and work on templates their beneficial properties are obvious, and making readers aware of this available resource will improve their usefulness. To do so they must be visible, just as every other section of the page is visible. Question, are templates sometimes featured on the main page, either as the daily feature or as an additional item for readers to browse? Thanks. Randy Kryn 11:40, 30 July 2015 (UTC)[reply]

To answer your question, no. I see little reason to do so. --Izno (talk) 12:05, 30 July 2015 (UTC)[reply]
If one or more became featured articles (I know templates aren't considered 'articles' but does that eliminate them from feature contention?) it would expose more people to them. The fact that many editors enclose templates in the one-line navbox shows that they do not have the respect of the community, and this might be so ingrained that even people who work on templates accept it. But back to the topic, do you have a suggestion for guideline language which would limit the use of the one-line enclosure which we can formally put up for discussion? I'd say something like allowing six collapsed appropriate templates/navboxes before the use of the enclosure, with more allowed if applicable and nondisruptive to the page (some sports pages have a dozen or more templates, which seems excessive). Randy Kryn 12:14, 30 July 2015 (UTC)[reply]
I think it depends on the size of the article and relevance of the navboxes. A stub article would have a lower threshold than a large article. And things like awards navboxes should probably always be "caged" unless there are just one or two. --Rob Sinden (talk) 12:21, 30 July 2015 (UTC)[reply]

Readers don't see templates (or don't realize they are templates--this is A-OK IMO). The reason you see T:Navboxes used so often is because of writers being somewhat protective of how much information is displayed on the articles of choice they edit.

I would suggest that further discussion about T:Navboxes be at template talk:navboxes for an update of the associated documentation (or possibly at WT:NAV. Placing usage information here would be somewhat out of scope for this page (at present) since it mostly covers the differences and reasoning you would use a particular type of organization rather than guidelines for each specific to each (a fact that depresses me to some extent since there should be guidelines for such). --Izno (talk) 12:51, 30 July 2015 (UTC)[reply]

Those protective writers are just the point, that the respect for templates/navboxes is hindered by the overuse of these one-line cages (I know cages is an emotional word, but seems descriptive of what occurs), so a guideline is probably needed. Discussing that guideline here might be a better, or as good of, a place, because this page governs guidelines concerning the templates. Why don't we work on language and then alert both pages, but the point of this request is to see what kind of consensus comes from it. Thanks, and your comments do move the process along. Randy Kryn 13:32, 30 July 2015 (UTC)[reply]
Maybe some editors don't like navboxes because a lot of them are bloated with information text, images, external links and other clutter, so that's why they hide them. --Rob Sinden (talk) 13:47, 30 July 2015 (UTC)[reply]
That's a reason, disregarding the pointy language 'bloated' and 'clutter' (replace with 'data' and 'wow, look what's available to me! Thanks Wikipedia!'), if the templates were expanded on the page, not collapsed. If there happens to be one expanded template, say the template for the subject of the page, along with three or four collapsed templates, then those other could either be in plain sight or, depending on context and appropriate connection to the subject, within the one-line box. Randy Kryn 14:00, 30 July 2015 (UTC)[reply]

Template:Orson Scott Card

Any thoughts on how to improve this further? See Template talk:Orson Scott Card#Massive tidy-up. Also, given our discussion about images, should we include an image? --Rob Sinden (talk) 14:51, 12 August 2015 (UTC)[reply]

{{clarify}}

I just removed the {{clarify}} next to WP:NAVBOX 3.

I just wanted to clarify that navboxes should be created and used only if there is added navigational benefit. Otherwise, as editors we should defer to WP:NAVBOX 5 because we can simply create "list of ... articles".Curb Chain (talk) 21:03, 25 August 2015 (UTC)[reply]

An example would be List of laser articles.Curb Chain (talk) 05:05, 26 August 2015 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Categories,_lists,_and_navigation_templates&oldid=677891221"