Wikipedia:Village pump (proposals)/Archive 126

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

---

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

Template:Uw-english

I just discovered {{uw-english}} and was quite surprised by its wording: the thing actively forbids non-English comments without translations. It means that you're not allowed to leave an intelligible comment here unless you know English: what a horrid idea! Anyone can run Google Translate on something you've written in another language, but that's apparently not acceptable, because if it were, why would we complain about you doing it? Since that's the case, a {{user en-0}} person shouldn't leave an autotranslated comment either. Yes, it's not helpful for someone to leave a foreign-language comment at an article's talk page, where it might be read by others than the intended audience, and non-English article text is right out, but private conversations on user talk pages and notices on project pages (noticeboards, WP:RD, WP:HD, wikiproject talk pages, etc.) aren't problems. When someone writes an obviously badly translated message at WP:HD or WP:RD, we routinely say basically "Please just write in your original language, and someone will translate it", we actively encourage people to make English-only requests at other languages' Wikipedias if they don't understand the local language, and I've never heard of anyone on any other project to complain (I've even seen WMF staff leave notices in English at other projects!), so why should we object to the same thing here? We should welcome non-mainspace contributions by people who want to help and just don't understand English. Finally, please note that the template links to WP:TPYES, which specifically exempts user talk pages from its suggestions, and anyway TPYES is framed as "good practices" and is actively separated from actions deemed unacceptable.

With this in mind, I have two proposals, which obviously can't both be implemented: either deprecate the current template entirely (i.e. it will be deleted or marked as {{historical}}), or replace the wording with something saying basically "Please write in English if you're able to, because it will help others understand better". I'm proposing this here because it has a good deal more visibility than a template talk page. Nyttend (talk) 17:54, 24 July 2015 (UTC)

WP:SPEAKENGLISH states "It is preferable to use English on all talk pages of English Wikipedia" (emphasis mine). The template should simply use the guideline's unchanged own wording after the 1st intro sentence. This specific guidance has only 2 lines of text and would easily fit in the template to reflect the current consensus. GermanJoe (talk) 18:19, 24 July 2015 (UTC)

Agreed with GermanJoe. A template like this won't be used much except when posting in some not-English is an actual issue. It can be an issue for more than one reason, the two most obvious of which are: a) dominating an article talk page in non-English, to form a WP:FACTION that may try to reach a WP:LOCALCONSENSUS among themselves without the input or understanding of other editors, and b) use of other languages to violate policies like WP:NPA and WP:CIVIL. But even just making it a pain for other editors to figure out what you're posting about and why is kind of problematic to begin with. "People can use Google Translate" applies to the poster, too; those who habitually shift the burden onto all other editors need to, well, stop.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  19:32, 24 July 2015 (UTC)

• If a person is unable to communicate coherently in English, by definition they cannot contribute to a project that is writing an encyclopedia in English, through collaboration amongst English speakers. I know it seems unfriendly, but it is pointless to contribute here if you can't make yourself understood, and we shouldn't pretend that isn't the case just to be nice to the hard-headed type of person who will try to contribute to a project despite being unfamiliar with the language it is written in and that all its business is conducted in. Beeblebrox (talk) 19:54, 24 July 2015 (UTC)
  • It's not about the contributor, but the communication, though. Machine translation can permit any WP:COMPETENT person to contribute, to an extent, regardless of language. I use it frequently on non-English WPs, to suggest improvements to the non-English equivalents of en.WP articles, or to ask for review of our version of theirs. The purpose of the template here on en.WP needs to be to make it clear that the burden of translation is on the non-English speaker, not on all other editors. The purpose of the template is not to say "get lost". :-) This template should probably include a link to an online translate service, actually.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:17, 24 July 2015 (UTC)
    • I can't speak German, but I've made nearly 1000 edits to the German Wikipedia, most of them either involving communication with other editors (talk page chats, or the "Englische Frage" section of [1]) or minor things like modifying templates and adding images. I've not tried to write articles, except for pages like de:Quinter where I just created stubs by changing details from existing articles. As far as I know, nobody's ever objected to my actions over there. If we continue using this template, it needs to be reworked so that it's demonstrably only for the person whose lack of English is causing problems. Nyttend (talk) 21:18, 24 July 2015 (UTC)
  • I've added images to more than a dozen Wikipedias. Also, it's not necessary to speak any English at all to "make yourself understood" to some editors. You've just got to find the right ones.
    Imagine it in reverse: you happen to see a problem at another language's Wikipedia. For example, you notice that they have an image of a pear at the top of the article about apples. You don't speak that language. Can you contribute? I think you could. You could remove the photo, which requires no language skills at all. You could substitute a more relevant one. You could find someone who is active and whose WP:Babel box says that s/he understands English, and leave a note in English about the problem for that person. Any of these would be helpful, and I would welcome such contributions from non-English speakers here. WhatamIdoing (talk) 21:59, 24 July 2015 (UTC)

First off, the text of the template is

I noticed that you have posted comments in a language other than English. When on the English-language Wikipedia, please always use English, no matter to whom you address your comments. This is so that comments may be comprehensible to the community at large. If the use of another language is unavoidable, please provide a translation of the comments. For more details, see Wikipedia:Talk page guidelines. Thank you.

That's hardly forbidding, and in any case nothing forces anyone to use that template. Still, there is room to improve the template. In most cases the poster's language is identifiable and a roughly comprehensible translation can be produced, even if the original poster can't be the one to do it. The template could provide a way to link to a machine translation. It could suggest asking for help at wp:Local Embassy, on their language's wikiproject talkpage, or on their language's WP help page. Sometimes comments here relate to Inter-wiki collaboration. The idea that one would have to write English well in order to contribute by saying "There's a really good source on this topic on the Bengali Wikipedia" is just wrong. Contributions can be valuable without being perfect. We simply need to channel the contributor to a venue that will facilitate the work. LeadSongDog come howl! 20:26, 24 July 2015 (UTC)

I think you have some good ideas about improving it. What do you think about making it say, "please provide a translation of the comments if you can"? WhatamIdoing (talk) 21:59, 24 July 2015 (UTC)

That would be helpful, in my opinion. I'm just afraid of a not-so-competent-in-English editor (whether from another project, or not) getting a message and finding from Google Translate that it's basically a warning. We need to make this template as soft as possible; if someone actively ignores it and causes problems (as noted above) in a foreign language here at en:wp, someone can leave a personalised message in the language in question. Nyttend (talk) 05:07, 25 July 2015 (UTC)

• I certainly think the template as it stands is unhelpful. {{Uw-notenglish}} quite rightly tells editors who have written non-English in the main namespace that this is the English Wikipedia and foreign content should either be moved or translated. But if {{Uw-english}} has to exist at all, it needs to be reworded: "Please try to make comments in English wherever possible—this could be done using a machine translation like Google Translate." would be my suggestion. Maybe a link to Category:Wikipedians by language or an extra parameter to add a specific language to would help: for instance, if one adds a parameter saying "German", the template could link to Category:User de so the user could talk to someone in German. It also occurs to me that there could be little point in putting English text on the talk page of someone who clearly doesn't understand the language; perhaps once a better version of the text to include has been established, we could get some Wikipedians to make foreign translations of the template (e.g. so a user posting in Spanish can get a message in Spanish explaining the issue, rather than an English message that they find completely unintelligible). — Bilorv_(talk)^(c)(e) 18:09, 25 July 2015 (UTC)
• Does anyone here remember using this particular template? WhatamIdoing (talk) 21:52, 25 July 2015 (UTC)

Yes, on a number of occasions. Beeblebrox (talk) 21:53, 25 July 2015 (UTC)

I haven't used it but made a search on "If the use of another language is unavoidable, please provide a translation of the comments", an unchanged sentence since the 2007 creation. There are 2502 results in user talk, and 26 in other namespaces. It's meant for substitution and doesn't have transclusions. PrimeHunter (talk) 23:22, 25 July 2015 (UTC)

Excellent, Beeblebrox. Can you tell me what practical outcome you wanted to achieve by posting that template? If it was different things on different days, then just give me a few of your favorite examples. Also, did it work? WhatamIdoing (talk) 22:23, 26 July 2015 (UTC)

• A startling example of template creep. I've hated it for a long time. Better not to filter out any intended meaning by running it through a machine first. I'd rather see it in a user's first language. Mark Schierbecker (talk) 22:09, 25 July 2015 (UTC)

Yep, if we're going to translate the template, which is an excellent idea, Google is not the way to do it. The acxuracy and coherence of machine translation varies widely depending on the language. For German, it's pretty darn good. Tagalog or Mandarin, not so much. We don't want to be posting gibberish on people's talk pages. Beeblebrox (talk) 22:15, 25 July 2015 (UTC)

I didn't mean the template! That's nightmare fodder. Mark Schierbecker (talk) 23:19, 25 July 2015 (UTC)

• I suppose the PC people will suggest that the machine translation links be to something non-profit rather than what is the best solution. The last proposal to add social share buttons was sunk partially because editors didn't want to favor any one particular social network. Mark Schierbecker (talk) 23:26, 25 July 2015 (UTC)

• @WhatamIdoing: I will attempt to answer you though I get the feeling this is a loaded question.

• What I hoped to accomplish was for the users in question to understand that this is the English Wikipedia, and if they are going to have a discussion anywhwere on it, other users need to be able to particpate, even if it is on their own talk page.
• In at least two or three examples that I can recall, the user or users in question cheerfully provided a translation. In at least one of these cases it turned out they were in fact discussing article content, so it was kind of important that other users be able to understand and particpate in said discussion.
• In other cases it was simply ignored, and I did not pursue it further.
• I get the feeling most of the people commenting here think it is rude to ask people to communicate in a manner that can be understood by the community here. I am squarely on the other side of the coin, I think it is rude to come into a space where you know one language is used, and deliberately use another. Perhaps the language of the template could be softened, but the underlying message is perfectly valid.

• If you want to have a private converstaion, in any language, Wikipedia is not the place for that. That's what email, texting, phone calls, Skype, etc are for. Beeblebrox (talk) 18:04, 27 July 2015 (UTC)
  • That's really helpful. So the most useful focus for the message should be about the ability of others to participate (or at least to know what the subject is).
    How do you feel about a "do your best" standard? If someone doesn't speak English, then I cannot agree that it's rude to "deliberately use" a language that s/he actually does know. WhatamIdoing (talk) 23:42, 28 July 2015 (UTC)
• Google translate is literally worse than nothing. It would be much better to preserve the foreign text so that a human fluent in the language can translate it than replace it with the garbled ambiguous mess left behind by machine translation (this isn't just my opinion, it's codified at WP:MACHINETRANSLATION). --Ahecht (TALK
  PAGE) 14:31, 29 July 2015 (UTC)

"Worse than nothing"? I have to disagree. It is very helpful for identifying a mysterious source language. I almost invariably find that it has correctly translated many of the words, which at least provides me a clue what the subject matter is and where to look for human translators and often lets me find a link to the corresponding [whatever]-language WP article. When grasping at straws, these are no small things. Of course we don't want machine-translated text in the mainspace, but we can certainly exploit it in talkspaces. LeadSongDog come howl! 15:58, 29 July 2015 (UTC)

There can be some difficult problems, but it depends on what your purpose is. It's pretty good for "Is this source about this person?" It's pretty bad for finding out the nuance. WhatamIdoing (talk) 17:20, 29 July 2015 (UTC

It is worse than nothing when it is used without indication that it is a machine translation (or when it replaces the original text). With such indication it is more valuable - or, to be more exact, it is worth nothing, as anyone can get a machine translation on his own anyway... --Martynas Patasius (talk) 17:36, 29 July 2015 (UTC)

For the major Western European language it can be surprisingly good for many straightforward types of material , such as newspapers, provided you have the common sense & knowledge of the subject to fix the obvious errors. (and sometimes the cultural understanding to recognize equivalent offices and functions and the like) For Asian languages it's much less useful, but it's often possible to catch key words and phrases. (Of course the original text should be preserved also, and the translation acknowledged). DGG ( talk ) 01:53, 31 July 2015 (UTC)

On the other hand, German is sometimes an exception to that general rule, and in particular, machine translation is notorious for omitting a critical "not" when translating German to English.

I have updated the template's language somewhat, and I hope that User:Beeblebrox and others will think that it is somewhat more friendly, without changing the overall point of encouraging the use of English whenever possible. I have also thought about adding a sentence that says how much we need and appreciate people who speak a language other than English, but I haven't figured out where and how to do that. (Be bold, if you're inspired.) WhatamIdoing (talk) 02:14, 1 August 2015 (UTC)

Add functionality to User sandbox template

Have a look here: User:ManosHacker/sandbox and see how Template:User sand box works. New users can create, fast end errorless, their multi-article sandboxed workplace, fully organized as a list and ready to move sandboxed articles to main article space with simple clicks (mistakes were the rule without these new buttons, when moving from user namespace to main). Zero bites from old users. We have been using it for several months at Wikipedia School as standard practice. Unhide functionality first. Follow sandboxed child articles to see the change of behavior of the template. Hovering gives guidance. Moving a sandbox to an article removes it from the personal sandboxes view list.·· ManosHacker 23:33, 31 July 2015 (UTC)

What exactly are you proposing? Eman235/talk 10:29, 1 August 2015 (UTC)

This was also posted at Template talk:User sandbox#Add functionality. Please do not post the same thing on multiple talk pages without linking between the posts; see WP:MULTI. SiBr₄ (talk) 10:49, 1 August 2015 (UTC)

The proposal is to put this organized workplace functionality inside Template:User sandbox (replace old template with new).·· ManosHacker 11:22, 1 August 2015 (UTC)

Add functionality to User sandbox template

Have a look here: User:ManosHacker/sandbox and see how Template:User sand box works. New users can create, fast end errorless, their multi-article sandboxed workplace, fully organized as a list and ready to move sandboxed articles to main article space with simple clicks (mistakes were the rule without these new buttons, when moving from user namespace to main). Zero bites from old users. We have been using it for several months at Wikipedia School as standard practice. Unhide functionality first. Follow sandboxed child articles to see the change of behavior of the template. Hovering gives guidance. Moving a sandbox to an article removes it from the personal sandboxes view list.·· ManosHacker 23:33, 31 July 2015 (UTC)

What exactly are you proposing? Eman235/talk 10:29, 1 August 2015 (UTC)

The proposal is to put this organized workplace functionality inside Template:User sandbox (replace old template with new). It is extremely helpful for new users. It replaces Tutorial sandbox 1, 2, 3, 4, 5 with far more capabilities.·· ManosHacker 11:22, 1 August 2015 (UTC)

Email adresses for volunteers

Dear all,

A proposal to create Wikipedia email adresses for volunteers can be found at meta:Wikimedia Forum#Wikimedia volunteer email adresses. Your input would be very welcome.

Sincerely, Taketa (talk) 07:05, 2 August 2015 (UTC)

Notability

The reliable sources guideline says that articles should be "based mainly on reliable secondary sources" and No Original Research has similar language about primary sources being used "to a lesser extent". However, many specialized notability criteria allow the creation of articles where no secondary sources exist. This often results in Wikipedia pages that are basically just a mirror of the official website or bio.

In a prior discussion on Jimbo's Talk page here, I found myself agreeing with @Wnt:'s comment here, as well as part of @WhatamIdoing:'s comment: "We have people who show up at the guideline recommending that the advice be relaxed for their area of interest, but maintained for others." The specialized guidelines are generally abused and they codify the community's biases in favor of certain subject areas - biases we should be trying to temper. The most sensible aspects of these specialized notability guidelines are those elements that are completely redundant with GNG.

I thought I would see if others feel the same way - that it would be more sensible to consolidate on WP:GNG or WP:Golden rule, perhaps with a short bulleted list of exceptions. The only thing that really matters is whether there are enough reliable secondary sources to serve as the primary basis of the article. CorporateM (Talk) 11:17, 24 July 2015 (UTC)

I think it's a matter of "good sources are likely to be found" vs. "good sources already have been found" in part. My understanding is that the various notability guidelines concern mainly #1. Perhaps having one topic or two would work, but I worry about the length of a combined list of #1 factors. Jo-Jo Eumerus (talk, contributions) 12:04, 24 July 2015 (UTC)

I can't really improve very much on my comment referenced above (thanks!), but I should note that it contains a single tunable parameter, namely what "most" means. I think the specialized notability guidelines should be scrapped and we should use GNG, but it is necessary to make one compensatory change to GNG: we should allow a topic is notable if it is a member of a well-defined, enumerated, notable set of topics, most of which are notable. Two of the Golden Rule criteria still need to be met: there has to be a reliable source (we can't have an article without any source to cite about it) and that has to be an independent reliable source (otherwise there is no way to fully enumerate every member of the class; we can't just Google for everybody who says he won the X Award). The relaxed criterion is that the coverage doesn't have to be significant - we might have just a few vital statistics in a table, but still want to have an article to fill a gap in a list of kings so you can navigate up and down the generations of the dynasty. The tunable parameter is that we should put a number to precisely what fraction of the articles in a category have to be thought notable for this to apply.

To give an example, suppose we have an article about the 20** presidential campaign in some country. We have articles about ten major contenders (XXX XXX 20** Presidential campaign), but there are some other people in the contest. How would we decide under my system which of those deserve articles? Well, I'd say that first we look at some definitions of who is a contender. We can look at everyone that the State Broadcasting Corporation covers in their statistics - but is that notable? Is the SBC's set of candidates a notable topic in its own right? That could go either way, and reflects whether we find it important to have an article that covers every member of the list. If their set is not well defined, and includes different people at different times with no clear idea of who is "really" in it, we might still reject it. Or ... there might be a broader notable well-defined enumerated set we could also use, and I'd say that any such set justifies full coverage. Such as if the Public Broadcasting Company has its own list of 13 candidates, etc. And then, maybe a state office has a list of 15 people who made it onto the official ballot, and 17 people whose nominating petitions were accepted, and 24 people who filed petitions. So how do we decide if those are also acceptable sets worth completing? Well, in part, by a numerical threshold. We might say that to complete a class, >50% of the members are notable, or maybe >66.66%, or maybe >75% - some might even make it 90%. That particular choice is one to be made here, and determines how expansive this policy is. But whatever our choice, Wikipedia will look a whole lot fairer and more professional if we can point to our impartial threshold than if we point to a long chat thread with a bunch of people saying "this guy's a Nazi, nobody's going to vote for him ... no he isn't, that's just media propaganda ... etc." Wnt (talk) 15:45, 24 July 2015 (UTC)

The key about notability in both the main GNG and the subject-specific notability guidelines (SNGs) is that notability is a presumption - we want to give editors the opportunity to build an article on a topic that likely will have encyclopedic merit without worrying about a deadline. For most topics, this means showing that at least some (2-3 or more) secondary sources exist to build an article on (from the GNG). However, for many other topics, we have enough experience as editors that we can recognize that if a topic has met a certain milestone (such as a person winning a Nobel prize) that there most likely going to exist secondary sources or that these sources will be created as a result of that milestone, and so we accept the creation of an article just based on the primary source(s) that document the milestone. This provides the no-deadline time to allow existing sources to be found (recognizing that the Internet is not the end-all be-all of source locations, and that some might in print or in foreign languages and will take time to location).
That said, this is where the presumption aspect comes in: if someone created an article based on a milestone met 5 years ago and no one has been able to locate any sources for it with a reasonably exhaustive search in the present, that probably means our presumption was wrong, and because we cannot reasonably expand the article beyond the primary sources, deletion or redirection or merging is a perfectly acceptable result at that time. That's the checks and balances that make sure that we are always heading towards basing articles on reliable secondary sources, giving fair allowance for editors to work at improvement. --MASEM (t) 15:54, 24 July 2015 (UTC)

I am more concerned about articles being created with no WP:Independent sources than with no secondary sources. A common example of this is "Professor Important", employed by "Fancy University", whose article is entirely sourced to (and realistically cannot be sourced to anything except) the employer's website and the subject's own writings. This is accepted under WP:PROF. WhatamIdoing (talk) 16:00, 24 July 2015 (UTC)

@Masem: I think there is room for language like "Organizations of about 100 employees or less that are engaging in routine operations are most likely not notable". This saves us the time of having to look for sources, when it's pretty obvious they are not notable. Or on the other side of things, we could say something like "Fortune 500 companies are notable", because every Fortune 500 company is going to have enough sources in existence, even if they aren't found right away. These are shortcuts that save us the time of having to do research to verify notability. The Fortune 500 is also a good example of what @Wnt: was saying about being a member of a class of notable subjects.

But as things are now, an article about a professor will be kept even if an exhaustive search has been done and no sources were found. I see people complaining about the notability of a Fortune 500 CEO, but supporting articles on every tenured professor at a university. That's just crazy; I don't think it's like that because there is a high probability that the academic is notable (they probably aren't), but it's more likely because of the biases of our community (we have more of an interest in academics than business) that are codified into policies. CorporateM (Talk) 02:38, 25 July 2015 (UTC)

Unfortunately there are topic/focus areas of WP where there are people that will fight for notability of individuals that barely have independent sourcing but that meet an SNG. Professors are one area, professional athletes is another. We do require independance of sources irregardless of which SNG the person might met, particularly for persons to avoid self-promotional material. Unfortunately editors will fight for these areas hard. --MASEM (t) 03:12, 25 July 2015 (UTC)

@CorporateM: I think that arbitrary claims of non-notability are a very bad idea. Even when the specialty notability guidelines make them, in theory, as written, they only limit application of the 'alternate' guidelines and aren't supposed to infringe on the GNG; in practice this distinction is frequently ignored. But what are routine operations? Where did 100 come from? The Beatles are four people and all they go around and sing, no? I'm surprised to see Wikipedia is up to 200 employees, but not that long ago it was under 100. And of course any company that gets charged with a crime, or becomes known for some discrimination controversy, is going to end up being notable. So that is a rule without substance, as any rule must be that doesn't address our practical problem of finding enough sources to say something about a topic.

@Masem: Honestly, I don't see much wiggle room in the 'presumption' of notability. If all you have when you write an article are sources from a company website, you're not going to write an article people can trust. And if you have two independent reliable sources that detail a topic, there's no reason ever to delete that article, even if it remains small and no further sources emerge. Wnt (talk) 11:44, 25 July 2015 (UTC)

I would advocate moving in the other direction entirely. Whether or not we find sources for a particular is a matter of the quality of the search and the resources availabl3e to the individual, and whether the sources that write about the subject are the ones that we can easily search and recognize. Debates based on the GNG usually come down to evaluation of the terms "reliable" "substantial" and "independent", all of which can be interpreted to suit the desired result. Back when I joined in 2007, the guidelines were still being worked out, and I and others were able to use some rather convoluted arguments to justify the inclusion of obviously notable subjects. These were a very nonproductive way or arguing, and it in the end notability ended up as meaning, an article defended by someone with skill in using the arguments , but not anything about either the subject or the sources. Notability only means suitable for an encyclopedia like wikipedia, and , as long as verifiability is satisfied, the exact number and type of sources does not make much difference. The actual importance of the subject does.

(Incidentally, there is at least one formal guideline totally independent of the GNG -- WP:PROF does not work by presumption of meeting the GNG. It works by the different fundamental criterion of being an authority in one's subject, with various factors assumed to show it. It has worked very well for over 6 years, because everyone interested in the subject accepts it, and nobody else cares very much as long the results aren't ridiculous, which we take care of by being very conservative. I consider that an example, & think it's similarly time we get rid of the whole concept of presumed notability and have definite criteria that are easy to determine.

In practice, we interpret the key terms differently for different subjects,and the special notability guidelines help in subjects where the interpretation is particularly difficult. The balance between the different subjects is a compromise. Each of us accept a much greater notability for minor subjects in some areas they think totally unimportant in exchange for others accepting some relatively minor topics in their favorite areas, and thus we have a rough balance. The balance is at present rather distorted to sports and popular musics and geographic features, but this does no particular harm.

The basic question is, do we want to write and improve articles, or argue about what articles we should have? That's the real point. I'm rather good at AfD, and if we relied upon any such rules I think I could get WP to reflect my interests much more closely. I'm tempted to give examples of some of the arguments I used then and would use now, but I'll just give one: I would be prepared to argue that every news article written about a performer is ultimately the product of their press agent (actually, CorporateM, you taught me that argument yourself, in a slightly different context) and therefore not independent, and we should limit ourselves to to those about whom there is a full-scale published high academic quality biography or critical monograph. Think of it--we could remove 99% of the wrestlers and porn stars! But there are more important things to do here than argue at afd. There's a principle at WP just as important as consensus -- and, in a way, a restatement of it: compromise. DGG ( talk ) 03:11, 28 July 2015 (UTC)

I think the basic question is quite different, DGG: I think the basic question is, "Do we want to have encyclopedia articles about BLPs that we are reasonably certain cannot comply with WP:NOR and WP:V?" NOR requires that articles "be based on reliable, published secondary sources", and if no such sources exist, then it is absolutely impossible to comply with that core policy. WP:V requires editors to "Base articles on reliable, third-party, published sources with a reputation for fact-checking and accuracy." If no such sources exist, then it is absolutely impossible to comply with that core content policy.

We might well decide that these aspects of core policies are unimportant, but if so, then we should say so. WhatamIdoing (talk) 17:41, 28 July 2015 (UTC)

As I said just above, Without WP:V we are not an encyclopedia, and as I have often said, that applies to NPOV as well. But if bio article reports the verified information that is available, and that makes for something which is important, what's the problem? For example, an early Olympic athlete. We may know nothing but their name and country, and the event they competed in. That meets WP:V and WP:NPOV. It does not meet the GNG, so we currently deal with it by the evasion that there are certainly likely to be sources, if only we could identify them. (and I agree with this.) For an example in the other direction, an Assistant Professor at an undergraduate college. We know his degrees and position, for they are reported on the college website, which is a RS for such routine data as one of the exceptions to requiring third-party. In most cases, we can even find the title of his thesis and the date for it in WorldCat, a reliable and totally independent 3rd party source. It's a position which has some amount of social importance. But we do not make an article, because of the WP:PROF limitation that this does not show him to be an expert in his field, (and he hasn't met WP:GNG). Now, suppose that the college publishes a press release about an in-college teaching award he gets, and the town newspaper and his hometown newspaper report it. These would appear two RSs, but we still do not make the article, using the rationale that those two news sources are insufficiently discriminating for such matters for local people. (and I agree with this) Now, let's take a local politician, running for a town office. He says something remarkably stupid in an interview, it gets widely tweeted, to the extent that good national news sources report it. This does meet the GNG, but to evade it we use the BLP criterion of ONEEVENT. We do that regardless of the fact that we have V and NPOV. (and I agree with this.). Now suppose that 5 years later, he makes another such speech, with equal publicity. By our current rules, he should get an article; in reality, we probably wouldn't keep it, because anAfD will find some excuse for objecting to it. (and I agree with that also. Sometimes AfD will keep it, and I disagree with that--unless it becomes so prominent that people might reasonably look for it in an encycopedia) To anticipate, it wouldn't fall under the exclusion for purely negative information, because that doesn't apply to politicians who are by definition public figure. Now, let's take an example where I totally disagree with current practice: Consider an ambassador from one minor country to another. It's a public position at the top of his career ladder, and we can prove it by RS official sources. There's no NPOV problem involved in being an ambassador, and there's no problem with WP:V. We do not make the article. Why? Consensus has been that it isn;t important enough. To be sure, there is likely to be home country news reporting of his earlier career and the appointment., but normally we cannot find it. If we could, we'd probably still evade making the article by saying the appointment in ONEEVENT. Curiously, if instead of ambassador he was elected to the provincial legislature, we'd make the article. I could continue with such examples indefinitely. DGG ( talk ) 23:57, 28 July 2015 (UTC)

How do we demonstrate that anything "makes for something which is important", if the subject is apparently so unimportant to the word at large that there are no (or almost no) independent reliable sources on the subject? Olympic athletes about which nothing is known beyond name/country/event should be merged into lists until such a time as something is actually known.

Also, I suspect that library records about books do not constitute "independent reliable sources"; they are essentially direct copies from the books themselves (as you know better than I do). If you say your name is DGG, and I repeat that you said your name is DGG, the information does not become more reliable merely because I parroted what you wrote. If you publish a book, the book is not an independent, third-party reliable source for its title (although it is absolutely authoritative), and neither is an Amazon page. A library database that contains (on average) significantly less information than the Amazon page is not somehow more valuable for notability purposes.

One more question: Do you believe that it is possible to write an article that complies with NPOV, especially the part that prohibits the article from over-emphasizing the views of the subject itself, when 100% of the sources you can find are directly or indirectly controlled by the subject (e.g., the subject's own writings, the subject's own website, the subject's employer's website)? It'd be easy enough to get a neutral-sounding tone, but can you write an article about Alice Expert that fairly represent other people's views of Alice if every source you can find is from Alice herself? WhatamIdoing (talk) 00:47, 31 July 2015 (UTC)

In the specific case of Amazon, they are notorious for careless errors that refer to one edition with another edition's metadata, or flat out get bibliographic data wrong. (Page counts, for example, are often rounded up to the nearest power of 2 for recent books. Authors and illustrators are sometimes confused. Titles, esp sub-titles, are often wrong.) As long as it sells the book, they don't care. When I was working at the ISFDB an OCLC citation was MUCH preferred to an Amazon cite. It is true that such a cite is basically WP:PRIMARY. An OCLC cites says "A librarian handled a copy of this book and says that it exists, has so-and-so many pages, and states such-and-such data on its copyright page (and sometimes other pages such as the cover or back cover)." It also says that a library found it worth their time and money to acquire and catalog, and in some cases it shows that many libraries did so. That is worth something. DES ^(talk) 11:58, 31 July 2015 (UTC)

Or that someone donated it. At least in my local system, people dump used books in the return box all day long. We can count on getting sackfuls every week. Some get tossed, some get sold, some get added to the collection (pretty much anything written by a local author or for kids).

I'm unconvinced that "some library decided to put this book in the collection" signals that we should have an article about the author. If it did, then we would accept a lot more articles about pulp romance writers. WhatamIdoing (talk) 18:06, 31 July 2015 (UTC)

Concur with WhatamIdoing on that point.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  22:49, 3 August 2015 (UTC)

Back to the OP: If some topical "guideline" (usually a WP:PROJPAGE) is conflicting with WP:GNG, then GNG wins, and the conflicting page should be edited to stop violating WP:LOCALCONSENSUS policy. There cannot be a magical escape clause for including non-notable topics just because they happen to fall into the WP:OWN territory of some particular subject area. The one and only purpose of topical notability criteria is to help editors identify topics that are likely survive a GNG analysis and how; it's not for evading GNG. We should probably add a statement to WP:Notability's lead that it has precedence over other notability pages.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  22:49, 3 August 2015 (UTC)

Icon at top right corner for A-class articles

My proposal is simple: add the File:Symbol a class.svg icon to the top right corner of the pages of all articles that have passed an A-Class review, at the same location as GA and FA icons. Currently, most A-class articles have the GA icon displayed at the top right corner of the page, but the A-class criteria is usually more stringent than the GA criteria. Displaying the A-class icon instead will help differentiate these articles with other GA/FA articles. Sovereign Sentinel (talk) 11:17, 21 July 2015 (UTC)

Perhaps a diamond shaped icon rather than an upside down star? Praemonitus (talk) 15:13, 21 July 2015 (UTC)

I think that's a 90 degree rotation, rather than upside down. WhatamIdoing (talk) 17:43, 21 July 2015 (UTC)

I would oppose this change. A-class is project-specific whereas GA/FA are not. This means that A-class is not always "more stringent" than the GA criteria, and I can think of at least one project where A-class has been done away with entirely. --Izno (talk) 18:32, 21 July 2015 (UTC)

I am well aware that many WikiProjects have done away with A-class. Maybe I should clarify my proposal: if any WikiProject assessed an article as A-class, the A-class icon should be displayed at the top right corner of the article's page. Sovereign Sentinel (talk) 03:31, 22 July 2015 (UTC)

• Oppose: As per Izno. This idea appears wildly redundant. --78.149.112.112 (talk) 18:54, 21 July 2015 (UTC)
  • Are you a registered person using an IP? Why is this your first edit? Dustin (talk) 03:34, 22 July 2015 (UTC)

@Dustin V. S.: IP users are as allowed as anyone to participate in this discussion. Many IPs are dynamic, meaning they change regualrly without the user even being aware of it, so one legitimate user could have thousands of edits under dozens or even hundreds of addresses. Their comments and contributions are as valid as mine or yours and it reflects poorly on you to aggressive y interrogate them in such a manner.

I don't think this is a bad idea. Whether or not A-class and Good Articles are bettor or worse than each other, there is a difference, which should be noted. Eman235/talk 19:12, 21 July 2015 (UTC)

At the very least, I think there should be the option to view A-class icons voluntarily. Dustin (talk) 03:35, 22 July 2015 (UTC)

There is a script/gadget that will color the heading of the article based on the highest quality it's been assessed at. See the "Display an assessment of an article's quality as part of the page header for each article. (documentation)" checkbox under "Appearance" in the Gadgets tab of Special:Preferences. --Izno (talk) 03:41, 22 July 2015 (UTC)

I'm actually aware of that, and not to be picky, but it would be nice if displayed an icon. Regardless of how this would be done, I just want an A-class icon. Dustin (talk) 03:44, 22 July 2015 (UTC)

• Oppose – There is no unified standard for what A-class is, so having an icon doesn't mean much. A dead project with rubbish for criteria could tag an article as A-class. Why should that warrant an icon? We don't need anymore accolades or fancy buttons, which don't help the reader anyway. If there was a unified "A-class" criteria, then perhaps an icon might mean something. Otherwise, no way. RGloucester — ☎ 03:46, 22 July 2015 (UTC)
  • One method to avoid this problem is to require these articles to also pass a GA review. That is, if an article passes an A-Class review but not GA, it would not have the icon displayed. sovereign°sentinel 10:34, 22 July 2015 (UTC)

Another, even easier solution is to not do this as it adds nothing of value for our readers. Beeblebrox (talk) 20:53, 23 July 2015 (UTC)

Adding another layer of reviewing could mean more trouble for editors, but how on Earth does that "add nothing of value for our readers"? That simply is not true. Dustin (talk) 21:00, 23 July 2015 (UTC)

The good article and featured article icons let a reader know that that article has gone through a standardized review process and that impartial reviewers have found it to be among our best content. This would let readers know that some random person from a project that my or may not have decent standards and review decided an article was A class. That adds no value, it is just clutter better left on the talk page. Beeblebrox (talk) 21:33, 23 July 2015 (UTC)

• Oppose per RGloucester. There is a site-wide standard peer review process for FA and GA class articles; there is no such process for A-class. Quite literally, I could go to any article on Wikipedia and tag it as an A-class article, even conceivably under the guise of a project that doesn't have an A-class criteria, or a project that doesn't exist. Ivanvector 🍁 (talk) 20:56, 23 July 2015 (UTC)
• Oppose, per all those above. A-class (and B & C class, come to that) is a relic of the early days when the WMF was planning print and CD-ROM versions of Wikipedia, and needed some way to determine which articles were of adequate standard to make the cut, and doesn't generally serve a useful purpose. (A very few projects, most notably Milhist, use it as an internal quality control mechanism, but each of those projects sets their own standards; as Ivanvector says, there is literally nothing as things stand to stop me creating my own WikiProject Letter W, defining my project's A-class criterion as "The first word contains the letter W", and tagging every article that meets said criterion as A-class. – iridescent 21:02, 23 July 2015 (UTC)
• Oppose because there are no consistent criteria for A Class. In theory, A Class can be used by editors to undo changes demanded by WP:GAN and go back to some WP:RIGHTVERSION that suits their WP:LOCALCONSENSUS, and label it A Class (i.e. "better than GA"), even if it were later stripped of GA class at WP:GAR. In practice, from what I can tell, A Class is just a review process used by 3 wikiprojects, as an "FA prep" processes, but their internal criteria for what constitutes A Class are inconsistent between the wikiprojects. There's another proposal on this page or maybe at WP:VPPOL, I forget, to deprecate A Class entirely. B and C Class are fine; they have consistent site-wide criteria, and the wikiproject banner metatemplate supports individual parameters for which of the B-class milestones the article has passed.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  19:44, 26 July 2015 (UTC)
• Support; perhaps certain projects could be given approval to mark their A-class articles with the icon? North of Eden (talk) 03:25, 29 July 2015 (UTC)
  • Oh, so other wikiprojects become second-class wikiprojects, then?  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  22:53, 3 August 2015 (UTC)

Proposal: Make Wikipedia's in-house ads (Geonotices) opt-in

Wikipedia now has ads. They appear on one's watchlist page. Ads running right now include: "West Virginia University Library is hiring a Wikipedian in Residence", and "Join and add your city to the Great American Wiknic meetup events in July and August 2015". The volume of those ads has increased substantially in recent months. There's no obvious way to opt out of those ads. There should at least be an opt-out. I'd suggest going further; those should be opt-in, or not present at all.

(Yes, those are ads. "Advertising is a form of marketing communication used to persuade an audience to take or continue some action, usually with respect to a commercial offering, or political or ideological support." See Advertising.) John Nagle (talk) 19:34, 10 July 2015 (UTC)

The geonotice on the watchlist page can be disabled in your preferences, under the "Gadgets -> Watchlist -> Display notices on your watchlist about events in your region." section. Nakon 20:14, 10 July 2015 (UTC)

I'm not sure all of them are specific to events in our region. For example, I'm in Indiana, in the United States. Nevertheless I still get the one about West Virgina University; I got the banner about freedom of panorama in Europe; the Wikinic one is for all locations; the Wikilibrary ones are for all locations...

That said, they are easy enough to hid or dismiss by clicking the button that says "hide" or "dismiss". You only need see them once. ~ ONUnicorn^{(Talk|Contribs)}problem solving 20:33, 10 July 2015 (UTC)

The location for the WVU one is defined as "US", so it's being presented to the entirety of the United States. The full list of local entries can be found at MediaWiki:Gadget-geonotice-list.js. Nakon 20:37, 10 July 2015 (UTC)

The WVU ad is the worst one. It's a wordy job ad with too wide a distribution. "Just hit delete" is an classic spammer argument. [2] John Nagle (talk) 08:12, 13 July 2015 (UTC)

Today I get "Wikipedia Library and Wiki Education Foundation are announcing 5 new Visiting Scholar positions." Why am I getting this with Geonotices turned off? I've now turned off "Central notices" as well. Is there a delay before those preference options take effect, or do they not really work? John Nagle (talk) 21:15, 15 July 2015 (UTC)

Related suggestions

I agree that sometimes the "ads" can be annoying, but I also would like to see them just once, as occasionally one may interest me. Since I do not stay logged in for the 30-days at a time (browser settings set to clear cookies when closed, for privacy/security), I see notices every time I log in to WP and check my watchlist. "Hide" only removes notices while logged in, so the next time I log back in, I will often see the same notices. Sometimes, the same notices appear for weeks. It's a minor annoyance to look at the list and determine if there are any new ones.

Suggestion 1: When clicked, the "Hide" button should permanently hide the notice so that it does not appear the next time a user logs in. Suggestion 2: For users who may want to see notices, but not see a wall of text every time they look at their watchlist, I suggest an option be created (in preferences>watchlist) to place notices in a collapsible list that would not be fully expanded

Notices:
Notice 1 Notice 2 Notice 3 etc...

A better phrase than "Notices" is needed and any implementation would need to look better. The collapsible list is just for illustrative purposes. Users would still be able to permanently hide notices with suggestion two and change their preferences to display only central notices. I strongly support suggestion one. I am neutral to suggestion two...it's just something that crossed my mind and that is worth discussing.AHeneen (talk) 07:49, 23 July 2015 (UTC)

Odd, I have this enabled and didn't see any notices when I clicked on watchlist from a site in the US. WP:Geonotice doesn't list the West Virginia entry. Is there some other way to access this content? Wnt (talk) 11:51, 25 July 2015 (UTC)

I have a suggestion for ad and promotion placement: http://i.imgur.com/KXAGJgZ.jpg Syberiyxx (talk) 06:10, 29 July 2015 (UTC)

Yeah, it would force them to be more concise.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  22:55, 3 August 2015 (UTC)

Adding "something of person" vs. "Person" into WP:perennial proposals

We have endless proposals about making just names a standard for titles, whose involved person is not as notable as an event related to the person. Wikipedia talk:Article titles#"Death of John Doe", "Shooting of John Doe", "Murder of John Doe" vs "John Doe" is recently made; move request was made Talk:Death of Sandra Bland before withdrawal. When this fails, shall we add it into that page? --George Ho (talk) 08:25, 6 August 2015 (UTC)

Template:Infobox person ii

I created this template in order to be able to view and compare, side by side, wikidata and user data infoboxes. It displays a dual infobox during preview in Source Editor, it does not affect VisualEditor, there is no harm at all if it stays saved inside an article. Just keep it updated, along with WD hidden infobox person template. Check out here. Can be used in any article by adding an " ii" at the end of any Infobox person template name. Enjoy.·· ManosHacker 13:51, 22 July 2015 (UTC)

@Frietjes and Plastikspork: -- Magioladitis (talk) 16:25, 22 July 2015 (UTC)

if this is needed, it should be merged with template:infobox person rather than creating yet another frontend that must be maintained. @Mr. Stradivarius and Jackmcbarn: Frietjes (talk) 16:36, 22 July 2015 (UTC)

Yeah, this should just be a feature of the real template, that can be enabled in preview mode.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  16:47, 22 July 2015 (UTC)

I agree. -- Magioladitis (talk) 16:55, 22 July 2015 (UTC)

It's been made separate to show the potential and allow error checking. I also agree to a merge within the real template.·· ManosHacker 23:59, 22 July 2015 (UTC)

Understood. I agree it's helpful.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  19:47, 26 July 2015 (UTC)

It would also be handy to be able to link to wikidata entries for corrections/additions.·· ManosHacker 00:23, 23 July 2015 (UTC)

ManosHacker I think the problem is that in the English Wikipedia we are still not ready to obtain info from Wikidata in that large scale yet. -- Magioladitis (talk) 12:29, 23 July 2015 (UTC)

There is no reasoning or request to import from Wikidata to the article. This is a tool to compare automatic and manual data side by side during preview, just to help correct mistakes and update, either Wikipedia or Wikidata. It does not affect the article itself, only the preview of the source editor is affected.·· ManosHacker 13:08, 23 July 2015 (UTC)

Templates are now merged, Infobox person can be replaced by ii version

It is now merged with Infobox person and works like a charm. No need for updating both Infobox person and Infobox person ii during changes. I propose to implement it as an option for advanced users.·· ManosHacker 13:42, 23 July 2015 (UTC)

It can be used, but not merged in one template, as it will not pass loop test. Merging will always require two external child templates and template update will always be tripple.·· ManosHacker 16:44, 23 July 2015 (UTC)

That was a bit telegraphic. Is there a proposed solution then?  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  19:47, 26 July 2015 (UTC)

Update

Successfully merged WD hidden infobox person inside Infobox person ii.·· ManosHacker 15:12, 30 July 2015 (UTC)

Proposal: Nest old template inside new, make this feature optional and not pre-selected

Purpose

Preview, side by side, the manually filled in infobox person to a mirror infobox that is filled in automatically with Wikidata entries

Target

Compare and update data in either side, effortlessly

Feature

Wikidata infobox appears only during source editor preview, disappears in article view, old article version view, VisualEditor

Inconvenience

Having to keep both templates synchronized (but is very straightforward process and new template is very clean)

Steps (technical)

1. Call Infobox person i instead of Infobox person , inside template Infobox person ii
2. Move Template:Infobox person to Template:Infobox person i without redirect
3. Move Template:Infobox person ii to Template:Infobox person without redirect
4. Put link to Infobox person i , inside Infobox person usage help, to easily keep both templates synchronized

Future

Enhance wikidata template to link to Wikidata edit / update (edit value popup or wikidata page link)

---

• Support ·· ManosHacker 18:59, 27 July 2015 (UTC)
• Strongly Oppose unless this is made somehow opt-in only. When I am reviewing a change to an infobox in p[review mode, i don't want it cluttered with a 2nd infobox full of data that I don't trust and that will not be used in the article. More importantly, when an editor who has never heard of wikidata (which is most of out editors) uses preview mode, s/he should not see a preview made intentionally wildly different from the actual article display. Preview is intended to preview what an article will look like after an edit. It is an abuse of preview to display data that will not be displayed after the edit, except possibly in response to some setting or parameter that only editors who explicitly want such a display will set, and which will never be left in place to confuse future editors. DES ^(talk) 16:26, 30 July 2015 (UTC)
• Oppose DES objections are well founded. Anything fields that wikidata needs should be added - by WP:CONSENSUS to the current infobox. If that can't be done then perhaps persondata should not have been deprecated. MarnetteD|Talk 19:38, 30 July 2015 (UTC)

No doubt it will be optional, if implemented, and not pre-selected. It is made to help check for errors, not confuse people. Making it optional is beyond my current knowledge, an experienced user could help us on this.·· ManosHacker 21:06, 30 July 2015 (UTC)

I have no objection to a strictly optional feature intended for testing, as long as it doesn't unduly burden the normal use of the template. But is this proposal really ready for discussion before such an optional version is sandboxed? If we are discussing on an in-principle basis, I wouldn't expect to use this, but wouldn't object if it is optional, not the default, and doesn't impose significant cost on the very frequent normal use of the template. The discussion above sounded to me to imply that this would be always on, or on by default. DES ^(talk) 21:28, 30 July 2015 (UTC)

In Greek Wikipedia, wikidata automatically fills in the infobox and can be overriden only by filling infobox entries by hand. The result is a mixed infobox render and people get confused, unless wikidata values are rendered with different colour or icons (--) are used. I would use dual infobox by default there. English Wikipedia has a different approach and dual infobox should stay optional here.·· ManosHacker 22:40, 30 July 2015 (UTC)

It seems to work fine directly, but these templates also call it and we would have to check it there, too. Some expert could run tests to see if it is heavy for the system, I think not, and fetching wikidata would only be true for those who select to enable it and only during preview.·· ManosHacker 22:32, 30 July 2015 (UTC)

• Support, barring any devils in the details. An optional tool like this would be useful.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  22:51, 3 August 2015 (UTC)

Checking is done, to see if the template works nested, inside other templates, and it works fine. Template:Infobox artist ii is created, in which Infobox person ii is called. Preview this: Caravaggio, where it reveals that date of birth is to be corrected.·· ManosHacker 09:50, 6 August 2015 (UTC)

Request for comment: Restrict Content translator to autoconfirmed users

Following a discussion I had at mw:Topic:Smcw9jyo5p274lwk right now Content translator has the following limitations:

• Only logged-in users who activated Content Translation in the "beta" section can access the tool. Content Translation is provided as a beta feature so that users can opt-in, try the tool and provide us with feedback to improve the tool without affecting the experience of other users. Due to limitations of the beta features platform, only logged users can access the beta features (there is a ticket to expose beta features to anonymous users but here is not active work in that area as far as I know).
• Blocked users on the target wiki are prevented to translate. Content Translation respects the rules of the target wiki for publishing (abuse filters, blocked users, etc.). So anyone that cannot edit the target wiki won't be able to publish a translation. For the specific case of blocked users, in recent versions we are trying to anticipate that situation to avoid the user to waste time in a translation that cannot be published and showing the error when accessing the tool instead.

I suggest that we additionally restrict Content translator to autoconfirmed users in order that we reduce vandalism and people with no experience of the English Wikipedia. We had examples of editors who jump in various wikis, just add a promotional text in various languages and disappear. Check for example, now deleted LastLesson. We also has examples of people who tried to translate text from unsupported languages. Moreover, Content translator in many cases produces bad wikicode and we need to restrict this till these bugs are fixed. -- Magioladitis (talk) 05:57, 7 August 2015 (UTC)

I've tried content translation and it stinks at the moment. Good interface, but it doesn't work well. We definitely need to keep newbies from using it for now. Eman235/talk 14:47, 7 August 2015 (UTC)

Check this. It is a total disaster from someone that clearly does not speak English. -- Magioladitis (talk) 21:40, 7 August 2015 (UTC)

Alfred Berengena is a Catalan battery known by his versatile form to touch and his books

Berengena Possesses a form to touch very explosive and fast but to his dynamic time.

It's official, Content Translation tool writes worse than me. Bgwhite (talk) 22:15, 7 August 2015 (UTC)

Finally, someone's looking at the good things about further restricting anonymous edits. Cédric ^{Leave it to registered users! =D} 22:48, 7 August 2015 (UTC)

Moving modules

When a module called "M" is moved to a module called "N", Module:M should say return require('Module:N'). See also gerrit:146608. GeoffreyT2000 (talk) 17:41, 8 August 2015 (UTC)

@GeoffreyT2000: This seems perfectly reasonable and something that should probably just be on Phab if it isn't already. Sam Walton (talk) 17:50, 8 August 2015 (UTC)

WikiWidgets

The WikiWidgets project is about adding interactive JavaScript widgets into some articles, to help illustrate and explain the concepts within them. The Spanish Wikipedia has already implemented it, you can try the two existing wikiwidgets here and here. This proposal is about bringing the project to the English Wikipedia. In order to do so, several things need to be done. The first is to create the Template:WikiWidget. That's easy, I already did it. The second is to add the following code to MediaWiki:Common.js:

/**
 * Inserts WikiWidgets in the articles with the Template:WikiWidget
 * WikiWidgets serve to illustrate and explain interactively the concepts treated within articles
 * The code first inserts a preview of the WikiWidget. To minimise requests to the server,
 * the WikiWidget itself is only loaded when the user clicks on the preview.
 */
$( '.WikiWidget' ).each( function () {
	var wikiwidget = $( this ).data( 'wikiwidget' );
	var preview = $( '<img>' ).attr({
		'class': 'WikiWidgetPreview',
		'title': 'Click to load the WikiWidget',
		'src': $( this ).data( 'wikiwidget-preview' ),
		'style': 'cursor: pointer'
	}).click( function () {
		importScript( 'MediaWiki:WikiWidget-' + wikiwidget + '.js' );
		importStylesheet( 'MediaWiki:WikiWidget-' + wikiwidget + '.css' );
	});
	$( this ).html( preview );
});

This code checks for the presence of the WikiWidget template in every page. When found, it replaces it with an image that serves as a preview of the WikiWidget, the URL of which is found in the WikiWidget template. When a user clicks the preview, the wikiwidget named in the first parameter of the WikiWidget template gets loaded. If the wikiwidget is called X, the loaded code will be MediaWiki:WikiWidget-X.js and MediaWiki:WikiWidget-X.css. So the third step is to add the code of one or both existing wikiwidgets to their proper pages in the MediaWiki namespace, that is:

• MediaWiki:WikiWidget-Formicarium.js
• MediaWiki:WikiWidget-Formicarium.css
• MediaWiki:WikiWidget-Vivarium.js
• MediaWiki:WikiWidget-Vivarium.css

You can find the code in the homonymous pages in the Spanish Wikipedia, or at the Git repos here and here.

Lastly, a few pages of documentation would need to be created, probably Wikipedia:WikiWidget, the documentation page for the Template:WikiWidget and maybe even a Wikiproject:WikiWidgets.

I should mention that I already made this proposal here and here. The first time was before it got implemented in the Spanish Wikipedia, and it didn't garner much support, maybe due to technical and conceptual immaturity, so I took it to my home project and implemented it there before returning here. The second time it got much more support, but it got archived prematurely, so I'm posting it again. In these discussions and the one in the Spanish Wikipedia, a few concerns were recurrent:

• Accessibility: the wikiwidgets are written in JavaScript, so obviously, users without JavaScript won't be able to run them. However, the WikiWidget template has a nice fallback: the second parameter is the file that will be shown to the user when s/he doesn't have JavaScript enabled. Similarly, when printing a page, the fallback file is shown.
• Performance: the only new code that is added to every request is the one in MediaWiki:Common.js. The code of the wikiwidgets themselves is only loaded when the logo is clicked, and by convention the wikiwidgets don't start automatically, so the load additional requests and CPU cycles are minimised.
• Security: the code of the wikiwidgets will be stored in the official Wikimedia git repositories at git.wikimedia.org. All code will go through code review before getting into Wikipedia, so the risk of malicious code should be no greater than with any other piece of code. Furthermore, the existing wikiwidgets are composed of a single JavaScript file of less than 1000 lines of code, and future wikiwidgets are unlikely to grow much larger, so they are quite easy to review.

A few users have already contributed to this proposal, I invite you all to join in again LFaraone, JohnBlackburne, WhatamIdoing, SMcCandlish, Stuartyeates, APerson, Krinkle and Unready. Cheers! --Felipe (talk) 23:07, 12 July 2015 (UTC)

Felipe, is there any chance that you'll be in Mexico City for the Hackathon and Wikimania this week? WhatamIdoing (talk) 03:08, 13 July 2015 (UTC)

Hi WhatamIdoing, unfortunately no, but we can coordinate a Hangout or Skype meeting if it's useful. --Felipe (talk) 21:18, 14 July 2015 (UTC)

The Spanish implementation is like a black box, with no indication to the reader that it's anything other than a picture (no caption or title attribute). It would be nice, when javascript is enabled, for the script to directly load into a passive state (as both examples currently do) so that something interesting appears right off the bat. I wish the widget could have a caption beneath it, in all states, like an image. I don't know why the logo needs to be involved at all; the widget would load for those who have js enabled; and an image or whatever loads for those who don't. That aside I support adding this capability to Wikipedia. (It would also be nice if the two available widgets were given simple, explanatory names rather than the artful but cryptic names that are currently used. Compare {{WikiWidget|GameOfLife}} to {{WikiWidget|Vivarium}}...) Riggr Mortis (talk) 00:11, 19 July 2015 (UTC)

Thanks for your comment and support Riggr Mortis. The widgets did load in passive mode before, but a few comments made in the previous discussion led me to change that for the logo. Basically, the aim is to minimise the number of requests and data sent with each request, in order to reduce the load to those with a slow connection. There are a few other advantages too. First, using the logo would give an uniform initial interface to all the widgets, so as to make them recognisable (the two existing widgets are very similar, but future ones may look very different). Second, if the widgets start out loaded passively, they would need to have a small size so as to fit in the article without crunching the text. However, if they start out as a logo, then when the logo is clicked, the wikiwidget could expand to full size without upsetting the user (there would need to be a button to close it of course). So far, the two existing widgets expand to a small size, but this can easily change in the future, which to me is an exciting possibility, as more space adds more potential. On the other hand, I totally agree that there should be at least a title to the image, so I just added it to my proposed code. A caption may work too, but I'd like to hear other opinions before implementing it. Regarding the names of the widgets, I chose Formicarium and Vivarium mainly because they are more language-neutral (similar to latin names for species). These two widgets will serve as examples for showing the project to other Wikipedias, so I want to avoid language-based complaints if possible. What do you think? --Felipe (talk) 15:39, 20 July 2015 (UTC)

Is this just an FYI post, or are we supposed to support/oppose something, or provide some other particular form of input? (I do support, as in previous version of thread).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:30, 25 July 2015 (UTC)

I just want to make sure every major issue is accounted for before requesting the changes to the MediaWiki namespace. By the way, is anyone here able to do said changes?

Jackmcbarn, ais523, Technical 13, Anomie, SFB, you participated in the first discussion about this proposal. It has evolved a lot since then. Should we implement it? --Felipe (talk) 22:09, 30 July 2015 (UTC)

Personally, I'd rather see this done in the software instead of on-wiki, but I guess this is good as a stopgap. Jackmcbarn (talk) 22:43, 30 July 2015 (UTC)

Agreed. Its use here would help get it built in. Various things get tested as widgety experiments and end up becoming default parts of the system later.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  22:56, 3 August 2015 (UTC)

It would be helpful to have an admin create the four needed Mediawiki-namespace files so we can test this locally. I already have the js and css code in my User:SMcCandlish/common.* files, but there's nothing to test this with on en.wiki.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  23:07, 3 August 2015 (UTC)

Indeed it would be useful, but given that there is mostly support for this proposal, and that we've been through three cycles of debate already, when this discussion gets archived I plan to request an admin to create the necessary pages in the MediaWiki namespace, as well as doing the necessary changes to MediaWiki:Common.js and MediaWiki:Common.css. That is, unless somebody has a blocking objection. --Felipe (talk) 16:58, 5 August 2015 (UTC)

I'll reiterate my strong opposition, which was apparently only posted to a different incarnation of this proposal. Wikipedia should not require JavaScript for content—it should be strictly an enhancement. WikiWidgets are clearly intended to be content, not enhancement. Not to mention the security concerns, which I don't feel are fully addressed here. {{Nihiltres |talk |edits}} 01:59, 6 August 2015 (UTC)

Nihiltres, if you strongly oppose the project, I would expect strong arguments against it. However, you haven't provided any. You say that JavaScript should be strictly for enhancements, but you don't explained why. Could you please do so, so that we may evaluate your arguments? You also say you "feel" the security concerns haven't been fully addressed. But feelings are not valid arguments in this context. Please elaborate what are your actual concerns so that we may try to solve them. --Felipe (talk) 19:54, 6 August 2015 (UTC)

You have ignored the security issues and other concerns I raised here: Wikipedia:Village pump (proposals)/Archive 125#WikiWidgets. I did not want to reply yet again but your pleading ignorance of the concerns repeatedly expressed is frankly unacceptable. This is the third time you started a thread on this (see also Wikipedia:Village pump (proposals)/Archive 124#WikiWidgets). You don't get to keep re-running the same arguments until other editors tire of replying so you win by default.--JohnBlackburne^words_deeds 22:23, 6 August 2015 (UTC)

On the contrary JohnBlackburne, I have repeatedly answered your concerns, and some users have agreed that my answers were satisfactory. In fact, my first post in this thread has clear and explicit answers to your accessibility, performance and security concerns. I wrote those answers thinking mostly of you, but you haven't bothered to mention them, so I'm not even sure you read them. Would you be so kind to read them and point out what is wrong with the solutions I propose to your concerns? Regarding my repeated posting, you should know that the first post was done before the project was implemented in the Spanish Wikipedia, when the implementation strategy was still on its infancy. The discussion that took place there and later in the Spanish Wikipedia improved the implementation a lot, so when it got deployed in the Spanish Wikipedia, I retuned here to share the latest approach, and I would have continued the discussion in that thread, if it weren't because threads get archived regularly here, no matter if the discussion is resolved or not (another reason why the Flow extension is seriously needed). --Felipe (talk) 00:35, 7 August 2015 (UTC)

Look again at that thread. My concerns were expressed in the last but one post, were ignored then, and have not been addressed since--JohnBlackburne^words_deeds 01:58, 7 August 2015 (UTC)

I've re-read your comments on your last but one post. Regarding your concern about the widgets being developed in the Wikimedia repositories rather than on-wiki, I have already given answers here and there, but lets recapitulate: wikiwidgets are meant to be cross-wiki, so developing them in one central place makes sense, so as to allow developers from different languages to collaborate, and also to avoid multiplying the versions of the widgets which may then become incompatible, like it currently happens with gadgets (by the way, if you're concerned about security, you should start a campaign against gadgets, rather than wikiwidgets). Secondly, as anyone who has developed any gadget knows, the development cycle within MediaWiki is a nightmare: edit, save, reload the other page to see the changes, edit again, save again. Each cycle involves several clicks and reloads, and as they are repeated a thousand times, they become a nightmare. That's why the wikiwidgets repositories include an index.html file with the minimal markup necessary to run the widgets in a browser, which speeds up the development process enormously. Third, MediaWiki is just not designed for code development, so although doing so may be possible it's certainly not optimal, and wouldn't take advantage of the software that is designed for code development and collaboration. Templates and modules have some complexity, but not nearly enough as widgets have (I haven't developed modules actually, but plenty of templates), and as complexity increases, so does the need for adequate software. Anyway, even if you were right on this point, and widgets should be developed on-wiki, this is hardly a blocking problem for the project!

In the second part of your post you talk again about "performance, accessibility and security" concerns, as if those words meant anything without further explanation, given the fact that we had been discussing them in length. My solutions to those three concerns are explicitly given in the first post of this thread, which you still haven't given any signs of reading. You continue presenting your concerns without addressing the solutions I offer. You also say that "having user editable JS on an encyclopaedia that anyone can edit has all sorts of security implications", but then you say "We have a few JS files on WP already but they can only be edited by admins, and tend to only be touched by a handful of experienced admins, as any wrong edit can break things badly", so you almost answer yourself. Wikiwidgets, being developed in Gerrit, would be deployed on each particular Wikipedia only when an "experienced admin" decides to do so (at least until they are served from Commons, which is the natural way to go, as someone else has pointed out). And regarding your concern that "any wrong edit can break things badly", that is why code review exists, and even if something goes wrong (say a syntax error, or some incompatibility with a gadget, or an error by the admin in pasting the code), then the most that would happen is that some JavaScript wouldn't work in the particular page where the faulty wikiwidget is embedded, nowhere else. It would just be a matter of finding it and fixing it, end of the story, just like with any syntax error in wikitext or templates or anywhere else. No terrible consequences, you know, thanks to the fact that Wikipedia is so little JavaScript dependant, ironically. Sorry for the long answer, but you deserve it. --Felipe (talk) 02:51, 7 August 2015 (UTC)

There is no need to host them externally because they might be used on other wikis. This happens all the time with other source code and code-like content here. Templates for example, and now Lua modules, are almost always developed independently on one particular wiki. Often this one as it is the biggest and most developed. Then other wikipedias can and do copy them, localising them or adapting them in other ways to suit their particular needs, such as for a right to left layout. Github or Gerrit largely reproduces what we have here, but from our point of view very poorly with no integration with user accounts, permissions, histories or contribution records. Also once on WP there is nothing to stop any editor with appropriate rights (or any editor at all via the edit request mechanism) making changes, as has happened to the programs on the es.wp. These would then have to be integrated back into the externally hosted version. And we can't host code on commons which does not have support for diffs of content (just of descriptions). Plus with all the localisation/adaption needed it would be hard to have a version on commons that all wikis could use.

These are more like templates/modules than content: bits of programming that’s used on particular pages. Templates can be for a single page too, though typically the code is shared across multiple pages. The only difference with WikiWidgets is they are in JS. Well that is not a problem as MediaWiki already fully supports JS pages, for the interface, for gadgets, and for users' personal interface pages. But this is where the security concern arises. Other bits of JS are either global, so thoroughly and repeatedly checked, or optional and enabled only by users who want them, either as gadgets or personal JS.

WikiWidgets though run for everyone visiting the page they are on (after activation), which opens up far more security concerns. It’s not just that a bad edit might stop them working. With JS a bad edit might introduce malicious code that does all sorts of things you don't want. There is a small industry of people who write such code, looking for places it will go. Making them only editable by admins limits these concerns but puts the onus on admins to check and verify code they did not write. You suggest the code will be reviewed but it's quite hard to review someone else's code, especially JS which relatively few people have to work with here, and we don’t currently have a process for it.

Having it not autoload does deal with performance and accessibility somewhat, but the current interface is very poor. The icon is unclear and frankly ugly at that size: it looks like a blown up version of something from a user interface like the edit bar. Much better would be a static image of the content, with a right arrow icon over it. This is how much interactive content is presented today on the web, movies but also things like animated GIFs, slideshows, Flash content, including the movies here. That would make it much clearer how it works.--JohnBlackburne^words_deeds 21:47, 7 August 2015 (UTC)

I really appreciate your constructive criticism JohnBlackburne. Replacing the logo for a preview with a play button seemed like an obviously good idea, so I did it right away and it has just been deployed in the Spanish Wikipedia. You can check it out here and here (you may need to do a hard refresh). I have also updated the code required in MediaWiki:Common.js to make this new implementation work, and removed the code for MediaWiki:Common.css, as it's no longer needed.

Two other issues remain (or is there a third?): first, to decide if it would be better to do all the development via Gerrit and have the admins just copy-paste the code into each Wikipedia every time a new version of a wikiwidget comes out, or if it would be better to develop the wikiwidgets in a decentralised fashion on each wiki, like gadgets are currently developed. Let's call the first strategy the "Gerrit strategy", and the second the "on-wiki strategy", shall we? The second issue is to decide if the security risk is manageable.

You have presented very good arguments in favor of the on-wiki strategy. You have convinced me that it has advantages that cannot be replicated by the Gerrit strategy. Nevertheless, I think there are also advantages with the Gerrit strategy that cannot be replicated by the on-wiki strategy. Mind you, I have no emotional attachment to either strategy, just as I didn't have to GitHub. All I want is to do every possible effort to make this project work, as I think it has a lot of potential. Anyway, the advantages I see with the Gerrit strategy are:

First, by having a repository for each wikiwidget, developers can share files and development tools that go beyond the wikiwidget itself. I gave the example of the index.html file. Since I came up with that idea, my development cycles have speeded up enormously, and it would be a shame not to be able to share it with future developers. The idea and code of the index.html file could in principle be shared via some documentation on Wikipedia, but in which one? This may introduce unnecessary language barriers that would be totally avoided by just including the index.html in the repo. This issue may be solved for the index.html file, but I wouldn't be surprised if other larger tools for aiding development arose, which would be even harder to share effectively. The simplest solution seems to be a repository containing all the necessary code and tools for efficient development of each wikiwidget. Also, if we don't do this from the beginning, then it's likely to happen anyway on the background, as it currently does with gadgets, many of which are being developed on places such as GitHub (for example the ProveIt gadget, to which I contribute).

Second, by developing at one central location, new wikiwidgets and new versions of existing wikiwidgets would spread much more effectively. If the Chinese Wikipedia implements WikiWidgets, and some Chinese decides to improve Vivarium, how could I possibly find out, if the developer decides not to tell me, or forgets to? And if the project spreads, this would inevitably become more and more common. By developing at Gerrit, every update to the code would be reported to all the developers involved, so that we may spread the new code to our home projects.

Third, and most important: the security concern. As you said, requiring the admins of each Wikipedia to review code that they didn't write may be unsafe, as well as annoying. If, on the other hand, the policy were to only use code that comes from Gerrit, then only the developers involved in the project would have to review the new code, and we would probably be much more efficient at it than admins that aren't involved in the project. This I think is the key point that tilts the scales towards Gerrit. --Felipe (talk) 02:59, 9 August 2015 (UTC)

@Felipe Schenone: JavaScript should be used strictly for enhancements because some users don't have access to it (or don't have access to the latest versions, for certain features). Accessibility of content is widely regarded as important, and a WikiWidget would clearly be content (the argument that it is an "enhancement" of a placeholder is beyond flimsy). I also echo JohnBlackburne's concerns, both regarding the proposal and the way it's been repeatedly proposed. {{Nihiltres |talk |edits}} 23:38, 6 August 2015 (UTC)

Nihiltres, numbers for Wikipedia may be slightly different, but according to this source, more than 98% of users today use JavaScript. Forbidding valuable content that uses JavaScript because such a small percentage of the userbase doesn't have it (or chooses not to!) is a flimsy argument. It would be like forbidding images because a small percentage of the userbase uses screen readers, or is blind. Do you have another argument? Regarding my argument of the wikiwidgets being enhancements, you're right, it was flimsy, that's why I removed it before you posted. As to JohnBlackburne's concerns, see my reply to him. --Felipe (talk) 00:35, 7 August 2015 (UTC)

Proposal: Integrate Feedback request service and boards like WP:RSN, WP:NPOVN and WP:NORN

I watch WP:RSN, WP:NPOVN and WP:NORN regularly, and sometimes there is a bit of a lean patch and nobody really responds. Sometimes, people who are fighting (sorry, discussing) on the talk page continue their discussion there and outside editors don't respond.

I was wondering if the Feedback Request Service could integrate these pages into it, like it does with RfCs. This would instantly create a random pool of editors who could give opinions there. Kingsindian ♝♚ 23:08, 9 August 2015 (UTC)

RfC for binding administrator recall

Hello. You are invited to comment at Wikipedia:Administrators/RfC for binding administrator recall, where a discussion regarding a process for de-sysopping is taking place. ~ Rob^Talk 05:39, 10 August 2015 (UTC)

Search Request for new articles

Is there a way to find out if a topic has been requested with-out tediously going through all possible categories (e.g., name, alternative names, country, field, subfield) of the requests? Why doesn't a request show up when I do a search? I get all sorts of irrelevant stuff as it is (if there is no direct hit), why can't a note turn up that an article with this name has been requested? This would also eliminate some red requests for articles that have been written (but for which the writer didn't know there had been a request). Kdammers (talk) 09:16, 10 August 2015 (UTC)

User sandbox: Replace "Tutorial sandbox 1, 2, 3, 4, 5" with custom sandbox functionality

Have a look here: User:ManosHacker/sandbox and see how Template:User sand box works. New users can create, fast end errorless, their multi-article sandboxed workplace, fully organized as a list and ready to move sandboxed articles to main article space with simple clicks (mistakes were the rule without these new buttons, when moving from user namespace to main). Zero bites from old users. We have been using it for several months at Wikipedia School as standard practice. Unhide functionality first. Follow sandboxed child articles to see the change of behavior of the template. Hovering gives guidance. Moving a sandbox to an article removes it from the personal sandboxes view list.·· ManosHacker 23:33, 31 July 2015 (UTC)

What exactly are you proposing? Eman235/talk 10:29, 1 August 2015 (UTC)

The proposal is to put this organized workplace functionality inside Template:User sandbox (replace old template with new). It is extremely helpful for new users. It replaces Tutorial sandbox 1, 2, 3, 4, 5 with far more capabilities.·· ManosHacker 11:22, 1 August 2015 (UTC)

• Support. Tutorial sandbox 1, 2, 3, 4, 5 functionality is unneeded and unused. New functionality is proven helpful[3][4][5]. ·· ManosHacker 04:42, 10 August 2015 (UTC)

I fully agree and support the multiple usage of the sandboxes. FYI, I've been currently working simultaneously on several sandboxes (in the Greek Wikipedia) el:Χρήστης:Aristo Class/πρόχειρο/draft Πλουμέρια (this is pending, awaiting a clarification from an expert), el:Χρήστης:Aristo Class/πρόχειρο/draft Χρήστος Γαλανός (this is pending, awaiting to see another source of information-reference), el:Χρήστης:Aristo Class/πρόχειρο/draft Leghorn (this is pending, as needing confirmation from a veterinarian), el:Χρήστης:Aristo Class/πρόχειρο/draft Μακρύ πιπέρι (currently working on this sandbox), etc., so, I take advantage and exploit (to the outmost) my "Wikipedia time". --Aristo Class (talk) 18:48, 10 August 2015 (UTC)

Semi-regular Wikipedia Library Central or Site notices

Hi all, at The Wikipedia Library, we have developed an open research hub that helps editors discover a number of different community-led support services, including the Reference Desk, Resource Exchange, Open Access Guide and our popular free access to donated paywalled databases.

So far the donations have served over 2400 editors across a number of language communities with nearly 4500 accounts. Our main method for communicating these access donations has been bi- or tri-monthly watchlist notices, village pump messages, and social media announcing new partnerships. (see our announcing process here) .

However, we still have a number of partnerships with very useful resources that could benefit a wide range of editors, that have dozens or (in some cases) hundreds of accounts available. We realize that for some of the partnerships, this is because a resource is simply not of interest, but for many more of the partnerships, editors are missing out because our announcements aren’t reaching those who could benefit from free access to research materials. They simply don’t know this program exists.

There are a lot more potential users than the 2400 who already have accounts: most of our accounts are available for free to any editor with 6 months activity on Wikipedia and 500 edits.

We want to establish a consensus around the following: Can the Wikipedia Library run semi-regular (every 4-6 months) English Wikipedia Site- or CentralNotices targeted for signed in editors who likely meet the basic criteria for free access?

The notices will remind editors that a) access to partner resources are available and b) that, even if editors don’t qualify for those partnerships or need our particular sources, other resources exist to help their research and contributions to Wikipedia.

The French Wikipedia Library successfully ran a similar notice several months ago with great success in informing and attracting new editors.

We think this is a valuable opportunity to grow the impact of this program and we want to make sure as many editors as possible benefit from it. We would like to ask for feedback, and thoughts on the proposed notices.

Thanks, Astinson (WMF) (talk) 21:06, 11 August 2015 (UTC)

As a side note, I mistakenly ran another version of this request on Tech Pump, because previous SiteNotices had proposed them there. That conversation, has been redirected to here, Astinson (WMF) (talk) 21:06, 11 August 2015 (UTC)

Sounds great! SemanticMantis (talk) 22:01, 11 August 2015 (UTC)

Default number of search results

Change the default number of search results from 20 to 50, like "View history" pages, log pages, user contribs pages, etc. GeoffreyT2000 (talk) 23:45, 11 August 2015 (UTC)

When making a proposal it can be useful if you explain why you think your idea is a good one. It certainly isn't obvious in this case. Beeblebrox (talk) 23:19, 12 August 2015 (UTC)

Template:Infobox person ii

I created this template in order to be able to view and compare, side by side, wikidata and user data infoboxes. It displays a dual infobox during preview in Source Editor, it does not affect VisualEditor, there is no harm at all if it stays saved inside an article. Just keep it updated, along with WD hidden infobox person template. Check out here. Can be used in any article by adding an " ii" at the end of any Infobox person template name. Enjoy.·· ManosHacker 13:51, 22 July 2015 (UTC)

@Frietjes and Plastikspork: -- Magioladitis (talk) 16:25, 22 July 2015 (UTC)

if this is needed, it should be merged with template:infobox person rather than creating yet another frontend that must be maintained. @Mr. Stradivarius and Jackmcbarn: Frietjes (talk) 16:36, 22 July 2015 (UTC)

Yeah, this should just be a feature of the real template, that can be enabled in preview mode.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  16:47, 22 July 2015 (UTC)

I agree. -- Magioladitis (talk) 16:55, 22 July 2015 (UTC)

It's been made separate to show the potential and allow error checking. I also agree to a merge within the real template.·· ManosHacker 23:59, 22 July 2015 (UTC)

Understood. I agree it's helpful.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  19:47, 26 July 2015 (UTC)

It would also be handy to be able to link to wikidata entries for corrections/additions.·· ManosHacker 00:23, 23 July 2015 (UTC)

ManosHacker I think the problem is that in the English Wikipedia we are still not ready to obtain info from Wikidata in that large scale yet. -- Magioladitis (talk) 12:29, 23 July 2015 (UTC)

There is no reasoning or request to import from Wikidata to the article. This is a tool to compare automatic and manual data side by side during preview, just to help correct mistakes and update, either Wikipedia or Wikidata. It does not affect the article itself, only the preview of the source editor is affected.·· ManosHacker 13:08, 23 July 2015 (UTC)

Templates are now merged, Infobox person can be replaced by ii version

It is now merged with Infobox person and works like a charm. No need for updating both Infobox person and Infobox person ii during changes. I propose to implement it as an option for advanced users.·· ManosHacker 13:42, 23 July 2015 (UTC)

It can be used, but not merged in one template, as it will not pass loop test. Merging will always require two external child templates and template update will always be tripple.·· ManosHacker 16:44, 23 July 2015 (UTC)

That was a bit telegraphic. Is there a proposed solution then?  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  19:47, 26 July 2015 (UTC)

Update

Successfully merged WD hidden infobox person inside Infobox person ii.·· ManosHacker 15:12, 30 July 2015 (UTC)

Proposal: Nest old template inside new, make this feature optional and not pre-selected

Purpose

Preview, side by side, the manually filled in infobox person to a mirror infobox that is filled in automatically with Wikidata entries

Target

Compare and update data in either side, effortlessly

Feature

Wikidata infobox appears only during source editor preview, disappears in article view, old article version view, VisualEditor

Inconvenience

Having to keep both templates synchronized (but is very straightforward process and new template is very clean)

Steps (technical)

1. Call Infobox person i instead of Infobox person , inside template Infobox person ii
2. Move Template:Infobox person to Template:Infobox person i without redirect
3. Move Template:Infobox person ii to Template:Infobox person without redirect
4. Put link to Infobox person i , inside Infobox person usage help, to easily keep both templates synchronized

Future

Enhance wikidata template to link to Wikidata edit / update (edit value popup or wikidata page link)

---

• Support ·· ManosHacker 18:59, 27 July 2015 (UTC)
• Strongly Oppose unless this is made somehow opt-in only. When I am reviewing a change to an infobox in p[review mode, i don't want it cluttered with a 2nd infobox full of data that I don't trust and that will not be used in the article. More importantly, when an editor who has never heard of wikidata (which is most of out editors) uses preview mode, s/he should not see a preview made intentionally wildly different from the actual article display. Preview is intended to preview what an article will look like after an edit. It is an abuse of preview to display data that will not be displayed after the edit, except possibly in response to some setting or parameter that only editors who explicitly want such a display will set, and which will never be left in place to confuse future editors. DES ^(talk) 16:26, 30 July 2015 (UTC)
• Oppose DES objections are well founded. Anything fields that wikidata needs should be added - by WP:CONSENSUS to the current infobox. If that can't be done then perhaps persondata should not have been deprecated. MarnetteD|Talk 19:38, 30 July 2015 (UTC)

No doubt it will be optional, if implemented, and not pre-selected. It is made to help check for errors, not confuse people. Making it optional is beyond my current knowledge, an experienced user could help us on this.·· ManosHacker 21:06, 30 July 2015 (UTC)

I have no objection to a strictly optional feature intended for testing, as long as it doesn't unduly burden the normal use of the template. But is this proposal really ready for discussion before such an optional version is sandboxed? If we are discussing on an in-principle basis, I wouldn't expect to use this, but wouldn't object if it is optional, not the default, and doesn't impose significant cost on the very frequent normal use of the template. The discussion above sounded to me to imply that this would be always on, or on by default. DES ^(talk) 21:28, 30 July 2015 (UTC)

In Greek Wikipedia, wikidata automatically fills in the infobox and can be overriden only by filling infobox entries by hand. The result is a mixed infobox render and people get confused, unless wikidata values are rendered with different colour or icons (--) are used. I would use dual infobox by default there. English Wikipedia has a different approach and dual infobox should stay optional here.·· ManosHacker 22:40, 30 July 2015 (UTC)

It seems to work fine directly, but these templates also call it and we would have to check it there, too. Some expert could run tests to see if it is heavy for the system, I think not, and fetching wikidata would only be true for those who select to enable it and only during preview.·· ManosHacker 22:32, 30 July 2015 (UTC)

• Support, barring any devils in the details. An optional tool like this would be useful.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  22:51, 3 August 2015 (UTC)

Checking is done, to see if the template works nested, inside other templates, and it works fine. Template:Infobox artist ii is created, in which Infobox person ii is called. Preview this: Caravaggio, where it reveals that date of birth is to be corrected.·· ManosHacker 09:50, 6 August 2015 (UTC)

@DESiegel, MarnetteD, Frietjes, Plastikspork, Mr. Stradivarius, Jackmcbarn, and Magioladitis: It's been tested for more than 3 weeks (there are already 34 revision changes in Michael Jackson), works without error even nested inside other templates like infobox artist (Caravaggio), it is not heavy and it will be optional. Please update.·· ManosHacker 03:12, 14 August 2015 (UTC)

Should the Community portal encourage creation of articles about missing highly cited female scientists?

Please see the RFC at Wikipedia talk:Community portal#Highly cited women scientists without articles. EllenCT (talk) 15:16, 14 August 2015 (UTC)

There is a section at Wikipedia:WikiProject Missing encyclopedic articles/Thomson-Reuters most cited scientists#Missing woman scientists. Praemonitus (talk) 20:54, 14 August 2015 (UTC)

Register move log entries both under the target and the source title

Currently, when you move a page, the move gets registered only in the move log for the source title but not in that for the target title. This makes it hard to reconstruct the history of pages that have been repeatedly moved in the past. If, for example, a page has been repeatedly moved between two locations in a move war, only half of this story is documented in the move log for any one title. (Of course, the move log entries are also mirrored in the edit history, but there they may be separated from each other by many pages of normal edits, so they can be quite difficult to find.)

I've often thought that it would be much easier to follow such a history if a move simply created two page log entries simultaneously, one in the log for the target location and one in that of the source location. In this way, the move log for any title would document not only where a page went, but also from where it came. Fut.Perf. ☼ 07:33, 13 August 2015 (UTC)

Yes please. We no longer use moves & deletions to hide bad revisions (in the time before revdel and before oversight, it was done using selective deletions, restorations and moves, and hard to figure out afterwards even for admins). Being able to trace the move history easily has no downsides I can think of, and would make any kind of research into an article's history much less painful. —Kusma (t·c) 08:40, 13 August 2015 (UTC)

• Support. This will make things a hell of a lot easier, it's often a nightmare trying to find where moves were made, especially on high traffic pages. I'd also recommend doing the same thing for history merges using Special:MergeHistory, currently it only leaves a log entry at the source location but not the destination. Jenks24 (talk) 12:26, 13 August 2015 (UTC)
• Oppose Instead, have two textboxes, one for the old title and the other for the new title. If neither of them is blank, then the log will show all moves from what you put in the old title textbox to what you put in the new title textbox. If either of them is blank, then the log will show all moves from what you put in the old title textbox, or to what you put in the new title textbox, whichever one is not blank. If both are blank, then the log will show all moves. GeoffreyT2000 (talk) 14:01, 16 August 2015 (UTC)
  • That would no doubt be elegant; the question is how difficult it would be to implement. If I'm not mistaken, MediaWiki currently has a rather rigid internal concept of what a log entry is; across all types of logs it always involves one performer and one affected target (user or page). Currently what's stored in the "affected" field in the case of moves is the source location; the target location is only mentioned in the summary. Without having two separate log entries, your proposal would probably require either a redesign of the internal representation of log entries in the database (allowing two affected targets stored in the same log entry) or a new mechanism of searching and filtering log entries (based not on the target field but on parsing the summary text). Simply creating two log entries simultaneously would be the cheapest option to implement. Fut.Perf. ☼ 14:24, 16 August 2015 (UTC)
• Support Useful feature. Iceblock (talk) 15:01, 16 August 2015 (UTC)

Tool for identifying "cliques" on WP

(I do not know if this is the correct place.) After some bad recent experiences with socks (thankfully many of them blocked), I thought of this. Does there exists a tool to analyze editors in a particular area? I could think of some very simple criteria to identify "cliques", which would perhaps be useful for WP:SPI and or even more general purposes. Two easy criteria are:

• X agreeing with Y in RfC/AfD !votes etc. associates X with Y.
• X reverting an article to a version by Y, associates X with Y. (the revert is directed "against" a person rather than towards a person, but I couldn't think of an easy way to model this).

One could then create a graph of various editors and perform some sort of clustering. The criteria are not infallible, but I would think they would be a decent start. One could think of other similar criteria, perhaps with less or more weight. Kingsindian ♝♚ 11:43, 14 August 2015 (UTC)

I don't think this is such a hot idea. If you suspect socking, you should be able to find the evidence yourself. This seems like it would encourage fishing expeditions. Beeblebrox (talk) 22:40, 14 August 2015 (UTC)

Yup, my thoughts too. More or less guaranteed to generate a lot of false positives, and open to abuse accordingly - if you want to harass someone, run the clique-spotter and then report the results. It is more or less inevitable that such a test will provide some sort of 'evidence' even by chance - and agreeing with someone else in AfDs for instance may indicate nothing beyond an interest in similar topics, and a correct understanding of Wikipedia policy. AndyTheGrump (talk) 22:50, 14 August 2015 (UTC)

I am not sure it is a hot idea myself, but I don't see how it would be open to abuse. It's just a tool, like the editor interaction tool which is present on WP:SPI. Just because two people edit the same page doesn't mean they are socks, the same principle applies here. Kingsindian ♝♚ 02:47, 15 August 2015 (UTC)

Perhaps you should clarify what it is this tool is supposed to detect. What are the inputs, and what are you expecting to get as an output? AndyTheGrump (talk) 03:26, 15 August 2015 (UTC)

This is a bit vague in my mind, but the input is simply an area of interest. I, for example, work a lot in WP:ARBPIA. You then look at a set of users working in the area, and make associations between them based on the method I described above. Then you cluster them, and the output is the clusters. Kingsindian ♝♚ 03:32, 15 August 2015 (UTC)

Well yes, I'm sure you will get clusters. You'd get clusters if the input data was entirely random. But we know that it isn't. A lot of people editing in the WP:ARBPIA area have perspectives in common. Quite possibly you would find a 'pro-Israeli' cluster, and a 'pro-Palestinian' cluster - in fact, I'd be very surprised if you didn't, and would probably suggest that the tool was broken. But so what? It doesn't tell you anything you didn't already know - that when it comes to controversial topics, there are people inclined to support one perspective over another. All you have done is link people who agree. And agreeing with someone else isn't against Wikipedia policy. So what are you proposing the output data be used for? AndyTheGrump (talk) 03:59, 15 August 2015 (UTC)

To be frank, I have only a vague idea of what I want to use it for. As I said at the top, I am not sure if this is the right venue for this proposal. I was mainly interested in whether anyone had done something like this before. With some vague idea that it might be useful in SPIs. Also, as an interesting experiment. Kingsindian ♝♚ 04:05, 15 August 2015 (UTC)

Given that all the data required is publicly available, there is nothing in theory at least to prevent anyone doing the experiment. As for using it for SPIs, that rather suggests the fishing expeditions that Beeblebrox alluded to. SPIs are only supposed to be conducted when there are reasonable grounds to suspect specific accounts are socks of each other - submitting a 'cluster' to see what came out would be rather questionable. I've opened a few SPIs myself, and know that you generally need to provide specific diffs linking the accounts, and suggesting that they are up to no good one way or another. This often comes down to spotting the sort of behavioural clues that no program is likely to detect. And besides the nitty-gritty questions as to whether the tool would be useful, there is also the issue that WP:AGF is being somewhat neglected when edits that nobody has previously suggested are questionable are subjected to systematic mass inspection. I'm not sure our contributors would be happy with that. AndyTheGrump (talk) 05:36, 15 August 2015 (UTC)

Per Andy, SPI is really for confirming what behavioral evidence has already established as likely. And behavioral evidence is much more than just editing the same articles. For example, two people who fight with each other alot and bicker and follow each other around to taunt each other may end up editing the same articles, it wouldn't make them sockpuppets. Any person would instantly recognize them as edit warriors who are just fighting with each other (a problem of itself, but not sockpuppetry), and yet your proposed tool would falsely tag such people as socks. SPI should be as a secondary confirmation for what, based on behavior, we suspect to be invalid secondary accounts (socks) and NOT for fishing expeditions looking for socks where none such behavioral evidence exists excepting a coincidental alignment of interests. --Jayron32 06:00, 15 August 2015 (UTC)

@Jayron32: I am not sure if you have understood what the tool is supposed to be doing. In the example which you give, the tool will not "tag those people as socks" (it does not tag anyone as socks), nor will it put the two people in the same cluster.

@AndyTheGrump: This is not meant to replace giving diffs in SPI cases, nor will it lead to fishing, just as the editor interaction tool does not do so. This will likely be used as a investigative/analysis tool, nothing more. Anyway, I will check out the technical details on how hard it would be write such a tool. Kingsindian ♝♚ 19:21, 15 August 2015 (UTC)

At least one tool along those lines existed a few years ago; I don't know whether it still works. It made a list of pages that any two named accounts had edited. However, you had to give it the names of the suspected socks yourself. Also, I believe it was "expensive" (in terms of computing resources), so it was not available to everyone (via simple password protection). WhatamIdoing (talk) 03:37, 15 August 2015 (UTC)

User:WhatamIdoing: The "wikistalk"-tool used to be available to everyone; I used it a lot to build CU-cases. Unfortunately now down. I have asked if it is coming up again.

Another interesting alternative is discussed over at User_talk:Philippe_(WMF)#Blocking_tools. Blocking devices, instead of IPs, makes great sense to me (I edit in the extremely sock-infested area of Israel/Palestine) Huldra (talk) 23:11, 16 August 2015 (UTC)

Let's have a drive to wipe out the list of articles with multiple disambiguation links.

Thanks to the diligent efforts of disambiguators, the list of articles with three or more disambiguation links on the page has recently fallen under a thousand for the first time, and now stands at 850 (some of which have also already been fixed, the page updates daily). The entire list now fits on this page. That means that if we could get 84 Wikipedians to each fix just a dozen pages, the list would be done. Let's do this. Cheers! bd2412 T 14:16, 5 August 2015 (UTC)

Great work, BD2412 (and all the other disambiguators). I've done my 12. Ry's the Guy ^{(talk|contribs)} 08:52, 6 August 2015 (UTC)

I did my dozen --S Philbrick(Talk) 17:07, 7 August 2015 (UTC)

I did a few partials - slow going on some. I nominate User:DerUhrmacher to tidy up the current high score, Chronological list of famous watchmakers. Since they wrote almost the entire article (and recently!), they are in the best position to know where all the DAB links should go. The tool listed above should make it fairly quick :) SemanticMantis (talk) 22:23, 11 August 2015 (UTC)

It's under 700 now. 60 Wikipedians taking on a dozen pages each would clean it right up! Or 120 Wikipedians cleaning up six pages each. bd2412 T 16:42, 17 August 2015 (UTC)

Proposal for article display on mobile web

Hello Folks,

There are proposed design changes for how the lead section of the article could be displayed on mobile web. The rational and specifics of the change are elaborate on mediawiki page. Please check and add your suggestions to the talk page. Thanks --Melamrawy (WMF) (talk) 22:42, 17 August 2015 (UTC) :-)

Asking for endorsement for “Wikipedia Treks Kalindi Khal”

Dear my fellow Wikipedians,
Greetings from Kolkata, India.
I am pleased to inform you that we are going to organize a expedition project “Wikipedia Treks Kalindi Khal” under “Wikipedia Treks Mountain “in September 2015.
This is a high-altitude trekking expedition from Gangotri to Badrinath in the Garhwal Himalayan region of India, targeting all language editions of Wikipedia, Commons, Wikspecies, Wikivoyage and other WMF projects. The overall purpose of Wikipedia Treks Kalindi Khal is to increase the material related to Himalayan Range with a free license in Wikimedia Commons and improve the quality and increase the amount of articles about diversifying Himalayan mountain range and other respective variety in different languages in Wikipedia. Reaching out to the majority of Himalayan mountain range during this trekking program will not only raise awareness among various community chapters, but also motivate them to contribute to the Wikimedia projects and organize this kind of trekking expedition in future.
I just need an endorsement from all of you for this unique project

Feel free to discuss about the project in the discussion page.
Thanks in advance,
With warm regards,
Sujay25 (talk) 20:08, 18 August 2015 (UTC)

Fix the File Upload Wizard

Currently when using the WP:File Upload Wizard, you can upload somebody else's work with the option "I haven't got the evidence right now, but will provide some if requested to do so". What is the point of this? It means that unless an upload patroller notices it and asks we just have unverified files. Moreover since a license is supposedly provided, they are not caught by ImageTaggingBot. In my opinion we should remove this option in order to prevent there being a back door for dubious uploads. In effect, this is just making the request, which they have said they will fulfil, immediately. Opinions on whether/how to do this? BethNaught (talk) 14:17, 19 August 2015 (UTC)

Which page is that quote on? I could not find it. Alanscottwalker (talk) 14:54, 19 August 2015 (UTC)

The text "I haven't got the evidence right now, but I will provide some if requested to do so" appears in the upload form when you click on "This is a free work" and then "This file was given to me by its owner". What appears on the actual upload in these cases is "Evidence: will be provided on request". This issue has been discussed repeatedly on the wizard's talkpage, most recently at Wikipedia talk:File Upload Wizard/Archive 2#Evidence: Will be provided on request. and Wikipedia talk:File Upload Wizard/Archive 3#Letting through too many images without permission, which also contains my explanation (as the original author of the tool) of why I put it in. Fut.Perf. ☼ 15:03, 19 August 2015 (UTC)

You make a depressingly pragmatic argument. Thank you for the explanation. Consider my suggestion withdrawn. BethNaught (talk) 22:09, 19 August 2015 (UTC)

(slight technical problem with this page ??)

When the next section is minimized then the 5 sections following it are not showed.SoSivr (talk) 10:18, 20 August 2015 (UTC)

in the mobile versionSoSivr (talk) 10:23, 20 August 2015 (UTC)

Template break

(regarding template {{break}} which uses Lua module Module:break). In my opinion

{{break|0}}

should produce ZERO line breaks and not ONE (just shown here) which it does now.SoSivr (talk) 10:54, 20 August 2015 (UTC)

This would be better at Template talk:Break. Eman235/talk 19:29, 20 August 2015 (UTC)

RfC: Should Template:English variant notice be deprecated?

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.

The consensus is to oppose the deprecation. The opinion is that it is useful and on many pages. There were questions raised about the propriety of this RFC. But the discussion linked to was not closed, and it was wise to get a larger view on this question that may affect many pages. So I am closing this one. AlbinoFerret 06:47, 29 August 2015 (UTC)

---

A discussion recently took place concerning whether Template:English variant notice should be deprecated. I've decided to raise the issue here (unfortunately when I became aware the discussion was already archived) to determine a broader consensus (as there wasn't that much participation). It seems to only be deprecated "on paper" at the moment as the latter conditions of the proposal below don't seem to have been put into motion.

Original proposer's rationale- I propose that {{English variant notice}} (see example usage just above – it creates huge banners on article talk page) be formally deprecated. Then replace with the unobtrusive versions (e.g. {{Use British English}}; these go at the top of the article and do not display anything). Then take {{English variant notice}} to WP:Templates for discussion and delete it.

The template itself has also been considered for deletion in the past.

—Godsy^(TALK_CONT) 07:00, 14 August 2015 (UTC)

Just a gentle reminder that the following two sections for "Support" and "Oppose" are reserved for only those rationales. If discussion about any rationale is desired, then please use the "Discussion" section at the bottom of this proposal. Thank you for your help, as this is an organizational approach that aids the closer. – Painius  19:43, 14 August 2015 (UTC)

WP:PROCESS is important. Village pump does not exist to "ask the other parent" immediately after the close of a discussion Godsy isn't happy about.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  21:55, 16 August 2015 (UTC)

Yes, I agree that Wikipedia:Process is an important essay that contains a quote by Jimmy Wales in the first section that pretty much covers it all. – Painius  23:26, 16 August 2015 (UTC)

Support (Yes, deprecate the template)

• This is forum-shopping and out of process The template has already been deprecated, its categorization functions to be merged into to the hidden corresponding mainspace templates, and the WP:OWNish banners WP:TFDed. The TfD is already half written. None of the "oppose" comments below appear to have even read the prior discussion. It is "broke", and the fix is merging the functionality of these templates and no longer browbeating editors again and again with enomorous WP:ENGVAR warning templates. ENGVAR is an MOS matter, and no consensus was ever established to "enforce" MOS (a guideline, not a policy) in such a heavy-handed manner. It's been reviewed and found severely wanting.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  14:30, 14 August 2015 (UTC)

Very interested in knowing how it's "broke." Provide details in discussion section? Darkfrog24 (talk) 21:33, 14 August 2015 (UTC)

• Support on procedural grounds. One doesn't get to "lose" (for lack of a better term) a discussion in one venue and then go running to another venue to overturn it. GregJackP Boomer! 16:09, 14 August 2015 (UTC)
• Support. After studying this at great length, I've decided to come out in support of SMcCandlish's work on this, as well as the other editors involved. In a nutshell, I say we support the deprecation of all these templates, because there are so many supposed varieties of English in the world that it's almost scary how many of these templates may potentially be made. There are Ethiopian English (and many others in Africa), Vietnamese English (which is an interesting mixture that is quite tonal) and, since English is effectively, although "officially" unrecognized as, the global/universal language, there are many, many more. So from a "style" point of view, I agree with most of what Blueboar stated in the previously archived discussion, and I personally feel that at least most if not all of these language templates should be deleted. I say we support the present status and see how they all do at TFD. – Painius  21:41, 16 August 2015 (UTC)
• Clarification: Deprecation does not mean deletion. Deprecation does not mean "you can't use this". TFD is WP:Templates for discussion not "deletion". So, don't panic. The goal is to merge the categorization functions of the huge banner versions of these templates into the "quiet" versions of the templates, e.g. {{Use British English}} (which are not deprecated, and do some other cleanup (e.g. merge redundant varieties). Then see what TFD (the actual venue for the discussion of whether to keep templates) comes to a consensus to do something with the banner versions: they might be deleted, or limited in scope to use only on pages where there's a clear consensus to use them, or made smaller, or limited to talk page use only, or editnotice use only, or merged into geographic wikiproject banners, or who knows. That's what TfD is for. A panicky and misleading WP:PARENT attempt to overturn a just-concluded discussion the re-nominator doesn't like, is not in a position to tell editors in a consensus discussion at WT:MOS (i.e. WT:MOSENGVAR), one of the most-watchlisted pages on the system, and the proper venue for the discussion, whether they are "allowed" to come to a consensus that MOS:ENGVAR was not intended to be "enforced" in this manner by MOS:ENGVAR templates. Those who think the templates have some kind of value are welcome to comment at the TfD, which this pointless pseudo-RfC has delayed. I've opened a request at WP:ANRFC#Administrative to see this closed quickly.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  22:31, 16 August 2015 (UTC)

Oppose (No, do not deprecate the template)

• Oppose - Editnotices appear anytime someone edits a section, the alternative proposed only appears when editing the lead or the page as whole (at the top of the article). This is problematic because the notices will not be seen by some editors. This template is also used on article talk pages. It lets editors know that it is generally unacceptable to change the current variety of English used without consensus (WP:RETAIN), if this is their question or concern. Both having these present as an editnotice and on the talk pages are especially helpful to new users. It helps all users making a quick change or addition easily identify which variety of English to use if it's applicable.—Godsy^(TALK_CONT) 07:00, 14 August 2015 (UTC)
• Oppose I pointed out the edit section rationale above to Godsy elsewhere. I have seen many articles (particularly lists) where there are HTML comments over and over again saying, "Adhere to [X] English variant" or "any additions to this list need a source" etc. because of some small and persistent issue with editing. Editnotices in general decrease these problems by increasing visibility. Simply tagging {{Use British English}} at the top or bottom (or even worse, a contraction like {{EngVarB}} or somesuch) will not explain to all users what this means or how to use it while editing an article. I am definitely in favor of these editnotices and think that they serve an important function. —Justin (koavf)❤T☮C☺M☯ 07:21, 14 August 2015 (UTC)

• Yes, I adapted part of your comment elsewhere into my own rationale. It's quite sound reasoning.—Godsy^(TALK_CONT) 07:26, 14 August 2015 (UTC)

• Oppose - The current template may be clunky, but the proposed alternative is inadequate, and the current version works. AlexTiefling (talk) 08:55, 14 August 2015 (UTC)
• No need Is the template creating some kind of problem or do some of us just not like the way it looks? A larger and more visible template may be appropriate in articles that have been subject to or are at risk of too many well-meaning changes in variety. I see no reason not to let the editors choose which warning label to use. Darkfrog24 (talk) 12:31, 14 August 2015 (UTC)
• Oppose The argument seems to be that it's clunky taking up too much room, that it could be used as a staking of claim to territory and that it would encourage edit warring. Just randomly picking a few of the talk pages it's used on, this template seems to be one of many talk page notices taking up a very small proportion of the space. Could it be abused for making a territorial claim? Perhaps but the same can be said for the {{use ... English}} templates. The suggestion that it would encourage edit warring seems to be conjecture; where's the evidence of this? It seems a useful template. I say we undeprecate it. Jimp 12:48, 14 August 2015 (UTC)
• Oppose If it isn't broke, don't fix it. I think everything above has been said - I don't see a need for a change as the current template works fine. Either way, an alternative could make things less accessible. JAGUAR  13:18, 14 August 2015 (UTC)
  • See the above comment; also, what proof is there that it works? Dustin (talk) 14:53, 14 August 2015 (UTC)
• Oppose per Godsy. If it only appears when editing the whole article, and not when editing a section, it's not a proper replacement strategy. There should he a talk page notice describing what dialect the article is written in, and if necessary (when dialect is repeatedly mixed or flipped by editors), an edit notice when editing the articles. Obviously, edit notices should not appear as the default strategy, only when problems crop up should they be turned on. But deprecating edit notices does not serve to keep editwarring down nor keep articles using consistent dialect. Further, having talk page notices does serve to inform editors as to the accepted state of the article, and what dialect is being used. So deprecating talk page notices is similarly not going to help keep articles consistent. -- 67.70.32.190 (talk) 05:01, 15 August 2015 (UTC)
• Oppose if the notice does not appear when editing sections it is not a full replacement. I have a lot of color term pages on my watch list, and have seen many well meaning editors do the colour<=>color and grey<=>gray replacements especially on pages when editing sections. PaleAqua (talk) 18:58, 15 August 2015 (UTC)
• Oppose - articles can become in dispute of simply just because of what type of English is needed. A clear box is needed to show what type of English is needed, rather than a silly template that only gives an invisible category. Do you all agree with me? Qwertyxp2000 (talk | contribs) 01:39, 16 August 2015 (UTC)

Neutral

• Note: – Painius ' neutral !vote has become non-neutral (see above), so the post was placed in the Discussion area in chronological order. – Painius  21:50, 16 August 2015 (UTC)

Discussion

Is the template creating some specific problem or is this just an objection to the way it looks? Darkfrog24 (talk) 12:32, 14 August 2015 (UTC)

A more complete description of what some contributors think is wrong with the template in question can be found at the link to the archived discussion in the first sentence of this proposal. – Painius  19:36, 14 August 2015 (UTC)

Not really. I see "eyesore," "make things simpler," "territorial claims" but no details. "Eyesore" is self-explanatory but the others are not. Was there any specific case of someone causing territorial trouble using one of these templates? Make things simpler in what way? Darkfrog24 (talk) 21:31, 14 August 2015 (UTC)

Well, I didn't say "complete description", I said "more complete". Did you also note the disparity in the number of contributors present in that discussion vs. the community members who participated in the Snow Keep discussion? Maybe that was what the second supporter above meant by "losing" and then reopening? sort of an "Adlerian slip" (rather than "Freudian")? – Painius  21:47, 14 August 2015 (UTC)

What snow keep discussion? This one? [6] Yeah, there were more people. "Deprecate" and "delete" aren't exactly the same, though, and I've seen subtle differences in intent produce big differences in response. Still. Darkfrog24 (talk) 00:10, 15 August 2015 (UTC)

Yes, that's why this needs to go to TfD, with an analysis (I've been working on this) of exactly which templates are categorizing how, and what merging of functionality needs to be done, etc., before any of them can (or should) be deleted; none should be deleted without such an analysis, and scope limitation, e.g. to editnotices on certain kinds of articles, etc., might result). This forum shopping thread is an untoward Chicken Little action. The sky is not falling.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  22:36, 15 August 2015 (UTC)

Whether it's meant to deprecate of delete, what problem is doing so meant to solve? Darkfrog24 (talk) 00:37, 17 August 2015 (UTC)

Propriety of this RfC

• While I personally couldn't care less about this template, I just read the rationale's of the supporters, and I have to ask, is this just ban AGF week, or what? There is absolutely nothing that stands in the way of any contributor's prerogative to reopen a closed, archived discussion – NOTHING. Or did somebody forget to read {{aan}}? Next, as this proposer mentioned, the previous discussion was already archived before it was even known about, so how the hell is this a case of somebody reopening a discussion that they had lost??? Time to get a grip and start talking about WHAT IS RIGHT, and pay no attention to who is right, okay? – Painius  18:55, 14 August 2015 (UTC)

• @SMcCandlish: While the statement "ENGVAR is an MOS matter" is true, it conflicts with your statement elsewhere that "of templates for which there was never a consensus to begin with at MOS for "enforcing" MOS:ENGVAR [in this manner]". MOS:ENGVAR is a MoS issue, but that talk page isn't necessarily the best forum for the deprecation discussion, because as you said: consensus for them was never established there (I'm assuming that is true based on your statement). You can't eat your cake and have it too. A better original forum for the discussion would have perhaps been at Template talk:English variant notice or here. As this concerns many templates (e.g. {{American English}}, {{British English}}, {{Canadian English}}), and the other 10 or so templates), perhaps a notice on each of their respective template talk pages would have been and is now warranted. "WP:VPPRO wouldn't even be the right venue for such a discussion anyway; it would be WP:VPPOL", post a notification on WP:VPPOL if you'd like. I don't think the previous discussion with only four supports is a valid consensus for the deprecation of templates that appear on 10,000+ pages. Notices do not seem to have been posted anywhere (please correct me if I'm wrong); it didn't seem that there was enough participation for a matter with such far-reaching effects; the previous discussion wasn't formally closed and was automatically archived. The deprecation notice on the template documentation was jumping the gun a bit, and the community wasn't really properly notified about the first discussion.

@GregJackP: I don't quite understand your rationale, especially if "one doesn't get to "lose" (for lack of a better term) a discussion in one venue and then go running to another venue to overturn it" is directed at me. I was not aware of the discussion until Koavf inquired about the deprecation at this TFD, and I did some investigating on the matter.

Respectfully,—Godsy^(TALK_CONT) 03:10, 15 August 2015 (UTC)

There's no self-contradiction at all in what I said. WT:MOS is the normal venue for determination of MOS-related matters. Running to [the wrong section of] the VP to head off an impending TFD discussion following and already concluded MOS discussion about these same templates is inappropriate if done with that intention, and just unhelpful and counterproductive otherwise. Per WP:BUREAUCRACY and WP:LAWYER, merging these templates should not be a lengthy, repetitive process of "litigating" the matter at one venue, a "higher" court", then an even higher one. There's a consensus to merge the templates, and a TfD discussion will cover the details of how this is done (and possibly even conclude that maybe this consensus should change, on a basis relevant to how the templates are used). This VP post is a "drum up a bunch of FUD" action. I've asked WP:ANRFC to speedily close it as out-of-process.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  22:35, 15 August 2015 (UTC)

I did know that the original proposal suggested TFDing the templates, I had no idea there was an "impending TFD" discussion", and my intent was not to "head that off". I re-opened/started this discussion here (which was never formally closed, it was archived however) to improve the quality of the discussion by broadening participation to more fully achieve consensus. As I stated before I don't think the proper places were notified about the MOS Talk Page discussion, and I think this page is an appropriate venue to have the discussion. I replied to your request at WP:ANRFC#Administrative, and I think a closure of this discussion would be highly inappropriate. Per WP:CONLEVEL, "Consensus among a limited group of editors, at one place and time, cannot override community consensus on a wider scale". The first discussion was a subsection of another topic and wasn't even an RfC. The only reason I can think of to be opposed to a larger discussion, with the appropriate parts of the community properly notified, is that the proper consensus might be different. Opposition on procedural grounds seems more like WP:LAWYER and WP:BUREAUCRACY, than simply wanting a better discussion on the matter.—Godsy^(TALK_CONT) 01:30, 16 August 2015 (UTC)

It's ridiculous that you're quoting CONLEVEL, when you're trying to overturn a consensus you don't like, on one of the most-watchlisted pages on MOS, by using a ping list almost entirely consisting of editors of the template, to create a microconsensus in favor of keeping it. It's farcical, it's WP:PARENT, and it's WP:CANVASSING, whether you meant it that way or not. Only a tiny fraction of the articles on which this bludgeoning template have been WP:FAITACCOMPLI inserted robotically, show any consensus for such a template to be there. The reason to be oposed to re-re-re-opening the same discussion to get the result you want is codified very clearly at WP:FORUMSHOP.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  22:38, 16 August 2015 (UTC)

@SMcCandlish: I notified just a handful of editors to edit the Meta, American, and British templates within the last 6 months or so. The rest were as follows: Those who participated in the last TFD which is part of what this proposal suggests Wikipedia:Templates for discussion/Log/2013 September 7#Varieties of English templates), everyone who participated in the first discussion on the MoS talk page (Wikipedia talk:Manual of Style/Archive 167#Sub-national varieties of English?), and those involved in the TFD where the deprecation was mentioned (Wikipedia:Templates for discussion/Log/2015 August 9#Template:AmericanEnglish). I also posted a notification on the MoS talk page (Wikipedia talk:Manual of Style#Request for comment: Deprecation of the Template:English variant notice which I'll note someone else changed the section title) and the meta templates talk page (Template talk:English variant notice#Request for comment). It wasn't WP:CANVASSING and, quite frankly, I'm tired of these unwarranted accusations. If you feel my conduct or behavior was inappropriate take it to the appropriate forum.—Godsy^(TALK_CONT) 22:58, 16 August 2015 (UTC)

@Paine Ellsworth: I wouldn't be against the deprecation and possible deletion of some of the templates, but I am against those actions on the meta-template and specifically the British and American (and probably a few others as well), which are the most used. Some of them are perhaps redundant/not necessary, or could use a merge. The two templates I've mentioned are very useful, and help inform that it isn't generally helpful or appropriate to change the variety of English used in an article.—Godsy^(TALK_CONT) 22:41, 16 August 2015 (UTC)

Yes, I tend to agree with that for the most part, Godsy. And yet, I've always been more of a "content" editor and have not indulged too much in the "styles" that are extensively covered by Wikipedia:Manual of Style and its subpages. This has meant that I've sometimes been guilty of unqualified edits and soundly reverted by those more knowledgable in the particular style I stomped on. I usually leave these matters to those contributors who are far more interested in style than I am. I'm just being honest here and am not in any way making any negative implications toward any editor nor group of editors. In this particular case I have had a very limited experience with these language templates and do feel that at the very least, many of them should not exist (hence my support for letting Wikipedia:Templates for discussion sort it all out). – Painius  23:01, 16 August 2015 (UTC)

Even though the previous discussion looks like it was carried out in good faith, it had a significantly smaller turnout than this one. While that doesn't necessarily make it invalid I see no problem in a similarly good-faith effort to get more people to contribute. It's valid to revisit an issue if it looks like consensus has changed or would change. I see this as a reasonable extrapolation of that idea. Darkfrog24 (talk) 00:42, 17 August 2015 (UTC)

Yes, targeted canvassing does tend to increase turnout.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  05:15, 17 August 2015 (UTC)

That thread began on 11 June and the latest post in it was made on 26 June. The bot that archives the MOS talk page does so seven days after the final post was made. That brings us to 3 July. That's roughly two weeks of discussion followed by one week of just sitting there waiting for either another post or to be archived. As has been previously noted, on a highly watched page like the MOS, where no one knows how many people come, read, then decide not to contribute, three weeks was sufficient to garner enough consensus to begin the process. As far as trying to make this particular concerned effort here at the pump look bad by throwing ugly words around like "canvassing", "forum shopping", etc., that's not something with which I agree. In fact, I feel that such comments just slow the process down even more. If that is what the commenter wants, then by all means continue to kick a dead horse. – Painius  08:39, 17 August 2015 (UTC)

SmC, publicizing increases turnout, and it's not only allowed but encouraged (WP:APPNOTE). It only becomes canvassing if it's done to skew the outcome. It would have been spamming if the notes were indiscriminate, but Godsy's rationale shows that he/she at the very least did not intend to spam. It would have been votestacking if Godsy disproportionately alerted people whom he or she thought would agree with his or her position, but that's not what happened. When I got my alert, the first thing I did was check your talk page to see if Godsy had notified you too. Darkfrog24 (talk) 16:12, 17 August 2015 (UTC)

The only propriety question here is that of launching a new RfC immediately after one already concluded with the sole purpose of trying to reverse the first one because you missed it. It has nothing to do even with the motivation for doing so; it's procedurally disruptive, even with the best intentions. (And everyone here already understands that, I'm pretty certain.) If you don't believe this is true, see what happens if you go launch new RMs about the same pages immediately after earlier ones close, or what happens if you try to start a new ANI thread to overturn one at AN that didn't go your way.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  18:01, 17 August 2015 (UTC)

If there were either something clearly wrong with the previous discussion (not the case here) or the new one were a clear improvement upon it (arguably the case here), I wouldn't have a problem with that, no. We often start a new RfC right after an old one if that RfC was incomplete in some way.

EDIT: But technically no, it's not the only propriety question. You also brought up "targeted canvassing," which is why my answer addressed that point. Darkfrog24 (talk) 21:22, 17 August 2015 (UTC)

• Given the wide use of these templates, the very limited participation in the previous discussion, and the careful way in which this has been publicized (but not canvassed), and of course WP:CCC I don't see any impropriety in this RFC. And although i am a strong supporter of WP:Process is Important I don't see a need to support deprecation on process grounds. I would hope that discussion here could largely stick to the merits of the issues. DES ^(talk) 16:04, 19 August 2015 (UTC)
  • That's what TfD is for. This is canvassed WP:PARENT-shopping, period. The fact that virtually no one has commented but the directly canvassed parties is a pretty clear indication how bogus this.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  01:03, 21 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.

Template date

Perhaps the template {{date}} could be extended to output the day of the week too.SoSivr (talk) 09:59, 20 August 2015 (UTC)

It would need to be computed. Praemonitus (talk) 19:40, 20 August 2015 (UTC)

It wouldn't (on our side at least). Template:Date uses the {{#time}} parser function, which has the l option for the day of the week: {{#time:l|now}} → Wednesday. Additional formatting styles including it could therefore be easily added. SiBr₄ (talk) 19:56, 20 August 2015 (UTC)

I personally do not have access to {{date}}, therefore I could not have done more on my own. Someone who has access to the template may find time to add a relevant option and include it in the documentation. But this info was quite useful, so thanks.SoSivr (talk) 14:12, 21 August 2015 (UTC)

The recommended course of action would be to start a discussion at Template talk:Date to determine what exact formats could/should be added, and to implement them in the template's sandbox. You can then request a change to the actual template at the same talk page using {{editprotected}}. SiBr₄ (talk) 20:27, 21 August 2015 (UTC)

Move own pages without a redirect

Hello, this topic was discussed here, about one year ago. At the moment "suppressredirect" is not avaible for users at their userspace. I want to ask you, I you would support me, my bot can move pages per request, the programm for that runs at the german wikipedia at the moment, and if you as community support me, I can also enable this at this wiki after a requests for approval for that script, but first I want to ask you here. Here are the details: The bot manages a queue, where users can make a request, the following data is needed: The old titel of the page, the new titel and a reason for the requested move. The bot would move with the following reason: Bot: moving page per request of (Username), reason: (Reason). (Username) is the username of the requestor, automatically filled in, and (Reason) the given reason by the user. To prevent abuse:

• The bot moves only pages from your own userspace
• The bot will not move your main userpage, or a single talkpage

The bot will make the move 10-20 seconds after your request, he will move the page leave you a message, if the page move was successful. If not, he gives you a error message with more details. If you don't want these messages: There is on blacklist to quiet all messages, and a blacklist to quiet only the "move was succesful" messages, so he sends you a message, if the move was not succesful. So please give me your sight on that function, if you support this, I will make a request for aproval. Greetings, Luke081515 21:30, 12 August 2015 (UTC)

• While I have no problem with the idea (it seems a good one, in fact), wouldn't the bot need to have the admin flag to suppress redirects? You don't seem to be an admin on this project and, last I checked, BAG will only let admins run bots with an admin flag. Jenks24 (talk) 21:36, 12 August 2015 (UTC)

@Jenks24: Bots have also the rights suppressredirect, see here. (My bot has already a botflag here). Greetings, Luke081515 11:36, 13 August 2015 (UTC)

Interesting, didn't know that. Well that's my only concern resolved, happy to support. Jenks24 (talk) 12:23, 13 August 2015 (UTC)

• Strong support: This should definitely be implemented. Anyone should be able to move his/her sandboxes to articles without asking admins to remove the redirects left behind, or rename his/her sandboxes at will with no redirects. Here is a good reason why to enable this, the template user sandbox would be perfected by this touch. Even if redirects left behind are hidden in user sandboxes list, it would be much better if they were not created at all.·· ManosHacker 21:52, 12 August 2015 (UTC)

• While this isn't a big problem, I can't see any reason not to support this, provided it would not move either the main user page or the main user talk page, not sure if that's what's intended or not. If it needs an admin to "own" it, I'm sure we can find a volunteer. Beeblebrox (talk) 23:21, 12 August 2015 (UTC)

• Support This would make life easier for admins and users alike. ~ ONUnicorn^{(Talk|Contribs)}problem solving 00:34, 13 August 2015 (UTC)

• Support - generally there is no need or want for a redirect to exist in the cases this bot would handle.—Godsy^(TALK_CONT) 07:20, 13 August 2015 (UTC)

The request to free user pages from redirects has been put to discuss since April 2015 in MediaWiki. The addition in Luke's request, as I understand it, is that anyone should be able to move user subpages (not only his/her own) without leaving redirects. An addition is needed for this, as any user could do such a move: the user affected should receive a notification, more than a message from the bot.·· ManosHacker 08:12, 13 August 2015 (UTC)

If you want to inform the users about this possiblity, maybe a sysop can edit the mediawiki message for page move, so all user which can move can see this possibility. The message from the bot is only sended when the bot try to complete a request. Greetings, Luke081515 11:41, 13 August 2015 (UTC)

Ok, sorry, than I understand your comment the wrong way. I think at first, moving of own subpages is better, so that is form my view not a problem. Moving of other user subpages got the risk of vandalism. The page for bot requests should be semi-proteced in my opinion, so users can't move per bot, when they can't move yet. Greetings, Luke081515 13:27, 13 August 2015 (UTC)

---

The discussion is now here, (but nobody except me edited this site yet since 7 days, so please say something . Greetings, Luke081515 20:35, 21 August 2015 (UTC)

RfC: "demonym American(s)"

In regards to article titles, shall we pluralize "demonym Americans" (exempli gratia Korean Americans and Chinese Americans) or singularize ""demonym American" (exempli gratia African American)? Or shall we do each case-by-case? --George Ho (talk) 20:20, 21 August 2015 (UTC)

So far it looks like context should determine the matter. "Korean Americans" is a plural noun, but "African American" can be an adjective. See what I mean?

What specific problem is this meant to solve? Has there been an edit war about this? Darkfrog24 (talk) 18:12, 22 August 2015 (UTC)

I think the (somewhat hidden) clue is in the OP's linking to article talk pages, implying that they are talking about article titles only. Note the inconsistency between African American and Korean Americans. ―Mandruss ☎ 18:29, 22 August 2015 (UTC)

Altered the OP for clarity. --George Ho (talk) 12:43, 23 August 2015 (UTC)

• Pluralise article titles per WP:PLURAL and for WP:CONSISTENCY with non-American related ethnic groups – American groups like this are the outlier, and should be standardised per WP:PLURAL. The topics of these articles are the groups of people, not the word itself. The singular gives a false impression of what the article is about. RGloucester — ☎ 19:10, 22 August 2015 (UTC)
• Pluralize as per WP:PLURAL.--Eat me, I'm a red bean _(discuss)^(contribs) 12:49, 23 August 2015 (UTC)
• Comment - The closer of this RM referred to conflicting guidelines, and the closer of this RM alluded to the same conflict. I haven't looked into it, but I'll take their word for it. I'd submit that a better approach would be to identify the specific conflict and try to resolve it directly. This is not being done in this RfC, which does not even acknowledge the conflict. ―Mandruss ☎ 19:18, 23 August 2015 (UTC)
• Comment – ... but "African American" can be an adjective. In that case, wouldn't it be "African-American"? nyuszika7h (talk) 22:41, 23 August 2015 (UTC)

Yes. As an adjective, it is "African-American", but as a noun it is "African American". See MOS:HYPHEN. RGloucester — ☎ 22:01, 24 August 2015 (UTC)

FA/GA nomination

There is an unwritten rule here: that, the editor who make maximum edit to improve an article, has the right to nominate that article for GA/FA. If he finds another editor with no edits nominate that article, he gets angry. I saw in a featured article contributor's talk page, he was sad that he worked hard to improve the article from GA and wanted to take it for FA nomination, but when the article was ready a third user with few edits nominated the article for featured article. I can understand his feelings. We edit article which interests us. We don't edit those articles which is not about our personal interest. Few weeks ago as a new user i saw an article, which looked good. I nominated it for GA and another user who edited the article, started threatening me, "You made no edits, and you nominated it for GA". He was right, i made no edits. By nominating the article, i was trying to appreciate the editors who developed the article. In every good article, featured article's talk page, the name of the nominator is mentioned. For that reason , the editors who develop the article wants to nominate it.

So, i suggest that in a featured article and good articles talk page, instead of the nominator, the article developer's name should be mentioned. That will stop all this argument: "I developed the article, I worked hard, i spent my valuable time to fix errors, finding sources, I copy edited, then how can you nominate it for GA/FA?" — Preceding unsigned comment added by 112.79.38.40 (talk) 06:19, 23 August 2015‎ (UTC)

WP:FAC says: Nominators who are not significant contributors to the article should consult regular editors of the article prior to a nomination. FAC allows for multiple nominees for an article, but there is a restriction of two co-nominated articles at a time, so sometimes the major contributor gets left out. In the case of WP:GAN, Articles can be nominated by anyone, though it is highly preferable that they have contributed significantly and are familiar with the subject, so they are fair game. The main reason I have nominated articles I have not worked on for GA is because I am constructing a good topic. Hawkeye7 (talk) 22:42, 24 August 2015 (UTC)

Reading your comment means, i didn't deserve the abuse from the editor, when i nominated the article for GA without any contribution.112.79.39.22 (talk) 04:50, 25 August 2015 (UTC)

Suggestions for removing clutter on RFA

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. §FreeRangeFrog^croak 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)

Simplification of templates (and minimal ambiguity)

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. Gamingforfun³⁶⁵ (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. Gamingforfun³⁶⁵ (talk) 00:51, 28 August 2015 (UTC)

Make it easier to regain control of a compromised account

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.—^cyberpower_{Chat:Limited Access} 16:24, 24 August 2015 (UTC)

Support

Support A

Support B

Support C

Support D

Oppose

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. --slakr^\ talk / 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

• Account lockout on incorrect hash entry seems like an invitation for mischief. –xeno^talk 16:28, 24 August 2015 (UTC)

  Good point. I hadn't considered that. Give me a sec...—^cyberpower_{Chat:Limited Access} 16:31, 24 August 2015 (UTC)

  I made a change. How's that?—^cyberpower_{Chat: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.—^cyberpower_Chat: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.—^cyberpower_Chat: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 is}not^dave (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)

A Proposition

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)

Template Inappropriate title-soft

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:

{{Disputed title}}

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:

{{Inappropriate title-soft}}

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)

• Question - why not just use {{cleanup-articletitle}}? Ivanvector 🍁 (talk) 05:44, 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)

Regulation Committee and alternatives to consensus

Bumping thread for 30 days. ceradon (talk • edits) 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 (talk • edits) 04:20, 2 August 2015 (UTC)

I would like to put a timeline on a wikipedia page

Tracked in Phabricator
Task T110557

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

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

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)

Editor pages and editor designated hyperlinks for editors

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)

Bot to help cleanup MDY and DMY dates

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 (contribs • talk) 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)

Self-removed vandalism

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)/Archive 139#Question about IP talk pages. SiBr₄ (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. –xeno^talk 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)

Linking

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

Forced rename

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). –xeno^talk 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)

Allow users to delete pages within their own userspace

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

See also WP:PEREN#Grant non-admins admin functions within their user space. SiBr₄ (talk) 11:35, 3 September 2015 (UTC)

I agree with PrimeHunter. U1 and G7 are not a significant part of the speedy-deletion workload. JohnCD (talk) 11:39, 3 September 2015 (UTC)

The problem could be solved by applying the requested moves process, as mentioned earlier. Eat me, I'm a red bean (talk | contribs) 11:43, 3 September 2015 (UTC)

It would appear the two admins I can see that have replied think this isn't needed. As a user who has used CSD on my user pages several times, it is usually done in minutes. I don't think there is a need for this. Jerod Lycett (talk) 19:04, 3 September 2015 (UTC)

Is this the proper place to request WP articles?

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)

To answer the original question, no, you're looking for Wikipedia:Articles for creation. Jerod Lycett (talk) 19:05, 3 September 2015 (UTC)

Moving deleted revisions

Administrators should be able to move deleted revisions along with non-deleted ones when they move pages. GeoffreyT2000 (talk) 01:56, 4 September 2015 (UTC)

Should Wikipedia display a special thematic logo to celebrate the creation of the 5 millionth article?

See Wikipedia:Village_pump_(miscellaneous)#Logo_question for discussion. --Jakob (talk) aka Jakec 00:31, 5 September 2015 (UTC)

Wikipedia:Criteria for Acceptance

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 guideline(s) established here shall regulate the specific course of acceptance for different articles, and the means to obtain such, and the curation of such acceptance, to ensure that all articles are up-to-date with the most recent guidelines and virtues of consensus.

Method to obtain acceptance

An article obtains acceptance, which is a means to properly protect such content from unnecessary revision, or reversion, when it receives consensus from the Wikipedia community. When an article receives consensus, and is accepted, it receives additional protections, which are not applicable to typical articles. These protections include, but are not limited to,

• Protection from unnecessary revisions (all revisions must be proposed and achieve consensus). • Protection from unilateral deletion markings (the only form of deletion that shall be permitted, shall be Articles for Deletion [AfD]).

If a confirmed user deems it necessary, they may add in important information at any time, regardless of acceptance

These protections are not just handed out, but must be obtained by a specific process. This process involves submitting an article to the community, under a section “Articles for Acceptance”. Once consensus has been achieved for the article to be accepted, it must receive authorization from either a sysop or a sysadmin. Acceptance may be revoked by the community by achieving “dissenting consensus”.

General pillars for acceptance

Articles shall only be proposed for acceptance should they be found to be pursuant to a specific pillar of acceptance. Such pillars may only be established within this policy.

§1 - Likely not to require changes, or amendment. §2 - The article reflects fact, and is in no form opinionated information. §3 - The information presented within the article is, in some way, important, by community standards.

Accepted articles patrol

All changes made to accepted articles shall appear in an AcceptedArticlesFeed, and shall be closely supervised by an Accepted Articles Patrol (AAP), which shall be a voluntary service. All members of the AAP shall be granted permissions to add notices to accepted articles, revert changes as necessary, etc.

Disclaimer

This policy, in no way, mandates acceptance for publication of articles. It grants additional privileges and securities to pages which are accepted; no such other action shall occur as a result. — Preceding unsigned comment added by Ex Parte (talk • contribs) 02:20, 11 September 2015 (UTC)

Can you explain what it is that you are trying to do here? GenQuest ^{"Talk to Me"} 02:37, 11 September 2015 (UTC)

• Oppose as an unholy evil, which is antithetical to all that Wikipedia holds. This proposal is exactly the opposite of so many Wikipedia policies and core values, I can't even cite them, because it is literally in opposition to like all of them. --Jayron32 03:00, 11 September 2015 (UTC)

I disagree with Jayron; at worst this is just regular, every-day evil. @Ex Parte: can you explain: 1. What problem you are trying to solve, and 2. How does this proposal align with the third pillar? Thanks! VQuakr (talk) 03:16, 11 September 2015 (UTC)

• Oppose, because no rationale whatsoever has been offered for making a fundamental revision to Wikipedia process. I suggest that the proposer (who I note appears to only have been editing Wikipedia for three days [7]) might do well to find out how Wikipedia actually works first, rather than making proposals which have zero chance of becoming policy. AndyTheGrump (talk) 03:29, 11 September 2015 (UTC)

• Oppose Come on, this is just a goofy suggestion. Townlake (talk) 03:41, 11 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.

Change the default AfD template to include wording that it's a discussion

{{Afd2}} is currently the template we use on new AfD by default. I'm proposing that we include wording such as is found on {{Not a ballot}} by default, rather than waiting. While the wording may need tweaked slightly for this purpose I think the relevant section that should be included is:

please note that this is not a majority vote, but instead a discussion among Wikipedia contributors. Wikipedia has policies and guidelines regarding the encyclopedia's content, and consensus (agreement) is gauged based on the merits of the arguments, not by counting votes.

I would hope that this would preclude needing to use {{not a ballot}} as often. Jerod Lycett (talk) 02:32, 5 September 2015 (UTC)

Log of articles proposed for deletion

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)

• Support – I believe there's already a category of PRODed articles. It seems like it should shouldn't be too tough to create a 'By day' list of PROD articles at WP:Proposed deletion, like the ones at WP:RM or WP:TfD, etc. --IJBall (contribs • talk) 15:38, 30 August 2015 (UTC)
  • @IJBall: I think you meant "it shouldn't be too tough". nyuszika7h (talk) 11:54, 31 August 2015 (UTC)
    • Yes - fixed! --IJBall (contribs • talk) 13:12, 31 August 2015 (UTC)
• Here is a list of all the Prods in chronological order, User:DumbBOT/ProdSummary. Does that work for what you want? -- GB fan 12:05, 31 August 2015 (UTC)
• Support as long as someone's willing to operate the bot that you suggest. I've never prodded a page except by manually adding the prod template, and I doubt that I'd remember to log it manually, so my prodding would never get logged except with bot assistance. Nyttend (talk) 00:04, 6 September 2015 (UTC)

Efficient search for policies and guidelines

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. Cullen³²⁸ 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. Cullen³²⁸ 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. SiBr₄ (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)

This is not possible right now, without changes to Extension:Inputbox. I was hoping that abusing it's prefix param would work, but it seems prefix search is in a category of it's own and doesn't mix well with other search options. There are multiple ways that the search itself can support this usecase though Higher prio for pages containing the relevant header templates or search in pages that link to Wikipedia:Policies and guidelines. Neither is perfect of course, but it sort of works. To make it as accurate as possible, we could let the header templates add a hidden category, so that we could use the "incategory:" modifier (modifiers only really work as ANDs, not as ORs). But first, you'd have to adapt the extension I fear. —TheDJ (talk • contribs) 16:05, 3 September 2015 (UTC)

So if I understand, our best options are either we add all P&G pages to the same category, or we add a prefix (à la “Manual of Style/…”) to their titles. Is this right? And would we be able to include essays and supplementary pages like WP:BRD in whatever we might end up doing? —67.14.236.50 (talk) 22:35, 3 September 2015 (UTC)

Does anyone have any opinions on moving all policies and (non-style) guidelines to share a common prefix, like the MOS pages do? —67.14.236.50 (talk) 21:43, 6 September 2015 (UTC)

Please Contribute!!!

It has come to my attention that some users experience a serious glitch on the community portal that puts half of the content off of the page (I have a photo listed at the discussion I am about to refer to.). Also the community portal seems a bit outdated. So I created a new portal here and began discussion for consensus to implement the newly designed page. (I have not implemented a color scheme yet other than greys so that would be to be decided on if implemented.) Only one user contributed and I fine tuned the new page to resolve all of their concerns but I would appreciate more users to give their opinion (as only one has contributed in over a week) and hopefully come to consensus on this matter. The discussion is going on under the "A Proposal" section here. Thanks and please do not comment under this post!Tortle (talk) 01:41, 7 September 2015 (UTC)

New user right: Gadget editor

A new user right called "Gadget editor" should be created. Gadget editors are allowed to create, edit, and move pages in the "Gadget" and "Gadget definition" namespaces. Also, administrators should be given the Gadget editor right and in addition, they should be allowed to delete pages in the aforementioned namespaces. GeoffreyT2000 (talk) 00:12, 7 September 2015 (UTC)

• An observation: no "Gadget" or "Gadget definition" namespaces exist, these pages are in mediawiki namespace. What you suggest would require modifying the gadgets extension. Cenarium (talk) 00:54, 7 September 2015 (UTC)

  Check your recent changes filter dropdown. The namespaces exist now, but are unused. --Izno (talk) 02:19, 7 September 2015 (UTC)

  Indeed, I hadn't noticed them, they were recently added by phab:T106177. Even sysops can't edit them at the moment. A gadget editor usergroup seems like a good idea. Cenarium (talk) 13:11, 7 September 2015 (UTC)

• Who should hold that user right? The amount of trust necessary is so high that I can't imagine giving it to anyone but admins. —Kusma (t·c) 14:32, 7 September 2015 (UTC)
  • Seriously: The amount of damage that can be done with Javascript is so high, that maybe we ought to have a "two-key" system and use proper code review techniques. That way, if the first admin (or person who is an admin and a technically competent dev) happens to overlook a typo, then there's a chance that a second admin would notice before it breaks the wiki. WhatamIdoing (talk) 16:13, 7 September 2015 (UTC)

one article for all the languages (translated to all the languages)

Hello.

I use all the time en.wikipedia (english) and es.wikipedia (spanish).

I think the best it would be to have only ONE WIKIPEDIA translated to all the languages. Only one article translated to all the languages. This would be a lot better for everyone, for many obvious reasons. This would reduce the number of writers to only the experts.

I think also it would be better to ease the process of sending and publishing comments. I've found errors in articles and I don't know how to publish my corrections. By looking how to send this suggestion I think I found how but it would be better to make it easier (like writing a comment in youtube)

Thank you for listening me and for wikipedia. What would be the world without wikipedia. Carlos Arellano — Preceding unsigned comment added by 201.161.151.249 (talk • contribs) 05:09, 8 September 2015‎

Having only 1 article translated into all languages is not feasible yet. Maybe when machine-translation gets better it will be. HOWEVER, in the English Wikipedia at least you can enable the en:User:Equazcion/SidebarTranslate "gadget", which lets you see a rough machine-translation of the articles in the other-language Wikipedias.

On your other question: A good place to get help editing Wikipedia articles is WP:HELP. davidwr/(talk)/(contribs) 06:05, 8 September 2015 (UTC)

There is also the Content Translation tool available (when logged in) in Beta features. Keegan (WMF) (talk) 18:00, 8 September 2015 (UTC)

Userpage drafts shown in search engines

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.

While not necessary to mention because of the WP:SNOW outcome, there is consensus to add NOINDEX. Closing this to box it up. AlbinoFerret 14:54, 9 September 2015 (UTC)

---

Tracked in Phabricator
Task T104797

Hello,

I recently realised that if you try to Google for any topic, you also get userpage drafts in the search results. For example, see this wikipedia entry and the corresponding search query. In most userspace drafts, it is not obvious that the article is a draft under progress, causing readers to possibly get confused.

To deal with it, I can possibly see two ways out -

1. All userspace draftspages have NOINDEX added to them. If I remember correctly, all drafts currently in the Draftspace use something similar and this should solve the issue for us. If there is no such easy option to locate drafts in the Userspace, we could consider if putting NOINDEX on the entire userspace itself is feasible
2. Consider having a policy to move Userspace drafts, atleast for retired users to Drafts namespace.

What do others think?

Soni (talk) 09:36, 1 July 2015 (UTC)

• The whole of userspace desperately needs to be NOINDEXed because it is very lightly patrolled. There's too much spam and other self-promotional crap around and not enough people deleting it -- not to mention copyright problems, attack, BLP and child protection issues. MER-C 13:01, 1 July 2015 (UTC)

• I'd support a NOINDEX of the userspace. But perhaps there's a way to make them default to NOINDEX and allow that state to be overridden on individual pages? Praemonitus (talk) 21:24, 1 July 2015 (UTC)

• I'd support a blanket NOINDEX of the userspace as well. I can't think of a good reason not to. --Ahecht (TALK
  PAGE) 23:11, 1 July 2015 (UTC)

• NOINDEX all of userspace. I already do that with all of my own for quasi-privacy reasons, anyway. (BTW you can NOINDEX JavaScript with // __NOINDEX__ and both JS and CSS with /* __NOINDEX__ */) --Unready (talk) 00:06, 2 July 2015 (UTC)

• Support NOINDEX also. These pages are not really of interest to the average internet user and might confuse them. Happy Squirrel (talk) 01:37, 2 July 2015 (UTC)

• Support a blanket NOINDEX of all userspace. Geogene (talk) 18:24, 2 July 2015 (UTC)
• Yes, I agree. I have long NOINDEXed my user page and sandbox. We tell people WP is not a web host and then provide a web host. Thincat (talk) 18:35, 2 July 2015 (UTC)

• Support. I can think of no legitimate reason why userspace content needs to show up on search engines - and many good reasons why it shouldn't. AndyTheGrump (talk) 18:49, 2 July 2015 (UTC)

• Hrrm, I'm going to noindex my page right now! Very good idea. Eman235/talk 19:38, 2 July 2015 (UTC)
• Support, makes sense to me. Surprising this hasn't been done already actually. Andrew Lenahan - Starblind 18:22, 3 July 2015 (UTC)
• Strong Support of setting all userspace as noindex, I do not see nay reason that it is not already. All pages are still locatable through the internal search engine.- McMatter ^(talk)/_(contrib) 18:27, 3 July 2015 (UTC)
• I think I always assumed it was, though I know I've seen userspace pages in searches. I can't think of any good reason not to NOINDEX. Sam Walton (talk) 19:37, 3 July 2015 (UTC)
• See Wikipedia:Requests for comment/User page indexing for a prior RFC on this subject. Cenarium (talk) 22:11, 3 July 2015 (UTC)

• I agree, all drafts and user subpages should be NOINDEXed. FWIW, I've put User:Nobleeagle/India as an emerging superpower up for deletion as a G13. Joseph2302 (talk) 23:14, 3 July 2015 (UTC)

• Comment: {{Userspace draft}}, marks all such pages as noindex'ed. —TheDJ (talk • contribs) 23:25, 5 July 2015 (UTC)
• In my opinion this is unnecessarily breaking search engines, mostly because according to the comments above, 1 we don't check userspace much, 2 we allow people to do everything they want with it. Seems to me like we have our problems mixed up... —TheDJ (talk • contribs) 23:25, 5 July 2015 (UTC)
• Oppose I agree with TheDJ. I find external search better for most purposes. There is not a big enough problem here to break functionality over. --99of9 (talk) 04:26, 9 July 2015 (UTC)

• Given how many editors seem to agree on having NOINDEX enabled by default on Userspace, I would be initiating an RFC on the same to discuss and reach a clear consensus to act. For the moment, I will be writing the RFC at User:Soni/sandbox5 but if anyone is ready to assist with writing down all the reasons for why we should/shouldnt NOINDEX the entire userspace, please ping me on my talk page.

Soni (talk) 06:42, 9 July 2015 (UTC)

• I always though user pages were already No INDEX. Silly me. Let's get it done. Kudpung กุดผึ้ง (talk) 11:24, 15 July 2015 (UTC)

I've tracked this in phab already, however the foundation is looking into this. Mdann52 (talk) 16:27, 17 July 2015 (UTC)

• Support enabling NOINDEX by default for all userspace pages. I just went through and slapped {{NOINDEX}} throughout my userspace as a temporary remedy. –Prototime (talk · contribs) 19:35, 17 July 2015 (UTC)
• Support Marking content that isn't supposed to be searched to actually prevent it from being searched is not "breaking" search engines. --NeilN ^{talk to me} 06:52, 19 July 2015 (UTC)

• Supoort NOINDEXing all of userspace, except main user page. Libelous drafts, copyvios, and other such stuff are too much of a risk. WP's own search crappiness is a matter for the devs to fix. I sympathize with the external search preferences, but legal matters trump convenience workarounds.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  16:38, 22 July 2015 (UTC)

• Support The very strong consensus here should be sufficient to get it implemented. I'm not sure if it's feasible to exempt the main user page and noindex the subpages. If so, It would be better to even noindex the main user page than let the subpages be indexed. DGG ( talk ) 21:11, 23 July 2015 (UTC)
• Support blanket NOINDEX of User: space, and all spaces which are not article space. I really thought this was already the case. We shouldn't have material that is not published to main space showing up in searches and attributed to Wikipedia. Ivanvector 🍁 (talk) 21:14, 23 July 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.

Proposal: SPA template should not be used for dynamic IPs

When an unregistered user's IP address is dynamic, each IP they edit from is used only for a few hours, so the list of contributions from any one of their IPs generally is confined to whatever article they were editing at the time. On that basis, one user has tagged each IP I've used in this discussion with the "single purpose account" template. (See also the discussion here.) The SPA tag is intended to indicate something about the nature of the user whose posts are being tagged, but the way it's used in this case it only indicates something about the user's internet connection. This use seems contrary to the tag's purpose, but according to the one admin I've discussed it with (user:Nyttend), using it this way technically is allowed. Would it be possible to change the instructions for this tag so that it only can be used for either registered editors, or unregistered editors whose IP address stays the same over a long period? 43.228.158.49 (talk) 15:45, 9 September 2015 (UTC)

max-width

My desktop machine has quite a large screen - 1920×1080px but I normally view Wikipedia in a window 960px wide. When I maximise the window the page expands to use the full width which gives text lines impossibly long to read comfortably. There are so many user preferences already, it would not hurt much to allow the user to request the clause max-width: …px; to be sent in the CSS for every page.

Even as I was drafting the above, I remembered that I can set this myself using my custom CSS file. But I leave it as a suggestion of benefit to people who don't speak CSS. — RHaworth (talk · contribs) 15:56, 10 September 2015 (UTC)

Perhaps this would be a worthwhile gadget? {{Nihiltres |talk |edits}} 17:20, 10 September 2015 (UTC)

This would be a worthwhile fix in core MediaWiki. Alakzi (talk) 17:24, 10 September 2015 (UTC)

Change default behaviour of refs on pages without a reflist

When a <ref> tag is placed on a page, the software puts the text inside the ref in a {{reflist}} section, or if there isn't one, it puts the text at the very bottom of the page. At least, this seems to be the behaviour. A problem I've often come across with this is that when refs are placed on non-article pages (mostly talk pages, but I've also seen it at Arbcom and ANI for example) they get detached from the discussion which they're relevant to, and end up stuck awkwardly in whichever discussion is at the bottom of the page. For an example see this revision of WP:RSN, where the two refs at the bottom of the page have nothing to do with the "gun show loophole" thread. It's especially awkward for responding to edit requests, since references are generally a requirement for [semi]protected edits yet few non-confirmed editors know about {{reflist-talk}}, so on long-protected pages there can often be a long list of irrelevant refs inserted below the newest request.

I wonder if it would be possible to change the default behaviour, so that if a page doesn't have a {{reflist}}, the refs float to the bottom of the section they're placed in (above the next lv2 header, for example) rather than floating to the bottom of the page. Thoughts? Ivanvector 🍁 (talk) 19:40, 10 September 2015 (UTC)

T70324 is open for anyone wanting to work on it (or to read the repeated requests for it in various WP discussion areas). DMacks (talk) 21:19, 10 September 2015 (UTC)

entity vs template

Minor point for anyone who is interested: The software puts the contents of the ref tags in a <references /> block, rather than in a template. {{reflist}}, with no parameters, does nothing more than display the simple <references /> block, with the additional computing expense of going to look up the template first. Unlike the case in, say, 2008, there are no longer any differences between what <references /> and what {{reflist}} shows on a page, except that the latter is a slower and more expensive method of getting the first to display. WhatamIdoing (talk) 20:46, 10 September 2015 (UTC)

@WhatamIdoing: then why are {{Reflist}} and <references /> both options on the insert tool below the edit box and above the edit summary window? If {{Reflist}} does nothing different than <references /> yet is more expensive in terms of server power, shouldn't its use be depreciated and it be removed from the tool? ~ ONUnicorn^{(Talk|Contribs)}problem solving 21:11, 10 September 2015 (UTC)

{{reflist}} has lots of other formatting features if various parameters are used. It's just if used literally as "{{reflist}}" does it give simply result in "<references />". See the template docs for the optional other tricks. DMacks (talk) 21:17, 10 September 2015 (UTC)

ONUnicorn, I think that part of the reason is that we still have a few old hands who believe that there is still a font-size difference. I believe we have an editor or two who has been systematically substituting the template (via AWB) on all articles, and that adds up over time. I just did a brief review (n=10): one unreferenced; one WP:General reference; two using the templates' features (columns); and six that use the template needlessly.

The (IMO) rational argument in favor of using it universally is that if it's used everywhere, then the fact that the template has other features might be more discoverable for some users. This is probably a minor advantage, because presumably if you wanted to use the advanced features, then you would just find a page that had exactly what you wanted and copy from there. The arguments against are that it's specific to en.wp, so you can't use that knowledge anywhere else (e.g., about 100 Wikipedias, but also in private wikis at work or on other sites), that it's slower/more expensive. I suspect that any given editor would say that both of these are also relatively minor issues. WhatamIdoing (talk) 21:35, 10 September 2015 (UTC)

The reason I use the template is because it's easier to change later. When you only have a handful of references it's fine to have a single column, as it grows though you'll want to add more to split it up. It's pure laziness, but it's easier to add |2 than it is to change the whole tag. Jerod Lycett (talk) 22:51, 10 September 2015 (UTC)

column-count is deprecated. Use {{Reflist|colwidth=30em}} instead. Alakzi (talk) 22:55, 10 September 2015 (UTC)

Enable VisualEditor for Modern and Cologne Blue

VisualEditor should be enabled for Modern and Cologne Blue. Then, Supports only Vector and Monobook skins – of the four skins available in user preferences, VisualEditor works only with the two newest, and most popular. can be removed from Wikipedia:VisualEditor#Limitations. GeoffreyT2000 (talk) 23:15, 11 September 2015 (UTC)

@GeoffreyT2000: Have you tested these skins and ensured that they work with VisualEditor? Are you committing to keep them fixed promptly and consistently? The reason they aren't enabled for use with VisualEditor is because they're not supported except by the occasional volunteer, but instead of removing them from the cluster they for now still available on the basis that they will be fixed by them. Adding more burdens to volunteers just to make VisualEditor look good seems uncool. :-( Jdforrester (WMF) (talk) 23:19, 11 September 2015 (UTC)

Propose that the, top of window, [icon #] [icon #] links follow the text based links to which they relate

Currently we present:

♣ Name  [icon #] [icon #]  Talk  Sandbox  Preferences  Beta  Watchlist  Contributions  Log out

Basic proposal

The [bell #] symbol relates to a user's an editor's login so as to mainly present alerts on locations that the editor has been mentioned in (simultaneously signed) pings. To state the obvious, thanks given for on referenced edits (at points where the User name is also displayed) are also listed amongst alert notifications.

The [speech bubble #] access to "Your messages" notifications relates to contributions to the "User talk:" page of the editor.

The proposed sequence of links would present:

♣ Name  [icon #]  Talk  [icon #]  Sandbox  Preferences  Beta  Watchlist  Contributions  Log out

Proposal with spacing adjustment

At present the two [icon #] [icon #] are presented close together and the initial head and shoulders icon also appears to me to be presented relatively close to the user name text with greater spacing is provided between the other links. I would suggest that each [icon #] link could be presented with similarly close proximity to the related and preceding link. This would present:

♣ Name [icon #]  Talk [icon #]  Sandbox  Preferences  Beta  Watchlist  Contributions  Log out

I think that the basic change proposed will present the links in a more intuitive way.

GregKaye 08:49, 12 September 2015 (UTC)

• Support a much clearer presentation as proposed. Gmcbjames (talk) 18:50, 13 September 2015 (UTC)
• Comment There are many (many) proposed new types of notifications for the long-term (See mw:Echo (Notifications)#Suggested new notification types for a start, and I have more to add...). The icon split, comes with a request for feedback on how could we decide to divide the other notification types? Please suggest ways to 'bucket' the notification types, ideally over in that thread. Thanks. Quiddity (WMF) (talk) 18:38, 14 September 2015 (UTC)

Thanks both, Quiddity (WMF) Thanks for the reference following which I have copied the discussion there. GregKaye 04:45, 15 September 2015 (UTC)