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)[reply]
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)[reply]
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? — Rhododendritestalk \\ 20:36, 25 August 2018 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Weak supportprovided, 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)[reply]
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)[reply]
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. --Rschen775421:32, 2 September 2018 (UTC) edited 02:44, 3 September 2018 (UTC)[reply]
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.) --Rschen775421:39, 2 September 2018 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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. GMGtalk19:21, 17 September 2018 (UTC)[reply]
@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)[reply]
@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. GMGtalk23:54, 23 September 2018 (UTC)[reply]
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. GMGtalk02:01, 24 September 2018 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
@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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Support per Robby, let's help the people who've been working tirelessly on maintaining the local template links. --Nemo19:12, 3 October 2018 (UTC)[reply]
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. --Rschen775404:18, 26 August 2018 (UTC)[reply]
@Rschen7754: On the Wikidata site, Commons sitelinks are now used much more, alongside Commons category (P373). Compare the statistics from September 2017toJune 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)[reply]
@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. --Rschen775421:42, 2 September 2018 (UTC)[reply]
@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)[reply]
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? --Rschen775402:41, 3 September 2018 (UTC)[reply]
@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)[reply]
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)[reply]
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. --Rschen775423:08, 3 September 2018 (UTC)[reply]
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)[reply]
@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)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I suggest that CC-BY 4.0 should be the default suggested licensing when using the upload forms in Wikimedia projects for own works, instead of the current CC BY-SA 4.0 license (example at Commons), sometimes with dual GFDL licensing (example: here at Wikipedia). The main difference would be that derivatives are not required to have the same license. Reasons for changing to CC-BY 4.0 are:
It is a more permissive license.
It makes it much easier to combine and mix works. The combination of the two images at right, for example, would not have been possible at all if the images were licensed under let's say CC BY-SA 4.0 for the first one and CC BY-NC 2.0 for the other. However, if either was CC-BY 4.0 it would have been permitted. See WP:Adaptation for further information in this regard.
CC-BY is by far the most popular licensing for open access journals (see Directory of Open Access Journals - Journal license tab), and is similarly popular in databases (see CC: Data and CC licenses). CC BY-SA is therefore not compatible for inclusion in most open access journals, denying them free access to the sum of Wikimedia knowledge.
Most uploaders may very well be as willing to upload under CC-BY, but may not be familiar with the differences between having SA or not. The current upload form layouts thus make lots of works receiving a more restrictive licensing than necessary. Just because uploaders can upload under the most restrictive license Wikimedia has to offer doesn't mean they need to be presented with that option by default. Those who still want to put the additional SA restriction would still be able to actively choose so.
The currently suggested dual licensing with CC BY-SA 4.0 with GFDL such as here in Wikipedia (link to form) is actually incompatible in a strict sense (see Wikipedia section on this matter, and is also a lot of extra read for those who want to know what GFDL means, since it doesn't provide the short presentation as given in Creative Commons licenses (compare GFDL license page to the CC BY-SA 4.0 page. It would therefore be both easier for uploaders and more legally correct if we simply dropped GFDL from the default license suggestion. Again, those who do want to choose dual licensing for some reason would still be able to actively choose so.
I want to know if you agree with this suggestion, and we can then bring it to Wikimedia's legal team for review before implementation. I know the change is technically not that hard, since we only need to change the upload form layouts, not the licenses of any already uploaded works, nor the overall licensing of any wiki. I've started a vote on this issue in Wikimedia Commons. Please go to that page to join:
Oppose: There are many great arguments against this proposal over at Commons that I recommend users read through. In fact, there was so much opposition that the nominator withdrew this from there. But there is a unique aspect of locally uploaded files here on Wikipedia that they didn't touch upon. Unlike Commons, which hosts educational content for all, Wikipedia hosts files for use on Wikipedia (unused files will be deleted, unlike necessarily on Commons). That's why, if I choose to upload locally, the default should be that my file remains free and can be used on Wikipedia even after someone has modified it. Under BY, I cannot include that condition.
A practical scenario: I upload a file on Wikipedia under CC-BY 4.0. Someone else downloads my file, edits it into a much prettier version, and uploads it on their website. I come across that enhanced version and would love to use it on Wikipedia instead of or alongside my original. I marvel at the picture – that even credits me by name – but to my astonishment I find out that it has been uploaded with the notice "All rights reserved, no re-use allowed". This can happen with a BY license, but not with BY-SA.
That's certainly not "the wiki way". While by contributing to Wikipedia I want re-users to benefit, I also want to accumulate a corpus of free works that stay free (after all, that's why text here is CC BY-SA and that's not going to change). At minimum, when I upload files locally, I want my files to also benefit Wikipedia in the event that derivatives are made. That's not too much to ask for, as the default position, which should also be intuitive for the casual contributor. If someone consciously wants to waive more rights, they are, of course, free to do so, but the default position should be that when you contribute to a free encyclopedia your contributions stay free. – Finnusertop (talk ⋅ contribs) 10:22, 12 September 2018 (UTC)[reply]
Oppose. One gives freedom to use derivatives, the other gives freedom to prohibit use. I think we have a valuable interest in the freedom to use. In particular we don't want someone cloning all of Wikipedia and making it difficult or impossible to bring improvements back here. Alsee (talk) 00:48, 17 September 2018 (UTC)[reply]
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.
"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:
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. TeraTIX23:24, 20 September 2018 (UTC)[reply]
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.
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.
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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
AsI 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)[reply]
(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)[reply]
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")? — xaosfluxTalk15:06, 20 September 2018 (UTC)[reply]
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)[reply]
@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. — xaosfluxTalk22:18, 20 September 2018 (UTC)[reply]
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)[reply]
(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)[reply]
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)[reply]
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.
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. SemiHypercube✎23:28, 24 September 2018 (UTC)[reply]
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)[reply]
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. —Cryptic02:00, 25 September 2018 (UTC)[reply]
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)[reply]
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. —Jeremyv^_^vBori!19:00, 25 September 2018 (UTC)[reply]
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)[reply]
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. — xaosfluxTalk19:58, 25 September 2018 (UTC)[reply]
Additionally, some user-space essays may be good to index. Agree with the general problem though: newer users try to index inappropriate pages. — xaosfluxTalk20:00, 25 September 2018 (UTC)[reply]
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ölf00:08, 26 September 2018 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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-C19:57, 26 September 2018 (UTC)[reply]
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)[reply]
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 (TALKCONT)12:56, 27 September 2018 (UTC)[reply]
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)[reply]
(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)[reply]
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)[reply]
@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) SemiHypercube✎10:41, 3 October 2018 (UTC)[reply]
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)[reply]
@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)[reply]
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. –Davey2010Talk12:16, 4 October 2018 (UTC)[reply]
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.
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.
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. -- GreenC14:23, 1 October 2018 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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 :) -- GreenC20:46, 2 October 2018 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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:
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.
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)[reply]
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)[reply]
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)[reply]
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.
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)[reply]
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)[reply]
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.
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Y It's a blizzard and there's unanimous consensus to restrict indexing-capabilities to Extended-Confirmed-Users.∯WBGconverse 04:38, 7 October 2018 (UTC)[reply]
