This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
In the "Rational numbers" section of the Wikipedia article, Number, I discovered a way to write fractions as text rather an image. For instance, 1/2 was written as is. I don't know how to make the code for the fraction appear in the proposal but you will see how to write fractions when you edit the proposal to answer it. I still don't know of any way for to appear as text instead of an image without doing overline formatting with a separate square root symbol. Variables don't have to be images either but could instead be an ordinary letter with italicized formatting. I think there should be a source code that can make any mathematical expression at all appear as text instead of an image. Once that happens, the old methos of using math tags should stop working to raise awareness of the new method of creating mathematical expressions in an article because otherwise, all those millions of people will be doing the old method of creating a mathematical expression because they're ignorant and don't realize about the existence of the new method. Blackbombchu (talk) 22:17, 21 November 2013 (UTC)
I don't see that there is an actual proposal here. Basically you're saying "replace LaTeX by some new templates that haven't been written, and for which there's nothing remotely like a spec, just a blue-sky wouldn't-it-be-nice if".
However, there is a very substantial project to improve the rendering of mathematics in MediaWiki software. It's been going on at a slow burn for years and I couldn't tell you what the current status is. Search Wikipedia and MediaWiki spaces for "mathjax" and "blahtex". --Trovatore (talk) 22:32, 21 November 2013 (UTC)
Many mathematical expressions cannot be written as text. There is simply nothing we could send to a browser which would make it produce the wanted expression. Images are unavoidable for some things if we want to make proper looking expressions. PrimeHunter (talk) 23:00, 21 November 2013 (UTC)
Maybe browsers will slowly evolve over time gradually increasing the number of mathematical operations that can appear as text one at a time. Square roots are very common in math so maybe a square root symbol could be the first thing the browser accomodates, then much later, they might accomodate more complex expressions such as a definite integral. In chemistry, Elements are sometimes denoted with both a subscript and a superscript to denote the atomic number and atomic mass so the browsers evolve to accomodate a superscript directly above a subscript. Blackbombchu (talk) 03:35, 22 November 2013 (UTC)
This appears to be a proposal to change things for the sake of changing them, rather than there being any actual reason for doing so. I fail to understand why this "proposal" was made. — Huntster (t@c)03:17, 22 November 2013 (UTC)
Being in the form of images causes mathematical expressions to have bigger text than the text that is not in the form of images. Even if Wikipedia was like Wolfram Mathworld where the images are the same size as the text, numbers appearing in mathematical expressions would still not look exactly the same as the same numbers appear as text, especially when viewing the internet zoomed in. Having long mathematical expressions be in the form of images also makes it impossible to copy and paste only part of that expression instead of the whole thing. Blackbombchu (talk) 03:47, 22 November 2013 (UTC)
What are you going to do about expressions like (here, Stokes' theorem)? (you would need too many templates for this). On the other hand, LaTeX is well-standardized way of showing it and in fact is easier to export to other documents than templates. Even if browsers introduced it, it would be years after that until support for older browsers which do not support it could be dropped.--Jasper Deng(talk)04:58, 22 November 2013 (UTC)
I think once a browser that can handle all mathematical expressions gets made, Wikipedia should have 2 versions of an article, one for new browsers and one for old browsers that can't handle complex mathematical expressions. For certian types of edit that don't make a change to any mathematical expressions, there should also be a second editing option that makes the same edit to both versions of the article all at once. Blackbombchu (talk) 01:51, 27 November 2013 (UTC)
LaTeX is fairly well established in the math and scientific communities. While the average user may be unfamiliar with it, it is at least well-documented on Wikipedia and elsewhere. This is basically proposing to replace it with something Wikipedia-specific, that no one currently knows, and that no documentation for exists. That would likely be something that would seriously deter math experts from contributing. {{sfrac}} is not some special browser behavior designed to display fractions, it's just a bunch of CSS and template code that makes something look like a fraction. While you can highlight it as text, when you copy and paste it, 1/2 just becomes 1/2. Mr.Z-man05:43, 22 November 2013 (UTC)
I read on the internet that it's possible to write square roots in microsoft word even though I have no idea how to do it. Having said that, I suspect it's also possible to write fractions in microsoft word. Since Microsoft word can handle fractions, it should be possible for Wikipedia to evolve in such a way that if you copy and paste 1/2 into Microsoft Word, it pastes as 1/2 but if you paste it into Notepad, it pastes the same as what it would have pasted as if it been copied from Microsoft Word and pasted into Notepad. Blackbombchu (talk) 01:59, 27 November 2013 (UTC)
Word has a built-in equation editor. But it uses Microsoft's proprietary OLE format, so compatibility with Wikipedia, which prefers free/open-source software is unlikely. Getting something that works similar to the equation editor (a WYSIWYG editor [1]) is probably possible with VisualEditor. Mr.Z-man15:48, 2 December 2013 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I originally floated this idea at WP:VPIL, and it got some support, so I am bringing it here. This idea was inspired by the fact that Wikipedia allows people to configure their browsers not to display offensive images, such as those which depict Muhammad. My proposal is that we do the same thing, but for explicit words, so under my proposal, people would have the option to configure their browsers so that "fuck," "shit" and similar such words would be replaced by a black censor bar. While Wikipedia is not censored, I realize that, it is also not supposed to offend people any more than is absolutely necessary, in my view. Jinkinsontalk to me16:43, 27 November 2013 (UTC)
Oppose While I'm fine with keeping some especially disturbing images off of the main page, I have very little tolerance for other institutionalized "head in the sand" behavior. This is an encyclopedia, and in the course of properly covering history and current events, we can and do quote people saying things that, by modern Western social values, would be considered "horrible". We should not be wasting our time trying to hide words that every eleven year old has heard and most eleven year olds use. If someone wants to create a userscript, and keep the coding and the list entirely within their own userspace, they are free to do so, and I will not object. But if someone wants to turn this into a gadget, use the MediaWiki namespace, or do anything that might interfere with other people seeing those words, I will vociferously object. Let us not distort reality for the sake of making people with exceedingly thin skins feel more comfortable. Sven ManguardWha?22:09, 25 November 2013 (UTC) Copied, timestamp and all, from the previous forum, as my thoughts have not changed on the matter.
Oppose as per Sven Manguard. Even if this were optional, the debates over which words would be subject to the option, and which would not, would be toxic and profoundly unhelpful. I don't really approve of an image-censoring option such as Jinkinson mentioned above, unless it blocks all images equally. This idea has been proposed before and has never gotten anything like a consensus, nor do i think it ever likely to. DES(talk)19:33, 27 November 2013 (UTC)
No? Discussion about offensive words belongs on the talk page for an article, because an offensive word could be important in one context and superfluous in another. I don't think we need to lean on NOTCENSORED (Though it's there!) to make that decision. Protonk (talk) 19:54, 27 November 2013 (UTC)
Fucking Support. I initially opposed this shit, til I realized I was just getting my ass in line with what others will surely say, going with the traditional answer to these suggestions here, etc. Thinking about it, I wouldn't see the harm in a god damn gadget for this, however it should probably still show the words via a toggle link or on mousing over -- we don't want users to have to disable the gadget whenever they might end up needing to see those words. None of the votes above actually presented any reason this would be a problem as a gadget, other than the question of which words to include; I think we could solve that by using some external standard (such as words you can't say on western TV networks?). A gadget doesn't seem like it would harm the principle of us being uncensored. It might be a problem if we actually were "wasting time" or effort to accommodate it, as Sven argues above, but if some individual wants to devote said time to the coding, we can let them, without any real cost to the community that I can see. equazcion→19:57, 27 Nov 2013 (UTC)
I support the above idea. Further, rather than pre-defining the list of words, I suggest that any word any user finds is simply added to the list. Hence anyone who does not like the word "and" or "was" or "France" can simply add those words to the offensive list. Leaky Caldron20:02, 27 November 2013 (UTC)
I'm assuming you mean each user maintains their own list? Just clarifying. equazcion→20:06, 27 Nov 2013 (UTC)
Ah, I see. So your support vote is actually a trolling oppose vote. Just letting everyone know. Thanks for the clarification. equazcion→20:10, 27 Nov 2013 (UTC)
If someone wants to develop a personal script for this and someone else wants to use it, I don't see why we should forbid them unless it (somehow) interferes with other editors' work. Some people already use this client-side, and they would surely want to block the same words elsewhere. But as a global implementation, this can never work. The system cannot determine the context of the words and thus it cannot correctly decide when to censor something or not. This is even before mentioning that deciding on what is and what isn't offensive is highly subjective and dependent on so many factors, the system could never account for all. The only solution is to manually flag each instance, in which case I strongly oppose creating such arbitrary workloads. — HELLKNOWZ ▎TALK20:33, 27 November 2013 (UTC)
+1. It sounds like people just want a browser plugin or a userscript. There's no reason why this should be a site level feature. Protonk (talk) 20:40, 27 November 2013 (UTC)
Oppose Apart from the reasons expressed by User:Sven Manguard, such tools also accidentally censor lots of other things. Some time ago, the Chinese government wanted to prevent people from Googling for certain dissidents, so the government blocked searches for the characters 江 (surname of e.g. Kiang Tsing and Kiang Tse-min) and 周 (surname of e.g. Chou En-lai). While this blocked Google searches for those three people in China, it also had the unfortunate side-effect that you couldn't search for any rivers or weekly publications by typing in their names.[2] A blocking script would not only block bad words, but also words which aren't bad but happen to be spelled identically to a bad word in English, for example random words in non-English book titles in a reference section. Some badly written censorship scripts also censor long words which contain a short bad word, such as "Saturday", even if the long word isn't a bad word in the first place. These side-effects instead draw extra attention to bad words and are therefore counter-productive. --Stefan2 (talk) 22:10, 27 November 2013 (UTC)
Oppose. Wikipedia is not censored. Sorry, I dislike it when people jump in and just cite a policy, but I have to do it here. If someone wants to develop a gadget for people to use to do this, then fine. I've got no idea how you'd do that, as what is "offensive" and what is not is highly subjective and culture-sensitive. Still, whatever floats your boat! I've got no problem with people modifying their own interface. I do have a problem with this being a site-level feature. We're not censored. --(ʞɿɐʇ) ɐuɐʞsǝp22:40, 27 November 2013 (UTC)
I've never been one to push the boundaries of WP:NOTCENSORED, as it's usually pretty childish. But I'm also of the belief that if you're easily offended by something—anything—the internet probably isn't for you. There are plenty of historically and academically relevant uses of "bad words", and it's up to the reader to decide what he or she can't tolerate. – Juliancolton | Talk22:35, 27 November 2013 (UTC)
Oppose If you look at the problems that come up in UAA where the bot (and live users too...) brings in names containing 'nazi' (as in 'Nazir'), 'shit' (as in 'Dikshitar') and other ones where you have to look closely to see what they're on about, you'll see something of what Stefan2 says. There are quite innocent placenames like Penistone, Scunthorpe and Prickwillow in the UK too. Then there are words like 'fag'. Seemingly a near deadly insult in the USA, but merely a cigarette in the UK (or an old-fashioned term from public schools). A faggot is a type of meatball or a bundle of wood. What level of 'bad' are we talking? Are balls bad? Hard luck on the tennis players who bounce theirs on the court before throwing them up in the air. If balls are bad, what about testicles? What about words that are 'bad' in other languages, but not in English? Unnecessary use of 'bad words' with intent to offend can be classed as vandalism. Censoring them out of all use is unworkable, and they would be almost impossible to define to everyone's satisfaction anyway. Peridon (talk) 14:36, 29 November 2013 (UTC)
Haha! Penistone! equazcion→14:56, 29 Nov 2013 (UTC)
There was a Scottish council that installed software to censor things. It put 'bleep' in. They even managed to get things like 'bleeples and mussels' and 'bleeptails' on their site. It was great fun until they decided that they were looking extremely silly... Peridon (talk) 17:10, 29 November 2013 (UTC)
Support Per Leaky, above. If I ever feel like not seeing the word, "France" here, I'd like to be able to do that without having to write my own script. Can the opposers please tell me what's wrong with that? Seriously. If the feature isn't going to inconvenience anyone who doesn't want it, why should they prevent those that want it from having it, and those who want to make it from making it? What harm is prevented by the banning of such a feature?
Above, Sven says, "We should not be wasting our time trying to hide words that every eleven year old has heard and most eleven year olds use." But he doesn't tell us why we may not help readers hide them for themselves; or whose time he's worried about being wasted. Nobody's suggesting he has to do anything. He also exhorts us, "Let us not distort reality for the sake of making people with exceedingly thin skins feel more comfortable." Reality distortion? And a claim that people who find some words offensive are "thin-skinned" and their feelings don't matter. Sorry. I don't see anything here to justify preventing volunteers from making this feature if they want to.
I'm not suggesting banning anyone from doing their own thing. They can make a script that turns all s and x letters pink for all I care - so long as it does it only on their own machine. Or they can use that Chrome thing and discover tunes like 'Bleep o'the North', or try Bleep-a-Leekie Soup, and never find out what the bleep was in that Indian name. To use it, they've got to overcome their repulsion and type the offending words in. That amuses me. (Doesn't take a lot...) Peridon (talk) 17:20, 29 November 2013 (UTC)
It's basically a Western cultural thing. A few people are so offended by the idea that you don't want to read whatever profanity that they choose to post, that they want to make controlling your own reading as difficult and as officially disapproved as possible. It's sort of, "If you truly insist upon not seeing certain kinds of vandalism before ClueBot gets around to reverting it, or profanity in conversations between people with admittedly unprofessional communication skills, well—perhaps some of us think that you ought to see a psychologist about your weird hangups, but so long as you self-censor in private, then I guess we can't actually prevent you from exercising that liberty. Just don't let anyone know that you're not reading the profanity or obscenities that they post."
You won't find many people from Asian, African, or Global South cultures supporting this view. They tend to take the perspective that the listeners have a clear right to avoid speech that they do not choose to listen to, i.e., to walk away from the guy who is yelling profanity at passersby, or to do the Internet equivalent of either filtering pages or disengaging from conversations.
All that said, I can't imagine that very many people would actually bother to use a script like this. I've got no problem with any WP:VOLUNTEER spending his or her time making one, or even installing it as a gadget if it's stable, but I don't think it would prove to be popular. WhatamIdoing (talk) 19:12, 29 November 2013 (UTC)
If someone wants to write their own script, there is nothing stopping them. Doing so does not, and never did, require community approval. That is how the Muhammad image filter works. But censorship should not be made into a Wikipedia-supported gadget. Also, I consider your analogy to be poorly considered. Nobody is required to visit or read Wikipedia. They are just as free to walk away from the website as they are to walk away from that hypothetical person yelling profanity. Plus, there are plenty of people within "western culture" who seek and promote censorship. The opposition to it in this case is more accurately reflected by internet culture. Resolute19:25, 29 November 2013 (UTC)
Anthonyhcole - If you are on Wikipedia, the free encyclopedia, you are here to learn something. I believe that covering up unpleasant words simply because they are unpleasant serves no encyclopedic purpose and, in cases where those words are used in an appropriate way, as the "n word" is in Adventures of Huckleberry Finn and Stereotypes of African Americans, or the various bands and songs that contain the "f word", it actually impedes learning. I don't believe that Wikipedia should be giving people tools that allow them to whitewash or sanitize history and culture. Sven ManguardWha?18:05, 29 November 2013 (UTC)
Well, I guess if the people who would use this tool were forcing it on others, then of course I'd agree. But we're talking about a tool that the reader can choose to opt in to. How is that a problem, exactly? Who, exactly, is harmed here? --Anthonyhcole (talk · contribs · email) 18:35, 29 November 2013 (UTC)
Oppose, on the grounds that an encyclopedia that fears language is worthless. Never mind all of the technical problems. Resolute16:57, 29 November 2013 (UTC)
Strong support per NOTCENSORED and CHILDPROTECT. I think that many of those oppose votes above have missed the point of the proposal. This is NOT a proposal to impose a site-wide censoring of all potentially offensive words. This is a proposal for a tool that is entirely optional for those that don't want to see profanity (but should probably be encouraged for those editors who identify themselves as minors in the spirit of CHILDPROTECT). This gives everyone who supports NOTCENSORED, like me, an easy way out of any "Wikipedia should be censored" perennial proposal bullshit. "Oh, you think it should be censored? That's fine and everyone here on Wikipedia supports your right (yeah whatever) to have it censored for you. All you have to do is go to check the box next to Preferences → Gadgets → CensorMe and all "bad words" can be blacked out for you. Happy editing!" What could possibly be better? Technical 13 (talk) 17:24, 29 November 2013 (UTC)
I can't think of a kid that I know that's old enough to edit or read Wikipedia that would turn this on for themselves. And who is going to turn it on for them? But you miss the point of who decides which words. I remember using a school filtered system that wouldn't let me look up 'escort'. Hell's bells, it was a Ford car! (I'd got one and wanted some info on a problem.) Do you block 'cock'? A normal word in the UK where we don't talk about roosters and hens. Do you block 'prick' - Shylock: "If you prick me, do I not bleed?"? (I like that bit of punctuation...) Whose prejudices become the blocking standard? Peridon (talk) 17:37, 29 November 2013 (UTC)
Why not let each language group decide which words are bad in their culture? We are talking technical concerns here, and if it can be done (it can) where it is fairly accurate for each local, then technical issues aren't much of a concern... Technical 13 (talk) 18:15, 29 November 2013 (UTC)
So an American in the UK won't be able to block 'ass' because over here it's just a sort of horsy thing? Or is 'English' to be a single language group? (And then what is it that you cross with a horse to get a mule?) There are different levels of 'bad words'. I'm not offended by any that I can think of, but in certain places I don't use certain words, and I don't tell certain jokes to certain audiences. A lot of the fuss about 'bad words' and such is made by attention seekers. Sometimes it boomerangs - I'm sure Mary Whitehouse wasn't very happy about a certain magazine being named after her. As I asked above, WHOSE prejudices go on the list? Should we have an open discussion about it - or hand it to a secret committee? Or appoint a censor? Look at that link posted by Theopolisme above. Very good indeed. Peridon (talk) 18:56, 29 November 2013 (UTC)
The point I'm trying to make is that the list of potentially offensive words is large - and not all of them are single meaning words. To an American, an ass is what he sits on. A Brit can sit on his ass too - if he possesses a donkey like creature. So is ass to be on the list? How about an article like I Love Little Pussy? Now there's one for the censors... Who is going to draw up the list? No-one seems to be giving any indication so far of how they think this should be done. I would like to know who is going to bell the cat. Peridon (talk) 16:24, 2 December 2013 (UTC)
The point I'm trying to make is that there would be different lists (ie /languages/en and /languages/en-GB) and although "ass" might or might not be on the /languages/en list that would have no baring on whether or not it is on the /languages/en-GB list. The "official" lists would of course be populated by things on respective guideline lists such as Federal Communications Commission or Broadcast Advertising Clearance Centre guidelines. Users could then choose to add to their personal lists in a user configuration page such as Twinkle uses with twinkleprefs.js. Technical 13 (talk) 19:47, 2 December 2013 (UTC)
Oppose as stated. Support anyone writing a user script that they or others can install in their own common.js as long as it doesn't require the community at large to do anything to support it (note I consider making it a gadget a requirement that the community at large support it, as that would cause debates over default word inclusion that the community would have to find consensus on). Anomie⚔17:27, 29 November 2013 (UTC)
Ok, so I decided to take up the challenge and create a script that would blackout potentially-offensive words. Note that it is very aggressive in its word list (to minimize false negatives) and isn't configurable. Instructions are at User:Anomie/censorship. Anomie⚔19:29, 29 November 2013 (UTC)
Because if people are offended by things in the MediaWiki interface, there's little hope for them being satisfied. Anomie⚔22:14, 2 December 2013 (UTC)
Oppose as pure political correctness. This is the internet censorship of Scunthorpe all over again. Some things are offensive, yes, and should not be used, nor, if they are (eg) redirects, they should not be here, but spending your life typing G_d and being upset about Muhammed, and not wanting to see fluffy bunnies being harmed is, well, fluffy. FiddleFaddle18:40, 29 November 2013 (UTC)
Oppose per Theopolisme's excellent link - even if we did collectively want to do it, it's not possible to do it well, unless we ask every person to create/select their own wordlist (which as Peridon points out, would be somewhat wryly amusing (as in "please read this gigantic list of potentially offensive words")). –Quiddity (talk) 21:19, 29 November 2013 (UTC)
Support more or less per Anthonyhcole and Technical 13 above, and my thanks to Anomie for developing a prototype, which I think I would like to see publicized in the Signpost or elsewhere, and would hope for a more configurable one. I can't see any reason to not request the use of some sort of add-in which individuals who wish to use it can use. I myself, almost certainly, would never use it under any circumstances, because honestly some direct quotations which are extremely important to topics will contain such language. But we are intended to be a free encyclopedia for everybody, even fanatical idealogues who would object to seeing certain words in articles. Also, honestly, I have seen some internet servers, like some academic and public wi-fi services, block content of certain types with certain words or images, including some of our articles, like one article on sexual abuse in some country which a college student once told me couldn't be accessed from the college's computers. And I cannot see how it is in anyone's interests to effectively block certain editors' or readers' access to content exclusively because we want to include what some might consider questionable language. Also, if such an add-on is developed, it might be useful as a tool to determine which words which might not be essential for articles are among the most "blockable" by such servers, and knowing that would help ensure that all of our content is available to those who might need it, including those who might access us from libraries or elsewhere which have such blocking mechanisms in place, and can make it impossible for even some college students who are dependent on the college's service to access articles which might be important to them academically or personally. Granted, the individual lists of words will probably be more amusing than anything else, and like I said I can't imagine ever using one myself, but it might make it ultimately easier for us to make all of our content readily available to all who might want to use it. John Carter (talk) 00:52, 2 December 2013 (UTC)
"...and my thanks to Anomie for developing a prototype, which I think I would like to see publicized in the Signpost or elsewhere." This made me LOL. And if you install the script, I think you'll see why... Theopolisme(talk)12:09, 2 December 2013 (UTC)
Writing a user script can be done by any user. It doesn't require any MediaWiki developer time. But even if it did, most MediaWiki devs are volunteers, and are allowed to WP:VOLUNTEER (or not) on any project that they want to, just like most editors are allowed to volunteer (or not) on any article they want to. WhatamIdoing (talk) 19:20, 2 December 2013 (UTC)
Meh - while I support the principle of NOTCENSORED, it should be noted that it is likely some schools do not permit Wikipedia to be viewed as there are inappropriate images and language and whatnot. If there were a mechanism to "turn them off" that a school could implement (to a point above, few teenage boys are going to turn on a filter), that might be advantageous, but in principle, I support NOTCENSORED. GoPhightins!22:39, 2 December 2013 (UTC)
The relevant Policy and associated guideline could not be clearer, "In original Wikipedia content, a vulgarity or obscenity should either appear in its full form or not at all; words should never be bowdlerized by replacing letters with dashes, asterisks, or other symbols". That would include blanking letters or words. No aids/tools/gadgets should be provided within WP that would assist in concealing content. If you wish to contest the policy it should be discussed on the relevant policy page. It seems to me that a few contributors are putting a very large cart in front of a very small horse in discussing the practicalities of this proposal before securing the necessary policy revision. Leaky Caldron23:04, 2 December 2013 (UTC)
Well, it hardly matters: it's not at all technically feasible (at least to the level of functionality that one would expect in an official gadget), regardless of policy issues. Moreover, having it as a gadget would put a moral responsibility for the community to maintain some level of reasonable function with regards to what it censors and what it doesn't, and if history is any judge, there is not an icicle's chance in hell that the community would ever be able to come to any kind of consensus about such a thing (other than the current consensus of censoring nothing). So it's a moot point. There's really no reason for this section to still be open, to be honest; there's nothing to be done about it, even if we wanted to. Writ Keeper⚇♔23:10, 2 December 2013 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Watermark info on upload
Some people spend a lot of time to remove watermarks from images and that can be really hard sometimes, so I have a suggestion. - Could we not have clear information on the policy Watermark policy already at the upload?
This would hopefully reduce the amount of images that has to be edited afterwards and we could spend that time to do something more useful here. Goran tek-en (talk) 09:58, 2 December 2013 (UTC)
Telling a user of all 5000 rules we have during the upload process doesn't make a good and/or working system. Creating a rule means you will need to cleanup after the rule :( Do not see it as time wasted, see it as investing time to get the best quality content. —TheDJ (talk • contribs) 11:02, 2 December 2013 (UTC)
I do understand that you can not tell them everything but maybe some of the most time consuming things but I guess you have discussed this before or similar things, thanks. — Goran tek-en (talk) 12:07, 2 December 2013 (UTC)
RfC on preemptively protecting Today's featured article
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
As the headline suggests, I propose that all pages beginning with "Wikipedia" followed by a colon be permanently semi-protected from editing. (This proposal would not include noticeboards and pages such as this one; this proposal would only pertain to policy pages such as notability guidelines) Why? Because:
1. There is no reason for new and unregistered users to edit such pages as they probably won't understand them well enough to do so constructively,
2. There are, however, major reasons for them to want to vandalize these pages, for example to remove themselves from the list of banned users or to complain about how evil and heartless administrators were to them and their contributions on WP:Administrators, and
3. Many of them are already semi-protected indefinitely, including the two I just mentioned, so it wouldn't be a particularly drastic change.
I realize I am not the first to propose this idea, but I am confident that it is nevertheless a good one, and wanted to see if other editors agreed. Jinkinsontalk to me05:26, 15 November 2013 (UTC)
Registration is not a requirement. There actually are some unregistered users who are regular users and are plenty familiar with policies and procedures, but have just chosen not to register for whatever reason. Mr.Z-man05:45, 15 November 2013 (UTC)
There are plenty of unregistered users who are regular contributors to Wikipedia space. Except for just a few places where they are not permitted to vote '(uch as RfA, for example), their comments are as welcome as those of any registered users. To impose a restriction such as this would also engender an enormous bureaucratic overload at WP:ERQ. Kudpung กุดผึ้ง (talk) 06:20, 15 November 2013 (UTC)
I couldn't possibly support this idea as it is contrary to the principle that this is a community and you do not have to register an account to be part of it, as well as directly contradicting the idea that pages are generally not protected preemptively. Protection should always be used on a case-by-case basis. Beeblebrox (talk) 19:52, 15 November 2013 (UTC)
Oppose – What about making reports at admin boards? If you expect IPs to edit, you need to provide them with some way of getting help when they encounter problems that require admins. WP:ANI and WP:AN3 are both in Wikipedia space. EdJohnston (talk) 23:07, 21 November 2013 (UTC)
Moral support, because I am in favor of requiring user registration, and this kind of suggestion would fall under that (drastic and unpopular) action. Binksternet (talk) 23:56, 23 November 2013 (UTC)
Support, for reasons I regret I have not had time to articulate. The basic argument would be that allowing anonymous edits seems to be a sacred cow whose benefit is likely overstated, and that we need to protect what makes us a community. ~ J. Johnson (JJ) (talk) 22:03, 24 November 2013 (UTC)
Oppose as IPs are often valuable contributors, and because of noticeboards that often need IP input- WP:ANI for example. Ross Hill (talk) 22:37, 24 Nov 2013 (UTC)
No one claims that IP edits are all bad. But: 1) are the "good" IP edits worth all the valuable contributions not made by registered editors who have to spend time and energy suppressing the bad IP edits? 2) Why are the IP editors making valuable contributions unable (or only unwilling?) to do so as registered editors? ~ J. Johnson (JJ) (talk) 23:13, 25 November 2013 (UTC)
Thing is, if we could prevent lots of vandalism by preventing unregistered users from editing, why wouldn't we? Because of the countless helpful IPs who, while they are too lazy to create an account, are not too lazy to make thousands of constructive edits? I'm not sure such people even exist. Maybe it's no big deal that we can just revert a vandalistic or unconstructive edit, but the damage has been done--the vandal has gotten their vandalism viewed by the visitors of one of the top 10 most popular websites on the internet. So no, I don't think IP edits are worth allowing, because 97% of vandalism comes from them. Jinkinsontalk to me16:18, 27 November 2013 (UTC)
Very strong oppose. Most IP edits to Wikipedia space pages are constructive, so unless there is a specific problem (e.g. at WP:NOT) then like the rest of the encyclopaedia IPs should be able to edit. This is a fundamental principle and must not be changed lightly. Thryduulf (talk) 22:29, 1 December 2013 (UTC)
Oppose. Inexperienced users have a unique perspective and can often make better edits to documentation and policy pages than established editors can, in terms of spelling things out in words that other noobs can understand. Or sometimes inaccurate edits will show up from new users that at least let us know what's unclear to new users, indirectly resulting in an improvement. This is ignoring the whole principle thing which is probably reason enough. I'd actually be more receptive to proposing that all templates be semi-protected, as it's arguable whether they're generally part of the encyclopedia or more the interface, new users should be editing them even more rarely (if ever), and the average template is not nearly as watched as the average Wikipedia: page. But that has only a minutely better chance of passing than this, due to the whole principle thing ("anyone can edit"). equazcion→23:38, 1 Dec 2013 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
WebCite possibly going down
WebCite is used in 48000+ articles and on ~7000 project pages. They have announced that they may stop accepting new submissions next year, which may possibly lead to them closing down for good. I'm not sure what should be done, so I'm putting up a few ideas for discussion.
Inform Wikipedians. Especially those like me who use WebCite routinely when citing the web might be interested.
Helping with the fundraiser
Put up a banner on the pages.
Ask the WMF, they might be willing to share.
A project/bot converting WebCite's to archive.org cites.
archive.org is inferior to webcite; two things I've noticed is that archive.org makes all captures unavailable as soon as the robots.txt says to, and it doesn't cope well with cookies. Josh Parris23:16, 24 November 2013 (UTC)
It would be a great mistake to let WebCite die. It is obviously useful for rankings, scoreboards, climate stats and other data that are regularly updated at the same URL. It is also valuable for sourcing controversial claims about living people and litigious companies, particularly where the subject of the article controls the source and may have a vested interest in changing or removing it. Arguably it should be invoked by a bot for all {{cite web}} and web-based {{cite news}} references, so that the correct version of the source is captured automatically. - Pointillist (talk) 12:17, 3 December 2013 (UTC)
As we are all aware, there is a problem with the current RfA system. Two major issues I've noticed are:
People are scared of rejection and don't apply.
People apply to soon(WP:NOTNOW), get rejected and this puts them off applying again.
One way I feel this could be combated is by creating a pre-RfA page. Editors could almost run a 'mock RfA' where users can give them feedback without consequence. If an editor were to 'pass', they could then run for a real RfA and if they 'failed' they would know what to improve on before running for adminship.
While many hold a failed RfA in the past against a future RfA, this pre-RfA would not have the same affect as it is simply users looking for feedback. Also, if a user could pass this, it may remove the stigma of a self nomination as users can show that they already have support from other editors.
Of course, not all editors would want to do this and it should not be a pre-requisite for RfA. The traditional root would still be available but this would serve to help encourage editors who may not otherwise think of entering an RfA. Oddbodz - (Talk) (Contribs) 14:09, 24 November 2013 (UTC)
See WP:ER. Editors there asking for review who are contemplating RfA. I don't think we need a dedicated specialist area for pre-RfA purposes. If want-to-be candidates have not read the mass of available material on RfA, compared themselves to recent successful and unsuccessful candidates via the main RfA page or obtained some feedback from other editors one-to-one then one must question their suitability. Not keen on dress rehearsals. Leaky Caldron14:39, 24 November 2013 (UTC)
Yeah, WP:ER serves that purpose, although it's for more than just admin-hopefuls. Just like the majority of non-admin-required processes on Wikipedia (WP:AfC is another, IIRC), it's horribly backlogged and almost useless now. I don't see a specialized pre-RfA page to be useful, it would get even less visitors. Ansh66623:08, 24 November 2013 (UTC)
Support we need to be willing to try new solutions for RfA's problems. As far as I know, you can start up WikiProjects without consensus approval and I might be willing to help with this project if it is implemented, at least to get it off the ground. As for ER, I don't think it is effective enough to be useful here (Speaking from personal experience, I once opened an Editor Review for myself and it was open for almost a month before I got any feedback). AutomaticStrikeout (₵) – Rest in Peace, Jackson Peebles15:53, 25 November 2013 (UTC)
I have thought about a Wikiproject, and proposed one here. I was surprised how little interest it received, but still think there is no hope for meaningful reform without such an organized approach.--S Philbrick(Talk)17:06, 27 November 2013 (UTC)
In my opinion, the scope of your proposed Wikiproject is far too narrow. However, you already have one member, and I got none, so maybe I'm wrong.--S Philbrick(Talk)17:10, 27 November 2013 (UTC)
Comment In the UK, the Government some years ago wanted the quality of teaching to be assessed. So they introduced the SATS tests to see how well the teachers were doing. What happened? Most teachers proceeded to teach the kids to 'pass' the tests, and the parents put pressure on to get the kids through the tests. The kids got stressed. The teachers got stressed. Still do, but I think they're going to get rid of it. And no valid information came out of the exercise. A pre-RfA 'test', to my mind, would suffer similar problems. Unlike a car test (MOT), RfA is not a question of certain yes or now tick boxes. A pre-MOT inspection can get you avoiding a fail. A pre-RfA will soon be regarded as a preliminary test to be passed rather than being a source of information. At the RfA itself, people will say, yeh, they passed that, we'll !vote for them. Or not bother to come, because they passed already, didn't they? Peridon (talk) 14:53, 29 November 2013 (UTC)
I concur entirely with Peridon. While new admins of the right calibre are deperately needed, we want to avoid editors setting adminship as their main goal for participation in Wikipedia. We have more than enough advice pages for prospective admins and they are linked to from as many pages as possible, and if they can't be bothered to read them, they shouldn't be surprised if they fail. Kudpung กุดผึ้ง (talk) 01:55, 5 December 2013 (UTC)
Who enjoys public rejection? Editor review is just another forum for potential public rejection. I'd think that email or chat, while perhaps not entirely secure and private, are still better ways to put out inquiries to determine whether a potential candidacy would be viable. Wbm1058 (talk) 16:08, 5 December 2013 (UTC)
How to get as few as possible mistakes in Wikipedia
In the article Sinc function, I saw an obvious mistake in the introduction that has persisted for many years without anyone noticing or fixing it. It said the definition of the Sinc function was but that can't possibly be true for x = 0 because you can't divide by 0. For anybody who wants to train themself to be a better Wikipedia editor, there should be an online Wikipedia test that takes articles and adds in mistakes to already existing articles and displays those articles with the mistakes in them to the person doing the test and the task of the person doing the test is to see if they can find those mistakes on their own without being told what they were. Those mistakes shouldn't change how the article looks for everyone, just for the person doing the test during the test. Administrators should take already existing articles and try hard to think of what types of mistakes to add in that are as indistinguishable as possible from natural mistakes because they know exactly what mistakes they're testing other people's ability to find on their own and purposefully adding in mistakes and notifying people at the end of the test which mistakes they missed noticing trains them to be better at finding mistakes in Wikipedia articles. The same article should not add in the same mistake for everybody who happens to be given that article in the test.
I suppose the test could also include testing the ability to find natural mistakes in an old version of an article that no longer has that mistake, especially the ones that are the toughest to notice. To make it more of a challenge, some of the Wikipedia articles in the test should have no mistakes that the person taking the test is tested to find without being told that that article has none because it's harder to find mistakes in an article that has mistakes when you don't know for sure that it has any mistakes. Another type of mistake that people should sometimes be tested on finding is one where a physics or mathematical formula is missing a 2 in the formula. Blackbombchu (talk) 00:35, 2 December 2013 (UTC)
Well, to your specific point, the article mentions that "In both cases, the value of the function at the removable singularity at zero is understood to be the limit value 1.", because for sin(x)/x, as x approaches 0, the expression approaches 1, as can be seen at L'Hôpital's rule#Examples. So, I don't see the issue there. *No comment on the rest* Chris857 (talk) 02:36, 2 December 2013 (UTC)
Editors wanting to work on their error detecting abilities can just examine real articles and try to find the errors which are usually there. Looking for deliberately added errors in copies of articles sounds like a poor use of time when it isn't part of some exam prospective editors are required to pass (I would oppose such a requirement). PrimeHunter (talk) 03:17, 2 December 2013 (UTC)
Is it your expectation that if such a series of tests were created, editors would have to pass them in order to get permission to edit? If so, that flies in the face of some fundamental principles.--S Philbrick(Talk)14:07, 2 December 2013 (UTC)
No, it was just meant for those who wanted to make themselves really good editors. Reducing the number of people who can edit probably will make Wikipedia articles not get better as fast. On the other hand, it might be a good idea to follow my earlier proposal titled Pending changes where a change doesn't get made in the first place until the pending change is approved. The reason for that is that that way, people fell free to make as huge a change to an article as they want risk free. One such change might be rearranging the information all over the entire article to express the information in a clearer way and if that person is a really good English writer, that pending change will probably get accepted. The only possible advantage I can see to requiring people to pass those test in order to edit is so that really huge edits that rearrange an entire article can be done but I was more thinking of them being optional tests for people who choose to make themselves really good editors. Blackbombchu (talk) 14:52, 2 December 2013 (UTC)
Maybe the test should be able to ba taken by anybody and people should be required to pass it to have the power to approve or reject pending changes. Blackbombchu (talk) 14:57, 2 December 2013 (UTC)
There is no editor who is competent to edit articles on every subject in Wikipedia, so even if such a test could be made, no one could pass it. Also, even creating a limited test would be extremely complex and error prone, because there are many creative ways to fix even a simple error in an article —Anne Delong (talk) 15:33, 2 December 2013 (UTC)
Maybe there could be separate types of tests for each subject or specific area of a subject. Each person who wants to become a really good editor could make a guess which subject they would be best at pick a test that tests their ability to notice mistakes in that subject. For instance, a math expert might pick a test that tests noticing math mistakes such as stating that all twin primes are of the form (6n - 1, 6n + 1) when (3, 5) is not of that form and an English expert might take a test that tests their ability to rearrange the information in an article to express it in a clearer way or the failure of an article to give the definition of a not very well known term that the article is refering to. Blackbombchu (talk) 16:23, 2 December 2013 (UTC)
It sounds like a good idea in some ways, but... Have a look at the History page and the diff for my edit at Dendrocnide photinophylla. I'm not a qualified botanist or a resident of Australia. I've never even seen one of these trees. But I am fairly expert in the English language. So should I be barred from editing this article through lack of qualification in the subject of the article? I found mistakes in both the English and German versions of a publication about tropical reptiles - while proof reading it. I knew nothing about the reptiles, and don't regard my knowledge German as anything brilliant, but the authors accepted all my proposed changes. Not everyone is a specialist. But we can remove junk, and correct the wording. And, may I ask, who is to write and administer these tests? How do we know that the people setting the tests really know all about the subjects? A lot of us are anonymous for personal or professional reasons. Peridon (talk) 18:18, 2 December 2013 (UTC)
I never even once wrote in this proposal that anybody should be banned from editing certain articles. You're mixed up with me making a breif suggestion about all articles waiting pending approval to get changed. That doesn't mean certian people are forbidden to edit certian articles. It means they're free to guess what edits might be good and make them even if they're very unsure because they know that their edit will wait for pending approval and not risk harming the article. What I really suggested was that anybody at all could edit any article they want and the sole purpose of the test was for one who by free choice chooses to make oneself a much better editor. The only thing I even made the slightest suggestion about people having to past the test to do was having the power to accept or reject pending changes, not editing an article. Blackbombchu (talk) 01:44, 3 December 2013 (UTC)
This is a good example of a suggestion which would be better in the Idea Lab. I think of the Idea Lab as a place to brainstorm ideas, with the goal of developing a fully formed proposal, which might then come to the proposal page. I think there's value in doing some of what you suggest, but by repeatedly calling it a "test", you leave the impression that there are some consequences if you don't pass the test. I can see value in create a suite of pages with errors, and using actual examples, prior to being corrected, has some value. However, it isn't clear to me how they should be used, or where they should exists, so those are some of the details that can be worked out in the idea space. Presenting it as a proposal means that readers are likely to reject, rather than suggest modifications.--S Philbrick(Talk)14:06, 3 December 2013 (UTC)
I was thinking of not passing the test being treated like never having taken it in the first place where people can keep doing the test as many times as they want. Your ides is good too. I fell like having a test that only tests noticing already exising mistakes before they get corrected is better than having no test. Such a test could just as easily result in somebody finding a mistake other then the one they were tested on finding that no one ever noticed before mistaking it for the mistake they were tested on finding. The new discovery of mistake from doing a test would also have a huge advantage of future tests done by other people then randomly happened to get that article being tested on finding that same mistake that was not tested before. New mistakes discovered by doing a test should not be removed from the article right away. Keeping those mistake a short time for testing will probably eliminate more mistakes in other articles later than the number of mistakes that would have been removed by removing them right away because it will train people really well on noticing mistakes. Finding a mistake in a test should not remove it from the article instantly because some people judge a certain change in an article to make the article better when it actually makes it worse. Blackbombchu (talk) 01:31, 5 December 2013 (UTC)
Log links on all pages
It's just occurred to me that the Toolbox has a link to the user's log whenever we're on any userspace/usertalkspace page, but the same is not true for any other namespace. Why not? What if we would add [https://wiki.riteme.site/w/index.php?title=Special:Log&page={{FULLPAGENAME}}] to the toolbox for every page, in between "Related changes" and "Upload file"? I'm not sure if local admins can implement this change; if we get consensus for it, I understand that a bug request might need to be submitted. Nyttend backup (talk) 01:37, 6 December 2013 (UTC)
The toolbox "Logs" link on userspace pages is for logs of the user and not for the viewed page, so there is no concept of "the same" for other namespaces. History pages have a "View logs for this page" link. That's the same for userspace and other namespaces. I think page logs are a little technical to place in the toolbox for everybody including unregistrerd users, when they are only one click further away on the history page. But it would be possible for local admins to do it. Individual users can also do it for themselves with code like below in Special:MyPage/common.js. The gadget "Add page and user options to drop-down menus on the toolbar" at Special:Preferences#mw-prefsection-gadgets adds log links and many other things to a tab. PrimeHunter (talk) 02:40, 6 December 2013 (UTC)
mw.util.addPortletLink(
'p-tb',
mw.util.wikiGetlink('Special:Log')+'?page='+wgPageName,
'Page logs',
't-logs',
'View logs for this page',
null,
'#t-info'
);
Character lists are generally always okay as the work of fiction revolves about them, but when it comes to any other fictional element, we should be guided on how secondary sources approach the work, even if they dont' necessary break down every element. This, for example, allows one to argue the include of Mythology of Lost because those elements of the story have been the subject of some discussion, even if not all of them. If the only people that talk about the elements are fan sites or the primary work, it is probably not appropriate for WP. --MASEM (t) 18:58, 8 December 2013 (UTC)
Watching sections instead of the whole page
What if, instead of watching an entire page for changes, you could watch only a certain section of this page, so that you would only be notified when someone edited that section, rather than if someone edited anything on the page? I think this would be very useful on pages like this one, where you often don't care about responses to any of the threads except for a few. If there is a technical problem that would make it hopelessly impractical to do this, then forget it (this isn't my area of expertise here), but otherwise I can't see any reason why this is a bad idea. I could be wrong though, I certainly have been wrong here before. Jinkinsontalk to meWhat did he do now?02:55, 10 December 2013 (UTC)
You guys understand that namespaces are artificial constructs, right? The software doesn't care. At all. We can say "don't allow it to be enabled in mainspace". Or we can allow that. It's all configurable.--Jorm (WMF) (talk) 04:24, 10 December 2013 (UTC)
Oh, from a software point of view, I imagine that makes sense. I just don't think there's any plausible use model for Flow in article space. Unless I've completely misunderstood what Flow is. --Trovatore (talk) 04:29, 10 December 2013 (UTC)
I agree: on the Wikipedia projects, I can't see much use for it in the main namespace, no. I'm not willing to concede that for other projects or namespaces, however. --Jorm (WMF) (talk) 05:30, 10 December 2013 (UTC)
(edit conflict) I think the plan is to eventually enable Flow across the board on all talk pages, but manually on any other individual pages that are used for discussion -- such as the village pumps, everything in {{noticeboard links}}, and any other page used for discussion. It probably won't happen to any article-space non-talk pages, unless one of those happens to get used for discussion for some reason. I don't know that there's any real need for a namespace restriction. I doubt enabling will be performable by any old user. equazcion→04:26, 10 Dec 2013 (UTC)
Guideline needed on tagging practices
Hello. I recently stumbled into an ambush (continued here, here) over at Talk:Edward Snowden that, at the 50,000-foot view, boiled down differences in opinion about acceptable tagging practices. I had added a top-level {{undue}} tag for what I saw profound imbalances in the article. While there was some division about whether there was an imbalance (and the extent of it), the discussion devolved quickly into an acrimonious, unproductive battle that in the long term may cause lasting distrust and damage to the article and the community.
Regardless of how one feels about who was "right" in this dispute (and, to be crystal clear, I'm not here to prolong that debate), the bitterness and the resulting damage would likely have been avoided if we had a guideline on tagging: when tagging is appropriate, when it's not, how to do it, when to remove tags, and how to resolve disputes. The only essay I'm familiar with on this subject is WP:TAGGING, which covers this topic and I rather agree with it, but I'm sure many other editors do not. If we can't get a consensus for promotion of that essay, then we should try to adjust it in order to achieve consensus. Regardless, we need a guideline on this subject so that editors like me know when to tag, and how; and so editors like the others in that dispute know how to respond. This isn't the first time this need has been articulated -- see, for example, here, here -- and it's clear from those discussions there's broad support for the idea. The trouble, of course, is follow-through. And I'll admit, I'm a relative newbie on such matters and I have no experience working in the WP namespace. Perhaps there's someone(s) out there who's willing to champion this cause? Here's hoping. --Dr. Fleischman (talk) 19:21, 3 December 2013 (UTC)
I am sympathetic to the problem. I've worked with many newbie editors, and many of them make a reasonable, but incorrect assumption about tags. They create their first article, then see a couple tags identifying problems. They attempt to address the problems, then sit back to await the removal of the tags, confident that whomever placed them will be monitoring the article, and will remove them as soon as the issue is addressed. That often does not happen, so they reach out to the Help desk or the Teahouse or other venues to ask why their fixes were deemed inadequate.
We permit drive-by tagging (and I'm not inclined to support a prohibition) but that leaves an awkward situation, as the newbies assumption is plausible. I've occasionally mused about how to address this, but had not come up with anything.
I had not seen the essay Wikipedia:TAGGING before, and think it is a good start for a potential guideline. And specifically, it has some suggestions on addressing the problem I just described. While I am not inclined to prohibit driveby tagging, I would consider supporting a requirement that a tagger add a comment to the talk page. If nothing else, remember that many newbies do not yet know how to look at the article history, so do not know how to identify who added the tag by insisting that the editor who adds a tag add a comment to the talk page, the newbie can at least see who to contact. In an ideal situation, the talk page note might say, "This article is missing references for claim A in paragraph 2, claim B in paragraph 3, and claim C in paragraph 5. If those claims are referenced, anyone can remove the Needs More references tag". Another good situation would be "This article seems biased because of the inclusion of item A and no mention of item B. If you made an edit to address this, let me know and I'll reconsider whether the tag is still needed."
The fact than anyone can remove a tag if they address the problem is not something that newbies know. Even those of us that know it, might not know exactly what the tagger was concerned about, so an explanation will help if a tthird party is trying to determine whether to remove the tag. --S Philbrick(Talk)22:36, 4 December 2013 (UTC)
Thanks for the response. There seem to be many different assumptions and expectations about tags, and I wasn't aware of the one you mention. In the tagging dispute at Edward Snowden the tension seemed centered around (i) whether the tagging editor needs to do independent research to verify his/her concern before tagging, and (ii) whether the tagging editor is expected to fix the problem him/herself after tagging. --Dr. Fleischman (talk) 00:00, 5 December 2013 (UTC)
I agree with everything I read in WP:TAGGING, which I've never seen before right now. However, we already have too many rules here; instruction creep (and its enforcement, particularly) is not good for attracting newbies and keeping oldies. Instead of changing the status of WP:TAGGING or any other essay, let's do the following. (1) When we see someone "violate" WP:TAGGING, leave a note at the user's talk page saying something like "Hi, I'm not sure what you meant by [edit]. Would you please go to the article's talk page and explain your reasoning? [[WP:TAGGING|Explaining your tags]] helps others understand the tag a lot better". This isn't bitey for newbies. (2) Treat it as disruptive and begin seeking sanctions against people who wilfully don't explain their edits. However, this should be used in extreme situations, when a page is really and truly being hurt by someone who's been reminded many times that tag explanations are needed, yet refuses to provide them; a good sign of this is if unexplained and non-obvious tags are removed, yet the tagger edit-wars to restore them. Nyttend backup (talk) 01:45, 6 December 2013 (UTC)
I made a suggestion ages ago to add a link on each maintenance template for "how to resolve this issue" with a link to a help page (not a policy page) and one for "how to remove this notice" that links to a help page. --Gadget850talk23:52, 9 December 2013 (UTC)
Hi, reading this article [4] which mentions a few things i would like to propose a few possible improvements, The first mention is to shift funds from the chapters to volunteers, i think this discussion is now finished with the recent discussion about paid editing on Wikipedia is a no go. i think we learned a lesson from the paid editing Google KNOL[5] project as well, so the question arises, how is this with paid projects on Wikipedia and does wikipedia need paid for projects ?? In early stages life was simple, we had 5 devs who did mainly MediaWiki implemetations on request and now we have 175 people who do projects not only for Wikipedia but also for sister projects, let me first state that i think that we all agree that after the split with Wikipedia to protect us from claims the WMF had remarkable success with its Charity fundraising drive, as for the split from Wikipedia with the chapters so PR could be handled more professional we see the chapters developing other paid for projects from which some are very success full, remarkable is a license change in Dutch musea for art works to be reused freely and projects for our sister project Commons [6]] to get more photo's and no doubt there are more of such Chapter projects, very nice projects, but not Wikipedia projects, now after so many years in progress and testing the new model, the second mention in the article mentions that the influence of volunteers on the chapters is not working as desired, in the founding of the chapters a clear split with roles between the volunteer Wikipedias and the chapters was intended, however it turned out that a trias was formed on Meta blurring the lines between paid for contributions and unpaid volunteer work.
Proposal
To max this split on the short term i propose that every member with a paid income from a chapter ads similar to (WMF) a (WMFC) at the end of the login name, and second reclaim the META channels to Wikipedia volunteer only, as a channel to combine all Wikipedia related issues only, all sister projects, WMF and Chapters are moved to a new channel METAWMF, in this way hopefully unpaid volunteers stay in this project as their morale is more supported as we are all unpaid on this project, instead of paid project guiders and unpaid volunteers.
In short its not an attack on any project, but an attempt to create clear lines from which each project can decide at its own merits based on their contributor base instead of a mixed interest playing field.Mion (talk) 21:33, 10 December 2013 (UTC)
I don't understand..quite a bit of the above, although I'd note that the register is mostly staffed by trolls. In any case, there's an unspoken convention that paid chapter staff who need to edit wikipedia have the appropriate chapter abbreviation as a username postfix already (see User:Lydia Pintscher (WMDE) as an example). Ironholds (talk) 22:11, 10 December 2013 (UTC)
thank you for clarifying the first part of the proposal, i didn't know such unspoken convention for naming already existed, but maybe we should make that a "rule" on every Wikipedia as many might not be aware of it.
Reformed proposal
Reclaim the META channels to Wikipedia volunteer only, as a channel to combine all Wikipedia related issues only, all sister projects, WMF and Chapters are moved to a new channel METAWMF, in this way hopefully unpaid volunteers stay in this project as their morale is more supported as we are all unpaid on this project, instead of paid project guiders and unpaid volunteers.
In short its not an attack on any project, but an attempt to create clear lines from which each project can decide at its own merits based on their contributor base instead of a mixed interest playing field.Mion (talk) 22:19, 10 December 2013 (UTC)
Could you explain what you mean by "META channels"? If you mean the Wikipedia referred to by the essay WP:IGNOREMETA, I don't think we make proposals about that Wikipedia on this Wikipedia anyway. --Demiurge1000 (talk) 22:27, 10 December 2013 (UTC)
yes, [[7]] is exactly what i mean, all Worlwide Wikipedia's should be combined with their own META channel for Wikipedia projects only, it turns out that if its mixed with other projects we get to much influence from paid for (by WMF or WMFC contributors as compared to volunteer input. Mion (talk) 22:38, 10 December 2013 (UTC)
I don't think you really understood what that article, Sue's comments, and the paid editing proposals are about... because they're really not related at all. The paid editing issue stemmed from the Wiki-PR editing of Wikipedia incident and is mainly about corporations and PR firms editing Wikipedia, not Wikimedia chapters. Sue's comments and the Register article were about how best to spend WMF money. The issues are really not connected at all. Sister projects and chapters are not the same thing. Sister projects are things like Wiktionary and Wikibooks, which, like Wikipedia, are volunteer-run. Chapters are organizations like Wikimedia Deutschland and Wikimedia NYC. They do things like outreach activities with libraries and museums. There is little clear division between chapters and volunteers, as most chapter members are not paid employees (many chapters even have a fee to become a member), but are just regular volunteer editors from the various projects. Mr.Z-man23:09, 10 December 2013 (UTC)
The core of the story was that the chapters turn out to run projects not from the Wikipedia, and in so the population of these chapters are only minimal represented by unpaid volunteers from Wikipedia also because they raise entry fees and such. This mixed project population decides that paid members should do active coaching of volunteers on Wikipedia and such without any Wikipedia project wide consulting of these volunteers, and yes, i named that coaching a "paid for project"Mion (talk) 23:26, 10 December 2013 (UTC)
The core of the "story" is a gross distortion of what Sue actually wrote. I'm not sure what you mean "chapters turn out to run projects not from the Wikipedia" - That's kind of the purpose of chapters. Chapters are not supposed to just be clubs for local editors. They do outreach activities to try to get potential new editors interested in editing or to start collaborations with local educational institutions. Again, most of the people involved in chapters are volunteers. I'm not aware of any project that is paying people to "coach" users. Even the Register article doesn't mention that. Perhaps instead of vague references to things you assume we know, you could provide some specifics as to what they're doing that you think is problematic? Mr.Z-man03:16, 11 December 2013 (UTC)
I am finding the language in this proposal hard to parse. The use of the word "channel" is confusing, the only WMF "channels" I am aware of are on IRC, but this does not seem to be in reference to that. And I am unclear as to who it is being proposed be paid. I would also note that chapter staff that I have spoken to have indicated that they are not permitted to edit Wikipedia while on the clock as that is not what they are being paid for. I think this proposal needs to be completely re-written if it is to have any chance of success, currently it does not make much sense. Beeblebrox (talk) 01:53, 11 December 2013 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Currently the tool is limited to only administrators. I am proposing that we create a new user group with only the 'massmessage' right in it. Admins would be able to give out and remove this group from users. Users would need to show that they have a need to use the tool (need to deliver some newsletter), and understand how to use it. This would be the same as the current process at User talk:EdwardsBot/Access list. Legoktm (talk) 17:47, 20 November 2013 (UTC)
Questions (MM)
You say "newsletters and other messages". Would that include, say, notifications to people involved in a previous discussion of a new, related discussion? Project updates? What else might reasonably use this mechanism? DES(talk)21:16, 20 November 2013 (UTC)
This isn't quite my area but I think it's more for people involved in groups that need to send out regular announcements. I had a look at User talk:EdwardsBot/Access list for some examples. equazcion→21:32, 20 Nov 2013 (UTC)
The tool was designed for newsletters and WikiProject update type-things. That said, if people want to use it for other things, it's up to the community on whether that type of unsolicited messaging is ok. Legoktm (talk) 21:43, 20 November 2013 (UTC)
Is there a log of who creates these kind of message deliveries ? Just wondering where we can find the source in case there is any abuse. —TheDJ (talk • contribs) 23:14, 20 November 2013 (UTC)
Yup, Special:Log/massmessage. Each message also has a hidden comment (we can make it unhidden if that's wanted) which includes the user who sent the message, what wiki they sent it from (might be from Meta), and what input list was used. Legoktm (talk) 00:47, 21 November 2013 (UTC)
With the caveat that if someone is only going to be sending out one message in the foreseeable future, it's probably better to just post a request. The right should be given to people who can actually use it (obviously). Killiondude (talk) 22:17, 20 November 2013 (UTC)
Support since it's really a good idea and may help in reducing useless time consumption. For example if people are planning to start a drive to rate all unchecked articles in a WikiProject then all the members can easily be invited to contribute. In the same way if an article is being planned to undergo a major reconstruction then the main contributors can easily be invited. - Jayadevp1300:53, 21 November 2013 (UTC)
Support I think a limited number of people in some of the larger Wikiprojects and in the Signpost have valid reasons for having this as a userright. I know that some of the key Singpost members aren't admins, and while the current executive editor is an admin, it's always good to have several people capable of triggering the delivery. I'll note though that if admins start giving this out like candy to users that don't have a valid reason for sending mass messages, I'm going to be rather miffed. I don't like spam. Sven ManguardWha?04:09, 21 November 2013 (UTC)
I think if we're to have a new user group for this, the user group should be viral: anyone already in it can give it out to others. MediaWiki natively supports this configuration. All MassMessage does, at its core, is replace what would instead be a lot of browser tabs and clicking. A user group for a single user right feels a bit silly, but okay. --MZMcBride (talk) 04:29, 21 November 2013 (UTC)
Support - this rightr should only be given to users who are likely to be using it. I also think that it should be part of the bot package (bots can do this with a small amount of human effort on their own, but this will allow them to do it using less site resources), but probably not part of the automatic admin package (although admins should be able to take it if they need it). This will replace the newsleter bots (the users in charge of the newsletters should have this right, regardless of admin status). עוד מישהוOd Mishehu14:06, 21 November 2013 (UTC)
The only other reasonable option is to create a page for people to request that an admin send mass messages for them, which would seem to be more bureaucracy than this. The default of "only admins" makes sense for smaller wikis where admins actually have time to administer things, but on enwiki, it makes sense to delegate less dangerous/sensitive things to other trusted users. Mr.Z-man21:57, 21 November 2013 (UTC)
Support for having more unbundled user rights to eliminate bureaucracy. Ross Hill (talk) 01:15, 22 Nov 2013 (UTC)
Support as a more formal facility for achieving what was previously possible via EdwardsBot. Rights should be assigned by trusted community members, after considering brief use rationales within requests. The right shouldn't simply be assigned to others by those who have it themselves, because this could result in potentially abusive use, e.g. by those unfamiliar with adopted conventions. -- Trevj (talk) 03:57, 22 November 2013 (UTC)
Support, although I think User:Johnuniq has a point below. EdwardsBot usage is kind of obscure, while a user right brings this functionality into the limelight. There should be some guidelines laid out as to when this is appropriate versus other methods like RFC, and when a possible use should be discussed first. Eg. WikiProject newsletter by several individuals = probably okay; advertising your own village pump proposal = probably not okay; etc. equazcion→12:42, 22 Nov 2013 (UTC)
Support along similar lines that EdwardsBot was handed out; You only got it when you had an ongoing cause to use it (eg. I have it to help with WP:WPAFC message delivery.) --Mdann52talk to me!13:15, 22 November 2013 (UTC)
Support—some of us who currently edit WikiProject newsletters are not admins, and we have permission to use EdwardsBot to handle those mass mailings. Not supplying a userright, which like the EdwardsBot permission would be subject to revocation, and restricting this tool to admins just means admins will have to be bothered to take on the tasks already done by others, namely newsletter delivery. Imzadi 1979→05:45, 23 November 2013 (UTC)
Support I don't see why we would want to change the status quo (that an editor could be added to the EdwardsBot list). I echo Courcelles' comments above, thanks and well done to those who worked on the extension. Callanecc (talk • contribs • logs) 05:54, 27 November 2013 (UTC)
Support. The case for this has been clearly made, and so long as the new user right is responsibly assigned there are no obvious negatives in this proposal. AGK[•]23:35, 29 November 2013 (UTC)
Support. We already have this functionality with the EdwardsBot list, so the proposal's basically simplifying the process for users to get it. We really should have some sort of warning to would-be requesters, telling them that they won't get the userright unless (1) they've had EdwardsBot access in the past, or (2) they already have a message ready to go, which they can send out as soon as they get the right. This should cut down on the hat collecting substantially. Nyttend backup (talk) 00:26, 6 December 2013 (UTC)
Support. It makes sense to just ask an admin for permission to use the tool rather than ask an admin to review and send each individual message. It should only be granted to people with a demonstrated use for it; and people who misuse it should be drawn, quartered, and left for the vultures. ~ Ningauble (talk) 12:54, 8 December 2013 (UTC)
Support. Will save admins some work, which is good from my point of view. Also, the EdwardsBot system has been working well so it makes sense to make the MassMessage permission system work similarly. — Mr. Stradivarius♪ talk ♪04:15, 9 December 2013 (UTC)
Support - The idea makes sense. I'm sure the issue of spamming would be extremely rare, as this would essentially serve to replace EdwardsBot and would be given to trusted users who have a legitimate need for this permission. We can deal with each issue case-by-case. Michaelzeng7 (talk) 22:25, 9 December 2013 (UTC)
Meaning you just don't like the idea of non-admins collecting various userrights, or you think there's a potential for abuse? I'm curious. – Juliancolton | Talk18:24, 21 November 2013 (UTC)
I am not entirely sure about this one because of the potential to annoy literally thousands of users with unwanted messages. I think perhaps the criteria for granting it should be better defined. I assume requests would be made at a new page at WP:PERM? Beeblebrox (talk) 03:12, 21 November 2013 (UTC)
Well, the functionality to do this already exists with User:EdwardsBot, just that now it's been moved into a proper MediaWiki extension. Honestly, I'd rather do it on some talk page like Wikipedia talk:MassMessage like how WT:EF handles 'edit filter manager', which would hopefully discourage random hat collecting and whatnot. This is a pretty specific right, so there arent going to be access requests everyday for it. Legoktm (talk) 04:39, 21 November 2013 (UTC)
Beeblebrox: Anyone with the ability to write a for loop can annoy literally thousands of users. :-) Anyone capable of using browser tabs can annoy literally dozens (if not hundreds) of users. --MZMcBride (talk) 05:34, 21 November 2013 (UTC)
There is an important difference: Anyone who writes a script to drop a message on a thousand talk pages is very likely to be indeffed, whereas anyone using an official tool to spam a thousand editors can claim they are following standard operating procedure ("if you don't want to read my invitation to do a survey, just delete it, what are you whining about?"). Johnuniq (talk) 08:46, 21 November 2013 (UTC)
By having a separate user right for it, anyone who abuses this feature can have the right removed - and still continue doing other sorts of edits here. עוד מישהוOd Mishehu14:09, 21 November 2013 (UTC)
Od Mishehu: I disagree. Anyone who abuses this feature should not be making other sorts of edits on this project for a long time. Obviously the strength of block has to be tied to the context, but it's something that I feel should be handled with heavy-handed blocks, considering how riled up it gets people. Sven ManguardWha?18:47, 4 December 2013 (UTC)
MassMessage is just a tool, like Huggle or AWB. If you abuse Huggle, your rollback rights get removed. If you screw up royally, you'll get blocked. Same here. Legoktm (talk) 08:51, 22 November 2013 (UTC)
I agree with Legoktm and disagree with Sven Manguard. Generally only those will get this right who's trusted and useful to the project with a valid reason to get this right. Now at first a user gets a warning if s/he misuse Huggle or AWB. So I believe that in here s/he should be warned first time. Then if user continues to abuse it then his/her right should be removed. User should not get blocked. Cause a trusted user don't abuse a tool intentionally. It happens mistakenly and you should give him/her a chance for this.--Pratyya(Hello!)17:50, 5 December 2013 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
To quote WP:STUB, There is no set size at which an article stops being a stub. Where does the 1500 character mark come from? I'm not sure stubness is something that can be determined by a bot (or at the very least, not just based on size). Writ Keeper⚇♔19:33, 7 December 2013 (UTC)
@PrimeHunter: I'm not sure. Maybe someone at WikiProject Stub Sorting knows.
Are you saying that your bot filters out all wiki/html/css formatting before checking it against that 1500 character DYK, which I'm not comfortable accepting overrides WP:STUB, threshold? Technical 13 (talk) 21:47, 7 December 2013 (UTC)
Jakob, it is not accurate to state that DYK pegs a stub at lower than 1500 prose characters (or even a non-stub at being at least 1500). DYK has 1500 prose characters as its floor for qualification for any article nominated at DYK, and also requires that the article not be a stub. There are a number of articles that I've reviewed with significantly above the 1500 number yet were clearly still stubs, and were not approved unless they were expanded further: topic coverage was overly weak among other issues. See WP:DYKSG#D7 and D11 for more information. BlueMoonset (talk) 00:40, 17 December 2013 (UTC)
I tend to agree with PrimeHunter, I'm not sure this is something that can be reliably automated. I'm sure you could come up with some detailed set of criteria to get things that would be an actual stub 99.9% of the time, but you're going to miss a lot, and trying to figure out which stub template to use besides {{stub}} is going to be very difficult. A human will still have to add other categories, add any maintenance templates, and use a more specific stub tag, so I don't really see what value this adds. Mr.Z-man21:36, 7 December 2013 (UTC)
Yes, it would be almost impossible to reliably sort stubs with a bot. I thought that might be a problem. I also see that User:MenoBot II does a lot of the other maintenance tagging, with the exception of tagging for unreferenced pages. I think that if an article does not contain {{Reflist}} (or <references/>), a references section, external links, or further reading, then it's 99.99% sure to be unreferenced. --Jakob (Scream aboutthe things I've broken) 22:14, 7 December 2013 (UTC)
Then please go to Actual malice, where you will see an article that contains inline citations but does not properly collect those citations in a separate section, and Reversible error, which contains such a section, but it uses <references /> rather than the reflist template, and ==Notes== rather than ==References== for the section heading.
In the other direction, see Brief (law), which contains one of your elements but is actually unreferenced. Due to the Article Creation Wizard, your script would miss a lot of unreferenced articles.
@WhatamIdoing: Actual malice contains an external link, therefore would be counted as referenced. As for Reversible error, I edited the parameters above. Like with all bots, there would be some false positives, but I doubt there would be very many. Currently, the bot would have a 96% accuracy rate, which could easily be improved. I fail to see how the afc wizard would have anything to do with this--the bot will operate in mainspace not AFC. --Jakob (Scream aboutthe things I've broken) 20:25, 9 December 2013 (UTC)
By "external links", I had assumed that you meant ==External links== section, since it was in a list of other section headings.
Every time I come to Wikipedia and am not signed in, I get some sort of popup asking for money. There is nothing more irritating or user-unfriendly on a web site. I would much rather see advertising or decreased services than popup solicitations. I propose an absolute ban on popups.
Apollo (talk) 14:02, 10 December 2013 (UTC)
I think if you gave the WMF a large enough donation so they never had to ask for money again, you could solve that problem.--Jayron3214:42, 10 December 2013 (UTC)
There is an optout in , I think, preferences. Mayhap when I win the Mega-super-duper-set-for-life lottery, I will remedy the need fro pop ups. Better than the adds that beset some other projects. Dlohcierekim 15:51, 10 December 2013 (UTC)
Hi Apollo, how often is this happening (once a day? once a week?)? Different computers? Different browsers? I don't know what the current state of fundraising is, but earlier in the year, it was supposed to be only like one in a thousand logged-out users, and never more than once in the same computer/browser. If you're getting it a lot more often than that, then let me know, and I'll figure out who the right person is to talk to. Whatamidoing (WMF) (talk) 19:43, 10 December 2013 (UTC)
The banner requires javascript. If you don't have javascript, you won't see the banner. Like Quiddity says above, if you clear your cookies you will see the banner multiple times. @Whatamidoing (WMF): I haven't taken a look recently, but I recall the fundraising team was experimenting with the 1 out of X users idea to see how well it worked as opposed to the December fundraising drive. Unfortunately it requires cookies, so those that clear cookies will see the benner multiple times. While on other computers, I see the banner after 2 to 7 clicks. For example, I go to a page on Wikipedia, I click a link to another article and see the banner. The most clicks I could do before seeing a banner was about 7 and the least was 2. I never saw a banner on the initial click. Because I'd click to multiple articles, I always see the banner. So in that sense it's a 1 to 1 ratio. IMHO, readers that clear cookies (or have them disabled) will skew the results the Fundraising Team will see. You might want to mention that to them. Thanks. 64.40.54.101 (talk) 06:20, 13 December 2013 (UTC)
Yes, this is a known problem. If you disable cookies, then you're not supposed to get it at all. But if you accept cookies and then clear them (e.g., when you close your browser), then you look like a "new" person. (Does anyone else wish that Firefox had a "clear cookies after X days" setting, rather than "now or never"? I don't mind cookies hanging out for a week or a month—I really wish WMF cookies [and therefore login session length!] lasted longer than 30 days—but I'm irritated by the twenty-year expiration dates.) Whatamidoing (WMF) (talk) 18:06, 13 December 2013 (UTC)
When using Wikipedia only to view (on machines other than my personal one and therefore not logged in), I've seen just how excruciatingly awful the banner is. Not only does it clash with Vector's (extra web 2.0) feel, but it also annoyingly changes to a mini-banner and maintains location on the top left of the screen as you scroll past the obnoxious one at the top (if you don't close it). Really, fundraising team? Killiondude (talk) 22:52, 16 December 2013 (UTC)
Alexa rank for websites' template
I was wondering why we're using the Alexa ranking to describe websites, when there are several much more accurate and reliable services out there than can supply that data. — Preceding unsigned comment added by Noamsp (talk • contribs)
I think the basic question is, is the Alexia ranking really all that important? In the early days of the web, many website's would bragged about their Alexia ranking. But now, it is almost never mentioned. So what really is the point of providing the Alexia ranking in an article about a website? It doesn't tell the general reader anything about the website, but is a meaningless number to the general reader. 24.149.119.20 (talk) 23:17, 15 December 2013 (UTC)
A global ranking like Alexa or SimilarWeb produce is relevant for understanding the relevance of high profile sites (Facebook, Google, Wikipedia, Yahoo etc.) but not as much if you're looking into smaller sites, like most of the sites in the list. But, showing the actual traffic number is more interesting and indicative IMHO. For example, both services will indicate that Wikipedia's global ranking is 7, but SimilarWeb can also estimate the actual number of visitors (in Wikipedia's case, 2.4B)
Propose merging "Show Preview" and "Show Changes" options when editing
Its pretty simple but I think we can benefit from it. Since the options are merged when we're looking at the history page or in our watchlist, why do we keep them separate when we edit? I think this'll save ppl a lot of time when they are precatious but want to finish it as fast as possible.Lucia Black (talk) 05:30, 16 December 2013 (UTC)
I would object to merging them, as it would move the preview down the page, but I would support having the show changes button act like the compare histories function and show both the changed code as well as a preview of the page/section. VanIsaacWSVexcontribs05:52, 16 December 2013 (UTC)
The opposing isn't as strong as the support. I personally don't mind. Sometimes the change is needed to be seen before the preview. Perhaps collapsibility for change option in both proposed merger and those that are already merged such as the preview link in history pages, and the diff link in our watchlist.Lucia Black (talk) 05:56, 16 December 2013 (UTC)
I don't want this. It's difficult to manage large articles this way, especially if you make changes in several places.
However, I thought that there was, once upon a time, a (rather unpopular) prefs setting or script that provided this option for people who wanted it. I can't find it now. WhatamIdoing (talk) 20:09, 16 December 2013 (UTC)
I oppose this also. Nine times out of ten, all I want is preview, and I don't want the diffs on the screen. The one time I want to show changes, what I'm most interested in is the changes, usually because I've substituted a word or something technical, and then I don't want the preview. They're two separate tools, and I don't see what's to be gained by merging them for the general population. —C.Fred (talk) 20:15, 16 December 2013 (UTC)
I agree with WhatamIdoing. Doing a diff+preview for a lot of changes for a large article can be a lot of stuff to scroll through. Note that there is a "Do not show page content below diffs" preference option which makes it so diff links on watchlist/history will only show the diff, not the page. The reason there are 2 buttons is because they do 2 different things and you don't always need to use both. Mr.Z-man20:24, 16 December 2013 (UTC)
Would you all support it if the diff was collapsible for both proposed editing space and diff/prev space? What's to be gained is if someone made largescale changes and needs to see both preview and difference, it would be needed. For someone who constantly makes typos or such. Or if someone made a mistake in citations. The diff sometimes doesn't show the flaws right away.
But I'll compromise. We should have the option to see both at the same time.Lucia Black (talk) 21:08, 16 December 2013 (UTC)
No. It still has to generate the diff and send the data for it, which takes time. Or if I only want the diff, it still has to generate the preview. You still seem to be suggesting that everyone be forced to use a system that's more efficient for only a few people, and slower for everyone else. If someone wants to make a script to do this, that would be fine. But the only way I would support this in the software would be if there was a user preference for it, disabled by default. Mr.Z-man21:42, 16 December 2013 (UTC)
Speed has never really stopped a proposal in the past. Are you saying that it'll make the page go significantly slower? I'm suggesting we should offer options anyways. Let's not make this into it catering you. So you will only support if it was a preference disabled by default? That knd of thing wouldn't be disabled by default. But does it hurt to change the preference? Again...I feel strong opposition basing off of flimsy reasons.Lucia Black (talk) 21:51, 16 December 2013 (UTC)
Speed has killed quite a number of proposals in the past. Perhaps you just don't remember them. And, yes, this would make reviewing edits on pages significantly slower, particularly for people who only want to see the diff. Right now, a diff at Barack Obama (a notoriously complex page) takes me 12 seconds. A page preview takes 34 seconds. There is no way that you can supply both the diff that I want plus the preview that I don't want without wasting at least 22 seconds compared to giving me just the one thing. Collapsing the preview makes no significant difference in the time. My objections to having my time pointlessly wasted, with every single edit review on every single page, merely to provide me with a preview that I do not want is not a "flimsy reason". The objection voiced by a couple of people that it would require much more scrolling is also not a "flimsy reason" to oppose this. Scrolling is time-consuming and can be a serious problem for people with certain kinds of disabilities. If you want both, then I've got no objection to you getting both. Feel free to learn how to code, so you can write a WP:User script to do this yourself. However, I strongly object to you revoking my access to diff-only reviews. Finally, whether to request this sort of change is normally determined by the wishes of the people who show up for a discussion, and so far, only you support this idea without reservations. Rejecting your idea is not an example of catering to Mr.Z-man; instead, accepting it would be an instance of catering to you. WhatamIdoing (talk) 22:43, 16 December 2013 (UTC)
Not really, the general idea is to save time. And even if you did wanted to see the diff only, that can be arranged too by keeping it optional. But let's be realistic too. Let's say you edit Barrack Obama article from the opening post down to the very reference page. It would take more than 12 seconds, just to be sure that there weren't any mistakes in just the diff, especially if you're adding in citations, preview would be needed more. Also let's consider how long it really takes, realistically from looking at the barrack obama page, it would take even less time then wha you claim. If it takes longer, its not to just get it done, its because you'll be using both sides to it and looking at it thoroughly.
But I would like your support out of selflessness, afterall the compromise now is to have the option. Its not "catering" me if you support because its not about me, its about those who need it. On the otherhand, somehone making unrealistic conditions such as being optional and automatically disabled, is like saying only if I never get to fix it.
Me? I find it useful enough, a nuissance? Maybe at first. But others might see the need for it. I'll take If you want both, then I've got no objection to you getting both. Feel free to learn how to code, so you can write a WP:User script to do this yourself. However, I strongly object to you revoking my access to diff-only reviews. as a support as long as I find another editor willing to do it.
Killiondude. It maybe your internet provider or computer, but everything here runs smoothly. Plus its an option that technically already exists.Lucia Black (talk) 23:00, 16 December 2013 (UTC)
I can look into coding a userscript for this a bit later today. I know I'd find it useful, and I don't think it'll be too hard. I don't know that it needs to be a gadget or otherwise default feature of the site though. Writ Keeper⚇♔23:05, 16 December 2013 (UTC)
Could there somehow be a pair of checkboxes, so that a user could specify a diff, a preview, or both, as the user's case might suggest? Or some other interface for making the choice on a case by case basis, perhaps with a preference for the default. DES(talk)00:42, 17 December 2013 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I know that some articles in this wiki are inappropriate for certain contributors. I am requesting a search filtering to prevent unregistered (anonymous) users and users registered a minors to view such Wikipedia pages. I'm also requesting a template that warns users about its explicit adult content. -- Ismael755 — Preceding unsigned comment added by Ismael755 (talk • contribs) 04:17, 20 December 2013 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
There is currently an RFC opened at the village pump to clarify current consensus and policies about the controversial pseudo-namespace redirects that you might want to participate in. TeleComNasSprVen (talk • contribs) 23:48, 20 December 2013 (UTC)
Proposal to move the Orphan tags to the talk page
There is consensus to move orphan tags to the talk page, including with a bot. There were various proposals to create some type of new class of "minor maintenance templates," but they did not gain widespread support. Ramaksoud2000(Talk to me)20:41, 19 December 2013 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Hi. I'll make this short and quick. I'm still struggling to see how useful the {{Orphan}} tag is. It's big, it's ugly, and it concerns a very very minor problem that most of the times does not really have a solution. Some articles are simply about subjects that have not been mentioned in any other Wikipedia articles. As the VERY large backlog in Wikipedia:WikiProject Orphanage makes quite clear. Forcing editors to link them or add them even in places where they are only vaguely relevant is not good practice. Neither does it concern any of the readers, but it's them who have to see the tag first thing on the page. If it was a problem on sources, I would understand, as readers should know about it. But not being linked enough is not that serious of a problem to merit defacing an article.
I propose that the tag itself be moved to the talk page to minimize its impact on the article's readability.
Note that I do not know how this can be accomplished (probably by a bot?) Neither do I really have the time to make this a formal proposal, but I'm simply fed up at seeing it all the time for otherwise perfectly fine articles. What does everyone else think?-- OBSIDIAN†SOUL01:41, 14 November 2013 (UTC)
I can't imagine in what way a template that is formatted exactly the same as every other content notice and is barely two lines of text tall could possibly be construed as both "big" and "ugly". I would argue that the article page is the only place where it will do any good. If the original creator or other contributing editors had thought of incoming links that had been appropriate, they probably would have already done it. It's the drive-by reader, who searches and finds the orphan page, ostensibly after having been reading a related article, who should see that this needs to be done. Which means that the talk page is wholly insufficient to the task of the notice. VanIsaacWSVexcontribs02:38, 14 November 2013 (UTC)
It is formatted exactly in the same way, but not for the same problems. Not enough references, improper language, possible COI, those are templates that have the right to be noticed by the reader and should be screamed out prior to reading the article as a warning on the possibility that the content they were about to read may not be that reliable or in a bad shape.
But orphans? Really? It's not like those articles have problematic content or are completely inaccessible. Virtually all readers arrive on articles through search engines, not by clicking on a wikilink somewhere. And some articles again, simply can't be wikilinked elsewhere. What exactly is wrong with that? There's far more problems in shoehorning a distantly related article into another article simply because the tag tells you you need to link it. I've seen this happen when small out-of-the-way highly specialized articles get linked to high level articles by their creators where it isn't even mentioned and only vaguely relevant just because the tag tells them to.
As for regular readers, I highly doubt they would even know or care what it is for. And again, from the backlog (more than 120,000 of our articles have this tag, dating back from 2007 as a result of the rise of automated tools and drive-by tagging), they don't or (probably in most cases) can't fix it. They're basically going to stay there for eternity.
Give me one good reason why the reader has to know that the article they're reading is an orphan. And why they have to know it so urgently that it has to be the size of a bus with a big yellow threatening sign on it.
Because yes, it does affect readability. As an article writer, this kind of thing is extremely annoying. If not the talk page, how about something like the stub warning then? The one at the bottom of stub articles. At least those are placed after the text and is suitably small enough to not be defacing.
A compromise would be to move the tag to the bottom near the "no categories" tag. The categories and the linking are often being done at the same time when the article is first created, and this would separate it from the content problems being pointed out by the tags at the top of the page. —Anne Delong (talk) 04:36, 14 November 2013 (UTC)
I would be happy with having maintenance tags autocollapsed by default, with just a simple bar saying "Orphan article", "Article for Deletion candidate", etc, then having the standard "show" button to allow you to get the details. Obviously, it would require a far greater consensus than we can establish in this conversation, but it has the advantage of not requiring a bot run to alter 125 thousand articles, and the reprogramming of tools like AWB, and all the (dozens? hundreds?) tools and bots that do article tagging. VanIsaacWSVexcontribs08:52, 14 November 2013 (UTC)
Oh. This is one of the perennials? Why am I not surprised at that. That alone betrays that there really is a problem, don't you think? But yes, Anne Delong's idea is much much better in terms of what we have now. Autocollapse would be better too. Anything but that madly conspicuous "Notice me! This page has a teeny tiny problem that you need to know in the most obnoxious way possible (November, 2013)". It's just missing marquee and it could be a Vegas sign. -- OBSIDIAN†SOUL12:46, 14 November 2013 (UTC)
While the "orphan" tag points out a minor problem, some of the other tags point out major ones, such as advertising and no references. I don't think these should be collapsed. About moving the orphan tag to the bottom: I don't think it would be important that this was absolutely consistent. Without necessarily changing all of the other bots or scripts, a new bot that ran perhaps once per week or even once per month could check for articles that had had an orphan tag placed since the last time it was run and move the tags to the bottom. If a few were missed or if some were moved by other bots it would still be an improvement. The old tags would gradually melt away as links were added, and at some point a run-once bot could catch any that were left from years ago. Just talking off the top of my head here.... —Anne Delong (talk) 14:08, 14 November 2013 (UTC)
Yes. As stated above, I actually have no problems with unreferenced, COI, POV, etc. tags. It's perfectly reasonable that the reader should know about those, as it affects the actual content of the article. Orphans however, have actually nothing to do with the content, and it's a very minor problem that in the natural evolution of articles, eventually does go away. Those which don't are highly unlikely to ever be linked ever, and the orphan tag on them becomes permanent and unreasonable.-- OBSIDIAN†SOUL21:22, 14 November 2013 (UTC)
Support if de-orphaning was attempted and/or for all BLPs, businesses, and organizations (the orphans least likely to be de-orphaned in my experience). The reason that the tags "have to be" present on the page is because we're hoping that "readers" will turn into "editors" by trying to solve the problem. But if it's not (apparently) possible to solve the problem, then IMO we can safely place the tag elsewhere (or even remove it, but then some busy person might replace it later). WhatamIdoing (talk) 18:44, 14 November 2013 (UTC)
Support Orphan tags have always annoyed me as being very low value and distracting. We could have a gadget for those people that want to know about it, but at least 99% of readers will not care. Whether de-orphaning is attempted or not does not matter, there is no requirement for an article to be linked from elsewhere. Graeme Bartlett (talk) 20:33, 14 November 2013 (UTC)
Support I would create a separate category or class of "minor maintenance tags" which would be treated differently, and restructure the template code to change their display, making it less obtrusive, or else use a bot to move them to the talk page. DES(talk)21:54, 14 November 2013 (UTC)
support It might take some digging to find, but I recall making more or less this exact same proposal four or five years ago. Unlike other tags, being orphaned is not crucial information that readers should be informed of. We should treat the same way as notices for links to dab pages or broken brackets, just put it on the talk page and eventually it will be dealt with. Beeblebrox (talk) 19:57, 15 November 2013 (UTC)
Support per others. The reader should see maintenance tags that give us reason to be concerned about reliability (no refs, POV, etc.). But editor facing tags, such as this, should be kept in editor areas, i.e.: talk pages. Resolute21:39, 15 November 2013 (UTC)
Support outright removal -- the "Orphan" template, unlike other maintenance templates like {{ref improve}} or {{COI}} (random examples), provides absolutely no new information whatsoever. While other templates provide useful information that can't be acquired elsewhere (we don't have a bot that can automatically detect conflicts of interest, for example), all that the Orphan template does is provide one datapoint that is already viewable through the Wikipedia API or Special:WhatLinksHere. Additionally: should the template be removed, it would be trivial to develop a userscript to automatically inject an Orphan notice at the top of orphaned articles upon load for those who still wished to see the notice. Theopolisme(talk)00:19, 16 November 2013 (UTC)
Support Agree with the arguments above. Too many articles are tagged to death for no good reason and the least relevant ones like the orphan tag might do more harm than help. We already have some link related maintenance tags and announcements (such as DAB links and Commons image deletion) on the talk page. --ELEKHHT00:24, 16 November 2013 (UTC)
Support The fewer tags we keep on the article space, the less confusing The article itself should have only the necessary templates that affect the reader's use of the article--such things as NPOV. This probably includes tags like Unreferenced, because they too serve as a warning about reliabioity). It should not include any of the purely technical matters that may need to be improved, but do not immediately affect the readers. The failure to have appropriate links--in either direction--is not optimal for most articles, but it affects directly only the editors. DGG ( talk ) 00:49, 16 November 2013 (UTC)
Support. Normally my position might even be closer to "The more tags on the article - the better!", but the orphan tag is an exception. First, it does not indicate any problem with the article itself - the fact that it is not linked from elsewhere might be a problem for the rest of Wikipedia, but not for that article. Second, one of the main reasons to have tags on the article itself do not apply here: the user who corrects the problem is not that likely to see the tag and thus this placement does not encourage him to remove it when it ceases to apply. Third, having no incoming links simply is not that much of the problem. Actually, I'd say that a list maintained by a bot would be a good replacement for this tag... Speaking of which, Russian Wikipedia has a project to find articles that are not "orphans", but can only be reached from a very limited amount of other articles (ru:Википедия:Изолированные статьи, ru:Проект:Связность). Maybe the ones who like to work with "orphaned" articles will wish to have a look..? --Martynas Patasius (talk) 02:49, 16 November 2013 (UTC)
The Russian project is actually controversial, with a number of very vocal editors pushing it to the point that the majority of editors started to tremble at eny mention of "connectivity" in any context.--Ymblanter (talk) 12:02, 16 November 2013 (UTC)
Oppose as I feel that if an article is an orphan, what does it say about the notability of the topic. If this topic is not notable enough to be related to any of the other millions of topics, how "notable" can it really be. So, I oppose this being moved to the talk page on that basis. As for collapsing, I don't rightly see how that is very possible. I would venture to say that "most" of the uses of this template are inside of a {{Multiple issues}} grouping so it is already trimmed down to one line. I suppose it is possible for it to be a lone template and the article to have no other issues, but that just seems entirely improbable to me. Technical 13 (talk) 15:51, 17 November 2013 (UTC)
Then there are multiple issues on the article page anyways and there is no need to have two edits to make two templates, one on the article page and one on the talk page needless bumping up edit counts. The whole point of this is to reduce work and template size. Have to make two separate edits defeats the purpose. Technical 13 (talk) 15:45, 19 November 2013 (UTC)
Hokay. That's some convoluted logic there. Firstly, you are (wrongly) assuming that when orphan tags exist, other problems must also exist. You do realize that {{Multiple issues}} != {{Orphan}}, right? Secondly, as already mentioned, notability is a completely separate (and a far more serious) problem. The reasons for why an article can not or does not have links to it from other articles has nothing to do with how notable a topic is. It's usually because they're highly specialized or simply because we don't have enough articles on related topics yet. Yes, as hard as it is to believe, Wikipedia is still far from being complete. Because if all orphans are non-notable, all of them should have been deleted by now. Thirdly, orphans already require you to edit multiple pages anyway. In fact, unlike the other problems that you can find in the multiple issues tag, orphans are unique in that they require you to edit other articles. Not the article which is currently an orphan. And as far as I know, de-orphanings are done by periodic bot runs.
And lastly, the whole point of this proposal is to reduce the work and template size as well, by removing one of the "issues" which doesn't belong to the other issues. An issue which is neither priority nor something the regular reader should know about. We also don't place uncategorized, stub status, the lack of pictures, low internal article assessment grading, etc. on the {{Multiple issues}} template do we? -- OBSIDIAN†SOUL04:22, 22 November 2013 (UTC)
Weak support, since being orphaned is not something very urgent, and I think a reader needs not be warned about it, unlike for example being {{unreferenced}}. Keφr17:05, 17 November 2013 (UTC)
Support removing the message from the top of the article, either by putting it on the talk page or by making the template simply add the "hidden category" but not display anything (like {{coord missing}}). The reader simply does not need this information, and it detracts from the article. Most maintenance tags warn readers about possible problems with the article, to which they need to be alerted. The fact that no articles link to it is irrelevant to the reader. PamD22:55, 18 November 2013 (UTC)
Support I don't think readers need to be warned about this, and orphan tags encourage adding dubious links to tangentially related pages. --Cerebellum (talk) 01:53, 26 November 2013 (UTC)
Support. Indeed, would support deleting the template as it's not giving useful information nor providing a workable solution (it can be difficult to work backwards to find which articles already mention the topic). SilkTork✔Tea time01:54, 27 November 2013 (UTC)
Support removal altogether. Warning tags should only be used for problems that affect the reader. Additionally, the existing orphaned tag often leads inexperienced editors to make inappropriate inward links. I like the idea of a bot notifying the creator of an orphan article, as long as the text made plain that it wasn't necessary to insert inward links if appropriate articles don't exist. Espresso Addict (talk) 03:17, 27 November 2013 (UTC)
Support per nom and the tag makes users think there is something wrong with the article as they are used to seeing tags like {{unreferenced}} or {{Disputed}} when being an orphan is not worth notifying the readers and is a small issue. Ramaksoud2000(Talk to me)06:23, 27 November 2013 (UTC)
Support Contrary to WP:UNDUE and WP:RF, these grotesque banners give undue weight to an issue which is of no interest to our readers. Most of the other banner tags should be dialled down too. Notice that every page is displayed with a link to our disclaimers. This is important legal information - more important than most clean-up tags. But it is placed at the foot of every page in an inconspicuous way. By placing some clean-up tags in banners, we exaggerate their importance and diminish the importance of the disclaimers. Most clean-up tags are, in fact, quite useless as they are so vague and lacking in actionable detail that they commonly stay on pages for years without any productive result. They result in banner blindness like the boy who cried wolf. Save banners for those things that demand immediate attention and link to a discussion, like AFD. Warden (talk) 07:43, 27 November 2013 (UTC)
Oppose Who is most likely to have an idea of which other articles should link to the orphaned article? People who are reading it! Why should we stop inviting them to do so? I find the comments above about how we don't need to "warn" the readers about orphanness to be missing the point, as maintenance tags are as much or more to invite readers to join in editing the encyclopedia as they are to "warn" them of issues. Similarly, the claims that this information is available via Special:WhatLinksHere, gadgets, and the like don't really help readers or new editors who don't know about these features. Anomie⚔13:53, 27 November 2013 (UTC)
Who are the people least likely to know or care how to properly wikilink articles? The readers. If they don't know about gadgets and special pages, chances are they don't know enough to link properly either. The vast amount of unfixed orphans already makes it clear that readers don't care to fix it (virtually all of the orphans that can be fixed, get fixed by the original authors of the article, not the readers). And even if they did, readers most likely won't have the experience to know when and how to link articles together, resulting in links being added to other articles of dubious relevance. Their only motivation after all, is that if they did that, they might be able to get rid of the ugly banner and read the article in peace. Maintenance tags are also invitations, yes, but invitations for pressing issues that need to be fixed ASAP. Being an orphan isn't a fatal error, neither is it something that requires immediate attention as again, most of them are fixed naturally as more articles are added to Wikipedia which link to them. We have other minor issues too that aren't included with the pre-lead maintenance tags precisely for this reason. -- OBSIDIAN†SOUL15:01, 27 November 2013 (UTC)
Because it's not an invitation. It's either noise to be ignored by the reader or a vague hint that something is amiss about the article. I recommend watching new editors read pages with warning templates on them. Or asking them about the experience. From my interactions, tags are plentiful enough on wikipedia that they just mentally sort anything in those boxes as 'oh these are problems'. We only consider them 'invitations' because we (as wikipedians) are collectively insane. I mean that in the most loving way possible. There's no research indicating readers are converted to editors at a higher rate due to the tags or that they read articles more critically because of them (AFAIK). I support tags on pages where there is a problem on the page which someone can fix or where there is content on the page which may not need to be removed but we may not want to present as 'whole'. Otherwise what's the point? Protonk (talk) 19:35, 27 November 2013 (UTC)
Support. I prefer the idea of a small comment at an article's end such as the placement of a stub tag. This would categorise the article without yelling "fire". Fylbecatuloustalk18:22, 27 November 2013 (UTC)
Support per Resolute. An unnecessary disturbance for the reader. I have been directed to a couple of old orphaned articles via SuggestionBot; many of these orphans have been former deputy members of the Parliament of Norway and there is often no articles to naturally insert them in, so I simply removed the tag. But at the talk page, the tag won't bother any. Regards, Iselilja (talk) 21:15, 28 November 2013 (UTC)
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. A bot run based on the current guideline of 0 links, rather than the old guideline of <3 links would be useful to work out how many of the 121,000 are really still orphans by the current rule. The-Pope (talk) 07:36, 30 November 2013 (UTC)
That makes sense. Most people voting here don't seem to care much where it's placed anyway. As long as it isn't included along with the pre-lead banners.-- OBSIDIAN†SOUL15:06, 4 December 2013 (UTC)
Strong Support from two perspectives. Firstly, if we are going to throw a big flashy tag in front of our readership, we want it to inform them of a serious problem with the article that they might not have otherwise picked up on (coi for the author, non-notable subject, etc.) Secondly, Imagine you are a new user. You have just written a shiny new article, only to have a heartless robot come along and slap ugly tags on the front of it. Some of these tags are a net benefit, but others, especially orphan tags and similar, simply discourage the new user for minimal benefit. Tazerdadog (talk) 17:36, 2 December 2013 (UTC)
Support It's a silly tag, as there is no policy that requires articles to have links to them. Strangely, the tag isn't even about fixing the article that is tagged, but about working on other articles to add links. For those interested in such minutiae, the talk page is a good place. Note: there are obscure plant articles that simply won't have an incoming link, yet the plant/subject is clearly notable enough for an article. Now I won't have to just remove the tags without fixing the 'problem.' First Light (talk) 05:23, 3 December 2013 (UTC)
Support I believe the orphan tag has value and purpose but does not need to clutter up the main article page at the. I prefer a stub like message at the bottom on the main article but a talk page template is fine too. Gizza(t)(c) 00:41, 4 December 2013 (UTC) Gizza(t)(c)00:38, 4 December 2013 (UTC)
Support moving the tag to the bottom area where {{Uncategorized}} is placed and also support auto-collapsing, although the latter may require a meta-template enhancement (a bot should be able to just move it). Oppose moving it to the talk page. Category:Orphaned articles should be populated with articles, not talk pages. Talk pages are appropriate for matters where there is actually something to discuss, such as requested moves. Discussion about which articles should be linked to the orphan isn't likely, it's just up to someone to just do it. I would also support creating a new, more subtle meta-template for this purpose, similar to the {{asbox}} (article stub box) meta-template., which may mean a new Wikipedia message box template category. – Wbm1058 (talk) 18:55, 4 December 2013 (UTC) Amending my position to say that I can even support User:PamD's proposal to effectively collapse the message box out of existence entirely, as preferable to the existing banner, though that's not my preferred solution. I often do link to orphans and remove the tag when I see it... usually it's easy to find one or two good articles to link. Maybe even a small note at the bottom? This article is an orphan. I don't patrol for these. Though if it was eliminated entirely we wouldn't even need a bot to move the tags. Wbm1058 (talk) 23:48, 4 December 2013 (UTC)Oppose simply adding the "hidden category" and not displaying anything. At a minimum, a link to #The Find link tool should be retained, for the convenience of overworked editors. Wbm1058 (talk) 16:04, 9 December 2013 (UTC)
Support My initial reaction was opposition, thinking that tags being ugly is a feature, not a bug, but after thinking about it a bit, I feel that way about tags aimed at readers, rather than editors. I started to write out my support position, but then read over some of the comments and see that User:PamD mirrored my thoughts, so I'll support with "What PamD said".--S Philbrick(Talk)22:47, 4 December 2013 (UTC)
Support moving it to the talk page (maintenance is the function of talk pages), second preference is oblivion (deletion). My position on maintaince tags (which are solely editor to editor communications -- and so excludes tags such as {{unreferenced}}} which also convey useful information to readers -- is well known (see for example Template talk:Orphan and Wikipedia talk:Perennial proposals#Move maintenance tags to talk pages and the whole argument on Wikipedia:Perennial proposals#Move maintenance tags to talk pages is bogus as there has never been consensus (until now) on this issue. One point about placing maintenance tags on the talk page that I think needs emphasising is that they can then be automated with a bot. If a bot places tags in article space editors may well remove the tag and complain to the bot pilot. But similar tags place on a talk page are unlikely to annoy other editors so much. That means an accurate category of such pages can then be automatically maintained by a bot through the tags on the talk pages, for those WikiGnomes who like to fix such things. Those doing the fixing can then decide among themselves what is an appropriate level to the number of links to without those who think the template is unnecessary in article space trying to have it put as low as possible. -- PBS (talk) 14:45, 5 December 2013 (UTC)
Support - the tags should either be removed from the articles (putting them on the talk page would work) or be invisible. The average reader of these articles would be more likely to botch the job than do it correctly, and the problem is relatively minor (unlike, for example, the {{hoax}} tag or even the {{coi}} tag, which suggest the article's reliability level is below what can be accepted here). עוד מישהוOd Mishehu16:37, 5 December 2013 (UTC)
Conditional Support. But only moved to the bottom of the page and/or hidden. Oppose any move to talk pages—which only makes it harder on those who target these for editing. GenQuest"Talk to Me"18:36, 5 December 2013 (UTC)
Support - it's high time this was done. The tag at the top of the article is a disproportionate distraction to the actual importance of the tag. Much better to place it on the talk page. Jusdafax01:01, 7 December 2013 (UTC)
That is of course a ridiculous position, as any "improvements" have to be to other articles, not the one that's being tagged. EricCorbett03:02, 8 December 2013 (UTC)
Support being moved to the talk page (or removed completely). The less we advertise our articles' minor problems to our readers, the better. iMatthew / talk04:03, 8 December 2013 (UTC)
Support per PamD and SPhilbrick ("either by putting it on the talk page or by making the template simply add the "hidden category"") –Quiddity (talk) 23:24, 8 December 2013 (UTC)
Support. About time. This has been discussed in the past, it's a constant headache. As per above, uglification and alienation of the article is not worth any small benefit. Save the big honkin' tags for serious problems. Herostratus (talk) 08:55, 9 December 2013 (UTC)
Yes, probably. I had forgotten about that one. It's hard to keep track of all that stuff. I guess it could be a compromise. I guess my desired outcome in order of preference would be 1) move it to the talk page, 2) move it to the bottom of articles, 3) recast it as smaller box. Herostratus (talk) 17:21, 9 December 2013 (UTC)
I agree with getting rid of the template, but I'm not sure that the talkpage is the right place. My preference would be to replace the template with a hidden category, ideally one that was autogenerated by the system. That would work for the people looking for orphans to de-orphan, and would also work for our readers. No-one minds the odd maintenance category. ϢereSpielChequers22:54, 10 December 2013 (UTC)
Support and call for snow close. Gives undue weight to an issue which is of interest to editors but not to our readers. In my humble opinion, anyone who wishes to really understand this should look at the following two pages:
Oppose - The orphan tag doesn't necessarily indicate a problem with the page itself, just that someone should find other articles it is relevant to and link to it. A Wikipedia page that isn't linked from any other article is almost useless; it is practically unreachable. If an article has not been created until now, and it is an orphan, and no one can find any other highly relevant article to link to it from, it gives a very strong (and very useful) signal that the new page may not be notable. This is useful for cleaning out new articles that are not meant to be on Wikipedia. I may have agreed with this if it was the year 2005 or something, but in 2013, the Orphan tag is very useful and very telling. Ithinkicahn (talk) 05:45, 25 December 2013 (UTC)
And there are many scripts that will do this too such as in page patrol and AFC. So we should arrange that these do not add the template. (As a temporary remediation the template could be invisible on the page). Graeme Bartlett (talk) 20:31, 16 November 2013 (UTC)
I seldom delve into the deeper aspects of maintenance in Wikipedia. So if any of you know how to attract a larger number of editors to !vote on this so we can get a consensus please do so. Same with how this could be implemented if it passes.-- OBSIDIAN†SOUL21:38, 16 November 2013 (UTC)
Comment - It's important that editors be encouraged to link articles to each other. If the orphan notification is not to be at the top of the article, it could be (1) a tag at the bottom of the article near the "category improvement" tag, (2) a category of its own, (3) a tag on the talk page, or (4) not displayed at all, but kept track of in a hidden way, or (5) ignored totally. I prefer option 1, because fixing up categories and linking pages are often done together when pages are new, but there may be advantages to other ways. One good thing about a visible tag is that it's easy to find all of the orphan pages by using the "What links here" search. Another possibility would be to have two tags, one for new articles which no one had tried to link, and a second less conspicuous one for articles that really were (at the time) unique topics. —Anne Delong (talk) 21:45, 16 November 2013 (UTC)
(edit conflict) If this should gain consensus there are several methods that could be used to implement it:
Modify the existing template so that it displays differently, in a page-bottom position and with a less obtrusive style;
Create an alternate template for talk page use instead;
Notify script maintainers and ask them to use the alternate temple from now on
Alternatively, modify the template further so it appears differently on talk pages than it does on article pages;
request a bot or bot-task to move existing uses to talk pages, or request bot-authorization to use AWB for this purpose, once a talk-page-appropriate version of the template has been created.
Together, those should implement a decision (assuming one is made) to change this. DES(talk) 21:52, 16 November 2013 (UTC)
@Anne Delong, yes it is important, but it is IMO questionable how much the visible tag encourages meaningful linking. As to your options, note that a tag can also put an article in a category, as can a hidden tag, and that even a hidden tag can be traced via what-links-here. DES(talk)21:57, 16 November 2013 (UTC)
Thanks for these. I have no preferences on where it could be alternatively placed really. Just that I believe that the {{Orphan}} tag does not belong to the "reader-needs-to-know" tags that appear before the lead. These can probably be discussed in greater detail when enough editors have commented for consensus. Best with input from WikiProject Orphanage members as well(if the WikiProject is still active), as it is them who work on them, after all.-- OBSIDIAN†SOUL01:33, 19 November 2013 (UTC)
Comment: I'd suggest that the template should be amended so that it does not display anything to the reader but continues to add the hidden category Category:Orphaned articles from December 2013 etc, in the same way that {{coord missing}} does. Then any editor looking for orphans to fix can do so, and can then remove the template when it's fixed. Anyone else can ignore it. (Though as there are 121k orphaned articles in the system at present, I wonder how much point there is in even doing that?) PamD23:02, 4 December 2013 (UTC)
The problem with hiding them in article space is that the hidden categories they link to tend the to become the preserve of WikiGnomes. I think that if these maintenance tags were moved to the talk page and displayed at the top of the talk page as maintenance that needs to be done then other editors are more likely to get involved (I know I would be). I think that deletion is not a good solution because even it it is acceptable for this particular template, there are other maintenance templates that may be more important but ought not to be visible in article space. Moving this one to the talk page could be test and a forerunner to iron out the bugs before others are moved to the talk page. Particularly if the placing and deletion of the template on a talk page can handed over to a bot (same goes for {{Uncategorized}} and probably may more maintenance templates where the decision is a simply binary one involving no human judgement) -- PBS (talk) 15:16, 5 December 2013 (UTC)
Realistically it's just WikiGnomes that will work on these articles, which are mostly just cruft as Guy Macon alludes to in his comment above. They find these cruft-works because they were tagged for some violation(s), often by the new page patrol. If the gnome is orphan-focused, they need no on-page notice because they find it in Category:Orphaned articles. If talk pages are categorized, then that just slows down the gnome because their next step will be to click on the article tab, then click what links here to verify. Then they need to read the article for clues on what to link to it. Often the only thing on the talk page will be a WikiProject tag, so the talk page is usually useless. I usually find these when I'm on patrol for some other problem. I just fix what I see, and usually don't bother to look at the talk page, or check what links here. So if there's not at least some small message, I'll probably just miss it. Wbm1058 (talk) 18:19, 5 December 2013 (UTC)
There are a number of other similar maintenance templates which I think are similar enough to {{Orphan}} to be included in this discussion. Take for example {{Underlinked}} which was created at 07:01, 29 September 2012 with next to no support for its creation.
One major problem is anyone can create a new maintenance/clean template for use in article space with no support or very little from other editors. Once created they are difficult to delete because the person who has created it will usually tenaciously defend their baby arguing that there is no consensus to delete it. There are quite a few of these templates listed in Wikipedia:Template messages/Cleanup.
It's not quite true that {{Underlinked}} just 'came out of nowhere' with minimal support. {{Internal links}} was an earlier version of this tag, and {{Wikify}} was often used for this purpose, but was deprecated because the term Wikify is too vague. Wbm1058 (talk) 01:01, 9 December 2013 (UTC)
Whether there had or had bot been other previous templates, there is no evidence of a discussion which involved more than a few of editors over the desirability of creating a new template called {{Underlinked}}. Besides instructions like "Wikify", "undelinked", and "dead end", are all things that ought to be on the talk page not in article space. Then if someone really does not understand what "Wikify" means it can be explained to them in Janet and John terms. If a editor were to write at the top of an article in indented italic text "I think this article in underlinked" they would be told that such comments belong on the talk page not in article space. Placing it in a box does not change the essence of the message or where it should reside. Placing text into an article that starts "this list is incomplete" would not be deleted because it is a useful warning to readers whether or not a reader becomes an editor by helping by expanding it. -- PBS (talk) 08:34, 9 December 2013 (UTC)
Wikipedia:WikiProject Wikify is an established and fairly active project and it should be clear from the project page and the project's logo that adding internal links is a core function, if not the core function of the project. So, whether or not there was extensive discussion, there is widespread de facto support for that template, or some naming variant of it.
An editor writing "I think this article in underlinked" at the top of an article in indented italic text is probably more likely to find their edit converted into an {{Underlinked}} template than flat-out reverted or moved to the talk page.
Adding internal links may or may not be a core function (see the fuss over over-linking particularly dates), but that is beside the point of whether such templates as {{Underlinked}} should be placed in article space. Back in 2007 I wrote about how editors can and often do view pages differently from readers. They can forget that most people come to a page to read about the subject not about how the presentation of the subject matter can be improved. Articles should be about the subject, talk pages should be used for how editors can improve the article (if not why not why bother with talk pages and instead just append the talk page chatter at the end of the page as is done on many blog sites?). -- PBS (talk) 15:05, 9 December 2013 (UTC)
It's thoroughly maddening to me that you laid out what should've been a sufficient case to remove/move these templates 6 years ago and got the (no offense to whichever editor replied to you) standard data-free, 'truthy' response which totally ignored your reasoning in the first place. We've been slapping templates on pages since the inception of the project, telling ourselves (despite a near total lack of evidence in support) a pretty comforting fable. Protonk (talk) 23:41, 9 December 2013 (UTC)
The section in Perennial proposals is worded in a misleading way. It implies that there is a consensus to reject the proposal, when in fact there never has been any such consensus (See the Perennial proposals talk page for more details). I think that this RfC tips the balance further towards discouraging their use in article space. -- PBS (talk) 14:49, 9 December 2013 (UTC)
Oh I see: Wikipedia talk:Perennial proposals#Move maintenance tags to talk pages. Regarding your movies analogy, yeah, I'll agree that the current bold templates at the top might be like turning on the actors' and directors' commentary on a DVD. But why would moving the tag to the bottom and toning it down be harmful? That would be more like rolling the credits at the end of the DVD. Just as viewers are free to walk out of the theater or eject the DVD or turn off the TV, readers are free to just quit reading when they get to that point. I'd guess that the readers most likely to become editors of a particular article are those that take the time to read to the end of the article. Those just casually reading the lead before clicking off to elsewhere are the least likely to edit—and the most likely to be annoyed by in-your-face tags. And I do find the orphan tag useful as a reader. It tells me that the article is poorly integrated into the encyclopedia, which makes me question its reliability and notability. So I may not trust the article as much as articles lacking the tag. Wbm1058 (talk) 15:50, 9 December 2013 (UTC)
On articles with large reference sections, how many people will read past them to see what's at the very bottom of the article, unless they're looking for external links or navboxes? Anomie⚔19:18, 9 December 2013 (UTC)
I am sorry you posting is not clear to me. Are you advocating placing them at the bottom or the top? -- PBS (talk) 13:09, 10 December 2013 (UTC)
@Anomie: We can only guess on how many read to the end, and how much, if any, reduction in orphan-linking activity a move to the bottom would cause. I'd wager that very few well-developed articles with large reference sections are orphans. Many more orphans are stubs, where the top and bottom all fit on a widescreen HD monitor, or minimal scrolling is needed to get to the end. I share your concern about finding ways to increase orphan-linking edits. Along those lines, I think improvements to the message box text emphasizing that there is a nice tool to help may be more important than where on the screen the message is placed (see the next section). I think a bot-generated list of the most potentially link-able articles, using the Find link tool's algorithm, could be a big stimulant to orphan-linking similar to how the to-do list at Wikipedia:Disambiguation pages with links helps with that project, and would get our most significant orphans needing help knocked off faster. As to linking the articles of lesser notability, I just picked a longstanding one at random, and it happens to be what I feel is typical. Ken Nimori is in Category:Oregon State University alumni. It would be nice to create a lookup table that paired that category with List of Oregon State University alumni. Every member of the category should be in the list. I'd guess that hundreds of such pairs could be created. Then have a bot compare the categories with the lists and put orphans like Ken Nimori into the See also section of List of Oregon State University alumni, where a human editor could then find the correct section to move him to. I think a phased implementation of a move to the bottom would work best and cause the least disruption. Allow the tag to be at the top or the bottom during an indefinite phase-in period. When encased in {{multiple issues}} it will of course still be at the top. Over time the bots and AWB can start adding new ones at the bottom. If we find that the move causes a significant reduction in orphan-linking, then the move can be reversed before too much damage is done. I'll create a sandbox version of what I think could be a good, less cartoon-like bottom-dwelling template that would be less in-your-face but should still get noticed. Best regards, Wbm1058 (talk) 00:30, 11 December 2013 (UTC)
I think we are getting side-tract here. The specific points that Wbm1058 has raised in this last posting should be in the previous section I am going to place a comment in the previous section about it. -- PBS (talk) 11:09, 11 December 2013 (UTC)
The Find link tool
How many of you are aware of and have used Find link? I'll confess that I'd read this template many times, and assuming that suggestions may be available was just a link to some "helpful advice" on how to go about finding articles to link to the orphan, never bothered to click on that link because "I already knew how to do that". So I was very pleasantly surprised to find that this was a link to a very useful tool. I'd suggest changing the vague "suggestions may be available" to "try the Find link tool", and see if that doesn't draw more traffic to the tool. I think some may find it fun to use, perhaps a bit addicting. I think it's a shame that when this template is sandwiched inside {{multiple issues}} the link to the tool is removed. We have bots running that are efficiently tagging orphans, e.g., monstrous coalition was recently tagged. I just used the tool to link that to seven articles. That was like hitting the jackpot. Often the tool comes up empty. When the tool doesn't find the article title anywhere in the encyclopedia, then you have a "super-orphan", and we have a lot of those. It may be helpful to have a bot run this tool on everything and generate a list of the most potentially link-able articles for further attention by human editors, so we make the most impact with our time. – Wbm1058 (talk) 03:49, 9 December 2013 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Right now, we have some articles that have now been moved into the draft namespace. In the old days, you might have them under article titles like, "User:XYZ/Something." Now, they are under titles such as, "Draft:XYZ." In the days when everything was in the userspace, Articles for creation space, and wherever else people placed their submissions, it was harder to nullify the categories. Now that we have them in one space (well, in theory anyway), would people be adverse to having the categories either automatically nullified or have a bot do this work, so that we can remove potentially unnotable persons/places/things from general categories? It would remove a lot of the clutter that currently exists in these categories, which often contain half-worked on articles and ideas, and it would help to clean up the site. Plus, when the articles are moved, the site could be set up to automatically include these categories, like what goes on in the AFC submission process right now. Kevin Rutherford (talk) 07:14, 24 December 2013 (UTC)
Over the past couple of days, there have been several reports of vandalism or "hacking" at WP:AN and WP:ANI regarding template vandalism. The vandals target highly used templates that will transclude on lots of articles by placing images in the template to catch readers off-guard and shock them with nudity or something gross. There's obviously very little we can do other than revert the vandalism, protect the template, mark the image as a "bad image" and block the editor as of this moment.
My proposal is short, though the technical aspect of implementing it is a bit more complicated: To add images to the template namespace, an editor must have the autoconfirmed right. After filing a bugzilla and requesting it be changed, when the save button is hit, if the edit would transclude an image in the template namespace, the software would perform a check on the account and if it doesn't have autoconfirmed on their account, then the save will be stopped and brought back to the preview window with a message telling them they do not have the proper rights.
The result would be:
There would not be any IPs adding any images to templates, which is almost always reverted anyways because most unregistered users do not understand how to either correctly places images in template syntax or they don't understand that images are not a common thing in the template namespace. In regards to the problem, a majority of the vandalism comes from IPs as well. Forcing autoconfirmed for saving images would force them to at least create an account.
Brand new accounts with the intent to add images to vandalize wouldn't work either, because the autoconfirmed permission means they have to wait about four days and make ten edits, which makes template vandalism almost pointless if they have to wait for days and make edits that won't get them blocked. Vandals get bored that way.
To users who aren't brand new, it doesn't change anything.
The only potential collateral would be a brand new, well-intentioned user who is trying to insert a legitimate image into the template namespace and not being able to, and that is going to be a fairly low number of users who experience this problem.
There's too many ways someone could get around that (not discussing how per WP:BEANS; if you want to know I'll email you). It'd be almost impossible to completely prevent it without effectively semi-protecting all templates. Jackmcbarn (talk) 04:30, 19 December 2013 (UTC)
It's not intended to be a solution that will end the problem, there's effectively no way to end any vandalism outside of full protection so only administrators can edit the page. Of course there's ways to get around it, but it will still stop the majority of it. It's intended to slow down the problem, not to be complete prevention. It's becoming a daily occurrence, and we need to change something other than just wait it out and have readers stumble across an image of a woman peeing again. Regards, — MoeEpsilon04:40, 19 December 2013 (UTC)
Actually, there are two other pieces of collateral not mentioned: 1) regular editors editing from an insecure connection, where logging in could compromise their account, and 2) regular editors without an account. Both of these groups would be adversely effected by a semiprotect-esque edit filter on the entire template namespace. So I would have to oppose something like this. I would, however, be supportive of looking at expanding WP:High-risk templates to draw up criteria for semi-protecting semi-widely transcluded templates, including mature wikiproject infoboxes and expansive navboxes. VanIsaacWSVexcontribs05:13, 19 December 2013 (UTC)
"Regular editors without accounts" — this is a perennial (almost hallowed) objection to any suggestion of restricting IP access. How many of these are there? How is "regular" defined, and how substantial are their collective contributions relative to the work not done because time and effort spent cleaning up after irrregular IP editing? ~ J. Johnson (JJ) (talk) 22:01, 20 December 2013 (UTC)
How many long-term IPs are there? I've encountered enough that when I see a proposal like this, I think "but that would keep regular IP editors from doing X", but few enough that when I run into an issue with an IP, I don't give more than a passing thought to the possibility that they are actually a long-term IP editor. But you chose to ignore the possibility of other lines of inquiry - about expanding the high-risk template definitions to bring in default semi-protection for the kinds of templates where this could be a problem - so I don't know whether you are actually taking any of this seriously, or whether there's something else going on entirely that I'm not seeing. VanIsaacWSVexcontribs12:30, 21 December 2013 (UTC)
The proportion of IP editors that are "regular" (good? serious?) is small, just because of the large base, and I suspect their total number as well. But what I am curious about is: how substantial are the supposed contributions of these purported "regular IP editors" relative to the work necessitated by not having everything semi-protected? ~ J. Johnson (JJ) (talk) 20:27, 21 December 2013 (UTC)
Quite frankly, I don't know, and I'm not sure that anyone can even make an educated guess on it. You usually don't ever follow up on figuring that sort of thing out unless there is a conflict of some kind, which horribly biases personal experience, and tools can't see through dynamic IPs. We're actually dealing with five different populations here, and it's almost impossible to distinguish between many of them, let alone make any sort of comparitive enumeration: 1) single incident IP vandals 2) short-term IP editors involved in edit conflicts 3) short-term, productive IP editors not involved in edit conflicts 4) long-term, productive IP editors involved in edit conflicts 5) long-term, productive IP editors not involved in edit conflicts. Because IPs get dynamically allocated, there is no tool that can tell us the difference between #2 and #4 or #3 and #5, there is basically no means of ever really being able to notice #3 or #5, or determine whether you have seven different #3s or a single #5, and #1 is the only group that you are trying to target, but #2, #3, #4, and #5 are all getting caught in the crossfire. I don't know the answer, but I would certainly argue that making a blanket ban on editing templates with an image tag in them is an overreaction. VanIsaacWSVexcontribs21:57, 21 December 2013 (UTC)
One of the only things that Visual Editor was good for was providing a peek at behavioural choices. When given a choice, new accounts used Visual Editor about 25% of the time, IPs about 10% of the time, and established editors about 8% of the time. A little bit of number crunching on that factoid would indicate that about 80% of IP editors are experienced editors. Certainly not a number to quote as gospel truth, but an interesting indicator nonetheless.—Kww(talk) 00:37, 22 December 2013 (UTC)
Yes, I found that stat quite interesting. But "experience" does not necessarily correlate with "good"; it may mean nothing more than most vandals are experienced. I think it tells us nothing about all the good work IP's allegedly do. ~ J. Johnson (JJ) (talk) 00:44, 23 December 2013 (UTC)
Oppose as this hasn't been much of a problem for years. That tells me that for years, IP editors have been adding useful and proper images to templates with only an occasional vandal mucking with things. That leaves me the impression that this would leave way too much collateral damage to be worth doing. This would also prevent an IP from making edits to templates that include an image (even if they didn't place it there). So, if they wanted to update a flag icon template for example to adjust the range of years or correct a typo of a country name in a rarely used version, they would be unable to and be required to submit an edit request. This is too tedious and I think is a bad idea. Technical 13 (talk) 12:59, 19 December 2013 (UTC)
This is actually been a problem for a years, it's just that vandals get more creative with time, it's the whole reason why the page for high risk templates exist and has existed for so long. Finding gross or nudity-laced images and pluging them into templates to shock readers has been a long-standing vandal tactic. It's just a matter of finding an image that isn't marked as "bad" and finding a new template that hasn't been protected yet, and a vandal as of late has just been exploiting less high-risk templates that still spread to hundreds of articles, forcing us to protect things that are not high-risk. Also, your fear that IP editors wouldn't be able to edit a template with an existing image is not needed. When you click the save button, the software identifies what text needs to be changed, shown in diffs in the history and not surrounding text unrelated to the edit. The proposal is to have the software interpret new text being inserted and if it would render [[File:imagename.extension]] or [[Image:imagename.extension]] successfully, a check of permissions for the user would be done. Existing images would not be an issue, and the fear of high collateral isn't really warranted either. Images are not highly used in the template namespace, and outside of regular editors logged out, most IP editors would not know when or how to insert an image that wouldn't be reverted. Regards, — MoeEpsilon17:42, 19 December 2013 (UTC)
The problem is that figuring out whether it would render [[File:imagename.extension]] or [[Image:imagename.extension]] is extremely hard to do (impossible, actually, since the Halting problem is unsolvable). There'd either be a ton of false positives, effectively semi-protecting all templates, or a ton of false negatives, making the protection worthless. Jackmcbarn (talk) 17:53, 19 December 2013 (UTC)
Uh, how is that related to the halting problem? It's just a regex search for whether added_text contains /\[\[(File|Image):[^\]]+\]\]/, (or something like that). Writ Keeper⚇♔18:01, 19 December 2013 (UTC)
To clarify, if someone just sticks [[File:imagename.extension]] straight into a template, that's easy to detect, but there's ways they could add an image (poke me if you want an example emailed) without doing that, which we wouldn't be able to detect. Jackmcbarn (talk) 18:49, 19 December 2013 (UTC)
The filter code is hidden from public view but in order to reduce false positives, it only activates under certain conditions (which we don't want determined vandals to know) and it doesn't prevent the edit, it only logs it (the linked edit wasn't logged). PrimeHunter (talk) 19:33, 19 December 2013 (UTC)
Question - Is this a case where some variant of Pending Changes (something like Pending Changes 2 perhaps) for these high risk/high use templates would be useful? If it stops the vandalism going live across Wikipedia then it takes away the point of it - and it may also help to minimise the potential for people accidentally brwaking high use templates.Nigel Ish (talk) 23:35, 21 December 2013 (UTC)
Alas, pending changes Level 2 is not an option.
Extended content
Interaction of Wikipedia user groups and page protection levels
All users can edit Edits by unregistered or newly registered editors (and any subsequent edits by anyone) are hidden from readers who are not logged in until reviewed by a pending changes reviewer or administrator. Logged-in editors see all edits, whether accepted or not.
Infrequently edited pages with high levels of vandalism, BLP violations, edit-warring, or other disruption from unregistered and new users.
Specific topic areas authorized by ArbCom, pages where semi-protection has failed, or high-risk templates where template protection would be too restrictive.
Why isn't PC2 an option? That RFC only said not to use it (normally; there have been a very small number of accepted exceptions) for six months or so after PC1 was available. There's nothing there that says PC2 may absolutely never be used—and even if it did, then WP:Consensus can change. If this is an especially good use case for PC2, then just make a WP:PROPOSAL to do so. WhatamIdoing (talk) 18:14, 23 December 2013 (UTC)
It's a technical issue, not a policy one. Pending changes protection doesn't work through transclusion. The latest version is always transcluded, even if it's not accepted. Jackmcbarn (talk) 18:23, 23 December 2013 (UTC)
I think that because an administrator is no longer needed, the threshold for what constitutes a "high-risk template" should be lowered. Perhaps we should start at half of the transclusion count of what it was for full protection? What was that threshold exactly anyways, does anyone know? I've seen as low as about 2,000. Comments? Complaints? I'm sure there will be both to this idea, so we might as well get them now. Technical 13 (talk) 05:52, 22 December 2013 (UTC)
I'm not exactly sure. The high-risk templates guideline says each template was considered individually, which might need to be individually re-evaluated. Obviously a high transclusion count matters, but templates that are highly visible and not cascade protected and templates substituted often are also high-risk. Likewise, one-time targets for hit-and-run vandalism and transclude on a small number of pages should not have been semi-protected. I'm curious how abuse filter 599 is doing, since I can't view what it is logging. Regards, — MoeEpsilon07:49, 22 December 2013 (UTC)
Oppose This completely violates the template editor RfC. "It should be understood that the standards for what constitutes a high-risk template should remain unchanged and not be expanded, despite this newly created protection level and rights group."Jackmcbarn (talk) 16:19, 22 December 2013 (UTC)
I'm not proposing to change it solely on the bases of there being a new userright. I'm proposing changing the threshold because there is now evidence of vandalism on templates with a lower level of transclusion. There is a big difference there, I do hope you see it. Technical 13 (talk) 00:06, 23 December 2013 (UTC)
You said above, "because an administrator is no longer needed". That's exactly equivalent to being because of the new userright. Jackmcbarn (talk) 17:08, 23 December 2013 (UTC)
Yes, I seem to recall that during the Rfc there were a number of editors who opposed the new right because they believed that over time those with the right would find reasons to gradually protect more and more templates, causing frustration for those without it. —Anne Delong (talk) 05:51, 23 December 2013 (UTC)
I'd rather see a solution that added history information for transclusions, and if possible a summary added or removed images to the history pages. For example if article used template:Infobox_Foobar then the most recent changes to that template should be shown in the history. It wouldn't need to show the full history for the templates, just the most recent one for each template with a link to the full history. PaleAqua (talk) 08:26, 23 December 2013 (UTC)
I'm familiar with that script. It's why I think doing this for history page should be doable. The history page is seems to me to be a better place than the preview page for dealing with vandalism. The first check I make when noticing a page has been vandalized is the history page, I assume that this is fairly common. Furthermore, the editors that wouldn't automatically consider that a template change might be a cause, would likely also not be the ones to add a custom js script to common.js file. PaleAqua (talk) 18:09, 23 December 2013 (UTC)
All this really needs is a fast method of discovering and reverting template vandalism. Most of the complaints have been slow to be fixed because people have trouble discovering them. Like, is it any harder than using "Related changes" on a vandalized page and limiting to template namespace? If not, then instructions should be part of the AN/ANI editnotice. People are still going to run to ANI and associated boards as soon as an article shows some sign of vandalism, whether it's from a template or not, because they're not comfortable editing Wikipedia. —/Mendaliv/2¢/Δ's/ 08:43, 29 December 2013 (UTC)
As one of the editors who dealt with the fallout of one of the instances of this vandalism, there is anoher factor that I noticed coming into play here. Even after the template was reverted, several editors reported seeing the old vandalised template on several articles. (This, despite the fact that I was unable to see the same).
This had something to deal with purging of pages, and though I do not understand the technicalities of it, we must make sure our vandal-fighters know of this to make sure a vandalised version is not shown to some of the readers. TheOriginalSoni (talk) 11:17, 29 December 2013 (UTC)
The technicalities are thus: pages are purged automatically when a dependent template is changed, but it's not immediate (as it is when you hit the action=purge button on such a page). They go to the bottom of the job queue. Perhaps there should be a mechanism for bumping template vandalism reversions to the top of the job queue (e.g., the person who reverts would probably post a request at AN/ANI, and an individual with advanced permissions would be authorized to force such a cascading purge), though I imagine this would take developer intervention at the MediaWiki level. —/Mendaliv/2¢/Δ's/ 11:25, 29 December 2013 (UTC)
A script would probably work, but I think there are issues approaching WP:BEANS territory. I'd really rather see something implemented at the developer level that both handles this and blocks what activity I'm concerned about with scripting. —/Mendaliv/2¢/Δ's/ 12:52, 29 December 2013 (UTC)
Given the recent spurt of planned template vandalism, I have reason to believe that we need some sort of restrictions on IPs editing templates, even if as an interim/temporary measure. I agree there would be collateral, but we can deal with them using some sort of {{Template-edit}}template that can be placed on the talk page to request Template edits (Similar to how our current {{Help me}} works) TheOriginalSoni (talk) 11:17, 29 December 2013 (UTC)
As New Year is coming soon, so I'd like to propose that we adopt special New Year-theme appearance for our File:Wiki.png for only two days – 31/12'13 and 01/01'14. As I can see from file upload history, this wasn't a practice before. (Maybe it didn't occur to anyone.) But why wouldn't we make our Wiki space nicer with special holiday details? I have no doubts many of us were extremely hard-working this year, so we have so much to celebrate. Don't you think? Alexdiscussion★08:57, 26 December 2013 (UTC)
@Aleksa Lukic: I like the spirit of the idea but I'm not too sure about whether it should actually be done. At present, and as far as I am aware, we do not and have never changed the logo for any other ceremony or festival, apart from the tenth anniversary celebrations. By celebrating New Year, not only have we selected the Gregorian calendar's date of the New Year for 'special treatment' against others (i.e. the Chinese New Year), which would only seem to exacerbate the systematic bias towards the western world on enwp. If editors would like to commemorate events, they can nominate articles for special days at DYK, TFA, FP etc., though I personally would be sympathetic to sometimes changing the logo as a fun, light-hearted way of marking secular, non-controversial and apolitical events (whatever they may be). Sorry to be a party pooper, but I'd think we'd need general consensus on changinng the logo for events in principle rather than just for this specific New Years Day. Also, it's a little late - could we get a decent logo mocked up and decided on in time? I doubt it, unfortunately. :( Acather96 (click here to contact me) 22:33, 27 December 2013 (UTC)
Completely agree with what Acather said. I like the idea of changing our logo for specific occasions, but we need widespread consensus for the given select events (and designated alternate logos) before we implement that. Certainly an idea to be pondered over for a longer discussion. TheOriginalSoni (talk) 00:11, 28 December 2013 (UTC)
I agree with what Acather has said, but I would like to add that since I like this idea (and something along the same lines is something that I actually set up on DDOwiki) I would be willing to write a userscript that would be available to anyone that would like to see this be something available. I actually have another script that changes that image to symbolize that there is something going on on a page that is .sysop-show (a hidden section designed for admins and template editors) so that a setting can be toggled to show or hide those comments and notes. So, if I can find someone willing to create the proper sized .svg images for this proposal, I would be happy to write a script that will change the image on the correct days for whichever holidays or events that have available images. I could have it customized so each user could define a list of holidays in their userspace. Let me know if this would be an acceptable alternative to forcing holidays/religions/events on all readers and editors alike on Wikipedia. Happy editing! Technical 13 (talk) 01:44, 28 December 2013 (UTC)
Following that image to commons and looking through the cat structure, there aren't a lot of holiday logos currently... I see one for Christmas, Halloween, Valentine's, St Patrick's, but none for other holidays such as New Year's, Hanukkah, Easter, Thanksgiving, Independence day (of any nation), etc... Anyone that is good with such things want to volunteer to make some logos? Technical 13 (talk) 01:57, 29 December 2013 (UTC)
Need "Like & Comment" options in all Wiki articles
Dear Wiki Team,
I suggest that there should be some "Like & Comment" options in all Wiki articles.
Just like Facebook, these two options make articles more attractive.
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)
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. --NeilNtalk to me04:44, 7 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)
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)
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). Novusunatalk22: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)
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)
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)
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)
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.Graham11: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.Graham18: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)
Oh, sorry, I get it now. The dates are for bots to use that periodically visit and fix date formats or dialects, so you know the last time that a bot passed by to check for date or format inconsistencies. Wbm1058 (talk) 22:52, 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)
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 this. 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)
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.Graham14:56, 9 January 2014 (UTC)
More likely something like <span id="UseEnglish" data-which="XXX"></span>. The script would look for that id and read out the data-which parameter. Anomie⚔01:12, 10 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)
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 ▎TALK23:17, 7 January 2014 (UTC)
I'm proposing that hovering over a file look something like this
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-restedTalk06: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)
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)
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 ▎TALK23: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)
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)
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. bd2412T00: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)
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)
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. Resolute14:37, 8 January 2014 (UTC)
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
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"
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)
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 ManguardWha?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)
NO, NO, NO! You do not make the decision to close this in the way you would like—and certainly not by invoking a silent consensus after wearing people down. Leave that to an uninvolved editor (preferably an admin) to make the decision to close and to decide what the consensus is. - SchroCat (talk) 19:48, 10 January 2014 (UTC)
You know, SchroCat, yesterday I thought I'd go over to Talk:Gone with the Wind (film) and give my two cents about the proposal to include one portal link on that page... and it was so filled with you bickering that I decided not to bother even looking at the article to form an opinion. If you want comments from other people at that RFC, then let me encourage you to stop re-re-re-re-re-posting your own views. In fact, I'd suggest that all of that pointless argument be blanked or hatted, and that both you and WhisperToMe should resolve not to say a single word in or about the RFC for a while. If this sounds uncannily similar to the advice you were giving WTM in that RFC, then I'll suggest to you that what's sauce for the goose is sauce for the gander. WhatamIdoing (talk) 19:59, 10 January 2014 (UTC)
WhatamIdoing, I don't know who you are, or how little you know of this (not much, given your comment above), but considering I have walked away from three discussions involving WTM, including the walls of text on my two article talk pages and on my own page (twice: I have had to archive them both to close the discussion down), then perhaps you could be just a little less judgemental when I am trying to stop someone taking a provocative and irregular step. In addition, next time, perhaps you could also get your facts straight: I have made one made no comment in the Gone with the Wind RfC (since it was an RfC, only when it was a discussion), one comment on the Prometheus thread on this page (this is only my second) and only one on the GwtW thread on this page. Thanks for being so judgemental and pissing me off more that WTM has managed to do. - SchroCat (talk) 20:16, 10 January 2014 (UTC)
If you need some sort of "credentials", then you will likely find these two links to be informative: [8][9]. I've been involved in a lot of these "My WikiProject WP:OWNs that article" discussions, including several of the ones leading up to this particular RFC.
As for the instant "discussion", you have made six comments in that thread, and most of them are basically irrelevant (Could some other, unrelated film, with "only" an American screenwriter, an American producer, an American distributor and seven American Academy Awards, possibly be considered an "American" film in any way, if the American producer technically used a British corporation for the production) or unhelpful (e.g., accusations that WTM is "missing the point entirely" and "ignoring" other people's comments by requesting them). Whether these were posted before or after the RFC tag was added is irrelevant, since the discussion was originally advertised in other ways.
And on the relevant point: whether to add a link—any link—to a specific article is best decided on a case-by-case basis by the editors at that article, not in general discussions about whether, very generally speaking, links of this type are usually a good idea. The decision to link, or not to link, this link at that article needs to be made over there, after considering all the facts and circumstances, by the people who are working on that article. That talk-page discussion isn't trying to create a policy about links. It's trying to get uninvolved people (i.e., neither of you) to express opinions about one link in one specific article. WhatamIdoing (talk) 22:41, 10 January 2014 (UTC)
I'm not sure what your boast about the credentials is all about, or why you feel the need to blow your own trumpet on this. If you have something useful to say, then get on and say it, rather than pissing other editors off. (For the record, I'm not a member of any project - a slight nod to the Bond one is the closest, but nothing else). Your second point is unhelpful, unnecessary and off topic (try to focus not on me, but at the point I made about whether the proposer of an RfC should be the one to close a discussion, based solely on people not responding to them. If you don't have an issue with that then there is more concern for your judgement than I first thought). Thirdly I am well aware of how and where such a discussion should take place, I'm slightly bemused by you calling me "involved": I have made only three edits to the article and only ever commented on that one thread. Perhaps you could examine your attitude next time you want to talk to someone and stop being so judgemental and patronising. Perhaps you could also get a few of the basic points right about what my role in this is (I've already explained that I have disengaged from WTM, and strongly suggest that you disengage from corresponding with me in future). I'll let you get back to owning the pump and trying to dictate who can interact where and when. - SchroCat (talk) 23:15, 10 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)
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)
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)
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)
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)
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)
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.
The user pointed me to Wikipedia:Advice_pages#Advice_pages (a Wikipedia guideline). Since it is a guideline it is generally to be followed, but allows for exceptions and for common sense. Anyhow, once I notified the project of this, one Film project member argued that a WikiProject should still be able to make decisions on the WikiProject page. In response the user who gave guidance stated that decisions can be made on the WikiProject page but they may not only involve the members of the WikiProject. Advice pages states:
"However, in a few cases, projects have wrongly used these pages as a means of asserting ownership over articles within their scope, such as insisting that all articles that interest the project must contain a criticism section or must not contain an infobox, and that editors of the article get no say in this because of a "consensus" within the project. An advice page written by several members of a project is no more binding on editors than an advice page written by any single individual editor. Any advice page that has not been formally approved by the community through the WP:PROPOSAL process has the actual status of an optional {{essay}}." (I have bolded the relevant parts)
My impression is that the members believe that if major contributors to certain articles don't want portals in their articles, then portals should stay out. I have heard the following sentiments:
Another user proposed that Portal:Film in the United States should only be added to an article if three editors per article agree on including that portal.
Another user argued that the users of WikiProject Film should have the right to decide how Portal:Film is used and that WikiProject Film and WikiProject United States collaborate on how Portal:Film in the United States is used. The same user stated: "Portals are NOT a requirement of articles, and if they are opposed, they are opposed." The same user asked me "Despite the opposition points raised, which are actual points against their inclusion, you have not raised counter points, your argument seems to boil down to simply that because a portal exists it should be added to an article regardless of its relation or usefulness."
Considering what the above states about the powers of WikiProjects, I think these views should be formally proposed to the community so the relationship between the WikiProject and the portals under its scope are clarified. I have offered the project to write its own, but if it does not wish to do this, I will present these views in a proposal written for the project, so the community will decide.
In summary, I am convinced that matter is for the wider community to decide, and that this is the best course of action. No policy or guideline says portals must be included but in reality the community should decide which articles have portals, not only a small group of editors. If the community consistently supports adding even one portal to each regular article then this would mean de facto an article would have to have a relevant portal. DonIago, would you mind explaining why this particular article shouldn't have this portal? Or is this only about what AdvicePages is talking about? WhisperToMe (talk) 01:45, 10 January 2014 (UTC)
My reasons have already been verbalized by other editors at the linked discussions. That you're choosing to keep pushing this despite despite numerous editors disagreeing with you is, at this point, only reinforcing my feelings that you're more interested in forwarding your own edits than working with your fellow editors. DonIago (talk) 02:34, 10 January 2014 (UTC)
Take a look above: the editors are saying different things, and there are different threads of discussion (Prometheus (2012 film), Gone with the Wind (film) and this) with different people saying different things. There is no unified message from the WikiProject members about how portals should be used, only a general aversion of portals.
However, what has frustrated me was one user's insistence that portals should not be in any project, and has refused to consider the inclusion of at least some in Prometheus (2012 film) (this is distinct from his belief that I added too many portals to the page). This insistence was not spoken against, and his repeated messages insisting on debating whether portals are necessary at all (even though this question has been discussed elsewhere and portals are being systematically used throughout Wikipedia) have shown up in many places, including an outside source discussion over whether portals have any use that categories don't jave: Wikipedia_talk:WikiProject_Portals/Archive_2#Questioning_the_need_of_portals_when_categories_exist
The use of this general belief against portals to obstruct placement of portals in specific articles, have very much frustrated me, leading me to conclude that an ultimatum was needed, and therefore a village pump proposal is needed for his specific view of no portals if he insists on it. I have advocated for a proposal to be made to settle whether this user should continue obstructing the placement of portals in articles out of his belief that portals are not necessary. Therefore his proposal would either succeed (portals are abolished) or fail (portals remain, discussed on an article by article basis) and he would instead have to discuss the merits of a particular portal in a particular article as he is supposed to.
You are welcome. Since you understand what the guideline says: If I file such a proposal affecting many articles (remember this proposal talks about one portal for one article and is not a broad proposal for many articles) what may happen is that the wider community may approve or allows the practice of the WikiProject Film to restrict usage of the portals involved, which means it will satisfy Wikipedia:Advice_pages#Advice_pages. Having this question settled is something that the Advice_pages encourages. WhisperToMe (talk) 03:23, 10 January 2014 (UTC)
Comment I don't quite understand why there is a proposal to add a portal to the "Gone with the Wind" article here. I've read through the introduction at the top of the page twice now and I still don't really know what this board is for, but I'm pretty sure it's not for discussing Gone with the Wind. If there is to be an RFC affecting GWTW it should be filed at the GWTW talk page and tagged in the appropriate manner. Betty Logan (talk) 03:25, 10 January 2014 (UTC)
Yes, I should have added the RFC tags, so I went ahead and did so. Thank you for telling me that needed to be done. I am accustomed to listing discussions at a noticeboard and therefore hadn't used the RFC tags. I went ahead and belatedly added the RFC tags for the Prometheus discussion. WhisperToMe (talk) 04:18, 10 January 2014 (UTC)
Oppose any addition of content, portals, categories, etc. that are not pertinent to the article. In fact, I see little advantage in having portals AND categories in articles as they can pretty much cover the same territory and give the same information on connected articles. Many articles, IMO, have for the last few years been getting clogged with major info-boxes, minor-info-boxes, templates, portals, categories, long lists of "See Also's"; external links, and more. Anybody who has edited here for a while knows this to be true. Call me an exclusionist, but sometimes enough is just enough. GenQuest"Talk to Me"06:12, 10 January 2014 (UTC)
Oppose These generic portals are a waste of time and add no value to the article. All these tags are found on the talkpage, and I see no value in an article having a link to a "film portal" or a "1980s portal". Spam under a different form. LugnutsDick Laurent is dead08:41, 10 January 2014 (UTC)
Oppose, as per all the very good reasons above. It's also overkill and stretching the point of the portal too far. I'll also add that this seems to be forum shopping by WhisperToMe. After receiving no consensus for the inclusion on the article talk page, or at the film project, or even at my talk page, he's decided to keep beating the issue to death. We're getting further into WP:IDHT-ish territory now. - SchroCat (talk) 10:11, 10 January 2014 (UTC)
Oppose The portal is not "topic relevant". WhisperToMe seems to want to treat portals like categories but I disagree with this approach since categories do this job just fine. Yes, Gone with the Wind is a great American film but the article itself is not actually on the subject of American film. I believe portals should follow the principle of all internal wikilinks in that they should inform the reader on the subject of the article. For example, it would be ok to include something like the Star Trek portal on the Star Trek articles because other Star Trek content informs the subject matter of the article. In the case of Gone with the Wind I don't see how other articles about the American film industry would be particularly relevant to a reader; other Gone with the Wind articles would be relevant and we do have {{Gone with the Wind}} for that purpose. I accept that portals have their place but they should be used judiciously. Linking to other material on Wikipedia should be focused and relevant, since over-facing a reader with too many links can be counter-productive in assisting them in finding the information they want. Betty Logan (talk) 12:54, 10 January 2014 (UTC)
Guys, it would be really nice if especially those of you who are "uninvolved" would please post your views at the RFC that Betty suggested above. Please remember that the question at the RFC is about a specific portal being placed on a specific article, not about whether portals in general are spammy or a waste of time.
And if you've been arguing with WTM about this for days or weeks now, would you please not post for a while, or if you really can't wait, could you post your views in the nicest, least confrontational manner possible you can manage? RFCs are usually open for about a month. It'd be nice if we could get views of completely uninvolved people, and we've proven many times here at the English Wikipedia that they won't respond if they think that people will yell at them. I've hatted the argument between two editors about whether some other film is truly "American", so I think the RFC has a chance, but you can really help by making a friendly space for outside editors to comment. WhatamIdoing (talk) 22:57, 10 January 2014 (UTC)
--Pratyya (Hello!) 16:06, 5 December 2013 (UTC)
.png)
/Archive_108#c-Aleksa_Lukic-2013-12-26T08:57:00.000Z-Wiki.png){kind=link}
