Wikipedia:Village pump (proposals)/Archive 128

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

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)

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! ...

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://en.wikipedia.org/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,

( Talk )

03:49, 17 October 2015 (UTC)

ahau 2001:268:C2C1:21B0:7CDC:5127:2623:9CD6 (talk) 09:00, 25 November 2022 (UTC)

( Talk )

04:25, 17 October 2015 (UTC)

block). Inline comments run to the end of the line, while block comments may span several lines. SiBr₄ (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'
);

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)

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

then—upon editing—this:

should display as this:

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

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 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"?

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)

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)

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

This recognizes editors who've taken a page previously considered for deletion — to

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)

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)

Wikisource has original text related to this article:

What Is the Trans-Pacific Partnership Agreement (TPP)?

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

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)

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

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.

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)

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)

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)

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)

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)
  • There would be a new tick box on the edit screen "sign this edit". If you don't want to sign you untick it. ϢereSpielChequers 14:43, 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.—
  Chat
  :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.
  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. --
  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!. –Davey2010^Talk 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
  csdnew
  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)
  • @Nyttend: There would be a checkbox saying sign this post that would be automatically checked. Users who are deleting or editing would simply uncheck the box. Oiyarbepsy (talk) 00:03, 6 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
  ^talk_contribs
  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.

• Support as proposer.—
  Chat
  :Online 15:24, 3 September 2015 (UTC)

• Magic words that could be used for this purpose already exist: NONEWSECTIONLINK and NEWSECTIONLINK. Cenarium (talk) 16:57, 3 September 2015 (UTC)

  Fair enough.—

  Chat

  :Limited Access 17:19, 3 September 2015 (UTC)

@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)

• Comment: any subpages of
  Wikipedia talk:Articles for creation need to be excluded are they are article drafts. BethNaught (talk
  ) 21:11, 5 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)

• Comment 2 We already have Category:Non-talk pages that are automatically signed Oiyarbepsy (talk) 23:55, 5 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

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.—

Chat

: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.

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)

Hello everyone. There have already been discussions for a temporary logo to celebrate 5 million articles (

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).

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)

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? ~

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.

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

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

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.

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

Fu7ラジオ

❂In the Republic of China 103rd.民國103年 14:28, 13 November 2015 (UTC)

• I think your signature is a bit big! Try making font a bit smaller. Graeme Bartlett (talk) 07:43, 14 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)

• @
  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,.--JohnBlackburne^words_deeds 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)

• @
  WP:NACs. I think it is quite odd that one dies not exist (at least that I have been able to find over the years.) Steel1943 (talk
  ) 19:04, 16 November 2015 (UTC)

• Is
  WP:BADNAC not it? Ivanvector 🍁 (talk
  ) 19:10, 16 November 2015 (UTC)
• @
  WP:BADNAC as Ivanvector pointed out. But an editor doing this will only get their hand slapped. Admins would (and should) lose their bit. --NeilN ^{talk to me}
  19:23, 16 November 2015 (UTC)

• @
  WP:BADNAC needs a bit of polish to list consequences, then maybe get the page promoted to policy? Steel1943 (talk
  ) 19:27, 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)

• @
  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. –Davey2010^Talk 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.
  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

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)

• Huh.
  WP:DRVPURPOSE specifically says that overturning a prior deletion if new information has come to light is one of the reasons somebody may file a deletion review. I've seen such requests frequently on that page.Jo-Jo Eumerus (talk, contributions
  ) 15:09, 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)

• I have restored it. After 8 years a totally new CFD would be appropriate if people don't want it. Graeme Bartlett (talk) 07:40, 14 November 2015 (UTC)

• However if no one want to use it it could be chopped. Graeme Bartlett (talk) 07:42, 14 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)

• Support. Gamaliel (talk) 17:01, 29 October 2015 (UTC)
• Support without reservations.John Carter (talk) 18:39, 29 October 2015 (UTC)
• Support. But I think I'm missing the background/ context to that example. To me it looked like it could easily be interpreted as funny/ ironic. Or is this intended mainly as a sexist abuse filter? Martinevans123 (talk) 18:53, 29 October 2015 (UTC)
• Support. Excellent idea. Sarah ^(talk) 19:04, 29 October 2015 (UTC)
• Nice sentiment. Of course we want to prevent abuse, but the edit filter is a relatively blunt tool, with a high chance of catching false positives on talk pages. What exactly is the test being proposed? -- zzuuzz ^(talk) 19:07, 29 October 2015 (UTC)
• Not possible If regular expressions could identify abuse, what a world that would be. Rhoark (talk) 19:40, 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: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
  '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)
  • "Possibly problematic talk page edit?" Andreas JN466 06:07, 1 November 2015 (UTC)
    • Why don't we do what everyone else does and have Butters read all the talk page comments, filter out the mean ones and then provide printouts?[16] --16:28, 3 November 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
  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.
  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.
  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.

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,.

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.

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.

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)
          • That is true, Opabinia regalis, but I think that's normal – it's very early days. Thryduulf's idea below has merit. Andreas JN466 23:51, 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.--JohnBlackburne^words_deeds 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)

  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
  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!. –Davey2010^Talk 23:50, 26 November 2015 (UTC)

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 () "é".

(Actually, since ÁÉÍÓÚ are

Irish Gaelic

alphabets, there're simpler combinations:Option+A/E/I/O/U )

• Option+` produces " ` "; (Option+`)+A produces () "à".
• Option+6 produces " ê ", (Option+6)+E produces () "ê".
• Option+8 produces " ¨ "; (Option+8)+E produces () "ë".
• Option+0 produces " ¯ "; (Option+0)+O produces () "ō".
• Option+W produces " ˙ ", (Option+W)+M produces () "ṁ".
• Option+C produces " ¸ "; (Option+C)+S produces () "ş".
• Option+N produces " ˜ "; (Option+N)+E produces () "ẽ".
• Option+K produces " ˚ "; (Option+K)+A produces () "å", (Option+K)+O produces () "ø".
• Option+V produces " ˇ "; (Option+V)+Z produces () "ž".
• Option+M produces " ˛ "; (Option+M)+U produces () "ų".
• Option+L produces " - "; (Option+L)+L produces () "ł".
• Option+T produces () "þ"; Option+D produces () "ð".

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)

NOTHING TO SEE HERE, MOVE ALONG

not really a proposal, not really clear what it was even about, referred elsewhere for future reference

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)

@

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

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)

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)

Hello. Anyone who reads this message is invited to voice their opinions on the

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

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

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)

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

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

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)

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)

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)

I have created template {{

@

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).

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.

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)

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

talk

) 11:02, 4 December 2015 (UTC)

This is

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).

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)

@

Merry Christmas!: ...And a Happy New Year!

) 17:10, 16 December 2015 (UTC)

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)

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

• 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)

Hello. You are invited to comment on this RfC concerning clerking at RfA:

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)

I suggest that we make it possible for users (maybe the same as

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)

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)