Wikipedia:Village pump (all)

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search

This is the Village pump (all) page which lists all topics for easy viewing. Go to the village pump to view a list of the Village Pump divisions, or click the edit link above the section you'd like to comment in. To view a list of all recent revisions to this page, click the history link above and follow the on-screen directions.

Click here to purge the server cache of this page (to see recent changes on Village pump subpages)


Village pump sections

Edit-find-replace.svg
Policy
watch
To discuss existing and proposed policies

Preferences-system.svg
Technical
watch
To discuss technical issues. For wiki software bug reports, use Phabricator

Dialog-information on.svg
Proposals
watch
To discuss new proposals that are not policy-related. See also: perennial proposals.

Tools-hammer.svg
Idea lab
watch
To discuss ideas before proposing them to the community and attempt to find solutions to issues

Help-browser.svg
Miscellaneous
watch
To post messages that do not fit into any other category

View all village pump sections at once

Hyperlink-internet-search.svg
Other help and discussion locations
I want... Where to go
...help using or editing Wikipedia Help desk
...to find my way around Wikipedia Department directory
...specific facts (e.g. Who was the first pope?) Reference desk
...constructive criticism from others for a specific article Peer review
...help resolving a specific article edit dispute Requests for comment
...to comment on a specific article Article's talk page
...to view other Wikimedia projects Wikimedia Meta-Wiki
...to learn about citing Wikipedia in a bibliography Citing Wikipedia
...to report sites that copy Wikipedia content Mirrors and forks
...to ask questions or make comments Questions


Contents

Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).

Policy

Should WP:TWL be allowed to acknowledge the services they have partnership with in our articles?

Consensus to allow, when it adds something. Supporters and opponents were close to agreement that links should be allowed when where they benefit the reader, from WhatamIdoing's "warning notice", to Das Wolf's previews, to Daask's list. Several voices opposed paywalled links on principle, but others mentioned we have a long tradition of allowing such, again, when they add something. --GRuban (talk) 20:18, 17 September 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

This is a follow up to User_talk:CitationCleanerBot#Via. According to Nikkimaria (talk · contribs) and Vanamonde93 (talk · contribs), they put citations like

  • Esmonde, Margaret P. (1981). "The Good Witch of the West". Children's Literature. 9: 185–190. doi:10.1353/chl.0.0112 – via Project MUSE. (Subscription required (help)). 

by the reasoning "It wasn't used to advertise the service; it was used to acknowledge the access provided by Project Muse to certain Wikipedia users." This is apparently to comply with partnership requirements where they have gained personal access to pay-for-access databases (in this case Project MUSE) through The Wikipedia Library, where in return they need to mention in our articles that they had made use of Project MUSE.

Should the practice be allowed to continue? Or under which condition should |via= be used? Headbomb {t · c · p · b} 15:32, 28 June 2018 (UTC)

TWL discussion

Disallow: This is something that is a textbook WP:SPAM/WP:PROMO situation. Citations exist to verify our material, not advertise pay-for-access academic services. While we have links that often point to paywalled ressources, such as DOIs in our article, those are vendor-neutral identifiers are there to help identify the citation. WP:SAYWHERE is clear about this:

The advice to "say where you read it" does not mean that you have to give credit to any search engines, websites, libraries, library catalogs, archives, subscription services, bibliographies, or other sources that led you to Smith's book. If you have read a book or article yourself, that's all you have to cite. You do not have to specify how you obtained and read it. [emphasis mine]

The following

  • Esmonde, Margaret P. (1981). "The Good Witch of the West". Children's Literature. 9 (1): 185–190. doi:10.1353/chl.0.0112. 

fully complies with WP:SAYWHERE, and links to Project MUSE resources in a way that does not unduly promote a commercial service. Further, using the URL to further link to the paywalled Project MUSE is fully redundant with the DOI, and discourages editors from finding non-paywalled versions of the paper.

Things like

are ridiculous.

This is a horrendous practice, and one that needs to end now. If Project MUSE wants attribution in some way, that can be done in edit summaries, or via the talk page. Not in the main bodies of our articles. Headbomb {t · c · p · b} 15:32, 28 June 2018 (UTC)

  • Comment to be clear, I have been formatting citations in that manner because I understand that that is what TWL requires. I see the concern about being promotional, but as we routinely link to sites that are inherently promotional (official websites, twitter accounts, paywall protected newspapers, newspapers that don't have paywalls because the use ad revenue which eventually comes from consumers, etc) I'm not overly worked up about this. All I would like is to continue to be able to use these resources to provide more reliable and detailed information, which is what this should be about. If the community compels TWL to remove this requirement, I'm not remotely bothered. Vanamonde (talk) 15:45, 28 June 2018 (UTC)
  • TWL Comment Just to clarify, using the |via= parameter is not a requirement of citing resources obtained through The Wikipedia Library, and the citations found on the old signup pages (e.g. Wikipedia:Project MUSE) are only a suggestion for a fully formatted citation. I can absolutely see how the text there makes it seem like more of a requirement, however, and I’ll rewrite that section to make it clearer, in addition to the note that is already present.
As far as I’m aware, the parameter was initially added to these citation examples simply because it was present in the citation templates and has uses in cases where the URL doesn’t point to the location the source was found. It’s also useful because it saves you mousing over or clicking a URL to know where the citation is from. Ultimately though, the discussion about whether the parameter is useful is unrelated to TWL.
We’re not concerned whether this parameter is kept in the suggested citation style or not, and are happy to change it based on the outcome of this discussion. Given that the parameter isn’t a requirement of using TWL, however, I’d suggest reframing the discussion around whether use of the ‘via’ parameter is desired in any context. Let me know if you have any questions or suggestions. Samwalton9 (WMF) (talk) 16:56, 28 June 2018 (UTC)
Well, I'm very glad to hear this is not a requirement. However, Wikipedia:The_Wikipedia_Library/Publishers specifically mentions, in the "Exposure and promotion", "Publisher credit using the |via= parameter of our citation templates". Maybe this is the source of confusion? Or possibly pages like Wikipedia:Credo/Citations and other similar pages? If this isn't a requirement, those pages should be updated to de-promotionalize those services. Nikkimaria (talk · contribs) and Vanamonde93 (talk · contribs), what led you to believe that using |via= to 'credit' Project MUSE was required/encouraged? Headbomb {t · c · p · b} 19:15, 28 June 2018 (UTC)
@Headbomb and Xover: The instructions in question are the ones found at Wikipedia:Project MUSE, which say, among other things, that editors should "provide original citation information in addition to linking to Project MUSE resources" and "Cite resources in line with the citation examples provided below or with the examples provided by Project MUSE" (the example in question uses the |via= parameter. The version of the instructions that existed when I received access was even more definitive about this. Vanamonde (talk) 03:44, 29 June 2018 (UTC)
  • Comment @Headbomb: If you're going to be opening a policy RFC, please at least try to frame it neutrally. The above is closer to a diatribe and I would really rather strongly implore you to retract it and try again once your apparent indignation has had time to recede a bit.
    Second, The TWL partnerships do not "require" much of anything. The TWL effort suggests that per WP:SAYWHEREYOUGOTIT you use |via= etc. in a specific way for sources from that particular archive or service when appropriate. So when you access a journal article through a third party service—rather than on paper in your local library or directly from the publisher—you specify that you're citing the copy provided there rather than an original. The TWL example citations have been formed based on SAYWHEREYOUGOTIT and are intended to be used in accordance with SAYWHEREYOUGOTIT, including their mostly being optional and when it is not appropriate to include such |via= parameters.
    By all means lets discuss the finer points of how we should apply SAYWHEREYOUGOTIT to the TWL resources, but please don't let your knee-jerk reaction based on limited (and obviously skewed) information turn that discussion into a pointless drama fest that will achieve nothing but tarnish the coordinators and other volunteers working very hard to improve the encyclopedia. Please. --Xover (talk) 17:01, 28 June 2018 (UTC)
The RFC is framed neutrality. My !vote expresses my opinion. Nothing wrong with that. You're welcomed to make a support case if you have one. Headbomb {t · c · p · b} 18:10, 28 June 2018 (UTC)
Yeah, see, the problem is you've set up a strawman (just about zero of the assertions and underlying assumptions in the current RFC framing are true) and now you're asking me to argue against it.
I have no objection what so ever to discussing how TWL should recommend that citations to sources that happened to be accessed through a TWL partner's donated access be done. Nor to discussing how SAYWHEREYOUGOTIT applies to cases like these (of which some, but not all, sources made available through donated partner services are examples, but in no way unique in that regard). Nor to discussing the purpose in general, or finer points of application of, the |via= parameter. I might even have some opinions on some of these issues (then again, probably not enough to argue about them). You want to do any of those things, have at it. Heck, if for some reason you need my help with any of those, I'd be happy to step up.
But we can't have any of those discussions, at least not productively, in an RFC framed in an inflamatory way (That is, "in a way that is likely to have the effect of inflaming", not "in a way intended to inflame") and based on incorrect information. So, again, please—please!—reconsider: either by reframing the current RFC, or by withdrawing and trying again when you're less outraged by what is incorrect information! --Xover (talk) 19:22, 28 June 2018 (UTC)
  • Allow when it adds something. E.g., we routinely use |via=Google Books for books that Google is providing snippet views of and other "digitally digested" content, because we are not looking at the literal book itself and cannot, e.g., be 100% that the book's original text, pagination, etc. were preserved correctly by Google's OCR and other munging. We don't need to use it for old-book scans that Google hosts, because they are exact photographic facsimilies (often including the library cards :-). It's useful to say that you got a journal article via a particular journals database, because you are not literally reading the actual journal, but a PDF prepared from submitted content not a scan, or an HTML text-and-images relayout, or something like that (sometimes it's even a pre-print copy which may be pre-peer-review, too – same goes for arXiv), not a photographic facsimile.  — SMcCandlish ¢ 😼  19:40, 28 June 2018 (UTC)
Yeah that's fine, I'm not arguing for a blanket ban on |via=. I'm only talking about cases where there's no URL given, when things are redundant with links that are already provided by identifiers, or that the reproduction hosted by Database X is a faithful reproduction. Headbomb {t · c · p · b} 19:49, 28 June 2018 (UTC)
  • Edit the template. The "via" parameter is plainly dangerous, because it advertises random third parties. I don't get the argument that it isn't as bad if you're talking about Google Books, either. But, we also have a duty to the readers to help them access the material. So we should change the template as follows:
  • All "via" links should display the same text -- "access notes". This avoids any appearance of spam, and can be a neat, regular format. The "access notes" would be a link, of course, and could be set off with a cute/recognizable box using inline CSS: access notes or some such. And the links, naturally, go to different places depending on the via=parameter.
  • All "via" links link to pages in Wikipedia space, e.g. WP:Access help/Project MUSE. The template can even be designed for reverse compatibility to process the links it receives to add the WP:Access help/ part so the existing via link texts go new places, but new links should name a WP: space page directly (and thus not be altered). The reason for this is that Wikipedia articles are "WP:NOT#HOWTO", whereas what access help should be is absolutely, completely, one hundred percent HOWTO. That's an unacceptable philosophical incompatibility. We want to tell readers any and all options to get access when via= gives a particular mechanism, but are interested there in nothing else about it.
  • Our WP pages should then each explain their particular "via" mechanisms for the readers, including whether they can become editors and apply for access, or pay for it, or try to get lucky with an inconsistent server (I'm thinking Google Books) using any legally acceptable trick like using a VPN or TOR. (Actually I don't know if this works ... obviously the composition of these pages will be the topic of some specialized expertise and debate)
Wnt (talk) 21:12, 28 June 2018 (UTC)
That forgets one thing: WP:TWL is an editor resource, not a reader resource. The way to help readers access things it to find free-to-read resources. Headbomb {t · c · p · b} 22:17, 28 June 2018 (UTC)
@Headbomb: No, I didn't forget that. If we have a Wikipedia-space page on MUSE we can tell readers they don't easily get access via this route. But we can also point out that they can ask editors about it. And of course, any Wikipedia reader can become an editor -- it's never to be ruled out -- so TWL is at least nominally an access mechanism. I am actually not sure how TWL plays with WP:WRE -- are there TWL editors listed under the latter, or can you request copies of specific resources via that means? The distinction between "interlibrary loan" and "piracy" is utterly mythical and of paramount legal importance. Wnt (talk) 23:07, 29 June 2018 (UTC)
  • TWL Followup Just a note that I've reworded the old signup page template to make it clearer that there's no required citation style or parameter usage, and also reworded or removed explicit mentions of the via parameter elsewhere. Samwalton9 (WMF) (talk) 09:44, 29 June 2018 (UTC)
  • Allow - I liken it to a CC-BY-SA 4.0 license—it serves to benefit the project. Atsme📞📧 16:29, 2 July 2018 (UTC)
  • I think that the "via" information is most useful when you consider it as a 'warning' about the URL, similar to a PDF icon after an external link. To that end, I think it would be better if the citation looked more like this: "The Good Witch of the West (via Project MUSE)" (etc.). WhatamIdoing (talk) 19:00, 6 July 2018 (UTC)
  • Ditto WhatamIdoing. It's just more context for the citation. I have a weak disinclination to support reformatting the link to say "access notes" since requiring a separate click defeats the point of having that handy context (they can just click the link itself and see where it takes them, after all). If it were a requirement that it be formatted a particular way, that would be one thing, but it sounds like it's not, so it's just using the template as it's intended. I'll add that I also don't have a problem with TWL encouraging people to use it. This seems along the lines of "remember to include the title of the publication when you cite it". If reminding people to use the procedures/templates they should/could be using anyway indirectly helps more people get access, that seems like a win. It's when it becomes mandatory that it's a little more uncomfortable. — Rhododendrites talk \\ 05:36, 15 July 2018 (UTC)
  • Disallow all paywalled links and |via= notices, except when they add something for the reader (e.g. Google Books preview) AND when that wouldn't be already linked through DOI/PMID etc. We're not an affiliate site. There's already an annoying amount of paywalled links (e.g. Highbeam) to newspaper articles that are readily available for free from the newspaper website or archive.org. BTW I was less than impressed the Project MUSE's crappy primary-sourced, unreadable Wikipedia page. What do they offer that we should bend the rules for? I'd rather do this for arXiv, the awareness of which the readers at large could actually benefit from. DaßWölf 00:35, 16 July 2018 (UTC)
  • Allow this is completely unnecessary, we shouldn't hide where a source came from, if its available freely then the ref should be altered to point to the free version, overall this is a bureaucratic instruction creep, thanks Atlantic306 (talk) 19:44, 25 July 2018 (UTC)
  • Disallow rather obviously. We wouldn't add "via=through library X in city Y", even though that may well be how the person who added the source acquired the information (never mind "through Amazon" if one bought the book there!). The article should not have information about "who" added something or "how" they acquired their copy of the information specifically. Stuff like this may at most belong on the article talk page, although even there it seems unnecessary. Fram (talk) 08:40, 31 July 2018 (UTC)
    • There's also a big problem here that if we remove attribution to the archives they will remove free archive access through the Wikipedia library that many of us use and who cannot afford the expensive subscriptions. Also if a source is available from a library they can order it from out of the region/state whereas an archived link may be the only accessible point of entry so it seems contrary to attribution to hide that information from the public. Also if they are regular editors and see the archive they may be prompted to go to the Wikipedia library and request access, thanks Atlantic306 (talk) 20:25, 1 August 2018 (UTC)
      • I'm not concerned about archives deciding to quit supporting Wikipedia:The Wikipedia Library. I think that's an unlikely outcome. The bigger problem IMO is sending readers to this type of website without telling them where that link goes. In this case (unlike with a direct link to an academic journal), there's almost nothing in these big archives that couldn't be found through some other provider. WhatamIdoing (talk) 17:51, 3 August 2018 (UTC)
  • Daß Wölf makes a good point. --Nemo 12:55, 6 August 2018 (UTC)
  • Allow. I agree that the URL and via parameters should be omitted when the DOI redirects to the same URL. Other than that, I see several potential use cases for |via= and am not at all bothered by its inclusion even where it is unnecessary.
Reasons for the |via= parameter:
  1. To clarify links from multiple sources.
    {{cite thesis |last=Mirkovic |first=Alexander |year=2002 |title=Prelude to Constantine: The Invented Tradition of King Abgar of Edessa |id=Order No. 3047451 |publisher=Vanderbilt University |url=https://www.academia.edu/2028649/Prelude_to_Constantine_Dissertation |via=Academia.edu |access-date=31 August 2017}} Also available via [http://search.proquest.com/docview/276422499 ProQuest].

    Mirkovic, Alexander (2002). Prelude to Constantine: The Invented Tradition of King Abgar of Edessa (Thesis). Vanderbilt University. Order No. 3047451. Retrieved 31 August 2017 – via Academia.edu.  Also available via ProQuest.
  2. To help the reader find the item. This can broadly apply to all links to sources other than the publisher.
  3. To alert the reader which subscription service it is behind. When the content is behind a paywall, and the reader may want to know which one if they have subscriptions to some and not others.
Many TWL citations can claim at least one of these legitimate purposes, even if I would prefer the |via= parameter be omitted in most cases. Daask (talk) 19:44, 14 August 2018 (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.

Readers first?

WP:5P1 used to read Wikipedia is an encyclopedia written for the benefit of its readers [1] and I've continued to believe that but now note that it currently doesn't mention written for the benefit of its readers.

Was this an intentional change of policy?

I raise it here because it seems to me to be a major change to policy. Happy to take it to another page if that is more appropriate. But I'd like us to consider putting it back somewhere, perhaps not at 5P but somewhere! Or is it still there and I'm missing it?

I've done a little research, see here, following a post at an RM which asked whether readers or editors were our primary focus, and which caught me a bit by surprise.

It's been discussed before I see, again there are several links in my sandbox, but I can't see evidence of consensus to change this principle. Again, am I missing it? TIA Andrewa (talk) 20:43, 25 August 2018 (UTC)

  • It was added on 10:07, August 17, 2007‎ by Dhaluza (talk · contribs) with edit summary " 'written for the benefit of its readers'. See discussion on talk page."
  • The talk discussion appears to be this one
  • It was taken out on 09:09, March 9, 2008 by Centrx (talk · contribs)in 2012with edit summary "Fix some recent regressions, which dictate editors' intentions, and word order)". This user seems to have lost it in 2012 and has been indeffed since then.

────────────────────────────────────────────────────────────────────────────────────────────────────

  • Support restoring this text. Might seem obvious but then again, sometimes I wonder. It does seem like a reasonable thing to say out loud instead of imply. NewsAndEventsGuy (talk) 21:17, 25 August 2018 (UTC)
  • Oppose - Is there evidence that a significant number of editors think the encyclopedia's mission is to serve editors? If not, these would be more wasted words added to the ever-growing heap of wasted words.
    Editor1: "Per WP:5P1, Wikipedia's mission is to serve readers."
    Editor2: "I'm serving readers."
    Editor1: "No you're not, because [...]"
    Editor2: "Yes I am, because [...]"
    Repeat until one editor is tired. The preceding was not a productive discussion.
    Except for rank vandals, I've never seen an editor who didn't believe they were benefiting readers. Rank vandals don't read the pillars, and we don't need pillar language to deal with them. ―Mandruss  23:49, 25 August 2018 (UTC)
Good point, asking "how will it make a difference in practice?" Guess I don't have a good answer to that. How about you, @Andrewa:? Can you explain how it would make a difference in practice? NewsAndEventsGuy (talk) 23:55, 25 August 2018 (UTC)
I do so below. Andrewa (talk) 06:28, 27 August 2018 (UTC)
  • Oppose - 5P1 is about what Wikipedia is, or more specifically how the community understands what it means to be an encyclopedia. It's not a mission statement; it's a description of content/genre. That it's supposed to be for readers can be tacked on to any of the pillars ("if rules prevent you from improving Wikipedia for its readers, ignore all rules"; "we strive to serve readers by writing in an impartial tone"...). I also don't necessarily agree. Wikipedia is for everybody, regardless of whether they read it. It's also for people who want to reuse its content, for example. What's important for 5P1 is that it's an encyclopedia. That doesn't mean it's not for readers -- just that that adds a different dimension that's both unnecessary and potentially distracting. — Rhododendrites talk \\ 01:47, 26 August 2018 (UTC)
  • Oppose - While I agree it sounds like some nice, grandiose sentiment, it's really pretty meaningless. Like, it doesn't need to be said that Wikipedia was made "to benefit its readers". That's kind of implied with any encyclopedia, any educational material, or arguably any written work. There's nothing special about the fact that it's there to benefit readers. Is there a conceivable reality in which volunteers from all over the world collaborate to create a vast, free compendium of human knowledge without the intention of "benefiting readers"? It's kind of silly if you think about it. Spelling it out in 5P1 just sounds self-congratulatory and arrogant. Swarm 07:41, 26 August 2018 (UTC)
  • Support and yet, just to say Wikipedia is an encyclopedia written for the benefit of its readers does have the markings of "WTF? over". Maybe we should consider something like, Our encyclopedia combines many features of general and specialized encyclopedias, almanacs, and gazetteers. It is written by readers for the benefit of readers. Wikipedia is not a... (in order to express its primary distinction)?  Paine Ellsworth  put'r there  16:13, 26 August 2018 (UTC)
  • Just to clarify, what I support is the need to be "up front" about readers writing for readers. And I've adjusted 5P1 in the following manner:
Encyclopedia icon.svg
Wikipedia is an encyclopedia
This encyclopedia was created and designed to be written by readers for the benefit of readers. It combines many features of general and specialized encyclopedias, almanacs, and gazetteers. There are several things that Wikipedia is not. Wikipedia is constructed so that future generations can also benefit from the ever-increasing sum of all knowledge found on these pages.
Thank you! for your time.  Paine Ellsworth  put'r there  13:28, 28 August 2018 (UTC)
@Paine Ellsworth: Why did you remove the list of things that Wikipedia is not? I think that is an equally important feature of this pillar (even since the 2008 revision that the original proposer cites) that your revision is deprioritizing. Mz7 (talk) 20:00, 29 August 2018 (UTC)
To Mz7: because it's pillar one, and I can't see starting out so negatively, "WP is not this and WP is not that" not not not. It's still there in the link to What WP is not. Guess I think the first pillar should begin on a more positive note.  Paine Ellsworth  put'r there  04:42, 30 August 2018 (UTC)
  • Support I think this needs to be forefront, as there are editors that, while not necessarily OWNing articles, tend to put how they feel a topic should be presented over clarity of the readers. The infobox wars are one area that I think suffers from, where the omission of infoboxes from articles are to make the article pleasing to editors but without considering readership. --Masem (t) 16:23, 26 August 2018 (UTC)
  • Supplemental In followup to my "support" notvote above I just ran across a good quote in The "Elements of Editing: A Modern Guide for Editors and Journalists" by Athur Plotnik (1982 ed) ... An editor edits above all to communicate to readers, and least of all to address the sensibilities of editorial colleagues. (pg 2) I often think a lot of the drama at Wikipedia is for recreational drama over what are frequently arbitrary issues. I wish that didn't happen. On the other hand, I still don't see how adding the text (which I support for feel-good reasons) will really make a difference in practice. NewsAndEventsGuy (talk) 19:55, 26 August 2018 (UTC)
  • Support if only from conservatism - we ought not to be messing with this fundamental page without a very clear consensus and wide discussion. This is also an important principle which should be upfront somewhere. Johnbod (talk) 01:31, 27 August 2018 (UTC)
  • Support (disclosure: I of course started this section and suggested restoring the clause, this is just to make it explicit). This section was started specifically because a contributor asked Does Wikipedia exist for the benefit of its readers or for the benefit of its editors? [2] which took me by surprise, and then I found out that they were right, our policies didn't say either way. The answer to me is commonsense, and some seem to agree, and think that it's unnecessary to spell it out. But it would obviously help at least one editor if we did spell it out, and I cannot see any downside to spelling it out, nor any previous consensus to make this change to the first pillar, and it seems unlikely that any such consensus could be achieved now. So the clause should be restored, for several reasons. Andrewa (talk) 06:28, 27 August 2018 (UTC)
  • ? That discussion is about disambiguation pages. The most relevant guideline is MOS:DAB, which starts with: "Disambiguation pages (abbreviated often as dab pages or simply DAB or DABs) are non-article pages designed to help a reader find the right Wikipedia article when different topics could be referred to by the same search term, as described in the guidelines on the Wikipedia:Disambiguation project page. In other words, disambiguation pages help readers find the particular article they want when there is topic ambiguity." -- In its first two sentences, that dab pages are for readers is stated twice. — Rhododendrites talk \\ 14:22, 27 August 2018 (UTC)
Heh, speaking purely from wholesome naïveté, the ideal answer to that question is that Wikipedia's editors are its readers. In other words, all readers of Wikipedia are nominally also its editors, because all readers have the technical ability to edit most articles. This is the core principle of Wikipedia really: an encyclopedia written by the people who use it. This is somewhat codified in that third pillar. Obviously, there are many more distinctions made in practice: between active editors, once-a-month editors, blocked editors, readers that don't know how to edit, readers that know how to edit but aren't interested. In short: ideally, Wikipedia exists for everyone. Mz7 (talk) 06:21, 28 August 2018 (UTC)
That discussion is about disambiguation pages. Agree. But the question raised there applies to all of Wikipedia. The main namespace, containing the articles, DABs and some redirects, is the encyclopedia proper. But all other pages, including project pages, talk pages, even use pages and the other weirder namespaces, exist to support the presentation and development of the main namespace. In this sense, all of Wikipedia exists for its readers. Andrewa (talk) 06:29, 28 August 2018 (UTC)
  • Oppose I'm not saying it shouldn't be written for its readers, just that it is of too little value to say in a very valuable space giving the major principles for editing Wikipedia. The case needs to be made that this is a principle that if new editors are not made aware of they may edit in way that is significantly worse. Dmcq (talk) 19:50, 27 August 2018 (UTC)
  • Support in part, oppose in part. I wouldn't be opposed to including something to this effect in the description below the header "Wikipedia is an encyclopedia", but I don't think it should be added to the header itself. Back in 2008, it wasn't bolded either. I fear that if it's added to the header it may distract a little from highlighting the importance of the WP:NOT policy, which is also what the first pillar is about. Mz7 (talk) 05:51, 28 August 2018 (UTC)
    • My original suggestion was in fact that it mightn't be added to WP:5P at all, just somewhere. Andrewa (talk) 06:32, 28 August 2018 (UTC)
  • Support. WP:5P1 Wikipedia is an encyclopedia. What is an encyclopedia?

"Indeed, the purpose of an encyclopedia is to collect knowledge disseminated around the globe; to set forth its general system to the men with whom we live, and transmit it to those who will come after us, so that the work of preceding centuries will not become useless to the centuries to come; and so that our offspring, becoming better instructed, will at the same time become more virtuous and happy, and that we should not die without having rendered a service to the human race in the future years to come."
Diderot Reference: Denis Diderot and Jean le Rond d'Alembert Encyclopédie. University of Michigan Library:Scholarly Publishing Office and DLXS. Retrieved on: November 17, 2007

An inherent part of purpose of an encyclopedia is to transmit the knowledge widely, to all people, including to people suffering from systematic bias. Merely to mention systematic biases causes people to think on it, and it leads to better decisions on helping the product being available to the widest audience. Wikipedia is not a repository, it is a living, growing document with purpose. Imagine a world in which every single person on the planet is given free access to the sum of all human knowledge. That's what we're doing.
Three essays that immediately come to mind on belonging in WP:5P1 are Wikipedia:Reader, Wikipedia:Readers first, & Wikipedia:Product, process, policy. The third does not include mention of "readers", but it does expound on "improving our encyclopedia", which begs the question "for who". --SmokeyJoe (talk) 06:17, 28 August 2018 (UTC)
Is it worth mentioning that re: the Encyclopedie quote, that encyclopedia was a for-profit venture, with constant tensions about changing text to please the church, the state, publishers, editors, writers, etc. with all sorts of financial, philosophical, religious, anti-religious, political, radical, professional, and personal interests wrapped up in its production? :) (this isn't a real attempt at rebuttal btw, but here is a fun example of Diderot writing about his resentment about having to include material his publishers insisted readers wanted). — Rhododendrites talk \\ 15:28, 28 August 2018 (UTC)
Yes, it's always worth mentioning such things; might even be therapeutic both for the mentioner and the mentionees. There were a lot of things that I don't think anybody could have predicted. This was a crazy new endeavor after all, with surprises all around. And here we are, still trying to improve even our pillars. Seems to me that the phrase, "just keeps gettin' better and better" sounds less and less sarcastic over time. Wikipedia rocks!  Paine Ellsworth  put'r there  18:07, 28 August 2018 (UTC)
  • Support Everything should circle back to readers. Sometimes it seems like we blindly follow a policy or guideline, or edit based on writers' needs.—Bagumba (talk) 09:37, 30 August 2018 (UTC)
  • Support restoring. It helps to set the tone and focus, even if not strictly necessary. Peter coxhead (talk) 10:35, 30 August 2018 (UTC)
  • Oppose, out of fear that someone will point to that clause to justify something that would arguably help readers but isn't encyclopedic. Also doesn't really communicate anything, so it just adds text. One of the things that's great about the pillars as they are is that they are concise and easily readable. Compassionate727 (T·C) 13:35, 31 August 2018 (UTC)
  • Oppose because the language can be used to argue that every other policy should be ignored if the material in dispute is "beneficial to the reader". Indeed, the argument made by the IP editor, below, may at least imply this very argument. That is, of course, a specious argument, but we don't need to fuel it. - TransporterMan (TALK) 02:53, 14 September 2018 (UTC)

I would like to hear more

There are two early oppose !votes above.

Both seem to agree that the principle is sound and important, but think it unnecessary or even inappropriate to spell it out, and that in practice it makes no difference to do so. I hope I have answered that.

We seem agreed that the change was made without consensus support.

But I have been in consensus-based decision making processes where the motion was put and there were literally hundreds against a handful, so the chairperson said let's just hear from the handful and they convinced us. In that spirit, Mandruss and Rhododendrites, I'd like to hear more.

And the other person who might contribute something relevant is Robkelk, who (rightly as it turned out) asked the question that so startled me. So pinging him too. Andrewa (talk) 06:54, 27 August 2018 (UTC)

Yikes.
It looks like you're trying to spin the opposition in a way that seems to support this proposal... and you're doing it at multiple venues (that one of them is Talk:Fan (machine) makes me think this is more about that argument than 5P). I explicitly said that Wikipedia is for everybody. It's for people reading it, listening to it, writing it, looking at its pictures and graphs, republishing it, referencing it, analyzing it, etc. I suppose that can all be boiled down to "readers" but let's not turn this into a self-evident question of "are readers important?" Bringing it back to that discussion this seems to be about, at the fan article, "think of the readers" shouldn't be a trump card in an argument, but it's relevant to the disambiguation process. The way to propose a change that would make dab pages more useful to all users is to start a discussion about our disambiguation process, not to add something to 5P to use as basis for that dab argument (apologies if I'm misreading that thread).
I hope I have answered that. - Where?
We seem agreed that the change was made without consensus support. - ??? No. Someone added the text, legitimately, based on a very small discussion on the talk page. Someone else removed it a year later, legitimately. Nobody contested it. Then it sat there on one of the most visible projectspace pages for ten years. WP:IMPLICITCONSENSUS. I.e. the evidence that there was consensus for it is that it sat uncontested for ten years. — Rhododendrites talk \\ 13:53, 27 August 2018 (UTC)
The regrettable shortcut "WP:IMPLICITCONSENSUS" carries an unfortunate vibe of weight that runs contrary to the spirit of consensus. This shortcut is only a few months old and I objected at the time (but with very little input from others and I didn't feel like fighting). So here we have an authoritative table-pounding using this shortcut as the gavel. Well, look deeper. The shortcut points to a section in our WP:CONSENSUS policy. In that section is another link which points to our explanatory supplement WP:Silence and consensus. There we see a section titled "Silence is the weakest form of consensus". In the same vein, since Aug 2011 our essay WP:Arguments to avoid in discussions (rated mid-importance) rejects WP:CONTENTAGE as a reason for much of anything. Finally, assuming there were ever any consensus about any of this, we come full circle to our consensus policy, which provides WP:Consensus can change. In short, the mere passage of time can not turn "I just don't like" reasoning into slam-dunk reasoning. In even fewer words maybe we need a shortcut that says WP:Time means squat. NewsAndEventsGuy (talk) 14:22, 27 August 2018 (UTC)
Sidestepping your opinions about implicit consensus, which we can talk about elsewhere if you want, the point is that Andrewa argued the small discussion that led to the text being added in the first place should carry such a forceful consensus that when someone changed it a year later it was (a) illegitimate and (b) doesn't matter that nobody contested the change -- not then, despite having hundreds of people watching it, and not in the ten years since then. Consensus can change, absolutely, so I wouldn't argue that what has stood for ten years can't be changed, either, but the idea that what has been there for ten years should be undone because a handful of people had a talk page discussion the year before but didn't contest the change is absurd. — Rhododendrites talk \\ 14:32, 27 August 2018 (UTC)
I don't mean to twist your words but I think I agree. To be specific, I think that what happened in the long ago means squat and the important thing is what people think today. If that's what you said, then yes I agree. If that's not what you said please elaborate a little where I got it wrong. NewsAndEventsGuy (talk) 14:40, 27 August 2018 (UTC)
Close enough. :) I would personally grant a bit more weight to what managed to stick on a highly watched page for a decade, but neither of them need to dictate what happens now (i.e. it's less that I want to preserve some action from ten years ago and more that I disagree with Andrewa's notion that a change "made without consensus support" ten years ago is relevant to this discussion). — Rhododendrites talk \\ 14:57, 27 August 2018 (UTC)
Agree that neither of them need to dictate what happens now and the important thing is what people think today.
The lack of consensus support at the time of the change would be relevant only if we cannot come to a consensus decision on the wording now. Far better not to go there. But in that unfortunate scenario, it becomes relevant, unfortunately. Andrewa (talk) 20:10, 27 August 2018 (UTC)
I knew that question was going to kick off debate, even when I asked it. I've seen cases at other wikis where the act of creating and naming and filling in pages in just the right way, even when particular requirements would never be noticed by most people who use the wiki, got in the way of collecting and sharing information. The former is what I was thinking about when I asked whether the wiki existed for the editors, and the latter is what I was thinking about when I asked whether the wiki was for the benefit of the readers. That said and out of the way, we come to this proposal. If it needs to be said so that we focus on everybody who uses Wikipedia instead of focusing on those of us who edit here, then let's say it... but I hope that it wouldn't need to be said. Thus, I'll abstain on voting here. --Rob Kelk 00:09, 28 August 2018 (UTC)
As it turns out, you were probably wiser than I. Apologies. Andrewa (talk) 06:15, 28 August 2018 (UTC)

The principle

We seem to have answered part of the question. Nobody seems to doubt the truth or validity of the point that Wikipedia is... written for the benefit of its readers (my emphasis). Some see it as good to say so explicitly, while others object strongly to doing so, but nobody questions the principle itself.

So getting back to the original question, is this a fair comment? Andrewa (talk) 11:18, 27 August 2018 (UTC)

See above. — Rhododendrites talk \\ 14:14, 27 August 2018 (UTC)
OK... but what exactly is wrong with it? Andrewa (talk) 20:04, 27 August 2018 (UTC)
The supports and opposes are to restoring the text, following the first respondent’s lead. If you are not proposing the text be restored, and are simply trying to clarify whether “Wikipedia is written for its readers”, then it would be fair to say both the supporters and opposers agree that it, of course, is. It would be completely inappropriate to change the wording based on this though, because you cannot override the opposers just because you want to. You would need to make this an RfC with wide community advertisement to make changes to the text, given the fact that this is a controversial proposal. Swarm 20:10, 27 August 2018 (UTC)
Yes, there is a poll above (not initiated by me) into restoring the text.
Initially I was certainly asking whether we should restore the text, but also whether this had been a deliberate policy decision. And that seems to have been answered in the negative, there was no intention to change the policy, just to remove unnecessary clarification, and there is still no intention to change it. The only disagreement is as to how the policy should be expressed.
So far, several editors have supported the proposed change, and two have opposed. But both of these appear to me to support the principle. I really do not see what the fuss is all about.
I'm certainly not trying to fork any discussion. I'm trying to centralise discussion here on these matters, on which a heads-up was posted (again not by me but I think it was a good thing and said so) at WT:5P#Wikipedia is an encyclopedia written for the benefit of its readers. Both issues are obviously of relevance to that talk page. I have replied there to comments made there, but if anything, others are forking the discussion, not me.
A formal close to the poll would be good IMO. Where we go from there depends largely on the close. Andrewa (talk) 20:49, 27 August 2018 (UTC)
The repeated misrepresentation of this thread is getting concerning. ... and two (yourself included) have opposed -- at the time you wrote that four users had opposed, and five (yourself included) had supported. — Rhododendrites talk \\ 20:51, 27 August 2018 (UTC)
An honest mistake which I tried to correct but have had several ECs... one of which at least was probably one of the oppose !votes.
Please read WP:AGF and consider adopting it. Andrewa (talk) 20:56, 27 August 2018 (UTC)
Fair enough. I suppose that was a bit harsh. Struck the first part with apologies. — Rhododendrites talk \\ 21:26, 27 August 2018 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Rock in pond.... I might switch to "oppose". Here's why.... let us assume for sake of argument that everyone agrees (at least on paper) that Wikipedia is for the reader's benefit. Now suppose we say that on paper. What would be the impact of such a decision? Mandruss (talk · contribs) has already contemplated a new (sad) line of argument in the ephemeral debates we have to deal with. The only reason I first voiced support is the wishful hope that saying this would magically reduce some of the questionable behaviors from longtime users. But the discussion and further reflection leaves me thinking that there isn't really anything constructive to be gained here. The question arose at a great example where two options were being considered for an article title, "Mechanical fan" versus "Fan (Mechanical)" and somehow the differing views in the talk thread were boiled down to two supposedly conflicting policty statements, and supposedly the determining factor would be whether Wikipedia is (or is not) "For the benefit of readers" (Same diff that Andrew posted above) I am not qualified to offer an opinion if the logic is sound, because I am an involved editor championing a third option ("Fan (air circulation)"). But I'm not impressed that the partipants arrived at a point of trying to reconcile their reading of policy on this question. This is the sort of unexpected thing that could happen if this text is restored. "First do no harm". Before we risk inviting new lines of possibly lame argument by restoring/adding this text, what exactly do we gain? How will it be used to make the project better ? In my mind, this is how the question should be decided. Before I bother with the clerical task of switching to oppose, I thought I'd float the qustion a second time, since your first attempted answer "it would help at least one editor" wasn't really an explanation . NewsAndEventsGuy (talk) 23:13, 27 August 2018 (UTC) PS At the source venue, if the two policies being debated are indeed in conflict (on which I'm dubious but neutral) then the answer is not messing with a third policy. Instead the two supposedly conflicitng ones should be refined so they are in harmony. NewsAndEventsGuy (talk) 23:25, 27 August 2018 (UTC)

It would help at least one editor was my whole reason for making the suggestion that we consider putting it back somewhere, perhaps not at 5P but somewhere (please note that someone else then decided to make it a poll). Actually it's two editors... I used to refer to this policy a great deal. Now I guess I'll need to appeal to commonsense instead, which doesn't seem an improvement. But for every user who says they have the problem, nine others know they have it and don't say. For every user who knows they have it, nine others have it and don't know. On the other hand, there seems no harm in making it explicit. It's agreed that Wikipedia is for readers, the policy used to say that, and the case for removing it seems incomprehensible to me... mere speculation as to what damage it might cause, with no evidence that it did cause any damage at all in the years it was policy, but strong feelings that the damage would be there.
But really, it's not worth this angst. I still support making it explicit (again), but if commonsense it must be, commonsense it will be. I fear that will lead to more fruitless discussion not less, but nothing we can't deal with. Maybe we just need to do so. Eh bien, continuons. Andrewa (talk) 06:07, 28 August 2018 (UTC)
A valiant effort to make a change for good, but IMHO I think "fruitless discussion" would be unchanged either way. Some folks just like to argue about nothing. And to emphasize the #1 thing I got out of this, in the source issue at Talk:Mechanical fan if the two policies claimed to be in conflict are really in conflict, the answer lays in refining those policies so they march in harmony. NewsAndEventsGuy (talk) 11:50, 28 August 2018 (UTC)
I used to refer to this policy a great deal. Good, some actual practical experience, something real, empirical evidence. The question is: When you referred to this policy, did that affect the outcomes?
if commonsense it must be, commonsense it will be. No, "common sense" is equally useless, as it varies widely between individuals. It's been clearly established that the number of editors who don't understand that this encyclopedia, like all encyclopedias, exists to serve readers is zero or insignificant. That means you don't need a pillar to refer to to make that argument in a discussion. Whether the argument succeeds or not is a matter of consensus like everything else. ―Mandruss  22:42, 28 August 2018 (UTC)
Strongly disagree that it has been clearly established that the number of editors who don't understand that this encyclopedia, like all encyclopedias, exists to serve readers is zero or insignificant. On two grounds. I don't think that has been demonstrated at all, but respect your opinion that it has been, and again I'd like to hear more. But more important, no editor or group of editors is insignificant. Take care of the pennies and the pounds will take care of themselves.
At the risk of linking to my own essay, perhaps we might address the underlying concerns by promoting and/or developing User:Andrewa/creed? This concentrates on the positives rather than the negatives, as did the for readers clause of course. Andrewa (talk) 18:01, 29 August 2018 (UTC)

I think this concept is something that probably gets overlooked more than people realize. I won't get into specifics to avoid any drama, but recently there was a portal that made a decision about the templates of their articles, in favor of removing information. The community of readers voiced their opposition to it pretty clearly and loudly, but were ignored in favor of "policy" (no specific WP was cited), and even the compromise (removing bullet lists, and rewriting the info as prose) was ignored in favor of simply removing the information. As a result, READERS were negatively impacted. While people may feel this is a "common sense" thing, having it stated officially would go a long way to resolving issues regarding content that may not fall in line 100% with all guidelines, but is beneficial to readers nonetheless. 64.222.174.146 (talk) 14:53, 10 September 2018 (UTC)

  • A proper month long RFC after which uninvolved admins made a policy based decision to remove the section from pro wrestling articles. Misrepresenting the process shows that some people will never be happy with a process that does not support their POV.  MPJ-DK  02:11, 11 September 2018 (UTC)
Feel free to correct whatever was misrepresented. I pointed out it ws a policy based decision, and also that no specific policy was cited. I even went back and double checked to make sure my memory wasn't biased. Nothing I said in my comment was misleading, at least not intentionally. I specifically support this because of the fact that policy decisions can be made without factoring this bit of "common sense" into account, as its not officially stated anywhere. I intentionally didn't mention specifics so as to avoid dealing with people biased for/against the previous topic, as the topic itself is mostly irrelevant. My point was it would be nice to have this somewhere so policy based decisions can weigh it accordingly. 64.222.174.146 (talk) 16:20, 13 September 2018 (UTC)
So if I am reading this right your argument is that no policy was cited in the closure? There were plenty of policy based arguments made by participants and the closer agreed that the policy based arguments of one of the sides is what decided the outcome. Or am I misreading your comments? Not sure what "for the readers" would have invalidated there, it is not Wikipedia-Kryptonite that trumps all else. MPJ-DK (talk) 22:52, 13 September 2018 (UTC)
Not trying to argue for/against that specific subject any more, that point is moot. The point I am making is that when a decision is being made based around policies, having a policy in place that factors in stuff like a large contingent of readers being against a change. The arguments to make a change may be based around policy, and may be valid, but when a majority of the people actually reading the content are against the change, this policy prevents the outright dismissals of "Just because you like it doesn't mean it should stay." 64.222.174.146 (talk) 16:18, 14 September 2018 (UTC)

Heads-up at the project talk page

A heads-up has been posted at WT:5P. Andrewa (talk) 11:29, 27 August 2018 (UTC)

How to deal with articles meeting SNGs but not GNG?

This RfC is a followup to a June 2017 RfC clarifying the relation between SNGs and the GNG. Consensus was established that SNGs do not supersede GNG, but there was no consensus as to what to do about the articles not apparently meeting GNG. A pre-RfC discussion has show two major issues: What the final result should be, and what to do in the interim to avoid flooding AfD and related venues, which will be discussed as a follow up. The main options are keep, tag, merge, transwiki or delete.— Alpha3031 (tc) 03:20, 3 September 2018 (UTC)

Proposals

  • Flawed question that RfC changed nothing in WP:N, which makes it clear the SNGs are 100% equivalent to the GNG: the close was perhaps the worst RfC close I have ever read and is an example of closers trying to tell a narrative rather than actually answer the question the RfC at the time posed, which was re: WP:NSPORTS, an SNG that already subordinates itself to the GNG. As the RfC itself was not advertised as a major change to the notability guideline, nothing in the notability guideline itself changed: it just reinforced the status quo on one specific guideline. This RfC is not needed, as WP:N already covers it: SNGs == the GNG and GNG != N, SNG !=N, but instead both create a rebuttable presumption of notability. TonyBallioni (talk) 03:26, 3 September 2018 (UTC)
  • I don't follow what's going on here. That RfC applied to NSPORT, but the conclusion in question shouldn't be controversial. The GNG is just an application of the idea of notability, to ensure that we only cover subjects that have received significant coverage in reliable sources. If a subject does not have coverage, we should not have an article on it. If an SNG purports to trump the GNG and allows for articles on subjects that do not have significant coverage in reliable sources, it should not have guideline status. Or we could just kick out the either/or language in WP:N and clarify that SNGs are conditions under which something can typically be presumed to be notable in the sense of having received significant coverage in reliable sources, but that it ultimately comes down to that coverage. — Rhododendrites talk \\ 04:07, 3 September 2018 (UTC)
    • @Rhododendrites: The contention is around the (optimistically) 1% of articles that meet SNG for which GNG cannot be demonstrated. At what point do we delete the article for not meeting GNG, versus maintaining that SNG is met and sufficient coverage—though unidentified—does exist.—Bagumba (talk) 09:04, 3 September 2018 (UTC)
      • @Bagumba: But the GNG also only requires that sources exist, so in this example those articles are still expected to meet the GNG -- it's just they can only demonstrate one. Which is problematic, because when something is challenged the burden is on those who want to include material to show coverage. Winning a particular award may be a good indication of notability sufficient to create an article before checking for additional sources, but if those additional sources cannot be found sufficient to question whether they exist, someone else would be justified in nominating it for deletion. If we have an article that does not have significant coverage in reliable sources, we have an article that's either a permastub or based on unreliable sources. To be clear, I'm reframing more than disagreeing with what you're saying. — Rhododendrites talk \\ 15:05, 3 September 2018 (UTC)
  • I second on flawed question That 2017 RfC was related to Wikipedia:Articles_for_deletion/Magdalena_Zamolska, an AfD closed as "delete" that featured roughly as many "fails GNG" !votes as "pass SNG". All things being equal, an SNG does not eclipse GNG; in fact, many SNGs have verbiage saying they were written so that GNG is likely met. However, it would be a failure to assess consensus to have a few "fail GNG" !votes overriding a strong sentiment that it "meets SNG". It's up to the !voters to exercise judgement on when an SNG is sufficient (or not). The usual outcome is that domain "experts" are more likely to follow SNGs and believe that sources could eventually be found, while "outsiders" are more open to entertaining whether GNG is actually demonstratable now.—Bagumba (talk) 08:53, 3 September 2018 (UTC)
  • Needs Different Question - Thought I am strongly on the (modern) NSPORTS MUST meet GNG, I am having to agree that that close is not sufficiently clear. It's more a renumeration of near-unianimously agreed traits. Instead a formal proposal along the lines below should be made. I've narrowed to NSPORTS for now, as I've noted in the discussion I think most would agree existence is good for pre-modern (I roughly use 2000) articles, and a cross-SNGs risks excessive complication. NSPORTS is one of the bigger AfD GNG/SNG clash issues:
  • @Nosebagbear: The opening sentence of NSPORTS already states that the guideline " is used to help evaluate whether or not a sports person or sports league/organization (amateur or professional) is likely to meet the general notability guideline" Implicitly, GNG should usually be met by meeting the SNG. Are you stating that articles on modern sports subjects should not be covered by NSPORTS? Or are you saying that some existing NSPORTS criteria need to be tightened to ensure that GNG is likely to be met?—Bagumba (talk) 10:56, 3 September 2018 (UTC)
I would say it is more a case of “A demonstratable lack of source material (non-GNG) can sometimes out-weigh the presumption of notability (SNG)”. In other words... since SNG is based on the presumption that sources are LIKELY to exist, to out-weigh the SNG the nomination needs to make a convincing argument that the presumption is wrong... that (in the specific case) the expected sources DON’T actually exist. Blueboar (talk) 12:00, 3 September 2018 (UTC)
AfD is generally not thrilled if someone fails to make a case that GNG isn't met. Since in attempts of proving a negative you are somewhat forced to go off the person's assertion that nothing could be found. The only place where some difference might apply is when debating things like marginal Sig Cov cases. Nosebagbear (talk) 12:10, 3 September 2018 (UTC)
The relationship between the sports-specific notability guidelines and the general notability guideline has been discussed many times and the consensus has been the same since their inception. Closers who fail to acknowledge that the guideline itself says that the general notability guideline must eventually be met and that only meeting the sport-specific guideline doesn't automatically mean an article should be kept are supervoting. The criteria for baseball, hockey, and association football (and I believe others) have been reviewed and revised over the years to improve their accuracy in predicting that the general notability guideline can be met. Suggestions for improvement are always welcome. isaacl (talk) 21:23, 3 September 2018 (UTC)
No, that's not the discussion that's been had. It's been clearly recognized that if an article meets NSPORTS, but someone does a proper search of sources (as outlined in BEFORE) and finds nothing more to expand on that topic, then the presumption of notability that the SNG grants has failed, and the article can be deleted. However, 90% of the time, at these AFDs, people have not shown a proper BEFORE search for sources to prove this satisfactory (as it generally requires local newspaper archive searches.). NSPORTS remains a presumption of notability with the expectation that more sourcing will come to expand the article. --Masem (t) 21:27, 3 September 2018 (UTC)
I'm not really sure what discussion you believe has not been had. As you know, I am aware of what you've said is clearly recognized; I just didn't describe it (people can go look at the FAQ for a precis of the consensus on the matter). Given that the 2017 RfC was really about WP:NSPORTS, I'm don't know if Nosebagbear's desire to narrow the question to WP:NSPORTS is really needed. What we need is for closers to respect the consensus that for sports-specific guidelines, meeting the SNG is not a free pass forever. isaacl (talk) 21:41, 3 September 2018 (UTC)
  • Question is fine just needs clarification. It is not to re-define V, GNG, or SNG, but on the practical aspect of it -- what do we do with the (tons and tons) of sports bios that meet SNG but not GNG? Do we do nothing? Do we delete them? Renata (talk) 13:55, 3 September 2018 (UTC)
  • Comment - The purpose of SNGs is to allow articles to exist that may not otherwise meet notability guidelines. Therefore, no action is needed. — Godsy (TALKCONT) 05:44, 10 September 2018 (UTC)

Discussion

  • We do nothing. Coming from NFOOTBALL perspective - there is plenty of AFD consensus that an athlete technically meeting the SNG but failing GNG was not sufficient. What the SNG is intended to do is to give the article breathing room to meet GNG - it is an assumption of notability. How long that breathing room lasts before expiring is dependent on the subject of the article. GiantSnowman 08:00, 3 September 2018 (UTC)
  • The GNG is little more than a mostly accurate predictor of whether the article will be deleted at AfD. The SNGs are largely forulated as predictors of whether the sourcing would meet the GNG. The SNGs are mostly much easier to test, which makes them more useful for quick decisions, like whether you should bother making those stubs. The real test is a well-participated AfD. --SmokeyJoe (talk) 09:02, 3 September 2018 (UTC)
  • I tend to agree with the comment above by SmokeyJoe. Some people seem to think that the concept of notability and GNG are well defined but to me they are extremely vague. The merit of SNG is that they are (or at least, ought to be) very precise. At the end of the day, if there is dispute, the issue can only be decided by discussion and consensus. The great merit of SNGs is that they can be discussed, and the result applied to many biographies. To me the main problem with SNGs is not the concept of them but the fact that many of them are currently badly formulated. Many attempts to reformulate them seem to mired down by supporters of the GNG concept who generally put a spanner in the works. Nigej (talk) 10:17, 3 September 2018 (UTC)
  • But NSPORTS is frequently criticised as failing miserably at the "he SNGs are largely formulated as predictors of whether the sourcing would meet the GNG" requirement. It doesn't act as a good proxy like NFILM etc. There is good acceptance for some lower boundaries - GEOLAND etc. But for a modern (2000+) footballer etc, I wouldn't say the justifications for that apply. Nosebagbear (talk) 10:28, 3 September 2018 (UTC)
  • I always thought that the paradigm should have been: Policy - an abstract idea with no implementation guidelines -> High-level guideline - detailing how to implement policy ideas -> Sub-guideline (if needed) - specific implementations per subject. In this case, WP:VERIFY -> WP:N -> WP:NSPORTS, with WP:NSPORTS not contradicting either of them, but supplementing specific sport related notability (an advantage of this kind of model is that the policy is only used an argument when changes are needed to a high-level guideline, and a high-level guideline is only used an argument when changes are needed for a sub-guideline. The sub-guideline should be the only thing used in AfD discussions). Sadly this isn't the case (and not only with WP:NSPORTS) --Gonnym (talk) 11:51, 3 September 2018 (UTC)
  • Well, I do know of several sports wikiprojects who assume that "meets our SNG = automatically entitled to an article" and the SNG in question typically sets the inclusion bar so low that it allows the creation of nearly contentless microstubs based on sources without a single word of prose between them. Sometimes-- and I'm not exaggerating-- it is not even possible to unambiguously identify the player. But try to point out that this causes problems with WP:V and WP:BLP, and all you get is blank looks from AfD closers and a campaign of harassment from the wikiproject whose toes you trod on. Reyk YO! 13:39, 3 September 2018 (UTC)
    • ...and that's exactly why this kind of RfC is needed - instead of arguing one-by-one at AfD and getting stampeded by a particular wikiproject, there should be a clear community-wide consensus (that one could easily reference and link to) on what to do with the (tons and tons) of sports bios that meet SNG but not GNG. Renata (talk) 13:55, 3 September 2018 (UTC)
      • The thing is in order to determine that a given sports biography fails to meet the general notability guideline, a discussion is needed, and so following the established procedure by discussing it at Articles for Deletion is appropriate. Changes to the guidelines to make them a better predictor of meeting the general notability guideline are welcomed at the discussion page for sports-specific notability guidelines, and they have been made more stringent for various sports over the years. Closers of AfD discussions should be following the guideline which explicitly states that meeting the sports-specific notability guideline does not automatically mean an article is warranted. isaacl (talk) 21:32, 3 September 2018 (UTC)
    • I agree that often the "SNG in question typically sets the inclusion bar so low ..." To me this shows that the problem are the SNGs not other parts of the process. The SNGs need updating in many cases. Nigej (talk) 15:36, 3 September 2018 (UTC)
  • The issue about the framing of the question is correct. We have to be clear that the GNG is not the bar for notability, it is still a rebuttable presumption for a standalone option. We want articles to develop to a point in their sourcing and coverage that there is no question of the topic's notability (eg we would never ever consider deleting World War II) Both the GNG and the SNGs are presumptions made to favor creation of articles and giving time for editors to work collaboratively to expand, but at the same time there has to be balance with the amount of content. --Masem (t) 14:06, 3 September 2018 (UTC)
    • Yes, we should have SNGs so that we can write articles instead of trying to defend them from being deleted. That's why I engaged in this discussion. See Wikipedia_talk:Notability_(sports). At the same time we should be able to delete non-notable athletes, as @Renata3: explains. The good point with the SNGs is that they provide an easy way to check. NSPORTS lacks for example rules about teams, which is strange. The team is notable for winning and whence the club/federation that put together that team. The members need not to be notable, as notability is not inherited. Per W (talk) 14:22, 3 September 2018 (UTC) Have a look at other Wikipedia's guidelines such as sv:Wikipedia:Att_skriva_om_sport#Relevanskriterier_för_sport (reasonably well translated by google). Per W (talk) 15:47, 3 September 2018 (UTC)
  • I think GiantSnowman has the right idea. Not every discussion needs to result in changes. Unless I'm missing something serious, I don't see the need to change anything.--White Shadows Let’s Talk 22:18, 3 September 2018 (UTC)
  • Re: Closes Isaacl hinted above a couple times that AfD closers may be too lenient with allowing SNG to trump GNG. I am not aware how frequent that happens. However, my experience with NSPORTS—as a participant, not closer—is that the !voters often given more credence to SNG and its presumption that GNG is met. I suspect that the outcome of an AfD is often directly related to the proportion of !voters from an SNG-related WikiProject. At an extreme, the recent Wikipedia:Articles_for_deletion/Cray_Valley_Paper_Mills_F.C. had many citing not an SNG but a WikiProject essay, which resulted in a "no consensus" close. It's the participants that dictate consensus. Those who want change need to help advocate the limitations of SNGs and draw wider participation at AfDs. We should not expect closers to WP:SUPERVOTE.—Bagumba (talk) 04:55, 7 September 2018 (UTC)
    • We've had this conversation before, too: I think guidelines are agreed upon by consensus precisely so the interested parties don't have to show up to AfD after AfD to re-discuss the same underlying principles of how meeting a sport-specific notability guideline isn't necessarily enough once sufficient investment has been made trying to find adequate coverage so that the general notability guideline can be met. If editors are expected to have these discussions ad infinitum, then there's no point in having guidelines. isaacl (talk) 07:24, 7 September 2018 (UTC)
      • It's not that clear cut. Consider Wikipedia:Notability (sports)/FAQ#Q4, which says that there is "no fixed rule" for NSPORTS on what is a reasonable amount of time to uncover sources. If a large contingent cite guidline SNG, and a few expain how it doesn't meet GNG, there is nothing currently in any guideline that allows a closer to supersede the SNG camp because "enough time" has passed. Per the five pillars, "Wikipedia has no firm rules", and a closer generally should not dictate how participants apply guidelines. About the only exception per WP:ROUGHCONSENSUS where a closer should overrule editors' consensus is when policies—not guidelines—like WP:V, WP:OR, WP:NPOV, WP:COPYVIO, and WP:BLP are compromised.—Bagumba (talk) 08:13, 7 September 2018 (UTC)
        • Agreed that it's not easy to balance the two, because it's really hard to show that sources don't exist. But a closer can accept a presentation of the search that was made and agree with the conclusion that it is highly unlikely that appropriate sources exist (and they do it all the time when biographies are deleted). Wikipedia not having firm rules doesn't mean that all interpretations have equal weight; consensus generated from discussions with a broader, larger audience, for example, is more meaningful that those generated from a small number of people. Commenters who say "as per sport X's notability guideline" are availing themselves of this, by making reference to the consensus that agreed upon the guideline (otherwise, for each AFD they'd have to re-make the argument as to why the criteria in question are suitable to indicate Wikipedia notability). However for sports, this includes an explicit deferral to the general notability guideline. The sport-specific notability guidelines were written with this context in mind, and not designed as standalone tests. You can't pick-and-choose just one part of a previously established consensus and then treat it as if it has the same weight. isaacl (talk) 09:01, 7 September 2018 (UTC)
          • I think the scenarios you describe are a minute percentage of gray-area AfDs, where the close could have gone either way and not be subject to WP:DRV. It's my impression that most "meets SNG"–"fails GNG" AfDs are a clear-cut rough consensus one way or the other. By rough consensus, I mean how the actual participants !voted, not if there "really" are sources (or not). If you have specific AfD examples from the past, I think they would be better to discuss than hypothetical cases. Regards.—Bagumba (talk) 09:20, 7 September 2018 (UTC)
            • Well, that's the point: in theory it's not a straight vote, but an evaluation of the existence of sources or the likelihood of sources turning up. Yes, I agree it's a small percentage of AfDs that actually delve into the likelihood of sources, because as I said, it's a hard thing to demonstrate. But it's that small percentage that gets all the flak, with people complaining that the sports-specific notability guidelines are too lax (even though they do get tightened up based on feedback), which re-triggers these same discussions that we're having. And in actuality most people are in general agreement, albeit with differences in emphasis (there are some basic differences in underlying principles in some cases, but nothing that alters what happens in practice), so it's just a big time sink. If these triggers could be minimized it would save these never-ending cycles. isaacl (talk) 17:35, 7 September 2018 (UTC)
              • The claim the sports-specific notability guidelines are too lax is basically "I don't like it." It is incredibly difficult and uncommon for an athlete to reach these levels. You could train every day and do everything right, and still not ever play in a fully professional football game. The sports notability guidelines are very high, and the athletes virtually universally receive a great deal of press. If this wasn't the case, the funds would not be available for them to be professional athletes. Jack N. Stock (talk) 18:13, 7 September 2018 (UTC)
                • It is incredibly difficult and uncommon for an athlete to reach these levels. You could train every day and do everything right, and still not ever play in a fully professional football game. This is true of most careers. Sports are not special in this regard. athletes virtually universally receive a great deal of press Then that evidence should be presented at the AFD in question, not a handwave to the SNG. --Izno (talk) 18:59, 7 September 2018 (UTC)
                • Some were more lax and have been tightened up, so I'll venture that there are others that could benefit from being more strict. The key is how well they predict that the general notability guideline is met. isaacl (talk) 21:53, 7 September 2018 (UTC)
            • Part of the problem with sports is that it's not always clear on how the WP:GNG is met. (Compare to WP:AUTHOR, which provides clear guidelines for notability.) For instance, Major League Baseball has entire print encyclopaedias of anyone who has played on a major league diamond - the existence of these means a SNG allowing any MLB player to have an article will meet WP:GNG 99.9% if not 100% of the time. On the flip side, you have WP:NFOOTY which if a player doesn't meet the SNG has to delve into whether or not WP:GNG is met. The greyest areas, the Cray Valley AfDs, are basically an argument over very grey standards of notability. Also consider Wikipedia:WikiProject_College_football/Notability which basically provide guidelines to keep the majority of the articles they create (I consider this the project with the lowest notability standards I've come across.) I'd personally like to see policy guidance on how to interpret WP:GNG for sports, especially along the lines of: when should coverage be considered routine for athletes AND teams, and when should coverage be considered significant for athletes which don't pass the SNG presumption? Coming from a football perspective, for players/managers/coaches, I'd look for at least two secondary articles which significantly cover the player. Teams are a bit different - I've made the argument several times consistent routine coverage makes clubs notable, mostly from my work into African teams - many top division African teams don't necessarily receive feature article-level stories but receive lots of continual coverage. Also consider encyclopaedias of top flight soccer teams exist (I own a "football atlas" from the early internet age that's now rather out-of-date). SportingFlyer talk 07:43, 8 September 2018 (UTC)
              • For baseball, coverage in baseball-specific encyclopedias is considered to be routine coverage, and so isn't an appropriate source to determine that the standard for having an article is met. There has been discussions on the talk page for the sports-specific notability guidelines regarding judging sources based on the extent of its audience, and on needing to take into account the promotional nature of local sports journalism. But there hasn't been enough engagement from a suitable number of editors to establish a consensus view. The notability of teams hasn't been discussed in much detail (with the recent changes to the notability guideline for organizations, a few conversations have been started but they didn't progress very far). I suspect, though, the key sticking point with a standard that didn't include any feature article-level stories is that it would be hard to write a reasonably descriptive article without them. isaacl (talk) 04:51, 9 September 2018 (UTC)

Areas of Cyprus Republic (de jure)/Areas of Northern Cyprus (de facto)

Hello. First of all I want to say that I am a Greek Cypriots. But I believe that I have Neutral point of view. Sorry about using words like "occupied", "free" etc. It's easier to explain that way.

Some areas in the island of Cyprus are belong to Republic of Cyprus De jure and also are belong to Northern Cyprus De facto.

There is no problem having articles for the villages and municipalities of Northern Cyprus. We can do the same as any other village or municipality in the planet. They claim that they are a country (even though not recognized), they have their own administrative territorial entity.

For districts we already have separated articles. (Please see Districts of Cyprus and Districts of Northern Cyprus.

There are six districts in Republic of Cyprus. Of them:

The parts of that districts that is in north Cyprus, are consisting Northern Cyprus. Northern Cyprus is divided to 5 districts.

As you can see, these districts do not identify with the "occupied" districts of Cyprus, perhaps with the sole exception of the province of Kyrenia (Girne), without being absolutely sure ... We have a separate articles for each district of Republic of Cyprus and for every district of Northern Cyprus.

At this point, I would like to mention that Republic of Cyprus, although it does not control these areas, continues to have administrations for them. For example, District Administration of Kyrenia. For districts, I have identified only one problem: population. In Girne District we can write the population as recorded by Northern Cyprus. In Kyrenia District we cannot write the population according to Republic of Cyprus because the census cannot apply to "occupied" areas. And we cannot write the population recorded by Northern Cyprus because the two districts are not the same. Especially in other districts there is certainly no match. For example, in Famagusta District, Republic of Cyprus recorded only the "free" areas. For 2011 census that population was 46629. The population of that district (the way Republic of Cyprus defined it) include people that lives it the area of the district under control of Northern Cyprus. But they don’t count them. And we cannot easily counted them because the "relative" Gazimağusa District has not the same area as Famagusta District.

The main problem is about municipalities and communities (villages). Republic of Cyprus elects mayors, municipal councils, community councils for all "occupied" municipalities, has Geographical codes of the Republic of Cyprus for all of these areas, etc. With always the footnote that concern areas belonging to Republic of Cyprus but not are controlled by Republic of Cyprus because of the presence of the Turkish army. Of course, Northern Cyprus also elects mayors, has their own codes etc.

Problems:

  • Kyrenia: Who is the mayor? The Greek Cypriot or the Turkish Cypriot? The article of Kyrenia (and for Famagusta) has both mayor with de jure and de facto in brackets or with Mayor-in-exile.
  • That what Republic of Cyprus define as Keryneia Municipality, the area that the mayor has the has the administrative responsibility, is not identical for Republic of Cyprus and Northern Cyprus. That is, the Greek Cypriot mayor is the mayor of a particular territory, but the Turkish Cypriot mayor is the mayor of a larger or smaller territory. We both call them Kyrenia/Girne! But they are not the same.
  • Keryneia municipality has Statistical Service of Cyprus Geocode 2000. That is how Republic of Cyprus code that areas. But Northern Cyprus have also their own code. Which one must be it the article?
  • area: Keryneia Municipality, as defined by Republic of Cyprus, has different area that Keryneia/Girne Municipality, as defined by Northern Cyprus.
  • Quarters: Keryneia Municipality, according to Republic of Cyprus, is divided (administrative territorial entity) to quarters that are different from quarters that Keryneia/Girne Municipality is divided according to Northern Cyprus.
  • population: Same problems as districts.
  • Status: For example, Trikomo for Republic of Cyprus is a village, for Northern Cyprus is a town/municipality. And it is the capital of a district. Moreover, Dikomo is a municipality in Northern Cyprus, but for Republic of Cyprus are two separated villages, Kato Dikomo and Pano Dikomo etc
  • coat of arms image: Keryneia municipality has different coat of arms that Keryneia/Girne Municipality.
  • Websites: Famagusta Municipality for Greek Cypriot [3] and Famagusta Municipalities from Turkish Cypriots [4]. (English Wikipedia article gives both).
  • Even time is different the half of the year. Northern Cyprus is not using daylight saving time.

And more other problems like:

I am not sure about any solution. The only I have though:

  • Kyrenia: article only about the city. Not informations about municipalities. That way there is no problem, because city history continues regardless of who are living to the city and who are managing. The city has no statutory (legal basis) limits, area, emblem, website, quarters. The municipalities have. The municipalities do not identify with the city, as Limassol is no longer identified with Limassol Municipality. The only problems here are that it is necessary to clarify in which district the city is located (different for Republic of Cyprus and Northern Cyprus). Perhaps there are others problems that I did not think.
  • Keryneia municipality: article about Keryneia municipality from its foundation at 1878 as today. It will be the article for the municipality that continues to exist as an entity but with the administration and the residents outside the municipality (considering that for Republic of Cyprus refugees from Kyrenia and their descendants have electoral rights in that municipality. They are considered voters of the municipality and citizens of the municipality in general, according to Republic of Cyprus).
  • Girne Municipality: an article for the municipality that undertook the administration of the area in 1974 and which in 1983 became the municipality of the newly established Northern Cyprus). It will essentially be the article for the municipality with a year of foundation in 1974.

For communities, we can have two articles for each community. Like:

It that useful? Again, however, it is not certain that each village is terribly identified as Republic of Cyprus and Northern Cyprus mean it, even though they have the same name (translated between to Greek and Turkish).

And the problem is even more complicated for semi-"occupied" municipalities with population in both Republic of Cyprus and Northern Cyprus. An example is Nicosia Municipality (according to Republic of Cyprus). Part of it is in Northern Cyprus. Of course, we have article about North Nicosia.

I have asked the same to wikidata. d:Wikidata:Project chat/Archive/2018/08#Areas of Cyprus Republic (de jure)/Areas of Northern Cyprus (de facto). The solution they propose was to have 2 item for each village (Is easiest in Wikidata :). Like Gangwon Province (historical), Kangwon Province (North Korea), Gangwon Province, South Korea, Hwanghae Province (Republic of Korea), North Hwanghae Province, South Hwanghae Province, Hwanghae Province, Taiwan Province, Taiwan, Fujian Province, Republic of China, Fujian, Lianjiang County, Lianjiang County. I already have applied that. The explanations was that there are two distinct and separate structures in place. A Greek and a Turkish structure with only overlap where the structures indicate physical objects like human settlements are in both and create two artocles for not for the settlements but for all the "administrative and territorial units", they are "per country".

Of course, you may believe that we must not change anything. (Sorry about my Enlgish). Xaris333 (talk) 21:56, 6 September 2018 (UTC)

Year range for two consecutive years

Recently a single user moved 497 figure skating pages that had xxxx–xx year in title to xxxx–xxxx without discussion. I requested they be moved back, but was told I should start a discussion on village pump first.

To focus the discussion, I'm particularly interested in titles of sports articles that have a two consecutive years range in the title. For consistency, I feel all these articles should use the same format, either xxxx–xx or xxxx–xxxx. Currently, from my searches, xxxx–xx is the preferred format. I believe for consistency (and since it's okay with the MOS), the figure skating should be reverted to their original page names. Alternatively, all other pages with this issue (presumably several thousand pages) should be moved to xxxx–xxxx format.
Thus I'm asking everyone what format should be used? Thank you all, 15zulu (talk) 00:01, 9 September 2018 (UTC)

Should sports articles use xxxx–xxxx or xxxx–xx date format for two consecutive years? — Frayæ (Talk/Spjall) 09:36, 9 September 2018 (UTC)

I believe the move to 2015-2016 was justified. Years and year ranges should be spelt out in full to avoid ambiguity. Examples of problems include 2004-05 (could mean May 2004) and 1999-00 (wtf). The solution is to spell these years out in full, and for consistency it should be done always. If thousands of pages are named incorrectly, the sooner we et started with fixing them the better. Dondervogel 2 (talk) 04:59, 10 September 2018 (UTC)
  • Question is too broad WP:DATERANGE is already clear that XXXX-XX is OK: " Two-digit ending years (1881–82, but never 1881–882 or 1881–2) may be used in any of the following cases: (1) two consecutive years; ..." Its applicability for a given sport should be based on the conventions of that sport in reliable sources. Prescribing a specific format for all sports is undue. WikiProject National Basketball Association and WikiProject College Basketball use XXXX-XX.—Bagumba (talk) 05:58, 10 September 2018 (UTC)
@Bagumba: The 500 articles that were unilaterally moved are mainly about figure skating. This RfC is intended to clarify the situation on sports articles title date format before deciding to revert a non-trivial number of moves. The question is deliberately broad for overall consistency. The current guideline which says xxxx-xx "may be used" but that in general xxxx-xxxx is "preferred" is not at all helpful when dealing with such a large number of good faith moves. — Frayæ (Talk/Spjall) 08:23, 10 September 2018 (UTC)
It is a mistake to generalize it about sports. It should be dependent on the convention of the specific domain e.g. ice skating. With all due respect to WP:BB, it seems over-aggressive to change 500 articles in the same domain en masse without first asking about its background and the fact that it maybe "right". If, in fact, they made these changes and already aware of the MOS:DATERANGE exception, it also seems rash to make widespread changes from an accepted format to their self-described "preferred" style without dropping a note at the affected WikiProjects.—Bagumba (talk) 10:33, 10 September 2018 (UTC)
@Bagumba: There does not appear to be a specific guideline for skating articles and I am not aware of any notification or discussion that occured beforehand. At the same time, 500 moves is a lot to undo without a good reason. What do you suggest is done moving forward? — Frayæ (Talk/Spjall) 10:45, 10 September 2018 (UTC)
I think this is a figure skating issue, and not a general or sports issue. The orginal mass move failed WP:RMUM: It seems unlikely that anyone would reasonably disagree with the move. There was not a problem per WP:DATERANGE, which allows XXXX–XX, and it's debatable if this is an improvement when 500 some-odd figure skating articles were already consistently named. The onus is on the orginal mover to gain consensus for the new XXXX–XXXX title. This could have been done at WP:RM, but the RfC is already open, so let's go from here.—Bagumba (talk) 10:29, 11 September 2018 (UTC)
The previous RFC was regarding all year ranges xxxx–xx, so this question about sports is significantly less broad. As of right now, figure skating has no guidelines in place on Wikipedia and a single user unilaterally decided to move approximately 500 pages from xxxx–xx to xxxx–xxxx. Going by my original research, isu.org primarily uses xxxx/xx format while news sources use xxxx-xx format. The figure skating WikiProject is mostly defunct and it's likely most people editing figure skating pages will not see any question posed there. Regardless, while specific sports can have their own format, I feel that we should have generic/default Wikipedia guidelines too. 15zulu (talk) 08:08, 11 September 2018 (UTC)
FWIW, I went and left a notification of this RfC at Wikipedia_talk:WikiProject_Figure_Skating.—Bagumba (talk) 10:10, 11 September 2018 (UTC)

I noticed that not all events that span two years have the second year in their articles. 2008 NFL season is one such example. At what point do we include the second year in the title?

I'm under the impression that it's included if a significant portion of the event takes place in the second year. In other words, an event that starts in October and ends in January would probably do with just the first year. Would I be correct? --Ixfd64 (talk) 18:42, 11 September 2018 (UTC)

The conventions at Wikipedia obey the conventions outside of Wikipedia. The NFL, by convention, only calls its seasons by one year, even though the playoffs extend into the next year. Wikipedia did not invent or create this convention in the naming of its articles, it merely followed the existing convention. That's how we do everything here. We don't make up things, and then create our own reasons why we made them up, we obey what reliable sources do. --Jayron32 18:51, 11 September 2018 (UTC)
Thanks for the explanation. However, what about other events that don't have an official naming convention?
For example, suppose there is a large series of protests in Washington D.C. that lasts from October 2020 to April 2021. Would the article be titled "2020-2021 Washington D.C. protests" or just "2020 Washington D.C. protests"? --Ixfd64 (talk) 18:57, 11 September 2018 (UTC)
I have no idea. It would depend on what reliable sources were already calling the events. Show me what they are called when sources outside of Wikipedia write about them. --Jayron32 19:03, 11 September 2018 (UTC)
A descriptive title like that may be constructed owing to the absence of a single recognizable name for the series of events, or a recognizable name which is unsuitable for Wikipedia due to NPOV or BLP issues. In such cases I'd follow MOS and use 2020–21 Washington D.C. protests (don't forget the en dash!). – Reidgreg (talk) 17:35, 12 September 2018 (UTC)
  • Use whatever form the RS use – as discussed above. For the figure skating example, the ISU seems to use XXXX/XX (their web site is a mess but that's what the cited ISU sources use for example at 2015–2016 Grand Prix of Figure Skating Final). I'm not crazy about the slash but that's what they use. Kendall-K1 (talk) 00:29, 12 September 2018 (UTC)
    As I mentioned above, while ISU primarily uses xxxx/xx format, news sources for figure skating (including general news sources & figure skating specific sources) use xxxx-xx format. Also other figure skating organizations, like USFSA and Skate Canada, use dash. While one primary source uses slash, the majority of reliable secondary sources use dash. 15zulu (talk) 04:08, 12 September 2018 (UTC)
    We do not use slashes to indicate date ranges per DATERANGE. No comment on the actual concerns in this RFC, but that's a solid "we do not use slashes, ever". --Izno (talk) 16:24, 12 September 2018 (UTC)
    A slash may be used in place of an en dash for adjacent years when supported by a majority of sources, per MOS:SLASH and MOS:DATERANGE (special periods), but the former also generally discourages slashes which are one of those troublesome characters than can be interpreted as markup (along with ampersands, numeros, etc). If sources use a mix of styles, better to stay consistent with Wikipedia's broadly accepted style of xxxx–xx. – Reidgreg (talk) 17:35, 12 September 2018 (UTC)
  • Support xxxx–xx (with en dash, not a hyphen as in many of the above examples) as spelled out in MOS:DATERANGE. While 2004-05 is confusing and might be May 2004, the dash in 2004–05 indicates this is a range MOS:ENTO. The xxxx–xx format is particularly good for periods of less than a year which overlap calendar years, like fiscal year 2004–05, the winter (northern hemisphere) of 2004–05, and sports and television seasons. If it describes a period of 366 days or more, though, or if there are any clarity issues, I'd tend to use xxxx–xxxx. MOS is a guideline, and exceptions can be made if the context leads to confusion. I'm just not seeing why there would be any confusion here, or any reason to vary from the established style guideline. Adhering to the style guideline gives Wikipedia a consistent and professional look, and is meant to help avoid silly style warring. – Reidgreg (talk) 17:35, 12 September 2018 (UTC)
    • Agree. Normal English-language usage should prevail absent a much stronger rationale than has been suggested. 121a0012 (talk) 03:36, 16 September 2018 (UTC)
  • Support xxxx–xxxx - The range of xxxx–xxxx should be used, as the goal of any written text is to be as clear as possible and that presents the most clear title. The distinction the previous editor said about periods of more than 366 days would be lost on most editors; I've been editing here for years and I've never known that might be a reason for such usage. A previous example of 1999-00 is also a clear example where this just fails and looks bad. There is no title space shortage issues (titles aren't long and this isn't print), other date ranges (in non-consecutive years) use this style and per WP:CONSISTENCY would also work better and this would also eliminate the may be used [...] issue which just leads to endless page-by-page fighting over meaningless issues. --Gonnym (talk) 11:46, 13 September 2018 (UTC)
    Well put. Dondervogel 2 (talk) 12:02, 13 September 2018 (UTC)

Creation of article on Maria Elvira Salazar

I am stumped about something and am hoping someone can help me out. We have an article on a woman named Maria Elvira Salazar that was apparently created on 25 April 2017 with this edit but a user named Lcast043. What I don't get is how this editor was able to create the article: the creation of this article was and remains his/ her only WP edit to date, but it doesn't look like the article went through AfC or any other review process. The editor certainly didn't have 10 edits and 4 days of editing history— shouldn't that have made it impossible for him/ her to create a new article like this? I am missing something, but I don't understand what. If anyone has any ideas, please let me know. Will check back here regularly for responses. Thanks! A loose noose (talk) 00:42, 9 September 2018 (UTC)

Prior to 2018, editors could create articles without being autoconfirmed. They can still do so as drafts, and then the articles can be moved to mainspace by other editors. power~enwiki (π, ν) 00:53, 9 September 2018 (UTC)
Hello, A loose noose. Please see Wikipedia:Autoconfirmed article creation trial, commonly abbreviated ACTRIAL. This restriction on direct article creation by brand new editors went into effect on a trial basis in September, 2017. It is now permanent. Cullen328 Let's discuss it 01:03, 9 September 2018 (UTC)

Proposal to draftify UDP-tagged articles

No consensus as to any definite plan.Please try the idea of a sticky-prod in a new RFC.Thankfully,WBGconverse 06:37, 10 September 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Currently we have just 780 articles tagged with template:Undisclosed paid (UDP), a particular aspect of more general template:COI. I think mere tagging for suspected UDP editing is toothless - the potential paid editor gets the job done anyway and the article becomes indexed by search engines, hanging around indefinitely until someone cleans it. Moving all UDP-tagged articles to the non-indexed draft space and keeping them there untill they're fixed and ready to return to the mainspace could be a good solution. Also in this option, any new UDP-tagged article might be draftified by any registered user. If adopted, the proposal might entail corresponding addendums in relevant pages. Thoughts (support, oppose, comments)? Brandmeistertalk 13:40, 14 July 2018 (UTC)

  • Support I like this idea, as it would remove those problematic articles to a more appropriate space where they can be dealt with properly, subject to the AfC criteria. — AfroThundr (u · t · c) 19:27, 14 July 2018 (UTC)
  • Support This would reduce the automatic "BOGO" that many paid editors count on. John from Idegon (talk) 19:36, 14 July 2018 (UTC)
  • Support Although it would be interesting to know if the relevant templates could also apply noindex as an alternative. —PaleoNeonate – 19:51, 14 July 2018 (UTC)
    • Mainspace pages aren't noindexable. —Cryptic 01:14, 15 July 2018 (UTC)
      • Unless someone changed something again when I wasn't looking, Cryptic, new pages are default NOINDEX, until passed by NPP or 90 days old. Oh, wait....I read that wrong. So, yeah. I like the idea of the UDP template adding the NOINDEX back in addition to draftified. Anything that pushes UPE editors into outing themselves is a good thing in my book. John from Idegon (talk) 02:02, 15 July 2018 (UTC)
        • My point is that either this requires a software change, or that all paid pages are found and fully dealt with before the 90-day cutoff before indexability stops being configurable. Neither of those are realistic in the least. —Cryptic 03:17, 15 July 2018 (UTC)
          • I don't understand the software, nor do I care to. So I'll take your word for it. However, that does not affect the original proposal, ya? John from Idegon (talk) 03:36, 15 July 2018 (UTC)
          • The UPE template already applies NOINDEX and the page will stay NOINDEXed even if patrolled for 90 days after creation. MER-C 13:15, 19 July 2018 (UTC)
            • Good tidbit I was not aware of. But there's also the possibility to alleviate the mainspace and cut off potential traffic to such articles - several dozens UPE articles are already in drafts. Brandmeistertalk 18:59, 20 July 2018 (UTC)
  • Support Are supposed to go through AfC anyway. One thing to consider is the "undisclosed paid articles" that make it through AfC, should we deal with these differently? Doc James (talk · contribs · email) 20:41, 14 July 2018 (UTC)
    • My understanding is that those that have passed AfC do not require cleanup requested in the UDP template, at least in the reviewed AfC version. If UDP is still suspected, they could be sent back to drafts. Brandmeistertalk 21:10, 14 July 2018 (UTC)
      • IMO, and I'm not alone, AfC is kinda like economics. We all know ideally that's how it should work, but in actuality, it doesn't always. John from Idegon (talk) 02:07, 15 July 2018 (UTC)
  • Support This sounds like a good idea, as the authorship violates the site's terms of service. However, would not the lag between creation and detection allow for search engine indexing in some % of cases? Also, could someone point me at a description (or put it here if brief) of how one determines that the content has been paid for, particularly if undisclosed? Thanks. --User:Ceyockey (talk to me) 00:32, 15 July 2018 (UTC)
  • Conditional Support - I'd like a second pair of eyes on each of the articles before they are moved to draftspace. I'm leery about doing this automatically where it allows any editor to unilaterally move any page to draft. Tazerdadog (talk) 01:42, 15 July 2018 (UTC)
    Sticky Prod, as suggested below, is a better solution which I fully support. Tazerdadog (talk) 21:26, 16 July 2018 (UTC)
  • While I support the general idea, I'm not sure moving pages into draftspace where they will disappear from the eyes of other editors is the best way. Natureium (talk) 01:47, 15 July 2018 (UTC)
  • Oppose as written. We should not automatically userfy pages just because someone slapped a template:Undisclosed paid on it. Really, if no one is planning on improving these articles, sending them to draft space is just a delayed WP:CSD G13 death sentence. If we want to delete these articles, we should use the existing CSD or AFD processes, and only send them to draft space if there is a editor without a COI issue who plans to improve the article in the 6 month window. If they haven't already been nominated for deletion under existing policy, and instead are stuck with the Undisclosed paid tag, its because they still add value to the encyclopedia, not withstanding the issue with their primary contributor. Monty845 04:39, 15 July 2018 (UTC)
  • I'd prefer a sticky PROD that couldn't be removed by the creator. TonyBallioni (talk) 04:46, 15 July 2018 (UTC)
  • #1 choice sticky PROD. This deals with the article quickly and keeps it visible for those who may be interested in fixing it. The stickiness should require the remover to place {{oldprodfull}} with con= and conreason= filled out ie disallow 'I just don't like prod's prod removal'. Personally I would like to see that requirement for all PRODs but I know a loosing battle when I see one :) #2 choice support proposal for moving them to draft but it seems to be the less accountable and reviewable of the two. Regardless, if this is to become a regular thing, a tracking category should be added when either is done to facilitate review. Jbh Talk 11:07, 15 July 2018 (UTC)
  • Oppose. As it's currently set up, the draft namespace is only for short-term collaboration on future articles, so unless there are editors who have expressly volunteered to work on an article, and there's agreement that this article is not ready for mainspace, then it shouldn't be draftified. In practical terms, sending an article to draft will be useless if the COI editor is still around, as they're likely to be motivated enough to move it back; and if there are no editors (with a COI or without) watching it, then the move is most likely to result in the silent "expiry" of the draft after six months – this is deletion by the backdoor and should not be encouraged. Additionally, the fact that a given article has been edited by someone suspected of UDP is not a single problem that has a single solution, it's simply an indication of a more basic problem. Fundamentally, this might be an issue of either notability – in which case deletion via the proper channels is the way to proceed, or of neutrality and sourcing – in which case it's better to rewrite the article or simply to remove any suspicious parts, even if this means paring it down to a one-sentence stub. – Uanfala (talk) 13:47, 15 July 2018 (UTC)
    I understand these concerns about "deletion by the backdoor" even if I supported. A good approach if this passes and there is enough will to make it happen, would be to make a temporary trial (i.e. I remember of WP:ACTRIAL), then evaluate with stats if it helped. It may help in some ways: (quickly unindex pages vs deletion processes, permit more time to work on them, for instance) which is why I think it's worth trying. If it results in draft space becoming unwieldy other procedures may need changes... —PaleoNeonate – 16:02, 18 July 2018 (UTC)
  • Support if not fully automatic, per concern raised by Tazerdadog and Monty845. It needs human review, because not every tagging will have been valid, and some valid ones will already have been resolved without removing the tag.  — SMcCandlish ¢ 😼  17:00, 15 July 2018 (UTC)
  • Conditional support - I'm with SMcCandlish here, although I'd prefer mass draftify over leaving them alone. DaßWölf 00:19, 16 July 2018 (UTC)
  • Support. Regulars to the Wikipedia:Conflict of interest/Noticeboard or NPP would observe that this is already starting to become practice when dealing with promotional articles. I prefer sticky prod over draftifying -- spammers sometimes continue to work on the draft and move it into mainspace (either with the original account, socks, meatpuppets or a different spamming company altogether). Paid-for spam in many cases can't be fixed, because the subject may be non-notable and the article's very existence is promotional. Sticky prod satisfies the desire above to have review of any pages affected by this proposal. MER-C 12:15, 16 July 2018 (UTC)
    • Prodding could be a good alternative. To severe oxygen supply for paid efforts and convey WP:GAME message this might entail mass prodding of all such tagged articles and possibly prescribing in policy that articles tagged for UDP might or should be prodded. Brandmeistertalk 19:00, 16 July 2018 (UTC)
      • Only if the spammer and any non-autoconfirmed user (covert advertising frequently involves large sockfarms) are prohibited from removing the deletion messages. MER-C 20:39, 16 July 2018 (UTC)
  • Support, noting similarity to my Wikipedia:Quarantine promotional Undeclared Paid Editor product proposal.
The sticky PROD idea looks just as good. How long until the UPE-PROD results in deletion? In the case of the sticky UPE-PROD idea, who is the non-UPE false positive editor supposed to respond? If they make a response, surely it must demand reading before deletion? Who would read it, how would they be drawn to the response?
I think quarantining outside mainspace has the advantage to retaining UPE edit histories that may be helpful to non-admins in detecting patterns. I continue to submit that there are probably far few UPE people than UPE accounts, and that an awful lot of UPE product is the result of a few Wikipedians among us. The deletion of identified UPE product helps prevent detection of the puppet master. --SmokeyJoe (talk) 04:01, 18 July 2018 (UTC)
  • Support Too often articles that are plain articles are kept "because normal editing van fix that". In fact, the editors claiming that never alter a letter in such articles. Do you remove the spam, you get flak. And if you don not get flak, the spammer put everything back in. The COI-noticeboard also seems ineffective in dealing with that. So this is a good alternative. The Banner talk 13:18, 18 July 2018 (UTC)
  • Support - Way to easy to just let them be. Lee Vilenski (talkcontribs) 13:41, 18 July 2018 (UTC)
  • Support sticky prod proposal as that is far more visible, open and accountable with deletion by an admin if necessary. Any editor being allowed to move articles to draft is wideopen to abuse either in error or deliberate in cases of edit wars, vandalism, incompetence and even UPEditors paid for deleting rival companies pages etc, also drafted articles are easily forgotten and mistagged articles would be unfairly deleted as G13s are mainly deleted on mass with little oversight. Also, this should not be retrospective as it would cause a huge backlog of prods to deal with, thanks Atlantic306 (talk) 20:11, 25 July 2018 (UTC)
  • Oppose It's not safe enough--it's too easy to apply the tag incorrectly. It is sometimes very difficult to judge if it is actually paid editing , and even those of us who have been working on it for years inevitably make errors. . As for s sticky prod-like procedure,I assume we are talking about a proceed to move to draft, not to delete. it's worth considering, but I'm reluctant to add another procedure to an already complicated process that already engenders multiple disputes about how to proceed. DGG ( talk ) 16:08, 31 July 2018 (UTC)
  • Oppose per DGG and because if the text is suspicious then it's better to delete and start from scratch. Otherwise we look like we're restricting unrelated users from their normal editing process and forcing or encouraging them to edit the text outside main namespace. --Nemo 12:51, 6 August 2018 (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.

RfC on text highlighting in signatures

Just a heads up to page watchers that I've started an RfC on whether to disallow text highlighting in signatures at Wikipedia talk:Signatures#RfC: Should we disallow text highlighting in signatures?. Comments welcome there. — Rhododendrites talk \\ 18:57, 12 September 2018 (UTC)

FOOTYN (again)

The Wikiproject Football notability essay, WP:WikiProject_Football/Notability (commonly linked as WP:FOOTYN), is still being used as an argument of notability/lack of notability in deletion discussions. I attempted to forestall this by adding a link and note at the club section pointing to WP:NTEAM (the actual SNG related to teams) and advising not to use the essay as an argument for inherent notability in deletion discussions. I have twice been reverted by Number 57([5][6]) for adding a supplemental hatnote to the club notability section at WP:WikiProject_Football/Notability.

I have opened a section at Wikipedia_talk:WikiProject_Football/Notability#Hatnote_for_club_section_linking_to_the_actual_SNG_section_on_team_notability to discuss this addition, but wanted to post here to draw wider community input. Please comment at the talk page of the relevant page rather than here. Cheers, — Insertcleverphrasehere (or here) 23:20, 13 September 2018 (UTC)

RFC: Capitalization of Senator

At Talk:Dan_Sullivan_(American_senator)#Requested_move_8_September_2018 it is pointed out that Senator and Senators are often capitalized when they should not be per MOS:JOBTITLES; e.g. should be List of U.S. senators from X, but U.S. Senate and Senator Smith. Do we have consensus to fix this widespread error with the help of scripts, bots, or other tools? -- Dicklyon (talk) 02:05, 14 September 2018 (UTC)

Political titles are often improperly capitalized. I don't think we need consensus to fix those errors. -- Ajraddatz (talk) 16:24, 14 September 2018 (UTC)
Agreed with the above from Ajraddatz. --Bsherr (talk) 22:40, 14 September 2018 (UTC)
We do need consensus. I think you both mean we already have it via clear guidelines, so we don't need this RFC. I tend to agree, but when asking for bot help one needs to be sure. Dicklyon (talk) 03:27, 15 September 2018 (UTC)

More specifically, are there any objections to this bot request I just submitted: Wikipedia:Bot_requests#Bot to fix capitalization of "Senator" in specific contexts? I realize this won't fix everything; maybe we can find more patterns that are safe to do automatically. Dicklyon (talk) 03:48, 15 September 2018 (UTC)

The problem with bots is that they are notoriously bad at determining context. This seems like something that should be done manually. Blueboar (talk) 11:24, 15 September 2018 (UTC)
As the linked bot proposal shows, this would involve only specific narrow contexts that a bot can easily get right; 250 moves (5 per state) and links to them. Dicklyon (talk) 16:17, 15 September 2018 (UTC)
I've made multiple objections on that page. Most are technical in nature and don't need to be repeated here. However, I'm not convinced that changing "United States Senator" to "United States senator" is correct. I agree that "American senator" or "Colorado senator" is the correct capitalization, as the word senator is merely a descriptor and not a title in that phrasing. While it's not quite the same, the capitalization of United States Attorney does not appear to be in dispute. power~enwiki (π, ν) 03:50, 16 September 2018 (UTC)
I'm hoping you'll follow up there to explain; I don't understand your objections. Dicklyon (talk) 00:27, 19 September 2018 (UTC)

On a related note, I have filed a CFD discussion regarding Category:Alabama State Senators; Wikipedia:Categories for discussion/Log/2018 September 17 is the log-page. power~enwiki (π, ν) 02:39, 17 September 2018 (UTC)

I support that one. But don't understand your objections to my proposal. Looking forward to clarification on the bot page, as that's where more of the details are. Dicklyon (talk) 03:28, 17 September 2018 (UTC)

Editing restriction logging discussion

There is a discussion at Wikipedia talk:Editing restrictions regarding the logging of restrictions imposed as an unblocking condition, as well as formal logging of editor warnings. Administrators and editors are invited to participate in the discusson. Thanks. Ivanvector (Talk/Edits) 16:40, 14 September 2018 (UTC)

Request for an update of size calculations for splitting an article

The "rule of thumb" listed in Wikipedia:Article size for splitting an article has not changed since 2008 (at least). Is it possible to update these values? because I feel that some good articles (therefore long) are unnecessarily split by following this rule, thus reducing Wikipedia's readability. Nowadays, articles are significantly lengthened by the increased use of citations (many articles have hundreds of citations, often with external links). Browsers have made significant progress in ten years and can display such large pages; I think it is time for a change. Values in the scale should be at least doubled imo. Another way to improve this rule would be to exclude citations/references from the calculation. T8612 19:06, 17 September 2018 (UTC)

The size guidelines are for readable prose size, so citations/references are indeed excluded. Galobtter (pingó mió) 19:10, 17 September 2018 (UTC)
  • (edit conflict) Generally speaking, I'd say we can probably just toss out the article size suggestions that are based in the page's database size. Text is easy to load, it's all our fancy images that lag slow connections, and there's CSS and scripts and stuff that lag fast connections on slow computers too. On the other hand the guideline does deal largely with readable prose, and that's not a matter of technical limitation. Maybe we should update the WP:SIZERULE portion to be in terms of word count, rather than kilobytes. Ivanvector (Talk/Edits) 19:12, 17 September 2018 (UTC)
If the issue behind this guideline is loading time, why not placing the limitation on this, instead of text length?T8612 19:45, 17 September 2018 (UTC)
  • Yup, those figures are way too large and need to be shrunk. I'd recommend 30KiB as an upper limit. Jdforrester (WMF) (talk) 19:20, 17 September 2018 (UTC)
  • As noted to does not include citations notes etc, only readable prose size. Also, 'make it shorter' just sounds like good writing advice. So, not in favor (perhaps, if you proposed, 'make it shorter? :)). Alanscottwalker (talk) 19:30, 17 September 2018 (UTC)
  • The real problem is that they are not being enforced. Every time I point out an article is over 100kb rps ("Almost certainly should be divided") the response is that it's such an important and big topic... People simply ignore Wikipedia:Summary style, although that's one of our most important writing guidelines. – Finnusertop (talkcontribs) 02:13, 20 September 2018 (UTC)

Technical

How to permanently and globally disable mobile wikitext editor without disabling mobile wiki skin.

Reposting from helpdesk according to suggestion

I have repeatedly encountered the problem and tried to searched and asked for solution but still can't find anything that can help me.

On mobile devices, due to the limited amount of memory, it's easy for browser tabs to be clear out of memory when user opened too much other tabs to look for information when from other sites.

Normally, when browser reload those tabs when user switch into the tab after the tab being cleared out if the memory, it would still be possible for original text in editor field to be loaded back.

However, since that wikitext mobile editor was dynamically pulled in the page, this browser text field recovery process could not work, and thus hours and hours of edits that would have been made via mobile browsers have all go into vain thanks to that completely counterproductive design.

How to permanently disable that?

C933103 (talk) 03:08, 6 September 2018 (UTC)

C933103, which of the multiple mobile-editing systems is being used here? Whatamidoing (WMF) (talk) 17:59, 7 September 2018 (UTC)
@Whatamidoing (WMF): The one with "#/editor/0" appear in URL when used. C933103 (talk) 18:02, 7 September 2018 (UTC)
C933103, I asked a couple of tech folks about this, and I have sort of bad news and maybe-okay news. There doesn't seem to be a way to change the browser behavior. The default at "#/editor/0" is the Javascript-based mobile wikitext editor, and there's no way to stop the browser from clearing out the memory, nor is there any autosave. (The original text in the editing window is only auto-reloaded by some browsers, some times, usually on desktop.) However – and this is the maybe-okay news – if you can switch to the mobile visual editor, then you'll get a built-in autosave feature which would usually save your work in such cases (although it's not guaranteed). Whatamidoing (WMF) (talk) 15:07, 12 September 2018 (UTC)
@Whatamidoing (WMF): So that mean I can switch the editor, but I can only switch it to the mobile visual one instead of the traditional desktop one? If editor switching is already possible, can I request the feature pf switching it to the traditional mobile one? 221.127.109.116 (talk) 16:16, 12 September 2018 (UTC)
If the URL says "#/editor/0" at the end, then you aren't using "the traditional desktop one" (of which there are about four, depending upon how you count them, plus multiple other "non-traditional" mw:editors). If you are on the mobile website, regardless of device, then you have only three options for editing:
  1. The "traditional" (but not the "original") mobile wikitext editor (You are using this if Javascript is enabled in your browser, and you see wikitext.)
  2. An empty HTML <textarea> box, aka the 2003 wikitext editor (Javascript is disabled. You will see wikitext but no toolbar or buttons.)
  3. The visual editor (This is the only option that doesn't show wikitext codes. It is also the only option that has a built-in auto-save feature.)
You can already switch between all of the three available options. Unfortunately, what nobody can do right now is:
  • make any of the visual editor's built-in features (its citation filling tool, its auto-save feature, etc.) appear in any of the other editing environments (and vice versa), or
  • make the web browser on your phone auto-save lost work in the same way that the web browser on your laptop auto-saves lost work. Note this key detail: If you accidentally close a tab in Chrome or Firefox on your Windows laptop, and your changes are restored when you re-open the tab, that recovery is being done directly by Chrome or Firefox on your laptop – not by anything Wikipedia controls. So far, it appears that the makers of mobile web browsers have not chosen to provide a similar feature on mobile browsers. You'd have to contact the makers of UC Browser, Opera, Firefox, etc., and ask them to build that (and then it would work for all websites).
Whatamidoing (WMF) (talk) 18:33, 12 September 2018 (UTC)
@Whatamidoing (WMF): I mean, do you know how can I switch from using "#/editor/0" by default, into using "?action=edit&section=0" by default? Or alternatively, how can I change to use the "2003 wikitext editor" you described while still staying in the mobile skin when reading? I can't find where can I make such a switch option. C933103 (talk) 21:32, 12 September 2018 (UTC)
C933103, sorry for the late reply. I don't think that you can switch the URL. You get the 2003 WTE by turning off Javascript in your web browser, but (a) you might not like the results, since lots of pages will look worse and most tools will disappear, and (b) I don't think it would solve your actual problem.
Your actual problem is that your web browser is running out of memory and, as a result, actively throwing away your unsaved changes. Since the problem is "browser out of memory, throwing away all the changes", then it seems to me that it is unlikely that you will, even in the 2003 WTE, get "browser out of memory, throwing away all the changes – also, saving those changes in memory, just case he re-opens this tab". The reason that a desktop web browser (sometimes) saves your changes when you accidentally close a tab is because your desktop browser is not running out of memory, so it has a place to save those. If your mobile web browser had memory to save it, it wouldn't have thrown it away in the first place. But it has no memory to spare, so it throws away your changes permanently, with no hope of recovery.
I don't think that there is any change you can make on Wikipedia that will stop your web browser from actively throwing away your changes on Wikipedia when it runs out of memory. If you need Wikipedia to save your changes, so that they can (usually) be recovered when your web browser throws them away (or crashes), then that feature is only available in VisualEditor. If you want your web browser to save your changes (or just to stop removing them), then you need to upgrade your mobile device, to something with a lot more memory. In the meantime, it might be a good idea to "Save Early, Save Often". Whatamidoing (WMF) (talk) 17:25, 18 September 2018 (UTC)
@Whatamidoing (WMF): Except I do get my text back if I use the desktop editor and then page get purged due to lack of memory. The reaso is that mobile browser also have something like cache memory that's stored within devices' storage instead of RAM. So, the no-js editor is actually helpful too, but I don't want to disable js for my entire browser just tp use this particular old edit tool. How can I get that no-js editor via setting? Or should I request the implementation of such feature that would allow user to manually switch between different editors?C933103 (talk) 18:56, 18 September 2018 (UTC)
Have you tried switching to that editing environment in Special:Preferences, and seeing whether that carries over to the mobile editing environment? mw:Editor probably has the necessary details, but you need to turn off the 2017WTE in Beta Features, turn off the 2010 ("enhanced") toolbar, **and** turn off the 2006 toolbar. Each newer system secretly overrides all older ones. (What a confusing mess. We need to fix this, so you can just pick the one you want, all on the same page.)
If that doesn't work, then you might have to disable Javascript in your mobile web browser. (It should be sufficient to do that just for the en.m.wikipedia.org domain, if there's some sort of add-on.) Also, before you do that, please look at phab:T192018. It appears that you won't be able to edit the introduction of any article on the mobile site with Javascript disabled. Whatamidoing (WMF) (talk) 17:36, 19 September 2018 (UTC)
@Whatamidoing (WMF): I have tried turning off both the 2007/2010/2006 editors but they only affect the desktop editing environment and the mobile editing environment is still the 2013 one without changes. And I don't want to turn off javascript for the entire browser just for a single site and Chrome Android browser support turning off js for individual site nor support plugin (Strangely it support turning on js just for a few site while blocking all other sites from using js). And no, it seems like I can edit lead section using the js-less editor. C933103 (talk) 02:41, 20 September 2018 (UTC)

AWB

Is there any difference in operating WP:AWB and WP:PyAWB.--PATH SLOPU (Talk) 16:23, 11 September 2018 (UTC)

@Reedy: this is one for you. Headbomb {t · c · p · b} 14:56, 12 September 2018 (UTC)
I doubt PyAWB even works, it's not been touched for 9 years. [7] Reedy (talk) 22:04, 12 September 2018 (UTC)
@Reedy:Can I use PyAWB instead of AWB. Please help.--PATH SLOPU (Talk) 01:35, 14 September 2018 (UTC)
Try it, if it works, it works. If it doesn't, it doesn't. However, see the response above: this is pretty much outdated abandonware, and will most likely fail epically in several places, and make edits that no longer have consensus, or which are no longer valid. Headbomb {t · c · p · b} 01:41, 14 September 2018 (UTC)
@Headbomb:Thank you for your advice. Sir, I queried about this because I would like to use AWB for my bot. But I am using linux. I tried to install wine with software centre and get-apt. But I couldn't install it because of some technical problems. Is there any alternate way for that. Sir, please help.PATH SLOPU (Talk) 15:53, 14 September 2018 (UTC)
@Path slopu: Just so you know, you don't need to call people 'sir' or 'madam' or whatever every time you post somewhere. We're all equals here. Just call people by their username and talk to them normally. As for what to do with Wine or PyAWB, I suspect the best place to get advice would be at WT:AWB. Headbomb {t · c · p · b} 16:58, 14 September 2018 (UTC)
@Path slopu: You could try building your bot with Pywikibot instead. --Ahecht (TALK
PAGE
) 17:07, 14 September 2018 (UTC)
Ahecht - FYI Wikipedia:Bots/Requests for approval/Pathbot — fr+ 05:50, 15 September 2018 (UTC)
@Headbomb, Ahecht, and FR30799386:I placed my doubt in WT:AWB. I used pywikibot in earlier time. But I understood that AWB is more better than python for doing my bot's task to avoid mistakes. So I tried for AWB.PATH SLOPU (Talk) 09:12, 15 September 2018 (UTC)
@Headbomb, Ahecht, and FR30799386:Hi greetings, I added a request for using JWB for my bot in WP:PERM/AWB. Is it correct? Am I place the request in correct page? Kindly please help.--PATH SLOPU (Talk) 12:11, 15 September 2018 (UTC)

I accidentally removed half my watchlist

Well, yeah, I tried to edit my raw watchlist to trim it a bit but I didn't notice only half of it was loaded. So when I clicked save, 3,000 pages were gone. Is there any way to restore them (aside from remembering the pages and manually readding them)? Regards SoWhy 10:56, 13 September 2018 (UTC)

Unfortunately, that's not possible AFAIK. Only Developers can retrieve that kind of data. –Ammarpad (talk) 18:20, 13 September 2018 (UTC)
Ammarpad, actually they can't either. Well, in theory some system administrators probably can, by opening the vault with the backups, but I don't think that has ever been done for something as small an issue like this. —TheDJ (talkcontribs) 21:17, 13 September 2018 (UTC)
@Ammarpad and TheDJ: Thanks for the replies. I'll trout Self-trout then and take it as a sign to slim down my Watchlist. Regards SoWhy 06:06, 14 September 2018 (UTC)

Template:Pie chart appearance

See the discussion here. Thank you. --Hddty. (talk) 06:31, 14 September 2018 (UTC)

Wrong code in infoboxes for languages

Someone in WP:RD/L has reported that the infoboxes on the pages Dutch language, English language, German language, and Korean language all currently show the ISO 639-1 code for the respective languages as "hh". Since the "iso1" codes shown on each page are correct, this has to be a bug in whatever it is that "{{Infobox language}}" invokes. Someone who understands this, please fix. --76.69.47.228 (talk) 09:17, 14 September 2018 (UTC)

I just reverted this IP edit to {{ISO639-1}}. It has 224 transclusions which isn't a great deal but perhaps an admin would like to add some protection. Johnuniq (talk) 09:27, 14 September 2018 (UTC)
Thanks, John! --76.69.47.228 (talk) 20:19, 14 September 2018 (UTC)
Airplaneman has protected the redirect against IP. Graeme Bartlett (talk) 00:17, 17 September 2018 (UTC)

Thumbnail too dark?

Picture of Bell Labs Model V, circa 1947
Picture of Bell Labs Model V, circa 1947

We've got an image, File:Bell Relay Computer.png. It looks reasonably well exposed, if somewhat low contrast. I can see detail in the technician's white shirt, and even a little in his black shoes.

In Model V, we use that as a thumbnail. Here, the image looks highly underexposed. The technician is barely visible in the shadows. Is this loss of dynamic range an inevitable result of the size reduction? Is there anything that can be done to improve this? I can certainly download the image to my box, adjust things there, and upload a new copy, but I'm thinking more of something I can do within the wikimedia system. And something that will work across all image sizes. -- RoySmith (talk) 13:37, 14 September 2018 (UTC)

Top image is 240px, bottom is 241px. I think this is phab:T68337. Galobtter (pingó mió) 14:00, 14 September 2018 (UTC)
Actually phab:T106516 seems to be it. Galobtter (pingó mió) 14:17, 14 September 2018 (UTC)
It's really inexcusable that this bug has gone on for over three years without a fix. --Ahecht (TALK
PAGE
) 15:06, 14 September 2018 (UTC)
If you think that's bad; the company I last worked for left their private servers wide open to the internet for four years. ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 19:08, 14 September 2018 (UTC)

Regex editor trespassing

How do I get rid of this and put OhConfucius' Engvar B back please? Keith-264 (talk) 16:08, 14 September 2018 (UTC)

@Ohconfucius: somewhat recently updated User:Ohconfucius/script/EngvarB.js and may be able to help here. — xaosflux Talk 17:21, 14 September 2018 (UTC)
Thanks I've left a message. Keith-264 (talk) 17:59, 14 September 2018 (UTC)
I don't understand why this is happening, nor can I offer an explanation at this point. However, I did manage to get the script buttons by importing my monobook script. Perhaps you can try doing that instead of importing the EngvarB script? Please note that you will get maybe five sets of Engvar script buttons. Not ideal, I know, but at least they appear. Face-wink.svg -- Ohc ¡digame! 07:55, 15 September 2018 (UTC)

Captcha?

Both my original posting and this simple edit in this thread required a captcha. Is that intended? I wasn't posting any external links, for example. (And I see that this new posting, too, is requiring one.)

(Please reply here, not to this IP address's talk page.) --76.69.47.228 (talk) 20:22, 14 September 2018 (UTC)

G with a macron below

Hi, why doesn't the "Special characters" table (or the Latin extended set) in the editor have an underlined G? The {{underline}} template does produce something similar in G, but that is accomplished using CSS. Any alternatives? Thanks.—Cpt.a.haddock (talk) (please ping when replying) 21:02, 14 September 2018 (UTC)

Unicode doesn't have a precomposed character of G with a macron below. So you would have to use the combining diacritic U+0331 ◌̱ , as in "G̱". Nardog (talk) 21:14, 14 September 2018 (UTC)
Thank you.—Cpt.a.haddock (talk) (please ping when replying) 21:26, 14 September 2018 (UTC)
More at Macron below#Precomposed characters. --Redrose64 🌹 (talk) 20:00, 15 September 2018 (UTC)

Using the Search box and limit results to not include redirects

I'm trying to do a search using "intitle:", but I wish to only get actual article titles and not redirects. I tried searching for information at Help:Searching, but couldn't find any. Hope someone here can help me out. Thanks. --Gonnym (talk) 21:09, 14 September 2018 (UTC)

@Gonnym: If you are searching for articles beginning with a specific string, you can look at this page which does appear to provide an option to hide redirects. I'm unsure if there's a corresponding page that handles titles containing a specific string.—Cpt.a.haddock (talk) (please ping when replying) 21:30, 14 September 2018 (UTC)
@Cpt.a.haddock: I'm trying to find titles using certain disambiguations. So "intitle" works for that, but then it just gives me all the redirects as well which defeat the purpose of my search. Prefix won't help here. --Gonnym (talk) 21:35, 14 September 2018 (UTC)
I was having this problem also, likely for a similar reason. It would be very nice if I could discard results from redirects. I think phab:T73491 probably blocks any similar functionality. --Izno (talk) 22:39, 14 September 2018 (UTC)

There's a script SearchSuite by The Transhumanist that can hide redirect results, and make various other improvements/adjustments to search result pages - Evad37 [talk] 12:07, 15 September 2018 (UTC)

Amazing! Thank you very much! --Gonnym (talk) 12:17, 15 September 2018 (UTC)
You are welcome. :)    — The Transhumanist   12:25, 15 September 2018 (UTC)
@Izno and Gonnym: From SearchSuite's documentation:
SR redirecteds
Turning this off doesn't just remove the notes that say "redirect from", it removes the entire entries that include those notes. It also removes entries of items from related categories, and the results that match subheadings.
Turning it back on, adds those items back onto the list.
This feature helps narrow search results down to the topic entered.
I hope you find it useful.    — The Transhumanist   12:25, 15 September 2018 (UTC)
So far it is. The way Wikipedia's system is set-up is mind blowing to me. Instead of creating a system where a title and a disambiguation are two separate entities, they are just another string in the system. This made searching for incorrect usages extremely hard. Thanks again for creating this! --Gonnym (talk) 12:30, 15 September 2018 (UTC)

Watchlist filter and Twinkle not loading in Chrome

I've experienced several issues in Chrome over the past week.

  1. The watchlist filter does not load. Just gets stuck on the three loading dots permanently.
  2. Twinkle doesn't load when I open a article.
  3. I'm unable to open any collapsed navboxes. The "show" links are just not present.

I'm not experiencing these issues in other browsers (Edge and IE). --The1337gamer (talk) 09:52, 16 September 2018 (UTC)

It works for me. Google Chrome 69.0.3497.92, Windows 10, Vector. What is your skin at Special:Preferences#mw-prefsection-rendering? Does https://en.wikipedia.org/wiki/Special:Watchlist?safemode=1 work? Do navboxes work if you log out? PrimeHunter (talk) 10:18, 16 September 2018 (UTC)
Also on Chrome 69.0.3497.92, Windows 10, Vector. Had to check the skin on Edge because I can't actually access Special:Preferences#mw-prefsection-rendering on Google Chrome since the tabs on Preferences don't load either when I select them. Watchlist filter is missing from that safe mode link and collapsed navboxes also don't work when I log out. --The1337gamer (talk) 10:35, 16 September 2018 (UTC)
It sounds like a browser problem with JavaScript. Does https://www.whatismybrowser.com/detect/is-javascript-enabled say JavaScript is enabled? Try to clear your entire cache. Does JavaScript work at other sites? Do you have Chrome extensions or security settings which may disable or cripple JavaScript at some sites? If you make tests at Wikipedia then I suggest being logged out. If navboxes work when logged out then you can test whether all is well when you log in. PrimeHunter (talk) 11:40, 16 September 2018 (UTC)
This happened to me and was caused by uBlock Origin. — JJMC89(T·C) 16:23, 16 September 2018 (UTC)
It seems it is the AdBlock extension on Chrome causing it for me. I've added Wikipedia to the whitelist filter and the issues are now resolved. Thanks for the help both of you. --The1337gamer (talk) 16:56, 16 September 2018 (UTC)

Specific Inquiry about Data on Mathematics Portal

On the Portal:Mathematics page (https://en.wikipedia.org/wiki/Portal%3AMathematics), there is a claim that "There are approximately 31,444 mathematics articles on Wikipedia. I'm curious about how Wikipedians have gone about estimating this number. Can someone point me in the right direction to find the answer? I looked at WikiData, but did not find enough of a robust dataset that could support this high count reported on the Portal.

Any help would be greatly appreciated. — Preceding unsigned comment added by 001JakubSvec (talkcontribs) 04:12, 17 September 2018 (UTC)

I've removed the statement. The count hadn't been updated since 2015. — JJMC89(T·C) 04:34, 17 September 2018 (UTC)
JJMC89, thank you for the speedy update, but I was mostly curious about how Wikipedia determined that in the first place, even if it was in 2015 that it determined that statistic. -001JakubSvec — Preceding unsigned comment added by 001JakubSvec (talkcontribs) 12:26, 17 September 2018 (UTC)
This example was kept at Wikipedia:WikiProject Mathematics/Count. The page history [8] shows it was updated by a bot until 16 June 2015‎. The edit summaries only said "daily update from wikilabs". Other examples have used counts of articles tagged by a WikiProject. Wikipedia:WikiProject Mathematics uses {{Maths rating}} but it only has around 17,000 transclusions. Category:Mathematics articles by quality gives the same total. I don't know where the bot counted the extra articles. PrimeHunter (talk) 13:04, 17 September 2018 (UTC)

Copying on tablets and smartphones

There’s an unresolved issue about copying content on devices such as tablets (iPads and etc) we need an extension that lets us copy all the content of a page at once without having to scroll through each line for copying, for example you have to sell yourself to Satan to copy a page like this on a tablet, and to people like myself who contribute mostly using tablets, this is annoying as heck. It would be really cool if we had some sort of “select and copy all” tool, developed either by a user or Wikimedia.--▸ ‎épine talk 08:48, 17 September 2018 (UTC)

@Épine: are you using the app/mobile view/desktop view/etc? If not using the app, are you only having this issue with certain browsers? — xaosflux Talk 16:15, 17 September 2018 (UTC)
@Xaosflux: I’m using desktop mode on an iPad, Safari browser. I rarely edit using the wiki app. The browser is not an issue, the way the apple products are designed to copy content is. This issue can be easily resolved with a small and quick tool that can either be developed by a user or the wikimedia foundation. I don’t know why this issue keeps getting overlooked.--▸ ‎épine talk 18:36, 17 September 2018 (UTC)
The Editing team has been talking about some problems with mobile editing. Épine, would you mind leaving a note at mw:Talk:Mobile editing using the visual editor report about this? It's not strictly on topic, but I think it'll be the best way to make sure that everyone on the team sees it. Whatamidoing (WMF) (talk) 17:38, 18 September 2018 (UTC)
@Whatamidoing (WMF): I don’t think it’s appropriate to address this issue there. I think they’re talking about the visual editor which I never use, I only use source editor. If you can address it on my behalf I would appreciate it.--▸ ‎épine talk 18:55, 18 September 2018 (UTC)
Épine, at the moment, they're mostly talking about basic problems with using mobile devices, including copying and pasting, so I'm sure they'd be interested. (Presumably Safari's copying/pasting system is the same on all of the editing tools on Wikipedia.) I can certainly talk to them for you, if that's what you prefer. Whatamidoing (WMF) (talk) 21:01, 18 September 2018 (UTC)
@Whatamidoing (WMF): you have a higher chance of being listened to (made some other requests that are left unanswered for some reason) so please do so and warn them about this issue. On PC you can just ctl+a and select everything while on tablets on phones you can’t execute an action like that. Note that copying from protected pages is even worse. Thank you.—▸ ‎épine talk 22:15, 18 September 2018 (UTC)
I've started with a note on that page. I pinged you, so you can make sure that I accurately described the problem. I also pinged Jess, the team's new designer. I think she'll be particularly interested in this problem. Whatamidoing (WMF) (talk) 17:48, 19 September 2018 (UTC)

Oddity with navigation popups

This has been brought up at WP:ERRORS today. At Template:Did_you_know, the last hook of the day contains a link to Crime Does Not Pay (comics). If I hover over this link, the preview actually shows me the "Spinoffs" paragraph of the article, instead of the lede as you would expect. This happens in Firefox, Edge and Chrome. However, on all three of those browsers, if I log out, it works correctly. I am on Windows Home 10.0.17134. Black Kite (talk) 09:24, 17 September 2018 (UTC)

Black Kite, does it work now? Works for me now after this which I think allows navpopups to detect the bold lead instead of skipping to the bold text in Crime_Does_Not_Pay_(comics)#Spinoffs Galobtter (pingó mió) 09:36, 17 September 2018 (UTC)
Also, when you're logged out, mw:Page_Previews is used which is different from Wikipedia:Tools/Navigation_popups Galobtter (pingó mió) 09:39, 17 September 2018 (UTC)
Seems to be working for me now (I am the editor who first raised ths at ERRORS). Thanks all for the help. DuncanHill (talk) 13:39, 17 September 2018 (UTC)
Yes, it works for me now as well, thanks. It's still a bug, though, isn't it? Black Kite (talk) 18:15, 17 September 2018 (UTC)

Tech News: 2018-38

21:57, 17 September 2018 (UTC)

Feedback wanted on mobile web contribution prototype

CKoerner (WMF) (talk) 15:34, 18 September 2018 (UTC)

IAdmin access request for User:Pharos

A request for Interface administrator access under the stop-gap process for User:Pharos is currently open at Wikipedia_talk:Interface_administrators#IAdmin_temporary_access_request_for_User:Pharos. Community commentary on the request is welcome at that page. Best regards, — xaosflux Talk 18:05, 18 September 2018 (UTC)

Audio recording software

Anybody have any recommendations for a (preferably) free open source software for recording/editing spoken audio recordings of articles? I would have posted this at WikiProject Spoken Wikipedia, but it seems pretty dagum dead there. GMGtalk 18:57, 18 September 2018 (UTC)

Audacity is quite popular lately and simple to use (it's not necessarily for voice recordings only, however). —PaleoNeonate – 19:37, 18 September 2018 (UTC)
If I'm not mistaken I think I used Audacity some ten-odd years ago in college, but I don't remember it having any kind of editing functionality. My intuition was to do two takes and splice the paragraphs together for which ever was the better take. But the last time I messed with audio editing I was (again) in college, and I don't own any fancy pants software anymore. GMGtalk 19:41, 18 September 2018 (UTC)
Audacity does allow editing audio, and it should allow doing what you want re splicing pretty easily Galobtter (pingó mió) 21:47, 18 September 2018 (UTC)
@GreenMeansGo:. Second Audacity. Standard tool used by the LibriVox community. A helpful page. -- GreenC 13:34, 19 September 2018 (UTC)
I downloaded it last night and did a couple of test runs. But I'm going to have to dig through the stacks of boxes that are the remnants of my music room to find one of my old USB mics. The mic on my laptop bottoms out on any subtle inflection and basically records nothing. GMGtalk 13:41, 19 September 2018 (UTC)
  • I'd also recommend Audacity. I use it several times a month, at least. As for the mic, if you have to buy one I'd recommend a Blue Yet as a relatively cheap mic that's very popular with youtubers. Don't forget the pop filter. I have one and while it's not quite studio quality, it's close enough to produce professional-sounding audio with the right post-processing. I also have a bunch of tips for processing vocal audio, if you're interested. Let me know at my talk page. ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 14:23, 19 September 2018 (UTC)

Prefs change

OOUI continues its march; see https://en.wikipedia.beta.wmflabs.org/wiki/Special:Preferences for the latest. AFAICT some of the sections look just about the same, and some (especially the first) are more obviously different. Remember that the content isn't changing; it's just things like the size of the buttons and the color of the tabs.

Also, there's at least one feature that's likely to be useful: You can now give people a link to the relevant sub-section, not just the tab. This means that the WP:AFD instructions can be updated to tell people to go to "https://en.wikipedia.beta.wmflabs.org/wiki/Special:Preferences#mw-prefsection-gadgets-browsing" to turn on Twinkle (for example), rather than just to the gadgets tab, and then to scroll around until you find it. Later, that team is hoping to change things so that individual items (e.g., the Twinkle button itself) can be linked and highlighted. So there's some good news here. Whatamidoing (WMF) (talk) 21:06, 18 September 2018 (UTC)

You can also test this locally at Special:Preferences and tacking ?ooui=1 to the end of the URL. --Izno (talk) 21:42, 18 September 2018 (UTC)

Watchlist updating itself

If this a new feature? If so, why was it implemented? I don't want my watchlist updating itself, especially when I'm in the process of catching up on my watchlist. It's annoying having to find the spot I was at time and again. Flyer22 Reborn (talk) 23:12, 18 September 2018 (UTC)

This could be one of two things:
  • There was a gadget or user script lying around which implemented this. Verify you aren't loading one of those.
  • This is part of the recent (a few months ago) watchlist improvements. You can verify those are turned on if there is no checkmark at Special:Preferences#mw-prefsection-watchlist. Either a) you can opt out there entirely for all improvements or b) you can go to the watchlist itself, find the button that says "Live updates", and press it, such that a triangle ("play") displays after, rather than a square ("stop").
--Izno (talk) 23:29, 18 September 2018 (UTC)
Thanks, Izno. Flyer22 Reborn (talk) 00:14, 19 September 2018 (UTC)
Flyer, there's a button right above the first date/item. It says "Live updates". If it's selected/dark blue, then un-select it. Whatamidoing (WMF) (talk) 17:22, 19 September 2018 (UTC)

A technical request

Is there a way to find instances of {{infobox song}} where certain fields are not filled in? I sometimes find instances where at least one of the genre, label, writer, or producer is not filled in, and would like to work on filling those in where possible, as I just did on Jump Around. Ten Pound Hammer(What did I screw up now?) 23:38, 18 September 2018 (UTC)

There's an external tool or two lying around which list parameters which are unused, but I don't know if unused in specific templates... You could use AWB, search for "hastemplate:infobox song", and then set it to skip when it detects | *paraname *= *.* or something like that. --Izno (talk) 23:53, 18 September 2018 (UTC)
If those are required (or very nice to have) parameters, it might be worth it to add a tracking category for parameters that are missing. For an example of such a category, see Category:Comics infobox missing language parameter. If you need help, post on the template's talk page and ping me. I'll stop by. – Jonesey95 (talk) 09:19, 19 September 2018 (UTC)
TenPoundHammer, see templates with missing genre and missing writer. One can't find instances missing the other two parameters using this tool because they aren't set as "suggested" parameters in the WP:TemplateData for {{infobox song}} (though one could change that and it'll come in next month's report) Galobtter (pingó mió) 09:31, 19 September 2018 (UTC)

Is tools.wmflabs down?

Greetings, for several days now when attempting to run tools.wmflabs.org/enwp10/cgi-bin/update.fcgi and getting "504 Gateway Time-out" instead. Not sure who to contact so I thought to start here at VPT. Regards, JoeHebda • (talk) 13:25, 19 September 2018 (UTC)

@JoeHebda: is a platform for developers to host their programs. So no, not all the tools.wmflabs.org platform is down, only the enwp10 tool :)
@Hedonil, Kelson, and Theopolisme:, project maintainers of https://tools.wmflabs.org/enwp10 tool. --Framawiki (please notify) (talk) 16:42, 19 September 2018 (UTC)
I reported at Phabricator, open task T204844 is "504 Gateway Time-out on enwp10 tool". JoeHebda • (talk) 16:45, 19 September 2018 (UTC)
Pings to maintainers: @Theopolisme:, @Kelson:, and @Hedonil:. — xaosflux Talk 17:12, 19 September 2018 (UTC)

--

I have restarted the Web service manually and it is back. Kelson (talk) 10:06, 20 September 2018 (UTC)

Sortable side-scrolling table

Hello there: on the suggestion of Waldir, I wish to ask here if anyone can add the ability to sort in {{Scrolling table}}? I think adding such functionality may be useful for tables like the one at Škoda Auto § Sales and markets, as well as more sophisticated examples that I not know of yet at this time. Best, --Marianian(talk) 17:27, 19 September 2018 (UTC)

@Marianian: You should now be able to set |sortable= to any value to add sortability. --Izno (talk) 20:29, 19 September 2018 (UTC)
Hi, I think it takes more than adding the parameter to {{Scrolling table/top}}. I tested it and I cannot see the functionality to sort the values. For the record, using Firefox 62.0. Best, --Marianian(talk) 21:48, 19 September 2018 (UTC)
@Marianian: So I just took a second look, and what you're requesting cannot be done with the way the templates are implemented. The general point I'm going to make is that the table is fake -- it might look like a single table, but it is actually two tables. I'm half tempted to send the templates to TFD because a) they are not widely used and b) should not be used at all, as I would guess they are inaccessible. --Izno (talk) 22:07, 19 September 2018 (UTC)

Broken template

Something is causing the template to be broken. See Wikipedia:Articles for deletion/Jean-Philippe Susilovic, where the {{u|7&6=thirteen}} is displayed as [[User:{{{1}}}|{{{1}}}]]. PS please ping me if this is replied. I'm not watching this page. I have also posted at Template_talk:User_link#Broken_template but redirected replies here. --Tyw7 (🗣️ Talk) — If (reply) then (ping me) 20:24, 19 September 2018 (UTC)

Fixed. Ruslik_Zero 20:27, 19 September 2018 (UTC)
Ruslik0, erm still not working https://en.wikipedia.org/w/index.php?title=Wikipedia%3AArticles_for_deletion%2FJean-Philippe_Susilovic&type=revision&diff=860316837&oldid=860316800 --Tyw7 (🗣️ Talk) — If (reply) then (ping me) 20:45, 19 September 2018 (UTC)
@Ruslik0: I don't think that your fix is the best way of doing it, although it does work in certain circumstances. A better way would be to explicitly number the parameter, as in {{u|1=7&6=thirteen}}. --Redrose64 🌹 (talk) 20:48, 19 September 2018 (UTC)

Pinging Enterprisey as his widget uses this template. --Tyw7 (🗣️ Talk) — If (reply) then (ping me) 20:46, 19 September 2018 (UTC)

@Tyw7: The explanation of the original problem is that since 7&6=thirteen (talk · contribs)'s login name contains an equals sign, whenever it is used in what is intended to be a positional parameter of a template, it is instead treated as a named parameter - the name being 7&6 and the value being thirteen. --Redrose64 🌹 (talk) 20:48, 19 September 2018 (UTC)
You can always contact me by using [[User:7&6-thirteen]]. 7&6=thirteen () 20:51, 19 September 2018 (UTC)
7&6=thirteen, thanks. Yeah I was trying to ping you. Plus Enterprisey's reply gadget uses that template. --Tyw7 (🗣️ Talk) — If (reply) then (ping me) 20:54, 19 September 2018 (UTC)
@7&6=thirteen: no we can't. User=7&6-thirteen is a redlink to a non-existent article. --Redrose64 🌹 (talk) 21:13, 19 September 2018 (UTC)
Redrose64, is there a possible fix to the bug for users with "=" in their name? Also maybe user:Enterprisey can fix his reply gadget to use the 1= template to make it more resilient. --Tyw7 (🗣️ Talk) — If (reply) then (ping me) 20:52, 19 September 2018 (UTC)
One can make reply-link do that by setting replyLinkPreloadPingTpl to "{{u|1 = ##}}, ". Not sure if i'd want "1=" everywhere for the very rare cases of breakage.. Galobtter (pingó mió) 20:56, 19 September 2018 (UTC)
@Tyw7: There is no possible fix, other than the |1= method that I already described, because there is no bug. It is a design feature of the MediaWiki template parser that in every template, every parameter that contains an equals sign is interpreted as a named parameter. See H:T#Parameters. --Redrose64 🌹 (talk) 21:18, 19 September 2018 (UTC)
Redrose64, ah right. I guess the only fix is probably a rename but I doubt 7&6 would want to do that. --Tyw7 (🗣️ Talk) — If (reply) then (ping me) 22:19, 19 September 2018 (UTC)
There is a possible workaround in the template; if implemented in Lua the template could automatically interpret unrecognized parameters as usernames containing equals; something like for k, v in pairs(args) do if (string.match(k, '%D')) and (not paramWhitelist[k]) do addEqualsUsername(k, v) end end would let usernames containing equals be "escaped" automatically. {{Nihiltres |talk |edits}} 13:57, 20 September 2018 (UTC)
@Nihiltres: Other than checking to see if the user page exists (which only works if the user has a user page, which is not a given), how would the lua script interpret {{u|1=one}}? Is it User:1=one or User:one? --Ahecht (TALK
PAGE
) 16:24, 20 September 2018 (UTC)
@Ahecht: It would handle your example as "User:one"; the logic (string.match(k, '%D')) I mentioned checks for any non-numerical characters ("%D") before the equals sign; normally those are "lost" as unrecognized parameters, but the example code would recapture those cases. A user "User:1=one" would still be a problem; there's no safe way of checking one that would match a purely-numeric named parameter. I'd recommend such users either a) be renamed or b) included as narrow special cases, where (b) only applies if they register the conflicting account themselves to ensure it isn't used. {{Nihiltres |talk |edits}} 17:18, 20 September 2018 (UTC)

Found another issue. The user's name broke the [[]] and []. --Tyw7 (🗣️ Talk) — If (reply) then (ping me) 21:08, 19 September 2018 (UTC)

@Tyw7: No, those broke because you used unencoded braces. Totally different issue. --Redrose64 🌹 (talk) 21:20, 19 September 2018 (UTC)
Redrose64, how to properly link then? With other usernames posting diffs usually work. --Tyw7 (🗣️ Talk) — If (reply) then (ping me) 21:46, 19 September 2018 (UTC)
It is nothing to do with the user name, it is the unencoded braces. This is one of the reasons that we request people not to use templates in section headings. To link to that section, either of the following work in Opera: User talk:7&6=thirteen#Username breaks the .7B.7Bu.7D.7D template; User talk:7&6=thirteen#Username breaks the {{u}} template, although the second one might not work in all browsers. --Redrose64 🌹 (talk) 22:03, 19 September 2018 (UTC)
Redrose64, the first one worked. User_talk:Enterprisey/reply-link#Gadget_fails_to_reply_to_users_with_"="_in_their_name --Tyw7 (🗣️ Talk) — If (reply) then (ping me) 22:18, 19 September 2018 (UTC)

Please post comments about Enterprisey's gadget here --Tyw7 (🗣️ Talk) — If (reply) then (ping me) 21:05, 19 September 2018 (UTC)

Sorry for my error. [[User:7&6-thirteen]]. 7&6=thirteen () 21:16, 19 September 2018 (UTC)
User:7&6-thirteen no such user. Please stick to the method that I described, which is proven to work. --Redrose64 🌹 (talk) 21:21, 19 September 2018 (UTC)
[[User:7&6=thirteen]] works. -- GreenC 21:30, 19 September 2018 (UTC)
Duh!. I just use four tildes. Sorry for the repeated errors. Thanks. 7&6=thirteen () 21:33, 19 September 2018 (UTC)
I was trying to link to his page.... how to do that? The talk page link to the specific thread breaks so as direct linking using the long URL> --Tyw7 (🗣️ Talk) — If (reply) then (ping me) 21:45, 19 September 2018 (UTC)
You link to the page in the way that I described already - make sure that you use |1= in order that the next equals sign is taken literally, and not as the separator of a name=value pair. If it helps, you can do this for all users, like this: {{u|1=Tyw7}}Tyw7. --Redrose64 🌹 (talk) 22:12, 19 September 2018 (UTC)
I once proposed to disallow equals signs in new Wikimedia accounts: meta:Talk:Title blacklist/Archives/2015#Equals sign. PrimeHunter (talk) 23:47, 19 September 2018 (UTC)
^ this seems like it would be the real solution. Killiondude (talk) 01:00, 20 September 2018 (UTC)
PrimeHunter, I support this proposal. Can you re-submit? --Tyw7 (🗣️ Talk) — If (reply) then (ping me) 01:25, 20 September 2018 (UTC)
An archive search shows it was also proposed at meta:Talk:Title blacklist/Archives/2018#= where it was rejected by Billinghurst. PrimeHunter (talk) 09:41, 20 September 2018 (UTC)
1) We already have usernames with equal signs. 2) Users can be renamed. 3) If it that problematic, get it fixed properly by opening a phabricator ticket, not a jerry-built job in the title blacklist. — billinghurst sDrewth 11:22, 20 September 2018 (UTC)
1) Blacklisting new "=" would reduce future problems without annoying existing users. 2) It's easier to blacklist "=" than to rename users who chose a name in good faith. 3) Many Wikimedia wikis have templates with usernames as unnamed parameters. Many other wikis may have no issue with "=" in usernames. It could be a MediaWiki configuration option but then it would be similar to just blacklisting it. Requested MediaWiki features are often declined or take years. PrimeHunter (talk) 13:00, 20 September 2018 (UTC)
1) Yes, though doesn't resolve our problem of use, just limits the cases into the future. 2) Sure, see 1) though it removes the problem into the future. 3) The issues of positional parameter and an equals sign is not limited to usernames alone, there are many times that it has an impact. It is not a new phenomenon, nor needs new solutions. We can and should educate our users, and write good templates, write good documentation, and utilise lua as required, not necessarily rely on lazy templating.

What if other wikis want their users to have an equals sign? What if users want to have an equals sign. We just forbid it so it makes it easier for user positional parameters at the gorilla wiki as it doesn't like it where it is a very occasional problem?

If it is truly problematic, start a phabricator ticket and see what ensues in the conversation, as ideally technical issues should have technical solutions, whereas social issues belong in blacklists. If it is seen as a crosswiki issue that needs resolution, then start your conversation at meta and invite the other communities to have an opinion, and if there is a consensus it will be undertaken. However, please just don't sit here and opine that it makes our use of a small set of templates here at enwiki harder for you when there is a pretty simple solution of 1= or user= and some updates to documentation. — billinghurst sDrewth 23:20, 20 September 2018 (UTC)

@Billinghurst: I'm not familiar with title blacklist additions. Is there a process on meta for gaining consensus for additions, or are proposals simply up to meta-admin/steward discretion? --Ahecht (TALK
PAGE
) 16:34, 20 September 2018 (UTC)
@Ahecht: Sure, meta is a consensus wiki like all WMF, and this discussion it would take place at m:talk:Title blacklist. Depending on the complexity and the impact of decisions that have a crosswiki impact, meta administrators may do it easily and quickly, or we may ask for a broader consensus, or we may ask for post to many/numbers of wikis to ensure that someone is open for many language, many sister wikis decision-making. The two previous occasions have had little input from users, and on both occasions the feedback was that it is probably a mediawiki-level determiner (so phabricator) if it is that problematic. If it came to my making a decision, I doubt that I would do that without broader xwiki input identifying the risks, the solutions, and that many wikis thought that it was appropriate. — billinghurst sDrewth 22:55, 20 September 2018 (UTC)

Tracking down a heavy memory leak

A few weeks ago, I volunteered for new page review and I tweaked some configs accordingly. Since then, every Wikipedia open tab leaks large amounts of memory, so that I have to kill the relevant processes in Chrome every few hours. I am trying to track down what the pages are doing, but had no luck so far. The Wikipedia pages typically accumulate memory allocation while in the background, sometimes up to gigabytes, while consuming a tiny fraction of CPU. Then when I switch to display such a page, memory usage goes back to a reasonable value. I am positive that this phenomenon only applies to the Wikipedia site. I have tried removing all my user scripts, to no effect. I also tried to disable many gadgets in Preferences, but had no luck isolating the issue. Is it possible to check the history of my preferences, especially in the gadgets section? Then I could restore them to a known working state prior to the memory leaks appearing. My next attempt would be to request removal of the NPR user right, although I don't understand how that would affect memory usage. Any help appreciated. — JFG talk 08:54, 20 September 2018 (UTC)

User:JFG, I'm sorry to hear that you are having problems with this. I wonder whether the "safemode" trick would help you figure this out. See mw:Help:Locating broken scripts#Test if you have problems related to user scripts or gadgets.
Did you turn off NAVPOPS? I've seen something similar in Safari on another wiki (one whose tabs I tend to open because I'll get back to it "soon", and days later I still haven't read them...), and I think that NAVPOPS might be one of the few commonalities. Whatamidoing (WMF) (talk) 16:42, 20 September 2018 (UTC)
Thanks for the tips. Loading a page with |safemode=1 still leaks memory. NAVPOPS is disabled. Any other ideas? — JFG talk 23:18, 20 September 2018 (UTC)
JFG, any browser extensions enabled ? —TheDJ (talkcontribs) 07:49, 21 September 2018 (UTC)
Yes, I've got a few. Did not change any of them prior to this issue, though. I could try disabling them. Also, I made a snapshot of memory use in debug mode, would that help if I upload it somewhere? — JFG talk 08:24, 21 September 2018 (UTC)
All extensions disabled this morning; still leaking like a sieve on idle pages. An article page that has been loaded, minimized, left untouched, and shares its process with no other page, grows to over a gigabyte of memory usage over a couple hours. I'm really puzzled. — JFG talk 10:34, 21 September 2018 (UTC)
I've filed phab:T205127 and liberally tagged some devs who might be interested. Please feel free to drag-and-drop your picture into a comment on the Phab task. Whatamidoing (WMF) (talk) 18:00, 21 September 2018 (UTC)
Great. Let's continue there. — JFG talk 21:12, 21 September 2018 (UTC)

Strike tag odd behaviour

I've been cleaning out some mis-matched <s> tags in old WP:FAC nomination pages, and ran into an odd situation, which I've reproduced in this sandbox. The closing </s> tag does not work there. Is there a non-printing character stuck in there somewhere that is screwing up the parsing? The original page which has the problem is here, now fixed with this edit, though I don't know why that worked. Mike Christie (talk - contribs - library) 10:52, 20 September 2018 (UTC)

This is expected behavior according to the lengthy discussion on T199057. I'd just skip to Matma's comment at phab:T199057#4524359. --Izno (talk) 12:26, 20 September 2018 (UTC)
That's a surprise, but I see why they declined it. Mike Christie (talk - contribs - library) 13:46, 20 September 2018 (UTC)
I see a glaring problem at Wikipedia:Featured article candidates/Banded sugar ant/archive1: there are some bad violations of WP:INDENTGAP which might aggravate that problem described at phab:. But regardless of that, there are a number of cases where <s>...</s> is used to enclose a list, which is not valid - lists are flow content, and <s>...</s> may only enclose phrasing content. Markup like this is valid:
::::<s>Comment</s>
::::<s>Comment</s>
::::<s>Comment</s>
but markup like this
<s>
::::Comment
::::Comment
::::Comment
</s>
is invalid for the reason that I just described. Even worse is
<s>
::::Comment
::::Comment
::::Comment</s>
since the absence of a newline before the </s> tag means that it is inside a list item, whereas the matching opening tag is not just outside the item, it is outside the whole list which is a nesting error. --Redrose64 🌹 (talk) 20:58, 20 September 2018 (UTC)

Email pings

I do not have email checked as notification of pings, not on Englilsh Wikipedia, nowhere. I just got 3 emails that I've been pinged on Wikipedia. One of them in non-English language (I'm guessing French, but I don't know for sure). As I have received no ping notices on my Wikipedia page itself, I'm deleting the emails without opening them. — Maile (talk) 19:40, 20 September 2018 (UTC)

Hi @Maile66:, without looking at the emails, we're not really going to be able to tell if they came from us or not. You may want to check Special:GlobalPreferences#mw-prefsection-echo to see if you have any email notifications on by default, where someone could email you from any of the other projects. — xaosflux Talk 19:49, 20 September 2018 (UTC)
Thanks. Checked Global Preferences. No email checked for notifications. — Maile (talk) 20:02, 20 September 2018 (UTC)
The reason is that you just received a silly attack at fr:User talk:Maile66 from an WP:LTA. I blanked the nonsense so I am afraid you will get another email. You can fix the emails at fr:Special:Preferences. The LTA has been dropping crap like that for a decade and has resumed activity recently. Johnuniq (talk) 23:08, 20 September 2018 (UTC)
Well, I figured out what is triggering it. Every one has happened within seconds of my blocking a user at WP:AIV. The last one came just seconds after my original block of 209.239.97.188. Well, it did make me change my password. Which is probably a good idea once in a while, anyhow. Thanks. — Maile (talk) 23:37, 20 September 2018 (UTC)
Also, I don't read French. So, I'm guessing that by unchecking the same two boxes that are unchecked in English WP has done the trick. — Maile (talk) 23:40, 20 September 2018 (UTC)
When I have set my preferences at another language site, the first step is to set the language to English and save that. That makes everything in preferences a lot clearer. It looks as though you can do that at the global preferences linked above and then it will apply by default to all sites. Johnuniq (talk) 03:41, 21 September 2018 (UTC)
For related cases, see ANI. Johnuniq (talk) 03:45, 21 September 2018 (UTC)
Thanks for the global preferences info. It worked. Re the ANI link ... yep, I blocked two lightening round-robin doppelganger socks of the yahweh vandal. — Maile (talk) 11:05, 21 September 2018 (UTC)

Problems with Template:Hidden begin/Template:Hidden end and sortable headers in collapsible tables.

EDIT: The problem appears to have resolved itself, at least on my end, although User:Woodlot was able to confirm it for me earlier. I'm going to strike this comment. Here's the unstruck version for readability. Hi, I'm going to paste here what I wrote on User:Woodlot's talk page about a technical problem I found with the use of Template:Hidden begin and Template:Hidden end:

On Webkit/Blink browsers (tested in Safari and Chrome and Mac OS X, and Chrome on Windows), if Template:Hidden begin and Template:Hidden end are on the page, all of the sortable column headers in other collapsible tables on the page disappear. For a comparison, see the Santa Barbara County voter registration tables before and after the {{Hidden...}} templates were added. The same thing happens on Contra Costa County [13][14], Sacramento County [15][16], etc.

The tables render normally in Firefox on OSX and Edge on Windows (the only other browsers I tested). I’ve checked the diffs and nothing changes in the tables themselves. It’s also worth noting that this is not restricted to tables in the same section, and it affects tables both above and below the {{Hidden...}} templates. See the "Crime" sections of the linked comparisons for the same effect.

Some additional information: When I checked my comparison links in Chrome (I primarily use Safari), I opened the “before” links first, and the “after” pages then appeared to render properly. I believe this is due to some rather aggressive caching on Chrome's part. To see what the revision actually looks like be sure to bypass the cache.

I'm sorry I don't have more information on this. User:Woodlot suggested I post it here – as you can no doubt see by my lack of an account, I don't spend much time behind the scenes on Wikipedia. I prefer to just make small copyedits and formatting fixes. Still, hopefully this information can be of some use. 50.1.108.138 (talk) 21:08, 20 September 2018 (UTC)

Collapsibility should be removed in main space per MOS:COLLAPSE. --Izno (talk) 21:22, 20 September 2018 (UTC)
I'm aware of that (in fact I mentioned it in my linked comment on Woodlot's talk page). I wasn't the one making the edits. However, it seems that all of the editors on those county pages and similar articles are either unaware of that part of the MOS or are certain that the collapsible content is excepted. Regardless, the technical problem remains. It's too big for me to fix myself – I've no idea how many articles have the problem, and I'm not comfortable using scripts to make bulk edits.
Anyway, it may be a moot point since I've just checked the live examples again and they seem to be working. The behavior has been too inconsistent for me to really find a reduced test case. User:Woodlot was able to confirm the same behavior when they replied to me before, but now I can't replicate it. I'm going to strike my above comment for now. 50.1.108.138 (talk) 22:03, 20 September 2018 (UTC)

WikiProject request for technical assistance

I have a request on behalf of WikiProject Newspapers for somebody with programming abilities. I think it's not terribly difficult, and it's something that could be useful not just to us, but to any number of cross-article collaboration projects or "sprints."

Our project aims to add 1,000 stubs about U.S. newspapers by mid-December of this year, as well as adding infoboxen to existing stubs. What we need is a straightforward way to measure our progress.

I imagine it working like this:

  1. Start with the results of a SPARQL query like this (thank you Certes)
  2. For each item returned, test for the following (and perhaps a few other things as well; this would be the bare minimum)
    1. Did it exist on June 1, 2018?
    2. Is it a redirect now?
    3. Was it a redirect on June 1?
    4. Does it have an infobox now?
    5. Did it have an infobox as of June 1?
  3. The output, I think, would ideally be a spreadsheet or a wikitable containing all that info.

Is there anybody who might be willing to help us create such a script? (Note, I inquired about this previously on Wikidata, but I have a clearer idea about what is needed now.)

Suggestions for better venues to seek help are most welcome as well. -Pete Forsyth (talk) 23:32, 20 September 2018 (UTC)

Just to keep track, here are some other characteristics it would be nice to track before-and-after. None of these is necessary, but all would be nice to have:
number of footnotes; what maintenance banners, if any, at the top of the article; how many categories; does its talk page have the WikiProject Newspapers template; what quality rating(s) does it have; how many character in the article; how many sections on the talk page. -Pete Forsyth (talk) 00:17, 21 September 2018 (UTC)

Fixing bad mobile layout

Lagrangian point looks fine in desktop view, but in mobile view the lead images obscure the text. Any recommendations for troubleshooting this? Thanks, 28bytes (talk) 02:08, 21 September 2018 (UTC)

@28bytes: Looks fine to me in mobile domain. What do you mean by "obscures the text"? Obscure would be a word I would use to say "in front of"--what I see is "moves the text down", as is reasonable. --Izno (talk) 02:31, 21 September 2018 (UTC)
@Izno: I have uploaded a screenshot of what I am seeing here. 28bytes (talk) 02:59, 21 September 2018 (UTC)
@28bytes: Obscure indeed. What operating system, browser, and version is that in? --Izno (talk) 04:41, 21 September 2018 (UTC)
@Izno: iPhone 6, iOS 10.3.3, Safari. 28bytes (talk) 11:03, 21 September 2018 (UTC)
It might be due to the 400 px fixed image size of the lead image, which is above MOS:IMGSIZE recommendations for fixed image size for the lead image. I've reduced it - does it look fine now? Galobtter (pingó mió) 10:00, 21 September 2018 (UTC)
@Galobtter: Unfortunately the text is still hidden behind the images, even at the reduced size. 28bytes (talk) 11:03, 21 September 2018 (UTC)

Does mw.config need to be loaded?

When writing a user script that uses values in mw.config, do I need to explicitly load mw.config using ResourceLoader? Enterprisey (talk!) 02:21, 21 September 2018 (UTC)

No, mw.config is part of the base mediawiki module [17], which does not need to be loaded per mw:ResourceLoader/Core modules. - Evad37 [talk] 05:26, 21 September 2018 (UTC)
Thanks! Enterprisey (talk!) 05:51, 21 September 2018 (UTC)

Help with problem loading linkclassifier

I've been using User:Anomie/linkclassifier for a long time. Ihave it as link in my toolbiox in vector skin. Some time ago I noticed it occasionally wouldn't display, and I figured there was some timing issue on what was getting loaded in page. Refreshing usually fixed it. Lately it has gotten to where it would not load at all. Then looking at the instructions I updated my jss to use a suggested new script to load

$.when( mw.loader.using( 'mediawiki.util' ), $.ready ).then( function() { var el = mw.util.addPortletLink('p-tb', , 'Link Classifier'); $(el).click(function() { LinkClassifier.onDemand(); } ); } );

instead of what I had before

mw.util.addPortletLink('p-tb', 'javascript:LinkClassifier.onDemand()', 'Link classifier');

But now, every time I click on it, it reloads the page and the highlighting only briefly flashes before the page reloads. olderwiser 09:44, 21 September 2018 (UTC)

Bkonrad, those instructions were incorrect. I've amended them now. I think i'm even to blame for the incorrect instructions. So sorry. —TheDJ (talkcontribs) 11:01, 21 September 2018 (UTC)� —TheDJ (talkcontribs) 11:01, 21 September 2018 (UTC)
Thanks User:TheDJ, everything looks to be good now. olderwiser 11:07, 21 September 2018 (UTC)

Central javascript library for tools idea

Not sure if this is the best place for this discussion, but figured it might as well start here.

I'm sure that many of you have been bitten over the years by how different tools handle seemingly identical operations (see NPP toolbar vs Twinkle in creating AfDs for pages that have had a previous AfD discussion). What I would like to propose is the creation of a centralized javascript library that would contain the code required for common tasks, talk page messages, AfD and CSD processing, etc, that could in turn be used by tools like NPP and Twinkle so that code doing the technical actions wouldn't need to be duplicated across tools. This should reduce the number of errors, both technical and human. I don't have a clear thought out plan on how to accomplish this, but I wanted to broach the topic and see if anyone thought it sounded like a good idea other than me. Part of the challenge will obviously be getting the developers of the individual tools to be on board. {{u|zchrykng}} {T|C} 03:32, 22 September 2018 (UTC)

Justified text in edit boxes

The justified text option, as a gadget in user preferences, seems to enable text justification in edit boxes with source editing. While text justification is obviously useful in reading, it's frankly a pain when trying to edit pages, as the syntax and the like often leave large, unwelcome gaps between "words". If it's possible, please fix this so that justified text doesn't work in this case. Thanks. RAVENPVFF | talk ~ 10:38, 22 September 2018 (UTC)

Proposals

RfC: Switch to using Wikidata for interwiki links to Wikimedia Commons

Should use Wikidata as our primary source for links to Wikimedia Commons in sister project templates? Mike Peel (talk) 18:07, 25 August 2018 (UTC)

Background

Wikidata provides nearly all of the interwiki links from enwp articles to other Wikipedias, and other sister projects, through the links in the sidebar. However, we still use manual links in the sister project templates. With Wikimedia Commons specifically, there are currently over 750,000 articles that use {{Commonscat}} and similar templates - and nearly all of them currently have manually-defined and -maintained category names.

Extensive work has taken place this year to improve Wikidata's interwiki links to Commons, and this is now the main place where Commons' interwiki links are managed, with around 2 million Commons categories now linked to Wikidata items. These are maintained by a combination of editors from Commons, Wikidata, and other language Wikipedia editors, as well as bots - and these links are automatically updated when categories are moved on Commons. However, while those changes appear in the sidebar, the templates don't automatically update, and we have an increasingly large number of broken links to Commons as a result (which are tracked in the subcategories of Category:Commons category Wikidata tracking categories). This proposal would fix that.

If we decide to migrate to using Wikidata by default for links to Wikimedia Commons in these templates, then the next steps would be to bot-remove the manually-defined links to Commons that are the same as on Wikidata, and to investigate (manually or by bot) the mis-matched links to find out if they have been moved or are no longer needed. The links would then be maintained on Wikidata in the future. Where we need to have links to multiple commons categories from one page (or where there are any other complications), then these would continue to be manually defined. This proposal is focused on Wikimedia Commons, other sister project should be considered separately.

Survey

  • Support as proposer. I am also the human-in-charge of Pi bot, which is responsible for adding quite a few Commons sitelinks of late - and could help the bot-migration of existing links here if desired (subject to a bot request here). Thanks. Mike Peel (talk) 18:07, 25 August 2018 (UTC)
  • Support as a user seting countless links to Commons on Wikidata and trying to convince individual users to do the same. --Robby (talk) 20:20, 25 August 2018 (UTC)
  • Support - Assuming the implementation does not alter (or require extra work) to retain existing templates where there is not yet a link via Wikidata (i.e. it should replace existing templates only when there's a clearly appropriate replacement). I'm curious to hear whether there are any downsides to this? — Rhododendrites talk \\ 20:36, 25 August 2018 (UTC)
  • Support. It seems to be a good idea to have everything in one place.— Alpha3031 (tc) 05:24, 26 August 2018 (UTC)
  • Support as well. Done properly, this would improve the inter-project links and reduce maintenance overhead (always a welcome change for us WikiGnomes). — AfroThundr (u · t · c) 14:35, 26 August 2018 (UTC)
  • Strong Oppose As someone whose articles mostly include a Commons link, the correct commons category is often far from obvious, and far too many of the Wikidata links will be wrong (because far too much of everything on WD is wrong, not to mention Commons). That Commons seems to completely lack a mechanism for moving/renaming categories is much of the problem. Sorting this out will take forever and involve huge amounts of work - with very many wrong links sitting there indefinitely. Johnbod (talk) 17:55, 26 August 2018 (UTC)
    There is both a manual mechanism and a bot-based on-request one. Jo-Jo Eumerus (talk, contributions) 18:17, 26 August 2018 (UTC)
  • Oppose. Trusting Wikidata usually is a bad idea, vandalism there too often goes undetected for way too long (in my experience more so than is the case on enwiki). Furthermore, it would be better if the sister templates were simply removed and such links (at least those we want, which would be mainly commons) placed in the left side bar instead. Left side = Wikidata maintained, article = enwiki maintained. Mixing the two usually gives very unhappy results and many disputes. Fram (talk) 10:26, 27 August 2018 (UTC)
  • I am sympathetic to the aim of this RFC, and in that regard you could say I support it, but I would prefer to see these boxes and links removed entirely in favor of the links by Wikidata already provided in the sidebar. --Izno (talk) 12:10, 27 August 2018 (UTC)
    • Yes, keep these boxes only in cases where some exception is needed (e.g. an article on two persons, with two Commons cats). And in those cases keep it local. Fram (talk) 12:32, 27 August 2018 (UTC)
      • I wonder if in the general case a "two-person" exception will be all that necessary--I would guess that if we have an article on a pair, Commons should probably have a category on the pair. But IANACommonist.... but sure, there might be other, unknown exceptions (almost 6M articles now...). --Izno (talk) 14:06, 27 August 2018 (UTC)
  • Support - assuming the Wikidata value can be overriden for special editorial cases (when the WikiData value differs from the needed link and can't be changed on WikiData for whatever reason, or when multiple Commons category links would be useful). But the current handling via commonscat templates in the article itself should be kept (a removal is not proposed anyway, if I understood the OP correctly?). The template is better visible than a small link in an overloaded sidebar, and more flexible to use and change if needed. GermanJoe (talk) 11:33, 28 August 2018 (UTC)
  • Oppose. I'm not too involved in Wikidata integration, but what little discussion I've seen and what little actual activity I've paid attention to is far from flattering. And I'm not wagering that Wikidata has made tremendous strides in quality control since the relevant ArbCom discussion. There just isn't the manpower for that. Compassionate727 (T·C) 01:05, 30 August 2018 (UTC)
  • Oppose. The number of problems with wikidata information that I have encountered means that this is not a good idea and that the existing instances where editors have selected a specific target should be retained. In fact I would go further and remove any pulling of data from wikidata in this template and just report differences. There are problems with wikidata entry been incorrect, the random selection of a wikidata entry when there is more than 1 instance of commons link against an item on wikidata. The need for the positional parameter in the template when there is a need for a second positional parameter to show the display name. The use of multiple entries on a page to show different specific images of a topic. The problems around the commons category not matching the wikipedia scope for the topic and a different commons link it more appropriate etc.. Keith D (talk) 09:34, 30 August 2018 (UTC)
  • Weak support provided, and these are vital provisos, that (a) it's easy to over-ride the Wikidata default and (b) it's made clear to editors that they need to check the default provided by Wikidata, then this seems relatively harmless, and avoids redundancy, and in particular discrepant links. Peter coxhead (talk) 10:04, 30 August 2018 (UTC)
  • Support Despite Wikidata's poor reputation, I always think it is a valuable project and (with support and patience) will do more benefit to Wikipedia than harm. I also agree the pulled value should be easily overridable here so as to fix edge cases or where simply something different is needed. –Ammarpad (talk) 16:16, 30 August 2018 (UTC)
  • Oppose at this point, per Fram and Keith D. Too many potential problems at this point. Killiondude (talk) 19:34, 30 August 2018 (UTC)
  • Oppose I support Wikidata, but I don't support this proposal. I would support, but [18] is not what the bot should be doing. What if there is a gallery for example? This is not good ontological organization. --Rschen7754 21:32, 2 September 2018 (UTC) edited 02:44, 3 September 2018 (UTC)
    • Compare that to for example, d:Q16, which links to a gallery page on Commons. Candidly, I am not sure the bot is doing the right thing and unless the rules on Wikidata have changed recently I am not sure the bot task to do this should have been approved. (In fact, support was begrudging at best [19] and loosely based off a not widely-advertised discussion and 1 quick RFD.) --Rschen7754 21:39, 2 September 2018 (UTC)
  • Oppose per Fram. We do not need Wikidata's unreliable help to handle this. Nihlus 22:15, 3 September 2018 (UTC)
  • Support interwiki data is what Wikidata does best, and what we shouldn't duplicate that information here locally. None of the identified problems pertain to this task, but related problems that persist regardless of how this issue is handled. – Finnusertop (talkcontribs) 07:43, 4 September 2018 (UTC)
  • Strong support - the way to get more eyes on Wikidata to fix some of the issues people raise is not refusing to use it in any way on WP. Plus, in general, Wikidata has built in protections for interwiki links, such as allowing only one link per project per entry, that make it difficult to casually vandalize, at least in this instance. ARR8 (talk) 04:40, 11 September 2018 (UTC)
  • Support per proposer, this is the obvious next step in a process that's already worked quite well. Gamaliel (talk) 01:22, 12 September 2018 (UTC)
  • Support per proposer. Bidgee (talk) 03:25, 17 September 2018 (UTC)
  • Support Wikidata integration with Wikipedia can mean lots of things. I discount all oppose votes that generally dismiss the reliability of Wikidata in all contexts without distinguishing what is higher quality, safer, and higher impact content, versus what could cause more problems for less benefit. For this proposal we are talking about a relatively small collection of matches for higher profile media sets. This will only go into effect when Wikidata matches a Commons category and a Wikipedia article covering the same topic. These conditions are only typical when multiple Wiki editors have collectively made a Wikipedia article, uploaded media, sorted the media into a Commons category, and structured data for the topic on Wikidata. The human attention which goes into this workflow this one of the better opportunities for aligning the content and leveraging the existing editor base which could detect problems on a Wikipedia of any language where this is used, or Commons, or Wikidata. This system provides for more content security than we currently have for this content, not less. It is an experiment and things could got wrong but among experiments this seems like low risk of harm, high potential of positive impact, and high potential for detecting challenges with integration when they occur. Blue Rasberry (talk) 13:40, 17 September 2018 (UTC)
  • I would prefer an implementation like that with Template:Official website, where if no parameter is specified, it defaults to WD, and if a parameter is specified it does not, at least for now. In the short term, I would rather see a bot adding the templates in cases where there is no sister link in ELs, but there is a sister link on WD. GMGtalk 19:21, 17 September 2018 (UTC)
  • Comment I have a problem understanding the first sentence of this rfc "Wikidata provides nearly all of the interwiki links from enwp articles to other Wikipedias, and other sister projects, through the links in the sidebar." I understand Wikipedias to mean language wikipedias is that what is meant? As to sister project all the linking I do is thorough the body of an article. EG links to articles on wikisource (usuall either as a citation or as an line link), links to pictures (Files) on wikicommons and to words on Wiktionary. So User:Mike Peel please explain to me what you mean. Because I am not clear on what this RfC is about. -- PBS (talk) 19:22, 17 September 2018 (UTC)
Example @PBS: Look at Statue of Liberty#External_links. See the Commons box which links to Commons:Statue of Liberty. This discussion is about whether that box should be set only for humans to edit on English Wikipedia or whether a mix of automation to post here and human/automated editing on Wikidata can manage the link. Right now we in English Wikipedia manually have to make that connection. We can automate that connection in the same way that the various languages of Wikipedia connections happen, so yes, you understand that correctly. The connection in Wikidata is at Statue of Liberty (Q9202). Look at the bottom of the Wikidata entry to see how Wikidata connects various languages of Wikipedias and other Wikimedia projects. For English Wikipedia I think these connects are very useful. For other languages without an editor base making these connections are more valuable because connecting to Commons images and other Wikimedia content may be the only way to access information. Part of this experiment is about improving Wikipedia, and part is about Wikipedia testing this out for other language Wikipedias which are likely to follow the English language lead. That is another reason why interlanguage links get mentioned in these discussions, because English tends to find solutions which work generally for other projects.
Mike mentioned {{Commons category}} but I am talking about the similar {{Commons}}. For the Statue of Liberty editors have curated a selection of good media so we have a Commons page. When there is no curation, a more typical case, the link would be to the top level category for the concept and all the media in the category. This proposal covers both of these cases. I am not sure about numbers, but maybe this is 1 million or 20% of English Wikipedia articles. Blue Rasberry (talk) 13:55, 18 September 2018 (UTC)
Two points from the clarification if all you are talking about is changing the behaviour of two templates then the background needs to be rewritten much more succinct: just to focus on the changes to the two templates. The second is that both templates take names to create links to wikicommons, indeed it is a bad idea at the moment to assume that the en.wikipedia name and the commons name are the same because, if the article titles is changed, then the link to wikicommons will be broken. I can understand that is a problem that would go away with this proposed change, but if an editor on en.wikipedia wishes to change the link to another area on commons, at the moment they simply do it by changing the link name. In the future how would a link change be done if this proposal is accepted? -- PBS (talk) 18:03, 18 September 2018 (UTC)

Discussion (Switch to using Wikidata for interwiki links to Wikimedia Commons)

What were the recent changes made? I was under the impression that it was a huge mess with some items linking to the gallery and others linking to the category. Maybe things changed over my break though. --Rschen7754 04:18, 26 August 2018 (UTC)

@Rschen7754: On the Wikidata site, Commons sitelinks are now used much more, alongside Commons category (P373). Compare the statistics from September 2017 to June 2018. On the Commons side, Wikidata information is used a lot more in Commons categories (ahead of the arrival of Structured data on Commons that will affect the files). A lot of that has been done by Pi bot (talk · contribs) this year (see the list of tasks on the bot's user page), but it's also become the norm and there are a number of editors maintaining/adding more links manually. Thanks. Mike Peel (talk) 13:55, 26 August 2018 (UTC)
@Mike Peel: I am sorry for the late response, but this doesn't answer my question, and now I indeed see that the bot is doing what I feared it was and that this proposal does not address the inconsistency of some items linking to the gallery and others to the category (and in fact, the bot is making it worse). This has been a problem with Commons linking from day 1 and the WMDE team still has failed to fix this (it was raised to them but apparently it is not enough of a priority to them). Nevertheless, this proposal will make things worse as it stands. --Rschen7754 21:42, 2 September 2018 (UTC)
@Rschen7754: The bot adds/moves the sitelinks to category items where available, and if there is a better way of storing them in the future (dual sitelinks, mass-creation of category items, and end to commons galleries, etc.) then it will be straightforward to migrate to that system. The important thing in my mind is to have one main set of interwiki links between Commons and the other wikis (including enwp), which is then properly maintained, rather than N partial sets across all different projects. That's what this proposal is trying to move things towards. Thanks. Mike Peel (talk) 00:51, 3 September 2018 (UTC)
I'm afraid that this proposal is unclear and glosses over what will happen to a page like Canada. Will it link to the category or the gallery? Shouldn't we be consistent? What if someone specifically wants to link to one over the other? Are we just going to enforce the preference by bot and remove it from enwiki? --Rschen7754 02:41, 3 September 2018 (UTC)
@Rschen7754: That actually seems to link to commons:Special:Search/Canada. This RfC is not about whether the links go to galleries or categories, and the bot would not enforce a preference. Thanks. Mike Peel (talk) 10:45, 3 September 2018 (UTC)
So then what is this RFC about? --Rschen7754 20:04, 3 September 2018 (UTC)
@Rschen7754: E.g., at Academy Awards, changing {{commons category|Academy Awards}} to {{commons category}} so that, should the commons category be moved to "Oscars", the link will automatically update rather than needing a manual fix. Thanks. Mike Peel (talk) 22:11, 3 September 2018 (UTC)
This isn't specific enough. Where does the category come from? The sitelink? P373? The article title? The label? etc. --Rschen7754 22:13, 3 September 2018 (UTC)
Currently, Commons category (P373), which is bot-updated when the sitelink to a category changes. I'd personally prefer to use the sitelink directly, but that would need the gallery vs. category question answered, so that's something for the future. Thanks. Mike Peel (talk) 22:49, 3 September 2018 (UTC)
Why didn't you say that at the start of the RFC? Here I am, a Wikidata admin, and I couldn't even understand what the RFC is asking. While I would support using P373, I am reluctant to support the RFC as is, because it is too vaguely worded and feels like I am signing a blank check. --Rschen7754 23:08, 3 September 2018 (UTC)
The saying here is that you can't see the forest for the trees... We're arguing about the technical details here, while most oppose statements are focused on Wikidata's apparent unreliability. Mike Peel (talk) 23:27, 3 September 2018 (UTC)
  • One difficulty has been that editors seem to have been discouraged from linking different Wikidata items to the same Commons category. This causes particular problems, in my experience. with articles about organisms that have more than one currently used scientific name and hence have multiple taxon name items in Wikidata (and articles under different names in language wikis).
Linking information in separate Wikidata items that are synonyms, of whatever kind, needs to be automated. Thus Platanus ×acerifolia (Q24853030) and Platanus ×hispanica (Q161374) are correctly linked to the same Commons category, currently called commons:Category:Platanus × hispanica. (Platanus × hispanica is the most widely used name, but is now thought not to be correct, the right name being Platanus × acerifolia.) However, Platanus ×acerifolia (Q24853030) and Platanus ×hispanica (Q161374) only link to the same commons category because I inserted the link manually, even though they are correctly said to be synonyms. This process needs to be automated in some way. The problem isn't limited to organisms; it arises whenever there isn't a simple 1:1 relationship between Wikidata items, language wiki articles, and Commons categories. Far too often it seems to be assumed that all such relationships will be 1:1, but this is simply wrong. Peter coxhead (talk) 10:30, 30 August 2018 (UTC)
@Peter coxhead: I can help automate that, but it probably needs some discussion first (e.g., shouldn't those two Wikidata items be merged? Or should they use said to be the same as (P460) or exact match (P2888)), perhaps post some more examples on my talk page or start a discussion at d:Wikidata:Project chat. Thanks. Mike Peel (talk) 22:17, 3 September 2018 (UTC)

A better way to handle headings with the same name

User:Amaury/sandbox/Test page.

As can be seen, sections A through Z all have the same sub-headings of 1, 2 and 3. If I make an edit to section 21.1 (Section U, Sub-Section 1), when I save it, it returns me to section 1.1 (Section A, Sub-Section 1). When there is more than one heading with the same name, from the second heading onward, there needs to be some way to make it unique within the URL or code—perhaps by adding additional characters or numbers in the URL, like the IDs on forums for posts, threads, etc.—go back to the right section. In addition to that, if I want to link someone to Sub-Section 1 on any section other than Section A, I can't, because User:Amaury/sandbox/Test page#Sub-Section 1 will just take people to section 1.1. Granted, my test is a little extreme, but for a more realistic example, see List of American Housewife episodes. Editing "Season 3" under "Ratings" will just take me to "Season 3" under "Episodes" once I submit the edit. Likewise if I link to "Season 3." Amaury (talk | contribs) 07:29, 7 September 2018 (UTC)

How about people start observing MOS:HEAD and not create headings with identical names? – Finnusertop (talkcontribs) 09:41, 8 September 2018 (UTC)
The MOS:HEAD point actually states exactly why the rule exists... which is because of technical limitations. (One might tease out that having no same headings is also a bit more accessible, but I don't know if that's per se true or not.) The ones Amaury is advocating could or should go away. However, it is not obvious to me that this would work to fill the contribution summary. --Izno (talk) 12:10, 8 September 2018 (UTC)
There already is a mechanism for making the section links unique - but it's invisible. Append a space and an integer from 2 upwards. Try out these links and compare their effects: User:Amaury/sandbox/Test page#Sub-Section 1 and User:Amaury/sandbox/Test page#Sub-Section 1 2 all the way down to User:Amaury/sandbox/Test page#Sub-Section 3 25 and User:Amaury/sandbox/Test page#Sub-Section 3 26. This is not really a VPR matter, more one for WP:HD. --Redrose64 🌹 (talk) 15:20, 8 September 2018 (UTC)
Or -- And I know that this is a radical proposal -- The WMF could take some of the 91 million dollars that they got on donations last year or the 113 million dollars they had left over from the year before and spend it fixing basic usability problems like the table of contents sending you to the wrong section. All it would take is a hidden variable; the first time someone names a header "Season 3" the software displays it as "Season 3" but stores it as "Season 3 0001" and stores the next occurrence of "Season 3" as "Season 3 0002", and the table of contents and the part of the software that returns you to a section after an edit would use the long version with the hidden variable. In my opinion, this would be a better use of the money than the 3.3 million they spent on travel expenses for Wikimania. I'm just saying. --Guy Macon (talk) 17:47, 8 September 2018 (UTC)
@Guy Macon: Please give an example of a page where the TOC takes you to the wrong section. --Redrose64 🌹 (talk) 20:27, 8 September 2018 (UTC)
I just tested it on my sandbox. I was wrong. Just using the table of contents works fine. Using the table of contents to go to a section and then editing the section brings you back to the wrong section, but that's not what I described above. Thanks for the correction. Also, posting a link to the second section doeasn't work. The reader ends up looking at the first section.
Still, coming back to the wrong section after an edit and not being able to correctly link to a section falls under "fixing basic usability problems". --Guy Macon (talk) 22:21, 8 September 2018 (UTC)
posting a link to the second section doeasn't work. The reader ends up looking at the first section. In my post of 15:20, 8 September 2018 (UTC), I gave four links. The second of these, User:Amaury/sandbox/Test page#Sub-Section 1 2 takes me to the Sub-Section 1 that is under Section B. It works as intended. --Redrose64 🌹 (talk) 09:38, 9 September 2018 (UTC)
phab:T2111 from 2004 is "Return to page after edit of section when section name occurs multiple times may point to wrong section". I agree MediaWiki should detect if it's the 2nd section by that name and automatically add _2 to the anchor like it already does in the TOC. PrimeHunter (talk) 11:17, 9 September 2018 (UTC)
@Guy Macon: That sounds... quite difficult. Mediawiki doesn't currently have the ability to store anything associated to a particular piece of content, afaict. It's all plain text, and when the user edits it, it's replaced by new plain text. Trying to attach permanent identifiers to headers would probably require making VisualEditor the only available editor and dropping wikitext, which I'm quite certain wouldn't be popular here. --Yair rand (talk) 19:51, 12 September 2018 (UTC)
As Redrose64 demonstrated above, Mediawiki already stores something that allows the table of contents to work correctly when two sections have identical names - identical in the wikitext and identical when the TOC is displayed.
Speaking as a person who spent years writing software and more years managing engineering project that included software, I am extremely dubious about arguments in the form of "yes, the behavior of the software sucks in this instance, but I just spent a whole 30 seconds thinking about it and concluded that it is too hard too fix because of our existing software". Many times, after I direct the person saying that to spend 4 hours writing up a plan for what it would take to fix the suckiness and a rough estimate of how many man-hours it would take, I get a completely different answer after the four hours is up.
There is an attitude around Wikipedia of putting up with minor annoyances and glitches rather than making the software excellent. This is a problem.
As of Saturday, 22 September 2018, 14:20 (UTC), The English Wikipedia has 34,538,616 registered users, 128,442 active editors, and 1,202 administrators. Together we have made 855,910,205 edits, created 45,912,924 pages of all kinds and created 5,720,583 articles.
If we made a tiny improvement to our software that, by removing an annoyance like coming back to the wrong section after an edit, reduced the time to spent creating the page (the total time, including every edit ever made to that page, every talk page comment, and all the time spent by multiple users checking the page for errors over its lifetime) by a single second per edit, that would be the equivalent of a single person working 40 hours a week for six and a half years.
As of the 2016-2017 fiscal year we had $91.3 million USD in revenue, $69.1 million USD in expenses, and $113.30 million USD in assets.[20] So we could easily afford to hire a few top-notch software developers to make improvements to our software.
Given the above numbers, in my considered opinion we should not put up with minor annoyances in our software. We should hire someone to fix them.
This of course assumes that fixing the suckiness is too hard for our staff developers to do, a claim that I find to be dubious. IMO They appear to be highly competent, but IMO hindered by management decisions (and we have had major changes in management since then, so this may no longer be the case). --Guy Macon (talk) 21:46, 12 September 2018 (UTC)
@Guy Macon: Mediawiki doesn't store anything about headers between revisions. The table of contents is regenerated from scratch after every edit. My point was not that this problem is unfixable or shouldn't be worked on (it really shouldn't be marked "Lowest" priority in Phabricator), just that your proposed solution really couldn't work. --Yair rand (talk) 22:53, 12 September 2018 (UTC)
The discussed issue only affects section edits to a section with the same name as an earlier section. That is a tiny part of edits at the English Wikipedia. It's more common at Wikivoyage according to Carlb at phab:T2111. Phabricator is the place to request changes to the MediaWiki software. T2111 shows this change has already been suggested many times. PrimeHunter (talk) 23:48, 12 September 2018 (UTC)
Please don't ask me to report anything at Phabricator. See User:Guy Macon/Proposals/CAPTCHA for what should be a high priority item that has sat unaddressed for 12 years. --Guy Macon (talk) 01:17, 13 September 2018 (UTC)

CC-BY 4.0 as default license in upload forms

I suggest that CC-BY 4.0 should be the default suggested licensing when using the upload forms in Wikimedia projects for own works, instead of the current CC BY-SA 4.0 license (example at Commons), sometimes with dual GFDL licensing (example: here at Wikipedia). The main difference would be that derivatives are not required to have the same license. Reasons for changing to CC-BY 4.0 are:

  • It is a more permissive license.
Derivative of medical imaging.jpg
  • It makes it much easier to combine and mix works. The combination of the two images at right, for example, would not have been possible at all if the images were licensed under let's say CC BY-SA 4.0 for the first one and CC BY-NC 2.0 for the other. However, if either was CC-BY 4.0 it would have been permitted. See WP:Adaptation for further information in this regard.
  • CC-BY is by far the most popular licensing for open access journals (see Directory of Open Access Journals - Journal license tab), and is similarly popular in databases (see CC: Data and CC licenses). CC BY-SA is therefore not compatible for inclusion in most open access journals, denying them free access to the sum of Wikimedia knowledge.
  • Most uploaders may very well be as willing to upload under CC-BY, but may not be familiar with the differences between having SA or not. The current upload form layouts thus make lots of works receiving a more restrictive licensing than necessary. Just because uploaders can upload under the most restrictive license Wikimedia has to offer doesn't mean they need to be presented with that option by default. Those who still want to put the additional SA restriction would still be able to actively choose so.
  • The currently suggested dual licensing with CC BY-SA 4.0 with GFDL such as here in Wikipedia (link to form) is actually incompatible in a strict sense (see Wikipedia section on this matter, and is also a lot of extra read for those who want to know what GFDL means, since it doesn't provide the short presentation as given in Creative Commons licenses (compare GFDL license page to the CC BY-SA 4.0 page. It would therefore be both easier for uploaders and more legally correct if we simply dropped GFDL from the default license suggestion. Again, those who do want to choose dual licensing for some reason would still be able to actively choose so.

I want to know if you agree with this suggestion, and we can then bring it to Wikimedia's legal team for review before implementation. I know the change is technically not that hard, since we only need to change the upload form layouts, not the licenses of any already uploaded works, nor the overall licensing of any wiki. I've started a vote on this issue in Wikimedia Commons. Please go to that page to join:

  • Commons:Commons:Village_pump/Proposals#CC-BY 4.0 as default license in upload forms

Mikael Häggström (talk) 20:38, 10 September 2018 (UTC)

  • Oppose: There are many great arguments against this proposal over at Commons that I recommend users read through. In fact, there was so much opposition that the nominator withdrew this from there. But there is a unique aspect of locally uploaded files here on Wikipedia that they didn't touch upon. Unlike Commons, which hosts educational content for all, Wikipedia hosts files for use on Wikipedia (unused files will be deleted, unlike necessarily on Commons). That's why, if I choose to upload locally, the default should be that my file remains free and can be used on Wikipedia even after someone has modified it. Under BY, I cannot include that condition.
A practical scenario: I upload a file on Wikipedia under CC-BY 4.0. Someone else downloads my file, edits it into a much prettier version, and uploads it on their website. I come across that enhanced version and would love to use it on Wikipedia instead of or alongside my original. I marvel at the picture – that even credits me by name – but to my astonishment I find out that it has been uploaded with the notice "All rights reserved, no re-use allowed". This can happen with a BY license, but not with BY-SA.
That's certainly not "the wiki way". While by contributing to Wikipedia I want re-users to benefit, I also want to accumulate a corpus of free works that stay free (after all, that's why text here is CC BY-SA and that's not going to change). At minimum, when I upload files locally, I want my files to also benefit Wikipedia in the event that derivatives are made. That's not too much to ask for, as the default position, which should also be intuitive for the casual contributor. If someone consciously wants to waive more rights, they are, of course, free to do so, but the default position should be that when you contribute to a free encyclopedia your contributions stay free. – Finnusertop (talkcontribs) 10:22, 12 September 2018 (UTC)
  • Oppose. One gives freedom to use derivatives, the other gives freedom to prohibit use. I think we have a valuable interest in the freedom to use. In particular we don't want someone cloning all of Wikipedia and making it difficult or impossible to bring improvements back here. Alsee (talk) 00:48, 17 September 2018 (UTC)
  • Oppose per Finnusertop. It's also wrong that contributors who use CC-BY-SA are not being asked. Bidgee (talk) 03:23, 17 September 2018 (UTC)

Watchlist pop-ups?

Might it be possible for the account Watchlist to implement pop-ups that summarize small revisions? Or even show a list of recent small revisions? That way we don't need to visit the article, look at the history, and do a compare. It'd be a nice time saver. Praemonitus (talk) 22:09, 11 September 2018 (UTC)

Add to Special:MyPage/common.js
importScript( 'User:Writ Keeper/Scripts/commonHistory.js' ); // Backlink: [[User:Writ Keeper/Scripts/commonHistory.js]]
Should be standard IMO. Not a pop-up but essentially the same, view diffs from watchlist without clicking through to the article. The limit is it only shows most recent edit and I agree it would be useful to show further back but no idea how. -- GreenC 22:42, 11 September 2018 (UTC)
Do you have navigational popups enabled? I noticed it's not in your common.js, but you can also install via Special:Preferences. What you described is mostly what I use the tool for. Killiondude (talk) 23:22, 11 September 2018 (UTC)
Thanks, I'll give those a try. Praemonitus (talk) 22:15, 12 September 2018 (UTC)

RfC: Proposal: make subjects actively in the news ineligible for GANs and FACs

Withdrawn: I've poorly worded the problem and proposal, resulting in comments and !votes whose rationales miss the point. The problem remains one that needs to be addressed, so I will reintroduce when I've better reformulated them. Curly "JFC" Turkey 🍁 ¡gobble! 00:32, 13 September 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal: WP:GANs and WP:FACs for subjects undergoing rapid changes (e.g. prominent politicians at the height of their careers) generally should be autofailed at GAN and FAC as inherently unstable. Curly "JFC" Turkey 🍁 ¡gobble! 00:19, 12 September 2018 (UTC)

Discussion (make subjects actively in the news ineligible for GANs and FACs)

Support as proposer: Yes, I'm aware such articles have been promoted in the past—let's not trip down WP:OTHERSTUFFEXISTS. I've thought this for a while, and wouldn't have submitted such an article myself. This most recently came up with the Doug Ford article, which I've contributed to but am not the primary editor:

  • Ford became premier of Ontario three months ago, and is the sort of personality that constantly makes news. What happens in the coming months and years will undoubtedly be the keystone to his bio—the article will expand and be reshaped as the RSes inevitably multiply.
  • Ford is a divisive personality, which has also led to instability in the article—earlier this year, we dealt with editwarring, sockpuppeting, and POV pushing, as well as heated debates on the talkpage. That was before he won the premiership—the article has since gone from an average daily readership of 59 hits to a 1265, and his actions have dominated Canadian headlines of late. More eyes will inevitably lead to more active editing—for instance, in the last couple days we've had everything from vandalism to the addition of entire new sections, as well as page protection.
    Not every such article will be so heated, but the principle remains the same—when a great number of changes are inevitable in the foreseeable future, the page is inherently unstable.

Having articles promoted to GA with this sort of timing only makes a joke of the whole article-recognition process—while every article is a "work in progress" and can be improved, subjects at the heights of their careers are so inherently unstable that they should be considered ineligible for promotion.

Please keep in mind that I'm proposing this for such articles in general—let's keep any issues with the Ford article itself at Talk:Doug Ford. Curly "JFC" Turkey 🍁 ¡gobble! 00:19, 12 September 2018 (UTC)

  • I would guess this RFC isn't necessary for FACs because there is criterion 1e. It is stable: it is not subject to ongoing edit wars and its content does not change significantly from day to day, except in response to the featured article process. You're proposing to change the similar criterion (5) in the GAC from Stable: it does not change significantly from day to day because of an ongoing edit war or content dispute. to...? --Izno (talk) 00:46, 12 September 2018 (UTC)
    • Izno: I don't have a proposed wording, but a lack of editwars and content disputes is not a sign of "stability". I suppose I'm looking for the sort of wording that implies the article is in some way "settled"—that is, edits tend to be copyedits rather than significant addition or reorganization of content. Curly "JFC" Turkey 🍁 ¡gobble! 02:47, 12 September 2018 (UTC)
  • Oppose I won't speak to FAs as I am not familiar enough with them, but GAs already have a stability criteria. Like most things it is left up to the reviewer to decide if they feel the article is stable enough for a review to be conducted. Also given the inconsistent timing of reviews (many wait months for a review) it is entirely possible that someone could be nominated and then before the review is picked up get in the news. The current guidelines work well enough. AIRcorn (talk) 02:08, 12 September 2018 (UTC)
  • Oppose. Echoing Izno and Aircorn, both FA's and GA's have stability criteria. Some articles might be in the news often simply because of the nature of the subject, but aren't necessary unstable. It should be up to the reviewers' discretion to determine whether the article is eligible for GA or FA status on a case by case basis. If the article is constantly updating 100 times a day, or is the subject of an edit war, I'd argue it's already ineligible for GA status right off the bat based on the criteria. For that reason, this ban is unnecessary. epicgenius (talk) 02:25, 12 September 2018 (UTC)
    • Aircorn, epicgenius: as has been pointed out at Talk:Doug Ford, the stability criteria at GAN refers to editwars and content disputes. The issue I've raised is of articles that will inevitably undergo significant expansion and reorganization. Curly "JFC" Turkey 🍁 ¡gobble!
      • @Curly Turkey: I think "significant expansion and reorganization" would need to be clarified. For instance, if it's a building in the planning stages or if it's a very active politician with frequent controversy, that would qualify as something that has significant expansion and reorganization. On the other hand, a building that's almost complete or a relatively non-controversial politician would probably not qualify as "significant reorganization". Otherwise I might get behind further clarifying the GA criterion. However, the FA criteria doesn't need to be clarified, because something like this would be automatically failed anyway. epicgenius (talk) 03:51, 12 September 2018 (UTC)
        • epicgenius: Would it really? Barack Obama not only was promoted, but made TFA on election day 2008. Curly "JFC" Turkey 🍁 ¡gobble! 04:12, 12 September 2018 (UTC)
          • @Curly Turkey: Yeah, and and also on August 18, 2004. That was a few days after Obama's article was promoted to FA status, and a few years before he was elected as POTUS. A more apt comparison would be Mitt Romney, whose article was promoted just a few days before the 2012 election. In any case, it's the maintenance of such articles that should be focused on, not the promotion. If the article doesn't meet the FA or GA criteria anymore, there's a review process for that. I also agree with Iridescent's comment below that being in the news often is not a sole indicator of being "ineligible". epicgenius (talk) 13:43, 12 September 2018 (UTC)
            • epicgenius: Do we want constant GARs and FARs for articles when we have a reviewer shortage in the first place? Of course, I'm talking about articles undergoing constant expansion—not simply "in the news". Curly "JFC" Turkey 🍁 ¡gobble! 20:27, 12 September 2018 (UTC)
    • I have always taken the stability criteria to be for the reviewers benefit. It is very hard to review an article if it is constantly changing. I would maybe support the addition of something simple as long as the reviewer has some flexibility when applying the criteria. Especially as the scope for this could be very broadly interpreted. Any current sportsperson, writer, academic or similar biography would fall under it as well. I disagree with Barkeep49 below. Just because something is ongoing does not mean it should not be a Good Article. I do spend some time going through old GAs and cleaning them up and there are many from TV shows through to science topics that are not kept up-to-date. They then fail the broad criteria so are easy to delist. There are also many more that are updated. It is just the nature of writing a live encyclopaedia. I also dislike adding too much to the criteria as the process itself should be kept as lightweight as possible. AIRcorn (talk) 07:24, 12 September 2018 (UTC)
  • Support as I like the idea that the bulk of a topic should be complete before getting featured article status. Like Aircorn I can speak to GA but not FA. An example of a GA which bothers me which is not a BLP and is not prevented over any reasonable interpretation of stable as currently defined at GA but has potential for long term decline is The Resident (TV series). We have here a series like to run at least 3 seasons, if not many more, meaning that the content that was present on the page when it passed GA is only a small portion of what will eventually be there. Maybe through careful stewardship it will stay at GA level - but maybe not. But in any event that designation is likely to stay there. There is absolutely no policy justification in how stable is defined at GA or in the explanatory essays to say that articles which will inevitably need major future expansion based on ongoing events should be failed as not stable. Not only that I'm not aware of any GA in the last 5 months (when I've examined at some level a huge percentage of GA reviews) where any definition of stable beyond "no current edit warring" has been used - not even on articles under AP2 GS. I'm not a huge fan of the wording of this current proposal but I think the spirit behind it is correct and appropriate for the kind of content the encyclopedia should feature and recognize. Best, Barkeep49 (talk) 02:33, 12 September 2018 (UTC)
  • Sorry should have linked in my original reply and it's DS not GS but I'm referring to the articles affected by the sanctions in this arbitration case. Best, Barkeep49 (talk) 02:52, 12 September 2018 (UTC)
  • Support, agree that it needs to be formalized and put in review guidance and not left solely for "reviewer's discretion" in order to strengthen quality of promoted articles. Reviewer's discretion will be needed to determine when to (not) apply the rule. Current guidance talks about edit wars, but I found keeping an article updated and balanced if the topic is continuing to evolve and change is a much greater and often neglected challenge. Renata (talk) 06:28, 12 September 2018 (UTC)
  • Oppose "Being in the news" does not by default entail that an article is unstable and both FA and GA have "completeness" criteria that cover the other use cases. Jo-Jo Eumerus (talk, contributions) 07:48, 12 September 2018 (UTC)
  • Oppose: the GA criteria reflect the actual present state of the article, not some hypotheticals. Just like we don't protect pages pre-emptively, we shouldn't fail GAs if we merely think there is going to be a problem with the current stability or completeness criteria. Both criteria are easy to demonstrate: has it actually changed on a day-to-day basis? Is it really missing something right now? If it passes now, pass it. If it doesn't pass in the future, Wikipedia:Good article reassessment is that way. There is a common sense element of nominations that needs to be followed, of course, but is impossible to spell out in full: don't nominate an article about a Super Bowl before or during the game, don't nominate an article about a person who is on their deathbed... we deal with a lot of bad "newbie" nominations and always find a way even if there isn't a rule for it. Let me end by noting that what might work for Doug Ford of Canada doesn't work worldwide. Do people living in dictatorships have to wait until their president-for-life has ended the "height of their career" in order to access a quality encyclopedia article about them? Heaven forbid. – Finnusertop (talkcontribs) 09:35, 12 September 2018 (UTC)
  • Oppose. Would this have prevented e.g. United States of America from becoming GA? If the rule were restricted to people, it won't completely solve the problem Curly Turkey is talking about (which does exist): a GA on a minor politician will become very out of date if that politician becomes much more prominent. I assume we're not banning GAs on anyone, no matter how minor, who might fall under this rule at some point in the future? The same problem would happen with minor sports figures who are still active. The rule wouldn't prevent the article from being as good as a GA or FA; it would just prevent the award of the status, but that would be demotivating for the editors working on the article, and I don't see there'd be any benefit. It would be better to take these articles to GAR and FAR once they start to decay. Mike Christie (talk - contribs - library) 11:14, 12 September 2018 (UTC)
  • Oppose. Being in the news doesn't make articles inherently unstable. We have current FAs on high-profile biographies such as Hillary Clinton, Taylor Swift, Elizabeth II, John McCain and Bob Dylan, and on high-current-interest topics as varied as Earth (and Moon), Antarctica, Diamond, BAE Systems and Germany. Provided there are people willing and able to monitor the articles to keep out the POV-pushers and cranks, there's no reason a current event article is inherently less stable than any other—Barack Obama was a FA for the entire duration of his presidency and India has been a FA continuously for 14 years, and the world has not come to an end. ‑ Iridescent 12:52, 12 September 2018 (UTC)
  • Oppose as a blanket restriction - articles about subjects "in the news" are not inherently unstable; this criterion should be reviewed on a subject-by-subject basis. I am the editor who nominated Doug Ford for GAN more than two months ago, at a time when the article was reasonably complete based on information available at the time. Many discussions about the article's content and development had recently concluded, the article was in a good and stable state, and it seemed that all of the editors who had participated in those discussions (including Curly Turkey, and other than some blocked sockpuppeteers) were satisfied with its state. I proposed nominating the article, there were no objections, and then I went ahead. Curly Turkey is definitely correct that Ford is a divisive and controversial politician, and with the fall session of the government getting started he is in the news and certainly dominating national headlines (e.g. our news in Prince Edward Island is "shit Trump did", then "shit Ford did", then local stuff about potatoes and roundabouts), so almost by the day there is new information to add. I say this doesn't make the article unstable, as long as the information is added responsibly and editors talk through disagreements, which we've set a precedent for on Talk:Doug Ford. I think this case is actually a good reason why we should not have such an automatic disqualification. Also per what Iridescent said. Ivanvector (Talk/Edits) 14:01, 12 September 2018 (UTC)
  • Oppose This is a fantastically bad idea. Articles should be assessed for such promotions based solely on the article content itself, not upon some random, blindly applied criteria. And there should be NO restrictions upon people who have valid, evidence supported contributions to make to ANY consensus-based discussions. That is, we should not tell people ANY article is automatically ineligible for FA or GA discussions, because that implies that any earnest and honest assessment they would make about the article quality is automatically rejected. No, no, no, a thousand times no. That's not how we do things at Wikipedia. Start the discussion. Assess the article on its merits. If consensus for that one article, at that one time that the article does not pass the criteria because it is not stable, then fine, lets have that discussion, lets make that the consensus. But we should not presume anything, and we should not tell people what they are going to think before they think it. If an article is part of a current event or in the news, just let people look it over and assess it honestly. If consensus is that article stability is not a problem, then promote the article. Nothing bad has happened because of that, in fact, the process worked exactly as intended. I grow weary of all of these rulesy people trying to pass a whole bunch of restrictions designed at preventing discussions from moving forward. That's so antithetical to how Wikipedia works. We don't have rules. We don't have laws. We discuss and improve and make decisions based on consensus. I don't (despite the insistence below) recognize any problem. This is not an issue of a wording problem. I think this would be a shitty idea in any wording. --Jayron32 15:12, 12 September 2018 (UTC)
  • Oppose. In an ideal world every article in the whole encyclopedia would be an FA. And vital articles, such as those about prominent leaders, even more so. Barack Obama was a featured article (as indeed was John McCain) on the very day of his first presidential election. And still is to this day. If the rapid editing leads to a deterioration in quality, then WP:FAR is right over that way. If it doesn't deteriorate, then all well and good.  — Amakuru (talk) 22:44, 12 September 2018 (UTC)
  • Oppose per Amakuru. I will add that the definition of "in the news" is a flexible one that is difficult to clearly define, and is thus likely in my opinion to lead to a major gray area which it is best to avoid. Display name 99 (talk) 23:48, 12 September 2018 (UTC)
  • Oppose In principle it is right, but we have have GAs on topics that still get coverage. What should be avoided is GA/FA of articles on topics that are in the current news due to some controversial element. This may not lead to edit warring but we should wait for the controversy to die down to best just how to cover it, as to make the article of GA/FA quality. --Masem (t) 23:53, 12 September 2018 (UTC)

Reboot proposal wording?

  • I'm seeing a lot of people recognizing the problem but opposing on the wording. The way this is going, the proposal will be trashed while a recognized problem goes unsolved. Perhaps some input here on how to improve the proposal? Curly "JFC" Turkey 🍁 ¡gobble! 11:29, 12 September 2018 (UTC)
    I think the problem you've identified is in the decay or failure to update the article, and not in the original promotion (so long as the stability criteria as they currently stand are followed). To me, that means the right answer is more active reassessment of articles of this type. Perhaps an internal category that tracks GAs/FAs likely to decay? An interested group could periodically review the contents of the category to see if a reassessment is warranted. Mike Christie (talk - contribs - library) 11:45, 12 September 2018 (UTC)
    There's an external tool which "grades" articles (e.g. WikiProject Canada GA-class articles), though I have no idea what is the background of the grading algorithm. That tool also lists the articles' assessment dates, so I suppose that info could be used to create a list of promoted articles which might be due for reassessment, or maybe that can be coded into the WikiProject banners to automatically populate a maintenance category. The problem then is that we're short on reviewers. Ivanvector (Talk/Edits) 14:06, 12 September 2018 (UTC)
    I think the last sentence is key. We are short on reviewers for new nominations already (GAN is perma-backlogged for example with articles from more than 9 months ago still awaiting review), so who will reassess old articles? This sounds good in theory but does not work without far more people participating in these processes and I don't see that happening. Regards SoWhy 15:40, 12 September 2018 (UTC)
    The DYK people cleared their backlog by requiring that each new nomination be coupled with the review of an outstanding nom filed by another person. In theory, this could also work for GANs; but it has been suggested that the requirement has led to the rubber-stamping of sub-standard DYKs simply to get the new DYK nomination into the queue. That would not be good for GAN. --Redrose64 🌹 (talk) 20:41, 12 September 2018 (UTC)
    DYK also doesn't have to deal with articles going immediately out of date. Curly "JFC" Turkey 🍁 ¡gobble! 22:22, 12 September 2018 (UTC)
  • I'm seeing a grand total of one person "recognizing the problem but opposing on the wording", and near-unanimous consensus that unilaterally deciding that certain classes of articles should be excluded from Wikipedia's usual assessment processes just because you disagreed with the GA nomination of a single article is a terrible idea. Have you actually got any, like, evidence to support your core assertion that subjects actively in the news [are] inherently unstable, or are you just assuming that because you saw an edit war on one article you can extrapolate that to every other article? How are you even proposing to define "subjects actively in the news" in a way that wouldn't exclude every country and major city, every living artist, performer and writer, every active politician and probably every single BLP, every major animal species, every "broad concept" article like Sea or Planet, every scientific field in which new discoveries are being made (which is all of them)…? What you're essentially proposing, whatever form your final proposal takes, is that Wikipedia not cover anything that's the subject of any controversy, and whatever form that proposal takes it will be mutually contradictory at the most basic level with Wikipedia's key principles. ‑ Iridescent 17:05, 12 September 2018 (UTC)
    I agree with much of this, but it's not really fair to Curly Turkey to say they're proposing that Wikipedia not cover these topics; the proposal only says they cannot be FA or GA. Mike Christie (talk - contribs - library) 17:51, 12 September 2018 (UTC)
    Iridescent isn't the first to suggest that I'm saying we shouldn't cover these articles, and I don't know where this interpretation is even coming from.
    "just assuming that because you saw an edit war on one article ..."—again, nothing like what I've suggested, so how am I even supposed to reply?
    The issue isn't "controversy", but articles that are in a current state of rapid expansion. "In the news" wasn't the best way to express what I was trying to say—Led Zeppelin is "in the news", but obviously (I would hope) not what I'm driving at. The Doug Ford article will be undergoing significant changes in the coming months and years. Should it be subject to WP:GAR quarterly or something to ensure it's still up to snuff? And that's the difference—it's reasonable to assume Led Zeppelin will remain within spitting distance of the article that was promoted even years after its promotion. It's a matter of fact that Doug Ford cannot, because key features of the article's content are being generated right now and will continue for the foreseeable future. Curly "JFC" Turkey 🍁 ¡gobble! 20:23, 12 September 2018 (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.

Special:CreateAccount

At Special:CreateAccount a link labelled (help me choose) directs a person to the Username policy. I would like to know how many people have actually read through the page and or found it useful/helpful when they first registered an account. — fr+ 08:07, 14 September 2018 (UTC)

I did not, for one.But, have anyone ever felt that the persons in these help-videos are a bit err........weird......? With all due respect to the prosucers and those in the videos, can't the video-makers choose folks from the median-class? WBGconverse 08:48, 14 September 2018 (UTC)
Neither did I for that matter, which is why I asked. I did find the people in the video to be a bit weird but to be fair, those were probably not designed keeping the Indian middle class in mind.Face-smile.svg — fr+ 11:26, 14 September 2018 (UTC)
@FR30799386:--Iridescent's opinion over here is interesting :-) WBGconverse 12:46, 18 September 2018 (UTC)
I always found that link odd. It would be better if some guidance were offered directly on the account creation page. Regards SoWhy 16:50, 14 September 2018 (UTC)

Deprecating GFDL

Wikimedia Commons has officially deprecated the GFDL and will no longer allow images licensed under just the GFDL after October 15. I'm not sure how I feel aboutt his change, but I think we should make the corresponding change here too - we should not accept a "free license" that is not accepted at Commons. (The only "free" files we accept that Commons does not are files that are public domain in the US, but not in their country of origin.) --B (talk) 13:42, 14 September 2018 (UTC)

  • Comment: we should not accept a "free license" that is not accepted at Commons begs the question – why not? Shouldn't we accept all licenses that meet WP:C? – Finnusertop (talkcontribs) 14:08, 14 September 2018 (UTC)
  • Comment: Please note that GFDL has been deprecated for most, but not all types of files. Copying stuff from a GFDL-licensed software manual to Commons is still possible, for example [21]. --El Grafo (talk) 14:11, 14 September 2018 (UTC)
  • This can lead to an absurd situation where the file that has been released under a free licence is being uploaded under fair use. Facepalm! Gone Postal (talk) 14:22, 14 September 2018 (UTC)
    Not really, any local Wikipedia could decide to continue to allow GFDL-only photos. {{PD-USonly}} isn't fair use either. If this passes, well yes, but that's theoretical. Most GFDL-only photos and the like are own work. That would hardly if ever meet the non-free content criteria. Alexis Jazz (talk) 14:24, 14 September 2018 (UTC)
    Let's say File:Reham Khan memoir.jpg were licenced under GFDL, are you telling me that magically it would no longer be allowed as fair use and would be disallowed because of the "deprecated" licence? How does any licence make fair use not legal? Gone Postal (talk) 20:41, 14 September 2018 (UTC)
    @Gone Postal: Commons allows an exception for things extracted from GFDL-published software manuals and the like. Is there anything else that you can think of that would be acceptable for fair use under our policy and would ever be published as GFDL? People out in the non-Wikipedia world occasionally publish things with Creative Commons license, but they never publish under the GFDL. The idea is that if we're uploading our own photos, we will upload them under something freer than the GFDL. Nobody outside of the wiki-universe is creating GFDL images. --B (talk) 15:10, 14 September 2018 (UTC)
    If people never publish under GFDL, then what is the purpose of discussion at all? To resolve the problem that doesn't exist (I actually agree with that assessment). The truth of the matter is that there are cases where GFDL is used, and any file that is under fair use right now could theoretically be published under GFDL by copyright holder. Gone Postal (talk) 20:41, 14 September 2018 (UTC)
    Aside from people publishing documents for GPL software (which is a permitted exception under the new Commons policy), the only people who publish anything under the GFDL are people who contribute to wikis. So we're going to simply say you can't do that any more - if you want to contribute to Wikipedia, you need to license your content under an acceptable Creative Commons license. Your concern that you expressed was what if there was something that might otherwise be acceptable under our non-free content policy but was published under the GFDL and my contention is that no such content exists or ever will exist. --B (talk) 21:29, 14 September 2018 (UTC)
    And that is my point as well, the anti-GFDL crowd seems to be hiding their head in the sand pretending that fair use is somehow better than GFDL. And simply disallowing somebody from uploading a file under GFDL and forcing them to upload it as fair use is not a proof that you are correct, in fact it is an admission that you know how wrong you are, since you would be forced to delete the free file just so that nobody is noticing the glaring problem. Gone Postal (talk) 12:44, 15 September 2018 (UTC)
    Well lets assume after October and if en Wiki followed Commons path, someone finds or has a photograph of a living person (or recent) licensed under a GFDL, then it can't be uploaded under fair-use (since it is assumed that a "free-use" photograph exists, since it does but just not recognised by a few contributors). Why is it that a few are so interested in "re-users" yet they totally disregard the uploaders who contribute, in fact excluding them from the policy discussion by not informing them of it, while GFDL is still recognised as a "free-use" license. Bidgee (talk) 14:17, 16 September 2018 (UTC)
    GFDL is virtually nonexistent outside of wiki and software manuals. And the same arguments can be used to advocate allowing CC BY-NC and BY-ND on Wikipedia. Alexis Jazz (talk) 15:31, 16 September 2018 (UTC)
    Could you stop including NC and ND into the GFDL which is just a FUD, yes a very small number of users had included NC but that is a different matter that should be discussed separately, GFDL is still a "free-use" license that I have seen used outside of Wikipedia/Wikimedia that wasn't text form. Bidgee (talk) 03:34, 17 September 2018 (UTC)
    @Bidgee: "GFDL is still a "free-use" license that I have seen used outside of Wikipedia/Wikimedia that wasn't text form." Pics Links or it didn't happen. And nothing that's over 10 years old. Alexis Jazz (talk) 13:09, 17 September 2018 (UTC)
  • Support (as the proposer of the proposal on Commons) GFDL for photos is/was mostly used as a Creative Commons NonCommercial backdoor. Textbooks, software manuals and (as El Grafo already mentioned) logos, diagrams and screenshots extracted from such a manual are still allowed. Alexis Jazz (talk) 14:24, 14 September 2018 (UTC)
  • Comment As background, the rationale for the change on Commons is that GFDL, as a sole licence, is now only used (and it is only occasionally used) as a backdoor "CC -NC" because of the burdens it imposes on reuse outside of Wikipedia. Wikipedia:Copyrights doesn't say anything about what licences are acceptable. Wikipedia:Image use policy simply links to Wikipedia:File copyright tags for "a list of possible licenses which are considered "free enough" for Wikipedia". That page offers two lists. One is a link to Wikipedia:File copyright tags/Free licenses and the other is titled "For image creators". Not entirely sure why we need both. Anyway, Wikipedia:File copyright tags/Free licenses list already discourages GFDL (because of the burden to reproduce the entire text of the GFDL when reusing) but it also states a falsehood: "If one include any of the content, the entire book/section goes under GFDL, unlike CC-BY-SA". That is garbage and should be removed. What might help here is for that section to have similar guidance to Commons about GFDL/GPL no longer being accepted. Further, the "For image creators" of Wikipedia:File copyright tags probably shouldn't list anything other than CC, FAL and PD. For PD it should suggest CC0 as well as PD-self as the former is more useful internationally and better thought out. I don't think obscure licences, licences designed for software and software manuals, and home-made ones like "Copyrighted Free Use" should be listed at all. But more generally, users should be more strongly encouraged to upload to Commons instead. -- Colin°Talk 14:43, 14 September 2018 (UTC)
  • Oppose if commons does not permit it, then it is good to have somewhere else to load it for use. The reason for not hosting on commons is extremely weak, as the licensing requirements are the problem for the reuser, and as long as we comply, which I believe happens, then it is OK, and potentially useful. We can discourage the license use, and encourage a CC license. But that can only be done if the material is not already under the GFDL. Graeme Bartlett (talk) 05:38, 15 September 2018 (UTC)
    This argument is also valid for CC BY-NC, BY-ND and promotional images that can be shared free of charge. Alexis Jazz (talk) 15:31, 16 September 2018 (UTC)
  • Comment I am on a fence here. If common is not gonna allow it then why we should allow? That argument is as strong as the argument of Graeme Bartlett that if commons is not allowing it then it should be uploaded somewhere else. I think that advantages and disadvantages should be laid out. If I ever plan to upload an image, I would use upload it to Commons. Kraose (talk) 05:44, 15 September 2018 (UTC)
  • Commons can be a bit idiosyncratic. I agree that Commons is the best place to upload, but aggressive deltionists there can make it difficult. Graeme Bartlett (talk) 01:47, 16 September 2018 (UTC)
  • Support as per Alexis above. --Yann (talk) 13:11, 15 September 2018 (UTC)
  • Support with same caveat from Commons (as explained in their discussion there): material taken/extracted from software/manual/textbooks already under GFDL can remain licensed GFDL, but users otherwise should not be submitting any other type of content as GFDL to the onus on reuse. --Masem (t) 13:22, 15 September 2018 (UTC)
  • Support per Alexis. Thanks. Mike Peel (talk) 13:34, 15 September 2018 (UTC)
  • Oppose We allow, without discrimination, licenses that meet the Definition of Free Cultural Works 1.0 (WP:C). GFDL meets this definition [22].
  • People who are calling it a "backdoor NC" license are missing something. There is nothing inherent in commercial activity that precludes reusers from observing the terms of the license. I can print a GFDL book – and either sell it or give it away. I can host a GFDL website – and have it either open to all or behind a paywall. Just because it costs some extra to print or host 7 pages does not make it a NC license any more than a BY license is NC because attribution requires some extra ink! – Finnusertop (talkcontribs) 14:07, 15 September 2018 (UTC)
    • It's more that it's a "strong copyleft" license. I write commercial software and, as most people do now, I have a desire to use open-source libraries from time to time. I can't use anything that is GPL because it would require that I, in turn, release my software under the GPL (which I'm not going to do). Does that mean that GPL isn't a free content license? Of course not - it just means that it isn't useful to me in my needs. For good, bad, or indifferent, Wikimedia Commons has decided that it is going to deprecate the "strong copyleft" GFDL and only allow licenses that would be useful to a wider variety of re-users. That doesn't mean the GFDL isn't a good license with a good purpose - it just means that Wikimedia Commons is looking to host media that is useful to a wider variety of re-users, including commercial users who don't create GFDL websites. I don't know that I agree with this decision, but I also don't think that it makes sense for the English Wikipedia to have a different definition of "free content" from what Commons has. --B (talk) 14:21, 15 September 2018 (UTC)
    @Finnusertop: I'm calling it a "backdoor BY-NC" (I think I was the one who came up with that, but I'm not sure) because GFDL-only for photos was afaik used exclusively to upload photos with a CC BY-NC license. But a BY-NC license is not allowed so the photographer also tacked on a GFDL license, knowing full well nobody will be interested in using that. Alexis Jazz (talk) 15:31, 16 September 2018 (UTC)
  • Oppose it is certainly free culture, just as a licence that requires attribution to all down-users is free. We should not handicap Wikipedia from being useful with free culture, because some down users (or Commons) may not find it useful. We do not handicap Wikipedia from being useful with even 'fair use/NFCC', we should be even more loath to do so here with something that is freely-licenced. Alanscottwalker (talk) 14:29, 15 September 2018 (UTC)
  • Oppose Given the caveats, I don't see this as having much effect, but per Graeme Bartlett it would be useful to allow upload here. Hawkeye7 (discuss) 02:23, 16 September 2018 (UTC)
    @Hawkeye7: dare Graeme Bartlett to present a real-life example that isn't over 10 years old or a photographer trying to hamper commercial re-use. Alexis Jazz (talk) 15:31, 16 September 2018 (UTC)
  • Oppose per Graeme Bartlett. Sadly the Commons GFDL restriction was part by a few who also want to remove CC-BY-SA as a default license and replace it with CC-BY, what next! Bidgee (talk) 07:04, 16 September 2018 (UTC)
  • If you think so, and that would make the supporters saying that GFDL is being used as a -NC backdoor argumentum ad hominem. Bidgee (talk) 14:02, 16 September 2018 (UTC)
  • Oppose per Graeme Bartlett. Having more licensing options is beneficial to Wikipedia as it encourages more people to upload images.  pythoncoder  (talk | contribs) 15:54, 16 September 2018 (UTC)
  • Comment I think a point to stress from the Commons argument is not to disallow GFDL but where users have a choice of licensing (such as their own photos) to disallow the use of GFDL as such a license. If there is material that already exists that is appropriate to use and it is only under GFDL, there's no reason to not accept it, but this is primarily only going to be software and related materials. GFDL is not a license people use for their photos or other works that are not software related. --Masem (t) 16:03, 16 September 2018 (UTC)
    • Well the decent and human response when someone gives something away, is just to say 'thank you.' Alanscottwalker (talk) 17:49, 16 September 2018 (UTC)
      • GDFL is a burden to re-users (as the whole 7 page license is supposed to be attached with any use), just as CC-*-NC or CC-*-ND does. We want our free media to be reasonably reused, so we want uploaders , if they have a choice, to use one that minimizes the "harm" for reusers. If the work to be added already pre-exists as GFDL, then we have to accept it, but most of our free works created by editors are photographs, drawings, or the like, and these clearly benefit better from being in PD, CC-BY, or CC-BY-SA. --Masem (t) 00:53, 17 September 2018 (UTC)
          • What we want is the best reference work possible. People should feel free from now on to upload whatever encyclopedic work of thier own they want to right here, using GFDL even, and avoid the ungracious others, who act as if they wish to shove people around about how they give things away, and we will use it because it makes the knowledge of the world better (at least, that's our mission). This proposal reminds me somewhat of the times one gets a few people who argue we should disallow books as references because they are not online or not free access online (no, that is not what we are here for, it's just wrong) -- Alanscottwalker (talk) 18:36, 17 September 2018 (UTC)
            • Ungracious? GFDL was simply never designed to license photos. How about I call you ungracious for not accepting CC BY-NC material? You would gain a lot if you did. GFDL on the other hand will get you pretty much nothing. In the future another photographer may stand up who doesn't want their photos to be used outside Wikipedia. That's all you can get. To my knowledge, there was only one really active photographer left on Commons (a few years ago we had more) who used GFDL (combined with CC BY-NC). And guess what, he was only doing it out of protest, going so far as to recommend this license to anyone who was looking for a noncommercial/Wikipedia-only license. That is what you are really voting for. No sane person uses GFDL-only for photos nowadays, unless they want to hamper commercial use. Alexis Jazz (talk) 20:08, 17 September 2018 (UTC)
              • There's still the case of illustrations from books that are GFDL. Hawkeye7 (discuss) 21:04, 17 September 2018 (UTC)
                • Which would still be allowed under this proposal. The way I read this proposal, assuming "you" are the person that wants to upload material.
                  • If "you" are not the creator of the material, and it already exists in a GFDL form (which 99.9% is going to only be software, manuals, textbooks, and materials extracted from those), then we'd still accept it (just as Commons would too)
                  • If "you" created the material, then you should not use the GFDL for that material, but instead PD or CC-BY/CC-BY-SA.
                • GFDL is not being banned, just only where we don't have an option to use something else that is less restrictive for our readers. --Masem (t) 21:44, 17 September 2018 (UTC)
                  • You've lost me. What's the difference between us not accepting it and it being banned? I note that our current "recommended" licence in the Wikipedia upload wizard is currently CC-BY-SA 4.0 + GFDL. Hawkeye7 (discuss) 21:55, 17 September 2018 (UTC)
                    • @Hawkeye7: dual licensing will still be fine. As long as there is also an accepted license (like CC BY-SA) it's fine. The difference would be that a ban would prohibit all of its use. The proposal only prohibits using the license for material it's not even suited for. Oh, and illustrations from books.. Show me some GFDL-only licensed books that were released in 2018? Here's what I found: Introduction to Ethical Studies (2003), Reading for Philosophical Inquiry: A Brief Introduction to Philosophical Thinking (2004, but already dual licensed with CC BY-SA), A First Course in Linear Algebra (2004, last update in 2010.. no pictures though), Linear Algebra (2012, but also CC BY-SA dual license). Alexis Jazz (talk) 23:53, 17 September 2018 (UTC)
  • Oppose per Graeme Bartlett and others. It's not uncommon that different projects use different standards, e.g. de-wiki does not allow FU at all despite German law not applying to a site hosted in the US. If there are problems with GFDL for newly created content, we can address this by asking people who upload their own works to do so at Commons where they will not have the option to select GFDL anymore. Oh, wait, we already do that. So what is the problem? If someone really creates something and wants to use a GFDL-license, we should allow them to do so because the alternative is not having that creation at all. Regards SoWhy 13:23, 17 September 2018 (UTC)
  • Why the Wikimedia projects should not use GFDL as a stand alone license for images. Why did I forget to link Notafish? This was written already back in 2005. All the opposers should read it. Some also referred to Freedom defined. https://freedomdefined.org/Licenses#Intended_scope is trying to tell you the scope is "Documentation", https://freedomdefined.org/Licenses/GNU_FDL_1.2 tells you the license was created "in order to be used for software documentation". It was never meant for photos. Alexis Jazz (talk) 23:53, 17 September 2018 (UTC)
Read it. Not persuasive. So, some down user may not like the licence, and some down user may not like an attribution licence, and some down user may not like fair use. None of what the down user may not like has anything to do with building the pedia -- the down user by definition is not building the pedia, they are doing something else with it. Furthermore, it remains an image is a document. Alanscottwalker (talk) 11:31, 18 September 2018 (UTC)
I'm so sorry, I'm a complete idiot! Thank you for sharing your wisdom. I'll contact Merriam-Webster, Collins and Oxford right away so they can update their definitions! Alexis Jazz (talk) 16:04, 18 September 2018 (UTC)
You think of yourself as an idiot? That's too bad, but no need to contact anyone about that. Alanscottwalker (talk) 16:12, 18 September 2018 (UTC)
The WMF's entire free content policy is aided to serve the downuser or repurposer in this case (that's why SS-BY-ND or -NC is not allowed as a "free" license). We do have certain expectations on content creators outside of licensing that we expect them to follow too, such as no watermarks on photographs or images that they freely provide (so that downusers can use these with even more freedom), there is no issue with telling content creators that want to provide material not already under a license to not use the GFDL to remove restrictions on downusers. --Masem (t) 16:19, 18 September 2018 (UTC)
We are not the WMF, Wikipedia's purpose is and always has been building the encyclopedia -- thus, Wikipedia allows even non-free content to be hosted, and GFDL is free content. Alanscottwalker (talk) 16:30, 18 September 2018 (UTC)
Limited non-free content, and where possible, using free content over non-free. That's a directive all WMF projects must comply by. Now granted, judging the GFDL to be less-freer than CC-BY (principally by placing an undue onus on reusers to include the full GFDL on reuses, but otherwise not restricting reuse/derivative rights) is probably up to the individual projects, but logic of why follows with the WMF's goals for all projects, to create works that can be reused and repurposed anywhere without restrictions. Non-free is only allowed where it meets the educational purpose and we don't have any other way to do that with free content. Asking users to use a more free-er license than the GFDL seems wholly appropriate to do within that purpose. --Masem (t) 17:09, 18 September 2018 (UTC)
  • Oppose - Commons is its own little cult with their own extremist rules about licensing (and a law-of-the-jungle culture of vendetta-motivated deletion). Their decisions are their own, and they can live with the consequences. English Wikipedia is not Commons, nor should it aspire to be. There is no legal defect with the GFDL and its acceptability should be maintained. Carrite (talk) 16:58, 20 September 2018 (UTC)
@Carrite: I'm not going to argue with your first points. A part of Commons is downright sick. Not gonna argue about that, you're just right. What I do argue about is "There is no legal defect with the GFDL". The GFDL is a perfectly fine license for books and manuals. It was never designed for individual photos. It wasn't even designed for anything on webpages! It causes huge problems if you want to comply with the license outside of the original scope: documentation for freely licensed software. Wikipedia:Licensing update wasn't just for kicks. Alexis Jazz (talk) 21:46, 21 September 2018 (UTC)
  • Oppose - It makes no sense to allow fair use but forbid the GFDL, the founding free license of this project. Jonathunder (talk) 21:59, 20 September 2018 (UTC)
@Jonathunder: You're 9 years too late, GFDL-only text from third parties was already banned on Wikipedia in 2009. Alexis Jazz (talk) 21:46, 21 September 2018 (UTC)

New proposal / Wikipedia:Naming conventions (books) / Standard disambiguation

In substitution of:

"To disambiguate, add the type of literary work in parentheses, such as "(novel)", "(novella)", "(short story)", "(short story collection)", "(dialogue)", "(essay)", "(play)", "(poem)", "(poetry collection)", etc. If none of these specific qualifiers applies, "(book)" can be used. Note, however, that this qualifier may be perceived as indicating a non-fiction type of writing.

If further disambiguation is needed, add the author's surname in parentheses: "(Orwell novel)", "(Asimov short story)", etc. In this case it is not advised to leave out the qualifier of which type of book it is, unless completely redundant, which may happen for some non-fiction books like Histories (Herodotus) and Histories (Tacitus). Additional examples:

I propose the following:

"To disambiguate two literary works add the author's name in parentheses.

Examples for Night and Day:

In case of the same autor has two works with the same title add, folowing of the author, the type of literary work, such as "(novel)", "(novella)", "(short story)", "(short story collection)", "(dialogue)", "(essay)", "(play)", "(poem)", "(poetry collection)", etc, or "(book)" if none of these specific qualifiers applies."

The reason of the proposal is because it is simpler, privilege the Author and work well in any circumstance (except in case of two works of the same Author). Then, there are works in which it becomes difficult to classify them as to their nature. And, if in the title of the article of an artistic work it isn't necessary, nor obligatory, the indication of its nature, why must its classification be included when it is a question of disambiguation?
I must note that I made a similar proposal at the Wikipedia in portuguese, and so far the six editors that had commented were against it. Namely, without being exaustive, because the focus should be at the art work, not at the author, because the proposal cause confusion, insted of the current explicative title type, because of the exception of two works with the same title by the same Author, because that could create confusion with other media, for instance in the case of Solaris (Stanislaw Lem) and Solaris (Andrei Tarkovsky), because of the need of standardization, and because if this proposal would be applied to the movies titles, for instance with the title The Three Musketeers, this would create a great confusion.
Nonethless, I don´t think these problems may occur, and I mantain that a title as Ulysses (poem), or Ulysses (novel), is less rich, less artistic, than the proposed Ulysses (Alfred Tennyson), or Ulysses (James Joyce).
At last, shouldn't it also be better for Wikidata, in general, have titles in the form of: Art work title (Name of the Author)? GualdimG/JMdosPerais 21:09, 15 September 2018 (UTC)
Other than concerns mentioned in the proposal itself, my main problem with this is that it makes the titles unnecessarily longer. TeraTIX 23:24, 20 September 2018 (UTC)

bays/inlets

What is the difference between a bay and an inlet ? I suggest Category:Inlets by country should be merged and replaced by Category:Bays by country. This probably this needs to be discussed, but I don't know where to ask. --Io Herodotus (talk) 05:05, 17 September 2018 (UTC)

Our articles, bay and inlet describe them as mostly different. Rmhermen (talk) 06:58, 17 September 2018 (UTC)
OK And what is the difference between a gulf and an inlet ? A gulf is an inlet. It's often difficult to know where the differnce is. Is Khawr al Udayd a bay or a gulf ?--Io Herodotus (talk) 07:32, 17 September 2018 (UTC)
Try our article on gulf maybe? --Izno (talk) 12:02, 17 September 2018 (UTC)

Language is not mathematically precise so this causes problems for computers attempting to categorize along a boolean form (bay or not-bay). In these cases one typically maintains multiple categories and follow the cultural naming conventions. For example, Facebook has a few dozen options for gender choice (this list is outdated more have been added), but they generally don't have an "other" option as they can't do much with that in terms of targeted advertising. Likewise with bays and inlets, how its called depends on the end-user preference (the place name convention). -- GreenC 14:56, 17 September 2018 (UTC)

  • Not sure why this is here instead of WP:RDL or WP:RDH, but since we've started here, lets finish here. The difference is that Bays are those bodies of water that people have named "Bay" and that inlets are those bodies of water that people have named "Inlet". The names are not mutually exclusive or even self-consistent, that is there are very different kinds of bodies of water named "Bay", that share little in common except being "bodies of water". Consider the difference between Opechee Bay and the Bay of Biscay. There are some general trends; Bays are generally only partially enclosed, that is being surrounded by wide, long arches of coastline, with a headland on each end (see, for example Bay of Biscay or Onslow Bay). Particularly deep bays are sometimes called a "bight", see Heligoland Bight or Great Australian Bight. An inlet, by contrast, is usually a cut through a barrier island which connects a sound, lagoon, or estuary to the ocean, like for example Jones Inlet or Oregon Inlet. Gulfs are also just bays, some people try to say that gulfs are particularly narrower than Bays, but not always (compare Gulf of California to Gulf of Mexico. Ultimately, they are just words, they all mean "a body of water", and words are fuzzy. There's some trends you can learn, but with anything like this, you should never be surprised when you find outliers whose name does not match the expected definition that closely. --Jayron32 16:43, 20 September 2018 (UTC)

Non-admin 'delete' group

Nothing new is being proposed, and not happening for the same reasons. Alex Shih (talk) 18:54, 17 September 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

This is my big proposal today. I have seen huge speedy deletion backlogs and AfD backlogs many times. Here is my proposal. My proposal is that non-admins are able to access the 'delete' tool. The 'delete' tool will only be available to highly-trusted users and can only be given at WP:PERM. This tool will also help fight vandalism in a way that bad pages will be deleted on sight on Huggle and when they enter the speedy deletion log. This 'delete' group and rollback together will help fight vandalism quickly. I had read Wikipedia:Requests for comment/Proposal to allow non-admin deletions for XfD and I was disappointed that it failed. Trusted non-admins should have the right to delete pages and clear speedy deletion logs without having to pass a RfA. Also, the speedy deletion backlog is sometimes huge. This is especially going on with things like drafts which are being deleted under CSD G13 and uncontroversial deletions under CSD G6. However, others also get big backlogs too as well. If this gets approved, users with this tool will be able to the following:

  • Delete pages (delete)
  • Mass delete pages (nuke)
  • View deleted history entries, without their associated text (deletedhistory)
  • View deleted text and changes between deleted revisions (deletedtext)
  • Undelete a page (undelete)

I feel users have to have 6 months to 1 year of editing, at least 3,000 edits and plenty of experience at any of the deletion noticeboards and speedy deletion. The user who is requesting the 'delete' right should not be a vandal. This right may be given through WP:PERM to trusted users by an administrator and it can be revoked if abused. I would like to know what you think. I don't expect this to succeed but there is no problem having a go with this proposal. I have a huge CSD log myself and I know many other users have big CSD logs that will certainly benefit from this tool. Pkbwcgs (talk) 18:23, 17 September 2018 (UTC)

Addition to this proposal - users with this right can view deleted pages. Pkbwcgs (talk) 18:40, 17 September 2018 (UTC)
  • Strong oppose for all the previously stated reasons why these tools cannot and should not unbundled, including but not limited to the WMF legal team requiring RFA or a similar process before access to delete pages and see deleted pages. This proposal does not address any of the previous objections. Regards SoWhy 18:31, 17 September 2018 (UTC)
    Also, and this is my strongest reason: I cannot think of any user who can both be trusted enough to delete pages and not be trusted enough to protect them or block users. But I can think of a lot of users who meet those requirements who I would never ever trust to delete pages. Regards SoWhy 18:44, 17 September 2018 (UTC)
    @SoWhy: Protect and block are core admin tools. Delete is also a core admin tool but users who have done loads of work in the deletion area should get this right. Obviously, it wouldn't make sense to have block and protect as separate rights. However, it makes sense for experienced non-admins to be able to access delete. Pkbwcgs (talk) 18:48, 17 September 2018 (UTC)
  • Oppose per SoWhy: the ability to view deleted text should not be unbundled from the ability to delete pages. That cannot happen without RfA, so therefore the ability to delete should not happen without RfA either. TonyBallioni (talk) 18:34, 17 September 2018 (UTC)
    Oppose the addendum as it doesn't get the point of these opposes: viewing deleted text and revisions is the core ability of sysops as far as the WMF is concerned and is the reason RfA is required before getting +sysop. TonyBallioni (talk) 18:43, 17 September 2018 (UTC)
  • Oppose allowing people to delete pages without being able to see deleted revisions strikes me as a very bad idea. --SarekOfVulcan (talk) 18:36, 17 September 2018 (UTC)
    (response to change in proposal) You can't view deleted revs without an RFA-equivalent process. --SarekOfVulcan (talk) 18:42, 17 September 2018 (UTC)
  • Oppose - generally speaking, the WMF will not allow access to view deleted content except for users who have gone through RfA or a community vetting process similar to RfA. AFAIK the Foundation hasn't said anything about allowing non-admins to delete pages without being able to view pages once they're deleted, but that creates an additional backlog problem for admins who would need to also scrutinize non-admin deletions, on top of scrutinizing CSD tags. This proposal doesn't reduce the backlog, it just splits the backlog into two separate queues. Ivanvector (Talk/Edits) 18:41, 17 September 2018 (UTC)
    Oppose the addendum as well - non-admin access to deleted content is a non-starter. It's not up to us. Ivanvector (Talk/Edits) 18:42, 17 September 2018 (UTC)
  • Oppose on legal grounds, as stated by others above. 331dot (talk) 18:51, 17 September 2018 (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.

RfC: Notify pending-changes reviewers during large backlogs

Should random pending changes reviewers be notified when the backlog is too large? Enterprisey (talk!) 07:25, 18 September 2018 (UTC)

The pending changes backlog sometimes grows to over 20-30 pages, some of which have been waiting for over a day. This situation is not ideal because there are over eight thousand editors who could take care of them. Thus, a bot should be written to notify pending changes reviewers (PCRs) when the backlog gets too large. This RfC covers only opt-out methods of doing the notification. One proposed method: a bot pings a small number of random PCRs on a central page, to avoid spamming talk pages. A given user would only be pinged once every few months, also to avoid spam. PCRs who have recently reviewed changes wouldn't be pinged, because they presumably already know. There could be a maximum edit count/tenure of PCRs who get pinged. (Although a couple of experienced users noted on the idea lab discussion that they just forget S:PC exists, so that may not be the best idea.) The effect of the pings on reviewing activity will be recorded, and used to adjust how many PCRs are pinged.

This RfC is only for opt-out notifications. This idea was first discussed at the idea lab section. Enterprisey (talk!) 07:25, 18 September 2018 (UTC)

Survey (Notifying PCRs)

  • Support as proposer. Enterprisey (talk!) 07:25, 18 September 2018 (UTC)
  • Please no the watchlist banner is annoying enough to the point I had to beg someone to make a .css workaround so I don’t see it. I’d support getting rid of pending changes as a form of protection that solves nothing while creating more work for everyone involved. I know it will be opt-out, but we really shouldn’t have to opt out of something like this. TonyBallioni (talk) 07:29, 18 September 2018 (UTC)
    TonyBallioni, the odds that you personally get pinged as a result of this are very small. Backlogs don't happen that often, and there are 7,038 other PCRs. It doesn't even have to ping admins. Enterprisey (talk!) 08:04, 18 September 2018 (UTC)
    We should probably pare that number down to editors who've been active in the last 30 days. No point pinging inactive users. — AfroThundr (u · t · c) 08:11, 18 September 2018 (UTC)
    Yup, I'll keep it to recently active editors. Enterprisey (talk!) 08:18, 18 September 2018 (UTC)
  • Oppose - There is already a perfectly good template for reviewers who wish to remind themselves to work on the backlog when it grows a little too large. I fail to see the utility in implementing this. EclipseDude (talk) 07:43, 18 September 2018 (UTC)
    The template doesn't seem to be working very well. Enterprisey (talk!) 07:47, 18 September 2018 (UTC)
    It seems to work decently well for me (once I discovered it existed). I added a fork of it to my user page, where I'm more likely to notice it, since I kind of use my page as a home page. — AfroThundr (u · t · c) 08:11, 18 September 2018 (UTC)
    Yeah, the template itself works fine, but it doesn't seem to be driving enough traffic to S:PC - hence the backlogs. Enterprisey (talk!) 08:18, 18 September 2018 (UTC)
    Perhaps the template should be displayed more prominently on WP:PC instead of as a footnote. Many reviewers are likely unaware of its existence. — AfroThundr (u · t · c) 08:21, 18 September 2018 (UTC)
  • Comment This would be better suited (IMHO) as an opt-in process. After advertising on the Village Pump, there'd likely be plenty of active participants who would sign up for this (myself included). Benefits of making it opt-in:
    • ensures you don't annoy other users who don't want to be bothered by a bot
    • ensures a higher likelihood of an actual response from the users pinged
    • increased frequency of pings to users since they actually want the pings
    As I mentioned in the original discussion, having users opt-in via a template (or signing a central page) would be a good method of doing this, and could even allow for the editor to specify their ideal notification criteria. — AfroThundr (u · t · c) 08:07, 18 September 2018 (UTC)
    Yeah, if this doesn't pass I'll write an opt-in bot instead. I just figured an opt-out bot would be more effective. Enterprisey (talk!) 08:09, 18 September 2018 (UTC)
    Second this. I would be more supportive of an opt-in process. EclipseDude (talk) 08:11, 18 September 2018 (UTC)
  • I don't have problem with this, but please make it "opt-in." –Ammarpad (talk) 14:38, 18 September 2018 (UTC)
  • (Summoned by bot) Comment Would support an opt-in version of this and/or if the PERM page was changed to make it clear that this was opt-out going forward for people granted the PERM that would be OK with me too. In general I think there's value in people with PERMS being alerted to backlogs. Best, Barkeep49 (talk) 14:58, 20 September 2018 (UTC)
  • Oppose opt-out if this is going to include all sysops (who also have pending changes review access) - else, perhaps this could be a css controlled watchlist banner ("There are %somehighnumber% of backlogged pending changes")? — xaosflux Talk 15:06, 20 September 2018 (UTC)
    This will not include sysops. I considered a banner, but I only want to notify a very limited number of people about this, to reduce the overall level of annoyance. There's already a banner, I think, but it doesn't show count. Enterprisey (talk!) 22:06, 20 September 2018 (UTC)
    @Enterprisey: I think you get a banner if there are any PC's that are for pages on YOUR watchlist. I'm suggesting that IF (PC log>n)&&(usergroup in reviewer) => SHOW BACKLOG BANNER. — xaosflux Talk 22:18, 20 September 2018 (UTC)
    Ah, I get what you're saying. Enterprisey (talk!) 22:51, 20 September 2018 (UTC)
    I think this is an intriguing approach to the problem. Best, Barkeep49 (talk) 01:41, 21 September 2018 (UTC)

Idea lab

Give Extended Confirmed Users/Non-Admin Users the right to semi-protect a page in order to deal with vandalism.

Today I was engaged in a suppression of a particular persistent vandal on theDracula (Castlevania) who was able to continually vandalize the page despite a RPP being filed along with an administrator request for intervention due to lag and Admin-Shortage. Perhabs a way to reduce the demand for admin services would be to re-distribute some of their powers down to other users by giving them the ability to semi-protect pages for a short period of time(1-2 hours) to reduce the delay and improve counter-vandalism efforts.Zubin12 (talk) 12:42, 28 August 2018 (UTC)

There was a recent major RfC on the creation of an additional userright to allow short term page protection. Strictly speaking only the original proposal which allowed quite a long time was closed as major consensus against. A mid-discussion proposal fairly similar to this got mixed views (I think that one mooted 6 hours). The userright would need to be significantly tougher to acquire than rollback/NPP (the general "intermediate" rights). Worthwhile having a hunt through the archives to find it to avoid duplication. Nosebagbear (talk) 12:57, 28 August 2018 (UTC)
Oh that's disappointing, Could I have a link to the discussion I'm not able to find it looking back through the archives.Zubin12 (talk) 13:01, 28 August 2018 (UTC)
  • Link to RfC. I'd suggest linking in NeilN if you want to discuss the concept in more detail - it would need to be excellent to even get some reasonable discussion as this is a functional perennial. You can have a look at his proposal if you search ctrl+f " I agree the original " Nosebagbear (talk) 13:03, 28 August 2018 (UTC)
I just went through a discussion today where if an extended-confirmed editor had been able to exercise their wish for protection they would have unjustly prevented an editorial opponent with a valid concern from editing and pretty much destroyed three months' work without scrutiny. I know this is a one-off anecdote, but I do see it happening regularly enough that I'm convinced that granting any blocking or protection powers to non-admins is and remains a bad idea. Ivanvector (Talk/Edits) 23:34, 28 August 2018 (UTC)
Just giving it to ECs would be an insane idea and wildly OTT. As I mentioned, were this 3-hr protect proposal to progress you'd need a firm set of requirements for an extra user-right to be provided/denied at WP:PERM.
Ivanvector,and Nosebagbear I understand your concerns that this power may-be misused in edit-wars but I don't think that a short duration 45 minute block with instant permanent revocation for misuse will be that much of a problem. Surely responding to handful users abusing a tempory protect function will take far less admin time than the current RPP system ?Zubin12 (talk) 14:19, 29 August 2018 (UTC)
  • EC is too short, 5 months 2 thousand edits would be better, and at PERM admins would look for a proven track record in counter vandalism. As for duration of application, I think 45 minutes max would be quite ok, and not against the Wiki Way. The perm could be limited to the mainspace only, and could also be made have its own tag and show up at a Special:UserTempProtected noticeboard where patrolling/subscribed admins could attend to it. Also, a rate limit of 2 temp semi-protects an hour would further prevent rogue users from abusing it. The standard "Users take all responsibility for their edits while using this permission and may receive sanctions up to and including indefinite blocks for misuse" would cover anything else. I can see an occasional user being confused (AGF) and using it enforce their preferred reversion (off the top of my head, when BMK was last dragged before AN3, it wasn't strictly vandalism, but he wasn't edit warring for his own sake, rather the good of the 'pedia.) but either the removal of the right, a community talking-to, or a block would solve the problem. It's fairly hard to disrupt the encylcopedia when you can only semi-protect the same page for 45 minutes out of each hour. I'd view rollback as a more dangerous tool than this. Thanks, L3X1 ◊distænt write◊ 13:46, 29 August 2018 (UTC)
Beyond prove track record in CV, a demonstrated correct use of RFPP would be necessary. A couple more thoughts: depending on coding complexity, preventing the same user page-protecting the same article twice within any 24 hr block would also hinder mis-use. I would say if this is in place, then a simpler 1 hr SP could be used. There are quite a few cases though where a 2hr SP would be better (particularly either in really peak times or the (0400-0700 UTC) "bubble" when the amount of admins online drops heavily). Nosebagbear (talk) 15:03, 29 August 2018 (UTC)
Nosebagbear, I agree with you on the RFPP trackrecord and on the once-per-day rules. I also agree with what Zubin12 said just above. Thanks, L3X1 ◊distænt write◊ 20:42, 29 August 2018 (UTC)
I'm just going to specifically link in @NeilN: since he was the one who wrote a proposed motion in the middle of the rejected one that is reasonably similar to this one and I think his thoughts might be helpful Nosebagbear (talk) 21:22, 29 August 2018 (UTC)
Neil's on wikibreak, since the 5th of this month. Thanks, L3X1 ◊distænt write◊ 21:12, 30 August 2018 (UTC)
Cheers for pointing out. Nosebagbear (talk)
  • So some summary thoughts from the couple of us currently involved, I'm not sure I'm fully in favour, but I think a pre-pre proposal would help clarify (italics indicate known queries):
  1. Protection would be limited to semi-protect.
  2. Protection duration would be limited to between 45m-2 hours (TBD).
  3. Right holders ("RHs") could only protect the same page once within 24 hours.
  4. RHs could only protect 2 pages within one hour.
  5. There would be stringent requirements at WP:PERM to acquire this right. At a minimum: 2000 posts (or 1500 mainspace?), a clean 6 month block record, registered user for 150 days, proven track record in Counter-vandalism, proven track record in Requests for Page Protection.
  6. Use of the right must be accompanied by a full request for some form of page protection at WP:RFPP. Failure to do so would be deemed a mis-use of the right.
  7. The right could only be used in Main or Talk (not including User Talk) namespaces.
  8. Right could only be used in instances of vandalism from multiple IPs/newly registered accounts. Alternate uses of protection (such as against unsourced details etc) would not be permitted

Nosebagbear (talk) 22:43, 30 August 2018 (UTC)

That's a good summary, but I would ammend the requirment for RPP to simply record of previous vandalism on the page. The whole point of this proposal is to reduce the work-load on admins so requirng an RPP is kinda counter-produtive. Zubin12 (talk) 23:45, 30 August 2018 (UTC)
A good summary, but there are some points (I am directly responsible for a few, it seems,) which over time I have come to second guess. While we all agree EC30/500 is too short, I am not convinced 6 months is a good minimum, 3 months (or 90-100 days)might seem better. Our goals here are twofold (correct me if I am wrong): prevent misuse by the novices, and to prevent abuse by those with malicious intentions, such as socks and LTAs. Well, socks, LTAs and those who are NOTHERE usually either show their hand in the first week of editing, or are quite capable of playing a long game to get their way. (Jay, SwisterTwister, TheGraceful-Not-Slick-Enough, and Dr.Strauss fit into the sock category, they ran sock accounts for months and years before being discovered. Now TBH, they had other intentions than the disruption of the Pedia, but still, they can serve as a template) For these people 6 months isn't long enough, but neither is 5 years. For maximum effective use, to our own benefit and to the RH, I think shortening it would work just fine. As for edit count, I am fine to pitch that to the community, as I started out editing with all my heart and soul, and racked up 2000 edits quite fine. However, if our Service Awards are to indicate the general or expected progression of editting progress, if we are going to lower it from 6 months, the edit count requirement should correspondingly drop to 1000 edits as well. I have seen in recent discussions just about everywhere here, that more and more of us are delineating mainspace edits apart from all edits, and that is good, but admins at PERM aren't stupid, and would detect gaming when they saw it. Bots aren't giving out permissions to anyone who just breaks the minimum threshold, anybody making piddlesome edits to their sandbox would be shot down. I also think it would be beneficial to us and to novice CVU operators if the permission requirements weren't carved too deeply into stone. The goal here is to protect the encyclopedia against vandals in a more effective manner while helping to take a few straws off admins' busy backs. Assuming point 5 is accepted by the community sans amendments, I would like admins to not decline a RH just because they were 10 days or 200 mainspace edits short, if everything checkout.
Another thing (sorry I am running on) about point 5, (and I know these are just brainstorming points) 150 days is 5 months, so if 150 is going to be accepted, the block log thing should be amended (on paper at least) to reflect that.
Re: Point 6, I agree with Zubin a bit, it seems counterproductive to file a duplicate report. One thing I have noticed through my work in CVU is that it would seem that a short "Go away stop that please" technical restriction would be of infinite more use to the encyclopedia than actually having to fight prolonged revert actions against vandals. (Basically, for an obvious vandal, a 30 minute no frills block after just one penis edit would be more effective and better to all involved than having to wait for 4+ vandal edits, multiple warnings, and then AIV. If I were in charge I would rewrite the blocking and protection policies to encourage the use of very short term measures. But I digress…) If the Special:NonAdminSemiProtect page/queue were implemented, or maybe just for the first 10 uses by the RH, I think that would allow misuse to be corrected and abuse to be stopped easily enough, without requiring RFPPs all the time. I expect this tool (if enacted by the community) to be used quite often, and if point 6 was the rule, RFPP would be spammed into useless oblivion, requiring a dozen or so "clerks" to sort through them all and try to keep up.
If each mini-protection had a tag attached to it, a MW query (we are now in technical territory where I am quite ignorant) or bot could trawl through them all and look for anything suspicious: pages being mini-protected when they hadn't been previously edited by IPs/non-AC users for a week or more, repeitious protections that might indicate misuse, and flag those for human review. I'd expect a large false postive rating (how many of us have clicked the wrong button in TW or rollback and not noticed it?)
Currently, I think we have enough to prevent abuse, indeed Point 2 and 3 would make this harder to abuse than rollback, where one could cause an awful lot of damage in 4 minute if they so desired. Playing devil's advocate, if we hand out RB to over 6 thousand editors and let it be, why should it be so hard to get a right limiting you to disrupting 48 pages a day?
Last one for tonight, something should be done about spaces where this tool is applicable: main only? Main and Talk: spaces? If use in the userspace at all allowed? I can see a lot of newer users getting a nasty comment from a reverted IP (vandal or no) and applying temporary protection when they really of oughtn't. Thanks, L3X1 ◊distænt write◊ 00:59, 31 August 2018 (UTC)
Drops mike...saunters away
2 hours still seems short. During the RFC mentioned above I visited RFPP during off hours (early morning UTC, US holiday). Four requests took over 12 hours to be answered, the average answered request took over 9 hours to be answered, and there were 10 requests that were still unanswered after over two hours. I think 6 hours would be reasonable, although NeilN's proposed 3 hours is better than nothing. There would be a requirement to report all temporary protection at RFPP, so if admin response time at RFPP suddently improves, improper application of protection could be swiftly be dealt with by admins. --Ahecht (TALK
PAGE
) 17:48, 5 September 2018 (UTC)
  • Response - Right, the comments above seem to pertain to points 5 & 6. I'll attempt to reply to this, bit by bit:
The time span was less "filter out bad eggs" and more "let policies fully seep in" - you can gather lots of CV experience and a fairly high hit rate, but I think accuracy still improves over time. Still, I'd be happy to say 90 days so long as CV and RFPP track record were fairly firm
I disagree about reducing the edit count. I think that level of participation is necessary - you might do it in (say) 120 days, you might take 200, but I think that 1000-2000 step is a fairly key one in "basic grasp on the intermediate bits" to "being firm on all the standard areas". I believe this right could be more troublesome than rollback error, and thus a higher level of edits should be required. If nothing else, it needs to be made clear that this will be a fairly rare user-right.
I'm fairly happy for a general all-space edit count, and leave it to the WP:PERM admins (who are definitely aggressive investigators) to check for system-gaming (even non-deliberate cases). I'm also happy for admins to judge edge-case exceptions - they usually do so via probation.
I originally did write time-in and block-free times the same, but amazingly all the user-rights are like this. I think it is there in the viewpoint that an newish editor with 3 months exp is easier to trust with tools than an 8 month editor with a block 4 months ago. I'm not sure myself either way, but if that is the general viewpoint then I'm not sure I'd dispute. I would want to note that perhaps it should be a 90 day clean-period for a single 3RR block.
Hmm, I can see the arguments here as regards time saving, duplicative, even more admin-time use etc. I can also see some massive concerns that RHs would be getting admin-lite powers without proper oversight - it'd be a shift of direction from "holding the fort while awaiting an admin" to "dealing with smaller cases alone". I'm concerned by the thought (and potential significant disagreement) - might be nice to get a couple more opinions.
I 100% agree that it should only be usable in Main and Talk spaces (not including User Talk). In fact, I'm going to add it as a mooted agreed point above.
My own thoughts A "Special:NonAdminSemiProtect" queue would be needed, however perhaps two other things could be useful: a more active use of parole when giving the right then usual, and some comment/tick box log that would require RHs to note 2 things: why they were using the right, and why it had to be used in place of other measures/warnings and AIV-block etc.
As well as an individual "1 use per page per 24 hours" perhaps we should make that a "1 (maybe 2?) use per page per 24 hours" in total". After all, if it is being that much of a problem it is most definitely a case for a "proper" protect.
Thanks for reading (and if you aren't L3X1, congrats for reading both posts!) - thoughts, especially on point 6? Nosebagbear (talk) 17:23, 31 August 2018 (UTC)
I've also amended another bit of NeilN's usage - the right should only apply against vandalism from multiple users, rather than the other reasons RFPP being used Nosebagbear (talk) 16:09, 2 September 2018 (UTC)
I get that other reasons (disruption, unsourced additions and removals, annoying edits etc) would be disallowed but are we sure "from multiple users" is a useful clause? I can't really remember anytime I was dealing with multiple accounts or IP hopper on the same article at the same time while an RFPP was filed. Most vandalism I know of is single-author.
Thinking point, allowing other reasons to protect would open a can of worms, but might it be worth it? This was on my watchlist this morning, Special:Contributions/Brent_william. None of the edits are vandalism, (wolf characterising the last one is up to him, I won't dispute it, but I wouldn't have done that myself), but the editor in question did need assistance in making whatever changes he wanted, and a technical nudge to a talk page might have helped hium. Thanks, L3X1 ◊distænt write◊ 18:56, 2 September 2018 (UTC)
L3X1 - Multiple users is necessary - otherwise these RHs would have lower requirements than formal RFPP. I also agree with them - I think the disruption of short protect is greater than the 4 or so actions to block a single user/IP and refer to AIV (which is more reliably quick than RFPP).
While of course there would be some benefits for additional benefits for blocking other categories, we need to limit to extremely clear-cut cases and the only general category where that is the case is vandalism. Nosebagbear (talk) 10:43, 3 September 2018 (UTC)
Only noting that "protecting against widespread vandalism" could be seen on the other side of the coin as "rump caucus trying to subvert the page consensus". The protection better get an endorsement by an admin in good standing otherwise the protection and permission needs to be revoked, for cause. Hasteur (talk) 16:39, 8 September 2018 (UTC)

"Helper" account for a user assisting another disabled user

There was a request yesterday that bounced around a few forums, about how a user could go about assisting another user who has a disability (arthritis, I think it was) and finds it difficult to edit directly. The "helper" user, Izzat Kutebar, proposed creating a second account for the disabled user, which they would then operate on the disabled user's behalf. By the time the question got to my attention Izzat had already been advised to ask in a different place several times, and was unfortunately but understandably upset about the situation. I responded that shared accounts are not allowed, but I think I need to go back on that in the interest of accessibility. This seems like as good a time as any to have a discussion on this topic, even though Izzat has supposedly permanently retired apparently because we did not jump fast enough for their liking; that's partly my fault.

On the issue of a "helper" account, I think it's fine, and if there is some policy that forbids it, we should revise it. Let me use the example (inapt here, but maybe not) of a deaf person's assistant, or a translator (or an ASL interpreter, I suppose). In sensitivity training, we are taught that even though the disabled person interacts with the assistance of a helper, you are not interacting with the helper but with the disabled person. I see this as an analogue for a disabled person who cannot operate a keyboard editing Wikipedia with the assistance of a helper who types for them - per our policies, the disabled person must have their own account, not share the helper's account. I think we can and should accommodate that.

As far as policy is concerned, the sockpuppetry policy (the policy on the use of multiple accounts) doesn't explicitly cover this situation, but I think it ought to fall under something similar to a designated role - the helper is a role and should not edit from their own account while helping the disabled user. But the policy also says that role accounts of this sort are forbidden (presumably meaning those roles that aren't "designated"), so if this is the approach then the policy needs to be adjusted. I'm not sure if we need to require disclosure or just advise that helpers can disclose privately to Arbcom if they wish.

I'm posting this here at the idea lab because I'm not really sure where to go with it, so input and/or other ideas are appreciated. Ivanvector (Talk/Edits) 23:30, 28 August 2018 (UTC)

If User 1 wouldn't be able to operate a keyboard, then wouldn't the account belong to User 2, with User 2 editing by proxy for User 1? WP:PROXYING is only prohibited in the case of users who are sanctioned. There is, AFAIK, no policy forbidding proxy editing for users in good standing. GMGtalk 23:35, 28 August 2018 (UTC)
As a concrete example, I was in the middle of the woods in February on a training exercise, and I spotted what I thought was copyvio, but was on mobile with crap for internet access. So I logged onto IRC and asked for someone else to look into it. That, to my mind, is proxy editing for reasons of accessibility, although in my case, not related to disability. GMGtalk 23:40, 28 August 2018 (UTC)
I suppose you're right, and I've done the same. I guess what I'm looking for is a way for us to recognize, for reasons of administration and dignity, that the account actually belongs to the disabled user, who edits with the assistance of the helper. The same as if the user edited with an assistive device, or text-to-speech or whatever technology is used for this purpose (I don't mean to offend anyone, I just don't know). I may be overthinking it. Ivanvector (Talk/Edits) 00:09, 29 August 2018 (UTC)
(edit conflict) Well you can't let it "belong" to User 1 (that would be shared), but you can have it "dedicated" to User 1. Something like:
It's not perfect, but it puts someone else in the position of having to open an RfC to disallow it, rather than you opening an RfC to allow it as a form of shared account. GMGtalk 00:43, 29 August 2018 (UTC)
I suppose if serious behavioral issues arose, all three accounts would be subject to sanctions. Just as if you asked me by email to join in your edit war by proxy, and then when I was blocked, I gave your email to ArbCom. GMGtalk 00:51, 29 August 2018 (UTC)
  • Wikipedia will bend over backwards to help with accessibility for to the project by the disabled, definitely including editing assistance by arthritic users. If User_1 needs assistance from User_2 to perform some edits, and these two people feel more comfortable not using their main accounts where User_2 is doing something for User_1, then by all means create a new User account, such as User:User_2 on behalf of User_1, making it clear on the main userpage that User:User_2 on behalf of User_1 is an account controlled solely by User_2 for the sole purposes of performing edits requested by User_1. This way, each account is technically controlled by a single person, and no one is sharing passwords. Ideally, User_1 will use their main account to confirm the arrangement.
This is off the top of my head. I am sure there are other solutions. --SmokeyJoe (talk) 00:34, 29 August 2018 (UTC)
I think that we're overthinking this. Two editors need two accounts (one each). We don't care whether those users type on keyboards, sing to their speech-recognition software, or ask someone else to press the buttons. What matters is that 100% of the words posted under each username are actually the words chosen by a single human. It is not a "shared account" if you are typing someone else's words. That makes you a meat-based implementation of speech-recognition tools. It does not make you a joint owner/participant in the account's activities. The only significant policy problem there is Wikipedia:Meatpuppet, but that is not unique to disability/transcriptionists. That problem is no different from the problems experienced by people talking about their edits in university dorms, on Facebook, or around family dinner tables. WhatamIdoing (talk) 20:59, 10 September 2018 (UTC)
  • Taking everything that's been said here into consideration, I think perhaps that nothing necessarily needs to change. If a disabled person has their own account but gets assistance from another person to physically operate the account, this is either not a violation of any policy, or we should ignore the rule. As for "helpers" who also have their own account, I would suggest that they disclose privately to Arbcom, keep their own editing separate (with a separate account) from the editor they're assisting, and have that be the end of it. Ivanvector (Talk/Edits) 13:42, 12 September 2018 (UTC)
    It's like an amanuensis. Consider Eric Fenby writing out a musical score: if it's his own work, then his name appears at the top; but if it was composed by his employer, then the name Frederick Delius is given. --Redrose64 🌹 (talk) 19:49, 12 September 2018 (UTC)

Removing official website

I would suggest the members who would like to comment on the question I am going to ask, to visit [23] link before answering my question. My question is: from the link, I was able to understand that the subpages like 1970 Stockholm Open and 1989 Stockholm Open doesn't have official website and doesn't needs to be linked. So, am I allowed to remove the official website link from the specific wikipedia pages or do I need to remove the magic word official website and provide it as a normal link? Currently, for the official website section, they follow single value constraint ie. only one page can have same official website. Adithyak1997 (talk) 15:07, 1 September 2018 (UTC)

Just as a note, original discussion here. I don't think we should replace {{official website|http://www.stockholmopen.se/en/}} with [http://www.stockholmopen.se/en/ Official website] in 1970 Stockholm Open only for the sake of a cross-wiki category check, since the use of the template on the page will let people know if there is an official website being linked to on the page. That being said, if a consensus determines that having an "official website" (of the organization) for an individual year of a tournament is inappropriate, then by all means feel free to remove the template (though linking to the Swedish Open website on the 1970 SO page makes sense to me). Primefac (talk) 15:15, 1 September 2018 (UTC) (please ping on reply)
This seems like primarily a Wikidata problem with P856. But anyway, the template only defaults to the Wikidata property if left blank. So {{Official website}} on Google will to to https://www.google.com. But {{Official website|https://www.yahoo.com}} on Google will go to https://www.yahoo.com, even though it's placed on the Google article. GMGtalk 15:16, 1 September 2018 (UTC)
I think the concern is more with pages populating Category:Official website not in Wikidata - the WD page for the 1970 Stockholm Open, for example does have an "official website", and thus it's in this cat. Primefac (talk) 15:48, 1 September 2018 (UTC)
Oh. That seems like a bit of a silly category actually. Poor Abraham Lincoln's got no website at all. GMGtalk 16:03, 1 September 2018 (UTC)
You won't see that category in the article Abraham Lincoln because what it really says is Official-website-defined-in-article-but-there-is-no-official-website-defined-on-Wikidata
As for the 1970 Stockholm Open etc., we shouldn't use the template or the phraseology. Remove the link because it contains nothing about the 1970 tournament. – Finnusertop (talkcontribs) 17:01, 1 September 2018 (UTC)
Since many of them are saying answers, I suggest somebody(after discussion)to tell a final response to this message as I am not familiar in doing that. It needs to be done only after discussion and not now. Adithyak1997 (talk) 17:33, 1 September 2018 (UTC)

So what change needs to be made?Any final result from this discussion?Adithyak1997 (talk) 14:36, 10 September 2018 (UTC)

Discussion for feasibility of a two password system

How hard would it be to implement a two password system in the database? A system that:

  • Allows for using a second password in conjunction with the first for increased user security. Password entropy increases by orders of magnitude when you have two.
  • Is an additional layer of security for those who are not comfortable using 2FA but it could be used with 2FA as well. Should also work with the "keep me logged in" 365 day cookies for simplicity and convenience. Transparent. See the admin newsletter from March where it is reported that only 16% of admins have enabled 2FA. I believe that editors/admins would be much more comfortable using a two password system.
  • Is optional for existing editors but recommended for those with advanced permissions. Possibly required for all new accounts; this may help stifle all existing automated account creation scripts (spambots) used by prolific sockmasters and UPE sock farmers. It would also slow down those creating multiples by hand, too.
  • Would allow the user more time to help prevent a compromised account in the event the first password is breached. The user should be able to change the breached password to maintain account control and the alert should encourage contacting a checkuser to go after the hacker.
  • First alerts the user when the first password has been breached as opposed to alerting on attempts at the first password. Current attempts at hacking passwords result in alerts that are causing disruption by encouraging users to change their passwords. Aside from alarming people, sometimes en masse, this has led people into locking themselves out of their accounts. If their password was already strong then they shouldn't have to change it. We shouldn't be allowing hackers and sockmasters the ability to cause that much disruption (see this article and Attack on Wikipedia accounts over).
  • Allows checkusers to check those that breach the first password and hopefully block underlying IP addresses. Currently checkusers cannot check hacking attempts although there is something in the works to remedy that.

Is this something that others would be interested in having?
 — Berean Hunter (talk) 16:42, 5 September 2018 (UTC)

  • It sounds interesting, but I'm having a hard time coming up with situations in which an attacker would be able to obtain the first password without obtaining the second. It's not like attackers are just running dictionary attacks against wikipedia (as that is easily detected and shut down). The only feasible ways are a) password reuse from compromised sites, b) phishing, or c) a breach of wikimedia servers. For password reuse, rather than activate a two password system, a security-concious user could simply use a unique password for wikipedia. For phishing or a breach of servers, the attacker would get access to both passwords. In terms of increasing entropy, a security-concious user could obtain the same result by simply concatenating the two passwords (or joining them with punctuation or something). --Ahecht (TALK
    PAGE
    ) 16:50, 5 September 2018 (UTC)
    • Random note: I haven't enabled 2FA because I don't want my ability to edit Wikipedia to rely on my ability to pay my phone bill. --SarekOfVulcan (talk) 16:57, 5 September 2018 (UTC)
2FA, i.e. Google Authenticator, works offline. Just like a RSA security key generator. I suppose without a data connection, clock drift would eventually become a problem. But key generation doesn't depends on an active data connection. ☆ Bri (talk) 18:37, 5 September 2018 (UTC)
To me that Google Authenticator looks like it would negate much of the security benefit if it's all stored in the same device. Nevermind the added complexity... Jo-Jo Eumerus (talk, contributions) 19:11, 5 September 2018 (UTC)
Using google authenticator means that someone needs either physical access to your device or something like a remote-desktop connection to it. It prevents the vast majority of attacks where a remote attacker obtains your password either through password reuse, phishing, or a database breach that includes passwords but not OTP keys. --Ahecht (TALK
PAGE
) 20:33, 5 September 2018 (UTC)
Ahecht, if your home was your account then the analogy is that I'm suggesting adding a type of entryway that is a mantrap (interesting that they have put that article up for deletion...it can be sourced but I'll have to do it later today or tomorrow..example of mantrap). Instead of having one solid door with a deadbolt, you would have two where the design slows down an attacker and allows a better chance to respond. If someone gets your keys elsewhere because they picked your pocket (phishing) or left copies elsewhere (password reuse) or they got master keys from the manufacturer (compromised wiki servers) then they could still get in. My suggestion was never meant to be solutions for those problems. That would not negate the security value of the added entryway. Lock pickers would have two to get through. The analogy doesn't work fully because you would be able to do something about a person trying to break in the first door in real life but in our current situation, we can't.
"In terms of increasing entropy, a security-concious user could obtain the same result by simply concatenating the two passwords (or joining them with punctuation or something)." No, because each password field has a character limit; you can't currently do what I'm suggesting. You can use one long sentence consuming most of the limit like Guy Macon recommended. With what I'm suggesting, you would have two long sentences in separate fields with separate constraints. Entropy potential increases greatly.
If the mantrap is a sound, security best practice then why wouldn't it be in the virtual sense? Security is best practiced in layers and having more options is better.
 — Berean Hunter (talk) 11:30, 6 September 2018 (UTC)
Berean Hunter, so basically you propose the current 2FA system, but without the key changing every single time... —TheDJ (talkcontribs) 11:40, 6 September 2018 (UTC)
It is similar to 2FA in that you are using multiple tokens for authentication but would not require separate apps or timing sync. This would be built in just like the current password. It is simpler than conventional 2FA and you wouldn't have the opportunity to lock yourself out because of scratch codes.
 — Berean Hunter (talk) 12:01, 6 September 2018 (UTC)
Breaking a password isn't like picking a lock. Generally, it's not a brute-force attempt (as those are easily detected and blocked), but it's the equivalent of someone having the key to the door because they found your keys lying on the street. If you keep both keys on your keychain and someone steals it, a mantrap won't help. If you're trying to stop someone from picking the lock, instead of adding a second lock, you can just add more pins and use security pins. --Ahecht (TALK
PAGE
) 13:25, 6 September 2018 (UTC)
I am wondering whether a person is more likely to use two 12 character passwords or one 24 character password. And whether they will remember the two 12 character passwords more than the 24 character password. If the answer to both questions is yes as I suspect then that would be a sound argument in favour of 2PA. Jo-Jo Eumerus (talk, contributions) 13:54, 6 September 2018 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Re: " '...user could obtain the same result by simply concatenating the two passwords' No, because each password field has a character limit; you can't currently do what I'm suggesting. You can use one long sentence consuming most of the limit like Guy Macon recommended."

If I remember correctly from my conversation with the developers, you can enter a passphrase of 65535 bytes (possibly larger -- I would have to check) but (and I did look this up before posting) only the first 256 bytes are used. Unless you are doing something fancy with Unicode characters, 256 bytes equals 256 characters equals 2048 bits.

Anything larger than 32 characters doesn't increase security -- it would take longer than the age of the universe to guess, so whoever is first in the concatenation could use up to 224 characters without compromising security. (Pro tip: always place the shortest password first when concatenating, just in case some bozo has a million-character password.)

Technical details: Wikipedia stores a hash of passwords using PBKDF2/HMAC-SHA-256 with 64000 rounds and a 128-bit salt. If you have a unified login on multiple projects, each project uses a different salt, so cracking a password hash on Wictionary or the French Wikipedia doesn't allow the attacker to log in to the English Wikipedia.

Re: "...alerts the user when the first password has been breached...", this is a terrible idea. Lets say we combine passwords using your scheme or concatenation -- it doesn't matter for the purposes of this illustration. You choose "ab" and I choose "XY", giving us a password of "abXY". That's 32 bits, so it would take 32768 guesses to try all possible 4-byte passwords. Now allow the fact that someone correctly guessed the first two characters leak out (Per Kerckhoffs's principle, we have to assume that the attacker can monitor the alert) So the attacker only needs to make 256 guesses to get the "ab", them 256 guesses to get the "XY". By alerting the user of a partial breach you have substantially reduced the strength of your password.

In my expert opinion, the scheme I described at Wikipedia:Administrators' noticeboard/Archive298#PSA: Admins might be better off with a long passphrase rather than two-factor authentication is more secure than the scheme described above. --Guy Macon (talk) 13:59, 6 September 2018 (UTC)

Re: Google Authenticator; really really bad idea. You are putting software on a smartphone, and if the smartphone is an Apple or Android device, it isn't secure. And closed source from a company which is known to gather user data? No thank you.
Here is how I protect my Wikipedia login:
My Wikipedia passphrase consists of 256 random printable characters, which I generated from my hardware True Random Number Generator. I recommend BitBabbler ( http://www.bitbabbler.org/ ). Every website gets a unique password, with the longest length they will accept.
I can't remember the passwords, so they are stored as ASCII text files, which I only access using Linux. The files live on on an SD card, encrypted with Veracrypt ( https://www.veracrypt.fr/ ) using a long but easy-to-remember passphrase, plus a 1MB keyfile on another sd card.
I keep copies of the two sd cards in multiple locations in multiple countries (I have a deal with two other crypto nerds -- they send me their encrypted backups and I send them mine).
And of course c0c5e71bca550e99a8ae6641e66c428e232051bade39cd47355634ff159c9475fffa1d12eee339aa401bfe5b31ff7fc352c2b9c6f002bfe82d03a6b3f9e40047 is a SHA-512 commitment my real-life identity. See Template:Committed identity. --Guy Macon (talk) 14:30, 6 September 2018 (UTC)
  • I'm in favor of multiple passwords, but not in this variety. I think we should be able to have "privileged" and "non-privileged" types of passwords as described here: phab:T153454. I don't think changing logon security from "something you know" to "something you know+something you know" is that beneficial. 2FA is a great idea, but we need to make 2FA recovery easier to use. — xaosflux Talk 14:34, 6 September 2018 (UTC)
Ahecht, I disagree. With our specific problems and existing system, the more frequent occurrences of hacking attempts are done by hand and perhaps to harass users because they can invoke the alert system and alarm them. It can be somewhat akin to repeatedly pinging someone as a form of harassment. "as those are easily detected and blocked" No, they are not easily detected and blocked. I'm a checkuser and I can't detect the IPs being used at all and no, they aren't usually blocked. What do you know that I don't? For me it is frustrating to see people get locked out of their accounts or they otherwise become alarmed/upset and we couldn't detect them. That is why your suggestion of security pins doesn't work as an optional instead of but perhaps built in as an additional feature. That would not forego our ability to have a crow's nest built in for the checkusers to see them and then detect and block. You may also be missing the value that this system could break existing automated account creation scripts and force a reset. Most operators aren't the coders and that sends them all back to the blackboard. Zombie machines would break, too. Not a bad way of performing a purge.
"If you keep both keys on your keychain and someone steals it, a mantrap won't help." I've already accounted for that with "My suggestion was never meant to be solutions for those problems." It is understood that if someone gets your keys elsewhere that there could be a compromise...no claim to the contrary has been made. Are you suggesting that the concept of a mantrap does not have value or isn't a security best practice?
Guy, I wasn't suggesting that someone does this idea instead of yours but rather in addition to it. I think the long passphrases are a very good idea. "By alerting the user of a partial breach you have substantially reduced the strength of your password." You lost me with that. The person that possesses both passphrases has the ability to reset the first. That beats the current system where they own you as soon as they have used the first password. If you had a mantrap entry, you wouldn't want your alarm to go off at the first door? Huh?
Also Guy, this isn't about what professionals are doing...this is security for the masses. Like you, I use GNU Linux but we both know that it remains in the minority from a user experience perspective. Sometimes, it is hard to get people to try it, isn't it? Perhaps not for everyone. People aren't going to do all that you describe above because they are not as technically adept as the professional. They aren't enabling 2FA, either. Wiki editors could simply check a box in their gadgets and enable what I'm talking about. With new accounts having them enabled by default (still an optional idea), there would be no further complication than simply entering the second password. Remember that many folks don't perform regular backups so getting a more satisfactory security practice is a balance between the practical and the ideal. KISS principle applies over Kerckhoffs's principle here. This would offer a pragmatic approach where a solution has not been realized for the masses of our editors/admins. If there is a hole (exploit) to what I suggest then help me fix it but we need other options available. This option could also be quantified by similar results as those used to determine only 16% admins have 2FA enabled. We don't have a way of quantifying who decided to take your long passphrase suggestion so easily.
 — Berean Hunter (talk) 15:15, 6 September 2018 (UTC)
  • I just want to respond specifically to User:Xaosflux's two password idea. I think what we need is some kind of privilege escalation mechanism, like unix's sudo. I maintain two accounts (User:RoySmith and User:RoySmith-Mobile). I use the later on my phone because I don't want to leave an admin-enabled login session on a device that's easy to lose. It's a common practice, but it's awkward, and fails KISS. I'd rather have a single account, and a way to say, "authenticate and grant me admin rights, which automatically expire in N minutes". BTW, the best 2FA device I've ever used was the Yubi Nanokey. It lived in a USB-A port on my laptop, so it was always within reach, and totally convenient. If you make things easy to use, people will use them. If you make them awkward to use (i.e. having to type in a code), people won't use them. That's human factors for you. -- RoySmith (talk) 15:44, 6 September 2018 (UTC)
  • Can I add that you do not need a smartphone (or any phone) to have 2FA. There are other systems to generate that data, so long as that system has your 16 digit code and the current time, then it can work it out. I've enabled 2FA on my account and my Bot account (an adminbot). All I use is a simple python routine to give me both numbers (User:Ronhjones/2FA). I suspect there are other ways it can be done on the PC (you could always load up a Memu android emulator). Ronhjones  (Talk) 21:25, 12 September 2018 (UTC)
  • There's also Winauth, a portable open-source Windows 2FA authenticator that also supports encrypting your TOTP seeds with a FIDO U2F hardware token. --Ahecht (TALK
    PAGE
    ) 21:08, 13 September 2018 (UTC)

A bot to ping pending changes reviewers

So I'm looking at the pending changes backlog, and there are 39 pages in it. The oldest revision has been waiting for 45 hours; the next oldest, 25. We have over eight thousand users who could review these changes (probably less, once activity is taken into account), and somehow all of them have just not looked at Special:PendingChanges. I propose we have a bot that pings random pending changes reviewers (opt-in or experienced (>50 reviews) PCRs only? let me know) when the backlog gets over 10 pages (threshold up for debate) or a revision is over 24 hours old. Thoughts? Enterprisey (talk!) 06:14, 8 September 2018 (UTC)

So you are proposing having a bot nag me about pages with pending changes that are not on my watchlist? Editing Wikipedia is like drinking from a fire-hose; you need to focus on the articles you are interested in improving.--Guy Macon (talk) 06:45, 8 September 2018 (UTC)
It's opt-in. (Probably.) Enterprisey (talk!) 07:06, 8 September 2018 (UTC)
I imagine this falls under same de-facto policy as reporting AIV backlogs to AN. That is to say – don't. :P Although if people want to opt-in to the pain, then by all means. TheDragonFire (talk) 07:10, 8 September 2018 (UTC)
The thing is, the people at AN are probably very aware that AIV exists, and likely check it from time to time. I imagine many pending-change reviewers just don't check the pending changes page whatsoever, and this would just be a reminder. Enterprisey (talk!) 07:11, 8 September 2018 (UTC)
Who says that pending changes reviewers are supposed to respond to all pending changes requests on all pages? I certainly never signed up for that. Sure some reviewers would be willing to do that , but for them we have Template:Pending Changes backlog and Template:Pending Changes backlog-defcon --Guy Macon (talk) 18:11, 8 September 2018 (UTC)
This has started to go slightly off-topic, but I don't think many reviewers stick to a single topic area, as there's nothing in the pending changes guidelines that requires topic knowledge.
Another thing I could do is exempt editors above a certain number of edits, on the grounds that they would get annoyed by such a notification. Enterprisey (talk!) 18:40, 8 September 2018 (UTC)
I'm glad you mentioned those templates. I now have an instance on my user page, where I'm more likely to notice it. — AfroThundr (u · t · c) 13:47, 10 September 2018 (UTC)
I mostly just forget that Special:PendingChanges exists, because I don't have these pages on watchlist. I will add it as a thing To Do. --Izno (talk) 12:04, 8 September 2018 (UTC)
  • SOunds nice, ATM. I don't put those pages on my watchlist because there are a few thousand of them, and also all the normal ok edits that happen to them would clog it. If you are willing to spend the tiem to make a trial bot, I might opt in for a few weeks next spring when I have time. Thanks, L3X1 ◊distænt write◊ 16:02, 8 September 2018 (UTC)
    Yeah, since there are so many PCRs I'd imagine, by default, the bot would ping a given user only once every six months or some massive time period like that, when the backlog gets quite high. Enterprisey (talk!) 18:42, 8 September 2018 (UTC)
    I'd be interested in a ping when certain criteria are met, such as >50 entries outstanding, or >48 hours pending, with a cooldown of X days (configurable). This could even be entirely opt-in and user-customized with a template like the Miszabot config. The bot could just check the talk pages of all reviewers (or check for transclusions of the hypothetical template) so it can know who to ping. It doesn't even have to clutter the user's talk page either, since the bot could just post on a central PC status page or something. — AfroThundr (u · t · c) 13:47, 10 September 2018 (UTC)
  • I wonder if bots can just ping notifications without the talk page spam. I wouldn't mind a bot that did that for a lot of the things around the wiki. --Izno (talk) 15:52, 10 September 2018 (UTC)
    Yes, that would definitely be a good idea. Enterprisey (talk!) 06:34, 12 September 2018 (UTC)
  • This looks like a nice idea, if only the bot could ping and not spam talk pages. I always forget about Pending changes L293D ( • ) 12:20, 12 September 2018 (UTC)
    Yes, I've decided to have it ping users on a talk page, so that the targeted pages (maybe two or three per user pinged) will show up in the notification. I could also ping users from an edit summary directly, thus avoiding cluttering up a talk page, but that would be harder to audit. Enterprisey (talk!) 20:00, 12 September 2018 (UTC)
  • I think it is commons: that does this: displays a "pending changes is backlogged, please help" to only pc access people - might be on watchlist only. — xaosflux Talk 12:40, 12 September 2018 (UTC)
    Actually, that is "patrol backlog", but same concept. — xaosflux Talk 12:41, 12 September 2018 (UTC)
  • I've opened a discussion at VPPR. Thank you all very much for the input. Enterprisey (talk!) 07:25, 18 September 2018 (UTC)

Logout tool

I made this suggestion over at meta 3 months ago and nothings come of it, so I wanted to post it here and see if perhaps a more active project would be interested in running with it. I'd like to propose the creation of a universal logout tool that can see what devices currently read your account as being logged in and log out of all of them so as to better insure account security. I know that certain password protected services (such as Gmail) have this option in place to unilaterally log out of all devices that read as having logged onto or into your account, so utilizing the tool for Gmail logs you out of your desktop, laptop, smartphone, and ipad devices which then require you to log in to all devices again. Such a tool would be a good fit for Wikipedia, I think, especially since many of us edit from public computers, mobile devices and the like. Being given the option to log out of all devices at once would increase account security and help keep accounts in account holder's hands. TomStar81 (Talk) 19:10, 17 September 2018 (UTC)

Showing a list of logged-in devices would require wiki servers to keep a log of which devices are issued persistant cookies. I'm not sure what the current data rentention policy is for data such as device type/browser/etc, but IP addresses used to access the site are currently only stored for three months (which is shorter than the 1-year expiration for checking the "keep me logged in" buton). As to the second part, clicking the "log out" link on any device should regenerate your login token, signing you out on all devices. See phab:T51890. --Ahecht (TALK
PAGE
) 20:25, 17 September 2018 (UTC)
Thinking more about this, there might be some merit in allowing all users to run the WP:CheckUser tool on themselves, to see if they can spot unusual activity. It wouldn't exactly show a list of logged-in devices, but it would give users a window into their own account activity. Only downside is that access to such a tool could help sockpuppets to make sure they are properly covering their tracks. --Ahecht (TALK
PAGE
) 20:41, 17 September 2018 (UTC)
I don't think a hacker getting access to your account should be able to see your IP address. PrimeHunter (talk) 21:53, 17 September 2018 (UTC)
@TomStar81: actually using Special:UserLogout on any session should log you out of every session already - though it doesn't let you 'display' the sessions. — xaosflux Talk 23:17, 17 September 2018 (UTC)
Well that's good news! If you log out from any machine you should log out form all machines, which helps keep accounts secure. Thanks for the reply and for entertaining the idea (although in this case it appears you guys were one step ahead of me :) TomStar81 (Talk) 23:52, 17 September 2018 (UTC)
Only tangentially related, but for what it's worth, you can see any applications you've granted authorization to at Special:OAuthManageMyGrants. ~ Amory (utc) 01:29, 18 September 2018 (UTC)

2 new ideas

I don't know if this is the right place to ask but I came up with these 2 ideas:

recognizing blocked users on history pages

When viewing history pages there should be a way to tell that a user is blocked, for example, to have the word "(blocked)" after the blocked user's username. -- -- -- 06:13, 20 September 2018 (UTC)

Check out the "Strike out usernames that have been blocked" gadget in your user preferences. DMacks (talk) 06:31, 20 September 2018 (UTC)
thanks, that was quick. -- -- -- 07:42, 20 September 2018 (UTC)

watchlist for all Wikimedia sisterprojects

To have all of my watchlists on a single page, so that I shouldn't have to visit each sisterproject separately in order to check my watchlists. Thanks in advance, -- -- -- 06:13, 20 September 2018 (UTC)

See Wikipedia:Global, cross-wiki, integrated watchlists. DMacks (talk) 06:32, 20 September 2018 (UTC)
thanks, I'll check when I'll have a chance. -- -- -- 07:42, 20 September 2018 (UTC)

Miscellaneous


Vulgate

Forgive and please advise if this is the wrong place to bring this up. Wikisource has only the first few chapters of the vulgate. This seems like a serious oversight that could be easily mended. Couldn’t any of many copies be uploaded? I regret if I’m being naive about the factors involved. Temerarius (talk) 02:16, 13 September 2018 (UTC)

Pinging several of the Wikisource admins: It sounds like Temerarius would like to help with Wikisource. Can someone point the correct direction? Whatamidoing (WMF) (talk) 20:13, 18 September 2018 (UTC)
The place to ask would be s:Wikisource:Scriptorium/Help, and it would be helpful to identify a public domain version of the vulgate suitable for uploading. bd2412 T 20:44, 18 September 2018 (UTC)
Consider the Clementine Vulgate Project as a source for the text. EdJohnston (talk) 21:39, 18 September 2018 (UTC)
Is this a desire to have a Latin text of the Vulgate put online, or an English translation of the Vulgate? This makes a big difference, since it involves different Wikisources (Latin versus English). Wikisource is divided into different language projects just as Wikipedia is. So the first question to be answered is: Which language are we discussing here? --EncycloPetey (talk) 01:06, 19 September 2018 (UTC)
Thanks all. Not a translation, just a Latin text. Temerarius (talk) 03:04, 20 September 2018 (UTC)
  • I have dropped a note at s:Wikisource:Scriptorium#Vulgate. bd2412 T 02:31, 19 September 2018 (UTC)
Resolved

billinghurst sDrewth 08:15, 19 September 2018 (UTC)

Template:Media_by_uploader and how to confirm uploads are in fact own work?

Per the comments on the closure of a TfD here Wikipedia:Templates_for_discussion/Log/2018_July_23#Template:Media_by_uploader it was suggested that a VP discussion be had. I've marked this template as deprecated as an amended wording was implemented in {{Img-unclaimed}} and {{img-claimed}}, but given the wording of those templates is related to the one at the closed TFD, this discussion also concerns them.

The problem is essentially that before Wikipedia developed the upload policies it currently now has and to some extent the structure imposed by the {{information}} template, some media was uploaded under a set of assumptions that whilst in good faith at the time, aren't necessarily the same assumptions that would be made when evaluating media that would be uploaded under the current policies. One of these assumptions being that where the uploader said something like "I made this" on the file description page, the file was implicitly considered own work, (One of the current recommend approach is for the uploader to use Own work as the Source: field and to use a license like {{Self}} or {{Self2}} at the time of upload.

Why does this matter? Currently a query at WMF Quarry (https://quarry.wmflabs.org/query/29651) lists at least 27,000 uploads (an expanded query listed at least 50,000) for which a source couldn't be recognised. The actual number of uploads that don't have a source is certainly going to be considerably smaller. In many instances the source for older images will be a statement to the effect "I made this" or " Photo taken by username", but NOT as it didn't exist the time an explicitly included {{own}}tag or {{information}} block. Some contributors in the past have added these in good faith, but I was advised against off-wiki (more than once) about automatically adding own work (or {{own}} without some kind of confirmation (either from the original uploader or by other means). Whilst assumption of good faith is a key Wikipedia trait, taking it on trust that something is own work based on limited meta-data is not necessarily a long-term approach.

{{media by uploader}}, {{img-unclaimed}},{{img-claimed}} were intended as part of a pragmatic approach, as by asking uploader to more actively confirm 'own' work status, without needing to take media through the FFD or PROD process which would be inappropriate given that many of the affected uploads are sourced, and are (implied or not) indeed own work by their uploaders.

ShakespeareFan00 (talk) 11:09, 14 September 2018 (UTC)

After a good chat with SF00 off-wiki, the issue seems to be as follows. There are three classes of images:
1. Images which are identified as own works, but without the exact {{Own}} template.
2. Images which are tagged with a licence but no clear source (and are presumed own works for some reason)
3. Images without any source or licence (if presumed own, then they are automatically licensed under the GFDL and CC-BY-SA)
SF00 has been previously instructed that tagging case 1 as {{Own}} is not appropriate which has lead them to attempt to create a new process of clarification. I'd like to invite the community to either allow SF00 to get on fixing the tags, or to put some proper thought into how we want to handle this. TheDragonFire (talk) 11:41, 14 September 2018 (UTC)
  • I think there are several good cases where it is perfectly safe to just put the {{own}} template in the image without further interaction from the uploader or putting any warning templates anywhere: (1) the uploader clearly says "my own work" or "I took this photo on my trip to Africa" or some such thing, (2) the uploader attributes the photo to "Bob Smith" and either the user's Wikipedia user name is BobSmith123 or the user says on their user page that their name is Bob Smith, (3) the user uses the {{GFDL-self}} or {{PD-self}} template. All three of these cases are obviously with the proviso that the claim is credible - that the image hasn't been published outside of Wikipedia, doesn't have EXIF data that contradicts what the user says, etc. On the other hand, if there is no claim of authorship at all or the photo is attributed to a person that we don't reasonably believe to be the uploader, then {{npd}} or {{nsd}} is the correct template. If the uploader is still an active user, then we can/should attempt to discuss the issue with the user rather than just tagging the image - that is more likely to get a positive response than just tagging 10 images and leaving 10 identical templates on the talk page. (Obviously, there is little we can do if the uploader hasn't editing in 10 years - we have no choice but to tag and delete the image.) --B (talk) 20:06, 16 September 2018 (UTC)

Adding short descriptions and defining pictures for search

Hello. I noted the Short description of "Azərbaycan" page with purple color in the following picture.

Viki az izah.jpg

My first question: how to add such descriptions to pages? Second question: If the article contains more than 1 photo, how to define which photo will be shown in search (for examle Azerbaijan's flag in "Azərbaycan" page)? For both questions, give universal methods for all languages. Ki999 (talk) 11:57, 14 September 2018 (UTC)

@Ki999: See the Wikidata method at Wikipedia:FAQ/Editing#How do I edit mobile subtitles? It requires a Wikidata item for the page. I think the alternative feature used by {{Short description}} is only enabled at the English Wikipedia. Special:Version#mw-version-parser-function-hooks lists shortdesc, meaning that feature exists here. It is not at az:Special:Version#mw-version-parser-function-hooks. See mw:Extension:PageImages#Image choice. It is not possible to specify the image directly. PrimeHunter (talk) 12:44, 14 September 2018 (UTC)
@PrimeHunter: Thank you!

Commons will soon stop accepting some GFDL-only media

In hindsight, this is better suited for Meta as other projects are affected as well: m:Wikimedia Forum#Commons will soon stop accepting some GFDL-only media. Alexis Jazz (talk) 13:02, 14 September 2018 (UTC)

Who are our fellow Wikipedians?

OP blocked until he can convince another admin that he can edit without attacking other editors again. --SarekOfVulcan (talk) 18:24, 17 September 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I have done over 200,000 edits to Wikipedia articles while logged in, and a similar number (but I don't know what it is) while not logged in. And as in all cases, there are some aspects of Wikipedia that I am familiar with and others that I am not.

Before Wikipedia existed, I was aware of the International Workshop on Bayesian Inference and Maximum Entropy Methods in Science and Engineering, an annual conference at which persons, most of whom are professors in physical sciences, assemble to present their research findings to others in attendance. I attended this particular conference in 1991. Those who attend this conference take an unconventional view, outside the mainstream, of the role of probability theory in the sciences. There are many conferences at which professors in many fields, who are interested in a particular topic that attracts a small number of their colleagues, annually assemble to present to each other their latest findings or creations. Some of these are gathering of those who take some non-mainstream view, and many are not, but either way, it is not considered grounds for suspicion about one's competence or honesty that one participates in such a thing, and I never expected that anyone would think it is until I encountered a dozen-or-so Wikipedian who told me I was stupid or dishonest or otherwise deeply flawed because I couldn't see that such a conference is a scam.

It was asserted on a Wikipedia page about professors in health-related fields, one of them a surgeon in the medical school at Johns Hopkins University and one a professor of psychology at UCLA, and various others, that their reason for using the standard terminology of their fields was only to create a false impression of legitimacy (this is absurd and clearly dishonest), that they don't publish, or at least not on the topic of their common interest, outside of a journal that their group had founded (this is false, as may be quickly verified), and that they do not collaborate in research with others outside their group (this is false, as may be quickly verified).

I objected to those assertions as clearly libelous and I was told that I was wrong without any attempt of six persons asserting this to tell me why I was wrong or to argue or discuss this with me. There is supposed to be collegiality among Wikipedians, and merely issuing a definitive ruling on a matter about which one disagrees with a fellow Wikipedian while refusing to discuss or argue, is inconsistent with that.

One person wrote that professors in health fields were "using sciencey-sounding language to advocate something that is unquestionably commercially lucrative but which does not appear to have significant academic support". Note that:

  • professors were using the language of their own academic fields;
  • "unquestionably commercially lucrative". What? Since when is organizing conferences like this commercially lucrative? I don't know the details of finances of such things, but this is implausible. Can anyone tell me about this?
  • "which does not appear to have significant academic support." How so? That professors organize conferences is academic support. Just how much support constitutes being "significant" will bear examination. Generally disagreeing with prevailing views in one's field and organizing conferences of those who agree with one's own views is not considered justification for accusations of dishonesty; it just means one disagrees with a prevailing view.

And now to the point: I want to know who these people are (not their names, and not individually). Their refusal to argue or discuss the issues with fellow Wikipedians is an occasion for suspicion. I have heard it asserted that a lot of mudslinging happens on Wikipedia on politically charged issues or other controversial things, but only asserted; I have not seen that sort of thing, probably because my stomping grounds within Wikipedia have not included certain areas very much. The person who made the assertion about the "unquestionably" lucrative nature of organizing conferences among professors declined to answer my request for the specifics about that. His assertions about the amount of academic support not being "significant" is also something about which he declined to be specific after being asked.

A Wikipedian and his followers (apparently there actually are such things as followers; I don't know how that happens) who gather to simultaneously oppose the position taken by one Wikipedian should assume good faith and should be willing either to argue or discuss or instruct their interlocutor, rather than just giving orders. But it is not so. Is there something that should be done about this? Michael Hardy (talk) 16:35, 16 September 2018 (UTC)

Really? --Izno (talk) 17:17, 16 September 2018 (UTC)
Wikipedia:Drop the stick and back slowly away from the horse carcass GMGtalk 17:35, 16 September 2018 (UTC)
If you are frustrated because editors will not respond to your points, I welcome you to Wikipedia (which seems odd considering you have many times my Wikipedia experience) and refer you to WP:SATISFY. There is no objective mechanism by which stronger arguments prevail, except in the rare case of a clear policy connection, and the rest of us learn to live with that or leave. I and others are dealing with exactly such a situation today, losing a debate to a majority with lame arguments in a discussion with no clear policy connection. If the trend continues to the close, we will review WP:How to lose, say our respective personal versions of the Serenity Prayer, and move on. We won't come to the Village Pump and complain about it.
Suggest speedy close as wrong venue and/or forum shop. ―Mandruss  17:56, 16 September 2018 (UTC)
@Mandruss: You misunderstand. My question was meant literally. I was seeking information. I have not encountered anything like this situation before. Michael Hardy (talk) 19:28, 16 September 2018 (UTC)
Michael, for your own sake please let this go. Allowing things to keep gnawing away at you like this cannot be good for your soul. Shock Brigade Harvester Boris (talk) 19:53, 16 September 2018 (UTC)
@Shock Brigade Harvester Boris: As I said, I am seeking information. I do not understand the behavior of some people around here, and I didn't know people of that sort existed. Michael Hardy (talk) 22:34, 16 September 2018 (UTC)
You have been told why your "claims" are not actionable on numerous occasions by a number of different editors, but you simply did not accept "no" as an answer, nor would you accept all of these explanations as valid because it's not the explanation you are looking for, so you continue to seek for new venues to re-litigate. Your not the first person to be in a similar situation; it seems like plain texts cannot get through to you, so perhaps you need to meet an experienced editor in person to explain to you. I am sure you personally know a few of them; the best ones are probably your fellow mathematicians that are proficient in the communication style of Wikipedia. Alex Shih (talk) 00:39, 17 September 2018 (UTC)
@Alex Shih: (1) "Actionable" is not the point. They may be BLP violations without being actionable. We're not concerned with actionability here because of the "no legal threats" policy.
(2) I'm not trying to "re-litigate" anything; I am seeking information. I never said I'm the first person in this situation; I said I've never seen it before.
(3) If I've been told _why_ it's not a BLP violation, it was based only on falsehoods. There have been numerous factually incorrect statements by people who I think are gaslighting me because I've gone against their agenda. Nobody has addressed this question while attempting to be factually correct. For example, the claim that organizing these kinds of conferences among professors is commercially lucrative.
(4) Give me the diffs. Under the circumstances and in view of your past behavior, what you're doing looks like gaslighting. Michael Hardy (talk) 17:15, 17 September 2018 (UTC)
@Alex Shih: Let's be clear: I've been told that my observations lack merit, by people who were contemptuous of any discussion or argument with me, and who appear to have motives unrelated to the merits or demerits of what I said. Michael Hardy (talk) 18:15, 17 September 2018 (UTC)
More casting of WP:ASPERSIONs without a shred of evidence. Will this ever stop? Without a block that is. MarnetteD|Talk 18:18, 17 September 2018 (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.

RfC: Coverage of Roundup Cancer Case

If interested, please comment here. petrarchan47คุ 04:10, 17 September 2018 (UTC)

Legally Blondes 2

This redirect "Legally Blondes 2" is unnecessary, it needs to be deleted...."Legally Blonde 2" is correct --SrpskiAnonimac (talk) 10:39, 17 September 2018 (UTC)

@SrpskiAnonimac: This is not the place. See Wikipedia:Redirects for discussion. ―Mandruss  15:23, 17 September 2018 (UTC)
For which I nominated it shortly after the note. Wikipedia:Redirects for discussion/Log/2018 September 17#Legally Blondes 2. --Izno (talk) 15:57, 17 September 2018 (UTC)

fold3

Is there anyone out there who can guide me through a few simple questions regarding my efforts to open a fold3 account, with Wikipedia permissions? -Broichmore (talk) 11:00, 20 September 2018 (UTC)

Broichmore, have you applied for access to WP:Fold3 yet? User:Samwalton9 (WMF) could probably help you get started with Wikipedia:The Wikipedia Library. Whatamidoing (WMF) (talk) 16:56, 20 September 2018 (UTC)
@Broichmore: I see you were approved for a Fold3 account - are you having issues accessing or using your account? Samwalton9 (WMF) (talk) 09:06, 21 September 2018 (UTC)
Thanks for your help, Yes, no access; it's apparently been resolved now, I'll know for sure in a couple of weeks. Broichmore (talk) 10:33, 21 September 2018 (UTC)

The GFDL license on Commons

18:11, 20 September 2018 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(all)&oldid=638744879"
This content was retrieved from Wikipedia : http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(all)
This page is based on the copyrighted Wikipedia article "Wikipedia:Village pump (all)"; it is used under the Creative Commons Attribution-ShareAlike 3.0 Unported License (CC-BY-SA). You may redistribute it, verbatim or modified, providing that you comply with the terms of the CC-BY-SA