Jump to content

Wikipedia:Village pump (proposals)/Archive 128

Add links
From Wikipedia, the free encyclopedia
Village pump (proposals) archive  

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.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215

Cat-a-lot

I have seen many articles categorised in a category and also the immediate parent of that category. This could be due to classification into a subcategory by the editor but non-removal of parent category. Should the immediate parent of a category not be removed from the articles containing the subcategory as well? Is there any mechanism by which we can determine quantum of such articles? -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 14:08, 7 October 2015 (UTC)

Note: In the case of articles with eponymous categories this categorization may be deliberate and should not be changed without consensus. Tobias Bergemann (talk) 15:24, 7 October 2015 (UTC)
Some categories are non-diffusing, let's not repeat the "women authors" disaster. Roger (Dodger67) (talk) 05:46, 12 October 2015 (UTC)
Agreed, so the short answer is "no". A lot of time is wasted correcting edits by those drive-by editors who don't fully understand the (admittedly complicated) policies on this. Johnbod (talk) 12:46, 12 October 2015 (UTC)
An other class of such cases where the parent needs to stay would be stub categories. עוד מישהו Od Mishehu 11:49, 13 October 2015 (UTC)

Put a persistent link at the top right of each page linking to "Pending changes reviews"

As a Pending Changes Reviewer it would be helpful to have a persistent link at the top right corner of each Wikipedia page, next to the the

User | Notification badges | Talk | Preferences | Beta | Watchlist | Contributions | Log out

links area so it would look more like this:

User | Notification badges | Talk | Preferences | Beta | Watchlist | Pending changes | Contributions | Log out

The new link would link to here: Special:PendingChanges

Easy peezey. Thank you. Cheers! ...Checkingfax ( Talk ) 02:56, 16 October 2015 (UTC)

At most, I'd suggest an optional gadget; there's a lot of stuff up there already. I also imagine that different kinds of patrollers (new page, AfC, various backlogs, etc.) might want something similar and they can't all be up there. Regards, Orange Suede Sofa (talk) 04:17, 16 October 2015 (UTC)
Here's a simple script to copy to your common or vector.js:
var head = document.getElementById('mw-head').getElementsByTagName('ul')[0];
var li = document.createElement("li");
var a = document.createElement("a");

a.appendChild(document.createTextNode("Pending changes"));
a.href = "https://wiki.riteme.site/wiki/Special:PendingChanges";

li.appendChild(a);
head.insertBefore(li, head.childNodes[9]);

- Esquivalience t 02:56, 17 October 2015 (UTC)

Thank you you so much for the effort, Esquivalience. I put the code above in to my common.js, saved it, and purged my browser cache. Not seeing the new link. Closed the browser and reopened it. Still not seeing it. What next? Cheers! ...Checkingfax ( Talk ) 03:49, 17 October 2015 (UTC)
ahau 2001:268:C2C1:21B0:7CDC:5127:2623:9CD6 (talk) 09:00, 25 November 2022 (UTC)
Esquivalience, face palm. I inserted a rem line in to your sweet code and it broke my whole common.js page. My bad. How do you insert comments in to a .js page? It's working great now. Cheers! ...Checkingfax ( Talk ) 04:25, 17 October 2015 (UTC)
JavaScript has two forms of comments: // comment (inline) and /* comment */ (block). Inline comments run to the end of the line, while block comments may span several lines. SiBr4 (talk) 10:24, 17 October 2015 (UTC)
The above code works but we already have a function addPortletLink to add interface links. It can be adapted for other purposes without actually knowing JavaScript:
mw.util.addPortletLink(
  'p-personal',
  mw.util.wikiGetlink( 'Special:PendingChanges' ),
  'Pending changes',
  'pt-PC',
  'Go to Pending changes',
  null,
  '#pt-preferences'
);
'p-personal' adds it at the top, '#pt-preferences' places it before Preferences. The top is usually used for links associated with the user account. Here is another version:
mw.util.addPortletLink(
  'p-interaction',
  mw.util.wikiGetlink( 'Special:PendingChanges' ),
  'Pending changes',
  'pt-PC',
  'Go to Pending changes',
  null,
  '#n-recentchanges'
);
'p-interaction' adds it to the Interaction menu in the sidebar, '#n-recentchanges' places it before Recent changes. These names can be found in the html source of pages. PrimeHunter (talk) 10:54, 17 October 2015 (UTC)

Viewing the "Pages transcluded onto the current version of this page"

If template X is used in template Y and only template X is used in a namespace:

then—upon editing—this:

Pages transcluded onto the current version of this page:

  • Template:X
  • Template:Y

should display as this:

Pages transcluded onto the current version of this page:

  • Template:X
    • Template:Y

 —User 000 name 04:54, 18 October 2015 (UTC)

secret ballot for arbitration commite election

this to prevent partiality — Preceding unsigned comment added by Albert einstein 1110 (talk • contribs) 16:34, 19 October 2015 (UTC)

Hi Albert einstein 1110. For the past few years, Arbitration Committee elections have used the SecurePoll extension, which allows for anonymized voting. This year's election won't be different in that regard. See Wikipedia:Arbitration Committee Elections December 2015 for more information. Best, Mz7 (talk) 21:11, 19 October 2015 (UTC)

Do we have a research template?

Do we have a template like Bulbapedia's MoveResearch? (For articles in general that need research). It would be great if we had one. If we already have something that serves this purpose, tell me here. Hop on Bananas (talk) 15:04, 3 October 2015 (UTC)

What do you mean by "research"? Original research is not allowed on Wikipedia. For templates that indicate that more or better sources are needed or the article needs to be expanded or improved see: Wikipedia:Template messages/Cleanup. Finnusertop (talk | guestbook | contribs) 19:49, 3 October 2015 (UTC)

"Original research is not allowed on Wikipedia". Duh, I knew that. I was looking for a template for articles with missing information (which might as well have reliable sources). Hop on Bananas (talk) 17:59, 12 October 2015 (UTC)

"need research" is very vague. See Wikipedia:Template messages/Cleanup#Expand and add and note Template:Expand. PrimeHunter (talk) 22:58, 12 October 2015 (UTC)

Okay, that seems close enough. For the record, I was looking for: 

This page is in need of research. Reason: (insert reason here) You can discuss this on the talk page.

I guess {{Missing information}} is good enough.

 – Hop on Bananas (talk) 12:54, 18 October 2015 (UTC)

Worth looking at the discussion in which the {{Expand}} template was depreciated: Wikipedia:Templates_for_discussion/Log/2010_December_16#Template:Expand. There is an understanding that ALL articles on Wikipedia need improving, and that simply tagging an article as such is not that helpful. And to get a fuller appreciation of why tagging an article as needing general improvement is not helpful, spend some time working through Wikipedia:Backlog. Pick a section, say Category:BLP articles lacking sources from October 2006, and look at the first article in that category: Tracey Cox. What has happened since it was tagged in Oct 2006? It has been tagged twice more, in 2008 and 2010, as needing improvement. There is a school of thought that rather than more tagging, what is needed is more actual work done on articles. Tagging is usually asking someone else to do it. As we see from the backlog, there is no-one else spare to do the work. If you spot that work needs doing, then it would be more beneficial to do the work yourself. SilkTork ✔Tea time 22:42, 20 October 2015 (UTC)

Deletion to Quality Award

I've created the WP:Deletion to Quality Award.

This recognizes editors who've taken a page previously considered for deletion — to Featured Article or Good Article quality.

The award is inspired by the Wikipedia:Million Award, the Wikipedia:Article Rescue Squadron, and the Wikipedia:WikiProject Quality Article Improvement.

Please see Wikipedia:Deletion to Quality Award.

Thank you,

— Cirt (talk) 00:35, 21 October 2015 (UTC)

RfC

A RfC has commenced on whether a limited unbundling of blocking for counter-vandalism should be tried for eight weeks, see Wikipedia:Vandalism/RfC for a trial unbundling of blocking. Esquivalience t 02:40, 21 October 2015 (UTC)

Trans-Pacific Partnership protest

Wikisource has original text related to this article:

Is Wikipedia going to do that semi-blackout thing for the Trans-Pacific Partnership like it did for SOPA?--67.182.233.46 (talk) 08:39, 19 October 2015 (UTC)

Not having been involved in SOPA, I don't know what "that semi-blackout thing" means, but if it means preventing or deterring edits that are contrary to WP:NPOV, or vandalism, then I guess it might be necessary. Ditto for TTIP perhaps. Stanning (talk) 09:51, 19 October 2015 (UTC)
See Wikipedia:SOPA initiative. Basically Wikipedia was shut down for a day to protest SOPA and 67.182.233.46 is asking if we are going to do the same thing for the TPP. I think there has been some discussion about it at User talk:Jimbo Wales, might be worth checking the recent archives there. Jenks24 (talk) 09:54, 19 October 2015 (UTC)
Aha, thanks. TPP is mentioned in User talk:Jimbo Wales/Archive 196, with pointer to information on Wikisource. I don't see anything about TTIP, which is getting a lot of protest over in Europe, but maybe that doesn't have the same concerns or isn't getting the same attention. Stanning (talk) 13:30, 19 October 2015 (UTC)
Added helpful information from Electronic Frontier Foundation, linked above. — Cirt (talk) 11:53, 21 October 2015 (UTC)

Well, the extension to copyright terms would drastically affect public domain works at Wikimedia Commons and Wikisource. It's a very strong reason to protest. --NaBUru38 (talk) 21:29, 24 October 2015 (UTC)

TAFI & main page discussion

Please head over to this discussion and place your views. :D--Coin945 (talk) 10:05, 25 October 2015 (UTC)


Indefinite Create Protection

Salted pages should not be case sensitive, as it allows the user to recreate the page by simply turning a letter from small to big or big to small. If an administrator indefinitely create protects Tunga Warrior, then Tunga warrior, Tunga warrioR and TungA warrior should automatically become create protected.--1.39.37.62 (talk) 13:39, 22 October 2015 (UTC)

I'm not sure it's necessary. Where we see odd capitalization, I presume an admin reviewing the CSD nom will also look around to identify that it's a deliberate misspelling trying to do the runaround on the page (if the NPP doesn't get to that review themselves). Recreated page at that point can still go through the salting nomination if it's a repeated action, IMO. --Izno (talk) 13:51, 22 October 2015 (UTC)
Any experienced admin has certainly seen this, we just delete and salt the recreations, and probably block the user responsible. I don't think it's that big of a deal and I'm not at all sure what is proposed here is technically feasible at this time. Beeblebrox (talk) 19:03, 22 October 2015 (UTC)
If it becomes a serious problem with a specific title, we can always use MediaWiki:Titleblacklist - simply add a line to disallow "Tunga Warrior", and it can't be created with any capitalization. עוד מישהו Od Mishehu 20:52, 25 October 2015 (UTC)

WikiHistory Project

we at Sindhi Language Authority developed a Project named www.encyclopediasindhiana.org, in it their is a feature of time line (dates entered in encyclopedia's articles and their description) with hyper link to such title of entered date. http://encyclopediasindhiana.org/timeline.php

Wikipedia can also build a project name like wikihistory or it can add feature to wikipedia called dates entered in this article, it would be very usefull for historians, students and comman user to search history of for example 2015 year. or history of Internet from 2000 to 2015, The history can be search able date-month wise, date-month-year wise, month-year wise and year wise, subject wise, location/country wise, for example history of Pakistan events or keywords used in description of such history timline.

Wikipedia can apply this idea also,,,, create crawler which find date formatted strings inside article data, store it in data base, as description it can crawl and include some sentences of crawled date both sides. for example the Pakistan get independent in 14th august 1947 from Brtain., crawler include words on both sides of date. then user can be asked to proof such entry of date line in such article, proper formate it as standerd date is formated, assign it a Defined description as in article. and update it to database.

or User can insert history from any part of world.

or wikipedia also can add one more feature to existing wikipeida articles, so that when a user enter an article so it can highlight date formated strings which will be shown in side bar of article and whould be added into database of wikihistory, or search able history of wikipedia dates entered in articles.

or this is also an example www.historymole.com — Preceding unsigned comment added by 182.182.116.243 (talk) 11:39, 26 October 2015 (UTC)

Internal Hyperlinking of Wikipedia article

1. Wikipedia can /should interlink all its data so that it will be very much better for user to reach indepth knowledge of any topic/article

their are three ways i think

  1. 1. Assign all article titles to an array, replace each array element into hyper link, for example title is Sindh, replace it into hyper link like <a href=www.wikipedia.org?title=sindh>Sindh</a>, now find sindh array element into articles body where it is just word with spaces around both sides. replaec ith with Hyperlink. this will be performed when article is loaded. like we have done at انسائيڪلوپيڊِا سنڌيانا Encyclopedia Sindhiana
  1. 2. Apply list of Title to an array and find replace it into store database at once, then on new submission of article the title automatically be hyperlinked into all articles in database.
  1. 3. the third way is little easy and bandwidth friendly also time friendly, i think, then above both ways, which is on load of any article assign all words of article to an array, and find each array element/word into list of titles. in find true replace array element/word into hyperlink of finded title. this will loop all words of article with title and hyper link on success find. then echo hyperlinked array element as article body.

(if some data should not be hyperlinked then assign linkable data to a veriable, like find until footnote word or until refrences word, i mean a= a varible of article data from title to footnote or reference. — Preceding unsigned comment added by 182.182.116.243 (talk) 10:50, 26 October 2015 (UTC)

If I can make any sense of this at all, it sounds like you're proposing to do exactly what WP:OVERLINKING says not to do. Or alternatively, to make Wikipedia look like the sort of articles you see elsewhere on the Internet where some ad script links random generic words to advertisements. No thanks. Anomie⚔ 12:00, 26 October 2015 (UTC)

Global Encyclopedias Network

i Think there is more then requirement Data available on net, but their is still thirist of even basic knowledge to some humans, the reason is simple we dont let comunicate information with each other, it can be a global network of information, fast, easy to access, and highly as per requirement of user. reach able to depth of requirment.

we can hyperlink all internet encyclopedias artilce's titles, at least we at www.encyclopediasindhiana.org want to let user be in network of encyclopedias.

the formula is simple call and apply any/each encyclopedia's article titles, convert them into hyperlinks in article body. (first stage), second stage is generate auto hyperlink on new submission of any article , auto click it programetically: for example in our case we can send or wikipedia can send us new submission of article, its title, it could be generating auto hyperlink of any new article submition, for example if at wikipedia side a new article is submitted, it can generate link like www.encyclopediasindhiana.org/articles.php?new_wiki_title=Sindh when such link be clicked/checked like google crawler check or broken links detecter check link and it will be ranked one time. so the autometically our page will be opened, on such evend we will add new_wiki_title=Sindh into database table of external links, find sindh word in our data replace it with wikipedia hyper link like www.wikipedia.org/Sindh. i think this would make us very informative and keep in touch with Latest Information. this would be the dream of story writer of time travel movie scene an global encyclopedia. one word can have more then hyper links of diffrent encyclopedias like sindh 1-2-3 (sindh one defind in encyclopediasindhiana.org, sindh two in wikipedia.org, sindh 3 define in encarta.com. — Preceding unsigned comment added by 182.182.116.243 (talk) 11:10, 26 October 2015 (UTC)

No, let's not spam links to every random encyclopedia (by whatever definition separates "encyclopedia" from other things pretending to be encyclopedias) onto all articles, particularly not in some SEO scheme. Anomie⚔ 12:04, 26 October 2015 (UTC)

Time to shut down WP:NFCR by merging it into WP:FFD?

Consensus is to merge NFCR and FFD into one process, called "Files for Discussion". No real discussion into merging WP:PUF into this now, but that can come later. Mdann52 (talk) 08:40, 27 October 2015 (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 propose that Wikipedia:Non-free content review be shut down as historical while referring editors to use Wikipedia:Files for deletion as an alternative. At the present time, there are 163 open discussions on WP:NFCR with the oldest discussion opened on 10 June 2015 (over three months ago.) The fact of the matter is that WP:FFD can and should be utilized in place of WP:NFCR for multiple reasons:

  1. On WP:NFCR, if a file is deemed to be used that is inappropriate, the file should be deleted (an outcome at WP:FFD). Files on WP:NFCR will be kept for the opposite reasons (also an outcome at WP:FFD.)
  2. Discussions at WP:FFD can question a file's non-free status, and if it is improperly used, it should be deleted.
  3. WP:NFCR does not have daily subpages (and seemingly never has), which causes inability to visualize and work on backlogs. On the other hand, WP:FFD has daily subpages and a backlog notification that accurately appears if there are entries existing more than 7 days old; in addition, the bit management and organization of WP:FFD is a lot more advanced in making it clearer what needs to be closed when.
  4. For someone questioning if a non-free file should remain in Wikipedia (aka, should it be deleted), it is honestly very unclear whether the discussion should go to WP:FFD or WP:NFCR.
  5. The concern regarding if WP:NFCR should still be functional has been discussed previously: see Wikipedia:Miscellany for deletion/Wikipedia:Non-free content review. The discussion happened back in 2012, and the discussion was closed with the suggestion to go to other pages to develop a consensus on what to do with WP:NFCR. Since that date, there has seemingly not been very minor, if any, updates to WP:NFCR that better distinguishes it from WP:FFD. (Thus, this is why this discussion is happening here.)
Very simply put, if a non-free file is not used per WP:NFCC, the file should be deleted immediately. The purpose of WP:FFD is to determine if a file needs to be deleted. However, there is another point from the the MFD discussion above that needs to be considered during this discussion:

What if the non-free file is used in multiple articles, and the question is if it should be removed from one article and not the other?

For this question, I recommend that WP:FFD be updated to allow an outcome that specifically states that the image "should be kept, but removed from this article". This will benefit closes if these discussions happen on WP:FFD since it could be possible that during the course of the discussion, a non-free file that is on multiple articles but is nominated to be removed from only one article could very well be determined needed to be removed from Wikipedia altogether (which results in the file being deleted.) On a minor distracting note, if this change were to be made to the possible WP:FFD close results, the page may need to be renamed from Wikipedia:Files for deletion to Wikipedia:Files for discussion since the nomination purpose and outcome could then be something other than deletion. (This idea is similar to the fact that WP:RFD is named "Wikipedia:Redirects for discussion" instead of "Wikipedia:Redirects for deletion" since pages are nominated there for reasons other than deletion.) Steel1943 (talk) 21:57, 2 October 2015 (UTC)
NFCR is not to be used for case #1: if the only use of a file is up for discussion, that should be at FFD. All other situations are cases of multiple files and/or multiple uses of a file, which may or may not result in deletion. This means that discussions can be closed without administrator intervention (as is require for FFD and AFD). So no, this is not a good proposal, because NFCR handles far too much more than FFD can accommodate. --MASEM (t) 22:00, 2 October 2015 (UTC)
Or to put it more directly, the distinction between FFD and NFCR is very clear: if you honest believe a specific image should be deleted from WP and just need community consensus for that, FFD is where you go. If you are not sure, or that one is talking about a certain use of an image, then we have the discussion at NFCR. It is the same distinction between AFD (where "D" is specifically for "deletion") and the various "for discussion" boards for other non-deletion options like merges. --MASEM (t) 22:03, 2 October 2015 (UTC)
Or, with my proposal, non-free discussions can happen at WP:FFD. I understand that you are trying to clarify the distinction between the two, but it should not have to be explained in this much detail, nor should an inexperienced editor still be confused after reading the distinction. (Which, I still am, by the way; what is the point of having a possible deletion concern started at one forum, then be forced to move it to another?) Steel1943 (talk) 22:13, 2 October 2015 (UTC)
If someone does open a NFCR case that should really be at FFD, we do close those and point to FFD. There's a certain rigor and process that the FFC/NFCR dicotamy has come out of based on the same AFD/(general article discussion) issues. It's tied to the perennial proposal of why we don't remain AFD as "Articles for Discussion" - deletion of content is meant as an absolute step, and so AFD avoids having cases where the proposal is not to delete content and encourages that to take place elsewhere. Similar case at FFD compared to NFCR. --MASEM (t) 22:22, 2 October 2015 (UTC)
  • (edit conflict) I have to disagree with this statement in full. For one, I proposed the exact concern stated here be resolved by amending WP:FFD to allow a "keep, but remove from this article" close. Also, I fail to see how this is any different than a non-admin closing a discussion to "keep" at WP:FFD (or any other WP:XFD forum, for that matter) due to a clear consensus that doesn't require a deletion. If a file needs to be removed from one page but not altogether, a non-admin can do that. Steel1943 (talk) 22:10, 2 October 2015 (UTC)
An admin action is the actual act of deletion. With images, NFCR is not about deleting images, just their uses (with rare cases of immediate CSD-type invalid images). Images may be removed from articles, then, leaving them as orphans which are then tagged with CSD by automated tools and later deleted (if the CSD tag is not removed) by admins later. So a non-admin can safely close a NFCR and take the required action that was developed without having admin tools. There's also much more than just considering keeping an image on a page - a good chunk is evaluating if a non-free could be tagged otherwise, if a non-free needs improved rational, etc. We used to have a noticeboard for the broader issues but that was shut down in favor of NFCR. So it is necessary for the less rigorous discussions that FFD is otherwise not set up for. --MASEM (t) 22:16, 2 October 2015 (UTC)
Let's take the following scenario: User:A finds an image, used in multiple articles, (s)he thinks should be deleted as unfree, and lists it at FFD. A clear (SNOW-level) consensus says that the image belongs in one of the articles. Would that be any different than an NFCR case? עוד מישהו Od Mishehu 16:13, 6 October 2015 (UTC)
If the user nominating honestly believes that the image should be deleted from all uses, the right place is FFD because they are seeking admin action. Just like AFD, an FFD can be closed without necessarily requiring an admin action as the example you give. But it's what the initial intent is - if pulling the trigger for deletion is the desired result, an XFD should be used, otherwise other means that do not demand admin attention should be engaged first. --MASEM (t) 16:48, 6 October 2015 (UTC)
  • Fully support this proposal. The distinction between the two fora is an artificial construct of bureaucracy, confuses potential nominators, reduces attention for both forums by dividing admin and voter attentions up between them, and serves no purpose that I can see. While we're at it, merge the utterly obsolete WP:PUF into it too. Fut.Perf. ☼ 18:12, 6 October 2015 (UTC)
    • Do you mean to say PUF is redundant? At first glance I agree with the rest of what you say. BethNaught (talk) 18:18, 6 October 2015 (UTC)
    • By that logic, then we should rename AFD from "deletion" to "discussion" and allow merges and the like to be offered there. The same reason that this idea remains a WP:PEREN applies to FFD/NFCR, as the FFD mechanism is simply not set up to handle the types of discussion NFCR handles. I can agree that PUF might be better at NFCR as NFCR handles the inverse case (possibly free files currently tagged as non-free). And really, the amount of mis-filings at NFCR (eg where the user is seeking deletion outright) is trivial and easily handled. --MASEM (t) 18:42, 6 October 2015 (UTC)
  • A question of mine: How does this proposal deal with the occasional topic asking about whether a non-free image really is non-free? There are plenty of queries in NFCR about whether such-and-such logo is original enough to be copyrightable. Lumping these into a deletion discussion is sort of odd.Jo-Jo Eumerus (talk, contributions) 18:48, 6 October 2015 (UTC)
    • Well, that's just the point: the types of questions asked at the three fora overlap to a very large degree. All of NFCR, FFD and PUF can deal with questions of whether something is copyrightable or below the threshold of originality (no matter whether it's originally mis-tagged the one way or the other). Both FFD and PUF frequently deal with questions of whether something is PD-old or not. Both FFD and NFCR routinely deal with whether NFCC#8 claims are plausible, the only difference being that NFCR typically does this across several articles. On PUF you often have the situation that you first have to determine that something was mistagged as free, but then the question arises whether you could alternatively keep it under NFC. Conversely, on FFD you often get things nominated as misapplied NFC but then end up discussing whether you could actually keep it as PD. And so on. It's really the same set of questions everywhere. – As for the cases where things get taken to NFCR for the purely formal question whether a non-free tagging should be replaced by PD-textlogo, the answer is simple: those cases shouldn't be nominated anywhere at all. If somebody thinks such items are mistagged, they should simply change the tags; if they are not sure and need to ask, they shoul damn well leave the file alone. The busibodies who keep nominating these should simply stop doing it. Fut.Perf. ☼ 18:56, 6 October 2015 (UTC)
      • But these are similar issues at AFD too. Dealing with mass noms, dealing with results that are not deletions, etc, and the logic to keep things separate is one of those points in the PEREN "Articles for discussion" ideas. As for those that ask questions if a non-free can be tagged with a PD label, while I do wish some were less wary, there are still a good number of edge cases or logos of unclear origins that should be discussed before retagging, and thus fair questions to ask, just as checking on free images that should be tagged non-free otherwise. I'm totally for cutting 3 boards down to 2 (perhaps even 4 to 2 taking WP:MCQ as well), but I fear trying to group all these to one, particularly in the current FFD approach (where we have by date but not separate nomination subpages) is a recipe for disaster. --MASEM (t) 19:08, 6 October 2015 (UTC)
        • I am not convinced that the "is this image really copyrightable" questions should be thrown to the wayside like this. One consideration for me is whether FFD should stay "Files for Deletion" if folks want to merge PUF or NFCR into it; renaming it to "Files for Discussion" would be a solution to the "odd" issue I have.Jo-Jo Eumerus (talk, contributions) 19:14, 6 October 2015 (UTC)
I would support renaming "Files for Deletion" as "Files for Discussion", as a number of FFD referals I made ended up with new information coming to light which meant files could be moved to Commons. A rename would also allow for PUF and NFCR to be merged into there being a single process for querying image status or information.

Perhaps the existing ffd/puf template code could be factored into feeding a new template which creates a "File for disscussion" entry with a reason code.

Some example reason codes in addition to the fact that the file is merely unfree/unused might be:

  • Dead source
  • "Practical" Duplicate - ie (not an F1/F8) but is in effect a near identical match to another image even if the hash means they aren't pixel for pixel
  • WP:FOP concern
  • WP:TOO concern
  • Derivative work concern
  • Work raises ethics concern ( e.g An image which shows an embarrassing medical condition, and the subject is identified.)
  • "Attack" image
  • Contested Speedy Deletion.

(Of course obvious cases for some of these would still be under CSD)

In addition to having referral/reason codes, there could be outcome codes along the lines of..

  • Deleted - and should not be restored.
  • Deleted - but can be restored.
  • Deleted - for technical reasons (can be restored)
  • Deleted - at Wikimedia Commons. (can be restored)
  • Retained - Non-free content
  • Retained - With status change/update
  • Retained - under new name(s)
  • Retained - Commons

Having more discrete referral and outcome codes would also potentially allow users like me that do a lot of file work to find similar previous decisions more easily. I am however wary about fosillising policy decisions "made from the bench" so to speak, given that contributors need some flexibility. Sfan00 IMG (talk) 12:51, 7 October 2015 (UTC)

  • Merge to Files for Discussion Articles is the only deletion venue that is explicitly deletion only, and for good reason, that there are a lot and it often takes significant effort to comment intelligently, so we need to keep the load a small as we can. It has nothing to do with whether administrators are required. In this case, like the Redirects, Categories and Miscellany venues, the real purpose is to centralize discussion of pages that may require deletion. Since FFD is not overloaded like AFD, it should be just fine to add non-free content reviews to it. Looking at the page now, there are nominations from four months ago, which is a big problem. (Also, it's difficult to explain the distinction, and I think Twinkle has it wrong) Oiyarbepsy (talk) 03:13, 8 October 2015 (UTC)
  • If a file appears on two or more pages and should be removed from some but not all of the pages, then the request should go to NFCR. On the other hand, if it should be removed from all of them, it should go to FFD. This looks like an artificial difference, and users who are unaware of the distinction sometimes send files to the wrong place so that discussions have to be closed as "wrong venue" and forwarded to the other venue. Also, it is not always clear from how many pages the file should be removed at nomination time, so nominations could accidentally go to the wrong place even if the nominator knows about the difference between the venues. I suggest that we merge these two situations by having both at the same discussion board instead of splitting them up. FFD could handle all of these situations.
If an article contains too many non-free files, then some of them need to be deleted from the article per WP:NFCC#3a, but there might not be any preference on which ones we should keep. If the files aren't used in other articles, then I create a section at FFD where I list all of the files, stating that we should keep some and delete some. On the other hand, if the files are used in other articles, then I create the section at NFCR instead. If some of the files appear in other articles whereas other files do not, then the page tends to be listed at NFCR, although the rules maybe technically say that the discussion should be split by listing some files at NFCR and some at FFD. This looks like an artificial difference, and it would be less confusing to list all of these pages at the same place, for example at FFD.
If a file is listed as free but someone suggests that it may be non-free, then the file is listed at PUF. If a file is listed as unfree but someone suggests that it may be free, then the file is listed at NFCR. Both situations (change free → non-free and change non-free → free) require the same knowledge and should attract the same users, so it seems more natural to list all of these at the same place. Adjusting PUF to take all of these files sounds like a good idea.
There was also a proposal to merge FFD with PUF. The difference between FFD and PUF is more well-defined and there is less overlap, so I think that it would be better to keep them separated from each other. --Stefan2 (talk) 16:54, 11 October 2015 (UTC)
  • Merge into a single process, unless there is some noticeable difference between the potential outcomes of the 2 processes, or some clearly objective difference between pages you should nominate for each (i.e not just the nominator's opinion about the ideal outcome). Consider calling this process "Files for Discussion" (just like we do for categories). עוד מישהו Od Mishehu 05:42, 12 October 2015 (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.

Removing Persondata

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
There is consensus to have a bot remove all the persondata from all the articles. The majority argument is that the sooner this is done, it will stop additional wasted effort of those adding persondata. As a side note there is common sense coming from the minority and even some supports. That the removal be done in steps and that moving what has not been moved to wikidata to some other place so that it can be done at a later date is a good plan that may save time of less informed editors. But there can not be said to be consensus for this, though I see no opposes. AlbinoFerret 16:10, 27 October 2015 (UTC)

Persondata was been deprecated by an RfC held here, which closed with "Consensus is to deprecate and remove". A bot is needed, to remove it from all articles. However, my request for a bot to do so was closed with the claim "a discussion about a bot operation of this magnitude needs to be held in a broader forum, with more participants and a more focused discussion". I therefore seek agreement here, to have a bot carry out this task. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:12, 8 September 2015 (UTC)

Wikipedia:Bot requests/Archive 64#Remove persondata is the request for a bot that Andy mentions. --Izno (talk) 15:59, 9 September 2015 (UTC)
  • Conditinal support. As the template has been marked as being deprecated for three months, it makes sense to begin removing it from articles in a methodical fashion. A bot is the most logical means to perform this task. My concern is that some portion of the Wikipedia community is unaware that {{Persondata}} has been deprecated and as a result is still adding useful information in calls to the template. To deal with this concern, when a bot is in the process of removing the template from an article it should check Wikidata to see if the data items defined in the template have been migrated to Wikidata. If a data item is missing from Wikidata, then the bot should copy the information there before completing the removal. I am agnostic on how the bot should behave when a conflict between Persondata and Wikidata is detected and will defer to the bot's designer on how to best proceed in such cases. --Allen3 talk 11:10, 8 September 2015 (UTC)
    • @Allen3: Please note the discussion of this point in the RfC. All the data that can be reliably ported to Wikidata automatically has been ported. Wikidata does not want further automated import of Persondata. I share your concerns that some editors are still expending time and energy updating this template - that's why we need to remove it from pages, ASAP. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:33, 8 September 2015 (UTC)
  • Question - Has all of the Persondata been migrated to Wikidata? That would seem to be a prerequisite. - MrX 13:33, 8 September 2015 (UTC)
    • Please note the discussion of this point in the RfC. All the data that can be reliably ported to Wikidata automatically has been ported. Anyone wishing to port any remaining data manually may work from articles as they were at the time of Persondata's deprecation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:29, 8 September 2015 (UTC)
  • Support. While I respect and endorse the BOTREQ groups desire for caution, that discussion already happened. Resolute 13:38, 8 September 2015 (UTC)
  • Support - I and a few other editors have been manually removing them ourselves but it would honestly be a lot easier if a bot could do it for us considering there's over 4 million articles on here, I understand the need for caution but IMHO something needs to be done as it'll take forever to remove them all manually here. –Davey2010Talk 17:00, 8 September 2015 (UTC)
  • Oppose using a bot or any automation to remove any persondata until such time that it can be demonstrated that it has been fully migrated to Wikidata, or that it persists in some other machine readable field in each article, for example in infoboxes. Dirtlawyer1 raises some very valid concerns and Andy Mabbett's responses don't exactly fill me with confidence that a bot will handle this properly. Removing persondata is not an emergency, and more harm could come from rushing this through with automation.that has not been migrated to Wikidata. Support removing persondata that has been migrated to Wikidata. - MrX 18:46, 8 September 2015 (UTC), 23:49, 9 September 2015 (UTC)
  • Support – it's definitely time to do this now. --IJBall (contribs • talk) 20:28, 8 September 2015 (UTC)
  • Support - given that the purpose of Persondata was for automated cataloguing, and an automated tool has already pulled any information useful for that purpose (the rest is unreliable, and Wikidata doesn't want it) then the time is right to programmatically remove all instances of the template. As Andy said, users wishing to port additional information can work from the page history. Ivanvector 🍁 (talk) 21:38, 8 September 2015 (UTC)
  • Comment - As a Wikidata editor, on the random of BLPs (and some dead people) on my watchlist that I've edited and noticed the persondata, I've found that not always is the data on Wikidata. This usually pertains to the alternate names, for which Wikidata has not pulled in as either aliases or as statements. A handful of times it has been differing birthdates. To suggest that everything has been moved over when not even aliases have captured the notion of alternative names is odd. --Izno (talk) 21:55, 8 September 2015 (UTC)
    • Once again: Please note the discussion of this point in the RfC. All the data that can be reliably ported to Wikidata automatically has been ported. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:20, 9 September 2015 (UTC)
      • Your snark ("once again") is unnecessary and unappreciated. The point I am making is that there are data which have not been provided to Wikidata; that such data cannot be automatically provided to Wikidata reliably (we agree!); and that mass-removal by bot is thus inappropriate. Except I nowhere opposed or supported. Would you like me to do so now on ad hominem grounds or the actual logical ones of my comment?

        A more sensible approach as provided at WP:Bot requests is to remove the ones by bot which can trivially be shown to have had all their information migrated. In fact, none of the very reasonable suggestions for a bot were presented in this RFC, which I find somewhat specious, since that discussion has gone unlinked in the opening statement of the RFC. Obnoxious. --Izno (talk) 15:49, 9 September 2015 (UTC)

      • Misleading statements alert - Andy, that just ain't so, fella. Please see my extended comments below: virtually no alternate form names have been transferred -- birth names, maiden names, married names, etc. -- and that represents a significant loss of USABLE information. Sorry, but you're wrong. Dirtlawyer1 (talk) 17:27, 9 September 2015 (UTC)
  • Support - having a bot remove deprecated persondata and complete the task. As stated above "Wikidata does not want further automated import of Persondata" so no need to match or compare persondata to wikidata prior to removal. The sooner the removal of persondata, the better - especially since consensus was to remove persondata three months ago. Thank you Andy for following up on this. Gmcbjames (talk) 23:45, 8 September 2015 (UTC)
    • Taking into consideration further discussion, my opinion has not changed. When Persondata is bot removed, information will not be lost - the information is in the article either in the text body or infobox (if used). This information has been visible for anyone to correct misinformation, unlike the invisible and unreliable Persondata. I would suggest editors porting Persondata into Wikidata to carefully double-check the persondata with the article for accuracy. The best solution is to remove Persondata completely at this point of time, as I doubt editors will take the extra time and effort to double-check information prior to porting persondata into Wikidata. As time progresses, the information in Persondata only becomes more stale, so delaying will only compound the problems. Gmcbjames (talk) 05:54, 10 September 2015 (UTC)
  • Support Helder 00:23, 9 September 2015 (UTC)
  • Support – RGloucester — ☎ 01:24, 9 September 2015 (UTC)
  • Support for all the obvious reasons. ~ RobTalk 01:38, 9 September 2015 (UTC) Oppose. It appears some editors do think valuable information remains and are working to manually transfer it. I would likely support more limited attempts to remove those which are not useful (i.e. blank persondata transclusions or those with only name filled in), but if there is actual data remaining, keeping a comment in the text hurts little to nothing. As we verify that everything has transferred, these templates can be gradually removed. ~ RobTalk 21:07, 9 September 2015 (UTC)
  • Support the bot program, and the sooner implemented the better. Four million articles await, and even with the bot it'll take some time to accomplish. Can we publish this deprecation better so editors don't keep wasting time on updating/maintaining these templates? GenQuest "Talk to Me" 04:00, 9 September 2015 (UTC)
    • Neutral Changed per the below information. Was the deprecation RfC regarding Persondata and its resultant "Consensus is to deprecate and remove" widely published? If so, the results (if you can call them that), have been poorly implemented. If not, then it seems that someone, somewhere has jumped the gun and the deprecation decision needs to be reversed and a newer discussion held in the broader community. As to @Dirtlawyer1: stating that people wasting time on updating the existing templates is "a red herring", I can assure you that I, who really, really have limited time these days to edit, have indeed been wasting my time on updating/fixing/editing them.
      This is turning into more bureaucratic horse pucky, and there Ain't nobody got time for that... GenQuest "Talk to Me" 22:05, 9 September 2015 (UTC)
  • Oppose This discussion is missing an important point. How do you get persondata information into wikidata in the future, if this established workflow of persondata at wikipedia is deleted? The situation is: enwiki persondata was imported in the last months to wikidata, ok. Comparing persondata form enwiki to wikidata has shown very similar quality, no surprise. Now tell me: How many new biographic articles were created at enwiki in the last 2 months? (How do you even find them without persondata?) Does wikidata contain the same data as enwiki-persondata about these new articles? How was this data entered into wikidata, by a wikidata-bot using enwiki-persondata? By a wikidata-bot using dbpedia-data that is harvested from enwiki-persondata? By a wikidata-bot harvesting enwiki-person-infoboxes, if and only if they are available? Or has wikidata no data about those new person-articles, because this dataflow to wikidata is now broken, because enwiki deprecates persondata? Show me the data! How is this going to work in the future? Who is supposed to enter new persondata in wikidata, some magic wikidata-workforce that doesn't exist? Magic bots? Show me the workflow! --Atlasowa (talk) 09:48, 9 September 2015 (UTC)
    • There is no workflow necessary. Once persondata is removed from articles, it will be deleted and the template will no longer exist. From there, if editors care to edit such data, they can put it directly into WikiData. In the meantime, all we're doing by waiting is allowing more editors to waste their time adding information that is no longer being used. ~ RobTalk 11:29, 9 September 2015 (UTC)
      • @BU Rob13: That's simply not true, Rob. Many editors, myself included, are manually transferring remaining usable persondata -- including multiple name variants -- to Wikidata. I have not seen more than 2 or 3 instances of editors updating Persondata in the last three months, and I have over 6,000 articles on my various watchlists. No one is wasting significant efforts updating Persondata, and we could significantly improve Wikidata if we had widespread notice and explanation of what usable Persondata remains. Instead, we seem to have a "not invented here" mentality driving the desire for the immediate deletion of Persondata. There is ZERO reason to immediately delete all Persondata, and there is no harm in keeping ti for a while longer. Dirtlawyer1 (talk) 17:22, 9 September 2015 (UTC)
    • You appear to be opposing the deprecation of Persondata. That has already been decided and enacted. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:28, 9 September 2015 (UTC)
  • Strongly Support Given that wikidata has decided to no longer have data pulled over from persondata and therefore any information entered in it from this point on is about as useful as scribbling it on your wall, it should be removed. Jerod Lycett (talk) 11:24, 9 September 2015 (UTC)
  • The Persondata data could be archived on Tools or something. We don't need to keep it lying around in articles; as the bot is removing Persondata, it could be storing it at an off-site location, for interested parties to review at a later time. This would be similar to what's been done with {{Authority control}} (see T.seppelt's Authority control validator). Alakzi (talk) 12:44, 9 September 2015 (UTC)
  • Pinging users of the discussion from the bot requests page (whom have not yet commented somewhere above): @Magioladitis, Gerda Arendt, RexxS, Dirtlawyer1, Hawkeye7, SLBedit, Francis Schonken, and Andy Dingley: @Jared Preston, GoingBatty, Jc3s5h, MSGJ, and C678: (Cyberpower as closing bot op). --Izno (talk) 16:06, 9 September 2015 (UTC)
  • Support, --Gerda Arendt (talk) 16:36, 9 September 2015 (UTC)
  • Support The sooner we get rid of this practically unused misfeature the better. Many of the oppose votes are bringing up the same tired objections that have already been discussed. Jason Quinn (talk) 11:32, 11 September 2015 (UTC)
  • Strongly OPPOSE at this time - A lot of misleading comments have been made regarding the status of the migration of Persondata to Wikidata. I know this first hand because I have manually transferred the Persondata from over 1,000 articles to Wikidata in the last 90 days, and I have had ample opportunity to review a sizable sample of Persondata that I entered into the templates myself. In many instances, the following information has not been transferred:
  • Alternate names - many, if not most alternate names have not been transferred from Personata to Wikidata by bot action; birth names, maiden names, married names, etc., probably represent the largest potential loss of valid, usable information from Persondata; and
  • Brief descriptions - in many instances, the brief descriptions have not been transferred by bot action; and
  • Updated information - as best I can tell, no new or updated descriptions -- or new or updated Persondata information generally -- have been transferred since at least November 2014; this includes new or updated names, descriptions, birth dates, birth places, death dates, death places.
The claim that there is no remaining usable Persondata to be transferred vastly understates the usable information remaining to be transferred. Persondata has been deprecated because a better long-term solution for biographical meta data -- i.e., Wikidata -- has been created. That does not excuse throwing away reliable information from Persondata, information that has not been transferred to Wikidata, without making a better effort to transfer what reliable and usable information remains. That's not undermining Wikidata, that's supporting and improving Wikidata. I am pinging "support" voters above (i.e., @Allen3, MrX, Resolute, IJBall, Gmcbjames, He7d3r, and RGloucester:@Davey2010, BU Rob13, GenQuest, Jerodlycett, and Gerda Arendt:) to reconsider their support for the immediate automate removal of remaining Persondata. Few editors have committed more personal editing time to manually transferring remaining usable Persondata to Wikidata than I have (see [1] for my Wikidata contributions), and few editors have better first-hand knowledge of what remains than I do. Simply deleting all remaining Persondata represents an amazingly foolish waste of past efforts, and the loss of an opportunity to improve Wikidata, educate editors about Wikidata, and recruit more editors to improving Wikidata. What is needed is project-wide notice and explanation to all editors and a concerted, a coordinated effort to transfer what remaining Persondata is usable, and a hard deadline for completion. There is nothing to be gained -- nothing at all -- by the immediate automated deletion of remaining Persondata, and much that may be lost. Dirtlawyer1 (talk) 17:16, 9 September 2015 (UTC)
Have you read my comment above? Would you support with the caveat that a copy of all data is made available elsewhere? Alakzi (talk) 17:26, 9 September 2015 (UTC)
@Alakzi: Yes, I did read your suggestion, A. It's a political solution that, as a practical matter, will simply lead to the removal of existing Persondata with virtually no transfer of remaining usable information. Once the Persondata templates are removed from our articles, it's gone. The solution is notify everyone about the status of Persondata, educate our editors about Wikidata and manual transfer of usable Persondata to Wikidata, create a simple set of instructions, and then set a hard deadline. In the mean time, remaining Persondata does ZERO harm, and immediately removing it by bot action represents the loss of usable information -- alternate name forms, in particular -- in many instances. Dirtlawyer1 (talk) 17:34, 9 September 2015 (UTC)
As far as I understand it, the concern is that, so long as {{Persondata}} remains in widespread use, people will blindly copy it over to new articles, or waste their time updating it, etc. The solution is notify everyone ... Instead, we could notify everyone that the data can now be found over yonder at that "toollab", and that they can transfer it to Wikidata at a leisurely pace, without having to mind any deadlines. Alakzi (talk) 18:01, 9 September 2015 (UTC)
Alakzi, I do new page patrol for articles within my subject areas, and I am seeing virtually no new persondata templates being added to new articles. The concern for lost efforts of editors is a huge red herring; where is the concern for the lost efforts of editors who added valid and usable Persondata that has not been transferred to Wikidata? There is no urgent reason to delete all remaining Persondata, and, and based on my first hand review of a relatively large sample, there is much that will be lost. If we simply transfer Persondata to a holding tank, it's as good as deleted, because once it's out of sight, it's out of mind. We both know this. Dirtlawyer1 (talk) 19:14, 9 September 2015 (UTC)
I'm no expert, being an engineer (and previously a software engineer) but is it really beyond the realms of possibility that a bot can sift through article histories and find the last one with the Persondata template and transfer that good stuff to Wikidata? The Rambling Man (talk) 19:49, 9 September 2015 (UTC)
@The Rambling Man: Andy maintains there is no way to engineer the further automated transfers of usable information from Persondata to Wikidata (please see above). If I understand him correctly, in fact, he maintains there is no usable Persondata left to transfer. I can tell you, based on over 1,000 manual transfers that proposition is incorrect. Dirtlawyer1 (talk) 20:31, 9 September 2015 (UTC)
Of course it's possible to do what I suggested. It's trivial. If WMF want me to help out with that, just send me an email. The Rambling Man (talk) 20:34, 9 September 2015 (UTC)
@The Rambling Man: I have little doubt that depends on the skill of the personnel involved. FYI, if WMF has been involved directly in the previous bot transfers of information from Persondata to Wikidata, it's not been mentioned in the previous discussions. This looks like a volunteer effort, not professionally managed. Dirtlawyer1 (talk) 20:57, 9 September 2015 (UTC)
(edit conflict) @Dirtlawyer1: It was my understanding that all automated transfer of persondata is complete. What do you believe needs a manual transfer, and why couldn't that be handled by an automatic transfer? I'm willing to reconsider if given a good reason to do so. ~ RobTalk 19:52, 9 September 2015 (UTC)
Rob, I see two primary areas of concern: (1) First, most alternate names -- birth names, maiden names, married names, nicknames, etc. -- were never transferred, perhaps because no one wanted to deal with the comma-delimited last-name-first format of the Persondata template. Frankly, from what I've seen, I would not be surprised if no serious automated effort was ever made to transfer alternate names from Persondata to Wikidata. (2) Second, based on my own own observations, I don't think any of the automated bot transfers ever updated any Wikidata fields once they had information present within those fields, and there was no effort made to reconcile conflicting information. Apart from those issues, I have also not observed any attempt to auto-transfer updated Persondata for the past ten months. And then there is the "error factor": dates and places of birth and death which were simply never transferred for some unidentified reason. The automated transfers appear to have been very "down and dirty" -- transfer as much as possible as quickly as possible, and ignore errors, conflicts and omissions. If we care about Wikidata and believe in its importance, we should be systematically reviewing it and comparing to remaining Persondata before it's deleted. In the mean time, it's not harming anything, and we should be encouraging people to review it and start utilizing Wikidata. If we don't, it's a lost opportunity on two levels. Dirtlawyer1 (talk) 20:31, 9 September 2015 (UTC)
You support removing Persondata from any article that has had all appropriate information transferred already, correct? ~ RobTalk 20:33, 9 September 2015 (UTC)
@BU Rob13: In theory, yes, I do, Rob. The question is how is that determined, and who will make that determination? Andy maintains that "all appropriate information" has already been transferred; frankly, that's simply not accurate. I have three months of first-hand experience in manually transferring usable information from Persondata to Wikidata, and I know that proposition is factually incorrect. Furthermore, I seriously question whether further automated transfers of remaining Persondata -- alternate names, in particular -- are technically infeasible. See The Rambling Man's comments above. Dirtlawyer1 (talk) 21:04, 9 September 2015 (UTC)
You're misquoting me. Please desist. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:19, 9 September 2015 (UTC)
No such claim was made. Please stop tilting at windmills. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:15, 9 September 2015 (UTC)
"All the data that can be reliably ported to Wikidata automatically has been ported." Pigsonthewing @16:33, 8 September 2015. You have now been quoted verbatim. And I hotly dispute the accuracy of your quoted statement: apparently no real attempt has ever been made to "port" alternate names. And your quoted statement raises more questions than it answers; it reads like a lawyer's non-answer. Dirtlawyer1 (talk) 21:52, 9 September 2015 (UTC)
Your claim about alternate names is bogus; they were discussed both on Wikidata and in the RfC which found consensus to deprecate and remove persondata. If you dispute the accuracy of my statement, it is open to you to attempt to disprove it, by showing a method, acceptable to the Wikidata community, by which further data from persondata templates can be transferred, with confidence as to its accuracy, to Wikidata. Please do so, or admit that you cannot. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:04, 9 September 2015 (UTC)
I think that you two are focused on different aspects. Andy is talking about "all the data that can reliably be ported automatically"; Dirtlawyer cares about "all the data", full stop. I tend to agree with Dirtlawyer's suspicion that blanking the remaining data will, for all practical purposes, mean losing the remaining data. However, could we not blank the pieces that we know have been ported reliably, and keep the rest—perhaps with an in-article note that says not to restore what's been ported? Then we could at least clean up some and see the scope of the remaining problem. WhatamIdoing (talk) 00:08, 10 September 2015 (UTC)
@WhatamIdoing: To be clear, WAID, 100% is an unattainable standard, and I understand that perfectly. My primary concern, as I and other have noted above, is that most alternate names have never been transferred, and Andy and others are apparently aware of this fact. I have manually transferred the Persondata from over 1,000 Wikipedia articles since June 2015; well over half required the transfer of alternate names -- i.e., birth names, maiden names, married names, nicknames, etc. -- that were not transferred by bot action. As a result, I quite reasonably question the accuracy of the statement "all the data that can reliably be ported automatically" has been; in fact, I would say that it's pretty serious misrepresentation of reality. If that is the best "that can reliably be ported automatically, then we need to find better solutions. Please note I support GoingBatty's modified RFBA proposal to remove Persondata templates that are empty except for the primary name field. No one is questioning that Wikidata is the better long-term solution, or the deprecation of Persondata; I am seriously questioning whether we have made a best-efforts attempt to transfer all elements of usable Persondata, and alternate names in particular. My first-hand review suggests we have not, representations to the contrary notwithstanding. Dirtlawyer1 (talk) 01:51, 10 September 2015 (UTC)
Once again, you "question the accuracy of the statement 'all the data that can reliably be ported automatically' has been", with no evidence to support your claim; one again, I challenge you to show a method, acceptable to the Wikidata community, by which such data can be automatically transferred, with confidence as to its accuracy, to Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:47, 10 September 2015 (UTC)

Two sets of questions:

  1. When do those arguing that data should be maintained, pending manual checking, expect to complete that task? On what calculations are those estimates based? Why can such manual checking not be done using old versions of articles?
  2. How do those arguing for further automated transfer plan to carry out such transfer? And is this agreeable to the Wikidata community?

If sensible and workable answers are provided, I'll strike my request; if none are, the "oppose" !votes should be struck. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:25, 9 September 2015 (UTC)

If the answer to #1 were 2200, would it matter? Persondata templates do not change the rendering of an article whatsoever. They're not so costly to keep for now as to cause any real issues. A more workable proposal, and one I'm working on fine tuning, is to remove those instances of Persondata where we can reasonably assume everything has transferred to help those doing manual conversion focus on what actually needs doing. For instance, any transclusion of persondata that only has a name can obviously go, and I'm having some discussions on user talk pages about other combinations that could be removed with no data loss. That is a reasonable compromise route that you may wish to consider. ~ RobTalk 21:32, 9 September 2015 (UTC)
Yes, it would matter (and it would likely be an underestimate of the time required). We already have an RfC which found consensus to remove persondata. This is a discussion about using a bot to do so, not about re-running the original RfC. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:44, 9 September 2015 (UTC)
There was consensus to remove after the useful stuff was moved to WikiData, as far as I can see. A few editors close to the template who have been trying to carry out the consensus to transfer stuff over have stated this isn't complete, and I see no evidence that it is. All persondata should be removed eventually, yes. When depends on how long the transfer takes. ~ RobTalk 22:44, 9 September 2015 (UTC)
No. The closer stated Consensus is to deprecate and remove. No qualifiers; no waiting period. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:10, 9 September 2015 (UTC)
  • BRFA filed based on my prior suggestion, which is intended to be a compromise to respect both sides of this issue. GoingBatty (talk) 23:25, 9 September 2015 (UTC)
  • With respect, @Dirtlawyer1:, I will not change my vote. If nobody has found the need to save what data is not already at Wikidata in the last few months, I see no reason to expect it to happen in the next few months. The consensus of the May RFC should not be set aside because doing nothing is more convenient. The community already spoke, and I do not see value into essentially turning this into a rehash of that RFC. Resolute 23:29, 9 September 2015 (UTC)
    • @Resolute: You know me from previous discussions where we have been on the same side of the fence, and occasionally on opposite sides, as reasonable, intelligent people sometimes are. One thing you should know about me by now: I don't bulls@#$. With regard to the original RfC: (1) it did not specify how Persondata was to be removed, and bot deletions require additional approvals; and (2) the original RfC -- how shall I put this delicately? -- misrepresented the status of some usable Persondata, alternate names, in particular: based on my personal review and manual transfer of Persondata from over 1,000 articles to Wikidata, very few birth names, maiden names, married names, etc., were transferred by bot action. You're welcome to review my contributions to Wikidata since May 2015: [2]. I would say that the misrepresentation(s) regarding the "porting" of all usable information should come pretty close to voiding what validity the underlying RfC had/has, but that still does not address the question of bot action required for immediate removal. Mindlessly deleting all Persondata -- including alternate names, most of which have not been transferred -- is just that: mindless. There are multiple solutions here, all of which would be better outcomes for Wikipedia and Wikidata, than the immediate deletion of all Persondata. Dirtlawyer1 (talk) 23:54, 9 September 2015 (UTC)
      • Your claim that "the original RfC... misrepresented the status of some usable Persondata" is fatuous, and made, as usual, without evidence. The removal of Persondata templates would not me "mindless"; it has been well-considered. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:44, 10 September 2015 (UTC)
      • Sorry Dirtlawyer. I wasn't intending to target a general response to you personally. Also in general, when push comes to shove, I put very little stock into the needs of machines. So while I respect the work you are doing to aid WikiData, I find it preferable to dump the entire mess entirely since I do not believe it adds much value to the project. Resolute 15:05, 10 September 2015 (UTC)
  • Suggestion: Templates with no unique information are deleted. If there is potentially usable info then comment out the template. The comment may include a link for why it is commented out. That link would say the template is deprecated, include instructions for submitting any reliable useful info to wikidata, and say to delete the comment&template when done. Alsee (talk) 02:07, 10 September 2015 (UTC)
    • @Alsee: This comment actually functions as something that's commented out. It doesn't change the rendering of the page whatsoever and exists only to store metadata that is easily readable by machines; something WikiData was designed to take over. That's why we're interested in conversion to there. ~ RobTalk 21:32, 10 September 2015 (UTC)
      • The factlets in persondata which have not already been transferred are not "easily readable by machines", that's why they were not transferred, and why consensus to deprecate and remove them was reached. Yet again I suggest reading the RfC discussion, and the Wikidata discussion to which it linked. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:10, 11 September 2015 (UTC)
  • Oppose As one who has worked with the migration of Persondata to Wikidata, I want to see Persondata disappear, the data within it is just not reliable. For birth/death dates and places, there are more reliable templates to use as a source.
Up until now, I have ignored the alternative name parameter as personally I found it too random to be of any use. However, @Dirtlawyer1: has convinced me that there is data that would be lost. My suggestion of a way forward would be be to remove persondata. If there is an alternative name, create a {{aka}} template. Make this visible at the top of the article and the community would correct the dodgy ones. Periglio (talk) 02:38, 10 September 2015 (UTC)
  • Suggestion: I was pinged, and now don't know where to add. I have personally replaced Persondata by infoboxes, much more useful because visible. {{Infobox person}} can hold alternate names easily. I imagine that a bot could check, when removing Persondata, if all information is already in an infobox, if not transfer it there, and if none exists, propose one on the talk page, again to keep the data somewhere visible. (It's not the first time I suggest this. I try to avoid mentioning infoboxes because some don't like them but can't stop thinking that they are useful.) --Gerda Arendt (talk) 08:59, 11 September 2015 (UTC)
  • Support: Wikidata covers what is needed, I always wondered why we ever used persondata, it seemed clunky to add invisible content when the same could - and should - be included in visible data in every article. Seems the decision has been made that it's duplicative, so let's get the ball rolling. Montanabw(talk) 21:24, 14 September 2015 (UTC)
  • Support: The PersonData template was deprecated back in October 2014. After that, no one was supposed to add it to any new articles. Changes were made to prevent its automatic addition. A far better attended RfC in May gave clear support for its methodical removal. I was disappointed that the WikiData people pronounced it of no use whatsoever for their purposes. There was talk of migrating information to the Infoboxes, but no support for this. Which left us with editors being advised not to include them on new articles, to remove them whenever they are editing an article with one, and to get a bot to do the final clean up. Andy is just responding to the recommendation of the RfC and the BRFA. I don't know and don't care what is on Wikidata - it has absolutely nothing to do with us. But I do know that all the information in the PersonData template is already present elsewhere in the article. Hawkeye7 (talk) 05:57, 7 October 2015 (UTC)

Multiphase removal

As I botop, I have a suggestion. It's clear consensus supports removal, at some point, but nobody can seem to agree when that removal should happen. So let's take it at chunks at a time. Here are the phases:

  1. Remove all blank templates...
  2. Decide on parameters of the persondata template that can be ignored and make another passtrhu with the bot.
  3. Repeat 2 until templates with useful information are left.
  4. Decide on suitable replacements for the remaining parameters of remaining templates.
  5. Implement suggestion with a bot
  6. Make a final deletion passthru with the bot
  7. Have champagne and beer to celebrate.

How does that sound?—cyberpowerChat:Offline 09:21, 11 September 2015 (UTC)

I should point out that number 1 is already being worked on.—cyberpowerChat:Offline 09:24, 11 September 2015 (UTC)
I've never seen a blank persondata template in an article; do you have examples? What do you mean by "suitable replacements for the remaining parameters"? And can you relate this proposal to the parallel discussion on Dirtlawyer1's talk page, where a different approach is being proposed? How do you propose to mitigate the apparent "error/conflict rate of 10+%" disclosed there? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:03, 11 September 2015 (UTC)
In which case, Andy, that step should be quick and painless.
Cyberpower, what do you think about changing the "final deletion passthru" to a "copy it to the talk page and remove from the article passthru"? That increases the odds that someone would look into it. WhatamIdoing (talk) 15:04, 11 September 2015 (UTC)
No objections
The BRFA is approved and there are edits that prove the template. Just go there. Each parameter it seems describes an attribute about the person that can be moved to a category, infobox, or whatever. That's what I mean. I'm not proposing anything, I'm suggestion a method of discussion that involves the creation of multiple proposals and them being acted on accordingly, where the final end result is the complete removal of persondata. I'm suggesting a method that might work.—cyberpowerChat:Online 21:11, 11 September 2015 (UTC)
You wrote above "I have a suggestion", so you definitely are proposing something. Much of the data is not fit for moving to a category or infobox, as discussed in the aforesaid RfC and on Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:54, 11 September 2015 (UTC)
Which step? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:54, 11 September 2015 (UTC)
The one in which the non-existent (according to you) templates are removed. If none exist, then performing that step should be quick, easy, and painless. WhatamIdoing (talk) 02:47, 12 September 2015 (UTC)
You must be thinking of someone else. I have made no assertion that any templates are "non existent". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:13, 12 September 2015 (UTC)
Right, you only say that you, who have seen thousands and thousands of persondata entries, have never seen such a thing. I admit that is somewhat different from positively asserting that none exist, but still: if you can look at many thousands without ever finding such an example, then removing the few that exist—if they exist—is still likely to be quick, easy and painless. WhatamIdoing (talk) 02:09, 13 September 2015 (UTC)
@C678: My proposal is to delete Persondata only if all of its values are found elsewhere in the article. For example:
  • Persondata |ALTERNATIVE NAMES= = Infobox |birth_name=
  • Persondata |ALTERNATIVE NAMES= = Infobox |other_names=
  • Persondata |NAME= = Persondata |ALTERNATIVE NAMES=
  • Persondata |SHORT DESCRIPTION= = Category
  • Persondata |DATE OF BIRTH= and/or |DATE OF DEATH= = birth date and/or death date from lead
  • Persondata |DATE OF BIRTH= = Infobox |birth_date=
  • Persondata |DATE OF BIRTH= = Category:#### births
  • Persondata |PLACE OF BIRTH= = Infobox |birth_place=
  • Persondata |PLACE OF BIRTH= = Category:People from xxx
  • Persondata |DATE OF DEATH= = Infobox |death_date=
  • Persondata |DATE OF BIRTH= = Category:#### deaths
  • Persondata |PLACE OF DEATH= = Infobox |death_place=
I created a custom module at User:BattyBot/Persondata and submitted a bot request for this, but the bot request was only approved to remove those templates that only have |NAME= populated. Any suggestions for careful removal of Persondata templates that doesn't prohibit the copying of data to Wikidata would be appreciated. Thanks! GoingBatty (talk) 04:28, 12 September 2015 (UTC)
I don't think the presence of any category is a valid substitute for short description. Similarly, we'd have to be somewhat careful with alternative names; the mere presence of an other_names parameter doesn't guarantee every alternative name is listed there. We would need to be careful that we're starting with edits that have zero data loss and going from there. This will help all parties, for the record; we have to start the deletion somewhere, and it might as well be here. It also gives those doing manual transfer an easier time by removing instances where no information is lost and giving them more time to work on the transfer. I'm not suggesting holding up the deletion, just that we might as well start with the deletion that no-one objects to before moving to the deletion that has substantial resistance, even if it's not a consensus not to delete. There's no point in trucking through the editors interested in manual transfer immediately when it will accomplish the overall task no faster. ~ RobTalk 04:52, 12 September 2015 (UTC)
@BU Rob13: Sorry I wasn't clear. When looking at categories, I meant matches such as Persondata |SHORT DESCRIPTION=American actor = Category:American actors. I also meant exact matches where the entire Persondata |ALTERNATIVE NAMES= value is in the Infobox |birth_name= or |other_names=. Please see User:BattyBot/Persondata for the details of the rules - any suggestions would be appreciated. GoingBatty (talk) 05:16, 12 September 2015 (UTC)
I'm not discussing a proposal to remove something and how to remove it. I'm discussing a proposal on a possible system of discussions so we can systematically remove them where almost everyone can agree with the outcome.—cyberpowerChat:Offline 06:11, 12 September 2015 (UTC)
@C678: Sorry for misunderstanding. I appreciate your efforts in proposing this path forward. GoingBatty (talk) 13:16, 12 September 2015 (UTC)
@Pigsonthewing: BattyBot just edited 34 articles that had a blank {{Persondata}} template (e.g. [3], [4], [5], [6], [7]). GoingBatty (talk) 05:11, 12 September 2015 (UTC)
@Pigsonthewing: BattyBot also has edited articles that had a full {{Persondata}} template with no values (e.g. [8], [9]). GoingBatty (talk) 05:38, 12 September 2015 (UTC)
Thank you for clarifying. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:13, 12 September 2015 (UTC)
@C678: Another proposal would be to remove the entire {{Persondata}} template from pages in the Draft namespace. Since they are not articles, I'm guessing they wouldn't be candidates for copying to Wikidata. Thanks! GoingBatty (talk) 05:59, 12 September 2015 (UTC)
@GoingBatty and C678: What's the policy/process for Wikidata creation for new articles? Presumably, for newly created articles there is standard process -- automated? -- to create new Wikidata profiles. Can someone who is knowledgeable about this process describe it for our benefit? If this process exists, then there is no reason why articles in draftspace should have Persondata templates. That said, I can't imagine that we're talking about more than a few dozen to a couple hundred affected articles. Dirtlawyer1 (talk) 06:22, 12 September 2015 (UTC)
There is no reason for any article, much less one in draft space, to have a Persondata template. The template is been deprecated. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:17, 12 September 2015 (UTC)
@Dirtlawyer1: I'm not aware of automated process for Wikidata creation based on new Wikipedia articles. I'm also not aware of any policy that mandates that new article creators on Wikipedia also must manually create Wikidata. I would agree that the number of Draft articles with Persondata is a small number. GoingBatty (talk) 13:06, 12 September 2015 (UTC)
@GoingBatty: So, there is no established process for the creation of Wikidata profiles for newly created articles? That's a rather serious omission, don't you think? That said, I also recognize that it's beyond the scope of our present discussion. As for the Persondata templates in draftspace, it would seem that some form of notice should be provided to the draftspace article creators that Personadata has been deprecated, so that no further effort is expended. Dirtlawyer1 (talk) 14:12, 12 September 2015 (UTC)
@Dirtlawyer1: Just stumbled across Category:Wikidata tracking categories, which may interest you. GoingBatty (talk) 18:05, 12 September 2015 (UTC)
See that would be something that could be discussed in phase 2.—cyberpowerChat:Offline 06:11, 12 September 2015 (UTC)
@GoingBatty: Okay. What's the official count on Phase I? Has BattyBot run its full cycle? I just checked, and it appears to have removed the Persondata templates from something like 1,700 articles. Dirtlawyer1 (talk) 06:22, 12 September 2015 (UTC)
@Dirtlawyer1: I got all the low hanging fruit first, and now it's going through the first million transclusions of Persondata. However, I'm not anticipating a significant number of additional removals. GoingBatty (talk) 13:06, 12 September 2015 (UTC)
@Dirtlawyer1:  Done - I estimate less than 2,000 944 removals. Only 1.2 million to go. GoingBatty (talk) 02:56, 15 September 2015 (UTC)

@GoingBatty: I understand what you're trying to do with your phase II proposal above. It is predicated on the idea of data preservation, i.e., does the same data exist somewhere in the existing article. My concern is data transfer, i.e. the transfer of Persondata information to Wikidata. So here's my fundamental question for you: why aren't we comparing Persondata to Wikidata? Dirtlawyer1 (talk) 14:21, 12 September 2015 (UTC)

@Dirtlawyer1: Yes - data preservation (by eliminating redundant data first) so that others more technical than I am can continue their efforts of data comparison and data transfer. My proposal also assumes that those who have the technical skills to do data transfer from Persondata to Wikidata could also do data copying from infoboxes and categories to Wikidata. GoingBatty (talk) 14:35, 12 September 2015 (UTC)
"so that others... can continue their efforts of data comparison and data transfer" - I'm not clear what part of this you're having trouble with: but to clarify, again: Those people have already migrated all the data which it is possible and sensible to automatically migrate. They then discussed the results on both Wikidata and Wikipedia, including the errors fund and the unreliability of parts of it, and as a result it was agreed at both projects - in the case of this Wikipedia, via an RfC - that what could be done had been done, and that no more should be done, and that the Persondata template is deprecated and should be removed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:30, 12 September 2015 (UTC)
Hey, Andy, once again, you've overstated your case, and that's why we're having this discussion now. You have repeatedly cited the May 2015 RfC as the basis for the deprecation and immediate removal of Persondata by the use of bots. In case you have forgotten, when asked for clarification on his user talk page, here's what the May 2015 RfC closing administrator had to say:
Andy, ping me off-wiki. You are in danger of WP:NCR. Seriously, calm down, it can be done slowly and methodically, and let people come to terms with it over a period of time. Seriously, just chill a bit and you'll win the battle for hearts and minds. Nobody doubts your commitment or passion, but you have a positive genius for rubbing people up the wrong way! Guy (Help!) 21:57, 2 June 2015 (UTC) [10].
That's what the RfC closing administrator had to say, in addition to offering you some excellent personal advice. Do you really want me to post the RfC closing administrator's clarification under every comment where you claim the RfC as authority for the immediate bot removal of all Persondata information? Dirtlawyer1 (talk) 18:29, 12 September 2015 (UTC)
@Pigsonthewing: You're at one extreme, and Dirtlawyer1 is the other extreme - I'm just trying to find the middle ground. Dirtlawyer1 is very interested in data transfer to Wikidata, and is doing so manually. Maybe Dirtlawyer1 will find someone to migrate more data programmatically, and maybe he won't. I've done a little data transfer from Persondata to other areas of the Wikipedia article (e.g. infoboxes and categories) - maybe there's opportunity for moving more programmatically and maybe there isn't. Agreeing on any set of Persondata to programmatically remove gets us closer to your goal of removing all of it. GoingBatty (talk) 18:05, 12 September 2015 (UTC)
I don't believe it's "extreme" to remind people of the outcome of a well attended, and convincingly decisive, RfC. And thank you, but we don't need to find the "middle ground" between that consensus and one extreme. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:12, 12 September 2015 (UTC)
Andy, here's what the May 2015 RfC closing administrator had to say:
Andy, ping me off-wiki. You are in danger of WP:NCR. Seriously, calm down, it can be done slowly and methodically, and let people come to terms with it over a period of time. Seriously, just chill a bit and you'll win the battle for hearts and minds. Nobody doubts your commitment or passion, but you have a positive genius for rubbing people up the wrong way! Guy (Help!) 21:57, 2 June 2015 (UTC) [11].
Do we really need to quote it every time when you cite "the outcome of a well attended, and convincingly decisive, RfC"? Dirtlawyer1 (talk) 18:29, 12 September 2015 (UTC)
You've had a "period of time". May was four months ago. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:58, 13 September 2015 (UTC)
@Pigsonthewing: "Extreme" was a poor word choice - I apologize. Unfortunately, repeating the RfC outcome doesn't seem to be helping. @Dirtlawyer1: No, you don't need to post the wall of bold text again - we got it. I fear that we're not going to make any significant steps forward until the two of you can come to some agreement. GoingBatty (talk) 02:33, 15 September 2015 (UTC)
It looks more like we need to wait until Dirtlawyer1 finds an agreement with the rest of us users who support removal of persondata. If a bot removes persondata, editors watching articles will notice on their watchlists when that happens. If they care they will check what has been removed and - if needed - place it at an appropriate place in the article. I trust us editors and am not afraid of a loss of data. Keep simple. (I also made a suggestion in the section above how keeping data could be done by the bot, which I don't want to repeat again.) --Gerda Arendt (talk) 07:02, 15 September 2015 (UTC)
I've not really been following the details, but this remark does not seem very sensible to me. Much more likely is that most editors will simply trust that the bot, which would have been given approval for this action, would know that every relevant piece of information had already been migrated. It doesn't seem like a good idea to have editors managing the fallout. Granted, those that are "in the know" will probably check up on the bot, but the majority of us will just ignore it. Also, I question the logic of doing this at all by an automated process if a massive decentralized volunteer effort is going to be needed to clean up afterwards. It seems simpler to me to have volunteers migrate the data in the first place. As I understand it, that's how things are currently being handled. Sławomir
Biały 10:31, 2 October 2015 (UTC)

Closure request

I've de-archived the above; could somebody uinvolved close it, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:03, 1 October 2015 (UTC)

  • Oppose immediate closure - I strongly oppose the request for an immediate closure of this RfC: this discussion is NOT RIPE FOR CLOSURE. Previous discussions of Persondata have significantly misrepresented the status of accurate and usable information from Persondata, as well as the extent of previous bot efforts to transfer information from Persondata to Wikidata. I am happy to review my own empirical review and comparison of over 1500 Persondata templates to their corresponding Wikidata profiles. This is one of sloppiest technical processes that I have witnessed in my six and a half years of editing the English language Wikipedia. We need an orderly process to continue to discern what remains that is usable, and transfer accurate information from Persondata to Wikidata, not simply delete all of it by mindless bot action without review. Dirtlawyer1 (talk) 22:06, 1 October 2015 (UTC)
    • Of course you do; having this drawn out serves your bizarre objection to enacting the existing RfC conclusion; which RfC was "an orderly process to discern what remains that is usable". Nonetheless this discussion is so over that it was already archived. If there is consensus for your PoV, why would you object to having that noted in a closing statement? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:50, 2 October 2015 (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.

Redirect "TEN" (all caps) to "Toxic epidermal necrolysis"

Wrong forum. Discussion moved to Wikipedia:Redirects for discussion/Log/2015 October 29#TEN. Steel1943 (talk) 19:06, 29 October 2015 (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 would like to suggest that TEN (all caps), which presently redirects to 10 (number), be changed to point to Toxic epidermal necrolysis instead, as this would seem to be much more useful for encyclopedic purposes. If deemed appropriate, the latter article could have a headnote added reading, "TEN redirects here. For the numeral, see 10 (number)." (I considered doing this myself in the spirit of WP:BOLD, but decided it would be better in this case to ask first.)— Jaydiem (talk) 18:56, 29 October 2015 (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.

Auto sign on talkpages

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
There is consensus for the proposal. The majority opinion stated ease of use and help for new users, also better for mobile editing. The minority opinion was that it may be hard to implement and other related issues. AlbinoFerret 19:37, 29 October 2015 (UTC)
Tracked in Phabricator
Task T117157
Moved from Wikipedia:Village pump (idea lab)
 – Mz7 (talk) 22:34, 5 September 2015 (UTC)

Now that Flow is deprioritised, I suggest we default all new accounts to autosign on talkpages.

This would require a new preference "autosign on talk" which would default to signing all your posts on talkpages, and a new tick box on the edit screen "sign this edit".

Existing editors could blithely ignore this if they wished, but simply clicking "sign this edit" would be a new way to add a space and four tildas when wanted. New editors and editors who opt in by changing their preferences could still untick "sign this edit" when fixing a typo in their previous talkpage comment.

RFA and certain other pages where you are expected to sign could have a special template to enable autosigning

All welcome templates could have the clunky, offputting and very silly looking bit about please sign your posts on talkpages with ~~~~ removed.

The WMF is asking for community input into things they could do instead of FLOW - this could be one of them. ϢereSpielChequers 13:37, 3 September 2015 (UTC)

  • Support - Good idea that's long overdue. The User:Sinebot does this as a cleanup measure anyway, and this would help demystify/declutter talk pages, which by almost every measure are a usability nightmare for newbies. -- Fuzheado | Talk 14:11, 3 September 2015 (UTC)
  • Support - frankly this should be in MediaWiki itself. Suggested method: if it doesn't detect a ~~~~ it adds one. You can switch this off in your preferences. Everyone who already has an account starts with it switched off, everyone creating a new account starts with it switched on - David Gerard (talk) 14:15, 3 September 2015 (UTC)
  • Support in the model suggested by David Gerard -> I have never understood why we rely on a bot to do this work, when we could just be signing as part of the software, Sadads (talk) 14:16, 3 September 2015 (UTC)
    One limitation should prevent edits to the header section of an article (such as infoboxes) from being signed. Sadads (talk) 14:17, 3 September 2015 (UTC)
  • Comment How does Sinebot determine where to put the signature? Presumably this would use a similar algorithm. We would need some sophisticated algorithms or very clear opt-out boxes to avoid messing up e.g. talk page refactoring and archiving. BethNaught (talk) 14:20, 3 September 2015 (UTC)
  • Support, should indeed be in MediaWiki itself. Fundamentally a talk page should be more like a blog page with threaded comments. As an ordinary non-admin user, I should be able to make posts like this one with the software autosigning, and edit them afterwards without having to specially turn off autosign but with the software either replacing the autosignature (not adding another one) or adding a small text such as "edited [timestamp]". But as an ordinary non-admin user, I shouldn't be able to edit other people's posts, which AFAIK I can, though I've never tried. Stanning (talk) 14:48, 3 September 2015 (UTC)
  • Support This is a great idea. I have proposed an addon on below.—cyberpowerChat:Online 15:24, 3 September 2015 (UTC)
  • Support, provided there is a clear opt-out so correcting a typo etc. does not result in another signature. If the function could be clever enough to detect when I am just editing my own, already-signed post, all the better. Andreas JN466 16:11, 3 September 2015 (UTC)
  • Comment If implemented it in JavaScript it could be running by next week. Doing it JS gives us better interactivity with the user and it would be open source unlike User:SineBot. Why wasn't it suggested before? Oh right: "FLOW is going to fix discussions". — Dispenser 17:39, 3 September 2015 (UTC)
  • Support. I didn't even know WP:FLOW had been deemphasized! --IJBall (contribs • talk) 19:46, 3 September 2015 (UTC)
  • Support. A sensible improvement to the current talk system. Should really be in core MediaWiki. MER-C 01:11, 4 September 2015 (UTC)
  • Support - as long as there is the choice to untick the box, e.g. for minor corrections to talk posts that I've already signed. Smallbones(smalltalk) 13:41, 4 September 2015 (UTC)
  • Support, especially the "special template" to enable autosigning, which is a great idea. APerson (talk!) 18:25, 4 September 2015 (UTC)
  • Support a great idea, new users can integrate more easily with one less of Wikipedia's many idiosyncracies to master. --Tom (LT) (talk) 00:49, 5 September 2015 (UTC)
  • Support - I concur with the above this really should be part of the MediaWiki software, I have a quite few newbies who post on my TP and never sign there posts and seeing as the bot never shows up it means I have to do it myself and quite frankly it's a pain in the arse at times (Admittingly I don't have to do it but I prefer them all signed & dated), Anyway it's a great idea!. –Davey2010Talk 01:08, 5 September 2015 (UTC)
  • Oppose as proposed. Many, many users have different signatures from their usernames, or have designed personalized signatures well within our signature guideline that are as much a part of their Wikipedia identity as their contributions history. The four tildes is what pretty much every experienced Wikipedian uses, not the "sign this edit" button (which on my screen is in the middle of a long string of small boxes and it doesn't even say "sign", it's just a representation of cursive writing). It also disenfranchises new users from participating in non-talk pages where signatures are expected, which encompasses most pages in Wikipedia space, and some in other areas, because they will never figure out how to do it. Risker (talk) 03:05, 5 September 2015 (UTC)
    • @Risker:, We are not proposing to replace tildes with a button, we are proposing to allow users to eliminate both. The intention is that the page is automatically signed with your signature, not a generic one. If you set the auto-sign user preference, you wouldn't need to type tildes or click a button, it would just do it for you like it should. Also, using categories or magic words, the software would also sign pages that are used as discussions even if they don't have talk in the name. Oiyarbepsy (talk) 00:00, 6 September 2015 (UTC)
  • Support although it's pointless to do so, since AFAIK this is a WONTFIX issue; would've been done a long time ago if it weren't. Signing is one of our more ridiculous and archaic-looking insider shibboleths. It's also a PITA on mobile, and anything that can make editing on mobile less of a dumpster fire of awfulness is a good idea. Opabinia regalis (talk) 03:59, 5 September 2015 (UTC)
  • Support If a bot can figure out how to do this then the interface can just use similar logic. Andrew D. (talk) 09:59, 5 September 2015 (UTC)
    I think Sinebot limits itself to new posts at the end of a section. This is precisely because it couldn't reliably figure out the correct action in other situations. If you add a new unsigned comment in the middle of a thread, the bot won't help you. The bot is also restricted to certain talk spaces. Thus a bot comparison isn't particularly apt. ―Mandruss ☎ 09:20, 6 September 2015 (UTC)
  • Conditional support - I think this is a good idea, particularly for mobile devices, as in some mobile keyboards the tilde "key" is hard to find. However, I have one issue regarding how this could work: how would this work if a user adds more than one paragraph or replies to separate paragraphs in the same edit? For example, what if I reply at this section and the section below in the same edit? Would it only sign one of my additions or both? Also, if this proposal is to pass, the coverage could also be expanded to include pages outside of Talk namespaces, such as noticeboards and the Reference desk (i.e. any page in Category:Non-talk pages that are automatically signed. Narutolovehinata5 tccsdnew 15:48, 5 September 2015 (UTC)
    Good point, but probably a rare/advanced user one. I suspect if you reply to more than one thread in the same edit it will only sign one of them, however by the time people are doing that they are likely to have learned how to get round that. ϢereSpielChequers 09:52, 7 September 2015 (UTC)
  • Support We already have bots that do this, so I see no reason why it can't just be done automatically whenever a talk page edit is made. Spirit of Eagle (talk) 22:41, 5 September 2015 (UTC)
  • Oppose People often edit their own comments or make other talk-page edits that don't involve the addition of new comments and shouldn't be signed. Sometimes, people even remove their own comments that they believe to be inappropriate. Even IPs often do this, especially in the case of people who edit frequently without accounts. These edits should never be signed; how would the software detect this kind of thing? However, I would support auto-signing of comments added through the add-a-new-section button, since those always should get signatures. Nyttend (talk) 23:52, 5 September 2015 (UTC)
  • Oppose A lot of article talk pages have a large top section that that contains things like ArbCom notices, old AfD notices, GA nom notices, etc. There is also the issue where at times you'll want your signature to be one space behind you post, at other times on a new line below it. It also lets you know about a user's competency as to whether they add a signature or not. Jerod Lycett (talk) 08:59, 6 September 2015 (UTC)
  • Support Support as opt-in, Oppose as opt-out Oppose - Which is harder, typing the tildes or clicking the button when you need a sig, or unchecking the box when you don't? Seems like a wash to me, but I'm willing to support giving it a try if WMF is willing to do it. It's completely opt-in, it affects no one who doesn't want it, so the worst case is that we keep a former Flow developer employed for awhile and then have to yank the feature back out in a few years because of lack of use. I could live with that worst case. ―Mandruss ☎ 09:37, 6 September 2015 (UTC)
    • The proposal by DavidGerard is opt-out, not opt-in. The proposal is to give this to everyone by default and then to let people opt-out if they don't like it (and if they can find a prefs switch in the long list of gadgets). I'd be opting out immediately, of course. WhatamIdoing (talk) 16:06, 6 September 2015 (UTC)
      • @WhatamIdoing: That's incorrect. This proposal is as I said at the top for "New editors and editors who opt in" David Gerrard added a suggested methodology, but he stuck with the same "opt in for existing accounts, opt out for new ones" logic. Nobody is suggesting the opt everyone in approach that WhatamIdoing opposes. ϢereSpielChequers 16:08, 8 September 2015 (UTC)
      • I stand corrected, thanks. New optional features should generally be opt-in, and this is especially true when a feature affects everyday work to such a degree. It would be highly disruptive to throw this in and force everyone to adapt immediately or change their prefs immediately. Modified my !vote. ―Mandruss ☎ 00:29, 7 September 2015 (UTC)
      • The ideal would be opt-in for existing users and opt-out for new users, making this even more messy. If this was at VPI first, I'm surprised this didn't come up there, or, if it did, I'm surprised the consensus there was opt-out for everyone. Sorry I missed that. But this Wikipedia thing is a messy business all around. ―Mandruss ☎ 01:55, 7 September 2015 (UTC)
        • That might be possible, although it's my impression that it would not be quick and easy. WhatamIdoing (talk) 02:50, 7 September 2015 (UTC)
          • Although I know nothing of the internals, the impression I have from decades in development is that it shouldn't be any harder at all. Seems to me there will be necessarily be two pieces of software involved: (1) a one-time mass update to add the new field to existing prefs, and (2) the code to create a new user. If that's the case, the former could set the fields to "off" and the latter to "on". But who knows. ―Mandruss ☎ 04:59, 8 September 2015 (UTC)
    • Alrighty Then. Per WereSpielChequers's comment above, there's apparently some confusion here as a result of failure to nail down the particulars at VPI first. In any case, if Quiddity (WMF) is to be believed below, and they are in a position to know, opt-in for existing users is not a practical possibility. Since I can't live with opt-out for existing users, I'm left to Oppose. As I said, it's a wash anyway, largely trading one editor effort for another. I'm modifying my !vote, again. ―Mandruss ☎ 09:26, 10 September 2015 (UTC)
  • Strongest possible support. The Opt-OUT idea is good as are some of the other technical suggestions for identifying the kind of pages or edits. Kudpung กุดผึ้ง (talk) 05:26, 8 September 2015 (UTC)r.
  • Comment There are a couple of key points:
  • This proposal is not possible as phrased, because it is asking to turn the gadget off for 25 million existing accounts, but to turn it on for two or three million new accounts each year. This is not possible without some big changes to the performance of the preferences system in MediaWiki, and hacks to implement it would lead to the same performance issues described in the discussion about how to solve exactly this performance problem for VisualEditor (i.e. millions of accounts adding a new preference). Ultimately the developers would come in and switch anything like this off to save the site from falling over.
  • If a gadget is used, then to satisfy the requirements of being available for all newcomers (optionally including IP-editors), it would need to be "default on for everyone", with the usual gadget opt-out possibility for experienced users (as we have with Reference Tooltips, for example).
If we do decide to experiment with a gadget, there's an existing userscript at Dewiki (w:de:Benutzer:Perhelion/signing), which appears to generally work as expected. It will have all the limitations that Sinebot does, and possibly more. Creating something more reliable is an extremely difficult goal (because of all the edge-cases), which is why it hasn't been solved in the last 15 years. HTH. Quiddity (WMF) (talk) 18:03, 9 September 2015 (UTC)
    • We now have a range of opinions on the technical side from this needing a week to it not being possible. While I'm not a mediawiki coder, I've been in IT for long enough to know that if the decision is to go ahead the reality will be somewhere in between. We might at worst have an entirely opt in system where we can at least amend all our welcome templates to give people a choice between learning to type tildas or clicking something to set a user preference; That would of course still be a big win. In the meantime can I suggest that we focus this discussion on whether we want to introduce an autosign system with an opt out for existing accounts and an opt in for new ones; And can I point out to those who believe in Flow, that Flow would be resented by fewer if its price didn't include a blanket veto on any attempt to improve the existing software. ϢereSpielChequers 11:00, 10 September 2015 (UTC)
@WereSpielChequers: I now see at least some rationale for opt-in for new users, I guess. I still can't see forcing 120,000 active users to adapt immediately or change prefs immediately; that is, unless we made it extra challenging for the developers and required some kind of pop-up "Do you want this or not?" the first time they edit a talk space after the change. The pop-up would then set the prefs according to the answer given. Without something like that, how are 119,800 of those users going to know about the change and how it affects them? I don't see anything about that in the proposal.
I'd support opt-in for everyone, but this proposal seems pretty much off the rails to me and a new one would be in order (maybe after another round at VPI). I know, it's incredibly messy and frustrating, I've been there. ―Mandruss ☎ 14:28, 12 September 2015 (UTC)
  • Oppose per Nyttend. New editors will be annoyed with the fact that their copyedits will be auto-signed, causing a random signature to show up at the end of their copy edits. Also, this proposal assumes that the editor will be knowledgable enough to navigate to the preferences page to disable this feature, which is bad to assume. It would be more efficient for a bot to place an {{Unsigned}} template after the comment, then place some sort of warning message on accounts that fall under the "new" criterion as outlined in this discussion (provided that bot had not already been created.) Steel1943 (talk) 22:28, 11 September 2015 (UTC)
  • Support awesome idea Datbubblegumdoetalkcontribs 01:03, 15 September 2015 (UTC)
  • Support This is a good idea for signing talk pages. I recommend thgis be applied across all projects. There could be some editors who forget to sign their comments and other correspondence (I have sometimes as well), but a bot autosigns it. Still, it's an aye from me. Sam.gov (talk) 22:48, 16 September 2015 (UTC)

Set default discussion pages

In conjunction to the proposal above, I believe it is technically possible to implement this. All odd numbered namespaces are talk pages are extremely likely to be talk pages. The system could have magic words such as __NODISCUSSION__ and __ISDISCUSSION__, where the automatically leave the option unticked, or automatically tick it, respectively.

@Cenarium and Cyberpower678: Wait, unless I've misunderstood something, there are some discussion pages that do not use the "new section" link, AfD discussions being the first that come to mind. Mz7 (talk) 00:43, 6 September 2015 (UTC)
Last year, the AFC project made the change from the Wikipedia talk namespace to the Drafts namespace. I do not believe there are still AFC drafts in the Wikipedia talk namespace, so I'm not sure if this exclusion would be necessary. Mz7 (talk) 00:46, 6 September 2015 (UTC)
Doesn't look necessary. Eman235/talk 00:59, 6 September 2015 (UTC)
Slipped my mind to do a prefix search. It actually does look like it might be necessary. (The prefix is "Articles for creation" not "WikiProject Articles for creation".) While there aren't any pending drafts currently in the Wikipedia namespace, there does appear to be a significant number of declined and old WP:CSD#G13-postponed drafts still there. Mz7 (talk) 02:13, 6 September 2015 (UTC)
A better looking list is at WP:Requested moves/Old AFC submissions. 103.6.159.77 (talk) 13:11, 20 September 2015 (UTC)

Move to Wikipedia:Village pump (proposals)?

I was going to add my support to the discussion above, but I was hit by the edit notice for the page, which says it's not for consensus polling. Since there has been a rather overwhelming outpouring of support for this idea, and also since it's been listed on WP:CENT, I think this idea should be given the okay to move to the proposals village pump (the entire discussion above should probably be moved there). Mz7 (talk) 02:44, 5 September 2015 (UTC)

Agreed. This is no longer an idea lab.—cyberpowerChat:Limited Access 15:02, 5 September 2015 (UTC)
 Done Mz7 (talk) 22:34, 5 September 2015 (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.

Spark Energy / 2 different companies

The article for Spark Energy needs to be split into 2 articles, for 2 completely different companies. One based in the US and one in the UK. Victor Grigas (talk) 02:07, 29 October 2015 (UTC)

This is probably best to discuss on the talk page of the affected article, not here. GenQuest "Talk to Me" 06:17, 30 October 2015 (UTC)

Wikipedia:Five million articles - an open letter from the community

Hello everyone. There have already been discussions for a temporary logo to celebrate 5 million articles (discussion for idea, discussion for actual logo), and in each, the idea of an open letter from the community to clarify what the milestone symbolizes was viewed favorably. We have been drafting such a letter at Wikipedia:Five million articles. You are invited to boldly edit and improve the letter, or make comments on the talk page. Thanks! Mz7 (talk) 22:38, 30 October 2015 (UTC)

Language profile

I don't understand why the feature to select personal spoken languages in my own profile settings is missing! If you read a lot and switch between different languages it is unpleasant to select the desired language from the list, because it is so long. Most people (99%) will only want to read articles in 1-4 languages, i guess. Implementing this feature should be quite simple; it should take a good programmer less then a day. Looking forward on your comments! — Preceding unsigned comment added by Atom Materialist (talk • contribs)

Atom Materialist, I'm not sure which thing you're talking about. Can you give me a step-by-step guide to what you're doing, and how it differs from what you expected? Wikipedia:Screenshots of Wikipedia has instructions if it's easier to upload a screenshot. Whatamidoing (WMF) (talk) 19:00, 30 October 2015 (UTC)
Interlanguage links (to the corresponding article in other languages) I assume? Can be annoying when you switch between languages often, the mix of languages and character sets makes it more difficult to quickly locate the right one (and I often look for Dutch or German before realizing it's Nederlands or Deutsch I want). But it's a minor problem that affects few users. Ssscienccce (talk) 04:10, 2 November 2015 (UTC)
It's minor if you only use Wikipedias in languages you are familiar with. It should conform to language preference if set. All the best: Rich Farmbrough, 16:04, 3 November 2015 (UTC).
I think the proposal is to allow a small group of languages to be used in the interwiki slot instead of all that apply. Certainly allowing one to prioritise would be useful. All the best: Rich Farmbrough, 16:07, 3 November 2015 (UTC).

Give out Deletion to Quality Awards and log at Hall of Fame

Please see Wikipedia:Bot_requests#Give_out_Deletion_to_Quality_Awards.

A one-time-run would be totally acceptable here.

Is there any way either a bot or someone with a user script or automated or semi-automated skills, can help out here ?

Thank you,

— Cirt (talk) 03:37, 4 November 2015 (UTC)

Auto-generate backlinks, make all inter-page links bi-directoinal

When displaying any page, append an automatically generated list of links to all the pages that reference it. (filter this list to remove links that are already explicitely given, and truncate it to some sensible maximum if its' too long).

This should (a) increase the ability to browse related subjects, (b) encourage contributors or readers to check both pages and cross reference that the information is consistent or not excessively repetitious; it maybe possible to rework articles to include explicit links later, better leveraging both pages.

(does this already exist? is there something I'm missing? I was finding myself wanting to add such links to 'see also' manually. would it be too noisy?) — Preceding unsigned comment added by 81.155.67.16 (talk) 19:22, 5 November 2015 (UTC)

In the left hand column under Tools there's a link called, "What links here" that produces a list of all pages that link to the target page. Is this (sort of) what you're looking for? ~ ONUnicorn(Talk|Contribs)problem solving 20:21, 5 November 2015 (UTC)

oh,thanks. I'm blind, that does the job. I had thought having those links inplace might be useful, but there seems to sometimes be many more than I expected. maybe there would still be value in the filtering and having a few backlinks iplace. — Preceding unsigned comment added by 81.155.67.16 (talk) 04:05, 6 November 2015 (UTC)

Categories

Categories should be visible on the mobile Wikipedia. GeoffreyT2000 (talk) 01:15, 3 November 2015 (UTC)

This can be implemented by somebody else, though do you have any ideas for implementation? --Kiyoshiendo (talk) 04:27, 6 November 2015 (UTC)

extended markup hints - for translation/disambiguation, part-of-speech

Has the community considered extending the markup syntax - allowing various hints to assist machine parsing/translation of the articles;

These new hints would be invisible in the standard rendered pages; they would not affect the visible formatting; but they would be available to other programs parsing wikipedia's data directly.

Motivation:-

- annotating a single language article with hints may be less work than manually translating into several languages, and thereby increase the worldwide audience more efficiently. - a human translator could do the work of annotating an article until it machine-translates well, rather than manually providing a translation.


This markup could be:-

- individual part-of-speech tags postfixed on individual words?

- hidden disambiguation: e.g. [color/]red would clarify that the specific instance is an adjective referring to colour (as opposed to political affiliation or blushing); such tags might be more useful than mere POS tagging?

- phrase nesting/boundary hints e.g. [NP]blah blah blah [/NP] for bracketing a 'noun-phrase' etc;

- or perhaps an invisible piece of punctuation that marks a hard phrase boundary (e.g. in situations where a : would make sense but be overkill, no verbal pause would be desired);


It could be used to improve the accuracy of:-

- machine translation (which should itself get better as more training data becomes available);

- automatic knowledge-graph generation for AI and other semantic processing;

- better quality text-to-speech for accessibility (a purely audio interface to wikipedia would be pretty awesome);

Perhaps text weighting or colour coding in the edit-previews could confirm that the hints have the desired effect.

They shouldn't need to be ubiquitous, since disambiguating part of the text should improve the statistical estimates of its' surroundings in automatic tools — Preceding unsigned comment added by 81.155.67.16 (talk) 05:23, 6 November 2015 (UTC)

Can you please explain again what you are proposing? --Kiyoshiendo (talk) 04:05, 6 November 2015 (UTC)
This looks to me like a proposal for semantic markup. I think it's a fair idea in principle, but I wonder whether it has traction; it'd need a lot of standards work, and careful piloting before implementation, to avoid wikichaos. Perhaps a revival of microdata. Stanning (talk) 16:19, 6 November 2015 (UTC)
Making Wikipedia pages easier for machines to read at the cost of being harder for humans to edit seems foolish to me. Relentlessly (talk) 16:34, 6 November 2015 (UTC)
Right. Not everybody is a coder, but close to 100% of users can read. --Kiyoshiendo (talk) 16:48, 6 November 2015 (UTC)
POS tagging is non-trivial. I have a number of books on the subject and have been thinking about it for forty years, and I don't have all the answers. (I'm not even convinced that "parts of speech" is a valid concept anymore.)
If it was trivial the client could do it.
If it was merely hard we could (if we thought it worthwhile) create a shadow POS tagged page for each page, which would be updated at save time.
However if it is a manual process (or manually verified/corrected - probably with a significant manual error rate) then it would require an enormous amount of work, some of which would need to be redone on almost every edit.
I am not completely agasint the idea, though. We do tag a number of things partly for machine benefit, notably text in other languages, direct quotes, and things that look like they need spelling corrections.
At some point proper NLP of article-space will need to be done. This is a project I was hoping to start on three and a half years ago, but there have been various obstacles.
All the best: Rich Farmbrough, 01:48, 7 November 2015 (UTC).

National albums/music charts

Proposal to rename, where appropriate, national music charts articles to territory and format rather than official name, so Swedish music charts rather than Sverigetopplistan, etc. Discussion at Wikipedia talk:WikiProject Record Charts#National Albums/Music Charts. SilkTork ✔Tea time 11:03, 8 November 2015 (UTC)

Highlight reference tags

Any chance we can have the option of highlighting reference tags and wikilinks in the text editor. Here is an example of what I mean (using Notepad++): http://i.imgur.com/AY3JBM0.jpg Firebrace (talk) 15:53, 10 November 2015 (UTC)

That looks really useful! I would second that. Try suggesting that at Meta:2015 Community Wishlist Survey. ~ ONUnicorn(Talk|Contribs)problem solving 16:23, 10 November 2015 (UTC)
The WikEd gadget does this. --Izno (talk) 21:10, 10 November 2015 (UTC)

BASC reform motion

An arbitration motion proposing a major overhaul of the current BASC system has been proposed. Comments are welcome at that location. Thank you. For the Arbitration Committee, L235 (t / c / ping in reply) 20:33, 11 November 2015 (UTC)

Discuss this at: Wikipedia:Arbitration/Requests/Motions#Community comments (BASC Reform)

Motion to disband BASC proposed

A second arbitration motion has been proposed which would disband the BASC. Comments from the community are welcome. For the Arbitration Committee, Callanecc (talk • contribs • logs) 01:53, 13 November 2015 (UTC)

Discuss this at: Wikipedia:Arbitration/Requests/Motions#Community comments (BASC disbanded)

Restored articles

When an administrator restores a deleted article, the restored article should be added to the page curation queue and clicking the "Show metadata for this page" button should say that the page was autopatrolled. GeoffreyT2000 (talk) 03:10, 14 November 2015 (UTC)

I think there are some problems in the Reading frame

According to Lewin's Genes XI, the reading frame should on the mRNA rather than on the DNA. the DNA needn't be divided into the triplets, because the molecule translated is the mRNA rather than DNA.And the enzyme just transcrips the DNA, not divide it. The dividing happens when the ribosome is reading the mRNA. --- パンツァー VI-II ❂Fu7ラジオ❂In the Republic of China 103rd.民國103年 14:28, 13 November 2015 (UTC)

File Upload Wizard: Replaceability by free media under Fair Use

It would be nice to have a field where the uploader can enter why the image/file being uploaded is not replaceable by free media. We have one for 'Minimal use' but the replaceability rationale requires another manual edit after the upload. Mandatory or not, it would be good to have this in the file upload wizard itself. Ciridae (talk) 16:44, 15 November 2015 (UTC)

Give the functionaries the ability to view private abuse filter entries

Moved to Wikipedia:Non-administrator Arbitrators RfC
 – Kharkiv07 (T) 16:56, 16 November 2015 (UTC)

Allow all Users to Close AfD and RfD Discussions - while letting Admins still do the actual deletions

There is no possibility the this will be enacted based on the comments below. -- GB fan 16:02, 17 November 2015 (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 there is a policy that a non-admin from closing selected discussions in circumstances where they don't have the tools to complete the followup action (delete an article or redirect mainly). While there is some logic to this, it puts admins on a higher platform then mere users who can't be trusted to assess consensus on a delete. However, the same mere users can assess consensus to keep or relist the same discussion.

I propose that the restrictions on non-admin closure be written out of the rules as unnecessary for the following reasons:

1. Currently, the tools are provided to everyone to close discussions including:

  • G6 XfD in Twinkle with a box to put a link for the deletion discussion
  • templates and detailed instructions for their use.
  • Detailed instructions [12] and [13]
  • Accessible lists of Current and Old AfD discussions [[14]]

2. Practicing closing discussions is good experience for future Admins where they can establish a track record. If they make a mistake that can be pointed out and they can learn it.

3. The part the future Admin can't do - the actual deletion - can and should be G6 xfd'd into the admin que with a link to the closed discussion. This function is already built into twinkle.

4. There is no chance of any damage because the actual deletion is still done by an Admin who can do a quick check to confirm the close is correct. Just like a speedy or a PROD an Admin has the final say.

5. Admins are in theory, accountable for their closes, and so are all other users already.

Legacypac (talk) 15:18, 16 November 2015 (UTC)

So the admin would have the full responsibility for reviewing the non-admin user's close to confirm that it is correct. That seems like redoing the work. --GRuban (talk) 16:03, 16 November 2015 (UTC)
  • @Legacypac: I think this is a perennial proposal that fails due to going against WP:NACD and WP:BADNAC, the most important contrast to this proposal on those pages stating that non-admins should not be closing discussion to which they do not have the technical ability to carry out. (The only exception I have found that contradict this is for WP:RM; the closing instructions there say, in one way or another, that non-admins can close discussions to "move" even if there is a page blocking the move, which requires a deletion.) Steel1943 (talk) 16:20, 16 November 2015 (UTC)
  • Support - we already do this with TfDs, although the process is a little different there. All an admin would have to do is determine if the close is appropriate per WP:NAC (a clear result, basically) and then either revert the close and relist the discussion, or carry out the deletion. Since NACs are only for clear results then there shouldn't be much extra admin load. NAC already advises non-admins to leave closing questionable discussions to the experience of an administrator, and non-admins who ignore that advice are frequently admonished for it, which is good because it's a learning experience for everyone. There's even a tag for requesting that non-admins don't close a discussion, but I can't remember what it is at the moment. This might actually lighten admin load by relieving admins from the time-sink of reviewing the bulk of deletion discussions which are clear results. This isn't allowing non-admins to delete, so it's actually pretty harmless. Ivanvector 🍁 (talk) 16:26, 16 November 2015 (UTC)
  • Support for AfD, Oppose for RfD. AfD requires time to assess consensus, saving admin time is good. RfDs should be simple. All the best: Rich Farmbrough, 16:36, 16 November 2015 (UTC).
  • oppose. I don't see any indication of the problem this is meant to solve. There is not a backlog or excessive workload that needs dealing with. And the current policy exists for very good reason. Not only the technical part, that an admin is needed to do the actual deletion, but the authority part, that an admin is an admin because their peers have judged them to be mature enough and have good enough judgement to handle such decisions. Changing it to let any editor close such discussions would just mean more discussions get poorly closed, end up being quickly re-run or appealed to deletion review, and rather than saving time more of everyone's time gets wasted. Absent an actual problem that needs solving this seems like a very bad idea,.--JohnBlackburnewordsdeeds 16:53, 16 November 2015 (UTC)
  • Oppose. See Wikipedia:Administrators' noticeboard/Incidents#User:Legacypac -- NAC closes as "delete" for some recent background. One of the insufficiently many things RFA usually gets right is assessing the candidate's understanding of deletion policy. The Big Bad Wolfowitz (aka Hullaballoo) (talk) 17:04, 16 November 2015 (UTC)
  • Oppose - "all users" is an invitation for socking. Also, admins are very well aware of WP:INVOLVED and its consequences. There are no such consequences for regular editors. --NeilN talk to me 17:12, 16 November 2015 (UTC)
  • Well, what are the consequences? In one case, misunderstanding-but-good-faith editor is administered the cluebat from more experienced users, they come out more knowledgeable (hopefully), and a small amount of cleanup is done. In the other case, disruptive editor is blocked, and a small amount of cleanup is done. It's not like we can take anyone's editor bit away for having occasionally poor judgement. Ivanvector 🍁 (talk) 19:41, 16 November 2015 (UTC)
  • @Ivanvector: Technically, there is a way to take away the "editor bit" called a "block". But, that aside, maybe a mention of a "up to being blocked" consequence can be listed there. I mean, one of the worst case scenarios would be a topic ban enforced by sanctions (not counting site banned), but now that I think of it, all of this is already outlined elsewhere. I just presently think the current way the information is set up for, let's say, an editor not familiar with Wikipedia performing their first or second edit ever as a NAC, makes it a bit difficult and maybe overwhelming for them. But, in the other hand, maybe WP:BADNAC is sufficient and maybe it should be discussed to be promoted to policy. Steel1943 (talk) 19:51, 16 November 2015 (UTC)
  • Oppose - If an admin disagreed with the discussion it would end up being reverted and thus creating more unneeded work for them, To be totally honest I think it's fine as it is. –Davey2010Talk 17:31, 16 November 2015 (UTC)
  • Comment I don't think this would save much admin time, because the admin would still have to assess the consensus before deleting. Admins would also still have to look through the open discussions, because other editors wouldn't always choose to do a close. However, provided that these closed-but-not-actioned discussions were properly flagged, one difference might be that in some cases the pages would be deleted sooner. This is either a good thing or not, depending on one's point of view. The total time spent by two assessors on one closure might be more. On the other hand, assessing discussions resulting in deletion that are then looked over by an admin is a safe way to gain experience for editors who later become admins, and might result in them participating more in closing discussions once they are admins. The point about socking above is a good one, although more often socks are trying to get pages kept rather than deleted. A compromise might be to allow pending changes reviewers do this. I'm not supporting this, just mentioning it as a possibility.—Anne Delong (talk) 17:33, 16 November 2015 (UTC)
  • Comment I actually see this as necessary at some point in the future, either along the lines of TFD or with some sort of unbundling of Delete from the admin toolkit. The current admin corps is not significantly increasing, and deletions are one area that is *and* requires manual admin interaction. At the moment AFD deletes require an admin to assess consensus and press the delete button - which can be a lengthy process. (It is also by no means a sure thing that admins themselves are better at assessing consensus, in many cases they are a lot worse.) If there was a template along the lines of TFD/Speedy that could be added - the admin burden would be 'check closure has been noted correctly, click delete'. If its contested, the usual process applies. Questions about incorrect judging of consensus etc can be dealt with by peer review regardless if the person judging consensus is an admin or a plain editor. Ideally the ability to delete pages would be unbundled from the admin toolkit and handed out to editors who have a proven track record of judging consensus discussions at AFD. Only in death does duty end (talk) 17:43, 16 November 2015 (UTC)
  • Oppose as usual. The question of whether someone's judgment is good enough to be trusted to close AfD discussions is a big part of RfA -- and a big reason for many unsuccessful bids. AfD closure is just so often fraught and subject to dispute. Ideally, there would be no need for non-admin AfD closes, but we allow them for obvious keeps (and certain other instances where the need for nuanced judgment is minimal) because the load on admins is just too high. It's a sensible way to distribute the work (and I'm glad other ways to do so are being discussed within the RfA reform threads). Gray area is the biggest issue, but before getting to that there's also the matter of obvious delete closes (i.e. unanimity with good participation). The only practical benefit an NAC has in an obvious close is to save an admin the trouble of closing it -- and that's pretty minimal since an admin still has to review it before speedy deleting (and we know that sort of review doesn't always happen like it's supposed to -- and why would it? for an admin to properly evaluate a close saves hardly any time relative to what it takes to close in the first place). But the big gray area in between obvious keep/deletes is the big issue, and because it's gray, and because it's admins we entrust with the judgment to make tough calls, that gray area needs to be treated as vast. The simple fact is it's not sensible to say that two people can exercise the same form of judgment when one party is only allowed to act in one of the two available ways. It discounts things like time investment -- where, once one decides to act and becomes invested in a closure, it's not reasonable to think they'll be able to modify their judgment along the same spectra as someone who has every option available. — Rhododendrites talk \\ 17:59, 16 November 2015 (UTC)
  • DOA oppose As in dead on arrival. We keep seeing these half-baked proposals to give non-admins "moar powah" that would still require admins to be responsible for the result. This is why we have admins in the first place. They have been vetted by the community and found to have the skills and judgement necessary to assess these situations. No responsible admin would do this unless they were also satisfied that the consensus favored deletion, so this doesn't help anyone do anything, it would just be a pointless extra layer that would inevitably lead to drama when admins adisagrree with the closing user's findings. Beeblebrox (talk) 18:31, 16 November 2015 (UTC)
  • Oppose as this is taking no burden off the admin who (eventually) deletes the article. Kharkiv07 (T) 19:13, 16 November 2015 (UTC)
  • Oppose per Anne Delong. There is no time saving for admins because the AFD would still require thorough review in order to determine the validity of the close. And we shouldn't be looking to "save time" in deletion discussions, we should be looking to get them right. -- Euryalus (talk) 19:16, 16 November 2015 (UTC)
  • Oppose - At best, you've changed nothing as a deleting admin would still have to review to ensure consensus was reached. At worst, someone without the proper tools closing AFDs as delete would dramatically increase the odds of such articles falling through the cracks. Resolute 19:49, 16 November 2015 (UTC)
  • Oppose This would end up actually increasing the admin backlog since they would have to review the discussion anyway and determine if the close was correct and if incorrect, overturn it (with a rationale, etc). TFD is a special case where allowing NADCs effectively reduces the admin backlog since then, non-admins can take up the time-consuming task of removing the transclusions. Cenarium (talk) 20:02, 16 November 2015 (UTC)
  • Comment It is not going to work for all users, but as an unbundling tool and with a usual NAC clausure (if someone gets unhappy, they may ask for an admin reassessment) it might actually work. Here, we do not need a technical tool, just a gadget marking the user as a "AfD closer" or smth.--Ymblanter (talk) 06:33, 17 November 2015 (UTC)
  • Oppose as admins would have to delete as well as check the close. People that would like to close these sort of discussion should stand at RFA. Graeme Bartlett (talk) 07:52, 17 November 2015 (UTC)
  • Pile-on oppose per basically the last couple times it's been suggested. ansh666 10:36, 17 November 2015 (UTC)
  • Support in principle, oppose in actual practice. I agree with the sentiment; there is no inherent reason why any editor-in-good-standing would be incapable of assessing consensus on any discussion they were not part of. However, this has no practical effect, because there are only two outcomes, both of which make the action irrelevant.
1) Any admins who follow up would agree with the decision the non-admin made: If this is the case, the admins would have closed the discussion the same way, and the closure doesn't save any work; now two people have spent time doing an action it only needed one to do. Pointless.
2) Any admins who follow up would disagree with the decision the non-admin made: So either they don't enact the decision, which is a problem, or they override the decision, either generating unneeded drama or simply making the non-admin's action irrelevant.
In summation, I agree that we should not strictly forbid non-admins from any action that does not need the admin tools to make happen. In practice, we should also not simply make work to make work, or create a situation where processes become more complex just for the sake of complexity. So, the sentiment is entirely correct. This proposal doesn't work, however. --Jayron32 15:44, 17 November 2015 (UTC)
  • Oppose No admin should ever use their tools based on another person's interpretation of consensus. An admin would have to check the AfD so thoroughly they might as well just close it. HighInBC 15:47, 17 November 2015 (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.

Should the default Math appearance preference be changed from PNG to MathML?

Hi I just wanted to post a like here to my RFC: Should the default Math appearance preference be changed from PNG to MathML? Hungryce (talk) 20:25, 17 November 2015 (UTC)

Category:User en-0

This is basically a proposal to overturn Wikipedia:Categories_for_discussion/User/Archive/September_2007#September_23, which deleted Category:User en-0; it's here, rather than at WP:DR, because the purpose of DR for a deleted page is to say that the deletion was wrong, not merely to say that I think I have found a good reason to have the deleted page back. For those of you who don't know, the babel templates transclude a category for users by their language ability; for example, Category:User en-1 is filled with users who speak limited English but more than nothing. Before this category was deleted, it was filled with userpages of people who didn't speak English, many of whom were active at other Wikipedias but not here. Comparable pages exist in some other wikis; for example, my French userpage is in fr:Catégorie:Utilisateur fr-0.

At the deletion discussion, the primary reason for deletion was that nobody needed to categorise users by a language that they don't speak, and anyway you could truthfully fill your userpage with categories for languages that you don't speak. However, I propose that en-0 be treated differently: not for the sake of humans leaving notices or seeking collaboration, but for the sake of bots and automated scripts. Quite often, we see bots and scripts leaving big notices on various grounds, and for users who don't speak English, these notices are hard to understand at best; even with machine translation, it would be difficult to understand many notices. If we had a Category:User en-0, bots and scripts could be reprogrammed to look for such a category on a userpage or user's talk page, and when finding it, they could leave a significantly simpler message. This is the first use that comes to mind, although I suppose that there are other automated uses that aren't coming to mind.

Nyttend (talk) 14:33, 13 November 2015 (UTC)

  • I've always seen that as being a case of something verifiably being the case now and not previously. For example, "Jo-Jo Eumerus is a youth football player" gets deleted in 2007, and then I file a DR request in 2015 because "Jo-Jo Eumerus just yesterday played his first professional match with Chelsea F.C." — the situation is completely different now, so we might as well undelete. I came here because it's a newly-suggested reason for the category, but someone could have suggested that reason before, while a suggestion that you're a professional footballer would have been obviously wrong eight years ago. Nyttend (talk) 15:14, 13 November 2015 (UTC)
Bots and automated scripts can look for transclusions of {{User en-0}} just as easily as for Category:User en-0. And while I can certainly understand the need for a userbox indicating that a specific user doesn't speak English, I see no reason tyo associate these users with each other by means of a category. עוד מישהו Od Mishehu 22:15, 15 November 2015 (UTC)
They would also have to look for {{#babel:xx|en-0}} and other ways of doing the same thing. WhatamIdoing (talk) 22:55, 20 November 2015 (UTC)

No objection to recreation - this was not a purpose for the category that occurred to anyone at the time of last CfD. WJBscribe (talk) 23:56, 15 November 2015 (UTC)

Future of Wikipedia

I would like to offer a vision for one aspect of Wikipedia’s future - a way I believe could improve both relevance and interest in our favorite site, as well as some steps that could help us get there. I hope you find it useful. Please share your feedback and ideas. Thanks! --Yurik (talk) 20:03, 26 November 2015 (UTC)

Proposed: Tag / edit filter for talk page abuse

Proposal

Create a special tag / edit filter designed to catch talk page abuse. (Example: [15])

Envisaged benefits
  1. An edit filter could warn users before posting that their comment may need to be refactored to be considered appropriate.
  2. Editors could check recent changes for tagged edits, bringing much-needed third eyes to talk pages where an editor may be facing sexual harassment and other types of abuse.
  3. Prevention of talk page escalation.
  4. Improvement of talk page culture.
  5. Enhanced editor retention. Andreas JN466 15:51, 29 October 2015 (UTC)
Following discussion below, I would support a system that would ask the user for confirmation if an edit contains likely personal attacks. Due to possible moral hazards, any stronger action, including tagging, should only be enabled in a target-specific way as a discretionary sanction at WP:AE or following existing practice from WP:LONG. Rhoark (talk) 15:37, 30 October 2015 (UTC)
  • Partial support Have to agree on Rhoark's point, particularly in the situation that as a uncensored work that in the course of productive discussion about certain topics, it may be necessary to use language that would easily trigger such a filter. Once also has to consider that what actually might be taken as harassing language by one editor will not be the same that others would consider harassing, and context can be everything. To make everyone happy, we'd have to include a lot of possible hits, and the more we'd have to include the more false positives we'd get. So a full site wide use of a filter would not really work. That said, I would support a filter that could be applied to editors that have been established through AN/AE that they may use language that borders on the uncomfortable that they should be warned if they veer into that again. Or to use on certain talk pages that have already been identified as a hot bed for near-personal attacks to warn users before posting in anger/haste. We'll still get false positives but they will be much more limited and would be much more manageable by admins. --MASEM (t) 20:09, 29 October 2015 (UTC)
This tool is apparently used to deal with cases of long-term abuse, and it might not be a bad idea to expand its use as a targeted discretionary sanction. Rhoark (talk) 20:16, 29 October 2015 (UTC)
I would say there is no shortage of admins and other editors who are willing to pick up on sanction violations without the need for filters or tags. -- zzuuzz (talk) 20:26, 29 October 2015 (UTC)
Many cases seem to call for a response stronger than a warning but less extreme than a topic ban. Nuanced sanctions however have proven to be an invitation for baiting the sanctioned editor and playing gotcha. An automatic referee could help in this. Even if not automatically enforced, a code-level specification of the restriction could lower the volume. Rhoark (talk) 20:55, 29 October 2015 (UTC)
Not knowing the technical way this can be done, an ideal use would be where if an editor makes an edit that triggers this filter, that instead of immediately applying the new edit, to provide a warning screen "Hey, this page is prone to issues with such language, please consider rewording your edit, or proceed if you take full responsibility for the language and may be subject to administrative actions if deemed inappropriate." If the editor proceeds, that then would tag the admin flag , if needed. As long as that is used on sets of talk pages aggressively prone to personal attacks and harassing-type language, that should hopefully make editors think twice before posting, cutting down the amount of work admins have to do. But I am not sure if an edit filter can trigger a secondary edit submission check. --MASEM (t) 21:05, 29 October 2015 (UTC)
I'm fairly certain it can. For example, if you put a sanctions notification on someone's talkpage, you'll be prompted to make sure its not a duplicate. I think that's done with this system. Rhoark (talk) 21:52, 29 October 2015 (UTC)
It can indeed; see 2. below (which is copied from Wikipedia:Edit_filter). And the first step might well be to pilot such a system on known problem pages. Andreas JN466 05:37, 30 October 2015 (UTC)
Even with a limited scope pilot I would still only recommend this (using #2 below) on pages known to be hotbeds as to be approved by community consensus, which is probably less than 1% of WP's total page count. The only exception: User talk pages should universally have this, as I cannot imagine a need where such language needs to be used on a user page, ever. It's still just an extra edit step/tag, so it doesn't prevent posting and allows legit cases, but hope makes editors think twice before sending off a nasty message. --MASEM (t) 23:07, 30 October 2015 (UTC)
  • Support, though it should not be preventing any edits, just tagging. The potential for false positives is high. GorillaWarfare (talk) 21:18, 29 October 2015 (UTC)
    • Available edit filter options are:
      • When an edit being saved "triggers" an active filter, the effect depends on a setting associated with that particular filter:
        1. Under the strongest setting, the edit is rejected, and the user sees a message to that effect. (A link is provided for reporting false positives.) It is also possible to have a user's autoconfirmed status revoked if a user trips the filter.
        2. Under a less severe setting, the user is warned via a customisable message that the edit may be problematic. The user then has the option to either proceed with the save or abandon the edit.
        3. Under an even lower setting, the edit is tagged for review by patrollers.
        4. Under the lowest setting the edit is merely added to a log. (This setting is also used in tests of new filters.)
    • I think we would be shooting for 2, i.e. merely a reminder to think about the edit before clicking Save. ClueBot is very smart these days; over time, this filter could become similarly smart, recognise verbal abuse, sexual harassment (there should rarely be a need for someone to say something like "you turn me on", per the example linked above), etc. The tag would simply help getting more eyes on talk page conversations that may have taken a problematic turn. Andreas JN466 22:47, 29 October 2015 (UTC)
After an extensive period of training and refining a filter, it might not be harmful to enable it site-wide at an advisory level only. I'm pretty sure it wouldn't have made a difference to Qworty though. Rhoark (talk) 00:56, 30 October 2015 (UTC)
The difference is that edits like that, happening in some backwater of Wikipedia, would have been flagged, and attracted other editors' attention much sooner. Andreas JN466 01:18, 30 October 2015 (UTC)
  • Comment What exactly is 'talk page abuse'? The edit filter is very literal and can't be told to just look for 'abuse'; if you can provide some examples of text strings which in the vast majority of cases imply abusive behaviour, which aren't already caught by an existing filter, then that would be more useful. Sam Walton (talk) 22:42, 29 October 2015 (UTC)
    • It would require an effort similar to the one that went into ClueBot and its descendants like ClueBot NG, and a lot of brainstorming. Women editors I am sure could provide examples of sexual harassment, belittlement or other gender-tinged exchanges they found offensive and wouldn't want to encounter again. Off the top of my head, words/strings like "rape you" or "stupid whore" are unlikely to have many bona fide uses. Similarly, "fuckwit", "fuckwad", "you fucking cunt", "you asshole", "fuck you", "you dumbass" etc. are most likely to be used as terms of abuse indicating (or indeed initiating) a breakdown in communication that would benefit from an uninvolved editor having a look at what's going on. Generally speaking, an edit filter warning asking people to think twice about posting these strings would in many cases prevent escalation and reduce admins' and oversighters' workload. At any rate, the strings to be caught should be based on actual user experience of the kinds of exchanges that tend to make talk page discussions go south and contribute to an off-putting atmosphere. I am under no illusion as to the amount of work this would require. But similar work has been done to cut down on article vandalism, with outstanding results, and improving the working climate would to my mind justify another such effort. Andreas JN466 05:24, 30 October 2015 (UTC)
    • Note: The above post of mine was not tagged in Recent changes, despite its abundance of strings that would be clearly problematic if used in an actual talk page discussion. Andreas JN466 05:26, 30 October 2015 (UTC)
  • strongly oppose until and unless someone can define "talk page abuse" in a fairly specific way, and can at least outline an algorithm that could identify such abuse with pretty near zero false positives. I don't believe that it can be done at the current state of the art, even by a major AI effort, much less the resources available to a Wikipedia edit filter. Remember that it must permit detailed discussion of the content of sexually explicit articles, and so cannot simply block a list of words that are "profane" or "offensive". Any such filter must be able to correctly detect the context that makes a remark "abusive". I don't think this is possible, and anythign less ins IMO unacceptable. DES (talk) 01:27, 30 October 2015 (UTC)
    • Exceptions could be defined (talk pages of specific articles, etc.). I suspect ClueBot has similar capabilities today, and similar exceptions have been defined for pictures of gore etc. that have in the past been used for vandalism. Also bear in mind that no posts would be blocked; you'd still be able to post "You're a fucking fuckwit". This would merely remind people to consider potentially abusive posts carefully before clicking Save a second time, and present a tag in Recent changes enabling patrollers to have a look at what is going on. Or you could have the Recent changes tag only. Does this still sound unacceptable to you? Andreas JN466 01:59, 30 October 2015 (UTC)
      • Note quite so much, but I would still want to see a clear and specific definition of what is to be considered "abuse", and a detailed technical plan for the filter before I would support this. DES (talk) 03:12, 30 October 2015 (UTC)
  • Oppose. In principle, this isn't a bad idea. In practice, I don't trust the subset of the community that will appoint themselves civility-tag first responders and go digging through potentially uncivil edits looking for people to wag their fingers at. I think you're creating a technical mechanism to reward superficially civil goading and baiting and punish the frustrated recipient of it. If you want to design an opt-in tool that will flag potentially problematic edits on your own talk page, great. Opabinia regalis (talk) 06:11, 30 October 2015 (UTC)
    • This does not apply to the edit filter idea, which would merely challenge contributors to express their disagreement more skilfully (or perhaps invoke a process like WP:3O in preference over getting into a slanging match – an approach the edit filter message could suggest), but it's a potentially valid concern with the tag idea. One would have to do a pilot to see whether the upsides outweigh the downsides. Andreas JN466 13:55, 30 October 2015 (UTC)
      • This seems to be a little confused about the technical side (or else I'm the one who's confused). You've mentioned ClueBot a few times in this thread, but an edit filter is just static regex; it doesn't get any smarter unless a human makes it smarter. Both of the ideas in the paragraph above, if I understand you correctly, are actually "edit filter ideas", implemented using edit filters; it's just that one warns and the other tags. But if the filter is public, then even without tags there will still be a log of the warnings for self-appointed wikicops to inspect.
        If you wanted to run a pilot, how would you analyze the data to determine whether it's a net benefit? Opabinia regalis (talk) 00:17, 31 October 2015 (UTC)
  • Comment. Firstly thanks to Andreas for the proposal. I believe that it is important that we think outside the box for these things. At this stage, I do not have an outright support or oppose, as there are a few questions which I feel might bear thought. 1) What would be the proposed process or procedure for changes to the filter - if regexp based, how would patterns be added & removed; what level of support for addition/removal would be required? (Note with the spamfilter addition seems significantly easier than removal) 2) Given that (as I understand), we already have a filter for obscene terms, what would be the difference; both in patterns matched & in proposed effect? (Does the obscenity filter currently block edits?) 3) As we have seen a tendency for other filtering tools, like the spamfilter, to be used, for reasons of operational expediency, outside the originally intended use - e.g. to implement failed proposed WP:BADSITES and to control/limit sourcing options. What controls would be in place to ensure that the filter is used only for the intended purpose? 4) Given a community problem with WP:TAGTEAM & offsite WP:CANVASSing, what controls would be in place to prevent the edit tagging being used to gang up on editors whose edits have been tagged, but who may not be genuinely abusive? Many thanks for your thoughts in reply. - Ryk72 'c.s.n.s.' 06:42, 30 October 2015 (UTC)
    • 1. ClueBot has a mechanism for reporting false positives. The same approach could be used here. 2. I posted a number of sample obscenities above. The edit was not tagged. I invite you to post a similar message yourself, as though in response to me. Then check whether your edit is flagged in Recent changes. 3. Ongoing community scrutiny, with changes as dictated by community consensus. 4. (a) Iterative optimisation of the edit tag settings to weed out false positives. (b) Self-control on the part of those posting; the edit filter message would give a warning that an edit will be tagged, so it's possible to avoid being tagged. (c) If problems like ganging up occur in spite of this, contributors would have the same sorts of debates about what is incivility that they have now, but perhaps less frequently. It might establish a better baseline for communication among regulars, in addition to giving newbies some protection from the worst kinds of assaults. Andreas JN466 14:14, 30 October 2015 (UTC)
  • Support as I always support rainbow farting unicorn creations. Even if only tagging, how does an editor go about removing the "false positive" tag that would undoubtedly be a built-in machine driven personal attack? What would the tag say? "possible misogynist?" "transphobe" "rape culture support" "safe-space violation?" --DHeyward (talk) 22:18, 30 October 2015 (UTC)
  • Support in a limited way; should tag only, because the actual judgment for what might need to be removed, or about which other action taken, does need to be made in context by people. And also limit to the most obvious ones that would be so considered by almost everyone, in order to decrease the number that need to be examined. If the usefulness is proven, and the number remains manageable, the list could be expanded. I think the various objections above could be dealt with by using restraint. DGG ( talk ) 22:54, 30 October 2015 (UTC)
  • Question on technical aspect - Assuming we go with #2, I am assuming that if the user does go on to post that the edit will still be tagged. Is there a process/script that tracks how many such edits a single editor has that get tagged that way? (Here's I'm thinking that if a single editor racks up, say, 10 such tagged messages in about an hour, something's probably happening to evaluate that user's behavior, and that should go to some admin-reviewed logo to determine if a temporary block is necessary or if there's legit use there.) I am only speaking of the case where the editor does go through with posting: an editor that gets the warning and decides not to post is not tracked (eg immediate forgiveness). Which leads to another question which I'm pretty sure I know the answer but want to check: if I edit and get this warning and then alter my edit from that resulting page to avoid the language, I assume that the new edit is rechecked fresh and the resulting edit is not tagged? --MASEM (t) 23:17, 30 October 2015 (UTC)
    • Indeed, that is how it should work. The proof of the pudding would be to draft an edit designed to trigger an edit filter of type 2 (is there a list somewhere?), modify it so the new version would not fall foul of the edit, save it, and then check Recent changes for presence or absence of a tag. At any rate, I would be very surprised if edits that have been fixed before saving still trigger the tag under the current edit filter settings. Andreas JN466 06:27, 1 November 2015 (UTC)
  • Stupid idea This will only serve as an annoyance akin to getting an edit conflict, yet with no net benefit. And who gets to control the filter? Just another power grab. Color me shocked that this literally retarded proposal has received support from those who have screwed the pooch with with the blacklist filter. User:100.8.121.118 Talk signature added
  • Oppose. This isn't a big problem here worth the time and effort. If a problem arises, it's taken care of on an individual basis. GenQuest "Talk to Me" 07:04, 31 October 2015 (UTC)
  • Oppose. This is a good idea with too many problems. If a user wants to harass someone with talk page abuse, they will always find a characteristic of the user to attack. If someone has black skin, they may be called a n_gger; if someone has red hair, they may be called a g_nger; if someone is female, they may be called a c_nt. If a user is associated with a minority or otherwise generally disliked group, they would be harassed for that. Any targeted harassment is unacceptable, not only "sexual harassment". The real problem lies in the impracticality of implementing such a filter. Whether something can be taken as harassment depends on the harasser, the harassed, and words used for harassment. This would trigger excessive false-positives, possibly even creating so much inconvenience that editors feel annoyed (so much for editor retention). This edit filter may also unintentionally prevent normal discussion on talk pages of WP:NOTCENSORED articles (for example, articles in the scope of WP:FOS, WP:SEX, WP:NETPOP, etc.), causing further annoyance. In short, the use of an edit filter will result in too many inconveniences to be worthwhile. sst✈discuss 15:44, 31 October 2015 (UTC)
  • Although ClueBot is sophisticated in combating vandalism, to succeed in automatically combating talk page abuse (while preventing false positives and other issues pointed out by opposers) would require something far more than a tag/edit filter, which basically only search for words. While some words may be deemed to be unacceptable in some discussions, they may be totally normal in other discussions, and tags or edit filters are unable to distinguish whether these words are appropriately used. We must remember that the English Wikipedia is not a melting pot; we have people with vastly different cultures, and we even use different English dialects on different pages. This is an excellent idea, but impractical with tags and edit filters. sst✈discuss 16:05, 31 October 2015 (UTC)
  • Oppose This NagBot™ unless and until programming becomes much more sophisticated. This looks like it would have a huge potential to produce false positives and just annoy people. Simply searching for words is a far too simplistic approach, and if someone is acting up ona talk page a human admin should be the one to intervene. I can't imagine a scenario where one user would call another a stupid whore or threaten to rape them that would not result in an immediate block. Better to let them make such an edit and show their true colors so they can be blocked for it than to suppress it ahead of time. Beeblebrox (talk) 20:11, 31 October 2015 (UTC)
    • Many such edits are not noticed by any third party at the time they occur. If an admin blocks two days later, or another editor removes the offensive message from the talk page some weeks down the line, the damage is already done. Andreas JN466 06:13, 1 November 2015 (UTC)
If you have any evidence that there is recurrent problem with rape threats and users being called whores wiere there is no rapid administrative response, I suggest you show said evidence to the rest of us, because that would be very compelling for your case. I am sure any responsible admin would be horrified if you were actually able to back up such a statement. You just saying it happens, not so much. Beeblebrox (talk) 22:42, 1 November 2015 (UTC)
What is "rapid"? You're probably right that the vast majority of messages of this type are deleted, revdelled or oversighted within a day or two, but a tag would help admins arrive on the scene quicker, and without the victim first having to summon administrative assistance. That would send a better message to the editor being abused. Similarly, an edit filter might help reduce frequency of occurrence.
I gave an example of a problematic talk page interaction above, never spotted and acted on at the time. Recalling the Wifione arbitration case, one of the violent threats Makrandjoshi received is still on his talk page today: [17] There was no message of support or concern on Makrandjoshi's talk page until a couple of days later. Makrandjoshi raised the matter at ANI; a newbie would not have known how to do that. As for outright rape threats in the data base, a quick search finds: [18] from 2009 (editor blocked two days later), [19] from 2012 (perhaps just a juvenile test edit) and [20] from 2013 (in response to a warning left by a sysop). [21] may have been a test edit; if so, the test proved that it is possible to call another editor a nigger without anyone coming to intervene. [22] from 2010. "Boo you, whore", on the talk page of an IP that has made both content and vandalism edits, present since 2012: [23]. Editor asking for help after being called a whore: [24]. Janejellyroll was repeatedly abused, called a "stupid whore", "big bitch" etc. on her talk page; she stopped editing a few months later, after 8607 edits. [25] When school kids post similar vandalism in mainspace, it is quickly dealt with. All I'm saying is – given that the hostile editing climate is often cited as a reason for both the gender gap and poor editor retention, why not explore whether Wikipedia could be more proactive about talk page interactions, instead of putting the onus on victims to come forward and point this stuff out to an admin? Andreas JN466 06:19, 2 November 2015 (UTC)
User:Beeblebrox, compared to, say, adding unsourced text, the problem is less common. That doesn't mean that it's unimportant. Also, I'm surprised to hear you argue in favor of people getting hurt, just so it's easier to justify blocking problematic users. "Give them enough rope" is only appropriate if that rope isn't being used to harm other people. "Give them enough rope" is a good model for people with different ideas. It's not a good model for people who are verbally abusing others.
And just in case it's not obvious, merely reading the message is harmful to its target. Transforming an editor from someone who is happy to edit Wikipedia into someone who knows that another person wants him or her to be raped, maimed, or murdered is actually harmful to that editor. Blocking the person who wrote the message doesn't erase your memory of that event or change the fact that the message existed. As Jayen says, by the time that happens, the damage to the targeted victim is already done. WhatamIdoing (talk) 19:52, 2 November 2015 (UTC)

Replying first to to Andreas' examples: The example in the proposal itself is weak. Like, really weak. What, eactly, in that specific remark would a bot be clued into? And I think you can see for yourself that the rest of your examples are few and far between, some going back eight or nine years. This to me is not idicative of a widespread problem that something as sweeping as a filter on every single talk page edit would solve.

To Whatamidoing's comments: Let's look at the potential ways this could play out:

  • With the edit filter warning them not to do it: User writes up extremely nasty edit, hits "save". Edit filter stops the edit and warns the user that they were about to do something nasty. Horrible creep about to make a rape threat gets a chance to reconsider the consequnces, continues to be a more low-level creep on WP, now knowing that if he goes ovewr the line a bot will help him keep it in check. But nobody had to suffer through reading through the awful things he fully intended to say.
  • Without the edit filter: horrible creep makes horrible threat. Threat is removed, user is blocked indefinitely with talk page revoked, user who was subject of attack sees that while there will always be horrible people who say horrible things, these things are not tolerated here and persons who dothings that are that levelof awful don't get to continue being here.
  • Regarding the "harm" of even reading such things: You are only harmed if you let that person harm you. These are just words, not actions. Horrible words, and i wish there was some way we could just keep the sort of person who would make a rape threat or call another user racist or sexist things from even editing here, but we can't. Better to catch them and make an example, and at the same time show support to the target of the attack.
I actually have my own personal troll who comes to my talk page periodically and calls me a prostitute, suggests that I have sex with animals, and that my life is and endless pit of suffering and crying. Since I know none of this is true, and it has almost always been removed by somone else and the troll blocked again before I even see it, it doesn't harm me at all. In fact it makes me laugh because this pathetic loser actually thinks their nonsense could harm me. Perhaps others feel more harm from mere words with no basis in reality than I do, but really, these are just words. Letting them go ahead and be written, so we know what kind of horrible person we are dealing with and can remove them immediately, seems the best approach.
That being said, if you could write a bot intelligent enough that it was not just keying on words (because I don't see any words in the example given in the proposal that in and of themselves are a problem at all, it's the way they are put together and the tone that is the apparent problem) but could actually determine, with a high degree of accuracy the exact meaning and intent of a particular post, and that could therefore stop only the worst of the worst type of tp edits from being made, alert admins to the situation in some urgent way (not just an edit filter log) I would of course be in favor of that. As I've said, I do not believe we are at the point where a bot that sophistacted exists. Let us know when it does,. Beeblebrox (talk) 20:19, 2 November 2015 (UTC)
Yelling "Fire!" in a crowded place is "just words", and you can go to jail for it. Saying "I plan to bomb _____" is "just words", and you can go to jail for it. Actually, calling someone on the telephone and saying "I'm going to come to your house and rape you" is "just words", and you can go to jail for it. Are we putting these people into jail for no reason? Or is it possible that some kinds of words are not "just" words? WhatamIdoing (talk) 23:03, 2 November 2015 (UTC)
Right, so in those examples there is human being making that evaluation, assessing the context, etc, not just a robot that says "you are about to say the forbidden words". The inability of a bot to make such sophisticated distinctions is the basis of my opposition. Beeblebrox (talk) 20:24, 3 November 2015 (UTC)
This is why above in my partial support, I suggest that this should be limited to pages that the community has decided that have enough talk page problems to merit a "cool down" warning page. That choice to use the filter on those pages is the addition of a human element to decide when a page really needs it. And as long as we are using the #2 level (a warning but not preventing posting), and that determining if excessive hits on that filter is a cause for other admin action is based on human evaluation, it's a reasonable step; it will never be perfect but using it in exceptionally limited situations may help to defuse some talk page problems. --MASEM (t) 21:38, 3 November 2015 (UTC)
If you wish to continue using that analogy, let me suggest you consider the context of the original use; not exactly "The Judiciary's greatest hits." 97.93.100.146 (talk) 21:42, 24 November 2015 (UTC)
Beeblebrox, I think the boiling frog parable applies here. If you had been asked ten or twenty years ago whether you would want to work, voluntarily and without pay, in an environment where people regularly call you all the things you mention above, I think you would have said "no way". But you get used to it, accept it as part and parcel of doing this kind of work on the internet, and eventually learn to shrug it off. If you are male, then perhaps you even enjoy the challenge a bit, along with the sense that you have actually won the exchange, and the troll's posts are nothing but a sign of impotence. This is not something women contributors are likely to enjoy in the same manner; the male half of humanity thrives on conflict and competition in a way women, as a whole, do not. At any rate, by that time you have trained your responses to be quite different from those of a newbie. I recall one woman contributor telling me that the sort of abuse she has encountered in Wikipedia goes beyond anything she has ever encountered anywhere else, online or offline (including working environments that were even more male-dominated than Wikipedia). It is not an inviting environment for serious contributors interested in the project's vision.
As for examples being few and far between, you have to remember that most problematic posts are revision-deleted or oversighted. As an ordinary editor, I can only point you to examples that are still extant and visible by anyone. It is a very small tip of the iceberg.
As for the ability to program something sophisticated enough to tell real abuse from quotations etc., I am regularly amazed by how clever ClueBot has become at telling genuine edits and vandalism apart. The difficulty of making such determinations applies in mainspace just as much as it does on talk pages, because offensive words have many legitimate uses in mainspace, too.
I'd be interested in feedback from people like User:Cobi or User:Rich Smith as to feasibility. If it is feasible, then this is something I would like to see the Foundation investing in; in time, an open-source solution could even benefit other sites struggling with similar problems, allowing Wikimedia to take a leadership position on the web. It would be no mean achievement. Andreas JN466 20:44, 8 November 2015 (UTC)
I am aware that I have a somewhat thicker skin, not just because of my Wikipedia experience bu also because of working in the service industry for 25 years. You get used to bitter, unreasonable, possibly drunk persons making unwarranted attacks on you that say more about them than they do about you. So I could support this if I thought it was actually good enough to detect the context of a remark and effectively get admin attention. I have also marveled at ClueBot's abilities, but I have to disagree that even it is advanced anough to accurately parse talk page comments and detect only those that absolutely should not be posted. If we are going to talk about "prior restraint" of people's speech, I believe we must be very, very sure that it would produce almost no false positives. I am just not convinced this is currently possible. I would suggest that extensive testing would be a must before loosing such a bot on millions and millions of talk pages. Beeblebrox (talk) 21:02, 8 November 2015 (UTC)
  • Support. If we can take steps to protect our articles, we can take steps to protect our volunteers. Humans need to be involved in reviewing the initial results. It will take some experimentation to see what works. Most likely, ongoing adjustments will be needed as vandals attempt to foil the system. Bringing in some expertise on A-B testing could be useful. --Djembayz (talk) 21:59, 1 November 2015 (UTC)
  • Oppose While I fully support the thought behind it, getting a “you might be about to act like a jerk” warning will empower the jerks to be more sneaky. The jerks could just edit their word usage to make the abuse harder to find. The abuse would still be just as hurtful to the people targeted by their aggression. What if a bot looked for instances of abuse and compiled a list somewhere? People could then delete false positives from the list before attempting to using it for some purpose.Abel (talk) 00:37, 2 November 2015 (UTC)
    • A snide remark may be very annoying, but I suspect most people would prefer not to receive violent threats, or outright abuse. Andreas JN466 06:19, 2 November 2015 (UTC)
      • Which is my point. This would not stop violent threats, or outright abuse. It would empower the people using violent threats and outright abuse to craft their violent threats and outright abuse in ways that would be harder to find, yet would be no less effective at harming people. The idea behind it is very worthwhile, I am suggesting a different tactic for the same strategy. Abel (talk) 14:29, 2 November 2015 (UTC)
        • I think that an automated warning would stop some violent threats and abuse. Not all, but some. And I think that stopping (or softening) even a small fraction of those comments would be a valuable step that we should take. I'm also open to other tactics, and would be happy to hear more about your ideas. WhatamIdoing (talk) 19:52, 2 November 2015 (UTC)
          • I agree it would stop some and slow a few. I am concerned about the unintended consequence of how it would also help train the worst jerks in ways to be even more sneaky. If a bot looked for instances of abuse and compiled a list, then people could delete false positives from the list before attempting to using it for some disciplinary purpose. Think about how someone who wants to be a jerk could use this. Type type and get a warning. They edit until they no longer get a warning. Now they know how to abuse people in ways that will likely result in zero consequences. Not at all the goal we want. Abel (talk) 23:31, 2 November 2015 (UTC)
    • Point well taken, that warning won't stop people determined on being nasty, or eliminate arguments and bad feeling. It might help some people keep their tempers, though, and avoid saying something they regret. Getting a workable balance between tagging and warning, and coming up with appropriate messages, will probably take experimentation. Humor could either lighten things up, or make it worse, till you figure out how to apply it. Maybe stern and serious works better for some things. One objective here is that by keeping unwanted sexualized or violent language out of the mix, or at least reducing it, you prevent arguments from turning into something creepy or scary. Being upset over an argument can be expected sometimes. Being intimidated or frightened because comments start taking a sexual or violent tone isn't necessary. Even heated arguments and discussions don't have to be creepy or threatening. And of course, high levels of verbal abuse don't help with editor retention. --Djembayz (talk) 09:15, 2 November 2015 (UTC)
  • Also-- As the number of pages keeps increasing, there's a need to either automate patrolling or put more people on the task. Although some text strings will show up in automated results that are clearly abusive and unreasonable, there is no "automatic block" that can solve for all abuse, and many things will still need manual review. --Djembayz (talk) 09:51, 2 November 2015 (UTC)
  • Support tagging and warning, but not using an edit filter to prevent the edits. I like the deterrent advantage of warnings ("Am I too drunk to be posting?") and the tag: ("Hmm, this thing's going to get tagged. Some admin or oversighter might be checking the tags right now. I don't know if he's even going to read this before it gets rev-del'd and I get blocked.") An ideal system might have two tags: edits that tripped the filter and were cleaned up (high potential for finding frustrated but well-meaning editors), and edits that tripped the filter and weren't (higher potential for finding false positives). WhatamIdoing (talk) 20:07, 2 November 2015 (UTC)
  • Oppose. Apparently nobody studies history anymore. The creation of this filter is just the first step. First they come for the potty mouthers, the cussers and the swearers, the rude and uncouth. Then they come for the critics and the nonconformists, the politically incorrect and the religiously obtuse. Then they come for the humorists, the comedians and the satirists, the poets and the prosodists. Then they come for the sad ones and the depressed ones, the angry and disenchanted, the silly and the sublime. Finally they come for the writers, and resolve that all discussion is now prohibited under arbcom decree seven slash five dot two, by order of Her Right Honorable Adminbot Eliza B. Viriditas (talk) 21:07, 2 November 2015 (UTC)
    • I believe that history actually has moved in the opposite direction. Public use of profanity, especially profanity directed at a woman or a child, was illegal for centuries in most of the Western world (USA examples: [26][27]). It is now generally legal (but still not, I believe, while driving a car in Germany). Penalizing "potty mouth, cussing, and swearing" has not yet seemed to degenerate into making criticism, non-conformism, rudeness, or obtuseness illegal. Whether legally accepting drunk men screaming obscenities at strangers on public sidewalks constitutes an improvement is something you will have to decide for yourself, but I'm not buying the slippery slope argument. WhatamIdoing (talk) 23:17, 2 November 2015 (UTC)
  • Question this has been described again elsewhere as "ClueBot for talk pages", but there is still no substantive information in this thread about how this proposal is intended to be implemented. Most of the discussion is around the use of edit filters. Edit filters are much simpler and dumber than ClueBot. What it is, technically, that you're actually suggesting, and how do you plan to evaluate whether it works? Opabinia regalis (talk) 00:56, 3 November 2015 (UTC)
    • Opabinia regalis, at the moment, I am envisaging a two-pronged approach: 1. a tag that shows up in recent changes, flagging "potentially problematic talk page edits", 2. a type-2 edit filter that if triggered brings up a reminder to look over an edit again before saving. In other words, no edits would be automatically reverted (unlike ClueBot), and no one would be prevented from posting anything they desire. However, the kind of artificial intelligence effort and refinement that would go into this to catch truly problematic edits while avoiding false positives would be quite similar to ClueBot (incl. user reporting of false positives). As for evaluating whether it works, it could be applied to pages that are known to be problematic, much as Masem has suggested in this discussion. The decision whether or not to implement the feature more widely would be made on the basis of performance in the pilot (feedback from participants and metrics like number of admin actions, including revdels and blocks. I am happy for people to modify and refine the idea; however, at present I think it really needs a two-pronged approach, i.e. first getting people to think about whether what they're about to post will really help move discussion into the desired direction, and secondly getting outside eyes on problematic discussions more quickly and without someone having to complain to an admin first.
    • Social dynamics have tipping points; sometimes shifting cultural standards just a little bit is enough to make the overall culture change a lot, as the kinds of constructive people who presently leave may stay on, and abusers may engage in more self-examination and/or find themselves subject to more scrutiny. A feature like this has the potential to achieve such a shift, reinforcing desired and discouraging unwanted behaviours. Andreas JN466 20:25, 8 November 2015 (UTC)
      • Thanks for the response, but I am still missing something. The tags that show up in recent changes are applied by edit filters. Your "type 2 edit filter" just sounds like an edit filter set to "warn". Edit filters are static regex with tight performance requirements. You could certainly design some sort of machine learning approach to identify potentially abusive edits, but it could not use tags or warn editors at the time of submission, because edit filters don't work that way.
        Furthermore, you're talking about "culture" in a way that seems to conflate multiple forms of problematic talk-page behavior. The kind of thing an edit filter could catch is very simple, unambiguous abuse. We do have problems with that, but it's usually coming from trolls or one-off accounts, and it's almost always removed and its source blocked as soon as an admin notices. Whatever problems there may be with Wikipedia's general culture, this kind of unambiguous trolling and abuse is not widely accepted or defended. The problem you really seem to want to solve has to do with aggressive, unnecessarily confrontational, personally insulting comments from actual editors, not plain old trolls. That's the kind of problem that is not usefully addressed by searching for strings of text in an edit. I'd guess that most people here who are complete assholes manage to do it with a minimum of curse words. Opabinia regalis (talk) 22:38, 8 November 2015 (UTC)
        • To address the latter point first, trolls and regular editors form a continuum – there have always been editors who fall between the two extremes. The more troll characteristics they have, the shorter their tenure; the more bona fide edits they make, the longer they last. Similarly, counterproductive talk page conduct forms a continuum, ranging from outright abuse to civil vexatiousness. Cutting down on the outright abuse end seems worthwhile, given how much it can inflame discussions or turn people off. As far as I understand from Wikipedia:Edit_filter#Basics_of_usage, edit filters can warn or tag. The idea is to use both: give users an opportunity to edit before submission, and tag if an apparently problematic is made regardless. Whether or not that can be achieved with the current edit filter/tagging functionality I don't know. Andreas JN466 13:53, 9 November 2015 (UTC)
          • This proposal has scope creep written all over it, and I think a lot of that is coming from the lack of technical detail letting people's imaginations run away with them. Yes, edit filters can warn or tag. They can't do so on the basis of machine learning applications like ClueBot. I think you are more likely to see success for this proposal with someone on board to develop a prototype, because right now the supporters are a mix of people endorsing edit filters, people endorsing a hypothetical sophisticated ClueBot equivalent, and people who don't really know the difference. The proposed implementation is too vague and unclear to evaluate. Opabinia regalis (talk) 06:38, 10 November 2015 (UTC)
  • Tentative support - there's a limitation to what you can realistically do with edit filters as they stand. I have been thinking for some time there may be value in having one (or two) for talk pages that gives "bad word" warnings - enabled for all users.
    • We have bad-word lists already.
    • A suitably worded warning will help people think twice, perhaps even encourage them to find a co-operative action instead of a combative one.
    • We might indeed retain both more of the short-tempered editors, and more of those people are short tempered with.
On the "con" side folks might take "no warning" as an OK. That fallacy has to be made clear from day one.
It might also make the bad-words that are used legitimately subject to false deprecation. Again bad words is not a subset of incivility - context is key, which is why it's a warning only
All the best: Rich Farmbrough, 01:12, 3 November 2015 (UTC).
  • Oppose. To talk fairly, our community isn't dumb. We are responsible and smart. We don't need nannies who want to censor our speech. As South Park (crudely) summed it up, "the world isn't one big liberal arts campus". --Kiyoshiendo (talk) 02:22, 3 November 2015 (UTC)
  • oppose I don’t see how anything can be robust enough to catch most abuse without catching far more false positives, and being easily worked around by anyone with any ability in English. If it is issues warnings it is even less useful: many editors already happily skip past the 'no edit summary' warning and will do the same with this. A minority might be prompted to change their post but only a small minority.--JohnBlackburnewordsdeeds 02:41, 3 November 2015 (UTC)
    Is it much of a hardship to have an extra click, say, every 1,000 talk page edits? While only a proportion of offensive edits would be stopped that might save a substantial amount of drama and aid editor retention. The log/tagging would also help human agents nip unpleasantness in the bud. All the best: Rich Farmbrough, 16:15, 3 November 2015 (UTC).
  • Support This is a way to face up to a real set of problems. If Wikipedia had real, broad–base organizational strength, then technical solutions would not be necessary. But it does not. At a minimum, this proposal is an attempt to take the problems seriously—and the effort is minor considering the magnitude of the problems. Complete automation should not be allowed; tagging only, followed by community review and evaluation is reasonable. — Neonorange (talk) 22:42, 3 November 2015 (UTC)
    • So, we say something that might be not be considered "clean", and we have an audience attracted to us for whatever reason. Sounds like an unnecessary microscope for a discussion relevant only to two people. --Kiyoshiendo (talk) 00:20, 4 November 2015 (UTC)
      • This is actually a fair point. I can see vindictive editors examining an editor's history and counting every one of these tagged edits and using that to try to oust that editor. I can also see it as being a means for people with the drive and effort to figure out what exactly the edit filter is filtering on so they know how to purposely avoid it. Is it possible to limit knowing when an edit has been tagged by this to admins only, who should be the only people judging if a pattern of these flagged edits is something actionable? --MASEM (t) 00:40, 4 November 2015 (UTC)
        • This is the first spin on this proposal that makes sense, but I fear the false positive rate would still be a mitigating, overwhelming factor. Meaning and subtext structures need to be considered here, and I'm afraid a bot just can't make meaningful decisions on just what language is indicative of, or constitutes "harassment," or "bullying," or "abuse," or what have you. Still oppose it for those reasons, but the idea of enforcing such a policy (if EVER possible) is moving on the right track with User:Masem's idea above. GenQuest "Talk to Me" 01:00, 4 November 2015 (UTC)
          • If the false positive rate is too high, then we will either change it to limit it further, or we'll just turn the thing off. It's not like we're swearing to keep this system in place until the WP:DEADLINE passes. We can try it out, and if we hate it, then we can turn the thing off again. I believe that disabling an edit filter is a two-click operation for admins. WhatamIdoing (talk) 19:38, 4 November 2015 (UTC)
            • Update. We have just had a pretty major lapse in our patrolling for bad edits. If our patrollers are spread so thin that a situation like that one slips through the cracks, we need to address this problem! With 5 million pages, we may be reaching the point where patrolling is breaking down. Even if it turns out that the talk page "filter" gets turned off for too many false positives, and the tool is only useful for tagging edits for human attention, it's still a way to save the time of patrollers. We don't want patrollers to be so over-stretched that they miss more serious situations like the one above. --Djembayz (talk) 16:29, 7 November 2015 (UTC)
  • Oppose Not even sure I agree in principle, but this implementation is a bad idea, as no matter how good the software used is, the number of false positives is likely to be too high to offset any potential benefit. Personal attacks can, and should, be handled as they always have. By telling users who commit them to knock it off, and then by blocking them when they persist. --Jayron32 17:21, 6 November 2015 (UTC)
  • Support a trial. There is much discussion here about needing effort put in to learning, and about false positives. However, I see no downside to trialling a filter in log-only mode to see how many false positives there are and see how much effort is required to train it. If after a while of training the effort required is still too great we can end the trail as unsuccessful without significant loss. If however the effort involved is seen as worthwhile by those expending it and we end up with something useful then we have made a significant gain. With careful wording and an explanatory link, a tag need not be anything bad - e.g. my edit creating Mets (disambiguation) was tagged with "possible Michael Jackson vandalism" (although the tag seems no longer visible?) but a simple examination shows it to be a false positive, and it has never been brought up by anyone until now. Thryduulf (talk) 01:08, 10 November 2015 (UTC)
  • Comment: Editors may be interested to learn of a very similar machine-learning project carried out in an online gaming community, as described in the following article: "Doing Something About the ‘Impossible Problem’ of Abuse in Online Games". It's reported to have had a major positive impact on cultural norms in that community. One very interesting finding is that the vast majority of negative behavior (which ranges from trash talk to non-extreme but still generally offensive language) did not originate from the persistently negative online citizens; in fact, 87 percent of online toxicity came from the neutral and positive citizens just having a bad day here or there. (Hat tip to Denny and Jorm, who brought this study to the attention of the Wikimedia-l mailing list. [28]) Andreas JN466 16:18, 14 November 2015 (UTC)
  • Oppose. Nanny filters have been tried. Many, many times. They lead to clbuttic and the Scunthorpe problem. (Did I just get a tag if this filter were in place?) Natural-language parsing is one of the hardest problems there is. And someone who's in the habit of swearing for emphasis, but not at people, will still get nagged and tagged. This is well-intentioned, I'm sure, but there are far too many ways it can go wrong and it's an idea known not to work. At this point, human cognition is required to interpret human speech. Seraphimblade Talk to me 16:22, 14 November 2015 (UTC)
    • What is proposed here is considerably more sophisticated than a bot that replaces occurrences of the string "ass" with the string "butt", or the string "tit" with the character string "breast". It's a lot of work, but the study mentioned above appears to validate the idea that if you start with a large enough body of interactions identified as genuinely problematic by human cognition, machine-learning can be brought to bear on the dataset in a way that is meaningful. It's been done. Andreas JN466 16:32, 14 November 2015 (UTC)
      • The abuse filter has nowhere near that type of machine learning capacity. (To my knowledge, it has none at all.) And if you look at the linked article, it was still heavily dependent on human interpretation. You just can't do what you are proposing with a regex. If you want to propose a different solution, code it up, let the code be reviewed, do a test run, and let's see how well it works before deciding whether we want to implement it. It is one thing to conceptualize a system that does something, it is a very different question to properly implement it. Let's see code, not concepts. Seraphimblade Talk to me 17:42, 14 November 2015 (UTC)
        • It's something I would like to see a Foundation-led team working on, possibly with outside input, as in the gaming example. (I've added it to the wishlist survey.) The team could start by building a database of oversighted and revision-deleted talk page posts. There is a wealth of material there that admins deemed unacceptable. Andreas JN466 12:45, 15 November 2015 (UTC)
  • Support, worth a try. • • • Peter (Southwood) (talk): 18:53, 14 November 2015 (UTC)
  • Oppose, nanny filters are silly and have never proven effective. Even if such a thing were possible, it wouldn't be effective for very long; the abuse would simply change/evolve to bypass it, and then the filter would be a pain to every editor. Ciridae (talk) 17:10, 18 November 2015 (UTC)
  • Support – Talkpages shouldn't be littered with profanity. There's just no reason to countenance trash talk or obscene scribbling on Wikipedia: this is an academic site, and anyone who feels it's necessary to advance his or her arguments with abusive language is probably not here to build an encyclopedia. I've scrubbed away a lot of unhelpful profanity on talkpages because, unlike article vandalism, it all seems to just sit there, often for years: it sits and stays and ends up tolerated (and even archived), with admins and editors stepping around it like goose droppings. But it shouldn't stay there; it shouldn't even be there in the first place. It makes the inner workings of WP look repellent, and leaves a terrible impression on new editors. I realize this little filter won't prevent all that many actual instances, but it does announce to the community that we do not want abuse, profanity, or incivility on our project. It's important to keep that basic credo held high for all to see. SteveStrummer (talk) 20:19, 22 November 2015 (UTC)
    SteveStrummer You see such comments left because removing them is a violation og WP:TALK, where it says under "appropriately editing others' comments" Removing harmful posts, including personal attacks, trolling and vandalism. This generally does not extend to messages that are merely uncivil; deletions of simple invective are controversial. If you make a habit of editing other editors' comments to remove invective and profanity, you might well be blocked for such editing. DES (talk) 13:36, 23 November 2015 (UTC)
    DESiegel Thanks for your concern. I know the policies quite well, but do feel free to pore over all my talkpage removals and examine them to your heart's content: they're all indefensible cases of abuse, trolling, and vandalism. Yes, I certainly found many others that I would have liked to remove, but I stayed within my remit as a non-admin. You, on the other hand, could be using that mop of yours to clean the project more effectively, instead of spending your time making undeserved ominous remarks to longtime volunteer editors. SteveStrummer (talk) 17:22, 23 November 2015 (UTC)
  • Support a trial, at the very least then we don't have to have the uninformative arguments about what may occur and we gather actual data. Alanscottwalker (talk) 12:27, 23 November 2015 (UTC)
  • Oppose. This is copulating ridiculous. I strongly resent being intimidated by a machine demanding political correctness in my personal choice of words. If you want to violate me have some guts and do it w/o having to misuse some obscure software (which doesn't solve the problem anyhow, in cases where there is one).--TMCk (talk) 18:35, 23 November 2015 (UTC)
I'm wondering if you would re-read your own post and see either: 1) how ineffective (dulled) your communication was, or 2) how silly it would appear to almost all people, if anyone took the time to write like that? Alanscottwalker (talk) 19:40, 23 November 2015 (UTC)
"you communication" - Too bad, isn't it?--TMCk (talk) 21:50, 23 November 2015 (UTC)
  • Oppose nanny filter per Beeblebrox: programming needs to become more sophisticated first. After watching WP:UAA for a couple of months, I'm deeply concerned about how poor the bot there is at identifying unsuitable usernames. Is there any reason to think this algorithm would be better? Opabinia regalis makes a very good point too. I also would rather not enable "civility-tag first responders to go digging through potentially uncivil edits looking for people to wag their fingers at". We have more than enough petty civility gotchas as it is. Bishonen | talk 23:29, 26 November 2015 (UTC).
  • Oppose - I swear all the time so me and this edit filter won't get on, I mean anyone can easily bypass it by example putting different characters in (IE FǓĊK or $h!t or even "Thuck You" ...) .... Point is It'd never work and it would create more chaos than anything!. –Davey2010Talk 23:50, 26 November 2015 (UTC)

Easier typing of diacritics

I would like to propose that an easier system for inserting diacritics is implemented. This has probably come up before but I did not find it in the archives or perennial proposals. I would like to see a keyboard-based intuitive system for inserting these. The current "select from a list" system is inefficient. Microsoft Word has keyboard shortcuts that are very intuitive, some examples;

  • Ctrl-', e produces "é"
  • Ctrl-Shift-^, a produces "â"
  • Ctrl-Shift-~, n produces "ñ"

The shift key is only needed because the diacritic character is on the shift tray of the key (may vary by country). I'm hoping that this is technically possible to implement on en.wp, but if it is not and wikimedia engine code modification is required, I would still like to propose it anyway so community support can be shown for it. SpinningSpark 16:35, 26 November 2015 (UTC)

This is in my opinion a keyboard layout or operating system issue. Inserting German diacritics is easy on, say, a German keyboard. In Linux and other Unix variants, there is often a compose key that is even more intuitive than what you propose. The British keybindings on a Mac have alt-u for umlauts: alt-u a gives ä. When I had a US keyboard, I had the right command key acting as compose, and cmd-" u would produce ü. As different editors will have different diacritics needs, I don't think Wikipedia should force one system on everyone. The diacritics toolbars are OK if you occasionally need a single letter, and terrible if you want to access certain diacritics often, but then you can just use appropriate keybindings that give you access to the diacritics you need. Personally I rarely need anything other than German diacritics (which I can easily access using the methods explained above) or Chinese characters (for those, I use input methods built into my operating system). Are there operating systems without decent keyboard layouts that solve your diacritic problem? —Kusma (t·c) 17:11, 26 November 2015 (UTC)
There are indeed, Kusma. As a trilingual and Thai language user, and working constantly with a desk cluttered with different keyboards for years (at least the the keys on all keyboards purchased here in Thailand are all bilingual AE/TH), current release of Mac OSX has the wonderful feature of when holding down any key for long enough a pop-up will appear with a choice of all the diacritics (Roman alphabet) for that letter. Kudpung กุดผึ้ง (talk) 20:14, 26 November 2015 (UTC)
Hey, that is nice. Didn't know that. Now I finally know how to easily type a haček. Thank you Kudpung! —Kusma (t·c) 20:30, 26 November 2015 (UTC)
None of that helps PC users. SpinningSpark 01:05, 27 November 2015 (UTC)
If it works on your computer in MS Word, why doesn't it work on your computer elsewhere? Input is the operating system's job, not the individual app's job. If you leave it to individual programs, then you'll need to memorize different keyboard shortcuts for every single program you use. WhatamIdoing (talk) 02:53, 27 November 2015 (UTC)
Of course it doesn't help PC users. Microsoft might catch up with Mac one of the days though - they've copied or emulated every other Apple innovation over the last 30 years. Note that anyone who has been to a meet up or a Wikimania, a graphics bureau, a film set, a translation service, will have noticed the huge number of Macs being used by serious computer users in creative arts. Kudpung กุดผึ้ง (talk) 03:29, 27 November 2015 (UTC)
FWIW, for Windows, if your keyboard has a numeric pad, there is a simple way to enter diacritics but you have to memorize the codes. ALT + num pad 0225 gives á. (see [29] for common ones) --MASEM (t) 03:37, 27 November 2015 (UTC)
FWIW, if you use a Mac and your input method is "Irish Extended", typing most European diacritics would be like a piece of raspberry cheesecake:
  • Option+9 produces " ´ ", (Option+9)+E produces (France) "é".
(Actually, since ÁÉÍÓÚ are Republic of Ireland Irish Gaelic alphabets, there're simpler combinations:Option+A/E/I/O/U )
  • Option+` produces " ` "; (Option+`)+A produces (Italy) "à".
  • Option+6 produces " ê ", (Option+6)+E produces (Portugal) "ê".
  • Option+8 produces " ¨ "; (Option+8)+E produces (Albania) "ë".
  • Option+0 produces " ¯ "; (Option+0)+O produces (Roman Empire) "ō".
  • Option+W produces " ˙ ", (Option+W)+M produces (Republic of Ireland) "ṁ".
  • Option+C produces " ¸ "; (Option+C)+S produces (Romania) "ş".
  • Option+N produces " ˜ "; (Option+N)+E produces (Estonia) "ẽ".
  • Option+K produces " ˚ "; (Option+K)+A produces (Sweden) "å", (Option+K)+O produces (Denmark) "ø".
  • Option+V produces " ˇ "; (Option+V)+Z produces (Czech Republic) "ž".
  • Option+M produces " ˛ "; (Option+M)+U produces (Lithuania) "ų".
  • Option+L produces " - "; (Option+L)+L produces (Poland) "ł".
  • Option+T produces (Iceland) "þ"; Option+D produces (Iceland) "ð".
However, I do understand that it's not just another day in the office for PC users. The biggest issue, though, would be using these combinations to type letters with diacritics without triggering the hot keys of your browser. Until this issue is solved, I would say respectfully that we stick to the current "click-and-insert" method. Cédric SAYS NO to anti-diacritic crusades! 06:36, 27 November 2015 (UTC)
I am completely pissed off with every time I raise a PC problem being told I should buy a Mac and every time I raise a Windows problem being told I should install Unix. Those kinds of responses are not helpful. In reply to User:WhatamIdoing, I have no idea why the shortcuts only work in Word (why would I know the answer to that?), they do not even work in other Microsoft applications. SpinningSpark 12:03, 27 November 2015 (UTC)
Well, it's not really a matter of having to get a different system – what people are mainly saying here is that these things are best handled by the operating system, not by individual applications, let alone individual websites within a browser application. Windows, just like any other modern operating system, has a wide choice of optional keyboard layouts that can easily be installed and switched between (no matter if some people might think the methods on the Mac are even more user-friendly). The "US-international" one is what's typically recommended for English speakers needing to use various diacritics [30]. Fut.Perf. ☼ 12:47, 27 November 2015 (UTC)
Googling "compose key for windows" brings up various software solutions. (For me the first hit is Wincompose, by Sam Hocevar). Perhaps you can find something suitable for you there. —Kusma (t·c) 13:22, 27 November 2015 (UTC)
Exactly what Future Perfect said. It's not about what system you buy, it's about where in the stack the problem is best fixed. And that is NOT inside Wikipedia. We already do that 'a bit' with the character insert panels (visibility == discoverability), but when it comes to intervening with what people type, it's better to deal with this a the OS level. And yes especially Mac OS has a really elegant solution for this and something like Wincompose is an easily installable Windows component which also targets this problem. —TheDJ (talk • contribs) 13:45, 27 November 2015 (UTC)
Assuming that you control the computer. It ought to be handled by the OS, but if it's not, then people using Windows boxes in schools, libraries or internet cafés are going to have problems. WhatamIdoing (talk) 06:11, 28 November 2015 (UTC)
True, but there will always be problems and perfection is the enemy of good. —TheDJ (talk • contribs) 08:20, 28 November 2015 (UTC)

Article Deleted

NOTHING TO SEE HERE, MOVE ALONG
not really a proposal, not really clear what it was even about, referred elsewhere for future reference Beeblebrox (talk) 22:02, 27 November 2015 (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.

The return of the Trading Card Game. I want to revive it under the temporary name Article Deleted. Signed, I'm returning...from the WikiDead. (But you still dare speak to me...) 15:05, 27 November 2015 (UTC)

@The One To Return: You can create a userspace draft at Special:MyPage/sandbox. But next time ask questions like this one on the help desk instead. nyuszika7h (talk) 15:24, 27 November 2015 (UTC)
As far as I can tell, Trading Card Game has never been deleted, but it has been renamed to Collectible card game. SpinningSpark 15:42, 27 November 2015 (UTC)
I think it likely a different article being discussed since Trading Card Game was not an article but a refirect created over 8 years ago.--65.94.253.102 (talk) 19:39, 27 November 2015 (UTC)
Turns out that they were talking about Wikipedia:trading card game.--65.94.253.102 (talk) 19:42, 27 November 2015 (UTC)

Whack!

You've been whacked with a wet trout.

Don't take this too seriously. Someone just wants to let you know that you did something silly.
Clarify: I meant WP:Trading card game. I'm returning...from the WikiDead. (But you still dare speak to me...) 12:27, 28 November 2015 (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.

I propose that for false links a lighter pink should be used rather than the deeper red now used. It should make the name barely visible until the square brackets are removed. In many cases people deliberately use the red to highlight a name, making it more prominent than for a person acknowledged as prominent! Jzsj (talk) 20:32, 17 November 2015 (UTC)

Have you any actual examples of "people deliberately use the red to highlight a name"? In a decade on Wikipedia, I've never once seen this, other than in the sense that a redlink indicates that someone feels the topic is deserving of its own article. A link being blue doesn't mean the subject is "acknowledged as prominent", it means the Wikipedia article on the topic has been written—there should be no difference in notability between red and blue links. (If the target of a redlink is demonstrably so non-notable that an article about the topic should never be written, than the link shouldn't exist at all and the colour ceases to be an issue.) Making links "barely visible until the square brackets are removed" is never going to happen; why would we want to make articles intentionally unreadable? Besides, Wikipedia—and wikis in general—are so well established that virtually all readers are now aware of the "blue means written, red means unwritten" principle. ‑ iridescent 20:39, 17 November 2015 (UTC)
^^ The red link is relatively significant to Wikipedia's identity -- in fact, several books and papers about Wikipedia in general or its interface in particular have gone into some detail on the subject. Also, we don't want to make any text unreadable (or hard to read). — Rhododendrites talk \\ 23:35, 17 November 2015 (UTC)
I don't even know what to say to such a wrong-headed proposal. Our policy on the subject (you have read that before proposing this, right?) already defines when it is and is not appropriate to add or remove redlinks. This "solution" to the perceived problem of strategic adding of redlinks, to make them cause eye strain instead of just unlinking them or finding an appropriate target to redirect them to, is so bad it does not merit discussion. Beeblebrox (talk) 03:42, 21 November 2015 (UTC)
Is it really necessary to be so bitter, Beeblebrox? We should expect more of an administrator. SteveStrummer (talk) 21:43, 22 November 2015 (UTC)
I reckon red links should be invisible, until a page of the name of link is created, then a visible blue link is created.Theoosmond(talk)(warn) 18:40, 23 November 2015 (UTC)
Red links have the following effects:
  • indicating to people that an article for a notable subject is missing
  • making it easy for any editor to start the article (just by clicking on the link)
  • preventing new pages from being orphaned at the moment of their creation
  • causing Wikipedia to grow
Given all of those benefits, why should we make them invisible? WhatamIdoing (talk) 01:09, 24 November 2015 (UTC)
I tried explaining to Theoosmond here. --Redrose64 (talk) 10:01, 28 November 2015 (UTC)
@WhatamIdoing:You could simply list red links at the bottom of the page or on the talk page or something. All your arguements only seem to benefit editors, not just simple readers.Theoosmond(talk)(warn) 15:11, 28 November 2015 (UTC)
The goal is to benefit Wikipedia, by benefiting readers who would like to become editors and editors who would like to find an interesting new page to start.
Also, listing red links at the bottom of the page isn't as good (it'd be a random list of words, with no indication of relevance). Relatively few people read the talk pages. Finally, we already have centralized lists of red links: Wikipedia:Requested articles. This is a both/and approach, not an either/or approach. WhatamIdoing (talk) 17:25, 28 November 2015 (UTC)

Default english templates in all Wikipedias

I'm translating pages from english to the portuguese Wikipedia, and I've noticed that Infoboxes/Cite templates are not compatible between different language Wikipedias. When I copy-paste an Infobox from an english Wikipedia page to a non-english, the second will not process the Infobox correctly and will print some error or will have a wrong behavior. As a translator of pages, I'd like to be able to not have to worry about rewriting the infobox field names, when it could be done automatically for me by Wikipedia engine itself. That's why there should be a default english template fully working on all Wikipedias, without the possibility to remove or modify it - it should be restricted only to global Wikipedia admins/developers.

So, the person who translates a page from english to any other language will be able to copy-paste Infoboxes and Cite templates without changing any field names. The templates will support multiple field names from different languages. If a translator want to rewrite the Infobox in his language he will be free to do that, and he will have the option to stay with the english Infobox. Faltur (talk) 04:58, 28 November 2015 (UTC)

You can look at m:Global templates. Ruslik_Zero 10:44, 28 November 2015 (UTC)
Faltur, I sympathise up to a point, having met the same issue. I think you're calling for templates with the same function, such as infobox templates, to have exactly corresponding parameters with exactly corresponding functions in all languages (which I don't think is always the case currently); and for the ability to translate infoboxes automatically from one language to another. A central, multi-lingual template repository would be a very good idea.
I hope you're not calling for central templates in English language only , which would surely be thought cultural imperialism! Whatever we do in this area, we need to encourage, not discourage, editors of non-English Wikipedias, especially editors in Category:User en-0 (see above). Stanning (talk) 15:08, 29 November 2015 (UTC)

RFA2015 Phase II RfC

Hello. Anyone who reads this message is invited to voice their opinions on the Phase II RfC for the RFA2015 reform project. The purpose of this RfC is to find implementable solutions for the problems identified in Phase I of the project. Thank you. Biblioworm 20:51, 29 November 2015 (UTC)

Your input requested on the proposed #FreeBassel banner campaign

This is a message regarding the proposed 2015 Free Bassel banner. Translations are available.

Hi everyone,

This is to inform all Wikimedia contributors that a straw poll seeking your involvement has just been started on Meta-Wiki.

As some of your might be aware, a small group of Wikimedia volunteers have proposed a banner campaign informing Wikipedia readers about the urgent situation of our fellow Wikipedian, open source software developer and Creative Commons activist, Bassel Khartabil. An exemplary banner and an explanatory page have now been prepared, and translated into about half a dozen languages by volunteer translators.

We are seeking your involvement to decide if the global Wikimedia community approves starting a banner campaign asking Wikipedia readers to call on the Syrian government to release Bassel from prison. We understand that a campaign like this would be unprecedented in Wikipedia's history, which is why we're seeking the widest possible consensus among the community.

Given Bassel's urgent situation and the resulting tight schedule, we ask everyone to get involved with the poll and the discussion to the widest possible extent, and to promote it among your communities as soon as possible.

(Apologies for writing in English; please kindly translate this message into your own language.)

Thank you for your participation!

Posted by the MediaWiki message delivery 21:47, 25 November 2015 (UTC) • Translate • Get help

Moved from WP:VPT GorillaWarfare (talk) 02:06, 28 November 2015 (UTC)

Why in the hell are these things always posted on weekends and holidays? 97.93.100.146 (talk) 21:54, 1 December 2015 (UTC)

Wikipedia talk:Deletion policy#RFC: delete and redirect

There is an RfC at Wikipedia talk:Deletion policy#RFC: delete and redirect that asks: "Should our default practice be to delete article histories and contributions when a small article is converted into a redirect to a larger article?" Cunard (talk) 05:53, 2 December 2015 (UTC)

RfA clerking proposal

You are invited to participate in a RfC proposing clerking in RfAs; the discussion is here. Esquivalience t 01:37, 3 December 2015 (UTC)

fromtexttospeech.org

I propose we use fromtexttospeech.org to translate articles from text to speech, and save them to the articles, so wikipedia users can listen to the articles. It would improve accessibility 117.207.237.22 (talk) 13:47, 4 December 2015 (UTC)pacfall

Wikipedia Education

After bumping into several education projects, good and not so good, I have started this Request for Comment to try to make the education programme even better. You are most cordially invited to participate. Fiddle Faddle 14:06, 4 December 2015 (UTC)

Proposing to move this category and its children to "requested images"

Please see discussion at Category talk:Wikipedia requested images by subject#Proposing to move this category and its children to "requested images (of/in ...)". Thank you for your time. JJ98 (Talk) 17:58, 11 December 2015 (UTC)

Wikipedia turning 15: Top contributors

A good-faith suggestion but no point in continuing it given the current level of opposition. BencherliteTalk 22:23, 15 December 2015 (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.

Hello everyone, Wikipedia is turning 15 soon. I have a small suggestion (which I also posted here). I am not sure what is the right forum to bring up a subject like this and hence I am taking the liberty of opening a discussion here.

Can the foundation pick up top 10 editors, top 10 article creators etc and present them personalized mementos for their tireless contribution to Wikipedia? Also, a small note of thank and appreciation on various social networking (Facebook, Twitter etc) and a press release for their contributions will also be very encouraging. The least we can do is to express our gratitude and encourage following senior editors; without them Wikipedia would have been a very different and less informative place. Thank you editors (below) for your time and efforts.

Top 10 Wikipedians by edits

Top 10 Wikipedians by article count

Comments and support invited. Arun Kumar SINGH (Talk) 17:18, 15 December 2015 (UTC)

That's extremely thoughtful of you, Arun. All the best: Rich Farmbrough, 17:27, 15 December 2015 (UTC).
  • I'm not sure I like the idea of listing the top 10 by edit count - we're going to fight endlessly about whether or not automated edits should be counted, and then what is the definition of an automated edit, and I think we should just skip the whole exercise. Not to undermine any of these fine editors' contributions, of course. As for article creation, sure, but Neelix should be disqualified. Ivanvector 🍁 (talk) 17:27, 15 December 2015 (UTC)
  • Oppose advertising this as a whole. No offense to the good faith editors listed here, but this concept promotes "gaming the system" for validation. No thanks. Steel1943 (talk) 17:32, 15 December 2015 (UTC)
  • I don't much like this, especially the first list, as quantity too often drives out quality. I don't think Arun Kumar SINGH is up with the current Neelix situation, for example! Some more nuanced stats would be interesting but difficult to produce. I wouldn't mind some adjudicated list. Johnbod (talk) 17:40, 15 December 2015 (UTC)
  • Comment. Before I get hammered for floating a bad proposal, I just wish to clarify that I have nothing to gain from this. I am not concerned about the "automated" or "manual" edits OR the quality of articles created simply because regardless of automation, it is a fact that all the people listed above have devoted massive amount of personal time from their life without any personal gains, which they could utilized somewhere else - let's not discount their efforts. Let's not forget that this "proposal" is only AGF and does not mean that the Wikipedia Foundation, Jimmy Wales and / or Larry Sanger should shower them with expensive gifts or go ga-ga on print and electronic media. All I am trying to say is let's be appreciative of the work done by our senior fellow editors and at the same time, some sort of acknowledgement from the foundation will be very encouraging. Thanks, Arun Kumar SINGH (Talk) 17:43, 15 December 2015 (UTC)
p.s. I have simply picked the top 10 (non bot) names from the list without applying any "filters" and the list does not mean that it is firm.
  • Oppose There are many ways to contribute and we don't have a meaningful measure to compare different ways, editing patterns and quality. Comparing to Wikipedia:List of Wikipedians by article count#List, is it for example fair that Tassedethe is listed above with 7,410 articles + 35,970 redirects, while Ram-Man is not with 35,079 articles + 802 redirects? I have no idea which of the two has made the "largest" or "best" total contribution to Wikipedia. Project space can show various lists like edit count and article creations but I don't think specific counting methods should be singled out in official announcements. PrimeHunter (talk) 18:20, 15 December 2015 (UTC)
  • Oppose Why not by number of featured articles ? Or by number of admin actions done ? All of these criteria are arbitrary and do not reflect the wide array of positive contributions editors can make on Wikipedia. Cenarium (talk) 19:55, 15 December 2015 (UTC)
  • Oppose This is a form of WP:Editcountitis, and encourages junk edits. John Nagle (talk) 20:05, 15 December 2015 (UTC)
  • Oppose for the following reasons:
  • This isn't a contenst.
  • Anyone using AWB or other automation can make thousands of brainless edits, that doesn't make them a top contributor. It doesn't make them a crappy contributor either. It just makes them a contributor, like everyone else.
  • Some users make big edits making lots of changes with a single edit. Edit counting implies these are less worthy than lots and lots of small edits that accomplish the same thing less efficiently.
  • One of your top article creators is blocked for creating tons of crappy pages, so there's a demonstration of why this is a bad idea right there
  • Anyone can create thousands of two-line stubs and really pump up their article creration numbers. That doesn't make them more valuable to the project than people who concentrate their efforts on improving one thing at atime until it's a good article or better.
  • This still isn't a contest.

-Beeblebrox (talk) 20:11, 15 December 2015 (UTC)

  • Oppose This encourages too much of the wrong mindset. There's also been more gamesmanship on the article count side by people either creating BS versions that get immediately deleted or draft or userspace versions with basically nothing and then asking to "refund" their version or merge their version into the one that is created later so they can puff up their "article creation count" and steal the creation credit from the person who actually did the real work. -- Ricky81682 (talk) 20:17, 15 December 2015 (UTC)
  • Oppose. A well-meant proposal, but there's really no good way of measuring any of these things, compare Beeblebrox's examples. Bishonen | talk 20:18, 15 December 2015 (UTC).
  • Oppose. As someone included into this shortlist, I, too, am uncomfortable with this proposal. I may have sunk countless hours into Wikipedia, but I don't feel that elevates me in status to that of a "top contributor"; it merely shows that I stuck around for a long time and probably have time to spare and enjoy the process. Lots of people contribute into Wikipedia in lots of different ways, and not all those ways will lead to them showing up in the "top XX whatever" lists. This does not make their contributions any less worthy, only less conspicuous. If the proposal is to recognize tenure, that may be fine, but even then I would personally feel a little foolish. Wikipedia is a group accomplishment; let's celebrate its anniversary as such.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); December 15, 2015; 20:39 (UTC)
  • Oppose. As another listed contributor I too would not endorse this. The type of edits I do tend to quantity over quality (other contributors may vary). Tassedethe (talk) 21:30, 15 December 2015 (UTC)
  • Oppose per the points summarised by Beeblebrox. --Rubbish computer (Merry Christmas!: ...And a Happy New Year!) 21:49, 15 December 2015 (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.
Didn't get a chance to comment before the bad-faith lockdown. Obviously those who oppose have no real contributions worth talking about anyway. Oh well. Lugnuts Dick Laurent is dead 07:49, 16 December 2015 (UTC)

Template:Item

I have created template {{Item}}. It is a generic template, which allows to pass multiple structured items to another template. I think it has a great potential. Look at its documentation or see its use at Myanmar general election, 2015#House of Nationalities. Petr Matas 16:23, 13 December 2015 (UTC)

@Petr Matas: It does, indeed, look extremely useful: thanks for creating it! Rubbish computer (Merry Christmas!: ...And a Happy New Year!) 00:44, 14 December 2015 (UTC)
Thanks for that! All the best: Rich Farmbrough, 13:53, 16 December 2015 (UTC).

SUL

All users should be permanently attached to an account on every WMF wiki. Also, when creating an account on any WMF wiki, the same username with the same password should automatically be created simultaneously on the other WMF wikis. That would mean that all WMF wikis would have the same number of user accounts. GeoffreyT2000 (talk) 15:22, 29 November 2015 (UTC)

They are, and have been since May 2008. --Redrose64 (talk) 21:59, 29 November 2015 (UTC)
Actually, accounts are only created on those wikis where the user has logged in, or has transfered to while logged in to an other wiki. However, they exist in the sense that you can log in to any one of them as easily as the one where you originally created the account, and no one can create an account with the same name. עוד מישהו Od Mishehu 21:45, 30 November 2015 (UTC)
That, and I think since last year, each username has to be connected globally to all WMF sites. I cannot find a link to a reference right now, but it was because of the integration that caused the user names ending with "enwiki" to exist on this Wikipedia. Steel1943 (talk) 23:52, 30 November 2015 (UTC)
@Od Mishehu: So how come I occasionally get welcome emails from foreign Wikipedias that I've never visited? --Redrose64 (talk) 00:36, 1 December 2015 (UTC)
@Redrose64:Which ones? עוד מישהו Od Mishehu 03:59, 1 December 2015 (UTC)
Don't recall, I deleted the mails. Mostly they had a non-Latin script, possibly south Asia; also I think somewhere in eastern Europe. --Redrose64 (talk) 10:08, 1 December 2015 (UTC)
Redrose64,Od Mishehu, There seems to be a half-way state for user accounts if some of your edits are copied in to another wiki. My global contributions show a strange existence on bh:. My account on mai: was the same "SUL: Account not attached" until I visited my talk page there at which point it disappeared. Perhaps that might account for Redrose's emails, there are several wikis where that state holds true for Redrose's account? Bazj (talk) 14:47, 1 December 2015 (UTC)
Those are strange. I just visited a couple of those showing "SUL: Account not attached" - ml.wikibooks.org and el.wikisource.org - and both of them show me as logged in. When I refresh https://tools.wmflabs.org/guc/?user=Redrose64 I find that those two are no longer listed, it's like my transwikid contribs are lost. --Redrose64 (talk) 21:41, 1 December 2015 (UTC)
My best guess is that these edits were deleted - either normal deletion or revdel including the user section; unfortunately, I can't check this - either you need to have the page titles in question (which you probably don't), or we need the local admins from these wikis to answer. עוד מישהו Od Mishehu 05:31, 4 December 2015 (UTC)
Since b:ml:Special:Contributions/Redrose64 and s:el:Special:Contributions/Redrose64 both come back empty, I think that what has happened is that edits that I had made on English Wikipedia were imported to another wiki by somebody else but without first checking that I was registered on that wiki. They were shown against my name because that name was on the XML file exported from en.wp but as soon as I registered on those wikis (merely by visiting them), the link was broken. This happened a few years ago on another wiki (I think w:ur:), and I had to jump through all sorts of hoops to get the accounts properly linked.
Testing that idea: https://tools.wmflabs.org/guc/?user=Redrose64 currently shows mr.wikisource.org as "SUL: Account not attached." with two edits, mr:s:Special:Diff/8298 to mr:s:साचा:Pp-meta and mr:s:Special:Diff/8366 to mr:s:साचा:Pp-template. If I check when logged out, s:mr:Special:Contributions/Redrose64 shows those same two edits. Then I log back in, and my contribs is empty; log out, and it's still empty. However, the edit histories for those two pages still list me as having made the edits. So the action of visiting that wiki makes the link between the accounts, and breaks at least one (but not all) of the links between my account and those edits. This indicates a MediaWiki bug. --Redrose64 (talk) 10:24, 4 December 2015 (UTC)
Agree. I hit an edit conflict when saying pretty much the same thing. Looking at my user log on mai it shows a creation date of 1 Dec, when I first visited. I can't find any trace of any other Bazj account there. Perhaps it's as simple as not checking for edits prior to your account creation? But... In comparing edit histories of Redrose's templates it appears that the entire pre-copy history is lost.
Comparing the history of pp-meta here and there (screen-grab), and then comparing the history of pp-template here, at el.wikisource where RR has visited, and mr.wikisource (screen-grab) where RR hasn't, seems to show that a visit from RR destroys the history drawn from other wikis leaving intact only the post-copy history. It then affects the contributions of other editors of the pre-copy version stripping them of the credit they're due. It seems to affect templates, modules, .js and .css which have been copied across. Bazj (talk) 11:02, 4 December 2015 (UTC)
This is phab:T111605. --Stefan2 (talk) 18:03, 12 December 2015 (UTC)
Okay, let's clarify a few things. Accounts are only created on Wikimedia projects when you visit them while logged in on another project. The only exceptions to that are loginwiki, mediawikiwiki, and metawiki, where your account will be created instantaneously upon initial registration (since ~6 months ago). The GUC tool on labs claims your account is unattached if your edits were imported but doesn't exist - that's a bug in the tool. Use Special:CentralAuth if you want the actual data that MediaWiki sees. Legoktm (talk) 21:51, 12 December 2015 (UTC)
@Legoktm: How can I find the edits that have my name on if they're not showing in my contribs? --Redrose64 (talk) 17:19, 13 December 2015 (UTC)
You can't. There are perfectly good reasons not to credit imported contribs, unless you are given that there is a universal correspondence between the accounts on the two wikis, which has only been the case for WMF wikis for a relatively short time. All the best: Rich Farmbrough, 14:03, 16 December 2015 (UTC).
Unless of course you use Quarry. Or raise a bug to have the situation changed. All the best: Rich Farmbrough, 14:04, 16 December 2015 (UTC).
And the tool Bazj pointed out? ( https://tools.wmflabs.org/guc/?user=Redrose64 ) All the best: Rich Farmbrough, 14:07, 16 December 2015 (UTC).
Except that once your account is attached, these edits no longer show. <sigh> All the best: Rich Farmbrough, 14:17, 16 December 2015 (UTC).

Donation banner, it should be shown differently

I try to donate every year a bit to the wiki, but the donation banner is very invasive. I would understand if it would be shown every day once, but not every time that one lands on a wiki page. I know that one can just click to disable it, but still i think that it is more counterproductive than productive, it should be shown in a less invasive way. Very basic example: having it not as a javascript dynamic action, but hardcoded in a wiki page (would be possible, like an include), would make the navigation better because one can just read the page leaving the banner on the top. And this would not disrupt the navigation with touch devices that does not use the mobile wiki site. --Pier4r (talk) 15:33, 16 December 2015 (UTC)

@Pier4r: That sounds like a good idea. --Rubbish computer (Merry Christmas!: ...And a Happy New Year!) 17:10, 16 December 2015 (UTC)

Suggestion about deletion notifications

I would like to suggest Wikipedia can notify creators or uploaders that article (or template, file etc.) has been deleted or kept by administrator after the article for deletion discussion (or template for discussion, files for discussion etc.) is closed. Please propose your ideas and views under the line, thank you.--Shwangtianyuan (talk) 00:31, 18 December 2015 (UTC)

I do see it on the watchlist - deletions or removal of AFD notices. But I suppose you may want a notification. Graeme Bartlett (talk) 12:24, 18 December 2015 (UTC)

Make it harder to move pages to the "Wikipedia" namespace or provide a way to track these moves

I'm not sure if this is the right place for this so please do redirect me if there is a more appropriate venue. I just spent my time going through the move log searching for moves to the "Wikipedia" namespace. (I only managed to get up to November 13) The generally appropriate moves to that namespace are renames, and user essays. However, I found quite a few drafts (and user pages...) moved there. Here are the options the move dialogue gives you. I don't know about you, but if I was a new editor wanting to publish my article, I would choose the "Wikipedia" option, especially since the "article" option is in parenthesis. (Note also, that the move page makes no mention of what these options are)

Now why is this an issue? Here are the types of people I've noticed moving these articles:

  • New editors: As you'd expect, many new editors accidentally move their articles here. The solution once you find these is usually pretty easy: either move the article back or publish it. However we should be stopping this from happening because it causes these new articles to never receive attention and be invisible to our normal processes. It also make editors wonder where the wiki part of our encyclopedia went and deprives us of the chance of working with them and teaching them.
  • Student editors: The student drafts are the most confusing ones because they usually end up doing copy-paste moves or don't know how to integrate their sandbox version of an article into the existing one. So you end up having an article with the same name in the Wikipedia namespace. This is a sign that we need to help guide these editors more, because the articles I have seen from them have been pretty well referenced and it would be a shame to have them hidden away.
  • Bad actors: This is where things get worrying. I've seen users whose talk pages are littered with rejected draft notices just move the things like non-notable subjects and blatant advertising. And guess what? The moved article shows up in search results! What's the point of our new article patrol if it can just be circumvented?

Wikipedia needs to make it harder to move images to the wrong namespace by either:

  1. Clearly telling users: "If you're ready to publish, choose the (article) namespace [usually what they want] or if you want more more eyes, choose the Draft namespace."
  2. Prevent moves to the article namespace except by more experienced editors. Even the actual pages in the Wikipedia namespace should be seldom-renamed.
  3. Provide an option to track cross-namespace moves. It is in our best interest to watch these even if the instructions were made clearer because there could still be bad actors and these could be used for subtle vandalism.

Wikipedia's system usually works really well but this is an overlooked hole that harms well-meaning users and helps nefarious ones as well. (See also: Special:NewPages filtered by the "Wikipedia" namespace and Category:Non-userspace pages using User sandbox. At some point it might be worth running a script to find all articles in namespaces where they don't belong)

tl;dr: newer editors are moving articles to the Wikipedia namespace and it's a problem. Opencooper (talk) 20:05, 17 December 2015 (UTC)

This is a problem, and also getting things wrong on the dropdown is very easy. In the previous version of move, this sort of problem did not happen. I have made enough erroneous moves to user space, by only removing the user, or ending up with the username as part of an article name. So I agree there should be more of a sanity check on the move. Perhaps different options on a dropdown, eg publish article, userfy, convert to draft, simple rename. Graeme Bartlett (talk) 02:40, 18 December 2015 (UTC)
  • Add a confirmation prompt for cross-namespace moves. That is all. (If possible, with one exception: moved from the "Wikipedia talk:" to the "Draft:" namespace. I know that may sound a bit odd, but since drafts were previously in the "Wikipedia talk:" namespace and the new accepted namespace is "Draft:", it's just namespace correction.) Steel1943 (talk) 02:45, 18 December 2015 (UTC)
  • Also, I oppose warnings/prompts for anything else regarding this proposal since anything else, such as what is suggested here, would cause an annoyance for seasoned editors. However, I'm neutral on having a system to track the cross-namespace moves. Steel1943 (talk) 02:47, 18 December 2015 (UTC)
  • Lastly, the proposer has not defined what a "more experienced editor" is. This proposal, if executed as proposed, will need to have a technical definition of what a "more experienced editor" is. Otherwise, that portion of the proposal world require judgement of others to define ... and if that is the case, I would oppose that as unnecessary WP:CREEP-adding. Steel1943 (talk) 02:50, 18 December 2015 (UTC)
We may be able to do some of this with the abuse filter, I've been trying a few things but it may be running in to a namespace definition bug. — xaosflux Talk 03:48, 18 December 2015 (UTC)
Thank you all for the thoughts. @Graeme Bartlett: I like the idea of of giving choices for actions instead of pure moves. That way the intent is really clear. Great idea and it would eliminate the need for having to understand namespaces for beginners. @Steel1943: I never knew about drafts being in the "Wikipedia talk:" namespace. You have a good point about having to strike a balance between not annoying the more experienced editors like the ones who want to publish user essays, and newer users might ignore the prompt because who reads popup messages anyway? And I realize now that "more experienced editor" might be really vague and not so clear-cut so I take that back since we have autoconfirmed rights for that anyway. @Xaosflux: I'm assuming you're talking about adding tags for cross-namespace moves? Because I have seen "new editor moving page out of userspace". That would be a good way to track these. Opencooper (talk) 09:43, 18 December 2015 (UTC)
Perhaps there could be a preferences setting for the form of move for different users. By default you would get a guided choice that would steer clear of pitfalls. But with a preference setting you could get a move screen the same as it is ow, or the more basic older screen, with no dropdown lists. The more experienced editor is the one that knows how to change it in their preferences. Graeme Bartlett (talk) 12:23, 18 December 2015 (UTC)
@Opencooper: tags are reactive - if we can get it to work we could issue a "warning" (are you sure? notice) for certain criteria {such as MAIN-->WIKIPEDIA, editor has <100 edits} if it is prevalent enough and has community support. — xaosflux Talk 14:55, 18 December 2015 (UTC)
Discussion continues at Wikipedia:Village pump (technical)/Archive 142#Make false links GREEN rather than RED. I am closing this discussion per WP:MULTI. --Izno (talk) 20:32, 21 December 2015 (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 understand that red ((proposed) links are useful for suggesting articles for creation. But I've heard no reason why green couldn't be used. It would be less of a distraction on the pages of the encyclopedia and still allow for a suggestion that prominence might be accorded the person or item. Having green would also lessen the widespread abuse of the red to give prominence to those who have very little chance of achieving it.Jzsj (talk) 18:42, 21 December 2015 (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.

Clerking RfC

Hello. You are invited to comment on this RfC concerning clerking at RfA: Wikipedia:2015 administrator election reform/Phase II/Clerking RfC. Please do not comment in this section, but rather make all comments in the appropriate place on the RfC. Thank you. Biblioworm 22:32, 21 December 2015 (UTC)

Allow non-rendered content in TimedText namespace

It seems to me that the TimedText namespace needs to be changed to allow the inclusion of non-rendered content such as csd tags, mfd tags, and non-free-use rationales. Maybe it could be set off with noinclude tags. —teb728 t c 11:36, 22 December 2015 (UTC)

Users can help in AIV

I suggest that we make it possible for users (maybe the same as WP:NAC) to reply to reports in AIV. For example, if a user has not been warned even once and seems to have made good faith edits, we could put a warned tag as a reply. I've also seen a lot of people coming to AIV for block evasions, so it might be easier for the administrators if we could reply with a message saying they might want to take it to WP:SPI. Finally, if people really like this idea we might want respectable users to 'self-endorse' the block after they have looked into it. Dat GuyTalkContribs 10:50, 24 December 2015 (UTC)

All users are welcome to help at AIV. By tradition only admins can remove reports, but anyone can comment. -- zzuuzz (talk) 11:44, 24 December 2015 (UTC)

Bring template for translated articles back

Hello. I am user of the Spanish Wikipedia, but I was passing around and I improved an article that had been translated some days ago from the Spanish Wikipedia. It had none mention to the fact of being a translation, so I inserted it the appropriate template in the talk page. But to my surprise, there is no template for the article itself. In the Spanish Wikipedia when we translate, we put a template in the talk page and another one in ¨External Links¨. I want to have a similar template here because I think it is more important to have it visible in the article than hidden in a talk page. Unless wanting to discuss something, readers don´t open a talk page. And I think it is fair to editors of other wikis, to have the attribution in the article. Besides, that goes in line/agreement with our license and policy of giving attribution when we use material from other free knowledge/source sites. And the article is the place for attribution, not the talk page. I was reading that there had been a template like this and had been deleted five years ago. One of the arguments was that in the summary of edits the attribution could be given. But this could be ignored in and edit and there isn´t way to fix it as there would be if I could insert the template (that besides is more visible and doesn't get lost in the history after hundreds of edits in years). I don't know if that template was the same as the one I am asking, but the template I want is something like this (first bullet), used in the Spanish wiki. It doesn't occupy much space or distract... but just gives a necessary and fair attribution. I know that there is a Template discussion page, but it talks only about deletions, not about bringing something back. That is why I bring it here... sorry if there is other place more adequate. Regards, --Lcsrns (Talk) 18:03, 25 December 2015 (UTC)

I'm confused as what you want. Is If you look at the first discussion, you'll see that the larger concern was against disclaimers at all, not objections about it being from other wikis. In that sense, is it really worse if we say that translated articles aren't identified and marked up and instead are just treated the same as if a English second language writer or the like wrote it? Now, I'd say that the GFDL requires that the editor in the edit summary mention that it was from the other wiki which is explicit here and done via the edit summary with nothing more on the page itself. -- Ricky81682 (talk) 08:52, 29 December 2015 (UTC)
I didn't meant anything regarding an objection about disclaimers being from other wikis... all the contrary, I just think it is a good idea and being used to the Spanish version I was surprised when I was looking for the template and I couldn't use it here. I just think that putting a note in the edit summary is not enough and in would be better to also have a note in the external links section. That is what I want, sorry if I didn't express correctly before. I thought that the last discussion was of 2010 and I was reopening debate as whether to have it, but now I see it was also debated in 2012 (thanks for showing me that discussion, I hadn't seen it before).--Lcsrns (Talk) 12:44, 29 December 2015 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_128&oldid=1219405199"