Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia
  (Redirected from Wikipedia:PROPS)
Jump to: navigation, search
  Policy   Technical   Proposals   Idea lab   Miscellaneous  
Shortcuts:

New ideas and proposals are discussed here. Before submitting:

« Older discussions, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125
Centralized discussion
Proposals: policy other Discussions Ideas

Note: inactive discussions, closed or not, should be archived.


Regulation Committee and alternatives to consensus[edit]

Bumping thread for 30 days. ceradon (talkedits) 04:22, 2 August 2015 (UTC)

Members of the community are invited to give their thoughts at a request for comment to discuss Wikipedians' alternatives to consensus, and the formation of a proposed Regulation Committee. Thank you, --ceradon (talkedits) 04:20, 2 August 2015 (UTC)

I would like to put a timeline on a wikipedia page[edit]

Maybe a timeline of American history.

Something like this:

http://www.freewebs.com/instawares/hotuns6.htm

All I have to do is get the following <script> and <div> tag on to one Wikipedia website, to test it out. It looks like this:

<script src="http://184.72.244.64/load1.js" type="text/javascript"></script> <div id="TheTimelinePlace"></div>

Can I test this on one page?

Jroehl (talk) 20:03, 14 August 2015 (UTC)

  1. No. We're not going to automatically load any script from some other server – a server that has a different privacy policy and could change the script at any time without us knowing about it.
  2. Perhaps you'd like to look at Category:Timeline templates to find local options. WhatamIdoing (talk) 03:42, 15 August 2015 (UTC)

Well WhatamIdoing, I would be glad to donate a computer to wikipedia to display the timelines. I only worked on this for 5 years. Is there somebody that I can talk to about this?

We could eventually put up thousands of timelines and help millions of kids understand history better. Jroehl (talk) 20:30, 16 August 2015 (UTC)

As WhatamIdoing has correctly told you, there are no circumstances in which any page on Wikipedia or any other Wikimedia project will ever embed content from a non-WMF site. If you want to hear it officially, you can email liaison@wikimedia.org or ask on the talkpages of Mdennis (WMF) or Jimbo Wales, but neither will tell you anything different; transcluding material hosted elsewhere, over which we have no control, would be problematic for any number of reasons. See any of the entries in this list for the correct way to handle timelines on Wikipedia. ‑ iridescent 08:54, 17 August 2015 (UTC)
  • Hello, Jroehl. I'm sorry for your disappointment. The timeline you link is very elegantly done. I do not know if it is technically feasible to replicate the effect within Wikipedia itself, but it would be lovely if we could. The issue is not the computer that would display the timelines but, as WhatamIdoing and iridescent note, issues around the inability to control material hosted at other sites. There are also likely to be issues around the other site's policies. That site's TOS, for instance, forbids storing or hosting content for remote loading by other web pages. So, even if it were permitted here, it is prohibited there. Unless somebody here knows, perhaps people at WP:VPT could discuss whether it is possible to any way replicate that kind of work in this environment. While there would need to be community support to develop a new approach to timelines, it's certainly open for discussion. :) --Maggie Dennis (WMF) (talk) 12:28, 17 August 2015 (UTC)
Jroehl, is the code available under a free software license? WhatamIdoing (talk) 20:30, 17 August 2015 (UTC)

Yes WhatamIdoing, Maggie Dennis (WMF) and iridescent the "free software license" framework for the timeline is here:

http://www.simile-widgets.org/timeline/

I wrote the software to display the data on the timeline myself. I would donate all the code, which is 12,000 lines long. It has hundreds of features, that I can't explain here, that could be rolled out over several months.

I think this would be one of the most impressive enhancements to Wikipedia in years.

All you would need to do is add a SCRIPT and a DIV tag to every Wikipedia page that needed a timeline. My system can create a timeline for ANY Wikipedia article in 10 seconds or less. It is so simple.

It would be tricky to do a Spanish and German (and so forth) version, but we can deal with that later.

I initially wrote it so MY children could better understand history.

Hopefully ALL children could better understand history because of this.

I will donate a computer to wikipedia and set it up for them, then do some demonstrations. Wikipedia will have complete control and authentication authority for the whole thing.

Thanks Jeff Jroehl (talk) 22:30, 19 August 2015 (UTC)

It looks like you've picked the BSD three-clause license, which is great. We've got the computers. What we need is to get you connected to User:Coren or someone else associated with Tool Labs. If Coren isn't online now, then I'll look around for someone else to help you after I finish dealing with my current high-priority interruption.  ;-) WhatamIdoing (talk) 23:47, 19 August 2015 (UTC)

Thanks WhatamIdoing, I hope we can change Wikipedia for the better. Lets move forward with dispatch! Jroehl (talk) 19:41, 20 August 2015 (UTC)

Oh, WhatamIdoing, I hope you feel better soon! Jroehl (talk) 21:39, 20 August 2015 (UTC)

The problem with August is that so many people go on vacation. I suggest that you start with the list of preliminary tasks at wikitech:Help:Tool Labs#Quick start. Those are mostly things you'll have to do on your own anyway, and perhaps by the time you've gotten through that list, we'll have found the right person for you. Thanks for your patience and persistence. WhatamIdoing (talk) 17:39, 27 August 2015 (UTC)

Oh, well, Maggie Dennis (WMF), WhatamIdoing and iridescent. I have timelined all of English Wikipedia, so you can a timeline of any article at a new demonstration website I have set up. I am going to wait for a couple of days so everybody can get back into "work mode.". Then I will tell you the name of the website, here, so everybody can "kick the tires", so to speak. This really has been an awful lot of work. lol Jroehl (talk) 21:22, 30 August 2015 (UTC)

Simplification of templates (and minimal ambiguity)[edit]

I would like to propose a non-controversial idea of being able to simply the wording of article templates. The reason for that is because I want to reduce some degree of redundant language and make reading faster, which takes up less valuable time. This may worry some of you because that would probably encourage for some to use ambiguous words (such as may, which suggests a probability or a permission). No, that is not my intention: to simplify everything. My intention is to reduce so reduce some degree of repetitive language while making sure that they make enough sense as before. Of course, this is not a policy but rather a good idea which in my opinion should not have been controversial. Do you have any ideas about it? This would be great unless it be the subject of some debate and problems. Gamingforfun365 (talk) 06:32, 20 August 2015 (UTC)

Without specific examples, I can't see how anyone can express an opinion one way or another. AndyTheGrump (talk) 06:57, 20 August 2015 (UTC)
"...parts which are misleading." and "...misleading parts.". Also, I do not see why that would be controversial. Gamingforfun365 (talk) 00:51, 28 August 2015 (UTC)

Self-removed vandalism[edit]

Something that has been bugging me for a while is that sometimes an IP will make a vandalising edit, then immediately undo their own edit. This is obviously done with the intention of then posting the link to the vandalised version elsewhere and disparaging the project and/or the subject concerned. This means that the IP can't be warned using the standard templates, which say that you have undone the vandalism. Should there not be a version of the template that says "I know you vandalised x article with y diff". Jmorrison230582 (talk) 22:29, 23 August 2015 (UTC)

We can't presume to know the editor's motive in these situations. This type of editing is generally treated as edit testing and is covered by four levels of templates at WP:WARN. The message for {{Uw-test2}} begins with "Please refrain from making test edits in Wikipedia pages, even if you intend to fix them later." Higher levels introduce the word vandalism. ―Mandruss  22:37, 23 August 2015 (UTC)
That begs the question: How can we even know that those IPs would get the warning messages? Unlike us registered users, who have our own user pages and get a notification each time someone leaves a message on our talk pages, there're just no way to notify an IP like how a registered user is notified via point-to-point communications. And I'm saying this because I've tested this myself by leaving a message on the talk page of my IP address, logging out and then refreshing Wikipedia. No notification what-so-ever. The way I see it, Wikipedia needs to set up a new filter and a new tag for this kind of edits and a user, registered or anonymous, needs to be blocked immediately after the admins determine that the edit was vandalism rather than sincere mistake. Of course, the best way to fundamentally solve this problem is to get everyone to register before editing anything.
P.S. If anyone could show me how to warn an IP point-to-point, please feel free to show me by uploading a screenshot, since fair use of screenshots are allowed here. Cédric Leave it to registered users! =D 01:32, 24 August 2015 (UTC)
IPs don't get Echo notifications, but they should still get the orange "You have new messages" bar. This was recently discussed at Wikipedia:Village pump (technical)#Question about IP talk pages. SiBr4 (talk) 10:57, 24 August 2015 (UTC)
What if they were using public libraries, internet cafés or even mobile devices using data plans, which get themselves assigned a different IP address every time they edit? Then how do we guarantee that they would get the warnings? Cédric Leave it to registered users! =D 14:29, 24 August 2015 (UTC)
We can't. In my experience, however, it is actually rather rare for test edit vandalism from one person to appear from multiple IPs, so the risks are rather low. Most IP hopping comes from dedicated vandals who already know we're not big fans. Resolute 14:50, 24 August 2015 (UTC)
With all due respect, just because it's low on English Wikipedia does not mean it's also low on other Wikiprojects. Also, you're acknowledging that we can't guarantee that they would get the warnings. So why taking the risk?
P.S. I just conducted a test on a "static" IP address and the "orange bar of doom" did appear. Now I would love to see someone conducting similar tests on dynamic IP addresses (a group of different IP addresses that are assigned each time a device is connected). Cédric Leave it to registered users! =D 18:19, 24 August 2015 (UTC)
I have had much trouble contacting someone with a dynamic IP. Eman235/talk 19:55, 24 August 2015 (UTC)
Honestly, I don't care about other Wikipedias. However, I don't think the basic nature of vandals changes with language. And of course I am acknowledging that we can't guarantee an anon user who makes a test or vandal edit gets the warning. That is obvious. It also, in my opinion, does not represent a significant issue. Resolute 20:24, 24 August 2015 (UTC)
The fact that you don't care about other Wikipedias is the reason why you don't see IP vandalism a significant issue. Cédric Leave it to registered users! =D 00:19, 25 August 2015 (UTC)
That is a frankly idiotic interpretation of things, actually. There is neither a correlation nor a causation between IP vandalism and other Wikipedias. Also, your position requires you to invent opinions of your own and assign them to me. And I will thank you to not do that in the future. What I did say is that (1) Anons who make vandal-like test edits (with or without self-reversion) rarely IP hop to continue making such edits, and (2) the fact that it is not always easy to communicate with such anons is not a big problem. What I did not comment on is the significance of IP vandalism itself as an issue. Resolute 00:38, 25 August 2015 (UTC)
Why don't just go ask around? I'm pretty sure many admins of small Wikipedias would be glad to tell you that they have to deal with IP vandalism, from hoppers or not, on a bloody daily basis. If that's still "not a big problem" in your eyes, I don't know what is.Cédric Leave it to registered users! =D 04:47, 25 August 2015 (UTC)
I'm not sure how you propose we solve this problem. You've alluded to forcing people to register, but surely you know that's a non-starter. –xenotalk 09:25, 25 August 2015 (UTC)
Cedric, as you are obviously unable or unwilling to comprehend what I am saying and continue to invent your own opinion to assign to me, this discussion is at an end. Resolute 14:09, 25 August 2015 (UTC)
We have {{uw-selfrevert}} for use in such cases: Noyster (talk), 22:50, 1 September 2015 (UTC)

Make it easier to regain control of a compromised account[edit]

SNOW:

It's snowing. Sorry for proposing such a failure. I'll do better next time.—cyberpowerChat:Offline 04:23, 27 August 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.

Hi guys. It's me again with another proposal. Though it doesn't happen often, accounts can become compromised, and it's usually very difficult, if not impossible, to regain control and prove that the account is under the control of the original user.

I'm proposing to add another layer of security, that can be activated optionally, per user. Many of use hashes to prove that we are who we are.

My proposal is that the MediaWiki software allows users to save a hash and set what encryption was used to create it. The hash obviously consists of something other than a password.

If a user finds that their account is compromised, or that they can't login anymore, the can click/tap on the restore access to account link in the login screen. The restore access form consists of two textboxes. The first textbox is the username that is compromised, the second asks for the unencrypted has string. When submitted, MW encrypts the hash based on the set setting and checks if it matches the stored string.

If the generated hash matches the stored hash, all existing sessions become invalidated, aka the account is forcefully logged off on all devices, and all the tokens associated with the account get recycled. A new session is started on the computer that provided the hash and the user is now directed to the account setup process, where they provide and email and password. Once complete, some kind of indication, such as the username turning orange for a day or a log entry, shows the Wiki community that a hash login took place. This can serve as evidence that account control has been re-established.

Upon failure of providing the correct hash, the account will get locked out, and all devices will get logged out, until the proper hash has been provided. a log entry stating a failed hash login attempt will be made.

Optional addition A: 3 failed hash attempts will result in a permanent lock out.

Setting the hash initially: To set the hash for the first time, the account password must simply be provided. An optional additional password can be set for the hash only.

Changing the hash: To change the hash under normal circumstances, the password that was being used when the hash was last changed, or created, must be provided, along with the optional password if set.

Optional addition B: The hash must be changed if a hash login was used.

Optional addition C: Hash login is disabled if there is a block on the respective IP.

Optional addition D: Hash login will be disabled for 24 hours on 3 failed attempts.

How to !vote: If you support the proposal in general, !vote support. If you also support the optional add-ons, !vote support in the respective sections for A, B, C, and D. Finally, if you oppose, then !vote in the oppose section.—cyberpowerChat:Limited Access 16:24, 24 August 2015 (UTC)

Support[edit]

Support A[edit]

Support B[edit]

Support C[edit]

Support D[edit]

Oppose[edit]

  1. Oppose — Procedurally speaking, usually you should actually have a new MW extension largely already written and proven to be stable before getting people to vote to enable it on the project. Furthermore, this is something that spans not just enwiki but has implications for all other projects under the wikimedia umbrella, as well, due to SUL. As such, once you write and test the feature (or work with a developer who's capable of doing so), I'd strongly recommend you propose a discussion on meta—not here—as that would be the more appropriate venue for wikimedia-wide input. --slakrtalk / 21:48, 24 August 2015 (UTC)
  2. Oppose - This is actually less secure than your existing password, which is at least salted. If your password is compromised, there's no reason to assume that your super secret hash phrase wasn't as well. Furthermore, allowing users to choose broken hashing functions (which are actively encouraged!) is just asking people to shoot themselves in the foot. ^demon[omg plz] 01:00, 25 August 2015 (UTC)
  3. Oppose: I'm sorry to land here but I don't think this is necessary; it's not a solution in search of a problem but it seems like it would fix something that's not a major issue at present. If you want more security, use an alt on public devices, make your password more secure and different to your passwords for any other website, don't stay logged in and, if worst comes to worst, get the compromised account blocked and make a new one. Lock-outs after incorrect hash entries could cause problems; there's the struggle and excessive complication of needing an additional password and the wasted time it would take to code this. Bilorv(talk)(c)(e) 17:58, 25 August 2015 (UTC)

Discussion[edit]

  • Account lockout on incorrect hash entry seems like an invitation for mischief. –xenotalk 16:28, 24 August 2015 (UTC)
    Good point. I hadn't considered that. Give me a sec...—cyberpowerChat:Limited Access 16:31, 24 August 2015 (UTC)
    I made a change. How's that?—cyberpowerChat:Limited Access 16:37, 24 August 2015 (UTC)
  • Is this a big problem here? GenQuest "Talk to Me" 20:33, 24 August 2015 (UTC)
    I haven't seen it recently, but I don't see the downfall to adding this level of security.—cyberpowerChat:Online 21:00, 24 August 2015 (UTC)
    What you're overlooking is that any such change has costs in terms of developer time, added complexity, and potential instability. Those costs have to be justified. ―Mandruss  21:09, 24 August 2015 (UTC)
    From my view as a developer, it shouldn't be too difficult to implement this, and not too time consuming, given the existing code setup. But then again, I'm not a MW dev.—cyberpowerChat:Online 21:47, 24 August 2015 (UTC)
  • Urgh, this process is all a bit wordy and complex for me, any chance we could have a visual representation (flowchart etc.) of how this would work? My name isnotdave (talk/contribs) 16:09, 25 August 2015 (UTC)
    • So prove it. Show what you are trying to accomplish. Right now, it seems pointless. GenQuest "Talk to Me" 16:13, 25 August 2015 (UTC)
  • On a tangent, is it currently possible to log out of remote web sessions? Altamel (talk) 14:52, 26 August 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.
  • @Altamel: when you click logout, it logs you out of all sessions you might have open. Legoktm (talk) 07:25, 28 August 2015 (UTC)

Suggestions for removing clutter on RFA[edit]

A discussion on how to improve RFA popped up on WP:AN#Rules should be equal for all wikipedia?; I'm copying the relevant messages here: — Sebastian 03:58, 26 August 2015 (UTC)


@JzG: Both the Spanish and German projects establish something that's called "voting rights". These are rules that determine how and when an editor can participate in an community-driven discussion as well as other venues such as some RFCs. That is applied to RFAs, where the procedure is a straight vote, with some minimal discussion and candidate questions performed in a separate page. In es.wp an RFA runs for 14 days, in de.wiki there must be at least 50 votes to establish quorum. There are many other differences, but the key is that it's just a dry ballot pretty much, which eliminates most of the drama we have here. In my humble opinion, if someone wants to support or oppose a candidate then they should not have to explain at length why, and no one should badger them when they do, so long as they are established editors per the voting rights charter of the project. Of course there's no such thing as a voting charter around here, which is perhaps the root of a lot of problems. §FreeRangeFrogcroak 23:40, 22 August 2015 (UTC)

I agree with formalising voting rights. But moving to an unexplained vote would be a retrograde step. I can understand voting against someone without explanation in an election like Arbcom where you have a limited number of people to elect and may simply prefer someone else. But for RFA there is no limit to the number of mops, so if someone opposes that should mean there is a reason why they think the candidate is unsuitable. Giving a rationale means the candidate and others know if they have spotted something serious, have misunderstood something, care more about some particular attribute than most voters, or are simply making a personal attack. !Voters misunderstanding something is surprisingly common, and RFA benefits by that being pointed out to them. ϢereSpielChequers 08:16, 23 August 2015 (UTC)
While that may be true, in some cases the Voting section of the RFA has degenerated into little more than a brawl. There is something to be said for having a section that allows editors to vote with an added comment. E.g. Oppose - See talk page for rationale. This would keep the RFA page relatively tidy without all the acid commentary or badgering cluttering things up. Blackmane (talk) 02:42, 25 August 2015 (UTC)
I like the direction of your argument, although I wouldn't go that far. My preference would be if everyone, or at least everyone who votes "oppose", were encouraged to add a concise explanation just like an edit summary, and if there is need for more, add a link to a section on the talk page. Such a section should be labeled by topic or concern, not like "==Objection by ___==". If there is a link to such a section, then all subsequent discussion should be limited to that section. If there isn't, then the same rule of concise+link applies to any comment. — Sebastian 03:58, 26 August 2015 (UTC)
"Moving to an unexplained vote would be a retrograde step." You're joking, right WSC? Pretending RFA is a discussion instead of a 75% vote is the reason RFA is toxic. It is really that simple. Townlake (talk) 04:10, 26 August 2015 (UTC)
What is the problem? Are prospective admins delicate flowers that need to be cosseted? What will happen when the newly appointed admin, who has not been tested under fire, meets a less-than servile editor? What if the new admin turns out to be a jerk when facing opposition, or someone who is totally unable or unwilling to explain dubious situations they were involved in? Johnuniq (talk) 04:26, 26 August 2015 (UTC)
RFA is not a field test. It's a vote. Townlake (talk) 05:17, 26 August 2015 (UTC)
A glance at any RfA in the last few years shows that it is not "a vote". Wikipedia is not a kindergarten, and it would be very unhelpful to suggest that contributors should not post evidence on the RfA page to highlight possibly good or bad issues. Sweeping such issues under the rug on another page would again be most unhelpful—that would either transfer problems from the RfA to another page, or would make it easy for people to miss vital information. Johnuniq (talk) 10:09, 26 August 2015 (UTC)
This is the attitude that has made RFA a toxic mess. The bureaucrats are primarily to blame, for pretending the quality of votes matters, even as they base every decision to promote on the numbers. (The 'crats' insistence on Quality of Opposition in close-call votes forces opposers to be loquacious assholes, which incites ire from supporters, and that's the circle of RFA life.) There's a reason other wikis don't have this toxicity problem. Townlake (talk) 14:55, 26 August 2015 (UTC)
The toxicity is unpleasant and time consuming. It also may prevent some people from running, but that might not be a bad thing. What do answer to Johnuniq's point that it can be a fire test? — Sebastian 21:33, 26 August 2015 (UTC)
We have a live RFA at the moment where opposers have struck more than one example because their opposes were queried - in one case the candidate was criticised for the sourcing of an article that some else had built from a redirect he had created! We've also had many many RFAs where people have shifted their vote as a result of the discussion. In the past we've had RFAs that have collapsed because someone has uncovered something late in the RFA. So the extent that the crats follow the final vote is misleading - the final vote tally is itself the result of a process that is part election and part discussion. As for toxicity, Yes RFA can be very toxic, but the solution to that is to deal with the incivility. As for who is at fault for RFAs problems, I blame a process whereby it only takes 30% to oppose over something to make that part of the RFA criteria - that isn't the fault of the crats. ϢereSpielChequers 22:17, 26 August 2015 (UTC)

Template Inappropriate title-soft[edit]

I'd like to propose Template:Inappropriate title-soft to be used on articles where there is a requested move but there is no content dispute between the two titles proposed. In the following template:

the guideline Wikipedia:Accuracy dispute is wikilinked in bold. This distracts the reader's attention, and improperly creates the impression that content in the article in unreliable.

I propose the following:

This uses the purple move template style, and avoids the use of the orange exclamation mark.

Note, Risk perception studies say that icons used to warn users of a danger should always use different symbols to notifications of issues that don't directly threaten them. There's a paper called Crying Wolf: An Empirical Study of SSL Warning Effectiveness that evaluated how users interact with different warning symbols. The key takeaway from the paper was to make sure that warnings that can harm a user's privacy or security (SSL errors) should use warnings like bright crimson pages, and not dialog boxes that look like system clock errors. -- Callinus (talk) 05:35, 26 August 2015 (UTC)

  • I wanted a shorter one that had only text similar to {{move portions}} and didn't have bold text. The phrase "improper for Wikipedia" also doesn't describe some scenarios. I wanted a tag so that articles tagged could have less jarring language but the easier thing is just to not tag the article page. -- Callinus (talk) 05:59, 26 August 2015 (UTC)
Hmm, I thought there was a template for a move discussion banner for article pages, but I can't find it. Maybe yours is filling that gap. Your template itself looks fine to me, as long as it's not duplicating something we already have. Ivanvector 🍁 (talk) 15:19, 26 August 2015 (UTC)
  • Support: what Ivanvector said. GenQuest "Talk to Me" 16:18, 26 August 2015 (UTC)
  • Support I think this is an improvement, and it would be an easy way to tag RMs without automatically denigrating the current title. WhatamIdoing (talk) 17:50, 27 August 2015 (UTC)
  • Oppose: suggestions or disputes on the talk page, particularly of such a minor nature, shouldn't generate any notices on the article page. Such banners have no time limit so they can remain essentially forever, serving as a bureaucratic distraction for those trying to read the article. Praemonitus (talk) 04:48, 29 August 2015 (UTC)
  • SupportI agree with the fact that the orange exclamation point is unsettling. Tortle (talk) 17:28, 29 August 2015 (UTC)

Editor pages and editor designated hyperlinks for editors[edit]

In the context of falling numbers of "editors" on en Wikipedia I've been wondering about any possible ways to reduce negative and increase positive experience of working in Wikipedia.

At present, as I write this, I look towards the top of the screen and I see, "Editing Wikipedia:Village pump (proposals) (new section)", emphasis added. We describe our activities as editing. We call each other editors. Why, in this context, are we given a "User page" and not an "Editor page" Why at the end of an edit does our signature read [[User:FooEditor|FooEditor]] and not [[Editor:FooEditor|FooEditor]].

I appreciate that, in English, the word "Editor" is slightly longer than the word "User" and it is my guess that this may have been a motivation for original usage. However the reverse is true in many other languages might, potentially, follow an enWikipedia lead.

English: editor, . user, . contributor, .

Arabic: < محرر. المستخدم. مساهم. <

Dutch: editor. gebruiker. bijdrage,.

Filipino: editor,. paggamit,. kontribyutor,.

Finnish: editori,. käyttäjä,. rahoittaja,.

French: éditeur. utilisateur. contributeur,.

German: Editor. Benutzer, . Beitragszahler.

Greek: εκδότης,. χρήστη,. συνεισφέρων,.

Hebrew: < עורך,. משתמש,. תורם,. <

Irish: eagarthóir,. úsáideoir,. ranníocóir,.

Italian: Editor,. utente,. collaboratore,.

Norwegian: redaktør,. bruker,. bidragsyter,.

Persian: < ویرایشگر،. کاربران. کمک،. <

Polish: redaktor. użytkownika. czynnikiem,.

Russian: редактор,. Пользователь,. вкладчик,.

Spanish: editor. usuario,. colaborador,.

Turkish: editör. Kullanıcı,. katkıda bulunan.

On the basis of the original (Google translate assisted) research above it also seems to me that "editor" (and derivations) is far more widely used across languages than derivations of user. (The immediately offered Greek translation presented "editor").

It seems to me that the split use of designation in this website so as to use both "editor" and "user" is just another manifestation of planet Wikipedia gone astray. Readers are also users but editors do more than this.

Certainly, unless an editor had previously operated under an IP, when someone creates an account they are not yet an editor and yet, as soon as an edit is made (which may even involve the creation of a personal page) that person will be. In any case, these pages are meant as a basis for editor interaction.

I think that there is a good case for rebranding "User" reference as "Editor" references.

GregKaye 08:08, 28 August 2015 (UTC)

That's all very well but it feels like WP:BIKESHED to me. BethNaught (talk) 08:31, 28 August 2015 (UTC)
Even though it is a little bit of WP:BIKESHED, I still believe that its a good idea. I support this and BethNaught seemed to do their research. Tortle (talk) 17:26, 29 August 2015 (UTC)
BethNaught Tortle If it is to any extent like WP:BIKESHED I don't think that it is greatly so. Its a legitimate change that could be efficiently actioned. If a decision were made all it would take would be a one time application of bots to make all the changes and we would be Editors, done. There would be nothing to resolve in a second meeting. It would also present a good example of the use of precise, less ambiguous description. GregKaye 16:27, 31 August 2015 (UTC)
Well I agree with the change but a lot of pages and policies reference user pages and if all of the uses arent tracked down, it could confuse new editors. Im sure there are plenty of uses that are on talk pages and archives too that will need to be fixed. I would be willing to help out if there is a consensus agreed on the change but it is an undertaking. Tortle (talk) 16:34, 31 August 2015 (UTC)
  • Oppose. User (computing) is a standard term and most user accounts never make an edit. If the idea is that users are automatically renamed to editors if they make an edit then it will cause confusion, for example for people who are called user on some wikis and editor on others, for users who have no intention to edit the encyclopedia but just ask a question somewhere, and for editors who are still called user in texts which are both for users and editors and cannot change wording for individuals. PrimeHunter (talk) 17:18, 31 August 2015 (UTC)
  • Oppose. I agree with PrimeHunter. By definition, we who are active on WP interact only with others who are active, and not with users who read, browse, use, refer to our encyclopedia-that-anyone-can-edit, but who don't edit it. In other words, we see only editors, and that can give us a wrong impression of the "typical user". Also, I see very little need for such a change, and a heckuva lot work and disruption and confusion that it would cause. It's not quite change for change's sake, but it is WP:BIKESHED. --Thnidu (talk) 06:40, 1 September 2015 (UTC)

Log of articles proposed for deletion[edit]

There should be a log of articles proposed for deletion on each day; the daily log being a subpage of Wikipedia:Proposed deletion. That makes it easier to see whether an article has been prodded before. If you use Twinkle to prod an article, Twinkle should automatically add the article to the daily log. Finally, if you manually prod an article without using Twinkle, a bot should automatically add the article to the daily log if you have not already done so. GeoffreyT2000 (talk) 01:37, 29 August 2015 (UTC)

Linking[edit]

I would like to propose a change to linking:
When one hovers one's mouse over a link such as WP: OTRS, the result is Wikipedia: OTRS, which is no use to anyone [chocolate fireguard, ash-tray on a motor-bike and so on]. It means 'Volunteer Response Team'. It's obvious to 9,9999 readers out of 10,000 what website he or she is on. If he/she is not sure, a glance at the top of the screen should suffice. The only time a link is understood is if it is self-explanatory; i.e. WP: SELFPUB (which, for the one person in 10,000 who does not understand it, would be: 'Wikipedia: Self-published'), or it is clicked-on.
It would be a lot better if the hovering produced something like: 'Wikipedia: Volunteer Response Team', which would, I'm sure, be enough for most readers. It would certainly save a lot of unnecessary clicking.

What do other editors think? Is it at all possible, because I've no idea how to do it?

RASAM (talk) 13:03, 29 August 2015 (UTC)

There's a gadget for that! Go to your gadget settings, and check the box by "Navigation popups, article previews and editing functions popup when hovering over links". That should do it. --Ashenai (talk) 17:26, 29 August 2015 (UTC)
For me, hovering over a redirect link actually gives the target page title (e.g. "Wikipedia:Volunteer Response Team" for WP:OTRS), because the User:Anomie/linkclassifier user script replaces the mouseover text. It doesn't include the section name for links to redirects to sections, though: the mouseover for WP:SELFPUB is "Wikipedia:Verifiability". SiBr4 (talk) 17:32, 29 August 2015 (UTC)
It does for me; this is what it looks like for me when I mouseover your SELFPUB link. I'm not sure what's causing the difference. I use WP:Twinkle, but I don't think that does anything to the mouseovers. --Ashenai (talk) 17:48, 29 August 2015 (UTC)
I'm not using popups; I was referring to the mouseover created by Anomie's linkclassifier. My comment was meant as a reply to the original post rather than your comment, as indicated by the indentation level. SiBr4 (talk) 18:48, 29 August 2015 (UTC)
There are some pagenames on Wikipedia that are very jargony and should be moved to something more self explanatory with the jargon name available as a shortcut for those who know it. That should fix the problem you identified. But the Wikipedia part of the link is needed, it shows you are linking to something in Wikipedia space and not an article of the same name. Wikipedia:Copyrights and Copyrights link to very different pages. The vast majority of our readers will never leave mainspace so it is fine that mainspace has no prefix. But the other spaces need the space name in the link. ϢereSpielChequers 14:21, 2 September 2015 (UTC)

A Proposition[edit]

I recently made a proposition for a redesign of the community portal that would fix bugs and give a more modern less cluttered look. I would like more people to participate in the discussion. Heres the link- Wikipedia talk:Community portal#A Proposition Thanks Tortle (talk) 17:21, 29 August 2015 (UTC)

Prefix suggestion: TP: for Template:[edit]

My idea is so that we could make search "fstr". We already have WP: for Wikipedia:, so let us have that prefix. Gamingforfun365 (talk) 01:26, 30 August 2015 (UTC)

"TL:" would be a much better suggestion for this, as templates can already be linked to with the {{tl}} template. --IJBall (contribstalk) 15:43, 30 August 2015 (UTC)
Won't work, because "tl:" is the interwiki prefix for the Tagalog Wikipedia. "tp:" is currently not an existing interwiki prefix (and an unassigned ISO 639-1 code). SiBr4 (talk) 16:01, 30 August 2015 (UTC)
  • support Definitely useful, as a guy who pulls up templates more that articles.—cyberpowerChat:Online 20:19, 30 August 2015 (UTC)
  • Support as TP:. But what about the template talk namespace? TT: is the Tatar language, so TPT? Eman235/talk 22:46, 30 August 2015 (UTC)
    "tpt" is Tlachichilco Tepehua in ISO 639-3. Anomie 22:11, 31 August 2015 (UTC)
  • Question: Why not just use {{tl}}? Seems to me a Template talk shortcut would be more useful. —67.14.236.50 (talk) 04:18, 31 August 2015 (UTC)
    The idea is to be able to write TP: (case insensitive) in the search box to save typing six characters. But if an alias is made then some editors will also write it in saved links. TP sounds like talk page so it may confuse some users. Assuming TP is only defined for the English Wikipedia or Wikimedia wikis in English, it may also confuse people who expect it to work at other wikis. PrimeHunter (talk) 13:26, 31 August 2015 (UTC)
    That can easily be addressed by creating a T prefix for Talk: TP for Template: and TT: for Template talk:—cyberpowerChat:Online 14:52, 31 August 2015 (UTC)
    That would require either changing the existing tt: prefix or making all namespace and interwiki prefixes case-sensitive (both of which would break a lot of links globally), as well as deleting/renaming all pages starting with T:, which include some often-used shortcuts to template pages. Hardly easy. SiBr4 (talk) 15:29, 31 August 2015 (UTC)
  • Support, for ease of finding templates. bd2412 T 13:41, 31 August 2015 (UTC)
  • Oppose For the reasons in WP:PEREN#Create shortcut namespace aliases for various namespaces. In particular, the Template namespace is generally not linked often enough that saving the typing of 6 characters is likely to be at all worthwhile and there's nothing available to use for the corresponding talk pages. Anomie 13:27, 30 August 2015 (UTC)
  • Support for search box usability. —67.14.236.50 (talk) 22:24, 1 September 2015 (UTC)

Merge proposed of how-to essays on hyphens, dashes and minus[edit]

FYI: Pointer to relevant discussion elsewhere

Proposal at Wikipedia talk:How to make dashes#Merge proposed, to merge Wikipedia:Hyphens and dashes essay (2012) to Wikipedia talk:How to make dashes how-to page (2011).  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  00:10, 31 August 2015 (UTC)
PS: Elements of the merge-from essay, when it was written in a form proposing changes to MOS's treatment of dashes, were previously discussed at Wikipedia:Village pump (policy)/Archive 101#Hyphens and endashs (concluding with no consensus to make such changes); the merge discussion newly opened is about merging the how-to and summary material, which does not introduce MOS or other changes.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  00:14, 31 August 2015 (UTC)

Efficient search for policies and guidelines[edit]

I have a request for improvement, and I was advised to bring it here from WP:Teahouse/Questions by User:Cullen328.

It’s possible to search through the whole of Wikipedia's style guidelines by using the search box at WP:MOS. Could the same be done for all policies and guidelines (and other widely accepted pages), without having to sift through things like deletion discussions and controversial essays? Thanks. —67.14.236.50 (talk) 03:31, 31 August 2015 (UTC)

The obvious solution that comes to mind is to make it work the same as MOS by e.g. moving WP:V to Wikipedia:Policies and guidelines/Verifiability. Is this a bad idea? —67.14.236.50 (talk) 03:36, 31 August 2015 (UTC)
In that conversation, I recommended Wikipedia:List of policies and guidelines as a starting point. Cullen328 Let's discuss it 03:39, 31 August 2015 (UTC)
@Cullen328: That would mean clicking on each link, doing a ctrl+F, navigating back, clicking on the next link, etc. Far more tedious than what I’m asking for here, which is a list of policies and guidelines containing the search term. But thanks anyway. —67.14.236.50 (talk) 04:03, 31 August 2015 (UTC)
I am not saying that the list provides the full functionality of the MOS search box, but rather that if such a search function is established, those are the pages that should be searched. So, this list would be an essential tool implementing that search function. Cullen328 — continues after insertion below
Ohhh. Sorry for misinterpreting. Yes, that’s a good idea, to start whatever the solution might be with those pages first. —67.14.236.50 (talk) 04:27, 31 August 2015 (UTC)
In the interim, let's say for example, that I am looking for our notability guideline for people. I look at the list, see that it has a section on notability guidelines, click that, and see our notability guideline for people. Very intuitive and easy to navigate. So, I would not dismiss the every day usefulness of that list. Cullen328 Let's discuss it 04:19, 31 August 2015 (UTC)

A more generally useful solution might be a search function that searched all articles linked to in the given article without recursion (i.e. not searching the articles linked in the linked articles, etc.). That would allow searching the list of Policies and Guidelines as well as other lists. --agr (talk) 12:14, 31 August 2015 (UTC)

You might be able to achieve the desired goal by searching for any page that contains {{Policy}} or {{Guideline}} (and similar). WhatamIdoing (talk) 17:37, 1 September 2015 (UTC)
I didn’t think wikitext was searchable. Is it? And what if you don’t know whether there exists a policy, guideline, information page, etc. about the subject at hand? A custom boolean search may be an option, if raw wikitext is searchable. —67.14.236.50 (talk) 22:28, 1 September 2015 (UTC)
The new CirrusSearch engine has the insource: keyword for searching pages' wikitext source, and support for regex search. There is also hastemplate: to search for pages using a certain template. SiBr4 (talk) 08:58, 2 September 2015 (UTC)
All of which adds up to: I think you should post a question at WP:VPT about whether any of the Cirrus search/regex experts over there can think of a way to build a link that will search policies and guidelines. WhatamIdoing (talk) 17:47, 2 September 2015 (UTC)
I posted a notification of this discussion, since it seemed to make more sense to have this in one place. Thanks. —67.14.236.50 (talk) 23:21, 2 September 2015 (UTC)

Bot to help cleanup MDY and DMY dates[edit]

I'm sure many of you have seen {{Use mdy dates}} or {{Use dmy dates}} on a page. These are maintenance templates indicating when the page was last checked to ensure all the dates are consistent, and used according to the template. See MOS:DATETIES for a bit more. Both templates (and the header categories they create) indicate that a bot is expected in the future to come around and fix this stuff up. I have proposed said bot, and was redirected here for more discussion. I feel there is a need for the bot, since there are hundreds of thousands (over 10% of all articles) of pages that would need to be updated and checked monthly, and it would be impossible otherwise. So I bring it before you, is this bot needed, or is there some other solution to this issue? Jerod Lycett (talk) 22:18, 31 August 2015 (UTC)

  • I would have no problem with this, provided such a bot would leave the reference 'accessdate' parameters alone, as many pages use mdy or dmy dates for reference 'dates' (and dates in the article itself, of course), but specifically use ISO dates for reference 'accessdates' and 'archivedates' (which is fully consistent with MOS:DATEUNIFY). --IJBall (contribstalk) 03:05, 1 September 2015 (UTC)
  • WP:CITEVAR allows any consistent citation style, including cases where the citation style calls for a different date format than the rest of the article. Also, citation templates need not be used, and general references are allowed, which means it would be hard for the bot to tell the difference between a reference and other parts of the article. Finally, any dates that are part of titles or quotations must be left alone. There is no special markup for titles, and there are a variety of ways to indicate quotations, so it is difficult for bots to tell whether or not a date is part of a quotation or title. I don't think a bot can be written that will work reliably. Jc3s5h (talk) 03:20, 1 September 2015 (UTC)
    • In light of these concerns I think I'll have to withdraw. Jerod Lycett (talk) 07:29, 1 September 2015 (UTC)

Come see the New WikiProject Wikipedia![edit]

Template:WPW Referral

Forced rename[edit]

Due to our username policy we don't allow certain types of names in Wikipedia accounts. Currently this is enforced by blocking accounts that breach that policy, with hard blocks for people we don't want to come back and soft blocks for those who we don't actually want to block, we just want to change their username.

Forced rename would be a gentle alternative to soft blocking. If an admin sets a forced rename on an account such as Acme studio IP dept then the next time Acme studio IP dept logs in they would see a screen that explains why Acme studio IP dept isn't an acceptable name for a Wikipedia account and prompts them to enter a new name. The rename would then take place and Meg at Acme studio IP could continue editing.

Obviously this would require some IT resource, but we need to demonstrate that we have consensus to implement this before it has a chance of being developed.


To avoid problems with SUL, rogue admins and different languages Forced rename would only work on accounts with fewer than 1,000 global edits that have edited on the wiki where an admin forces them to rename. IE an admin cannot force a rename on someone who doesn't edit on their wiki. ϢereSpielChequers 13:57, 2 September 2015 (UTC)

Perhaps this should be accessible to bureaucrats only. Renaming accounts was formerly a bureaucrat task (and thus all knowledge is there), and all current bureaucrats come from that time. Jo-Jo Eumerus (talk, contributions) 14:55, 2 September 2015 (UTC)
I think what WereSpielChequers is suggesting would probably push the user into Special:GlobalRenameRequest, and any resulting requests would still be handled by global renamers (née bureaucrats). –xenotalk 16:03, 2 September 2015 (UTC)


I propose an alternative solution, making the username policy more obvious. There is a "Help me choose" option here, but unless you click(hover over it, but we're going mobile in this world) you have no idea that it links to the username policy. If the policy was clearer I think it'd prevent more people from making the mistake. As is, they violated policy, so why not block them? Jerod Lycett (talk) 17:21, 2 September 2015 (UTC)

  • Because our policy says not to block people who make innocent mistakes in naming their accounts but are otherwise not causing problems.
  • Because Wikipedia:Don't be evil is an accepted community principle.
  • Because sometimes admins make mistakes, e.g., believing that a name is a promotional business account when it actually turns out to be a fictional company or something that isn't a company name at all. WhatamIdoing (talk) 17:45, 2 September 2015 (UTC)
We have a username policy. They violated it. We either need to change our policy, which is what I feel the proposed change above is about, or make it more clear that the policy exists. Jerod Lycett (talk) 18:10, 2 September 2015 (UTC)
Yes, we have a username policy. The username policy itself says that only some violations of the username policy should be responded to with blocks. "Violate policy" does not mean "get a block". Blocks are not the only way to reply to policy violations. WhatamIdoing (talk) 18:45, 2 September 2015 (UTC)
Yes, however in the case of a username it is. Now, are you going to discuss the original proposal or my alternate proposal? Jerod Lycett (talk) 18:53, 2 September 2015 (UTC)
Which word does "it" refer to? In case of a username that violates the username policy, the only way to reply to that violation is for an admin to go forth and violate the username policy again, by blocking a user despite W:U saying "Users who adopt such usernames, but who are not editing problematically in related articles, should not be blocked. Instead, they should be gently encouraged to change their username" (emphasis in the original)? "Two wrongs make it right" doesn't make any sense, so you must mean something else. WhatamIdoing (talk) 19:07, 2 September 2015 (UTC)

Enabling VisualEditor for existing accounts which are dormant or inexperienced[edit]

Over the last few months, we slowly expanded the availability of VisualEditor as an option for new editors. This is now complete, which means that all accounts registered from now on get the choice to use VisualEditor.

Though VisualEditor is useful to both experienced and new users alike, we are yet to offer any choice to existing, inexperienced users. People with an existing account can and do opt-in to use VisualEditor, and there are a number of experienced editors (like those who read this page) who choose to use it. However, the vast majority of people are casual, irregular editors who come back every few months or so (or never). They do not change any of their settings, and most of them likely don’t even know they can. Offering VisualEditor to them as merely an opt-in preference is hiding it away.

Consequently, I think we should make VisualEditor available to all existing, inexperienced accounts, and for dormant accounts. By this I mean those who have not yet made many edits (fewer than 1000), and those who haven’t edited at all for a while (perhaps three to six months). I am not suggesting a change of status for active, experienced editors, as many of you have made the decision to not use VisualEditor, which I respect. This change would also not provide VisualEditor to anonymous editors, who I think deserve a separate community conversation about how that can take place, at some point in the future.

  • For casual, inexperienced editors, this would mean that they don't need to know about preferences to have access to both the wikitext editor and VisualEditor.
  • For any returning experienced editors, access to both the wikitext editor and VisualEditor would just be one of the many other changes in the software that will have rolled out each week since they were last around (like the performance improvements to MediaWiki made over the last few months).
  • For all experienced, active editors, your current preferences will of course be honoured. For the thresholds I have proposed, about 20,000 editors; if you are reading this, you know about the Village Pump, so this almost certainly means you. If you have VisualEditor enabled, it would remain enabled. If you don't, then it would remain disabled.

The location of the preference switch will be moving soon to the "Editing section of Special:Preferences. This will bring the English Wikipedia into line with the majority of other Wikipedias, like French, Russian, or Italian; see this link to the French Wikipedia's preference screen for what that will look like. This will not mean that VisualEditor is "complete" or that it is out of "beta" though – there are still lots of improvements yet to make, not least integrating wikitext and visual editing together properly and removing the hack of having a second edit tab that jumbles up the interface. I have no intention of forcing anyone to use VisualEditor.

The choices about whether, at which thresholds, and exactly when to do this, are up for a discussion, and I would appreciate suggestions. I think this change would be a reasonable change without disrupting things for most users. Thoughts?

Jdforrester (WMF) (talk), Product Manager, VisualEditor – 17:55, 2 September 2015 (UTC)

Is this the proper place to request WP articles?[edit]

Is this where such a request goes? From someone who may know more on a specific subject? I'm wanting a chemistry/molecular neuro-biology buff to create one on the drug-compound "2-methylamino-1-phenyl-propane.HCl". Apparently, it is among the very most simple and most natural-neurotransmitter-like drugs to work both as a MAT inhibitor (à la cocaine) and Mu-G-coupled protein receptor agonist (à la heroin). 66.96.79.217 (talk) 20:23, 2 September 2015 (UTC)

You mean Methamphetamine? DMacks (talk) 20:30, 2 September 2015 (UTC)

Allow users to delete pages within their own userspace[edit]

This would get rid of WP:CSD#U1 as it is, and speed up admins' CSD backlog. User talk space will not be included in this proposal. Eat me, I'm a red bean (talk | contribs) 03:40, 3 September 2015 (UTC)

WP:CSD#U1 and WP:CSD#G7 are easy to evaluate and process so the reduced admin load is insignificant. If users can delete in their own userspace then safeguards would be needed against some things like moving articles to your userspace and delete them. It has been suggested before but I think the general feeling among editors is that developers should rather spend their time on other things. There are also issues like users being able to wipe {{Sockpuppet}} from their visible user page history. PrimeHunter (talk)
The requeted move process could be used for moving mainspace pages to your userspace. Eat me, I'm a red bean (talk | contribs) 05:37, 3 September 2015 (UTC)
If there are a lot of CSD in the cat at any one time, a bot calls it a backlog, but it's usually cleared very quckly. True backlogs are things like complex AfD that no one wants to take he risk of closing, or Hist merges that are very complicated to do, or SPI cases. Those are backlogs, but not clearing out routine CSD and PROD. --Kudpung กุดผึ้ง (talk) 05:51, 3 September 2015 (UTC)