Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

New ideas and proposals are discussed here. Before submitting:

• Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
• Consider developing your proposal at Village pump (idea lab).
• Proposed software changes should be filed at Phabricator (configuration changes should have gained a consensus).
• Proposed policy changes belong at Village pump (policy).
• Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
• Proposed new wikis belong at meta:Proposals for new projects.
• Proposed new articles belong at Wikipedia:Requested articles.

« Archives, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

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

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.

---

Result:

This discussion was well-attended but centred around questions that are complex in detail. Briefly: many articles currently use a template, eg {{commons category}}, to transfer readers inter-wiki to related content hosted by Wikimedia Commons. Those templates take a parameter that hardcodes the link to a given page at Commons. This proposal seeks to remove that parameter. Consequently, cataloguing of the connections between a given English Wikipedia page and the related content at other Wikimedia projects would be passed more fully over to the volunteers at Wikidata.

Some editors expressed doubts about more fully passing this responsibility over. The responsibility already exists in the form of the sidebar of all Wikipedia articles. These doubts are not new among the English Wikipedia community. I should clarify that personally, I am generally content to go along with the current editorial custom (about all matters of form or technique, eg citation format) on articles that I edit; I have no view either way on the issue.

The majority of editors in this discussion supported the proposal, which was presented in a clear, balanced manner. Nevertheless, a significant minority objected the proposal outright. Additional minorities objected (1) out of concerns about how most use cases would play out or (2) on the grounds that some detail around implementation was unclear.

On balance, I determine that there is consensus in this discussion to conditionally allow the proposal. Mike Peel and other editors may develop the proposed implementation – but are required to return to the community with the result of testing for further approval. AGK ■ 17:05, 7 October 2018 (UTC)

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 (t • c) 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)
      • For some additional background, see Template_talk:Commons_category#The_next_steps_with_this_template_and_Wikidata - people there didn't want to get rid of this template completely. Thanks. Mike Peel (talk) 11:16, 28 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 [1] 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 [2] 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 (talk ⋅ contribs) 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. GMG^talk 19:21, 17 September 2018 (UTC)

  @GreenMeansGo: The first part is what this RfC is about (plus the bot edits to remove redundant information). The second part is possible, but is a different conversation/bot task. Thanks. Mike Peel (talk) 22:27, 23 September 2018 (UTC)

  @Mike Peel: Yes the second part was just banter. But is that the planned implementation? If we can manually override it by providing a parameter, the no one should have any worries, because the people who have worries about WD can just provide parameters in their article. GMG^talk 23:54, 23 September 2018 (UTC)

  @GreenMeansGo: WP:OWN ... but the plan would be to remove the parameter where it is the same as on Wikidata, and adding it back again would be kinda pointless. Thanks. Mike Peel (talk) 00:00, 24 September 2018 (UTC)

  Yes, OWN is a thing in the context of a single project. But if you don't think there is a great deal of OWNERSHIP, between projects I think you're kidding yourself. En.wiki in particular I've seen has been particularly hostile to encroachment by basically any other project. GMG^talk 02:01, 24 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)

Any answer to my question on changing links? -- PBS (talk) 18:19, 22 September 2018 (UTC)

@PBS: Apologies for the slow reply. I deliberately wrote the proposal with background information, and also with wider scope than just two templates, as I think there are more templates out there that do something similar - see Category:Wikimedia Commons templates - and I didn't want to tie this down to a specific template change. I'm sorry that it wasn't succinct enough for you. The idea is that we use Wikidata where the links are empty, and bot-remove links where they are the same / need fixing. If they still need locally overriding, though, then that would still be possible in the same way as it currently is. Thanks. Mike Peel (talk) 22:25, 23 September 2018 (UTC)

Mike Peel regarding bot-remove links [which] need fixing, bypassing a commons-redirect is trivially appropriate regardless of whether Wikidata is involved. Any other interpretation of "fixing" must be clearly defined before even considering automated deletion of EnWiki values in favor of Wikidata values. If an existing value points anywhere else then I expect human examination will likely be needed to check how/why it needs fixing, even if the target is a non-existent page, nonsensical, or corrupt. Alsee (talk) 12:17, 28 September 2018 (UTC)

• Oppose because of User:Mike Peel's comment "and also with wider scope than just two templates, as I think there are more templates out there that do something similar" as User:Mike Peel is asking for a blank cheque. I think that the wording of the RfC is complicated and misleading. If this RfC is closed and another one is started for just two templates ({{Commons category}} and {{Commons}}) then I will reconsider my opinion. -- PBS (talk) 06:44, 24 September 2018 (UTC)

@PBS: A possible outcome of this RfC is only support for experimentation with those two templates. How do you feel only about that? {{Commons category}} is used 680,000 times and template {{Commons}} is used 745,000 times, so we already are in blank check territory for fundamentally altering the Wikimedia cataloging standard for billions of user experiences. In your comments above you say that if the Wikidata link breaks then that would cause a break in the English Wikipedia experience, which is true. Can you say more about why that is a problem? We have no hard data about the efficacy of the current system or the Wikidata system. What kind of evidence or assurance would you expect to see in place to support a change? Blue Rasberry (talk) 18:13, 24 September 2018 (UTC)

@PBS: I don't see it as a blank cheque, but as permission to move this to the next steps of working on the template changes (with discussions about the changes on the talk pages), and any bot edits would have to go through a bot approval process. Plus course-correcting discussions as things go to tackle any issues/disagreements. This is the start of the discussions about this ("do we want to go in this direction"?), not the end. Thanks. Mike Peel (talk) 21:01, 24 September 2018 (UTC)

See the relevant ArbCom discussion that Compassionate727 mentioned, specifically the section "Crosswiki issues: Motion" and within that "(B) To allow the English Wikipedia community to decide the policy issues involved, the Arbitration Committee recommends that a request for comment (RfC) be opened". I will not support an RfC that could be interpreted as a blank cheque against that ArbCom discussion.-- PBS (talk) 07:49, 25 September 2018 (UTC)

If this RfC was closed and a new one raised to that specifically and clearly covers just {{Commons category}} and/or {{Commons}}, with the ability of manual override via a parameter, then I would be willing to consider supporting it. -- PBS (talk) 07:49, 25 September 2018 (UTC)

As an alternative you could consider using {{Interlanguage link}} "for experimentation" in place of the two currently specifically mentioned in this RfC, because it involves inter language links, which are already implemented. -- PBS (talk) 07:49, 25 September 2018 (UTC)

• Strongly support, because it is indeed difficult to update links to moved categories, and if something is broken on Wikidata one can almost always as easily fix it there as in enwiki itself. Wikisaurus (talk) 17:36, 25 September 2018 (UTC)
• Support per Robby, let's help the people who've been working tirelessly on maintaining the local template links. --Nemo 19:12, 3 October 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)

@Mike Peel: just a brief note here, because this has been thoroughly discussed at Wikidata. No, the two Wikidata items should not be merged; they are distinct taxon names with their own separate entries in taxonomic and other databases. The core problem, as noted above, is that Wikidata imposes 1:1 links when these are not present in the information it is supposed to be modelling, so its model is at best incomplete and at worst erroneous. For a non-taxonomic example, consider our Berry and Berry (botany), which should connect to one article in language wikis that don't make the same ordinary language/botanical language distinction. Peter coxhead (talk) 08:03, 24 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.

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:

• From Night and Day (disambiguation page):
  • Night and Day (Parker novel)
  • Night and Day (Woolf novel)"

I propose the following:

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

Examples for Night and Day:

• • Night and Day (Robert B. Parker)
  • Night and Day (Virginia Woolf)

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)

Also, specifying by media type gives more worthy information in an article's text, where many editors might rather omit a meaningless name from an article's link. If specifying art by author's name got more conventional, then sure. With more author's having longer and longer bibliographies, I don't envision that happening in any way foreseeable.

2600:1702:1740:2CA0:E999:AB0B:FB6E:FCC2 (talk) 09:26, 28 September 2018 (UTC)

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)

• Oppose I don't see this as a major problem, and the tried-and-true approach of complaining on WP:AN if the backlog is severe enough (more than 75 articles to review or 48 hours) should be sufficient. There's no issue with a rate-limited opt-in reminder system if people want that. power~enwiki (π, ν) 22:03, 24 September 2018 (UTC)
• (Summoned by bot) Oppose an opt-out system, but an opt-in system seems useful. I am guessing that enough editors would volunteer to be pinged once the backlog reaches a certain size. Pinging PCRs without their approval may cause more annoyance than it is worth. Hrodvarsson (talk) 00:09, 3 October 2018 (UTC)
• Support if opt in - this would be seriously irritating to be notified of for random people making up the enormous pending changes user right. However an opt-in system has something to say for it. I'd suggest 60 articles/36 hours as a better point for this to occur. Nosebagbear (talk) 14:46, 6 October 2018 (UTC)

Prevent new users from allowing search engine indexing of user pages

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Y It's a blizzard and there's unanimous consensus to restrict indexing-capabilities to Extended-Confirmed-Users.∯WBG^converse 04:38, 7 October 2018 (UTC)

---

Should we prevent new users from indexing pages in the user namespace?

Recently, a new edit filter was created which disallowed new users indexing pages in userspace. The filter was later set to log because there wasn't a custom warning, and also there has not been consensus for disallowing userpage indexing by new users. Something like this was suggested in the discussion of this (failed) proposal, so this proposal is to gather consensus on this. ^Semi_Hypercube ✎ 23:28, 24 September 2018 (UTC)

Also the main reason for disallowing page indexing in userspace for new users would be to deter spammers. I forgot to mention this. ^Semi_Hypercube ✎ 00:00, 25 September 2018 (UTC)

Also I'm perfectly fine if userpage indexing gets restricted to extended confirmed users or even new page reviewers, as suggested below. ^Semi_Hypercube ✎ 12:41, 27 September 2018 (UTC)

Comments

• Support per WP:NOTWEBHOST and the ongoing torrent of spam. SemiHypercube, this proposal doesn't define "new user". The linked filter only disallows this for users with fewer than 20 edits, regardless of account age; is that the proposal? I'm still supporting because I'd favor the software silently disallowing this for all users, but that's probably not going to be popular. So I'll propose allowing this for extended confirmed users only but I'm also fine with the filter as-is. And admins, if you want another reason to support this, CRTL-F my most recent deleted userspace contribs for "G10". Look at how long some of those pages lasted. I don't think any were indexed, but I doubt anyone would have noticed if they had been. Suffusion of Yellow (talk) 00:44, 25 September 2018 (UTC)

  I think "new user" can mean any non-confirmed user (that's actually what I intended it to apply to when I suggested here.) ^Semi_Hypercube ✎ 01:08, 25 September 2018 (UTC)

  • The proper permission for this is patroller, because that's the same threshold we require to make spam visible to Google in mainspace, and the overwhelming majority of these are deliberate attempts to specifically evade the initial noindexing of mainspace. Some data here and (other than the dumpster fire that is my user js) here. Should also be extended to other namespaces besides User: that are instantly indexable via keyword, because that's where they'll instantly go. —Cryptic 02:00, 25 September 2018 (UTC)
• Support. I agree that this should be the default for all userpages (with opt-out available). I'd like to see that argument for people indexing userpages as being a net benefit to the project or society in general. I can't think of one right off. If it's not a net benefit let's not have it. We're taking about just new users here though, and I don't think there should be an opt out for new users -- don't let them do it all, unless a net positive benefit can be demonstrated. (What should be the criteria for "new user" I'm not sure, whatever you guys decide is OK with me.) Herostratus (talk) 09:14, 25 September 2018 (UTC)
• Support with either Patroller-eligible status (90d/500 article edits) or ECP status (30d/500 edits) and for both userpages and user talk pages. I don't see any real benefit to anyone when it comes to leaving userpages NOINDEXed. My big concern with this is that these users may resort to using their user talk pages for this sort of thing, but that's easily cut off at the pass by also NOINDEXing user talk pages with the same threshold. —Jeremy v^_^v ^Bori! 19:00, 25 September 2018 (UTC)
• Support making the current edit-filter prevent edits; I see no false positives. I'm not sure why any pages in user space should ever be indexed; Wikipedia is not a web host. power~enwiki (π, ν) 19:05, 25 September 2018 (UTC)

  It can be useful for cross-project users that want enwiki to be the primary search result, since noindex userspace is not WMF global. For example, I index my page so a google search for "xaosflux wikipedia" is most likely to land you at User:Xaosflux as opposed to w:din:Dulooi:Xaosflux. — xaosflux ^Talk 19:58, 25 September 2018 (UTC)

  Additionally, some user-space essays may be good to index. Agree with the general problem though: newer users try to index inappropriate pages. — xaosflux ^Talk 20:00, 25 September 2018 (UTC)

• Support restricting this to patrollers and above or EC and above. I find it unlikely that someone with under 500 edits would fall under the exceptions Xaosflux posted above, and if they did, an edit request would do the job. Daß Wölf 00:08, 26 September 2018 (UTC)
• Support what Jeske proposed and echoing DW above me. I can see the exceptions that xaosflux brings up, but these should mitigate those concerns. Killiondude (talk) 00:48, 26 September 2018 (UTC)
• Support TonyBallioni (talk) 00:49, 26 September 2018 (UTC)
• Support Restricting this to extended confirmed users. –Ammarpad (talk) 13:22, 26 September 2018 (UTC)
• Support Restricting this ability to extended confirmed users and patrollers per Jéské Couriano and Daß Wölf's statements above. This should also be implemented on any other user-indexable namespace per Cryptic's comment above. — AfroThundr ^{(u · t · c)} 18:19, 26 September 2018 (UTC)
• Support - I see no legitimate reason to index user pages, even less so those of spammers who just created an account. I don't think this is enough (especially if it allows confirmed users rather than extended-confirmed+), but it's a step... —PaleoNeonate – 18:49, 26 September 2018 (UTC)
• Support. I prefer a silent denial i.e. nothing happens to prevent the addition but adding the tag has no effect. This is fine, however. MER-C 19:57, 26 September 2018 (UTC)
• Support - new users probably do not have any reason to index anyway, so I support making it require ECU/Patroller only. Kirbanzo (talk) 01:46, 27 September 2018 (UTC)
• Support The definition for new users is very reasonable and per WP:NOTWEBHOST. – BrandonXLF ^(t@lk) 02:26, 27 September 2018 (UTC)
• Comment: SemiHypercube, please clarify the meaning of the jargon "users indexing pages" in your post: What it means is allowing search engines like Google to index a page (this is done by adding an __INDEX__ tag to the page, which overrides the default disallowance of such indexing). --Pipetricker (talk) 10:19, 27 September 2018 (UTC)
• Support - the current handling seems to leave an unnecessary loophole. And the limit should be set to extended-confirmed as mentioned by other editors above. Autoconfirmed is far too easy to circumvent - self-promoting users who are aware of the indexing mechanics will not be stopped by such a low hurdle. GermanJoe (talk) 12:05, 27 September 2018 (UTC)
• Comment - The proposal itself aside, if implemented, this should go hand in hand with extended confirmed status. Syncing it with patroller would be confusing because that user right is not automatically granted (even though this is through an edit filter and not part of any right). Additionally, I do not see any affinity between this and the patroller right. — Godsy ^(TALK_CONT) 12:56, 27 September 2018 (UTC)

  I'm thinking that's mostly to account for the possibility of someone gaining patroller rights before extended-confirmed? Seems remote, considering the requirements for the right would necessitate being EC anyway. — AfroThundr ^{(u · t · c)} 03:26, 28 September 2018 (UTC)

• Support (from CENT) till either AP90d or EC30/500 ^Thanks, L3X1 ◊distænt write◊ 22:27, 28 September 2018 (UTC)
• (Summoned by bot) Support EC only. But some spammers are smart too - we've already seen some get the correct permissions to bypass AfC when attempting to create new articles, so we shouldn't think that the smart ones won't get EC if they know of this loophole. Best, Barkeep49 (talk) 04:48, 29 September 2018 (UTC)
• Support per WP:NOTWEBHOST and should be extended to extended confirmed .Pharaoh of the Wizards (talk) 05:39, 29 September 2018 (UTC)
• Support restricting to extended confirmed users. the wub "?!" 16:30, 29 September 2018 (UTC)
• Support I can't think of a legitimate reason as to why a new user would do this. To EC level please. talk to !dave 20:00, 29 September 2018 (UTC)
• Support, but I also would support preventing all users from allowing search engine indexing of their user pages. --Metropolitan90 (talk) 17:40, 30 September 2018 (UTC)
• Support I see no valid reason not to support what Metropolitan90 has said, too. Nick Moyes (talk) 21:20, 30 September 2018 (UTC)
• Support restrict to extended confirmed please. funplussmart (talk) 11:58, 1 October 2018 (UTC)
• Support No good reasons for users to index their user pages on the ground of WP:NOTWEBHOST and mitigate self-advertising/promoting. If it is needed for special reason, then request permission from an admin. CASSIOPEIA^(talk) 14:21, 1 October 2018 (UTC)
• Comment Wait, we could index our user pages? I genuinely thought this was disabled on some basic site-wide level. XOR'easter (talk) 02:05, 3 October 2018 (UTC)
• Support though my vote is probably not needed. -- Taku (talk) 06:33, 3 October 2018 (UTC)
• Comment @SemiHypercube: this is about Google and Bing, etc right? Not about https://en.wikipedia.org/w/index.php?search ? Alexis Jazz (talk) 08:09, 3 October 2018 (UTC)

  @Alexis Jazz: Yes. Disallowing allowing page indexing (now there's some confusing wording) of user pages by new users would prevent them from letting the pages appear in Google or Bing (by adding a __INDEX__ tag to the page) when one does a search. It does not affect Wikipedia's own search engine. (otherwise one would never be able to search userpages) ^Semi_Hypercube ✎ 10:41, 3 October 2018 (UTC)

• Support but it doesn't go far enough The whole of user-space, and user-talk-space should be permanently noindexed, without any exceptions or any ability for any users to override it. Not new users, not EC users, not even admins, there is simply no valid reason for ever exposing any userspace content to external search engines, no exceptions. Google, Bing, etc. should never even know that user-space exists. Roger (Dodger67) (talk) 10:55, 3 October 2018 (UTC)
• Support up to extended confirmed. There's no reason why a userpage for a user which does not meet the EC criteria would need to have an indexed userpage. ---- Patar knight - ^chat/_{contributions} 19:36, 3 October 2018 (UTC)
• Comment - Is there a way for a user to turn off indexing of their own user pages? --Nessie (talk) 20:20, 3 October 2018 (UTC)

  @NessieVL: Any user can use the __NOINDEX__ magic word to unindex their user page. ---- Patar knight - ^chat/_{contributions} 20:46, 3 October 2018 (UTC)

  @NessieVL and Patar knight: Pages in User: space are noindexed by default (this has not always been the case, it was changed about three years ago). If desired, user pages may be indexed, but only if explicitly instructed, for instance using __INDEX__. --Redrose64 🌹 (talk) 22:11, 3 October 2018 (UTC)

• Support L293D (☎ • ✎) 01:40, 4 October 2018 (UTC)
• Support EC only. Beyond My Ken (talk) 04:43, 4 October 2018 (UTC)
• Support - Although personally I believe New users (or those that aren't a patroller or EC) should have their userpages non-indexed by default with no ability to make it indexed - I feel that would be much better but then again this proposal is better than nothing at all. –Davey2010^Talk 12:16, 4 October 2018 (UTC)
• Support Restricting this at least to extended confirmed users. Kudpung กุดผึ้ง (talk) 13:44, 4 October 2018 (UTC)
• Support - will help to reduce the impact of WP:NOTWEBHOST violating user pages. Dreamy Jazz 🎷 ^{talk to me | my contributions} 15:11, 4 October 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.

Removing genres from music infoboxes

There is an RFC on removing genres from music related infoboxes at WT:Manual of Style/Infoboxes#Request for comment on removing genres from musician, album, and song infoboxes — BillHPike (talk, contribs) 03:12, 28 September 2018 (UTC)

Move references embedded in sub-section headings

This is a proposal for a bot (as bot writer). There are currently about 14,400 cases where a reference is embedded in a sub-section heading. The refs can be moved into the section body.

Before (from Belgium):

=== [[Larger urban zone|Functional urban areas]]<ref name="europa">{{cite web|url=http://appsso.eurostat.ec.europa.eu/nui/show.do?dataset=urb_lpop1&lang=en|publisher=appsso.eurostat.ec.europa.eu|title=appsso.eurostat.ec.europa.eu/nui/show.do?dataset=urb_lpop1&lang=en|accessdate=6 January 2017}}</ref>===

After:

=== [[Larger urban zone|Functional urban areas]]===
Source: <ref name="europa">{{cite web|url=http://appsso.eurostat.ec.europa.eu/nui/show.do?dataset=urb_lpop1&lang=en|publisher=appsso.eurostat.ec.europa.eu|title=appsso.eurostat.ec.europa.eu/nui/show.do?dataset=urb_lpop1&lang=en|accessdate=6 January 2017}}</ref>

MOS:HEADINGS (fourth bullet) should "Not contain citations on the same line" as the section title. They make a mess of TOCs and edit summaries and are unnecessary. Typically done to indicate that all the information in that section came from that source – because they don't know where else to put the ref. A Source: at the top resolves the MOS issues and retains the reference information. -- GreenC 14:23, 1 October 2018 (UTC)

Discussion

• Proposal came out of a discussion on Wikipedia_talk:Manual_of_Style#Why_should_section_headings_"Not_be_phrased_as_a_question"?. -- GreenC 14:23, 1 October 2018 (UTC)

  @BarrelProof, J. Johnson, and Redrose64: -- GreenC 14:25, 1 October 2018 (UTC)

• Reasonable proposal, but it really only gets us from "bad" to "not great". Which is wiki, I suppose. Maybe it should be in AWB gen fixes though/also? --Izno (talk) 14:56, 1 October 2018 (UTC)
• There shouldn't be a space before a <ref> tag, per WP:REFPUNCT. Otherwise, I think it's a good idea. —BarrelProof (talk) 23:39, 1 October 2018 (UTC)

Three points. 1) More precisely, it should be "no space between terminal punctuation and a <ref>." (There are some cases where I think a space works, just not after punctuation.) 2) We should not confuse notes, created with <ref> tags, and citations, which notes generally contain. 3) Alternatively, would it be useful to have some kind of tag for "misformed heading"? ♦ J. Johnson (JJ) (talk) 23:58, 1 October 2018 (UTC)

This is drifting off-topic a little, since this doesn't apply here, but it's not just a matter of when there is a terminal punctuation mark. WP:REFPUNCT says "The ref tags should immediately follow the text to which the footnote applies, with no intervening space (except possibly a hair space, generated by {{hsp}})." Personally, I think it's a better idea to do something that fixes the problem than to do something that tags the problem, although I would hope that whoever is operating this bot would keep an eye on what it is doing and not just blindly let it do its thing. —BarrelProof (talk) 04:24, 2 October 2018 (UTC)

Of course I would. I'm used to running bots that make 100s of thousands of edits so 14,000 is no big deal. The way it's done is 1 edit. Then 2, 4 etc.. then a couple rounds of 100 .. manually checking all the way and stopping and fixing bugs. Then a couple 500s (manual check). 1000 (spot checks). 5000 (wait a few days for feedback). Then.. It's not like pressing "go" until 14,000 are done and clean up the mess after, much harder and uncomfortable that way :) -- GreenC 20:46, 2 October 2018 (UTC)

I don't see tagging as an end result, but as the start of a process. E.g., tagging could put an article into a special tracking category, and basically advise of a proposed change. There could be an option for anyone objecting to the proposed change to tweak a parameter, which would then shift the article to a different category for further discussion. Otherwise, after some period (two weeks?) the bot can be turned loosed on the articles remaining in the tracking category. While questioned bot edits doesn't seem to be a big problem re REFPUNCT, there are other areas where a process like this could reduce grief and drama by handling concerns with bot-edits proactively rather than retroactively. ♦ J. Johnson (JJ) (talk) 22:36, 3 October 2018 (UTC)

11 years ago, I made a mistake

Frank Loria was a famous football player who later became a coach at Marshall and died in the Marshall plane crash in 1970. On July 3, 2007, I noticed that his article lacked a photo and so I dutifully uploaded his official bio photo from Virginia Tech and tagged it as fair use. It seemed reasonable. He was long dead so surely unless we were to engage in grave-robbing, we would not find a free replacement photo. Secure in the knowledge that I was complying with WP:NFCC#1 (which was then rather new), I uploaded the photo. But in reality, we have every reason to expect a free photo of him. All anyone ever had to do is go to the Virginia Tech library and there are plenty of photos of him from publications that bore no copyright notice and are thus public domain. I'm sure Marshall probably has photos of him as well. At some point, Virginia Tech digitized all of their old yearbooks - and in the ones I have looked at I have yet to see a copyright notice, so all of the photos - including ones of Frank Loria - are public domain. So what I would like to propose is that we tighten WP:NFCC#1. If someone was a public figure in the United States prior to January 1, 1978, we have every reason to expect that there exists a publication that published a photo of them without a copyright notice and until a search is performed that includes visiting a university library near their home location or some other equivalent offline source where one might expect to find a photo of them, we should not accept that WP:NFCC#1 has been met. (WP:NFCC#1 does not mean merely that we can't expect to find a photo in 30 seconds of googling.) --B (talk) 13:41, 2 October 2018 (UTC)

I think I would not want to "tighten", I think NFCC is also useful for situations where things are unclear, eg. where it is likely the photo hosted is out of copyright (especially because copyright is often byzantine), but we are unsure of all the details, thus out of caution we host as NFCC. The very purpose of encyclopedia is served thereby by having informative images (instead of none). Alanscottwalker (talk) 14:33, 2 October 2018 (UTC)

Why did you pick January 1, 1978? Presumably, the effective date of the 1976 copyright act.

However, your discussion talks about them being a public figure prior to that date. I don't think being a public figure or not a public figure is relevant (let me know if I'm missing something) but more importantly, the date is relevant in the context of the date of the publication of the photo. (If someone's a public figure in 1965 but has a photo published in 1985, then no copyright notice is needed.)

Two complications:

1. Note that I said date of the publication of the photo not the date the photo was taken. If a photo was taken in 1977 and published in 1979, the copyright law in effect in 1979 applies, not 1977.
2. In the time periods in which a notice was required it does not have to be on the front of the photo. This can cause annoying problems. Many photographs were taken with a copyright notice on the back of the photo. It is not uncommon for someone to send in a scan of a photo to OTRS and claim it is not subject to copyright because it did not have a copyright notice. This may or may not be true but we need to see a scan of the back of the photo to be sure. This problem should not arise in the case of the yearbook as it seems implausible that the yearbook would publish the photo on one side of the page and the copyright notice on the backside, but I want to be careful that your advice is not taken too literally. People can and do send in stands of loose photographs and presume they are out of copyright because there is no notice in the publication date was prior to the effective date of the 1976 copyright act.--S Philbrick(Talk) 14:45, 2 October 2018 (UTC)

Loose photos? How would you know if they were ever published? Alanscottwalker (talk) 14:50, 2 October 2018 (UTC)

Well, actually, if the photo was published in 1985 with no notice and there was not subsequent copyright registration, it's also public domain. But that isn't the point. The point is that if someone was a public figure in the United States prior to 1978, then is is highly likely that someone published (not just took, but published) a photo of them and there is a decent chance that they failed to comply with formalities. Obviously a loose collection of photos at a university library is probably not going to be public domain, but there are other things you can find there - school newspapers and other regional publications that frequently didn't bother with a copyright notice. --B (talk) 15:15, 2 October 2018 (UTC)

You made a mistake 11 years ago? Shame on you for not knowing all of the rules before you made your first edit! We must now block you for life and shun all appeals. --Redrose64 🌹 (talk) 20:33, 2 October 2018 (UTC)

Automated (synthetic) audio for IPA

I think it would be helpful to allow readers to listen to the pronunciation of words for which Wikipedia already has an IPA representation. I've created a quick proof of concept (see the Phabricator thread). This can be done client or server side. Client side will be much easier to implement, but means that users will have to fetch ~500 kB of JavaScript when they first try to play a word.

--Janschejbal (talk) 20:57, 2 October 2018 (UTC)

I absolutely would like this. However, how would it handle exceptions (characters without an IPA representation)? Discuss-Dubious (t/c) 13:56, 3 October 2018 (UTC)

Not sure what you mean with "characters without an IPA representation"? The feature would be very simple: If an IPA representation is provided in the article, you can click a button and hear it spoken. If nobody added an IPA representation, there will be no button to click. If the IPA representation is inaccurate (either because the author made a mistake or because the language cannot be properly represented by IPA), the tool will read it as it is written. The project does not cover speaking random words or automatically generating IPA from text, the IPA has to be added by authors. --Janschejbal (talk) 18:02, 4 October 2018 (UTC)

Wikimedia Sweden + more are developing this at mw:Wikispeech. Anyone with interest can join Wikimania 2019 in Sweden where this will be showcased or otherwise join online discussions. Blue Rasberry (talk) 19:07, 4 October 2018 (UTC)

Also check out Wikidata lexeme project - d:Wikidata:Lexicographical data. Blue Rasberry (talk) 19:16, 4 October 2018 (UTC)

That script you wrote is pretty neat. The generated pronunciations aren't as good as the hand crafted ones, but that's to be expected. Implementing this client-side would be cool to have, at least as a gadget or something. — AfroThundr ^{(u · t · c)} 03:03, 5 October 2018 (UTC)

Make "view-source" an optional tab for the left of the search bar.

The view source tab would be good for the bar because it would make it easier if you want to look into wikicode and see how some formatting was used and borrow templates and citations that you need without the risk of accidentally ruining anything on the page in question. It already exists as a replacement for edit on protected pages.

What do you guys think? Discuss-Dubious (t/c) 13:55, 3 October 2018 (UTC)

@Discuss-Dubious: 'view-source' just goes to &action=edit, it is not a function to just call. — xaosflux ^Talk 15:58, 3 October 2018 (UTC)

Oh, okay then. Hmm. I wonder if making a new action for non-protected pages is a good technical fix. Where can I go to propose that? Discuss-Dubious (t/c) 19:49, 3 October 2018 (UTC)

phab: --Redrose64 🌹 (talk) 20:47, 3 October 2018 (UTC)

@Discuss-Dubious: Also, if you don't want to change the source, I think you can just click "edit source" and when you're done, leave without clicking "Publish changes", so that nothing happens. ^Semi_Hypercube ✎ 16:02, 3 October 2018 (UTC)

Yes, I know about that. That was what I did prior to creating this proposal. I thought the idea would better facilitate this by entirely removing the element of risk I perceive of accidentally publishing a page where you have casually pressed "cut" instead of "copy" entirely. Discuss-Dubious (t/c) 19:49, 3 October 2018 (UTC)

You could also use &action=raw to view the wikisource, but depending on your browser settings this may open a file download (or open) requester instead of displaying it... —PaleoNeonate – 20:39, 3 October 2018 (UTC)

Show draft deletion log together with article deletion log at redlinked article

Someone clicking on Loella Haskew has no way of knowing whether Draft:Loella Haskew was previously deleted (e.g. by G13). Some people don't realize that and don't request a refund, instead wasting their time on writing the article from scratch. In order to verify that, we have to go to the draft page and check, but we aren't perfect and often forget that. Because we already have {{Draft at}} which serves an equally useful purpose, I am proposing that the deletion log for the draft (if it exists), is shown at the redlinked article. wumbolo ^^^ 14:58, 4 October 2018 (UTC)

IB Russian inhabited locality replacement

I created a new version of {{Infobox Russian inhabited locality}} based on Infobox settlement (test cases found here); feedback and comments on the template's talk page would be most welcome.--eh bien mon prince (talk) 07:28, 5 October 2018 (UTC)

Thank you, but we already have {{Infobox Russian rural locality}} and {{Infobox Russian town}} and {{Infobox Russian urban-type settlement}} which cover all possible varieties.--Ymblanter (talk) 07:30, 5 October 2018 (UTC)

Add remark to watchlist items

Maybe this has been proposed before, but anyway: I just found an article in my watchlist that has been sitting there for months, and I now have no idea why I added it. It would have been nice to have the ability to add a remark to every watchlist item. I don't watch that many pages, 30 or so, and I hear some people watch 1000+ pages, which must be unmanageable. This idea is similar to watchlist item grouping, but is easier to implement. GregorB (talk) 18:20, 5 October 2018 (UTC)

It is also easy to do yourself by keeping a text file containing notes as to why you watchlisted a page. --Guy Macon (talk) 19:45, 6 October 2018 (UTC)

Or a bookmark. Not quite the same, though. GregorB (talk) 22:16, 6 October 2018 (UTC)

Why isn't mobile number and / or email required for new User Creation?

A lot of time is wasted in sockpuppet investigations and still they seem to have infested Wiki.My suggestion is to require email and / or mobile validation to create new accounts on Wiki. Existing users should also provide them to continue using their IDs. Email authentication is free of cost and easiest to set up, while mobile number verification may require sending an OTP to the number which can have a minuscule cost involved of sending an SMS. Email verification would be sufficient since to create new email IDs, the companies send OTPs to the mobile and user cannot register multiple email IDs linked to a single mobile number. Even small websites have these type of validations then why can't Wiki? Since sockpuppetry is becoming a nuisance on Wiki. Hopefully something gets done in this regard, if this is not the place for suggestion kindly let me know where to write it. Thanks!