Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia
Jump to: navigation, search
  Policy   Technical   Proposals   Idea lab   Miscellaneous  

New ideas and proposals are discussed here. Before submitting:

« Older discussions, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140
Centralized discussion
Proposals: policy other Discussions Ideas

For a listing of ongoing discussions, see the dashboard.

Time to revive WP:NCHAR?[edit]

I've noticed that the majority of pages in Category:A Song of Ice and Fire characters seem to have serious fan-cruft problems and are written almost entirely as plot summaries. We also have articles on extremely minor characters like Khal Drogo who were played by (retroactively?) famous actors in the TV show and so are popular out of proportion with their importance in the books/show, and also out of proportion of what we could write about them.

I looked around for the appropriate notability guideline, and it turns out we don't have one -- the proposed guideline (Wikipedia:Notability (fictional characters)) was apparently abandoned because of lack of discussion. Lacking a solid guideline we have all this crap floating around the encyclopedia. I'm a big fan of WP:POKEMON, which I feel probably should have the status of a guideline given how widely accepted it is.

Drmies also expressed a similar view on his talk page a few months back, which is what originally got me thinking about this whole problem, but I'm not sure if he'd want to be pinged or not.

Thoughts?

Hijiri 88 (やや) 07:39, 7 June 2017 (UTC)

We can try to revive it; I myself also see the proposed guideline as a good idea, and it would be nice to have at least something about this. SkyWarrior 21:16, 7 June 2017 (UTC)

WP: NCHAR currently has a note saying it has become dormant, and is merely being kept for historical reasons. This may make people wonder what it is doing in Wikipedia, but I can see the value of the site. It would be more specific than WP: GNG, and would form a good template for guidelines on what characters from a novel, short story or play should have their own articles. Sometimes, it would seem obvious that certain characters, such as those playing the title role in Shakespearean drama, should have their own articles; sometimes, there may be room for more discussion on whether a character merits his or her own article. So, many thanks for drawing this set of guidlines to our attention - it could have value and worth. Vorbee (talk) 15:03, 8 June 2017 (UTC)

There's been nothing in how notability is handled that changes the last failed consensus for fictional element notability, leaving the default to the GNG, which most individual characters fail (That is, I cannot think of any other metric that would be able to presume that a character could eventually met the GNG). I would think it might be good to have a pseudo-notability guideline of what are the minimum qualities we need to see for a character article that we'd expect to be meeting the GNG, namely something about the character's development, and something about the character's reception, along with a brief fictional biography (this is where most character articles fail), but it doesn't make sense to make a new subject-specific notability guideline when there are no new criteria to be applied. --MASEM (t) 15:20, 8 June 2017 (UTC)
The problem with that page right now is that it is basically empty, it does not really say anything useful that may help to decide if the character is notable or not. Before discussing about turning it into a guideline, improve it yourself so that it actually seems like a guideline, and then ask for more users to provide opinions, propose changes or additions. One starting point: how do you set apart the notability of a character and the notability of the work that features him? And also note that "fictional character" is too broad a concept: you have characters from films, TV series, animated series, books, comic books, videogames, classic tales, myths, etc. The guideline should somehow take into account the nature of all those works and their publishing styles. Cambalachero (talk) 13:14, 9 June 2017 (UTC)
That's where a "how to get GNG notability for characters" guideline might come into play, rather than a "notability guideline". There are ways to distinguish character from the work, generally if the character gets extra attention in the development or reception sections beyond the reception that the ensemble cast/characters get. And this generally works well across all types of mediums, recognizing that what are RSes for the different mediums might change. (eg for video games, we expect them to be using sources outlined at WP:VG/S, for television, I'd expect more reliance on Variety, THR, EW, and other trade publications, etc.) But central still remains that a character is only really considered notable if they meet the GNG, and the only way reliably to do that is to have development details and reception (all secondary information), and far less focus on the primary details (fictional biography). --MASEM (t) 14:16, 9 June 2017 (UTC)

While you guys are discussing the whole guideline as attempt to limit fancruft, there is meta:Wikifiction (In-universe encyclopedia), a proposed project that can house all the fancruft that editors can be good at. Also, it's an ad-free version of Wikia. George Ho (talk) 13:37, 9 June 2017 (UTC)

There is a wiki focused on in-universe, which is already running and thriving: TV Tropes. Despite the name, it allows content from all sources of fiction. Cambalachero (talk) 14:27, 9 June 2017 (UTC)

On the subject of how to distinguish characters from their works, can I point out that this might be a guideline here? A character might have notability if his/her character has given rise to a word in the English language that will mean something beyond the book - for example, Scrooge in Dickens' A Christmas Carol. Vorbee (talk) 15:27, 9 June 2017 (UTC)

Checking things a bit further, there was a lot of discussion at Wikipedia:Notability (fiction), which aims to be about both fictional elements (including characters) and portions of a fictional work (such as episodes). I have not checked yet the content of the discussions or the rejected versions, but I noticed that those discussions are from 2010 and before. --Cambalachero (talk) 16:12, 10 June 2017 (UTC)
NFICT was one of my first policy and guideline discussions in 2007/2008. It was a mess, and even if it had not been, it's probably not necessary in this day and age. A handful of the participants in that discussion are still around, but most are not. --Izno (talk) 20:38, 10 June 2017 (UTC)
No new notability guidelines are needed or helpful:
1) Unsupported details can be removed via regular editing.
2) Articles with <2 RS'es, without any hope for more, can be merged to character lists, episodes in which they appear, etc.
What problem, exactly, exists that cannot be dealt with through this sort of regular editing? Jclemens (talk) 02:03, 19 June 2017 (UTC)
  • Per above, another subject-specific notability guideline is unnecessary, especially for fictional characters. We already have one discussion declaring GNG neither replaced nor superseded by SNG, but GNG is not a hard-and-fast rule. Other existing rules, like WP:Notability and WP:Deletion policy, are adequate as they are. Since that discussion, there's no point on making another notability guideline or a guideline that would fail for a few or several years. We might change GNG rule, but I guess it is either too soon or bizarre to others. An alternative is a proposed sister project, but I guess it won't please some others yet. --George Ho (talk) 02:42, 19 June 2017 (UTC)
It might interest readers of this proposal and its responses that Jessica(Merchant of Venice) is currently on Wikipedia: Articles for deletion list. Responses to this might be easier to make if WP: NCHAR were revived. Vorbee (talk) 17:19, 20 June 2017 (UTC)

Preserve the search term during search[edit]

Wikipedia helps disseminate information, a marvel of the modern era.

One minor point raised herein to help it to be even greater: when searching a term, the search term disappears in the resulting page. If one wants to modify the term and do another search, s/he has to type the entire word. For instance, if I want to change the word wikipedia to wikimedia by just retyping the 2nd half of the word, that would make thing faster!

This feature is common at many if not most of other websites such as www.dictionary.com. Wikipedia should be at least as good.

At least when one does a search that has a "redirect" one has "redirected from..." at the top - certainly this has been the case in my experience, but what have other people found?Vorbee (talk) 08:38, 16 June 2017 (UTC)

OK it does not always work - I have now had experience of clicking a blue link and not getting the "redirected from" note at the top - but in many cases, I have.Vorbee (talk) 19:12, 17 June 2017 (UTC)

  • I agree, it would be good to have this. Absolutelypuremilk (talk) 19:47, 17 June 2017 (UTC)
  • This was a feature that was added to the mobile app at first. During some user testing with non-technical users, we discovered it presented a huge usability issue: people had trouble finding the search function again afterwards. People frequently thought their old search query was the title, even though it wasn't uncommon for their query to be quite different from the page title. Given the fact our search interface is quite bad and outdated in general, it's not a good idea to add things that we know can cause usability issues. I'd also note that dictionary.com makes some pretty fundamental mistakes with their search feature—such as keeping the box highlighted after searching and navigating, meaning you can't use keyboard keys to scroll after searching—so treating them as some kind of golden standard for us to aspire to isn't a great idea. --Dan Garry, Wikimedia Foundation (talk) 13:46, 19 June 2017 (UTC)

Adding the watchlist button to hovercards[edit]

It would be helpful to be able to see whether an article was on your watchlist without having to click it. Would it be possible to add a similar star to the thumbnail of articles so that you can see if the article is on your watchlist (and maybe even add it to your watchlist)? Absolutelypuremilk (talk) 17:20, 15 June 2017 (UTC)

Interesting idea Absolutelypuremilk. I spoke to the product manager for Page Previews/Hovercards and she created a task to discuss this further. CKoerner (WMF) (talk) 15:20, 23 June 2017 (UTC)
Brilliant, thanks! Absolutelypuremilk (talk) 15:35, 23 June 2017 (UTC)

Adding {{Redirect category shell}} to all single-redirect-template redirects[edit]

Per a recent bot RfA, and Template:Redirect category shell/doc#Purpose, should {{Redirect category shell}} be added to all redirects which only contain a single redirect template? The template documentation explains how it is useful not only for single-{{R}} redirects, but also for 0-{{R}} redirects. Pinging the template's creator, Paine Ellsworth, for input.   ~ Tom.Reding (talkdgaf)  16:05, 17 June 2017 (UTC)

To clarify, this is specifically addressing the question "Should a bot do this task?", which is slightly different than whether it should be done. The estimate provided at the BRFA was that this would take 400,000 edits. ~ Rob13Talk 16:20, 17 June 2017 (UTC)
400,000 is a conservative estimate. I'll start another database scan with a much higher limit to get an accurate count.   ~ Tom.Reding (talkdgaf)  16:23, 17 June 2017 (UTC)
My guess is now ~3 million... AWB's database scanner runs out of memory if I set the result-limit to several million (approaching 1 GB it starts to freeze, emit errors, and misbehave; my system memory still has many GB free at that time). With a limit of 2M, it considers itself ~16.9% done with ~337k matches, corresponding to the saturation limit of 2M (337k/0.169 = ~2M), so I need to raise the limit. With a limit of 5M, it's ~11.7% complete with ~344k matches, or ~3M estimated total.   ~ Tom.Reding (talkdgaf)  17:40, 17 June 2017 (UTC)
I think the real question is "should this be done". If yes, then it makes no sense to do this manually rather than by bot. Since I'll evaluate the BRFA assuming there is consensus for this task, I'll recuse myself from giving me opinion here. One thing that should be done is to clearly explain exactly what the benefits of putting single templates within a shell, and what is proposed to be done with uncategorized redirects. Headbomb {t · c · p · b} 16:37, 17 June 2017 (UTC)
@Headbomb: My point-of-reference is cosmetic-only edits. No-one thinks cleaning up whitespace is a negative, just that having a bot perform high volumes of such edits is a negative. This task has the same potential, in my opinion, although I'm pretty neutral on it for the moment. ~ Rob13Talk 18:20, 17 June 2017 (UTC)
(edit conflict) I can give input on the basic question of whether or not to use the Rcat shell on singularly categorized redirects, but I don't know enough about the needs to speak to whether or not a bot should take up the task.
  1. Rcat shell may be used to fulfill its primary impact, which is to "standardize redirect templates (rcats). Its basic purpose is to simplify the process of tagging and categorizing redirects.
  2. The shell template is also used to hasten the learning curve for editors who get into categorizing redirects. No matter how many rcats are needed, from zero to an as yet unknown maximum (usually six to eight rcats), the "manifold sort" can be used to populate the Miscellaneous redirects category. That category is monitored, so editors can check back to see what rcats have been used, and they will know next time what to do with similar redirects.
  3. The shell has the ability to sense protected redirects, so no matter how many rcats are needed, from zero to the maximum, protection levels are automatically sensed, described, categorized and changed when appropriate.
For these reasons, it is considered useful to enclose one or more rcats within the Rcat shell, and to use the shell without rcats when unsure of the categorization needs.  Paine Ellsworth  put'r there  16:58, 17 June 2017 (UTC)
I would also like to note that if the bare Rcat shell is added without rcats by a bot to a lot of redirects, then the manifold sort category would become too unwieldy for just a few editors to efficiently administer. Please don't do that, because it would effectively defeat the purpose of the manifold sort.  Paine Ellsworth  put'r there  17:05, 17 June 2017 (UTC)
Please note, some exact examples of what the change will do are linked from in Wikipedia:Bots/Requests for approval/TomBot. — xaosflux Talk 00:13, 19 June 2017 (UTC)

Will the bot add the rcat shell even if there are no existing rcats on the page? If it does, that would totally overwhelm the manifold sort. TheMagikCow (T) (C) 10:55, 19 June 2017 (UTC)

Nope; the title of this proposal and the BRfA explicitly & exclusively target single-redirect-template redirects.   ~ Tom.Reding (talkdgaf)  11:19, 19 June 2017 (UTC)
Oppose making millions of edits to pages hardly anyone ever sees, which don't change the functionality of the page one bit, but which may help other users to make somehow better redirect pages in some way, perhaps. Very unclear which actual issue this is trying to solve. Fram (talk) 12:40, 19 June 2017 (UTC)
The main issue, I believe (but I could be wrong), is that this will automatically include protection levels, improve sorting, and make things more standard. Tom has been doing this mind-numbingly boring task semi-automatically for a while, and doing this by bot makes it much easier to ignore on watchlists, both for people who ignore all bots, or for those who'll ignore TomBot in particular (e.g. WP:HIDEBOTS). Headbomb {t · c · p · b} 14:24, 19 June 2017 (UTC)
Yes, Wikipedia has both sharpened and dulled various parts of my brain. On balance I suspect it has at least retained its curvature, but I could also be wrong.   ~ Tom.Reding (talkdgaf)  15:27, 19 June 2017 (UTC)
Support but only just. Adding rcat shell to single-rcat redirects does make a slight cosmetic change; one of the examples given at BRFA is [1] to [2]. Before the edit, the redirect had the text "from a fictional character" floating on the page with no context. Adding rcat shell encloses that text in another text box which adds the contextual information "this page is a redirect:". It's unlikely readers will notice that change, and it's unlikely most editors would not be already aware that the page is a redirect, but this helps slightly. Also standardizing redirect categorization and adding the other technical functionality of the shell. I'm strongly against having a bot add the shell to non-categorized redirects, that's pointless busywork that just creates a huge maintenance chore. Ivanvector (Talk/Edits) 13:50, 19 June 2017 (UTC)
Is slightly modifying the redirect templates (e.g. R from fictional character) then not the much simpler solution than going to 3 million redirects to add that shell? Just change what, perhaps 100 templates, to make them clearer, and be done with it. Fram (talk) 14:26, 19 June 2017 (UTC)
Some of the benefits would likely carry over (like protection/categorization) easily. But the improved appearance and standardization might not, or might be hard to achieve. It's probably worth exploring the idea however. Headbomb {t · c · p · b} 14:39, 19 June 2017 (UTC)
From a standardization perspective, to eliminate creep/inconsistencies and maintenance/updating, it is best to have 1 wrapper template than multiple {{R}}s that "self-wrap". Furthermore, potentially-"naked" {{R}}s would have to detect whether they have or have not already been wrapped, to avoid unnecessary nesting. If that's easy/not prone to error, then that might be the best way forward. Is that the case, though?   ~ Tom.Reding (talkdgaf)  14:48, 19 June 2017 (UTC)
Perhaps the individual redirect templates can be turned into redirects (hah!) to the shell then? Although I don't really see the need for standardization of the look of pages hardly anyone ever looks at anyway: it is important that these are categorized, but apart from that one could eliminate the text from all of these and nothing really would be lost. Fram (talk) 15:04, 19 June 2017 (UTC)
Yes, if all {{R}}s call a module (I suspect it'd have to be a module rather than standard template code) that is able to perform the same duties as {{Redirect category shell}} and were able to sense whether or not the calling {{R}} is wrapped in {{Redirect category shell}}, that would be ideal. I certainly don't have the expertise to answer that question though, and someone should be summoned here that can.   ~ Tom.Reding (talkdgaf) 
Yeah, I'm not really convinced that the category shell is the best solution to whatever problem we're trying to solve, if the category templates themselves can just be modified to produce similar code. Like, the category shell has protection-level-sensing code, why can't all of the rcat templates have that, and do away with the shell? Since that seems so obvious to me but I'm not a coder, I've assumed that option has already been explored and ruled out, and having the template shell is the only (or most desireable) way to achieve the desired result. If that's not the case, then let's back up. Ivanvector (Talk/Edits) 17:09, 19 June 2017 (UTC)
  • After further thought, I must oppose (and recuse from handling any BAG aspect of the BRFA going forward). The examples given by Tom indicate that the only change being made here is a box that says "This is a redirect". Ivanvector rightly points out this adds context to the redirect page, which initially had me leaning toward support until I recalled that the only way you actually see a redirect page is by clicking the link at the top of the page you're redirected to that says "Redirected from X". That means by the time you've navigated to a redirect page, you would already know it's a redirect. Alternatively, you can navigate to redirect pages by clicking certain direct links that editors leave in discussions, but at that point you're almost definitely in project space and should know what a redirect looks like. Yes, the wrapper template handles protection, etc. That's a good rationale for adding an option to Twinkle to add the wrapper when protection is added to a redirect. Protecting a redirect is very rare (template-protection being the only semi-frequent case that comes to mind), so I don't see that as justifying three million edits. I do want to thank Tom.Reding for quickly bringing this to the village pump when requested, and I will be happy with the outcome of this discussion whatever it is. This is the correct and drama-free way to handle potentially controversial tasks. ~ Rob13Talk 16:17, 19 June 2017 (UTC)
  • Oppose as pointless per above. (although I wouldn't object to a bot adding it on all protected redirects). In addition to what BU Rob13 said about "Redirected from" links, all redirect pages have "Redirect page" at the top, just after "From Wikipedia, the free encyclopedia", so the template doesn't actually serve the purpose of notifying people it is a redirect. Pppery 11:50, 21 June 2017 (UTC)
  • Support, if the edits are made very gradually. The wrapper template seems like a Good Thing™ on balance. Enterprisey (talk!) 19:32, 21 June 2017 (UTC)

Disable/opt-out option needed for sister projects search results[edit]

That about says it. It appears there have been RFCs & discussions about this new feature, I posted a query about it on VP:tech ( see here but apparently I was supposed to post here?... I don't need it in my editing, these sister project results visually clutter up the page plus the results I have been getting are not useful. YMMV, etc, but I'd really like to be given the (checkbox) option to opt-out. I think I am supposed to ping the folks from that discussion to this discussion so here ya go: @BlackcurrantTea:, @Lugnuts: @George Ho:. Thanks, Shearonink (talk) 06:05, 18 June 2017 (UTC)

  • Comment - I added this discussion to Template:Centralized discussion because the search results update affects everyone, including those unsigned (i.e. using IP addresses) and registered editors. --George Ho (talk) 06:17, 18 June 2017 (UTC)
  • I note that there was a community RFC (on VPP I think) that supported the inclusion of sister project results on the search page. Are you saying you want to make it so they don't appear for you personally? — This, that and the other (talk) 07:02, 18 June 2017 (UTC)
YES. Don't want it, don't like it, glad to have the code-fix posted below, think this should be an opt-in/opt-out checkmark-box under preferences. Shearonink (talk) 18:25, 18 June 2017 (UTC)
That's what Shearonink is trying to say. Isn't that right? BTW, here's the RfC discussion. George Ho (talk) 07:22, 18 June 2017 (UTC)
  • Support Just as Shearonink said, "I don't need it in my editing, these sister project results visually clutter up the page." I edit Wikipedia, or (rarely) Wikidata, not the sister projects. If I'm looking for information and want to include Wikiquote, Wiktionary, or other projects, I'll use a search engine. If I search Wikipedia, then I want Wikipedia results. For example, when I'm fixing typos, seeing that someone spelled "television" as "televison" at Wikivoyage is neither interesting nor helpful. It's visual noise, and I don't want it. BlackcurrantTea (talk) 07:25, 18 June 2017 (UTC)
  • Support I don't care about the other projects and this is just clutter. Lugnuts Fire Walk with Me 07:44, 18 June 2017 (UTC)
YES. SO much this ^^^ Shearonink (talk) 18:25, 18 June 2017 (UTC)
  •  Already available, just add
    div#mw-interwiki-results { display: none !important }
    
    to your own common.css. By the way, I notice some scarce interaction with sister projects: maybe wait and see for a few days, you could find out that the sister projects contain something of interest for yourself too! --Nemo 09:29, 18 June 2017 (UTC)
The search results I have been getting are not relevant to my editing and, also, are useless to my editing at Wikipedia, which is what I am here to do. EDIT. End of story. Shearonink (talk) 18:25, 18 June 2017 (UTC)
I know how you feel about the updated search results, Shearonink. They can look awkward to or frustrate a user. Therefore, I won't object to having the option to disable/opt-out if a user wants those results disabled. Also, I'll respect your wishes and allow you to make decisions, especially when the "disable" option happens. However, with those search results, more likely some editors would come to those pages and improve existing pages or create new ones. Also, sometimes it helps editors not to create any more dubious articles in Wikipedia or pages that would have meant for other sister projects. It even would prompt some or many editors to create less cross-wiki redirect pages than we have seen lately. Well, I created one page with a German-language title to redirect to a Wiktionary entry, but it got deleted (...because I was convinced into requesting deletion on it). Even when the results from those projects are disabled by user preference, any Wikipedia article may still likely be nominated for deletion, especially due to notability and/or content issues (like "Georgia for Georgians") or because it looks like either a definition page, a travel guide, a mere document, a page of a book, or a collection of quotes. Of course, I was discussing mainspace results. Unsure about what to do with results of other non-article namespaces from those projects. --George Ho (talk) 01:36, 20 June 2017 (UTC)
Bam! Thanks - that works a treat. Lugnuts Fire Walk with Me 17:51, 18 June 2017 (UTC)
Yes, thanks for posting the code-fix. I still think it would be great if this feature were available as a checkmark opt-in/opt-out on a registered editor's preferences. Shearonink (talk) 18:25, 18 June 2017 (UTC)
I agree. Thanks for the css fix; please make it a checkbox on the prefs page. BlackcurrantTea (talk) 03:58, 19 June 2017 (UTC)
  • Support - I can't think of any reason why we would not make this available as a configurable option in preferences. Ivanvector (Talk/Edits) 13:36, 19 June 2017 (UTC)
  • Support - It should be an option in preferences. — Godsy (TALKCONT) 00:27, 20 June 2017 (UTC)
  • Support opt-out, oppose disabling. I see how others could find this unnecessary and obtrusive, but as someone who occasionally translates stuff from other Wikipedias I find this quite useful. DaßWölf 02:43, 20 June 2017 (UTC)
I don't think anyone is suggesting disabling the feature (for everyone), but fwiw I would also oppose disabling. Ivanvector (Talk/Edits) 11:59, 20 June 2017 (UTC)
  • Comment. It is easy to create a gadget. Ruslik_Zero 17:53, 20 June 2017 (UTC)
  • Support opt out as a user preference. it shouldn't require figuring out more than that. So far, I too find it unhelpful, and I suspect so will many others as they come to notice it. I predict it will soon change to opt-in. DGG ( talk ) 22:12, 20 June 2017 (UTC)
  • Oppose - we already have way too many preferences. The sister project results don't interfere with using the search interface as normal and it's easy for anyone that doesn't like them to hide them using their User CSS. Kaldari (talk) 04:18, 21 June 2017 (UTC)
    • User CSS is relatively inaccessible. Not everyone knows how to use it. Opt-out tick box is much more accessible. Options should be accessible to all, particularly opt-outs. • • • Peter (Southwood) (talk): 14:39, 21 June 2017 (UTC)
    • Pinging Kaldari for response. George Ho (talk) 17:03, 21 June 2017 (UTC)
      • We know from Special:GadgetUsage that gadgets that do nothing but disable features are consistently among the least used gadgets. Adding lots of preferences just for the small number of people who don't like certain new features causes 2 problems: It makes the preferences interface overwhelming and less usable for everyone; It means that developers have to support more variations of the interface, slowing down future development. A good example of that is when we had 3 different versions of the WikiText editor depending on how many new features users wanted to opt-out of. This required building 3 different version of any features for the editor, such as RefToolbar. (We finally removed one of the opt-outs from the prefs last month, which hardly anyone had been using anyway.) Kaldari (talk) 17:49, 21 June 2017 (UTC)
  • I notified communities of just selected sister projects about this proposal. --George Ho (talk) 19:17, 22 June 2017 (UTC)
    Is it possible for the interwiki searches to be selective? I, for one, greatly value WP, Commons, and Wikispecies in my play/work at Wiktionary, but would find other projects less useful. DCDuring (talk) 19:30, 22 June 2017 (UTC)
    That would take an RfC discussion and a Phabricator task to do so, DCDuring. Right now, due to the results, we don't see multimedia (audio/visual) results from Commons here. --George Ho (talk) 19:38, 22 June 2017 (UTC)
    As two of the three projects I am interested in are not-yet/may-never-be included, my enthusiasm is a bit further diminished for the taxonomy-type contributing that I do most often. For other editing, WikiSource is helpful. I expect that those who contribute to en.wikt in languages other than English would value including pedia and wikt projects in their languages of interest. DCDuring (talk) 19:51, 22 June 2017 (UTC)
    I made a note at some other venues, including Wikibooks, saying that Wikibooks was included as part of search results by developers. However, they didn't realize that there was "no consensus" to include those results. Therefore, I filed a task at Phabricator. I also noted the error at WP:VPT#Requesting suppression on search result from Wikibooks. --George Ho (talk) 00:57, 23 June 2017 (UTC); modified, 15:25, 23 June 2017 (UTC)
    I saw that another proposal to include Wikibooks as part of search system is made at WP:VPP. --George Ho (talk) 22:09, 23 June 2017 (UTC)
  • Support Another configurable button (Opt in or out -either works) in preferences won't hurt anything. GenQuest "Talk to Me" 22:09, 22 June 2017 (UTC)
  • Lukewarm support for a selectable preference. Note that English Wikiquote has all of 30,000 pages, about .08% of English Wikipedia's total. I don't see those search results, at least, as being particularly disruptive to Wikipedia searches. bd2412 T 00:24, 24 June 2017 (UTC)

Bot to fix certain common comma issues in articles[edit]

I've been tinkering with code to fix certain common comma issues in articles in a way that doesn't throw up a whole bunch of false positives. Before I go further, I'd like to see if the community would actually support a bot running this task. To give you an example of the sorts of things I think a bot could do without running afoul of WP:CONTEXTBOT:

Consider phrases of the form "Before 2017". These dependent clauses universally need commas, but there's a potential context issue if they're part of a longer clause (e.g. "Before 2017 buildings were constructed, ..."). They also may not need a comma if they come at the end of a sentence (e.g. "He had never acted before 2017"). My solution is to make the edit only when it is followed by a pronoun or article (he, she, they, it, the, a, an) and only when the first word of the clause is capitalized (fixing the second issue). That limits what the bot would edit to things like "Before 2017, he ...", which unambiguously needs a comma. This is a very common grammatical error introduced by young people or non-native writers.

The regex for this particular fix is currently: ((?:As of|In|During|Before|After|Since|Until) (?:(?:January|February|March|April|May|June|July|August|September|October|November|December) )?(?:19|20)\d{2}) ((?:she|he|they|it|the|a|an) ) --> $1, $2

I've found zero errors in about ~300 edits when I've used this code semi-automatically, so it appears fairly robust.

Is this a bot the community would support if it could be demonstrated that the false positive rate is very low (<0.1%) or nonexistent? ~ Rob13Talk 13:26, 20 June 2017 (UTC)

There are few universally agreed-upon rules of English grammar. For example, I don't agree with your statement that "Before 2017, he ..." must contain a comma. I expect that many of the "corrections" you plan to make would be controversial, because of a lack of consensus for your ideas about English grammar. Jc3s5h (talk) 13:51, 20 June 2017 (UTC)
@Jc3s5h: There are certain types of commas which are controversial (e.g. Oxford comma), but the fact that an introductory dependent clause requires a comma is not one such example. It's an accepted grammatical rule that is present in all style guides, not "my idea". I would obviously never propose to make fixes like the Oxford comma, because those aren't true "fixes". ~ Rob13Talk 17:29, 20 June 2017 (UTC)
Actually, this is outright in our Manual of Style, and it states we need a comma after all dates, not just those in a dependent clause. See MOS:COMMA. ~ Rob13Talk 17:35, 20 June 2017 (UTC)
MOS:COMMA states we need a comma after all m-d-y dates. It says "Dates in month–day–year format require a comma after the day, as well as after the year ..." It does not say we need a comma after d-m-y dates. It does not say we need a comma when the year only is given. — Stanning (talk) 13:23, 21 June 2017 (UTC)
This is the kind of change that should be manually reviewed. There are assisted-editing frameworks that could help, and it is possible to use a database scan to make a list of articles to look at. But each change should be manually reviewed, rather than made completely automatically by a bot. Just as one example of a corner case, "Before 2012 or 2013, she ... ". I'm sure there are more examples like that one. — Carl (CBM · talk) 14:00, 20 June 2017 (UTC)
@CBM: Well, that edit wouldn't be made by my regex. The point isn't to make all beneficial grammar changes, just the ones we can be sure would be correct. I certainly invite editors to point out corner cases, but what you stated isn't a false positive. I've already run a database scan, and it returned 400,000 pages. That's a bit outside the range of what I can do semi-automatically. ~ Rob13Talk 17:29, 20 June 2017 (UTC)
@BU Rob13: Ah, I see, thanks. I did check MOS:COMMA, which only mentions dates in month-day-year format. I also checked the Chicago Manual of Style, which says "An introductory adverbial phrase is often set off by a comma but need not be unless misreading is likely." (section 6.36) and gives this as a correct example: "After 1956 such complaints about poor fidelity became far less common." (no comma). So there is not a unanimity in style guides that a comma is required. — Carl (CBM · talk) 18:35, 20 June 2017 (UTC)
Also in WP:MOS I find "Since 2001 the grant has been 10,000,000 Swedish kronor" as a correct example. — Carl (CBM · talk) 18:41, 20 June 2017 (UTC)
Hi BU Rob13, personally I don't really support a job of 400000 edits to "add a comma" here; I don't see it is making a significant impact on readers - and don't see it alone as a "hook" if you wanted to scope creep this to 'comma adder + a pile of genfixes'. Seems like this should go in to one of those other "gen fix" piles. — xaosflux Talk 18:28, 20 June 2017 (UTC)
Fair. I'm not that attached to the idea myself, but I have been trying to think of "substantial" genfixes to perhaps reduce drama surrounding the cosmetic genfixes. ~ Rob13Talk 20:06, 20 June 2017 (UTC)

I support this task. -- Magioladitis (talk) 20:06, 20 June 2017 (UTC)

As I pointed out above, the MOS does not require the comma, and even gives "Since 2001 the grant has been 10,000,000 Swedish kronor" as an example of an acceptable style. — Carl (CBM · talk) 20:10, 20 June 2017 (UTC)
@CBM: That sentence is being pulled a bit out of context. It isn't giving appropriate style for commas. It's giving appropriate style for currencies. The lack of comma seems to be an error unrelated to the section its in. ~ Rob13Talk 00:43, 21 June 2017 (UTC)
@BU Rob13: And the Chicago Manual of Style explicitly saying that commas of that sort are optional? — Carl (CBM · talk) 02:17, 21 June 2017 (UTC)

This should be an AWB script, not a bot task. It will inevitably hit some false positives, which aren't worth the minuscule benefit of the change. It should only be done with live human review, IMO. Kaldari (talk) 04:23, 21 June 2017 (UTC)

  • BU Rob13, a comma isn't needed after a short introductory clause such as "in 2017". See, for example, Hart's Rules, pp. 75–76: comma not essential if the introductory clause is a short one specifying time or location: "Indeed, the comma is best avoided here so as to prevent the text from appearing cluttered." SarahSV (talk) 06:45, 21 June 2017 (UTC)
    I (and my grammar instinct) agree with SV on this point. --NSH001 (talk) 09:51, 21 June 2017 (UTC)
    Our manual of style disagrees, as do many style guides. MOS:COMMA. In any event, I've pretty much withdrawn this. ~ Rob13Talk 15:06, 21 June 2017 (UTC)
    Although the proposal may be withdrawn, I want to point out for postierity that MOS:COMMA only mentions "Dates in month–day–year format" - these are not what is being discussed here, which are plain years without month or day. — Carl (CBM · talk) 15:10, 21 June 2017 (UTC)

WikiProject Recommendations[edit]

Imagine you're a newcomer and you join Wikipedia and make a couple edits on Waffle and 2015 World Pastry Cup. It mostly goes OK. A few minutes later you get a message thanking you for your contributions and inviting you to check out some work lists from User:WikiPancake -- a member of the local "Welcome squad" at WikiProject Food and Drink. I'm trying to figure out how to recommend newcomers to WikiProject organizers or maybe even to recommend WikiProjects to newcomers. What do you think? Check out my project proposal at this meta-page. Bobo.03 (talk) 16:17, 20 June 2017 (UTC)

The projects that most need recruits are excluded from your study. Whether this will introduce any bias is another question. I would guess some but not much. • • • Peter (Southwood) (talk): 18:44, 21 June 2017 (UTC)

If one goes to the talk page of an article, one normally sees - quite clearly - messages stating that this article is under the scope of several WikiProjects. Possibly, the existence of WikiProjects would be more conspicuous if the "this article is within the scope of these WikiProjects" logo headed the article and not the article's talk page?Vorbee (talk) 15:09, 21 June 2017 (UTC)

Wikiprojects are not encyclopaedic content and are therefore unsuitable for inclusion in the main article space. They would indeed be more visible, but would have to be kept out of the actual article text. There is also the problem of inactive projects, and projects where the activity fluctuates unpredictably. Do we want to list them at the top of articles? • • • Peter (Southwood) (talk): 18:37, 21 June 2017 (UTC)