WhisperToMe (talk | contribs) |
Theopolisme (talk | contribs) |
||
Line 430: | Line 430: | ||
:: I disagree with the change. As DESiegel says, there is no benefit for the change. --[[User:NaBUru38|NaBUru38]] ([[User talk:NaBUru38|talk]]) 23:28, 8 January 2014 (UTC) |
:: I disagree with the change. As DESiegel says, there is no benefit for the change. --[[User:NaBUru38|NaBUru38]] ([[User talk:NaBUru38|talk]]) 23:28, 8 January 2014 (UTC) |
||
:'''Disagree''': The bolding of article titles helps emphasize what the subject is. [[User:WhisperToMe|WhisperToMe]] ([[User talk:WhisperToMe|talk]]) 23:46, 9 January 2014 (UTC) |
|||
=== An aside: looking at a couple of examples outside Wikipedia === |
=== An aside: looking at a couple of examples outside Wikipedia === |
||
Line 443: | Line 442: | ||
:The proposal does not explain how there is any advantage in changing this.--[[User:Charlesdrakew|Charles]] ([[User talk:Charlesdrakew|talk]]) 10:19, 8 January 2014 (UTC) |
:The proposal does not explain how there is any advantage in changing this.--[[User:Charlesdrakew|Charles]] ([[User talk:Charlesdrakew|talk]]) 10:19, 8 January 2014 (UTC) |
||
::Indeed. There is zero benefit to making a change to the bold title of an article. In fact, having to go through 4 million articles (even with a bot) to implement any such change would only be a mammoth waste of time and effort. [[User:Resolute|Reso]][[User Talk:Resolute|lute]] 14:37, 8 January 2014 (UTC) |
::Indeed. There is zero benefit to making a change to the bold title of an article. In fact, having to go through 4 million articles (even with a bot) to implement any such change would only be a mammoth waste of time and effort. [[User:Resolute|Reso]][[User Talk:Resolute|lute]] 14:37, 8 January 2014 (UTC) |
||
== Proposal to add [[Portal:Film in the United States]] to [[Gone with the Wind (film)]] == |
|||
There is a discussion at: [[Talk:Gone_with_the_Wind_(film)#Is_Portal:Film_in_the_United_States_tangential_to_this_article_or_not.3F]]. |
|||
I want to propose the addition of the [[Portal:Film in the United States]]. Some editors believe this portal (Portal:Film in the United States) is tangential to an article on an ''individual film'' and are only relevant to general/overall topics, and therefore this portal should not be included. I argue that this film has been perceived as one of the best examples of American film by reliable sources and therefore this portal is relevant and not tangential. Since there has only been a limited number of editors in this discussion, I am putting this forward as an RFC. Discussion may take place in the article talk page. |
|||
Some relevant discussion is located here: [[Wikipedia_talk:WikiProject_Film#Cross_WikiProject_relations_and_decisions_about_portals]] |
|||
[[User:WhisperToMe|WhisperToMe]] ([[User talk:WhisperToMe|talk]]) 23:10, 9 January 2014 (UTC) |
Revision as of 23:52, 9 January 2014
Policy | Technical | Proposals | Idea lab | WMF | Miscellaneous |
- Table of contents
- First discussion
- End of page
- New post
New ideas and proposals are discussed here. Before submitting:
- Check to see whether your proposal is already described at Perennial proposals.
- Consider developing your proposal on Wikipedia:Village pump (idea lab).
- Proposed software changes should be filed at Bugzilla (configuration changes should have gained a consensus).
- Proposed policy changes belong at Wikipedia:Village pump (policy).
- Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
- Proposed new wikis belong at meta:Proposals for new projects.
- Proposed new articles belong at Wikipedia:Requested articles.
Proposal for a Template Documentation: namespace
- This proposal is moved from the Idea Lab. That discussion may be found at Wikipedia:Village pump (idea lab)/Archive 12#Proposal for a Template Documentation: namespace. Update this link if it moves!
Any template with even a shard of complexity has a corresponding documentation file... the end result being that AllPages for templates is chock full of /doc, /doc, /doc. For such a ubiquitous feature, I feel that it would be very justified for a new Template Documentation: namespace to contain all of these documentation pages. This way, we could have a clear dichotomy between template code to be transcluded, as opposed to whatever needs to be said or explained about the template (but, of course, not transcluded with the template).
Let's also consider taking the idea a few steps further. By its direct association with an existing Template: namespace, the new TD namespace has potential for some features not usually found in a run-of-the-mill new namespace.
- Automatic transclusion
- We could make the function of the {{Documentation}} template automatic: a Template: page, requiring no individually-paged code or template to do so, could automatically check for a corresponding Template Documentation: page and display that on the bottom of the Template page, with a little explanatory divider/footer separating the two - explanation similar to the format currently in place on {{Documentation}}. And of course, none of that documentation or divider explanation would be transcluded onto any pages using the Template page. If we did this, it would be very feasible for a fully-developed, fairly complex template, complete with documentation, to use zero includeonlies, and zero noincludes. None of that crap. {{Documentation}} could become a thing of the past.
- No documentation exists? "No documentation exists for this template. Click here to write some! <link>"
- Special pages
- Hard-coded associations between Template: pages and their Template Documentation: pages would enable us to look into additional Special pages: "Special:WithoutDocumentation", et cetera.
- Intelligent categories
- An infobox template about birds might be in Category:Infobox templates. It might transclude Category:Birds onto host pages which use it. This is logical, but to restrict the application in those ways we need more include rules. Ugly! My understanding is you simply must have include rules to use categories on a template page - because honestly, how often do categories apply to both templates and their host pages?
- A better system: we could declare that categories in the Template: page's code would only apply to host pages, while categories one wishes to apply to the Template: page itself are placed in the Template Documentation: page.
I think that this would be a really useful thing to have on Wikipedia, and if it's adequately implemented it opens the door for similar features on other wikis. =)
Support
- As proposer: − Elecbullet (talk) 06:34, 12 December 2013 (UTC)
- See no reasons to object thus far; anyone who has worked on templates know how unwieldy the /doc subpage workaround system is for documentation. Not sure how much of this would also apply to Modules though. TeleComNasSprVen (talk • contribs) 07:04, 12 December 2013 (UTC)
- I know very little about Modules, in fact I learned they existed in the process of writing this proposal, so I have little ability to comment. I foresee much commentary about how if we can have documentation for user scripts, CSS, modules, et cetera, why should templates have special treatment?
- If a decision is made to implement Template Documentation as I have proposed, then (due to the bold-faced features I listed) my meager understanding of the software indicates it would probably require the writing of an extension, rather than just a simple new namespace. I think this extension could very easily have the capacity to work for every kind of namespace, and it could implement a system by which the individual installation selects which namespaces are document-able. So we could enable it for Templates if the consensus is as much, and if it is decided to apply to Modules as well, we could enable it there too. And if someone chooses to install the extension on their own wiki, the webmaster can implement documentation on whichever namespaces they please. Maybe I'm just rambling though. − Elecbullet (talk) 07:33, 12 December 2013 (UTC)
- As in something like a new super-namespace in the hierarchy? Like Documentation: Documentation\Template: Documentation\Modules: etc... (Well for now I mean we should just concentrate on Template Documentation: )TeleComNasSprVen (talk • contribs) 07:38, 12 December 2013 (UTC)
- Modules could already use such a system by changing MediaWiki:scribunto-doc-page-name if the target namespace existed. And if I were to implement such a thing more generically I'd do it along the lines of MediaWiki:ns10-doc-page-name. Personally, I'd recommend a pattern along the lines of "Documentation:Template:Foo" and "Documentation:Module:Foo" for a documentation namespace. Anomie⚔ 12:56, 12 December 2013 (UTC)
- That honestly sounds really great. An administrator here suggested to me a master "Documentation:" namespace, which I kinda brushed aside 'cause I never thought of it like that.
- Maybe that would be a better way to go about it. − Elecbullet (talk) 17:52, 12 December 2013 (UTC)
- Going one step further, I note we already have a "Help" namespace, and both Special:PrefixIndex/Help:Template: and Special:PrefixIndex/Help:Module: are empty. OTOH, Patrick87 does have a good point below about /doc subpages matching with /sandbox and /testcases subpages. Anomie⚔ 19:48, 12 December 2013 (UTC)
- Help: was mentioned in Idea Lab. I thought that it would be wise to keep generic, wide-scoped help pages like "Help:Editing" distinguished from specific, definitively page-associated documentation like "Template:Infobox bird/doc", which is why I didn't much like the idea of extending the use of Help. − Elecbullet (talk) 02:52, 14 December 2013 (UTC)
- Going one step further, I note we already have a "Help" namespace, and both Special:PrefixIndex/Help:Template: and Special:PrefixIndex/Help:Module: are empty. OTOH, Patrick87 does have a good point below about /doc subpages matching with /sandbox and /testcases subpages. Anomie⚔ 19:48, 12 December 2013 (UTC)
- Modules could already use such a system by changing MediaWiki:scribunto-doc-page-name if the target namespace existed. And if I were to implement such a thing more generically I'd do it along the lines of MediaWiki:ns10-doc-page-name. Personally, I'd recommend a pattern along the lines of "Documentation:Template:Foo" and "Documentation:Module:Foo" for a documentation namespace. Anomie⚔ 12:56, 12 December 2013 (UTC)
- As in something like a new super-namespace in the hierarchy? Like Documentation: Documentation\Template: Documentation\Modules: etc... (Well for now I mean we should just concentrate on Template Documentation: )TeleComNasSprVen (talk • contribs) 07:38, 12 December 2013 (UTC)
- If a decision is made to implement Template Documentation as I have proposed, then (due to the bold-faced features I listed) my meager understanding of the software indicates it would probably require the writing of an extension, rather than just a simple new namespace. I think this extension could very easily have the capacity to work for every kind of namespace, and it could implement a system by which the individual installation selects which namespaces are document-able. So we could enable it for Templates if the consensus is as much, and if it is decided to apply to Modules as well, we could enable it there too. And if someone chooses to install the extension on their own wiki, the webmaster can implement documentation on whichever namespaces they please. Maybe I'm just rambling though. − Elecbullet (talk) 07:33, 12 December 2013 (UTC)
- Support, although the technical details need to be discussed and ironed out first. The namespace could have the same relationship to
Template:
space as theTemplate talk:
namespace has, or it could be a new Documentation namespace, where identically-named Template, Module, and perhaps MediaWiki pages would automatically tie to -- similar to the way edit notices are handled. There should be a discussion on the pros and cons of each. equazcion → 02:38, 13 Dec 2013 (UTC)
- Part of me thinks that a master Documentation namespace with "Documentation:Template:Infobox" as name format would be best. But part of me thinks also that if that were the case, why would it not be at "Talk:Template:Infobox" too?
- It seems that everyone seems to agree that the basic idea of segregating template documentation in some more intelligent manner is a good idea - if I interpret his message correctly, even the fellow under "oppose" (but feel free to correct me). If we can move toward that goal in some form or fashion I think it'd be really good. − Elecbullet (talk) 22:15, 13 December 2013 (UTC)
- Support the spirit of the proposal. It would be nice it there were a simple, obvious, 1-click way to add documentation to a template. I'd support the idea of asking the foundationy/experty types for their advice on how to implement an improvement in the workflow. Maybe they'll say namespace, maybe they'll say gadget. But Elecbullet is making a useful point here. --HectorMoffet (talk) 04:49, 2 January 2014 (UTC)
Oppose
- Support the idea behind it, but oppose the proposed implementation. A new namespace for everything (I still have the whole "Draft" NS discussion in mind) will clutter up the UI to a point were it becomes impractical and it will definitely not improve clarity, especially for beginners. A documentation page is a fixed part of a template and should therefore be a subpage of it (I love logical hierarchical structures were appropriate!). The same goes for template sandboxes and everything else linked to the template.
- TL;DR: I would favor an implementation similar to WP:Editnotices. – as long as it is technically feasible. {{Documentation}} offers some functionality that would probably need some thought to carry over to the proposed system. Other projects have much more sophisticated documentation templates, e.g. commons:Template:Documentation which automatically creates WP:TemplateData, takes care of translations and much more. All this has to be considered and made available, too, which I currently have no idea how it could be done in a clear and easy way (without recreating the same problem - that this proposal aims to avoid - again) --Patrick87 (talk) 09:20, 12 December 2013 (UTC)
- This seems pointless when there is already a help: namespace for documentation. Graeme Bartlett (talk) 11:25, 14 December 2013 (UTC)
- Help: is very broad when it comes to Wikipedia, and covers mainly How to Write X (where X = article, redirect, portal, etc), How to Join the Education Program, How to Use the Watchlist, How to File a Username Change, in short how to use Wikipedia's front end. This namespace is used to document the code or the backend for the MediaWiki software among other things. (And then the really really far backend of this is on mediawiki.org) Sort of like when Help: was split from Wikipedia: as a namespace. I'll still take Help: into consideration as another place for documentation. TeleComNasSprVen (talk • contribs) 11:51, 14 December 2013 (UTC)
- Oppose we don't need another namespace. Documentation works fine the way it is. This is a solution in search of a problem. -- Ross Hill • Talk • Need Help? • 17:00, 15 December 2013 (UTC)
- Oppose The reasons for this are unconvincing. /doc pages represent only 5% of the template namespace. What is preventing AllPages from being an effective way to search through templates is the fact that we have half a million templates, making an alphabetical list an inefficient way of searching. Not having to use noinclude to transclude the documentation seems like a pretty trivial benefit, when you consider the tens of thousands of pagemoves and edits it will require to implement this. We could already do things like Special:WithoutDocumentation as a database report. You will still need include rules for categories to avoid categorizing the template itself in article categories. Saying that categories on the template page don't apply to the template is confusing and would require even more thousands of edits to create documentation pages for the thousands of templates that are categorized, but undocumented. As I mentioned, only around 5% of templates have a /doc page, but 90% have at least 1 category. Mr.Z-man 18:05, 15 December 2013 (UTC)
- Oppose. The benefits do not even come close to the cost in time; energy; resources; effort; etc. to implement this. GenQuest "Talk to Me" 18:10, 15 December 2013 (UTC)
- Oppose. This should be implemented properly as a MediaWiki extension, if it is to be done at all. — This, that and the other (talk) 06:31, 16 December 2013 (UTC)
- Well I'd imagined that anything beyond a simple addition of a namespace would require as much. I figured that if the great Wikipedia showed interest in a system, an extension would soon follow. − Elecbullet (talk) 08:21, 16 December 2013 (UTC)
- Oppose. While I could see some advantage to it, it seems to be a huge cost in maintenance and conversion, for very little gain, and it introduces rules that bring in a whole new set of issues with common documentation pages. It ain't broke, so why are we trying to fix it? VanIsaacWS Vexcontribs 06:42, 16 December 2013 (UTC)
- Oppose per Patrick87. I think the idea of moving documentation transclusion out of community edited templates and into something supported by mw is valuable. It likely doesn't need to be a namespace, but we should push toward hand-rolling less of the template infrastructure as time goes on. Protonk (talk) 18:05, 16 December 2013 (UTC)
- Oppose the method, but Support the desire to make it easier to manage template documentation. Is this something that could be done with a template that automatically transcludes the documentation page "Foo Template/doc" within "Foo Template"? I agree that the whole include/noinclude syntax is a bit daunting for moderately experienced article editors who are trying to figure out how templates work and how to improve their function or documentation. I also agree with the proposer that it should be easier to add missing documentation to a template. – Jonesey95 (talk) 16:07, 19 December 2013 (UTC)
- Oppose – per Ross Hill. United States Man (talk) 02:17, 21 December 2013 (UTC)
- Oppose – per above. — MusikAnimal talk 00:37, 30 December 2013 (UTC)
Comment
- Some possibly relevant Bugzilla pages:
- mediazilla:50512
- mediazilla:51849 (one I sent in myself)
- mediazilla:54140
- − Elecbullet (talk) 06:39, 12 December 2013 (UTC)
- What about Help:Template:Infobox officeholder instead of Template:Infobox officeholder/doc? --MZMcBride (talk) 01:43, 15 December 2013 (UTC)
- Similar things have been mentioned in other sections. An outline of proposals put forth:
- Template:Foo/doc (unchanged, ofc)
- Template documentation:Foo
- Documentation:Template:Foo
- Help:Template:Foo
- Of the four, I am afraid that I must see #4 as the least desirable, because I think that the Help: namespace, which is currently reserved for broad subjects such as Help:Editing, does so very well, but would not do well to be mixed with individual-page-specific documentation such as "Template:Infobox/doc". I honestly don't know if I would prefer that over no change at all. − Elecbullet (talk) 06:34, 15 December 2013 (UTC)
- Similar things have been mentioned in other sections. An outline of proposals put forth:
- I note there are really two separate issues here: (1) Automatically transcluding documentation (which could do /doc subpages) like in the Module namespace, and (2) a separate namespace for documentation. Anomie⚔ 20:01, 15 December 2013 (UTC)
- When you put it that way, simply having /doc be auto-transcluded without a new namespace really doesn't seem like a terrifically bad option. If we could find a way to move toward that it would be very good. − Elecbullet (talk) 03:49, 23 December 2013 (UTC)
- I think we have a winner for the technical implementation in Anomie's proposal. It seems most people agree that template documentation has room for improvement, but namespace isn't quite the right tool for the job. Auto-transclusion of a /doc subpage looks like the perfect tool for the job. --HectorMoffet (talk) 05:00, 2 January 2014 (UTC)
- When you put it that way, simply having /doc be auto-transcluded without a new namespace really doesn't seem like a terrifically bad option. If we could find a way to move toward that it would be very good. − Elecbullet (talk) 03:49, 23 December 2013 (UTC)
- Anomie's solution would also help small wikis, as they would get /doc support without all the template infrastructure that is currently required. \o/ John Vandenberg (chat) 11:26, 8 January 2014 (UTC)
On Orphan tags again
I apologise for missing the discussion above and the Request for Comment but I would like to give some arguments that oppose the move to the talk page. Before starting I would like also to note that I am ready to follow any consensus reached. I already filled a BRFA in case the consensus reached is finally implemented.
So, I start:
- The main argument on moving the orphan tag is a general argument against all tags and has already failed many times. SeeWikipedia:Perennial_proposals#Move_maintenance_tags_to_talk_pages
- Distinguishing editors from readers is completely out of the idea I have for Wikipedia. Wikipedia is the encyclopaedia everyone can edit. Every reader is a potential editor. We should encourage readers to become editors. Tags promote the idea of editing. Almost all Wikipedia articles are incomplete and need expansion.
- Connectivity between pages is a big deal. We should rely on the fact that an article is searchable via the Search engine. We should connect articles between each other. In the past the Russian Wikipedia went a step further and checked for articles only linking from one to each other with no other connections. We should not want dead ends in Wikipedia. Reading is an endless adventure.
- 120,000 pages with no incoming links, not even from lists of pages is an issue. Not a small issue. Think that from these lists we xclude disambiguation pages, SIAs etc etc.
- Things are getting better. That things are stale is a myth. Per progress described in Category:Orphaned articles: In January 2013, there were 175,000 orphan articles and in November 121,725 articles. 50,000 less. everytime there was some effort to reduce the list we had results. If we exclude pages with 1 or 2 incomings links from the list things may be much better. In the past we were very strict about it. Now maybe it is time switch a bit and remove tags if there is at least 1 incoming link. -- Magioladitis (talk) 11:37, 23 December 2013 (UTC)
- Simple things people could do: add a link and then remove tag. -- Magioladitis (talk) 13:42, 23 December 2013 (UTC)
- It's not that simple. I did a little experiment. I picked the first 10 articles under A in Category:Orphaned articles from December 2013 (I've not included those under deletion considerations). They are:
- I could only link three. I linked Abdul Wali Khan University Mardan in Mardan. I also removed the tag on Gerardo Ablaza since he had been linked already. I linked A Fort of Nine Towers in And the Mountains Echoed, since both books are mentioned as being reviewed in one of the references of the latter. I won't contest it if it is reverted. Three out of ten, and all of them could only be linked once (which I think still makes them orphans, but I removed the tags anyway). The seven will retain their orphan tags indefinitely.-- OBSIDIAN†SOUL 16:33, 23 December 2013 (UTC)
- Not indefinitely. Until Wikipedia is expanded further enough. Now I am running against all articles and checking they are already linked by other pages. Still 60,000 pages to check. -- Magioladitis (talk) 17:07, 23 December 2013 (UTC)
- @Magioladitis: Yesterday I ran BattyBot over all articles tagged as orphans and removed hundreds of tags. I check the current month's articles almost daily. GoingBatty (talk) 19:04, 23 December 2013 (UTC)
- @GoingBatty: and then why I did these today: [1], [2], [3], [4] and more... -- Magioladitis (talk) 19:12, 23 December 2013 (UTC)
- @Magioladitis:
- 1 & 4 - My bot runs autotagging and then skips any articles that still contain "orphan" - these contains "orphan" in the text.
- 2 - Link was added yesterday from Phalia
- 3 - Unknown, but glad you're finding them. GoingBatty (talk) 19:28, 23 December 2013 (UTC)
- Nope. Indefinitely. We have 58,662 orphans from 2006 to 2010. These are articles which had the tag for 3 to 7 years. That's 1.3% of our total number of articles. It's very clear from that alone, that readers either don't know how to fix them, or don't care to fix them. Fixing orphans are the concern of experienced editors not drive-by readers. They're the only ones with enough know-how to do it properly. All of you here who support retaining the tag as is are bot, tool, or script users. Even without the tag, you can still accomplish these tasks. But you are not anymore the average reader, and to equate yourselves with them is a mistake.-- OBSIDIAN†SOUL 00:11, 24 December 2013 (UTC)
- Additionally, saying "Until Wikipedia is expanded further enough" is basically saying it can't be fixed. That's counter-intuitive to the purpose of maintenance tags. What's the use of those tags on top of the article urging everyone to fix the orphan status if it can't be fixed anyway? And it's not the minority either. That was 7 out of 10 that couldn't be fixed. It will just waste everyone's time every time they attempt to de-orphan it, only to find out they can't.-- OBSIDIAN†SOUL 01:39, 24 December 2013 (UTC)
- @Obsidian Soul: Just curious why you didn't add
|att=December 2013
to the seven articles you could not deorphan, which hides the article message box. GoingBatty (talk) 04:14, 25 December 2013 (UTC)- Because like our regular readers, I had no idea that I could or should hide the tags for undeorphanable files that way. It is not mentioned in the template itself. And even if it was (which would make the template even larger and more alarming than it already is), I doubt a regular reader would actually understand how to add that properly or think they have the "rights" to. The only people who know that attribute and use it, are those who do dedicated maintenance work, and they don't need the tag to tell them it's an orphan. They usually access the orphan list through the category directly.-- OBSIDIAN†SOUL 05:18, 25 December 2013 (UTC)
- @Obsidian Soul: Just curious why you didn't add
- Additionally, saying "Until Wikipedia is expanded further enough" is basically saying it can't be fixed. That's counter-intuitive to the purpose of maintenance tags. What's the use of those tags on top of the article urging everyone to fix the orphan status if it can't be fixed anyway? And it's not the minority either. That was 7 out of 10 that couldn't be fixed. It will just waste everyone's time every time they attempt to de-orphan it, only to find out they can't.-- OBSIDIAN†SOUL 01:39, 24 December 2013 (UTC)
- Not indefinitely. Until Wikipedia is expanded further enough. Now I am running against all articles and checking they are already linked by other pages. Still 60,000 pages to check. -- Magioladitis (talk) 17:07, 23 December 2013 (UTC)
- Oppose as original proposer of previous discussion.
- The previous proposal explicitly only applies to orphan tags. I have no problems with other maintenance templates (except when people are tagbombing to make a point). As pointed out, the assumption that there is a preexisting consensus not to move maintenance templates is not based on anything other than they were first implemented that way in the first place.
- Wikipedia's primary goal is to educate, not to turn everyone into Wikipedia editors. While we should encourage new editors as much as possible, we should never lose sight of the fact that we are an encyclopedia, not the borg collective. We are meant to be read first, edited second. Otherwise we might as well just display Wikipedia as an etherpad in permanent edit mode.
- Not everything can be connected. Much less connected two to three times. Several subjects (e.g. taxon articles) already had to explicitly be excluded from being orphan-tagged because of their highly-specialized nature. There are other articles like that that can't be categorized as easily, but are nonetheless similarly unlinkable to more than one other article (or none at all) even though they are undoubtedly notable. For example: non-western notable people, places, ideas, or organizations. Or companies and products even, where adding it to other articles would constitute spamming. And while they may not have incoming links, they would usually still have outgoing links, thus still fulfilling part of the connectivity requirement. To put it in analogy: when you're solving a jigsaw puzzle, you will always find instances of difficult pieces which do not fit yet or can only be slotted to one other piece. And the best way to solve that is not to force them to fit, but to find other easier pieces to work on until you eventually link up with it.
- It's a minor issue because it does not concern our readers. Again, most readers arrive through the topic through search engines, not by clicking on a link from another article. They can still find the article very easily if they wanted to.
- The fact that more orphans remain than are fixed seems indicative that a fair amount of them are permanent members of the category. As in they can't be linked yet or at all, unless someone forcefully adds it on See alsos of vaguely related articles. And I don't see that as ideal either.-- OBSIDIAN†SOUL 12:32, 23 December 2013 (UTC)
- I have argued a few times to create a "page tags" extension to MediaWiki, which would make maintenance tags (and maybe WikiProject banners and things like {{ArticleHistory}}) out-of-band (separately displayed and separately editable from article content, possibly with different permissions). And by the way, it would render this whole discussion moot, since everyone could choose to hide or show tags wherever they want, as they please. Keφr 13:52, 23 December 2013 (UTC)
- Support Keeping all of the tags on the same page. Considering the technical in-feasibility of fragmenting the tags with some on the article page or some on the talk page, it jut does not seem sensible to do so. Twinkle, AWB, AFCH, and some other scripts/tools are all having difficulties accomplishing this because it requires adding an entire new section to the code and quite frankly it's not worth it. Let's not pad a bunch of editors edit counts to fragment the maintenance tags, seems entirely counter productive. You don't like the way the tag looks on the articles page, we can change the way it looks without getting rid of it. Technical 13 (talk) 17:47, 23 December 2013 (UTC)
- Here's my thinking:
- The main argument on moving the orphan tag is that it's about a problem on a different page. No amount of editing Orphan is going to de-orphan it. You have to edit some other page. I support reducing the prominence of this particular tag (e.g., moving, hiding, or re-sizing it). I do not support doing this for any other tag.
- I agree that every reader is a potential editor. Let's focus them on tasks that can be achieved by editing the article they're reading.
- I agree that we should not want dead ends in Wikipedia—but orphans are not {{dead end}} articles.
- I agree that having 120,000 pages with no incoming links is an issue. Maybe, in addition to manually de-orphaning some, we should be looking at whether all of these articles actually belong here. We had a spate of spam-articles about Alaskan dermatologists a couple of years ago. How many of them really belong here? Do you realistically think that we can de-orphan every single article about every single dermatologist that paid someone to create an article, without creating something silly like a "List of Alaskan dermatologists"?
- I agree that things are getting better, but this doesn't imply that we need these tags to be the first thing that the reader sees on the page. Things can still get better even if the orphan tag is moved to the bottom and made small like a {{stub}} tag, or moved to the talk page, or turned into a hidden maintenance category. WhatamIdoing (talk) 18:29, 23 December 2013 (UTC)
- Comment I'm more likely to attempt to deorphan an article if I see the tag. Moving the tag to the talk page makes it less likely that I'll see it, which means I'm less likely to attempt deorphaning. GoingBatty (talk) 19:32, 23 December 2013 (UTC)
- Note that the broader consensus of the previous discussion was to move it somewhere other than at the top of the article where it breaks article layout and is the first thing that the readers see. It doesn't necessarily have to be the talk page. A hidden category on the same page or somewhere at the bottom like
{{Uncategorized}}
or{{Stub}}
were all proposed as alternatives. All of those are functionally fine, and editors have no problem sorting through them and fixing them.-- OBSIDIAN†SOUL 01:52, 24 December 2013 (UTC)
- Note that the broader consensus of the previous discussion was to move it somewhere other than at the top of the article where it breaks article layout and is the first thing that the readers see. It doesn't necessarily have to be the talk page. A hidden category on the same page or somewhere at the bottom like
- Comment if we switch the minimum links to deorphan from 3 to 2 I believe many pages will be detagged with us making no extra effort. -- Magioladitis (talk) 22:32, 31 December 2013 (UTC)
- Oppose Compare Wikipedia:WikiProject Medicine/RFC on medical disclaimer. The current orphan banner is absurdly WP:UNDUE when compared to our disclaimers which are buried at the foot of the page. I'm not too fussy how it is made inconspicuous but if I can still see it then it's going onto the talk page. Andrew (talk) 19:14, 3 January 2014 (UTC)
- Move for an immediate close of this RfC as it is disruptive (see below) -- PBS (talk) 12:50, 6 January 2014 (UTC)
- Oppose. The only argument I see here with any level of merit is the fact that some of our automated tools would require recoding. That, however, is not a justifiable reason to overturn the original consensus. It would set a very dangerous precedent to accept that consensus should be set aside for the convenience of the people who maintain the tools. As to the original comment: 1. "Past proposals failed, therefore we should treat this one as failed even though it succeeded." Uhh, no. 2. Citation needed. 3. Agreed, but I've seen no evidence that the existence of orphan tags causes people to clear them on any noticeable scale. Especially from new editors. 4. Appeal to emotion that fails to rebut the original consensus. 5. "Every time there was some effort to reduce the list we had results" - implies that some editors have dedicated some time to dealing with the issue. I commend and thank these editors, but I also know they weren't finding orphaned articles by hitting "Random Article". Ergo, the existence of the Orphan template in mainspace is not driving reduction efforts. Resolute 14:49, 6 January 2014 (UTC)
Oppose overturning the recent RfC. The proposer's arguments don't convince me. Argument 1, that the Orphan tag is like other tags, isn't true: it's not. Argument 2, that the Orphan tag is particularly good, or even any good, at getting readers into editing, is arguable. My guess is that it's probably mostly not true, but nobody knows for sure. Arguments 3, 4, and 5 are all addressed by having the tag continue to exist, but on the talk page. Against that is the argument that won the day at the original RfC: it's a big honken ugly thing that degrades the article's appearance, degrades the reader's experience, and warns the reader of nothing useful, all for little benefit. However, I'm all for a clean RfC on the question of whether the tag should appear on the talk page or just be invisible altogether. Herostratus (talk) 21:32, 6 January 2014 (UTC)
Here's an idea: Why don't we just delete the template and turn it into a hidden category. I do agree that the template itself can incite panic in new users, but moving it to the talk page helps no one if you can't see it. If you want to do maintenance in this category under the above proposal, you either have to be a user with a sophisticated understanding of how categories work (surprisingly, this is less common than most people think), or you give up because you have no idea where the template went. How about we just delete the template itself and replace it with hidden categories, so that way it can be seen on the user page, and we won't have a maintenance template appearing on a talk page. Kevin Rutherford (talk) 07:11, 24 December 2013 (UTC)
- I have no problems with that. A fair amount (most?) of deorphanings are done naturally over time as more articles are created that start linking to them anyway.-- OBSIDIAN†SOUL 05:23, 25 December 2013 (UTC)
- This makes sense to me. Putting the tag on the talkpage makes even less sense than putting it on the article page. Like others, I have also tried to de-orphan an article on seeing that tag. After all, I want to help. But it's a difficult and frustrating task that leaves me dissatisfied. As a temptation to turn readers into editors it is more likely to achieve the opposite. A reader taking up the challenge would equally find it difficult and frustrating, and from that experience may decide not to bother editing Wikipedia again. May even spread the bad news among friends and colleagues: "I tried to help out on Wikipedia once. Wasted an hour of my life and achieved nothing. Editing Wikipedia is for weird geeks who don't have a life". SilkTork ✔Tea time 16:05, 3 January 2014 (UTC)
- I agree, this solution is brilliant, is inline with the perennial concensus about maintenance tags on the talk page, and should be acceptable to all sides. I can think of no reason not to do this. --NickPenguin(contribs) 19:27, 3 January 2014 (UTC)
Support. 90+% of de-orphaning work is done through scripts and bots these days. There is no reason for a glaring notice at the top of each page, especially when at least half of these articles are impossible to de-orphan. Kaldari (talk) 08:10, 4 January 2014 (UTC)- @Kaldari: I'm aware of bots that remove {{orphan}} from articles that have already been de-orphaned. Could you please give an example of a bot that actually does the de-orphaning work? Thanks! GoingBatty (talk) 00:27, 5 January 2014 (UTC)
- I guess I was thinking of the bots that remove the tag. It looks like you're correct that these don't actually perform the de-orphaning. Oh well, guess you can ignore my comment then :) Kaldari (talk) 00:41, 5 January 2014 (UTC)
- I wonder how much of the de-orphaning is done by people using the "suggestions may be available" script that's is linked in the template that we're now hiding.... GoingBatty (talk) 01:22, 5 January 2014 (UTC)
- I guess I was thinking of the bots that remove the tag. It looks like you're correct that these don't actually perform the de-orphaning. Oh well, guess you can ignore my comment then :) Kaldari (talk) 00:41, 5 January 2014 (UTC)
- @Kaldari: I'm aware of bots that remove {{orphan}} from articles that have already been de-orphaned. Could you please give an example of a bot that actually does the de-orphaning work? Thanks! GoingBatty (talk) 00:27, 5 January 2014 (UTC)
- I agree, this solution is brilliant, is inline with the perennial concensus about maintenance tags on the talk page, and should be acceptable to all sides. I can think of no reason not to do this. --NickPenguin(contribs) 19:27, 3 January 2014 (UTC)
Alternate idea?
Moving the orphan tag is an inelegant and needlessly complicated process upon which the validation and ultimate removal becomes unworkable. An alternate and better option is to remove the banner portion of the template and make it function like Template:Coord missing. The end result allows direct and no-mess tagging of orphaned articles and resolves the issue of those supporting the talk page move. I personally did not know about the RFC or would have commented - others have come to the same conclusion, but were also unaware. I believe that this resolves both parties issues with a more optimal solution in terms of those who place, check and remove the tags. To put it bluntly: The tag is gone from view and the banner won't choke the talk page where validating and removing won't occur. ChrisGualtieri (talk) 06:03, 28 December 2013 (UTC)
- Question: With your suggestion, would {{orphan}} still reside within {{multiple issues}}, or be moved somewhere else? If moved, where would it reside? Thanks! GoingBatty (talk) 06:13, 28 December 2013 (UTC)
- It would no longer be a banner, the most simple solution is to make it a hidden category and that would mean it would no longer be in {{multiple issues}} unless specifically requested. At this time, I think making it completely hidden is justified given the RFC, it would still be functional and check-able like any other tracking category. ChrisGualtieri (talk) 06:24, 28 December 2013 (UTC)
- I understand that the solution proposed here is to remove the visible banner. My question relates to the code that editors use. If it would no longer be in {{multiple issues}} unless specifically requested (by whom?), where should editors add {{orphan}} in the page layout in the future? GoingBatty (talk) 18:16, 2 January 2014 (UTC)
- It would no longer be a banner, the most simple solution is to make it a hidden category and that would mean it would no longer be in {{multiple issues}} unless specifically requested. At this time, I think making it completely hidden is justified given the RFC, it would still be functional and check-able like any other tracking category. ChrisGualtieri (talk) 06:24, 28 December 2013 (UTC)
- I would prefer to have the banner hidden if only tag on the page, otherwise it should be inside the multiple issues and display a one line note. this is very technically feasible and seems like common sense to me. Technical 13 (talk) 21:50, 28 December 2013 (UTC)
- Technical 13, I like this idea. -- Magioladitis (talk) 22:35, 31 December 2013 (UTC)
- This idea also sounds good to me. Ramaksoud2000 (Talk to me) 06:47, 1 January 2014 (UTC)
- Piling on to say that I like the sound of this. Novusuna talk 07:58, 1 January 2014 (UTC)
- This is a great idea. I'll reiterate that the original proposal to move Orphan Tags to the Talk Page is a bad, bad idea. While we're at it, are there any other maintenance tags—that are not needed to be announced to every reader—that should be considered as well? (May help cleanup the article pages somewhat.) Just a thought. GenQuest "Talk to Me" 08:17, 1 January 2014 (UTC)
- Support this, which I feel doesn't violate the spirit of the original consensus. Sorry these great technical minds were late to join the party (better late than never!), the idea that the orphan patrol can use a custom MyPage skin to still see the template is the missing piece to the puzzle that should keep it easy for the orphan patrol to still use Find link and make everyone happy (except those who want to encourage readers to become editors by fixing orphans, but that ship has already sailed). – Wbm1058 (talk) 21:34, 2 January 2014 (UTC)
- Okay then... What I am thinking is to wrap the meta "issues" template (haven't dug in to see what it is yet) in a span with an id of whatever the calling issue is (in this case id="orphan"). The next step is to add a style="display: none;" to the span conditionally based on if:
{{{hidden}}}
|true. This will give us the option to add|hidden=true
to the orphan template (or whatever other templates we deem it would be appropriate to hide by default) which will hide it from normal view and those users that still want to see that notice can simply add some code to their common.css or skin.css like#orphan{display: inherit !important;}
which will override the fact that the tag is hidden for that specific user. Everyone okay with this? Technical 13 (talk) 23:16, 1 January 2014 (UTC)
- Okay then... What I am thinking is to wrap the meta "issues" template (haven't dug in to see what it is yet) in a span with an id of whatever the calling issue is (in this case id="orphan"). The next step is to add a style="display: none;" to the span conditionally based on if:
Okay, based on Mr. Stradivarius's suggestions, I've made some changes to {{Orphan/sandbox}} with examples on the testcases page. If no-one sees anything I missed there, this will be moved live in about three days. For those that wish to override the hidden nature, all you need to do is add the following to your common.css or skin.css:
.orphan{
display: inherit !important;
}
I hope this satisfies what everyone wants without having to make a mess out of trying to move it to the talk page. Technical 13 (talk) 13:50, 2 January 2014 (UTC)
- If I recall chances to templates with a large set of transclusions won't pull through the changes until the update pass has happened or an edit (Even a null edit) has occured on the page. Therefore I'd like to suggest that a null edit bot be attached and set free over the Category:Orphaned articles category and it's children so that the nag disappears sooner rather than later. Hasteur (talk) 14:36, 2 January 2014 (UTC)
- It would still get run through the job queue like any other change, but that could in fact take weeks depending on how far down the queue it is. I wouldn't oppose a null bot running through the list, perhaps a ping to Joe Decker for his insight on running his Joe's Null Bot through it (yes, I know you can make a null bot for it too Hasteur, just getting another opinion on it.)? Technical 13 (talk) 14:54, 2 January 2014 (UTC)
- It appears that this solution would take care of articles that use the {{orphan}} template. Would this solution mean that we also need to convert any {{multiple issues}} templates with the old
|orphan=
parameter to the {{orphan}} template (and potentially relocate it to another part of the article)? Thanks! GoingBatty (talk) 18:16, 2 January 2014 (UTC)- Absolutely. It would be helpful if there was an approved bot like BattyBot task 26 to accomplish this. Technical 13 (talk) 19:19, 2 January 2014 (UTC)
- @GoingBatty: I though the consensus was to leave the Orphan template in the multiple issues wrapper so that if there were multiple issues, we'd draw attention to it. i.e. Not the primary cause for failure, but contributing to the failure. Hasteur (talk) 19:52, 2 January 2014 (UTC)
- @Hasteur: I'm not sure what the consensus is, so I'm asking. Note that I've updated Template:Orphan/testcases to show the difference between how the proposed {{orphan}} template does NOT appear within {{multiple issues}}, but the old style
|orphan=
still will. GoingBatty (talk) 20:02, 2 January 2014 (UTC) - @Technical 13: BattyBot 19 was approved to change the old style parameters to the new style ONLY when the old style was not displayed properly. GoingBatty (talk) 20:02, 2 January 2014 (UTC)
- @GoingBatty: I read the consensus proposed at 21:50, 28 December 2013 by Technical 13, and then endorsed and agreed to below that post. Personally, I like that methodology myself. Hasteur (talk) 20:09, 2 January 2014 (UTC)
- {{Multiple issues}} is one of those templates that is way overcomplicated and I have had the time to sort through and figure out how it works internally yet. Perhaps Theopolisme (who has written a Lua version of the template) or Mr. Stradivarius can help figure out why it doesn't show inside of Multiple issues? Technical 13 (talk) 21:28, 2 January 2014 (UTC)
- @Technical 13: In general, when an template is inside {{multiple issues}}, it displays the first sentence of the template text. Getting {{orphan}} to show nothing when on its own but a sentence when inside {{multiple issues}} will be new functionality. GoingBatty (talk) 23:34, 2 January 2014 (UTC)
- See Template talk:Orphan#Is it possible to have the functionality provided in the Toolbox? for a description of how {{orphan}} behaves inside {{multiple issues}}, where a shorter message is displayed. Wbm1058 (talk) 00:28, 3 January 2014 (UTC)
- @Technical 13: In general, when an template is inside {{multiple issues}}, it displays the first sentence of the template text. Getting {{orphan}} to show nothing when on its own but a sentence when inside {{multiple issues}} will be new functionality. GoingBatty (talk) 23:34, 2 January 2014 (UTC)
- @Hasteur: I'm not sure what the consensus is, so I'm asking. Note that I've updated Template:Orphan/testcases to show the difference between how the proposed {{orphan}} template does NOT appear within {{multiple issues}}, but the old style
- It appears that this solution would take care of articles that use the {{orphan}} template. Would this solution mean that we also need to convert any {{multiple issues}} templates with the old
- It would still get run through the job queue like any other change, but that could in fact take weeks depending on how far down the queue it is. I wouldn't oppose a null bot running through the list, perhaps a ping to Joe Decker for his insight on running his Joe's Null Bot through it (yes, I know you can make a null bot for it too Hasteur, just getting another opinion on it.)? Technical 13 (talk) 14:54, 2 January 2014 (UTC)
Looking at this more closely, it looks like we might need a new rule in MediaWiki:Common.css to make this work. The current {{multiple issues}} magic happens by using the class hide-when-compact
in all {{ambox}} text fields except |issue=
. This class is defined in common.css. However, to do what is being proposed here we would need to do the opposite, i.e. show text only when it is compact. Perhaps propose this on MediaWiki talk:Common.css? — Mr. Stradivarius ♪ talk ♪ 03:42, 3 January 2014 (UTC)
- And interesting technical point, if this is a barrier to its implementation then perhaps its resolution will result in a net positive because it could be extended to more or less the same type of tags in the future. This is definitely a more complex way to resolve the problem, but it does stand to be better than merely hiding it altogether - hide when compact is that functionality that seems like a great idea. ChrisGualtieri (talk) 13:42, 6 January 2014 (UTC)
- So far I see no discussion about this at MediaWiki talk:Common.css. Given that the wolves are demanding action and not foot-dragging, and the idea of keeping the message visible inside the {{multiple issues}} wrapper is the piece of this that might still be contentious and arguably against the spirit of the earlier consensus, can we just implement the solution that always hides the message? We can always revisit making it visible inside the wrapper later. Only downside I see is if there are only two issues, readers will just see one, leaving them wondering, "so what's the other issue?" - Wbm1058 (talk) 18:18, 6 January 2014 (UTC)
- Question. What's wrong with having the tag on the talk page? I haven't seen any compelling argument to that effect, except that it uglifies the talk page (so what, since it's useful) and that no one will see it (but even fewer people see it if it's not there, right?). Putting the page in a hidden category and also tagging the talk page would be OK with me, though. As to the original statement of this section, I actually can't even figure out what it means. "Moving the orphan tag is an inelegant and needlessly complicated process upon which the validation and ultimate removal becomes unworkable." Sorry, but what?. It looks like the sentence is talking about the actual process of moving the tags, which is relatively trivial I assume and I don't understand why it would be impossible to validate that this had been done properly? Herostratus (talk) 21:48, 6 January 2014 (UTC)
- To answer your question, all of the tools and applications that editors currently use to place the tag are unable to place the tag on the talk page (it would take a LOT of coding to be able to edit two pages instead of one for this, and is technically infeasible). This means that requiring this tag to be on the talk page instead of just hidden is essentially forcing the tag into deletion which was strongly against consensus in the discussion. Technical 13 (talk) 22:02, 6 January 2014 (UTC)
- Oh. Well, in that case, hmmmm. This seems odd to to me, since there are templates on talk page -- lots of them. So there must me some way place to templates there. I mean, it seems like an elementary thing -- you already know the name of the page, and the name of the talk page is very similar, the variance following a regular pattern. And I think it's possible to write to a page you're not editing, since various actions do that -- for instance, putting a speedy tag on a page (with Twinkle) writes a message to a user talk page. Are you sure you've drilled all the way down on this?
- But if it's the case that this can't be done, it is what it is and we have to move forward from there. I'd be leery of being driven too much by the technology. Heck, the tools are just conveniences). I put tons of templates on pages by hand for years. It's not that hard, so I wouldn't worry about it too much. There are tables to look these things up and it's a simple copy-and-paste operation. And anyway if these tools are that limited in how they can be configured to meet our needs, another good reason for not paying them too much mind.
- Again, if the case can be made and accepted that the Orphan tag ought not be on talk pages, that's different. But I haven't seen that case made very well.
- So I think we need to talk and think about this some more. One thing that comes to mind right off is allow the tools to operate as they do and just run [Wikipedia:Bots/Requests for approval/Yobot 23 Yobot 23] regularly; that'd solve the problem I guess. But this might degrade system performance, don't know. Another would be have the tools place the article in a hidden category, and have (as a separate thing) the visible Orphan tag remain as a talk page to be added by hand, if it really can't be automated. Probably there are other ways to deal with this.
- There's no hurry. It might be good to run a clean RfC with the two best options presented as binary choice, but I don't think we're there yet. Herostratus (talk) 01:07, 7 January 2014 (UTC)
- Your comparison is in the right direction, but for the wrong reason. When you put a speedy tag on a talk page to notify the user who created, you are doing a task with a very specific purpose. This is a notification and its a one-shot. The orphan tag on a page needs to meet a certain criteria to be applied (checked by AWB and some other tools including the AFC helper script). The article itself is checked, and if it was forced on the talk page, the talk page would receive the tag. This, by itself, is not too helpful, but possible. The real issue comes in knowing when the issue has been resolved - an AWB or other person who goes to the page will automatically check and remove the tag in the process of doing any other task. This will not be done if its on the talk page and to load up the talk page and load up the article to check would be a much more confusing and complex operation that is technically infeasible and inefficient. Completely hiding or having its concealment for editors who do not "opt in" is a great option, because it allows those who use the tools and do the tasks to resolve the orphan tag issue without loading up the talk page and flipping back, confirming on the article and re-loading the talk page to do the task. Or the other option would be load the talk page to check for the orphan and then the article itself, just to resolve this one issue... it creates more problems than it resolves and Coord missing is something with the exact same functionality and is a precedent that works. This is demonstrated and functional and it resolves the main issue - I don't think such an objection to forcing the talk pages to take the banner represents a net positive. ChrisGualtieri (talk) 18:29, 7 January 2014 (UTC)
- There's no hurry. It might be good to run a clean RfC with the two best options presented as binary choice, but I don't think we're there yet. Herostratus (talk) 01:07, 7 January 2014 (UTC)
This rfC is disruptive
The RfC that is now archived Wikipedia:Village pump (proposals)/Archive 108#Proposal to move the Orphan tags to the talk page, came to a clear consensus which was summed up by the closing admin. The alternative options being discussed here were discussed at the time and did not gain a consensus. To start another RfC over this issue so soon after a consensus was reached is disruptive. -- PBS (talk)
- PBS, unfortunately the closing consensus of that RfC was disruptive as it technically broke multiple tools and therefore has been re-discussed and consensus seems to have changed. Have a nice day. Technical 13 (talk) 13:33, 6 January 2014 (UTC)
- Considering multiple people called for it be hidden or given reduced notice in the original RFC, this is actually addressing the very concerns that were not fully explored. It became clear when preparing to do the actual letter of the consensus that it was infeasible for many more reasons. The spirit of it is being preserved and it will accomplish the original intended result in a far better way than discussed in the original RFC. ChrisGualtieri (talk) 13:47, 6 January 2014 (UTC)
- It is quite feasible to implement it as the consensus dictated. Which concerns were "not fully explored"? "actual letter of the consensus that it was infeasible for many more reasons" what are those reasons? -- PBS (talk) 14:19, 6 January 2014 (UTC)
- If you read the later comments closely, most support the removing of the banner, but ambivalent as to where it ends up, either category only on bottom of the article or on the talk page. My comment of "Oppose the move to talk page, Support hiding it away someway. From many years of doing maintenance backlog and tracking some of the progress, very little maintenance happens by drive by editors. Almost all happens by project or individual drives to clean out a cleanup cat. Whatever we do, the category must remain on the page, so that tools like the svick tool pick them up and catscan can be used to sort them. Moving the tag to the talk page just adds an unnecessary complexity to the sorting tasks - and will be a big task to do, compared to simply changing the contents of the {{orphan}} template. The-Pope (talk) 07:36, 30 November 2013 (UTC)" was supported by the RFC originator, but coming two weeks into the voting period, I doubt many others would have read it (TL:DR). If there are real technical issues with doing a move, rather than a template appearance change, then it is very valid to revisit it with the current knowledge. The-Pope (talk) 16:12, 6 January 2014 (UTC)
- For the record, I'm the closer of that discussion (I'm not an admin by the way) and I support this alternative idea, it even cropped up in the first discussion, but it came too late, and there wasn't a consensus at the time. Ramaksoud2000 (Talk to me) 22:32, 6 January 2014 (UTC)
I agree that technical means to hide the orphan tag on the main page would satisfy the spirit of the consensus. Our process isn't a legislative one, and closures are not usually meant to be literally binding except in extreme cases. PBS, if you have good reasons to prefer the original solution, you should just raise those for everyone to consider, rather than raising a procedural objection. Gigs (talk) 17:03, 6 January 2014 (UTC)
"The alternative options being discussed here were discussed at the time"
is not true. The currently favored solution to hide the template message, but to allow overriding the hidden nature by adding specific text to your common.css or skin.css (anyone on orphan patrol will want to do this) is a key idea that was not brought up in the original discussion and will make the largest possible number of editors happy. To suggest otherwise is to imply that consensus would want to move {{coord missing}} to the talk page because editors, not readers, find it disruptive. Wbm1058 (talk) 17:51, 6 January 2014 (UTC)
It's not disruptive IMO. If you look at the previous RfC, the concern of most all of the commentors was getting the ugly thing off the article pages. The idea that having it on the talk page as a positive good did not really come into play. So this is a refinement that's reasonable to discuss. Herostratus (talk) 21:39, 6 January 2014 (UTC)
- OK, I see some concern from editors who (1) don't want to see anything on the article page, (2) want to help with de-orphaning, (3) don't want to install the custom skin that would show them the template message, so (4) need to be able to see the message on the talk page, so they can help de-orphan. Sorry, I'm dubious about the idea that tagging the talk pages will increase de-orphaning, but this issue is easily solved by just asking the bot that was going to move tags to the talk page to copy them there instead, where they could display a talk page version of the message and would not be categorized. – Wbm1058 (talk) 22:18, 6 January 2014 (UTC)
- This bot would need to run on a regular basis to pick up the new ones. Wbm1058 (talk) 22:24, 6 January 2014 (UTC)
- I would be opposed to replicating the tag on talk pages as redundant, disruptive, and unecessary. I would be more than happy to make a simple script that those people could import into their css/js in addition to it also placing the pages in a category that they could use to find orphans. I'm still working on the technical aspects of hiding the template and making it show in multiple issues... I'll work on it at the end of the week as I have a final in sociology to get done this week (a really weak subject for me). Technical 13 (talk) 23:12, 6 January 2014 (UTC)
- I agree with you, T-13. I neglected to mention above that such theoretical editors wanting to fix orphans also refuse to check Category:Orphaned articles as that's too much bother, as well as opting in to see the message is too much bother. But, somehow, checking the talk page isn't too much bother, in spite of the fact that after checking the talk page they will need to return to the article to run "what links here" and they won't be taking advantage of the tool that's built into the visible template unless they go out of their way to do so. And we are supposed to assume that such theoretical editors are so numerous as to outweigh the burden on those using the cat, opting in to see the template, using the tools... having to make a special trip to edit the talk page to remove the template, which is totally unnecessary except to fulfill the needs of theoretical editors. Sorry if I'm sounding harsh, but I'm a little annoyed that this argument continues. Wbm1058 (talk) 19:17, 7 January 2014 (UTC)
- The issue is not "theoretical editors", but simply the common practice that the eventual resolution without tag removal is not a small minority. I often remove orphan tags with AWB and I also PLACE them with AWB. Moving it to the talk page means I'd have to stop and load up the talk page to place it (a function AWB does not have) and I'd have to check the talk page to see if I could remove the orphan tag (assuming one needs to). I'll run a operation this weekend (its been awhile since I last did the task) and show why the technical matter warrants this. It has never been about checking a category - it is part of the upkeep and maintenance of Wikipedia itself. The matter of "seeing" the tag has been secondary to me because I need the actual ability to detect, check and remove the tag all at once. And the result of moving it to the talk page splits the detect, check and removal up in two minimum edits and results in lots of needless reloading and processing. ChrisGualtieri (talk) 17:14, 8 January 2014 (UTC)
- I would be opposed to replicating the tag on talk pages as redundant, disruptive, and unecessary. I would be more than happy to make a simple script that those people could import into their css/js in addition to it also placing the pages in a category that they could use to find orphans. I'm still working on the technical aspects of hiding the template and making it show in multiple issues... I'll work on it at the end of the week as I have a final in sociology to get done this week (a really weak subject for me). Technical 13 (talk) 23:12, 6 January 2014 (UTC)
What portals, if any, are appropriate at Prometheus (2012 film)?
Previous discussions on this matter did not take place on the article talk page. Instead, they took place here:
- Wikipedia_talk:WikiProject_Film/Archive_46#Use_of_Portals_in_film_articles
- Wikipedia_talk:WikiProject_Film#Cross_WikiProject_relations_and_decisions_about_portals
- Wikipedia_talk:WikiProject_Portals#Questioning the need of portals when categories exist
What portals, if any, are appropriate at Prometheus (2012 film)? There are four opinions I have found in the archives that pertain to this film, so they can be thought of as four proposals: 5 portals, no (0) portals, no more than the number of relevant portals belonging to three WikiProjects, and 5 portals (with one being different than the first).
- Proposal A: I had included the following portals see diff:
- 2010s - Decade that the film was released
- Film - General portal on film (I had mistakenly added this portal twice in the diff)
- Film in the United States - Since some production companies are from the United States
- United Kingdom - Since other production companies are British
- Science fiction - Genre
- Proposal B: User:Darkwarriorblake argued that no portals are appropriate, and removed the portals I had added. Diff #1, Diff #2 which removed remaining portals - As of writing Prometheus_(2012_film) has no portals.
- Proposal C: User:Betty Logan stated at Wikipedia_talk:WikiProject_Film/Archive_46#Use_of_Portals_in_film_articles (Diff): "The Film portal is listed twice at Prometheus! For what it's worth though, I don't think portals belonging to other projects should be installed on articles that do not come within their scope. Prometheus belongs to the Film, Alien and Science Fiction projects, so at the most should only have portals belonging to those projects." (Note: the film portal listed twice was a mistake of mine) WhisperToMe (talk) 01:51, 29 December 2013 (UTC)
- Proposal D: User:Nihonjoe argued (See diff): "Apparently at least one person thought that was excessive. I added the Alien portal to the Alien footer template on that page (which is where it belongs). I think the 2010s portal might have been a little excessive, but the others seemed fine. It isn't unusual for some articles to contain multiple portal links. Certainly, Film in the United States, Science fiction (which actually redirects to the science fiction section of the Speculative fiction portal), and (what should have been, if it actually existed) Film in the United Kingdom are not just tangentially related, as Darkwarriorblake implied with his removal of the portals." - What "that" means is the number of portals I mentioned in the first "proposal"
So what portals are appropriate for this article? Which proposal should be selected? Or should another one be used? WhisperToMe (talk) 01:41, 29 December 2013 (UTC)
- What, if any, portals are appropriate. I know you didn't mean to make your question clearly leading. There is an ongoing discussion at the above links and I believe this new one to be an example of canvassing and forum shopping for support. As of writing, Prometheus has no portals, portals are not a requirement of articles, it isn't a requirement of getting to GA or FA status either which Prometheus has done. We have interwiki links, more specific and directly related categories, and nav templates, which makes most portals, including the ones that were added, redundant, and the others have no link to the film and can offer a reader no insight at all or further reading on the immediate topic at hand. But discussion should continue at the above 2nd link where it started, instead of now the third or fourth place WhisperToMe has opened this debate. Darkwarriorblake (talk) 02:03, 29 December 2013 (UTC)
- Please review Wikipedia:Canvassing. It is acceptable to notify other editors of a discussion as long as it isn't set particularly to any one side ("In general, it is perfectly acceptable to notify other editors of ongoing discussions, provided that it is done with the intent to improve the quality of the discussion by broadening participation to more fully achieve consensus." (emphasis mine)). What under the heading "Inappropriate notification" has happened in this instance? Also there is a parallel discussion of Should the WikiProject Film have the authority to say no articles in its jurisdiction should have portals or Should WikiProject Film entirely control the use of Portal:Film, prohibiting it from articles at the WikiProject members' say (My impression seems to be that different members have different ideas). WhisperToMe (talk) 02:10, 29 December 2013 (UTC)
- By the way, blake, one thing I did do was make clear above that one proposal calls for zero (0) portals. WhisperToMe (talk) 04:05, 29 December 2013 (UTC)
- Also I altered the title of this proposal and leading question to add "if any," making it clear zero (0) is an option for this article. WhisperToMe (talk) 04:40, 29 December 2013 (UTC)
- Talk about portal spam. Keep to the most relevant portals, Films and Science Fiction. Any more than that, it would be excessive. If you add Films in the United States, then you should remove the Films link. Links to the decade portals should never be in an article unless the article itself is about the decade. (ex. 2010 in film) 24.149.119.20 (talk) 12:12, 30 December 2013 (UTC)
- Comment: Honestly I'm fine with omitting Film since there would be "Film in the United States". However keep in mind pop culture products and current events are associated with decades. Beavis and Butt-head after all is associated with the 1990s. ThunderCats (1985 TV series) is associated with the 1980s. Restricting decades to decade portals would not match the public perception of "decade nostalgia" which associates specific shows/films/etc produced in a particular decade with that decade. Remember that some articles simply are associated with multiple topics and multiple genres. I agree that the set of portals should be condensed as much as possible compared to the number of WikiProjects. Compare Talk:World War II to World_War_II#See also because a dedicated portal was made specifically for World War II. The more specific portals made, the fewer portals needed for each article and the more relevant each one is. Also, I added UK because it is not strictly an American film but a co-production. Some topics are more complex than others. However I'm happy to start a Portal:Film in the United Kingdom to cut around that issue. WhisperToMe (talk) 19:58, 30 December 2013 (UTC)
- My general statement on what portals to include is "If it would be reasonable for the article to be used as a 'selected article' in the portal, it is reasonable to link to that portal in the article". I think that this would work as an entry in Portal:Alien, but the film probably isn't notable enough to be selected for inclusion in Alien's parent portals, Portal:Speculative fiction and Portal:Horror fiction. I also think that the film would work in Portal:Film in the United States, but again, robably isn't notable enough to be selected for inclusion in the parent portal, Portal:Film. I would not include it in the decade portal, myself, although those are rather poorly defined right now. Sven Manguard Wha? 22:23, 30 December 2013 (UTC)
- I created the decade portals myself but the idea comes from the French Wikipedia, where they've been established. I think the concept behind those decade ones is to match the public's perception of how culture and events transpire within a decade and the "decade nostalgia" that comes with them. A film/novel/television show from a decade could be seen as a "product" of that decade so I can see it as a "selected article" of that decade portal. WhisperToMe (talk) 00:07, 31 December 2013 (UTC)
- If there is no further comment here, within 7 days I would like to re-establish only the Film in the United States portal and Alien (as Alien is deemed a more specific portal) though I would be happy to write a portal for Film in the United Kingdom for this article. Also I would like to explain the importance of the decade portals so the Wikipedia community understands why I believe they should be widely used. WhisperToMe (talk) 12:53, 3 January 2014 (UTC)
- I created the decade portals myself but the idea comes from the French Wikipedia, where they've been established. I think the concept behind those decade ones is to match the public's perception of how culture and events transpire within a decade and the "decade nostalgia" that comes with them. A film/novel/television show from a decade could be seen as a "product" of that decade so I can see it as a "selected article" of that decade portal. WhisperToMe (talk) 00:07, 31 December 2013 (UTC)
VE on Wikipedia: namespace
Can we enable Visual Editor on Wikipedia: namespace? --Rezonansowy (talk • contribs) 17:29, 1 January 2014 (UTC)
- It is technically possible, if people want to do it. However, VisualEditor doesn't know how to sign posts, which means that it would not be especially useful for a page like this. Whatamidoing (WMF) (talk) 19:25, 1 January 2014 (UTC)
- Wikipedia pages don't cover only talk, they contains many article-like pages, that's why I think it will be a good idea. --Rezonansowy (talk • contribs) 13:14, 2 January 2014 (UTC)
- Does anyone else have an opinion on this? Whatamidoing (WMF) (talk) 21:34, 2 January 2014 (UTC)
- To the extent that the main focus of VE is to encourage new, inexperienced editors to contribute to article space, I don't see the point. If some experienced editors would find it useful, and we can avoid the previous main-space issues, then maybe. We don't really want newbies making many edits in WP: space, do we? Wbm1058 (talk) 21:47, 2 January 2014 (UTC)
- But WP:Draft namespace is another story. That could be the perfect place to beta test VE! Wbm1058 (talk) 21:51, 2 January 2014 (UTC)
- If a new user has something worthwhile to say in the Wikipedia: namespace, they should go right ahead and do it. To me, the problem with enabling VE in WP space is that it's a mixture of article-style and talk-style pages, and VE just can't handle signatures yet. As for Draft: namespace, VE appears to already be enabled (as it should be in my opinion). Novusuna talk 22:02, 2 January 2014 (UTC)
- But to use VE, even in Draft: namespace, I need to enable it in my user preferences. I'm suggesting, as was controversially implemented last summer, that this is the one namespace where the WMF might be able to get consensus for enabling VE to be the default editor. – Wbm1058 (talk) 22:26, 2 January 2014 (UTC)
- So, what now? --Rezonansowy (talk • contribs) 20:03, 3 January 2014 (UTC)
- At this time, it is not technically possible to do this. However, I can write up the request at Bugzilla, if people want to do it, and we could see whether they would make it possible. Whatamidoing (WMF) (talk) 23:26, 3 January 2014 (UTC)
- Whatamidoing (WMF), I'd appreciate it if you could create a bug to track the issues relevant to enabling it in the Draft namespace. I suspect bugzilla:50172 is one of the problems. John Vandenberg (chat) 11:08, 8 January 2014 (UTC)
- I created Template:Bug for you. I haven't yet found anything else that needed to be added to it. Whatamidoing (WMF) (talk) 22:05, 9 January 2014 (UTC)
- Whatamidoing (WMF), I'd appreciate it if you could create a bug to track the issues relevant to enabling it in the Draft namespace. I suspect bugzilla:50172 is one of the problems. John Vandenberg (chat) 11:08, 8 January 2014 (UTC)
- At this time, it is not technically possible to do this. However, I can write up the request at Bugzilla, if people want to do it, and we could see whether they would make it possible. Whatamidoing (WMF) (talk) 23:26, 3 January 2014 (UTC)
- So, what now? --Rezonansowy (talk • contribs) 20:03, 3 January 2014 (UTC)
- But to use VE, even in Draft: namespace, I need to enable it in my user preferences. I'm suggesting, as was controversially implemented last summer, that this is the one namespace where the WMF might be able to get consensus for enabling VE to be the default editor. – Wbm1058 (talk) 22:26, 2 January 2014 (UTC)
- If a new user has something worthwhile to say in the Wikipedia: namespace, they should go right ahead and do it. To me, the problem with enabling VE in WP space is that it's a mixture of article-style and talk-style pages, and VE just can't handle signatures yet. As for Draft: namespace, VE appears to already be enabled (as it should be in my opinion). Novusuna talk 22:02, 2 January 2014 (UTC)
- My opinion is that Visual Editor should be abandoned and certainly not made the default for any aspect of English Wikipedia anywhere. You did ask. Carrite (talk) 03:04, 4 January 2014 (UTC)
- And why would it be so? TheOriginalSoni (talk) 03:17, 4 January 2014 (UTC)
- Carrite, The power of Wikipedia is that you have always choice. You can use VE or edit the code, or even switch from VE editing to code directly. That's a power of the community project, nobody decides for you what you're using. --Rezonansowy (talk • contribs) 10:21, 4 January 2014 (UTC)
- Does anyone else have an opinion on this? Whatamidoing (WMF) (talk) 21:34, 2 January 2014 (UTC)
- Wikipedia pages don't cover only talk, they contains many article-like pages, that's why I think it will be a good idea. --Rezonansowy (talk • contribs) 13:14, 2 January 2014 (UTC)
Not only does VE not allow signatures to be added (bugzilla:51154/bugzilla:51899), it also corrupts existing ones (bugzilla:59229). It also can't efficiently edit sections (bugzilla:48429). There is an enhancement request to allow VE to be enabled on specific pages (bugzilla:50883), for example a sandbox in project space. I have started a tracking bug for related issues. See bugzilla:59818 John Vandenberg (chat) 11:05, 8 January 2014 (UTC)
Make it clear when there is no change to articles in your watchlist, compared to a zero byte length change
The watchlist is currently clever enough to show (10 changes | history) . . (+505)
when there are multiple changes, and (diff | hist) . . (-2)
when there is only one. However, when you have a (4 changes | history) . . (0)
you don't know if it's a edit then a reversion to the original version, or a real change without any change to the article length (ie changing a date of birth from 1980 to 1940 or the name from John to Bill etc). You then have to do a diff check or popup/hover to see what, if anything, has actually changed. Could the watchlist be made smarter to show something like (4 edits, no net change | history) . . (0)
when the current version is exactly the same as the original version? That would then make it very clear which article changes can be safely ignored. The-Pope (talk) 14:21, 4 January 2014 (UTC)
- My watchlist doesn't do this. What gadget are you running? WhatamIdoing (talk) 15:52, 4 January 2014 (UTC)
- You get it by both enabling "Group changes by page in recent changes and watchlist" at Special:Preferences#mw-prefsection-rc, and "Expand watchlist to show all changes, not just the most recent" at Special:Preferences#mw-prefsection-watchlist. PrimeHunter (talk) 16:24, 4 January 2014 (UTC)
- I agree this would be a really useful feature. Because I don't care whether the article is getting longer or shorter. I do care how much it is changing. A measure of how many bytes differ (or rather, of the least number of bytes that differ, since you must account for insertions/deletions), between the current version and the last one I saw, would be much closer to what I want. (Although it would still not satisfy me perfectly: for example, a word that negates the meaning of a sentence might be more significant to me than swapping the ordering of two existing subsections. What I really want is closer to the algorithm used for computing the molecular-clock time-of-divergence between two DNA sequences, accounting for not only point-mutations but also large-scale mutations, and which involves finding the minimum or "most-parsimonious" possible-trajectory connecting the two versions.)
- Obviously, this is computationally much more expensive than what we currently have (because simply comparing page-lengths is absolutely trivial). I'm not sure whether it would be prohibitively so. Cesiumfrog (talk) 23:10, 4 January 2014 (UTC)
- It isn't necessarily a good thing to make watchlists more efficient, lest they help contributors to "own" articles or categories. Apart from paid editors, no-one should have so many pages watchlisted that they need extra functionality to help. Ideally, pages should automatically drop off watchlists within a couple of months anyway. - Pointillist (talk) 23:44, 4 January 2014 (UTC)
- That's a really odd assertion. Right now I have 17,171 pages on my watchlist. Why do you think it's a problem for an administrator to pay at least cursory attention to a broad range of articles?—Kww(talk) 23:55, 4 January 2014 (UTC)
- It isn't necessarily a good thing that you've edited 19,858 unique pages over the past seven years and you are still watching 86% of them (I don't see how being an administrator is relevant). The whole idea of "anyone can edit" is that individual contributors don't control article content, so if a subject isn't notable enough to have many eyeballs continually reviewing it, it will eventually be trashed in ways that ClueBot etc can't easily detect. If young adults don't want to maintain their Dad's Wikipedia, the solution isn't to build new watchlist functionality just to help an aging population of sports fanatics more efficiently ride shotgun on articles about retired minor athletes, is it? - Pointillist (talk) 01:14, 5 January 2014 (UTC)
- What a bizarre view. Clue bot and edit filters don't always pick up the subtle changes. if established editors don't have big watchlists, who will notice subtle vandalism, whether to "serious" articles or to Dad's retired minor athletes - many of whom are still living, so WP:BLP trumps OWN. Anything we can do to help make watchlists more effective must be a good thing. Or are you trying to fork this proposal into a criticism of NSPORTS? The-Pope (talk) 01:47, 5 January 2014 (UTC)
- It's also possible to watch an article to revert vandalism and make formatting fixes without OWNing it. People might also want to watch this page for more than a few months. GoingBatty (talk) 01:55, 5 January 2014 (UTC)
- There are many valid reasons for a large watchlist. It's very odd to view it as an ownership issue. Many users have enabled "Add pages and files I edit to my watchlist" at Special:Preferences#mw-prefsection-watchlist. That can cause a huge watchlist if you don't spend time removing old entries. PrimeHunter (talk) 02:50, 5 January 2014 (UTC)
- I don't see a problem with vandal-fighters keeping track of many pages, except perhaps for the effect on server kitties, and PrimeHunter's checksum suggestion would be a good way to detect data vandalism in statistics, climate tables etc. It's contributors who want to police their content in perpetuity who I feel shouldn't necessarily be assisted by providing extra features. I've nothing against coverage of sportspeople and other "temporary celebrities" either—except that I doubt the next generation of editors is going to be interested in maintaining those articles. - Pointillist (talk) 13:19, 5 January 2014 (UTC)
- There are many valid reasons for a large watchlist. It's very odd to view it as an ownership issue. Many users have enabled "Add pages and files I edit to my watchlist" at Special:Preferences#mw-prefsection-watchlist. That can cause a huge watchlist if you don't spend time removing old entries. PrimeHunter (talk) 02:50, 5 January 2014 (UTC)
- Correct. Very bizarre. If you are a regular vandal fighter, and wish to deal specifically with articles dealing with subjects about which you are familiar and comfortable with, you will inevitably have a large watchlist. My watchlist has article watches which are set to expire "never." For those others that aren't necessarily of huge interest to me but that I've helped anyway, I tend to periodically remove them from the watchlist once the spate of vandalism (or whatever) that originally drew my attention to it moves on, but several hundred articles of interest to me are ALWAYS on it. There are hundreds of thousands of articles that need that kind of oversight at Wikipedia. That's NOT ownership—that's taking care of articles that are important to Wikipedia and/or just of particular interest to me or any other vigilant editor. GenQuest "Talk to Me" 04:20, 5 January 2014 (UTC)
- It's also possible to watch an article to revert vandalism and make formatting fixes without OWNing it. People might also want to watch this page for more than a few months. GoingBatty (talk) 01:55, 5 January 2014 (UTC)
- What a bizarre view. Clue bot and edit filters don't always pick up the subtle changes. if established editors don't have big watchlists, who will notice subtle vandalism, whether to "serious" articles or to Dad's retired minor athletes - many of whom are still living, so WP:BLP trumps OWN. Anything we can do to help make watchlists more effective must be a good thing. Or are you trying to fork this proposal into a criticism of NSPORTS? The-Pope (talk) 01:47, 5 January 2014 (UTC)
- It isn't necessarily a good thing that you've edited 19,858 unique pages over the past seven years and you are still watching 86% of them (I don't see how being an administrator is relevant). The whole idea of "anyone can edit" is that individual contributors don't control article content, so if a subject isn't notable enough to have many eyeballs continually reviewing it, it will eventually be trashed in ways that ClueBot etc can't easily detect. If young adults don't want to maintain their Dad's Wikipedia, the solution isn't to build new watchlist functionality just to help an aging population of sports fanatics more efficiently ride shotgun on articles about retired minor athletes, is it? - Pointillist (talk) 01:14, 5 January 2014 (UTC)
- That's a really odd assertion. Right now I have 17,171 pages on my watchlist. Why do you think it's a problem for an administrator to pay at least cursory attention to a broad range of articles?—Kww(talk) 23:55, 4 January 2014 (UTC)
- I personally try to keep my watchlist under a 1,000 pages, I agree that a zero byte change is different than a null byte change. Let's ask the Lead Software Architect if there is something the developers can do about this, and if it is possible, I'll happily put in the Bugzilla ticket myself. Technical 13 (talk) 04:40, 5 January 2014 (UTC)
- I have often missed a page history feature to mark identical revisions, not just to the current revision. If a hash value was stored for each revision then it should be cheap. PrimeHunter (talk) 04:52, 5 January 2014 (UTC)
- Have you had any feedback from the Lead Software Architect or the devs as to whether this is possible to do? The-Pope (talk) 09:12, 9 January 2014 (UTC)
- I have not heard anything from Brion or any of the other core developers (AKlapper (WMF)—Steven (WMF)—Whatamidoing (WMF)—Anomie—Magnus Manske). I just pinged some more (I'm guessing Brion has notifications disabled or isn't on here much). Technical 13 (talk) 15:52, 9 January 2014 (UTC)
- In principle one could change the software such that some sort of 'changed character count' based on a diff is generated at save time. (It would be too expensive to calculate on the fly on display; the current 'change size' is calculated simply by subtracting the old from the new text size in bytes, which is recorded at save time.) I'm not sure it's a high priority for folks, though, and finding a good replacement metric might be a bikeshedding nightmare. :) --brion (talk) 19:28, 9 January 2014 (UTC)
Proposed changes to WP:LEAD
I have proposed two changes to the guideline on leads which need some input from other editors. They are at Wikipedia talk:Manual of Style/Lead section#Four-paragraph lead and Wikipedia talk:Manual of Style/Lead section#Scope of article. SpinningSpark 00:23, 7 January 2014 (UTC)
Merge-and-delete accounts
Have we ever considered implementing mw:Extension:UserMerge? Apparently it's already being used by at least one WMF project, so it should be doable here from a technical perspective, and the idea sounds good. Nyttend (talk) 01:22, 7 January 2014 (UTC)
- This was only enabled for Wikivoyage wikis when they were being imported, so we could properly merge users from the Wikivoyage databases and the rest of WMF wikis. It's basically a non-starter though as-is, as it doesn't respect CentralAuth (which it'd need for any usage wider than what we deployed it for). ^demon[omg plz] 02:02, 7 January 2014 (UTC)
How to make all the proposals from now on get more attention
Everybody should have the option of setting up their own Wikipedia account in such a way that every time anyone writes a proposal, they get notified. It should also be possible to be possible to make it so that you get notified when ever an article gets created but since there are about 4,000,000 articles, that might be too often so maybe they should only be notified of the ones that get created while using Wikipedia. In addition to that, it should be possible to make it so that you get notified every time somebody edits a talk page of a specific WikiProject so that you can respond to the suggestions and edit many articles really fast to make them better.
Some people are really good at editing all sorts of Wikipedia articles. Just below the link Random article should be another link Random stub. In addition to that, everybody should be able to set up their own account in such a way that when ever anyone adds a stub tag to any article, they get notified by the notification box at the top of the Wikipedia web page they're on. There should also be a method of picking a random article from a specific category or a specific WikiProject so that people who are good at editing articles in that WikiProject can keep on editing more and more articles in that category to make them better. There should also be a method of picking a random uncategorized article so that people will be able to keep on going to random uncategorized articles to add categories to make other people who are good at editing articles in that category find that article more easily. It should even be possible to set up your own account in such a way to get notified every time anything happens in any subset of the subset of the following list that's mathematically possible: An edit to certian labs of community portal, an edit to the Teahouse, an edit to an article or talk page in a specific category or Wikiproject, creation of a new section for any of the above except for an article itself, creation of an article, requesting an article, and creating a previously requested article, creation of one's own requested article, closing of a discussion, an edit to one's own created article or its talk page, and creation of a red link in an article in hope of an article for that link getting created. For anybody with a Wikipedia account, every time any section with a part that was signed by them gets edited, they should automatically get notified. It's such a hassle for me to keep on going back and looking at all the talk pages I ever edited that I never got an answer to and be unable to remember all of them making it so that some answers I got, I might never go back and see because I forgot about that article entirely. Blackbombchu (talk) 04:20, 7 January 2014 (UTC)
- You can do pretty much do all this now. Use the "Watchlist". View "Recent Changes" (on the left menu panel) of any page. Type in any combination of letters in the search bar and hit enter for a list of random articles. Review "Categories" for maintenance needs. Join a "Projects" page. These are all in place now. GenQuest "Talk to Me" 05:41, 7 January 2014 (UTC)
- Is it also possible to watch just one section of a talk page? Blackbombchu (talk) 20:02, 7 January 2014 (UTC)
- No, it's not; that is a perenially-requested feature, but it has been deemed to technically difficult to implement, given how sections work. Writ Keeper ⚇♔ 20:05, 7 January 2014 (UTC)
- @Blackbombchu: You can get part of the way there by setting your Preferences to Group changes by page in recent changes and watchlist and Expand watchlist to show all changes, not just the most recent. You can then see the section header for each edit in your watchlist for pages such as this one, and only come visit when a section you're interested in is added/updated. Hope this helps! GoingBatty (talk) 21:30, 7 January 2014 (UTC)
- It looks like it somebody else has already done me the favour of setting up my account in that way because I actually got a notification about an edit to this section of Wikipedia:Village pump (proposals). Blackbombchu (talk) 21:40, 7 January 2014 (UTC)
- Not really; you got notified about that because GoingBatty explicitly pinged you, which caused the notification. Not all edits to this section will notify you; only ones which include a link to your userpage (as the template
{{ping|Blackbombchu}}
that GoingBatty used does) will. Observe: my earlier reply did not generate a notification, but now that I include the ping thusly: @Blackbombchu:, you will get a notification for this. Writ Keeper ⚇♔ 21:46, 7 January 2014 (UTC)
- Not really; you got notified about that because GoingBatty explicitly pinged you, which caused the notification. Not all edits to this section will notify you; only ones which include a link to your userpage (as the template
- No, it's not; that is a perenially-requested feature, but it has been deemed to technically difficult to implement, given how sections work. Writ Keeper ⚇♔ 20:05, 7 January 2014 (UTC)
- A think it would be really great if Wikipedia also made a change where every time a link from a Wikipedia article to an article somebody's watching gets created, they get notified because the article that the link was created from could be a stub and that would bring a lot of attention to the stub, helping it get improved really fast. In fact, which people had the stub brought to their attention would probably further improve the stub because somebody knowledgeable about the topic of an article is more likely to be knowledgable about an article similar to it than an article on a totally separate topic and articles tend to link other articles that are similar to themselves. Blackbombchu (talk) 03:29, 8 January 2014 (UTC)
- Is it also possible to watch just one section of a talk page? Blackbombchu (talk) 20:02, 7 January 2014 (UTC)
- You might also want to WP:transclude {{Centralized discussion}} onto your user or user talk page, where you can keep an eye on important discussions. That template is also transcluded at the top of this page. Wbm1058 (talk) 18:19, 7 January 2014 (UTC)
- Also you might want to subscribe to the Wikipedia:Feedback request service or transclude Wikipedia:Dashboard/Requests for comment. And, are you aware that you can watch pages? Alas, there is way more happening here than any one human can keep track of, so you need to pick and choose what you want to pay attention to. I tend to gravitate to things I find that aren't getting much attention from other editors, alas, there's a lot of that. Wbm1058 (talk) 18:42, 7 January 2014 (UTC)
- I don't know how to subscribe on Wikipedia. Is it possible to subscribe in such a way that a get notified by the message symbol at the top of any Wikipedia page instead of by email? Blackbombchu (talk) 20:02, 7 January 2014 (UTC)
- I encourage you to read the information at Wikipedia:Feedback request service. The idea of this service is to draw in editors for comments in discussions of more specific article-related issues. You can pick and choose which area(s) you want to get notifications in, and how many notices you want to get. A robot randomly selects editors who opted into a topic and posts messages like the following on their talk pages.
- Please comment on Talk:Genocide of indigenous peoples
- I encourage you to read the information at Wikipedia:Feedback request service. The idea of this service is to draw in editors for comments in discussions of more specific article-related issues. You can pick and choose which area(s) you want to get notifications in, and how many notices you want to get. A robot randomly selects editors who opted into a topic and posts messages like the following on their talk pages.
- I don't know how to subscribe on Wikipedia. Is it possible to subscribe in such a way that a get notified by the message symbol at the top of any Wikipedia page instead of by email? Blackbombchu (talk) 20:02, 7 January 2014 (UTC)
- Greetings! You have been randomly selected to receive an invitation to participate in the request for comment on Talk:Genocide of indigenous peoples. Should you wish to respond to the invitation, your contribution to this discussion will be very much appreciated! If in doubt, please see suggestions for responding. If you do not wish to receive these types of notices, please remove your name from Wikipedia:Feedback request service. — RFC bot (talk)
- Of course, anytime a message is posted to your talk page you get the notification at the top of any Wikipedia page you're on at the time. Note that I just randomly picked an example from archives. Sorry it happened to be such a depressing topic. I wish that kind of stuff never happened, but it does. Wbm1058 (talk) 20:57, 7 January 2014 (UTC)
Make it impossible to undo an undo
It would greatly reduce the number of edit wars if only administrators could undo an undo, with the exception that anyone can undo their own undo. If that casues too much of a problem because the person who undid the edit made a mistake and undid a good edit, then mayby instead, just certian people could just be blocked from undoing undoes rather than totally blocked for a certain period of time after it's discovered that they did an edit war. Blackbombchu (talk) 04:38, 7 January 2014 (UTC)
- This would simply make it harder to remove vandalism. And editors who are edit warring can still go to the old version of the article and click save. --NeilN talk to me 04:44, 7 January 2014 (UTC)
- Non-starter. Reason: see what NeilN said. GenQuest "Talk to Me" 05:34, 7 January 2014 (UTC)
Adding editnotices to date format and language templates
I don't know whether this is practical as it might require some software changes or an extension, but could the date format and language templates (e.g. {{Use British English}}, {{Use American English}}, {{Use dmy dates}}, etc) be configured to display an editnotice on pages which transclude them? It could be quite a neat way to let users know which format to use without them having to look for a template on the talk page, the bottom of the article body, or an obscure hidden category. --W. D. Graham 11:15, 7 January 2014 (UTC)
- I just created a new sub-category Category:Use English templates for English dialects. It could be a good task for a bot to just walk everything in that category, and create the appropriate edit messages—only admins and template editors can create or edit these messages. But I think there is confusion about the purpose of these templates. Are they designed as an advisory message for articles that already consistently use a single English dialect, to prevent editors from introducing other dialects to the article, or are they designed only for tagging articles that have mixed or incorrect dialects, intended to be removed once the problem is corrected, as categoring by date implies, e.g., Category:Use American English from December 2013. – Wbm1058 (talk) 18:05, 7 January 2014 (UTC)
- I think that rather than using a bot for this, JavaScript could be used to inject editintros, the same way it does for BLPs now. Jackmcbarn (talk) 18:13, 7 January 2014 (UTC)
- The documentation for {{use dmy dates}} states that they are intended to "assist in maintaining consistent formatting within an article. It is not a temporary "cleanup" template". One of the original purposes of the templates was to guide bots, although I am aware of several users - myself included - who also look for these templates when editing. I thought it might be a good idea to make them more visible - such as through an editnotice - to guide users who may not be familiar with them or know where to look. --W. D. Graham 18:13, 8 January 2014 (UTC)
- Right, I think it makes sense for both to just be permanent advisories. An editor noticing the wrong date format or the wrong dialect should just fix it right there rather than tag it for someone else. Given that, I don't think we really need to sub-categorize Category:Use dmy dates or any of the Use English categories by month as there is no backlog to work through. Wbm1058 (talk) 22:48, 8 January 2014 (UTC)
- Would adding a parameter (or two) to {{Edit notice}} that would put a note on the pages work? It wouldn't be automatic (although if the template is on the page itself, the maint bots could add it to the edit notice if it was in at least TE group or submit an edit request automatically otherwise). I would be happy to work up that in the sandbox. Technical 13 (talk) 22:39, 8 January 2014 (UTC)
- You mean like Template:Editnotices/Page/International Space Station? But editing International Space Station, I see that it also has a {{Use British English}} template. How can we avoid that redundancy and still have both the edit notice and the cats? Wbm1058 (talk) 22:58, 8 January 2014 (UTC)
- That is just ugly... But, yes, something similar only it would be a parameter instead of an entire new editnotice template. Anyways, why would it be redundant? The template doesn't seem to actually display anything (maybe I have something turned off which is why I'm not seeing it?) Technical 13 (talk) 00:43, 9 January 2014 (UTC)
- The link I gave is just what you see when you're editing the edit notice. When you're editing the article, it's . Looks nice to me. Keep in mind the original poster's question. Can we make any page with a {{Use British English}} tag just automatically have that edit notice? Needing to make a separate edit to the notice is what's redundant. The most promising answer above was the suggestion to "use JavaScript to inject editintros, the same way it does for BLPs now". I should learn how to do that sometime. Wbm1058 (talk) 04:24, 9 January 2014 (UTC)
- That is just ugly... But, yes, something similar only it would be a parameter instead of an entire new editnotice template. Anyways, why would it be redundant? The template doesn't seem to actually display anything (maybe I have something turned off which is why I'm not seeing it?) Technical 13 (talk) 00:43, 9 January 2014 (UTC)
- Found it! – Use an Edit Intro with these templates, rather than an edit notice. That's the ticket! See WP:EDITINTRO. Wbm1058 (talk) 05:09, 9 January 2014 (UTC)
- That's the same thing as Jack said above, the trick to that is getting community consensus to add the required code to MediaWiki:Common.js, which may be like pulling hen's teeth. Technical 13 (talk) 05:37, 9 January 2014 (UTC)
- Right, except he didn't give the link to WP:EDITINTRO which makes the details more clear. Is this something we could test by letting editors opt in by editing their common.css or common.js? Might be easier to get consensus if people have the opportunity to road test it before !voting. BTW I haven't even created my common.css yet. I trust your idea re {{orphan}} above really does work, otherwise some may have a point if they say "disruptive". Wbm1058 (talk) 14:09, 9 January 2014 (UTC)
- Looking at how the BLP and DAB notices are implemented, it looks like there needs to be either a central category or an html element for the javascript to latch onto. We might need to put an invisible html element - such as <div id="UseXXEnglish" style="display:none;"></div> - into each template to trigger the script. --W. D. Graham 14:56, 9 January 2014 (UTC)
- I created the central category, Category:Use English templates, maybe that's useful. Wbm1058 (talk) 15:35, 9 January 2014 (UTC)
- Looking at how the BLP and DAB notices are implemented, it looks like there needs to be either a central category or an html element for the javascript to latch onto. We might need to put an invisible html element - such as <div id="UseXXEnglish" style="display:none;"></div> - into each template to trigger the script. --W. D. Graham 14:56, 9 January 2014 (UTC)
- Right, except he didn't give the link to WP:EDITINTRO which makes the details more clear. Is this something we could test by letting editors opt in by editing their common.css or common.js? Might be easier to get consensus if people have the opportunity to road test it before !voting. BTW I haven't even created my common.css yet. I trust your idea re {{orphan}} above really does work, otherwise some may have a point if they say "disruptive". Wbm1058 (talk) 14:09, 9 January 2014 (UTC)
- I believe that Edokter or Mr. Stradivarius is the one that suggested common.js/css as a way to fix the orphan discussion above. I think it can be just as easily solved in-line through the lua module for multiple issues and the message box template that {{Orphan}} uses. I would much rather try to do it without common.js/css because I know what a pain it is to get consensus to add something to those pages. As to your question about testing, we can most certainly create it as a userscript, if that gains popularity it can most certainly be nominated to be a gadget to get a wider range of use (it can be set as default off or on based on what the community thinks). Technical 13 (talk) 15:04, 9 January 2014 (UTC)
- Right, I guess the implementation path might be userscript → optional gadget → mandatory gadget and that last hurdle may be the hardest as so far only disambiguation and BLP have risen to that level.
- (sidebar) remember there are two issues: (1) provide orphan patrol editors text they can import to common.css that makes {{orphan}} always visible. We could be testing this right now with {{orphan/sandbox}} and common.css code that works with the sandbox template. {{orphan/sandbox}} would be invisible by default, even inside {{multiple issues}}. This piece I consider mandatory. Do you have {{orphan/sandbox}} and common.css text ready for me to test? Issue (2) is making it visible by default when in {{multiple issues}}. I consider this piece optional, and maybe still even potentially controversial. - Wbm1058 (talk) 15:35, 9 January 2014 (UTC)
- (more sidebar) oh, sorry. (pulling foot out of mouth) I should have tested days ago. Returning to on-topic locations... Wbm1058 (talk) 20:39, 9 January 2014 (UTC)
- I believe that Edokter or Mr. Stradivarius is the one that suggested common.js/css as a way to fix the orphan discussion above. I think it can be just as easily solved in-line through the lua module for multiple issues and the message box template that {{Orphan}} uses. I would much rather try to do it without common.js/css because I know what a pain it is to get consensus to add something to those pages. As to your question about testing, we can most certainly create it as a userscript, if that gains popularity it can most certainly be nominated to be a gadget to get a wider range of use (it can be set as default off or on based on what the community thinks). Technical 13 (talk) 15:04, 9 January 2014 (UTC)
- That's the same thing as Jack said above, the trick to that is getting community consensus to add the required code to MediaWiki:Common.js, which may be like pulling hen's teeth. Technical 13 (talk) 05:37, 9 January 2014 (UTC)
Right click a file to view it at full resolution
I think right clicking any image file in any Wikipedia article should make a full resolution version of the image cover the article and both right clicking it a second time and moving the mouse of the image should make the image disappear off the screen. That avoids the cumbersome 2 clicks to view it at full resolution and another 2 clicks to go back to the article. If one of the dimensions of the image is larger than that dimension of the computer screen, left clicking the image should swap between screen fitting and full resolution and when view it at full resolution, there should be a hand symbol for dragging the image so that one or both of its dimension can take up an entire cropped part of the screen without a scrolling bar or the top of the browser reducing how much of the image is on the screen, or the entire screen if both of its dimension or bigger than those of the computer. That poses a problem of being unable to open the file in a new tab during editing without losing your edit. The problem can be solved by left clicking any link in a preview automatically opening it in a new tab. Even typing in the search bar during an edit then clicking the magnifying glass symbol should automatically open the search results in a new tab. Blackbombchu (talk) 20:24, 7 January 2014 (UTC)
I forgot, left clicking is used both for dragging the image with a hand symbol and for switching between screen fitting and full resolution which is impossible. One solution to that propblem is to make it so that left clicking can switch from screen fitting to full resolution but not the other way around. Those people who want to see the screen fitting version of the image can just not left click it in the first place. Another solution is to make it so that once you left click the full resolution version of the image that's larger than the screen, the - symbol where the mouse is doesn't turn into a hand until the mouse moves at least 1 pixel during left clicking. Blackbombchu (talk) 20:35, 7 January 2014 (UTC)
- Right clicking has always been reserved for browser and other application context menus, not to mention those that don't or can't support it, and further not to mention accessibility. Overriding right click functionality breaks all existing browser functionality, which in no way outweighs proposal issues. Almost every modern browser supports all the above actions with standardized controls. — HELLKNOWZ ▎TALK 23:17, 7 January 2014 (UTC)
I'm proposing that hovering over a file look something like this
with no edges around the image making it look like a popup window. Blackbombchu (talk) 02:38, 8 January 2014 (UTC)
- Honestly, your proposal for adding all that functionality into mouseclicks sounds like a solution looking for a problem, as encapsulated by the phrase "the cumbersome 2 clicks". And am I reading correctly that you are proposing that hovering over an image makes it pop up? I honestly hope that anything like this is never implemented. By the way, relax a bit with the proposals. There are far more productive and efficient ways to improve Wikipedia than by writing a lot of proposals that don't seem to gain traction with the community. :) -Well-restedTalk 06:59, 8 January 2014 (UTC)
- Maybe a better solution would be to have right clicking bring you directly to the page that shows the image all by itself instead of its description page with right clicking once performing the same function as left clicking twice. That way, the back button also only has to be clicked once. Blackbombchu (talk) 14:54, 8 January 2014 (UTC)
- An even better solution would be for links to files to include a hyperlink titled file. Blackbombchu (talk) 15:10, 8 January 2014 (UTC)
- Maybe the best solution is for images in Wikipedia articles to look something like this: Blackbombchu (talk) 16:39, 9 January 2014 (UTC)
I agree with Blackbombchu that having to load the file page for accessing the full image (two clicks + a page load) is a problem. But using right click or hovering seem the wrong solutions. A left click on the image should show display the expanded image in a lightbox, which is currently the standard behavior of images on the web; and the lightbox should include the link to the file page, thus reversing the order of actions and making the frequent interaction the easy one. Only with Javascript disabled should the image include a direct link to the file page. Diego (talk) 11:01, 8 January 2014 (UTC)
- If this were a thing, could it be opt-in/out? Because I personally enjoy the way images act now on this site. - Purplewowies (talk) 14:30, 8 January 2014 (UTC)
- Isn't this already a thing? That sounds more or less like the Media Viewer, available in the beta page of user preferences. Novusuna talk 16:40, 8 January 2014 (UTC)
- W00t! Thanks for pointing that, I wasn't aware of the Beta preferences. Diego (talk) 17:23, 8 January 2014 (UTC)
- Welp. XP Makes sense I didn't know about it, as I don't often go to my prefs, and even less often to the beta part. - Purplewowies (talk) 04:22, 9 January 2014 (UTC)
- W00t! Thanks for pointing that, I wasn't aware of the Beta preferences. Diego (talk) 17:23, 8 January 2014 (UTC)
- Isn't this already a thing? That sounds more or less like the Media Viewer, available in the beta page of user preferences. Novusuna talk 16:40, 8 January 2014 (UTC)
Allow any verifiable information at all in Wikipedia articles
The original purpose of requiring information to be verifible was so that almost all information in Wikipedia articles would be true, not so that almost all of it would be verifiable, because without it, some people would be adding in information they thought was true but wasn't. All verifiable information should be allowed even if the method of verification that can be done is different from viewing a source. For instance, information stating that YouTube is a website for watching videos shouldn't have to be removed even if no sources can be found for that information because it's verifiable by going to YouTube. On the other hand, stating that YouTube has a bell symbol at the top isn't quite true because it doesn't have it for people who aren't signed in, so if such untrue unsourced information is found in an article, instead of removing that information, it might be better to replace it with the true information that YouTube sometimes has a bell symbol at the top. Blackbombchu (talk) 22:56, 7 January 2014 (UTC)
- What you are proposing is making conclusions not directly supported by sources, which is basically WP:OR and is excluded for very good reasons. — HELLKNOWZ ▎TALK 23:12, 7 January 2014 (UTC)
- (edit conflict) Much information may be verifiable but not significant, and therefore not suitable for inculsion. For example I have white hair. This can be verified from my picture (on my user page) but I am not notable, and so there is no reason to include this in any article. Even if I were notable, it would probably be trivial. Likewise, we don't include the street addresses of most businesses, although they are generally easy to verify, because we don't consider such information encyclopedic. For information that is both obvious and unchallenged, there is You don't need to cite that the sky is blue. What sort of verifiable information that we now exclude would you want to include? DES (talk) 23:13, 7 January 2014 (UTC)
- Something like the fact that Bing feedback has a limit of 400 characters, which is super easily verifiable by almost anyone, which I proposed including in Google Feedback after it gets renamed to Feedback (internet) but that type of information seems to be opposed in Wikipedia:Articles for deletion/Google Feedback. There might be enough other facts about that topic verifiable in that way to have the amount of information sufficent to write an article on. Blackbombchu (talk) 00:51, 8 January 2014 (UTC)
- As a tertiary source, we're supposed to summarize, not detail, information. That Google allows feedback for its services is important, but how many characters you can include is not, unless for some reason that facet is called out by secondary sources. Even though you can validate the 400 character limit by looking at it, it's not really a needed point. --MASEM (t) 01:02, 8 January 2014 (UTC)
- Looking at your picture on your user page doesn't prove that you have white hair because it could be a picture of someone else. On the other hand, verifying that Bing feedback has a limit of 400 characters proves that it has a limit of 400 characters. Blackbombchu (talk) 22:41, 9 January 2014 (UTC)
- Something like the fact that Bing feedback has a limit of 400 characters, which is super easily verifiable by almost anyone, which I proposed including in Google Feedback after it gets renamed to Feedback (internet) but that type of information seems to be opposed in Wikipedia:Articles for deletion/Google Feedback. There might be enough other facts about that topic verifiable in that way to have the amount of information sufficent to write an article on. Blackbombchu (talk) 00:51, 8 January 2014 (UTC)
- Wikipedia is not an indiscriminate collection of information. Just because it can be verified doesn't mean it meets WP:GNG or WP:V. KonveyorBelt 23:22, 7 January 2014 (UTC)
- Moreover, a fact like "YouTube is a website for watching videos" is likely to be easily verifiable with reliable sources; the fact that sources discuss it is not only proof that it is true, but is also an indication of its significance. bd2412 T 00:07, 8 January 2014 (UTC)
- WP:Common Sense is what you are looking for. WP:Verifiable says "All quotations, and any material whose verifiability has been challenged or is likely to be challenged, must include an inline citation that directly supports the material." It does not say every fact has to be referenced. Rmhermen (talk) 00:13, 8 January 2014 (UTC)
- WP:Verifiability goes only as far as to document that something was stated (hopefully with some indication of who, when, where, etc.). But just because we can verify that (for instance) some text is accurately quoted says nothing at all about its truthfulness. That is why we have additional requirements, such as WP:RS, WP:WEIGHT, etc. None of which establish "truth". Nor should they. We only report what others have determined. Or at least said they had. ~ J. Johnson (JJ) (talk) 01:10, 8 January 2014 (UTC)
- Blackbombchu, the issue that has been raised regarding Google Feedback isn't verifiability, it's notability. —Largo Plazo (talk) 11:58, 8 January 2014 (UTC)
Don't have titles of articles bolded in the introduction of the article
The reason why not to bold them is because I believe the way it originally started was by editors making accidental mistakes. I believe the way the bolding of articles titles started is that sometimes when somebody added the title into the body of the article, they made a mistake by writing [[Name of the article]] forgetting that people were already on the article and so didn't need a link to it then later on, that caused other people to make a mistake and think bolding was the way it's normally supposed to work so they did the alternate method of bolding by writing '''Name of the article'''. Blackbombchu (talk) 00:30, 8 January 2014 (UTC)
- Blackbombchu, enthusiasm is great, but please scale back the number of proposals you're making. None of them seem to be gaining any traction. --Floquenbeam (talk) 00:33, 8 January 2014 (UTC)
- I think that your "history" here is incorrect. But even if it were correct, boding the subject at first mention is now the Wikipedia standard, and changing it would involve changing almost all of our over 4 million articles, to no particular gain that I can see. I also agree with Floquenbeam above, slow down. DES (talk) 00:40, 8 January 2014 (UTC)
- +1 → DES : bolding the topic name is now a standard practice, regardless of its origin. The question in my mind is whether any of the language-pedias go a different way and do not have this as a standard practice. --User:Ceyockey (talk to me) 01:02, 8 January 2014 (UTC)
- Your guess at the origin is wrong. Back in the day, you couldn't actually link to [[Name of the article]]. The wiki used CamelCase due to technical limitations, which had no brackets. Putting the title in bold-faced text became a convention very early on—possibly at exactly the same moment that putting the title in the first sentence caught on (because originally, you didn't do that). See this for the switch from CamelCase to free links; see here for the addition of the title to the first sentence, complete with standard bold-face. (These examples are taken from one of the oldest continuously surviving articles on the English Wikipedia.) WhatamIdoing (talk) 05:19, 8 January 2014 (UTC)
An aside: looking at a couple of examples outside Wikipedia
I was curious how other encyclopedias and "encyclopedic" resources might treat this, so I took a look:
- Encyclopedia Britannica appears to do the bolding in the way that Wikipedia does (e.g. marmoset)
- Encyclopedia of Military Science, though, does not do bolding (e.g. Drug Interdiction)
- Stories in Stone: A Field Guide to Cemetery Symbolism and Iconography does not do bolding (book on my bookshelf; e.g. entries for "stone" and "hibiscus")
- print dictionaries always appear to bold the word as there is no dichotomy between entry and page ... if we look at Wiktionary, the words within an entry are bolded (e.g. wikt:landing)
- The classic textbook Biochemistry by Lehninger has quite a few sections which are single topic, such as "Trisaccharides" (pg. 263) and "Exitation-Contraction Coupling" (pg. 763); bolding of first use of the topic phrase does not happen in this textbook (another book on my bookshelf)
--User:Ceyockey (talk to me) 01:02, 8 January 2014 (UTC)