Open main menu

Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab Miscellaneous 

New proposals are discussed here. Before submitting:

« Archives, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158

Contents

Video NamespaceEdit

VideoWiki tutorial for the tool made with the tool

A few of use have been making video scripts that than compile into videos using the WP:Videowiki tool. We are wanting a "Video" namespace for these scripts to help with a number of functionalities. Examples of already created video scripts include:

We have a tutorial on how the tool works at Wikipedia:VideoWiki/Tutorial. Development is ongoing. Doc James (talk · contribs · email) 04:21, 2 May 2019 (UTC)

@Doc James: Your post seems more like a statement than a proposal, at least to me. Are you informing us about this VideoWiki or proposing to add a new namespace on English Wikipedia to hold them?. – Ammarpad (talk) 08:37, 2 May 2019 (UTC)
@Ammarpad:: I believe @Doc James was trying not to be "promotional" about VideoWiki and stated ongoing facts while bringing the "video" namespace ask up, consequently the bare language. The "Video" namespace will really be helpful in bring collaboratively edited videos under one roof and allowing us to build the gadgets for the "video" namespace. Pratik.pks (talk) 10:42, 2 May 2019 (UTC)
clear is a deprecated HTML attribute. If these are automated in some way, and that's the required text, you should consider using a different signal.
That aside, I also am unclear; I do not think we should have a new namespace for these. If you want to host them in all in the same place, your current approach seems reasonable. --Izno (talk) 20:16, 2 May 2019 (UTC)
User:Ammarpad As stated "We are wanting a "Video" namespace for these scripts"
Not sure what you are referring to about clear User:Izno?
Having them in their own namespace will allow additionally functionality like allowing people to have just this group of articles show in their watch-list. Doc James (talk · contribs · email) 22:09, 2 May 2019 (UTC)
This functionality does not strike me as needed for this set. The middle-product is a list of pages from what I can see that are project-space; I would recommend categorizing them and then using Special:Recentchangeslinked. The end product is videos, and you can do the same with those. There is also a significant semantic overlap with the File namespace, which will cause confusion for many people. You really don't need a new namespace.
clear is a deprecated HTML element. That means it may not work the way you want after some significant period of time; browsers may deprecate or remove recognition of the clear functionality. My point was that if the script that creates these pages relies on that exact line being present, you may not have desirable pageviewing at some point. There are other ways to do this (e.g. <br style="clear: both;"/> or {{clear}}) that you might consider using which should continue to be useful long into the future. --Izno (talk) 13:31, 3 May 2019 (UTC)
thanks for the {{clear}} info. I'll implement. Ian Furst (talk) 13:36, 3 May 2019 (UTC)
Some functionality like VE does not work in Wikipedia space. I guess we could move these to "Video:" which would be in main space but not sure if that would cause concerns User:Izno. Doc James (talk · contribs · email) 21:25, 3 May 2019 (UTC)
You presume much if you believe that VE would be turned on in any other space. You could move them, but that would definitely causes issues and not likely have consensus. IMO, you're chasing a car you don't need to. You still have not illustrated particular need for a new namespace. --Izno (talk) 00:58, 4 May 2019 (UTC)
It might come to talk pages per the recently completed consultation. But yes hope springs eternal.Doc James (talk · contribs · email) 22:51, 4 May 2019 (UTC)
You can actually use VisualEditor in any namespace if you add a "veaction=edit" parameter to the URL bar. I find it useful for Requested Articles. Actually, that's the only thing I use VE for. Let me add that to my user script ideas list... —pythoncoder (talk | contribs) 21:32, 7 May 2019 (UTC)
User:pythoncoder many thanks, that is amazing :-) Doc James (talk · contribs · email) 01:31, 8 May 2019 (UTC)
Per T57792, not all. WBGconverse 14:45, 18 May 2019 (UTC)

Create new namespaceEdit

Support creation of Video: namespaceEdit

  • Support This would actually be better than the initial option IMO. Even though we have none articles in article space such as "lists" and "timelines" this route is not ideal for the video scripts. Doc James (talk · contribs · email) 22:04, 5 May 2019 (UTC)
  • Support. Also a good idea. OhanaUnitedTalk page 17:05, 7 May 2019 (UTC)
  • support very good idea--Ozzie10aaaa (talk) 12:45, 8 May 2019 (UTC)
  • support Would a a tidy way of keeping track of them and an easy way to ensure that they are VE-editable by users who don't know the secret veaction=edit trick. T.Shafee(Evo&Evo)talk 07:32, 9 May 2019 (UTC)
  • Support videos for WP:MAINSPACE articles. Only a handful of people are working on this. They will be mostly for medical-related articles at this point. They won't be for all articles. QuackGuru (talk) 15:19, 9 May 2019 (UTC)
  • I will support any step that gets us closer to being able to produce documentary films under the Wikimedia banner, and this is definitely a step in that direction. bd2412 T 15:07, 10 May 2019 (UTC)
  • Support A very nice idea to implement. Vulphere 12:22, 11 May 2019 (UTC)
  • Support I really found it beneficial especially in the medical and scientific topics.--Avicenno (talk) 17:05, 13 May 2019 (UTC)
  • Support Why not.. let's try something out, can't hurt us. —TheDJ (talkcontribs) 07:20, 15 May 2019 (UTC)

Oppose creation of Video: namespaceEdit

  • Wait until VideoWiki gets more popular. It just started this year and might fizzle out and leave us with a junk namespace. I don't think it will, but I still say that we wait until VideoWiki sticks and becomes a lasting part of Wikipedia. John M Wolfson (talk) 22:17, 2 May 2019 (UTC)
    Thanks User:John M Wolfson. That is certainly reasonable. Once we have more than a hundred or a few hundred videos we can come back :-) The one problem will be the amount of work required to do the move. The more video scripts the more work I imagine... Additionally we want to have visual editor usable on the scripts and moving a namespace would allow that. We are also wanting to enable a gadget to bring further functionality within Wikipedia, specifically we want to bring in the Videowiki player. Doc James (talk · contribs · email) 22:24, 2 May 2019 (UTC)
  • wait: first this is a brand new technology with no demonstrated adoption yet; we need to understand how the community responds. Second: what about Commons? Shouldnt we be making these in a platfrom that supports the translation extension? What happens when English Wikipedia, yet again, adopts something and then refuses to shift to the more collaborative international space where it would benefit many more communities? I think its great to start running this experiment on enwiki, but if you want it to scale: it needs to be in a robustly international, scalable solution that is responsibly multilingual and inclusive from the start.Sadads (talk) 08:47, 7 May 2019 (UTC)
    User:Sadads. Thank you for the feedback. The tool is being built with the express intent of reaching the non-english speaking minimally literate. Our motivation, is that there is strong evidence getting information from project medicine pages into the last mile of developing nations will save lives. Cholera and Dengue fever are both good examples. Once a script is created in english, it is being translated multiple times. The Videowiki player text-to-speech engine supports 21 language (plus several variants). This means the translator can publish their translated script (and link in the 'Languages' sidebar), and the video is ready within minutes to post on the local (non-english) page. Where a language is not supported by TTS, there is an easy way to overdub which will be shown in the history of the script. Part of the reason we're looking for a permanent home, is ensuring support for many languages means there are many links. E.g the script points to the player, the player points to the commons webm, the webm points to the article, then the article needs to point back to the script. For each language. As the number of scripts grows, the number of links connecting each piece grows by roughly ^4. Ian Furst (talk) 09:51, 7 May 2019 (UTC)
    @Ian Furst: I think the problem with your solution, is that we are holding the information on different pages: so if you update one video, its very hard for the other languages to update to meet the changes made in that language. Whereas if we did the videos on a multilingual Wiki (i.e. Commons or Meta-- but probably Commons because its designed to distribute content), we could use the Translation extension -- or any subsequent multilingual-support that WMF provides via structured data, etc-- to make it sustainable and maintainable. Forking the videos on every single wiki, requires a much higher standard of maintainence that makes sense on big language wikis (i.e. enwiki or frwiki) but not on smaller languages where the communities have very limited capacity/attention for content maintenance. This is in part of the reason why English Wikipedia doesn't adopt or understand globally useful Wikidata content, while smaller wikis are gobbling it up -- leading to a huge knowledge gap that the core parts of the English Wikipedia community continues to ignore, because of their refusal to contribute to Wikidata.... I don't think your current approach makes sense because it fractures the community, rather than encouraging it to work together. Sadads (talk) 10:29, 7 May 2019 (UTC)
    @Sadads: I'm a bit of a newbie, so if you could expand on this I'd appreciate it. At some point, there needs to be a script for the video, with links to any media. The Videowiki player pulls the text, media, and attributions from that single resource (the 'script'). Are you saying that if the script is hosted on Commons it lends itself to easier multilingual support? E.g. not just english to others, but others to english? If you have time, would appreciate the details. Ian Furst (talk) 11:56, 7 May 2019 (UTC)
    I do not think Commons would be a good place. These scripts are collaboratively editable content. Not every language should have an exactly similar script just like not every language should have an exactly similar Wikipedia article. Have figured out how to get Content Translation to work. Not seeing the translation extension as suitable. Doc James (talk · contribs · email) 13:02, 7 May 2019 (UTC)
    Oh - it's a machine translation of the text. I agree that this is not desirable. We've figured this out with the Hindi translations - what works in one language does not work in another (as a direct translation, or even the level of detail on certain slides). With that said, I now understand the benefit to text on .svg images - we need to make sure the player can add a white background to transparent slides so they're properly supported.Ian Furst (talk) 13:28, 7 May 2019 (UTC)
    No, hosting them on Commons has nothing to do with machine translation. I think Doc James is suggesting that it would be more suitable to make the scripts localized via the Content Translation tool rather than hosting them on Commons where they could be localized via the Translate extension. Kaldari (talk) 23:15, 7 May 2019 (UTC)
    User:Kaldari that is correct. And now that I see we are able to use Content Translation were the scripts are now, no significant need for a new name space at this point in time. Doc James (talk · contribs · email) 11:52, 8 May 2019 (UTC)
  • Oppose. I do not think we need to establish a separate namespace for videos regardless of their creation method, as I have already laid out multiple times above. --Izno (talk) 03:06, 5 May 2019 (UTC)
  • Oppose. For one thing, free videos belong on Commons, not here. Collaboratively edited content, if multimedia, are appropriate on Commons; if there's a language-related problem, just upload a different copy for each language. Text dumps don't belong there, but scripts for Commons-hosted videos would be fine there. COM:SCOPE says "no raw text dumps" but then says However, Commons can be used to host such material if included in a shareable media file that is of use to one of the other Wikimedia Foundation-hosted (WMF) projects, so scanned copies of existing texts that are useful to other WMF projects (e.g. to serve as the basis of a reliable, verifiable source) are in scope. Also allowed are files which embody something of value over and above raw text. For example, files consisting of scans of out-of-copyright books, newspapers and the like which preserve original font, layout, embedded images and the like are within scope. Captions for Commons-hosted multimedia content are definitely embodying something of value over and above raw text. Aside from that issue...we already have the File: namespaces for pictures, sound recordings, PDFs, and videos. Why do we need a separate namespace for a few videos with a specific subject? Namespaces exist to separate pages that serve distinct technical functions, not to separate similar pages with unrelated topics. Nyttend (talk) 22:15, 7 May 2019 (UTC)
    Agree completely free video belongs on Commons and that is were the videos go. What we are discussing is collaboratively editable video scripts. Doc James (talk · contribs · email) 01:33, 8 May 2019 (UTC)
    Exactly. Please move the scripts with the videos, because otherwise they'll get moved by someone else and then speedy deleted under the transwiki criterion. Nyttend (talk) 04:58, 8 May 2019 (UTC)
    The videos are on Commons. The scripts are here. The scripts do not work on Commons for a whole bunch of reasons. Doc James (talk · contribs · email) 11:42, 8 May 2019 (UTC)
  • Wait per John M Wolfson. I support this once the need has been demonstrated, but that hasn't happened yet. —⁠烏⁠Γ (kaw)  00:13, 08 May 2019 (UTC)
  • Oppose as premature. This initiative appears to be in its infancy and doesn't have widespread community support yet. We can revisit this matter in the future. -FASTILY 22:36, 8 May 2019 (UTC)
  • Oppose as outside the scope of Wikipedia. This is an encyclopedia, not a repository of source material and not youtube. We are not the only place to collaboratively edit things, there are sister projects such as Commons, WikiBooks, and WikiVersity which all allow collaborative editing but whose mission is more in line with the goals of this project. If none of those are suitable then one can always propose a new sister project tailored to this mission. Just because these scripts create videos that may be used on Wikipedia does not mean they need to be hosted on Wikipedia. Wugapodes [thɑk] [ˈkan.ˌʧɹɪbz] 16:47, 9 May 2019 (UTC)
  • Oppose per my comments below -- Colin°Talk 17:47, 9 May 2019 (UTC)
  • Oppose I think the whole concept is flawed, let alone creating a separate namespace for it. Examples that I saw had awful subtitling. They were useless for me, as a deaf person unless I paused every second or so. I can sort of understand a spoken wiki (blind people) but videos like the ones I saw some months ago are neither beneficial to the blind nor the deaf, and I suspect they're a tad difficult to edit but (I realise the contradiction) wide open to vandalism that is less likely to be spotted. - Sitush (talk) 18:26, 9 May 2019 (UTC)
  • Too soon: This new stuff is just getting out the door, we don't want it to be misused. Let policy and criteria for videos develop before we make a separate namespace. Kirbanzo (userpage - talk - contribs) 14:56, 10 May 2019 (UTC)
  • Not yet - this may be a good goal to work towards, but there are serious issues to work out before we implement it. Blueboar (talk) 13:20, 11 May 2019 (UTC)
  • Oppose, outside the scope of Wikipedia. This sort of content should be on Commons or another alternative outlet. Stifle (talk) 11:04, 13 May 2019 (UTC)
  • Strongest possible oppose, way outside the scope of Wikipedia. Generated videos might be in scope on Commons, but collaboratively edited scripts should probably be either in a new project, or on Wikiversity. rchard2scout (talk) 14:31, 14 May 2019 (UTC)
  • Oppose, if we want to have a video namespace, do it on Commons. (They have a featured media of the day!) – Ben79487 04:33, 15 May 2019 (UTC)
  • Oppose Too many issues. I foresee this going the way of WP:Books, which has its own rarely-updated namespace of crap. feminist (talk) 10:00, 15 May 2019 (UTC)
  • Oppose If it isn't broken, don't fix it. It's unneeded, and the new system could be easily confused. If it has to be done, at least trial it for a year in someone like Commons or WikiVersity. Then per all the above, we can come back to this after a year or so and see if it justifies another namesapce. The Duke 22:20, 15 May 2019 (UTC)
  • Oppose as per John M Wolfson. Could not agree more.

Move video scripts to Pseudo-namespaceEdit

Moving to "Video:Name" will allow those working on video scripts to use visual editor without any changes required by the WMF. Looking for consensus for such a move.

This would involved

Doc James (talk · contribs · email) 10:19, 4 May 2019 (UTC)

Support pseudo-namespaceEdit

  • Support as proposer. Less preferable than the one above. But will make it easier for more people to get involved. Doc James (talk · contribs · email) 10:19, 4 May 2019 (UTC)
  • Support. Makes it easier to distinguish and calculate stats. OhanaUnitedTalk page 01:37, 5 May 2019 (UTC)
  • Support. COI, as the main content creator with Videowiki, but I'd like to ask for consideration towards a namespace. The link between script<>Videowiki player<>commons_webm<>WP_article depends on a uniform naming protocol, so that each entity can find the 'call'. So far we're up to 20 videos, but with multiple languages that means roughly 100 named urls. If there is consensus, it would save a lot of work down the road in not having to re-point various elements. Wrt current space (Wikipedia:Videowiki/...), it doesn't allow VE. Many of these article sections have 50 characters of "script" with 400 characters of references. VE makes it much easier to change script (there is a lot of punctuation changes to make the TTS engine sound more human), especially for < veteran editors, like myself. A list of scripts, videowiki player links, and commons webm files can be found here to see the issue. Ian Furst (talk) 02:47, 5 May 2019 (UTC)
    Note that the proposal stated here is not for a namespace, but to put them into the main article namespace with "Video:" as a pseudo-namespace. Among other things, that means these would show up when people search for articles, use Special:Random, and so on. If other-language wikis were to follow, they would still likely use localized versions of the word "Video", while a true namespace could always have English "Video" available as an alias. I don't know if that distinction makes a difference to you. Anomie 13:51, 5 May 2019 (UTC)
  • support per above three editors--Ozzie10aaaa (talk) 12:47, 8 May 2019 (UTC)
  • support why not. namespace or pseudo space, it makes not difference to me in this phase. —TheDJ (talkcontribs) 07:21, 15 May 2019 (UTC)

Oppose pseudo-namespaceEdit

  • They are not articles. — JJMC89(T·C) 21:42, 4 May 2019 (UTC)
    • That is correct, they are scripts that are collaboratively editable which than generate video. Thus why the proposal is to label them "Video:" Doc James (talk · contribs · email) 22:49, 4 May 2019 (UTC)
      A video namespace does not exist (As written, this is not a proposal to create one, only to move the pages.), so they would be in the main (article) namespace. Since they are not articles, they don't belong there. — JJMC89(T·C) 23:32, 4 May 2019 (UTC)
      Lists and timelines are not articles either... Doc James (talk · contribs · email) 22:00, 5 May 2019 (UTC)
  • As this proposal is to use "Video" as a pseudo-namespace, I oppose. Adding a namespace is extremely easy:
    1. Establish consensus for the new namespace on this page.
    2. File a task in Phabricator with the Wikimedia-Site-Requests tag, similar to T156621. Side note, I'd recommend using namespace numbers 130+131, which could become the new "standard" VideoWiki namespace number if other wikis want to do the same thing.
    3. Create a patch similar to gerrit:334997 and follow the SWAT deployments process to get it deployed.
    There's no need to worry about "changes required by the WMF" here, step 1 is by far the hardest one. Anomie 23:36, 4 May 2019 (UTC)
    For the record, I have no opposition to the creation of a true namespace for these scripts, only to the use of a pseudo-namespace. Anomie 13:51, 5 May 2019 (UTC)
  • (edit conflict) Per JJMC89. Also note that Doc James has created Video:Urinary tract infection in the article namespace. * Pppery * DELETE! 23:37, 4 May 2019 (UTC)
  • Oppose. I do not think we need to establish a separate namespace for videos regardless of their creation method, as I have already laid out multiple times above. --Izno (talk) 03:06, 5 May 2019 (UTC)
  • Oppose until I see any convincing rationale that the File namespace is unsuitable — Martin (MSGJ · talk) 22:02, 6 May 2019 (UTC)
  • Oppose As noted above, the file namespace works for videos. Moreover, the pseudo-namespace would be confusing — we shouldn't have a significant number of pages called Talk:Video:Whatever. The only way a page should be entitled "Video:Whatever" is if "Video" is a namespace (so talk is Video talk:Whatever) or if it's about a topic whose name begins with "Video:", comparable to Book:A Novel. Nyttend (talk) 22:21, 7 May 2019 (UTC)
  • Oppose. Pseudo-namespaces are almost always bad ideas. —⁠烏⁠Γ (kaw)  00:14, 08 May 2019 (UTC)
  • Oppose. Putting videos in Mainspace is a bad workaround for a problem that was created less than a month ago, and which can surely be addressed in a better way. For one thing, the Foundation appears to be seriously considering officially enablinge VE for all pages as part of the on-going Talk pages consultation 2019. Alsee (talk) 15:39, 8 May 2019 (UTC)
  • Oppose per above, and per my reasoning in the above section. -FASTILY 22:36, 8 May 2019 (UTC)
  • Oppose pseudonamespaces are just generally bad ideas for all the reasons above. Under no circumstances do these belong in article space. Wugapodes [thɑk] [ˈkan.ˌʧɹɪbz] 16:56, 9 May 2019 (UTC)
  • Oppose per my comments below -- Colin°Talk 17:47, 9 May 2019 (UTC)
  • Oppose for the same reasons I gave regarding an actual namespace. Far too many issues for this to be moved over at present. - Sitush (talk) 18:28, 9 May 2019 (UTC)
  • Oppose per what I said above. feminist (talk) 10:00, 15 May 2019 (UTC)
  • Oppose I would support this if it was possible to create pseudo namespaces outside of article space but videos and their scripts do not belong in article space and this is not yet developed enough for a namespace of its own Abote2 (talk) 16:41, 18 May 2019 (UTC)

DiscussionEdit

  • Comment I'd like more information about the technology used for the text to speech in these videos. -- GreenC 23:34, 2 May 2019 (UTC)
    • User:GreenC it is an off the shelf text to speech reader.
    • It is specifically this one[1]
    • The legal opinion on the copyright of the output is that it remains with those who wrote the underlying text.[2]
    • Additionally as the underlying text is CC BY SA the output text must also be CC BY SA.[3] Doc James (talk · contribs · email) 23:55, 2 May 2019 (UTC)
      @Doc James: Thanks! It is high quality, Amazon explains it. About the only thing they might do is a Terms of Service request for attribution, but not seeing any evidence of such a TOS. Can Amazon be documented for people curious how it works? -- GreenC 07:10, 3 May 2019 (UTC)
User:GreenC have added at Wikipedia:VideoWiki/FAQ Doc James (talk · contribs · email) 21:25, 3 May 2019 (UTC)
    •  
      Editing workflow Videowiki
      One note, the workflow being used is to convert the TTS output to webm, and upload it to commons, where editors can decide if they want to use the videos in articles. This allows for offline use, but it also means the vast majority of views will be of webm recordings; not of the actual TTS output which limits costs. I've made a graphic of the workflow to the right. In Amazons FAQs they address this type of use. "Q. Can I use the service for generating static voice prompts that will be replayed multiple times? Yes, you can. The service does not restrict this and there are no additional costs for doing so." Ian Furst (talk) 10:57, 3 May 2019 (UTC)

@User:Anomie makes a good point. To make a informed decision, can you/(anyone) make a pros v. cons of 3 options (a) "as is" (b) "pseudo-namespace" and "video namespace". One of the biggest reason why we want are unhappy with the present (as is) solution is that Visual Editor isn't available which makes (a) content creation harder, (b) it is not accessible for inexperienced editors. --Pratik.pks (talk) 00:46, 6 May 2019 (UTC)

  • I refactored the discussion to make it more clear what proposals were being discussed where. If you feel where I placed your comment is not an accurate reflection of your position, please feel free to move it where you feel it fits. I'm pinging @John M Wolfson and Sadads: I created a new "oppose" heading under which I placed your comments and so you especially may want to review the refactoring. I'll also ping the others involved: @Doc James, OhanaUnited, Ian Furst, JJMC89, Anomie, Pppery, Izno, and MSGJ: Wugapodes [thɑk] [ˈkan.ˌʧɹɪbz] 20:59, 7 May 2019 (UTC)
  • @Doc James: I'm struggling to see what function this has that can't be better served using Commons. Why should we host the video locally, when we have a regime in place to use them on all projects in all languages, along with a translation regime for both video content, subtitles, and references? True, we don't strictly have a standard format for referencing on Commons, but it seems like we could much more easily make one, along with making a translation space that is language specific, and could swap languages based on user settings using existing template formats. GMGtalk 00:18, 8 May 2019 (UTC)
    @GreenMeansGo: the videos go on commons. What we are discussing however are the video scripts. This is collaboratively editable content. We are not wanting exact translations between languages of the scripts. We are wanting each language to be able to decide what text they use as well as what images or media files they use within each video. Doc James (talk · contribs · email) 01:42, 8 May 2019 (UTC)
    @GreenMeansGo: From an accessibility perspective, the one realization I've had is that the videos need to be custom for each language. A straight machine generated translation doesn't (often) work well. If that is accepted, is there still a benefit to Commons? E.g. will the same Commons url host 20 different videos which can be selected from the languages menu? Where are you thinking about hosting the script which organizes the text and media? Ian Furst (talk) 01:27, 8 May 2019 (UTC)
    Well @Doc James: @Ian Furst:, I'd preface this by saying that I am in no way a technical expert. Having said that, by "translation regime" I don't mean a process of machine translation. What I mean is a preexisting community of human translators (including a level of user access that doesn't exist on monolingual projects at all). I also mean a level of preexising technical support for multilingual work. For example, I don't leave a new user a "Spanish welcome message" on Commons; I leave them "a welcome message" and they see it in whatever language they speak. They don't even need to be aware of it, because it's automatically set according to their home project.
Again, I don't know the technical details of the script you've set up here, but it doesn't seem that it would be intuitively difficult to combine it with the use of multilingual templates so that we keep the sources, the description and the media all together on the file's description page. As far as I'm aware, the referencing function is native to Mediawiki, and exists even on projects that don't use it. So that much would just be a matter of importing individual citation templates, as has been done over time at Wikiquote.
Another issue is the attribution. The media you have here locally links "down" to the media on Commons, but it doesn't appear that the source media links "up" to the video, whereas Commons already has a preexisting method of doing that. You have attribution but it's messy and duplicative. You also have verifiability, but it's similarly messy, with the sources housed on an entirely different project from the media itself.
Beyond that, if this requires a technical implementation, such as the creation of a new name space, then I don't see why we should use our efforts at a local implementation that would need to be duplicated across hundreds of local projects, when we could have a single global implementation. GMGtalk 12:47, 8 May 2019 (UTC)
User:GreenMeansGo With User:pythoncoder providing me details on how to get Content Translation (CX) working on these scripts I am happy to withdraw this proposal. Being able to use CX was the main justification for the proposal in the first place.
When you say "the media you have here locally" User:GreenMeansGo to what media do you refer? The videos are on Commons such as here. And what do you mean here "the sources housed on an entirely different project from the media itself" What "source" are you referring too? The text for the videos is derived from English Wikipedia. The scripts contains media from Commons but so do standard Wikipedia articles.
How is the attribution duplicative? Each media file is attributed. Each component can have a different license so we list each. Do you have suggestions for a more condensed method?
With respect to "the source media links "up" to the video" this is indeed something that still needs to be build. The tool that will accomplish this will be a bot on Commons. Doc James (talk · contribs · email) 13:02, 8 May 2019 (UTC)
As far as I'm aware, the referencing function is native to Mediawiki, and exists even on projects that don't use it. Completely doesn't matter, but the referencing function is actually provided by mw:Extension:Cite; but it is indeed enabled on every Wikimedia wiki. Galobtter (pingó mió) 13:04, 8 May 2019 (UTC)
@Doc James: What I mean (and probably didn't express very well) is that you have two attributions, one on the English Wikipedia page here and one on the Commons file page. The attribution here is the link to the file description on Commons (which runs into copyright issues if piped elsewhere), but you also have to attribute it to the source media on Commons or risk it being deleted there. So you have to attribute everything twice. If the "source" of the video (the..."stuff" it is drawing from on en.wiki in order to generate the video) was housed on Commons, then you already satisfy the attribution simply by making the "source stuff", and every time the video is changed you don't have to change the attribution on two different pages, on two different projects.
As far as the sources, the sources are housed here locally yes. But that presents a non-trivial barrier for example, a user coming from de.wiki to Commons, finding a video, and then having to come to en.wiki to find the sources. It's a long standing problem anyway of users finding themselves on Commons and not realizing that they've left their local project in the first place. Also en.wiki is not exactly "renowned" for being a "friendly place" to people who show up and don't speak the local language (outright hostile is probably a better description). So if someone is trying to translate it and has to ask a question in German, they're pretty much SOL, and are going to just as likely get booed back to de.wiki by the locals.
Again, without the detailed technical expertise, I don't see why each file on Commons couldn't have a corresponding "source template" housed on Commons, placed on the file description. This main source template would then have sub pages for each language, just as the the main welcome template on Commons has sub pages for /en, /de, /ar, and so on. The sub page for Template:Wikipedia-VideoWiki-Typhoid fever.webm/Source/en would itself house the markup that is currently locally kept at Wikipedia:VideoWiki/Typhoid fever. The template itself would satisfy the attribution requirement merely by existing, without the need for the unwieldy mess at c:File:Wikipedia-VideoWiki-Typhoid_fever.webm#Licensing. GMGtalk 13:34, 8 May 2019 (UTC)
There are two parts to attribution of the creators. One is for the text of the script and the other is of the images. One is attributed on WP the other is attributed on commons and within the video itself. With respect to supporting multi lingual translation of medical content, we have done fairly well here on EN WP Wikipedia:WikiProject_Medicine/Translation_task_force Doc James (talk · contribs · email) 13:47, 8 May 2019 (UTC)
  • Question: is there any reason why this should be limited/focused on medical topics? feminist (talk) 09:53, 12 May 2019 (UTC)
User:Feminist This just represents the interests of those currently most actively working on video. We have one by User:Cryout on Wikipedia:VideoWiki/Economy of Bulgaria Doc James (talk · contribs · email) 07:52, 15 May 2019 (UTC)

Comment by ColinEdit

  • Why is this being proposed as a request for namespace when in fact what needs to be discussed is whether Wikipedia should host such article-summary-videos at all and whether the proposer's and creator's claims of "collaboratively edited videos" is accurate. Without a community debate on this, the creation of a new namespace seems very premature. These videos were previously discussed at Wikipedia talk:WikiProject Medicine/Archive 122#Video Wiki where various false claims were made.
  • The creator of VideoWiki (Pratik.pks) calls these "collaboratively edited videos" -- Let's be clear: the video content is not "collaboratively edited". The VideoWiki system links a collection of existing images and videos hosted on Commons, with effects and transitions applied. The only thing that can be collaboratively edited is the narration. Creation of actual video content remains very hard and non-collaborative.
  • The main pusher of these videos on Wikipedia is Doc James, who previously had a personal collaboration with a commercial video training company (Osmosis) that imposed 300+ videos onto medical articles. These videos contained factual errors and failed our policy requirements on verifiability. The video content could not be community edited and each video contained promotional material advertising the training company. When the inclusion of these videos were challenged by editors knowledgeable about the article subjects, Doc James edit warred to maintain them. They were eventually all removed after an RFC.
  • When James previously introduced the VideoWiki to the medical project (Wikipedia talk:WikiProject Medicine/Archive 122#Video Wiki) he dishonestly used the example at Acute visual loss. This is actually a commercial video (https://medskl.com/module/index/acute-visual-loss) by yet another commercial training video company (MEDSKL) in private collaboration with Doc James. The video was released with a free licence so James chopped it up into segments, uploaded them to Commons, and replaced the human narrator with the VideoWiki narration. He then created the article Acute visual loss with text similar to the commercial video narration. This was then promoted as an example of "the easy creation of videos from scripts". What became very apparent is that these professional quality videos are not "easy to create" but require professional tools and real artistic talents.
  • The videos are in fact glorified PowerPoint slideshows with tedious robot narration. It is fine to listen to Alexa for a few seconds while she reads out the lead sentence of a Wikipedia article. It becomes tiresome to do this for several minutes. The slideshows generally repeat images already present in the article, combined with some cheesy stock images of people holding test tubes.
  • The narration scripts are article forks. So not only do you have to watchlist the main article but also the narration article. This doubles the exposure to vandalism, and is especially a concern while/if few people actually watchlist those narration scripts.
  • The slides used for the video are especially vulnerable to vandalism. Most media files on Commons are watchlisted by one user: the uploader. If an image is maliciously overwritten then it may be noticed by anyone looking at the article that uses them. But if the slide is part way through the video, then nobody will notice unless they look at the narration page (which won't appear on your watchlist as being changed) or watch the whole video.
  • Every time the narration text or choice of slide images is "collaboratively edited" someone needs to publish a new video on Commons overwriting the existing one. COM:OVERWRITE specifically forbids overwriting files with edits that may be considered contentious and are not of the most trivial and minor nature. You can remove a dust spot in the sky or straighten a horizon, but if anyone on Wikipedia thinks you can start "collaborating" or "fighting" over video content hosted on Commons, then I have news for you. All parties blocked. And indef blocks for anyone persisting. Commons is not a collaborative editing project: it hosts stable media files.
  • When source images do not fit the 16:9 aspect they are stretched (for example the start of the Polio video). This and other restrictions of the image format may lead to editors modifying existing in-use images to suit the video, thus disrupting the other uses such as thumbnails.
  • The quality of the end product is really dire. When similar videos, taking Wikipedia text & images and creating a slide-show + robot narration, started appearing on YouTube, they were recognised as a cheap con to try to earn a few $$ off of Wikipedia content alongside advertising. They would show up in your search results but after watching and listening for a few seconds, you realised you'd be conned and clicked back. James has previously highlighted the viewer stats for such videos, as proof that they are useful, failing to realise that the stats only show people falling for the con and accidentally watching a few seconds. Youtube banned monetising such videos and discourages their creation.
  • James has made claims that a WMF survey asked for more Rich content (multimedia). These and the other commercial videos are offered as examples of meeting that request. However, WMF did not discover exactly what is meant by "Rich content (multimedia)" and so claiming that "A robot-narrated article summary with slide show" meets that need is challengable to say the least. FWIW I think we could do with lots more very short video clips that illustrate something (e.g. a child with polio walking) but it could also be interactive media. For example Body mass index could include a calculator for users to find out their own BMI.
  • James and Pratik.pks claim some people are "visual learners" and so Wikipedia should serve that need for people who don't want to (or can't) read a lot of article text. The problem with this is that the concept of "visual learner" is pseusoscientific nonsense thoroughly debunked. We have no evidence that anyone benefits from the narrated-slide-shows James has created. When a blind user of Wikipedia was asked for their opinion, they said they were of no use and screen readers already provide the narration required.
  • When James says "A few of us" he really does mean a few. James, Pratik.pks and Ian Furst. That's not exactly a community. Really this needs to extend beyond Doc James and his wiki friends before it can realistically be considered. The fact that it has failed to engage wider editor involvement suggests James and Pratik have developed a half-baked "solution" to a problem Wikipedia does not have.
  • Wikipedia:Wikipedia is not YouTube.

-- Colin°Talk 13:24, 8 May 2019 (UTC)

@Colin: You are entitled to dissent and make criticisms of VideoWiki as a tool. However, going personal (especially the petty attack/portrayal of James) is not cool. I will not reply to your claims (which are derived either from assumptions or from half baked understanding of VideoWiki's features). We will have an Rfc on adoption of VideoWiki (when it is ready), and please feel free to criticize it all you want that time. I will definitely get back to all your points. Pratik.pks (talk) 16:56, 8 May 2019 (UTC)
Pratik.pks, my comments about James aren't just random personal attack or off-topic complaints. They are directly relevant to James current promotion of your VideoWiki tool. The conflict-of-interest promotion of Osmosis videos, the edit warring to force them onto medical articles where editors did not want them and found faults in them, the dishonest claims that Osmosis videos could be edited by the community, and the dishonest presentation of your VideoWiki tool using professionally created video material are all documented facts. You persist in using the phrase "collaboratively edited videos" when it has been previously demonstrated that the "video" content is not collaboratively editable. That's just not cool, in my book. Further, I don't think either you or James really understand Commons and how hostile the reaction will be there if this was ever to grow beyond a few wikifriends mucking about. You have created a "slide-show with robotic text-to-speech narration", which is a long way from the sort of quality video I can get when I turn on my TV or find a decent YouTube channel. This isn't what Wikipedia is about. -- Colin°Talk 22:08, 8 May 2019 (UTC)
Excellent arguments. As much as I like visualization, the Video namespace means slipping into Fahrenheit 451-like click-flick coverage, as no other reputable electronic encyclopedia includes such videos. WP:NOTREPOSITORY and the existing media content has proved itself sufficient for supplementing text. Brandmeistertalk 14:19, 8 May 2019 (UTC)
I've a few thoughts on the comments above:
  • Re: Osmosis videos - the whole videowiki system is a vital part of addressing the shortfalls of the osmosis videos - that they were not easily editable. There is a clear need for an integrated open source video editor so that video clips / images / text can be combined and edited (indeed there is also a need for a user-friendly, integrated image editor, even if it's only for cropping images). Existing videos could be similarly trimmed into sections and re-combined in VideoWiki. For users that don't want videos in the leads or later sections, it should be possible to include a preferences setting.
Re: the inclusion of video summaries of the abstract: Wikipedia has had full spoken articles since at least 2005, and this sort of platform would be considerably easier to edit and update than full-length articles, let alone edit videos that are currently on Wikipedia as single blocks.
T.Shafee(Evo&Evo)talk 07:57, 9 May 2019 (UTC)
I agree videowiki attempts to address the problem that the narration of externally created videos is not practically editable or referenced. But it does so with a robot voice, which is not engaging for periods longer than seconds. Fundamentally, though, it does nothing about the generation of engaging video (visual) content. There are commercial packages that create the "doodle videos" used for teaching but there is no open-source equivalent and such tools need to come with freely-licensed clip-art libraries or else used by very talented artists. Then there's the question of how would one make such video-creation and modification a collaborative process. So we have no community method of creating and maintaining videos. Just a way to combine existing media into a slide-show and add robot narration. The idea of using a "Video" namespace is part of the dishonesty along with claims for "collaboratively edited videos" -- the video part of these audio-visual media files is not collaboratively edited at all. There might be a place somewhere in the Wikimedia universe for this project, but it isn't Wikipedia. -- Colin°Talk 18:06, 9 May 2019 (UTC)

RfC: Removing locally-defined links to Commons categories if they match the Wikidata sitelinksEdit

Should we remove locally-defined links to Commons categories where they can be provided through the Commons category sitelinks on Wikidata instead? Thanks. Mike Peel (talk) 18:09, 4 May 2019 (UTC)

ProposalEdit

While we have been using interwiki links from Wikidata to provide the sidebar links to other language Wikipedias for the last few years, we are still mostly using locally defined links in sister project templates. In an RfC in August 2018, starting to use Wikidata to provide these links in the case of Commons categories was conditionally allowed, with the requirement to return to the community after further testing, which leads to this follow-up proposal.

Since the previous proposal, the following things have changed:

As the next step, I propose to bot-remove the locally-defined Commons category names from the categories and pages in Category:Commons category link is on Wikidata, where they match the Commons sitelinks from Wikidata. If this proposal is accepted, then I will submit a bot request for approval to do this using Pi bot. This change should have no immediately visible effect, but any future changes to the category names on Commons would automatically be updated here. This would not affect any locally-defined Commons category links that are not on Wikidata.

Pinging those that !voted in the last proposal: @Robby, Rhododendrites, Alpha3031, AfroThundr3007730, Johnbod, Jo-Jo Eumerus, Fram, Izno, GermanJoe, Compassionate727, Keith D, Peter coxhead, Ammarpad, Killiondude, Rschen7754, Nihlus, Finnusertop, ARR8, Gamaliel, Bidgee, Bluerasberry, GreenMeansGo, PBS, Wikisaurus, and Nemo bis:

Pinging as well those that modified template Commons category since 2015 and thos e who discussed the same category on it's discussion page: @Ahecht, Redrose64, Fayenatic london, Rich Farmbrough, Pigsonthewing, IJBall, Magnolia677, Andy Dingley, JJMC89, Zhanlang1975, Michael Bednarek, Krinkle, and FunkMonk:

Survey (Commons category links)Edit

  • Support as proposer. Thanks. Mike Peel (talk) 18:09, 4 May 2019 (UTC)
  • Oppose now – see below. Cluttering articles with links to Commons when these are in the sidebar isn't desirable. However, my support is conditional on the point noted below, that only the Commons category link that matches the Wikidata link is removed. (As has been discussed, here and at Wikidata, many times now, there are problems caused by Wikidata insisting on 1:1 inter-wiki relationships, when for various reasons different wikis, including Commons, don't have 1:1 links – e.g. for monotypic taxa, enwiki has one article, whereas Commons usually has a category for each rank.) Peter coxhead (talk) 09:51, 6 May 2019 (UTC)
    @Peter coxhead: Just to be clear, the proposal is to go from e.g., {{Commonscat|Example}} to {{Commonscat}} where the Commons sitelink on Wikidata is "Category:Example". The template itself would not be removed. Thanks. Mike Peel (talk) 10:32, 6 May 2019 (UTC)
    @Mike Peel: ah, my mistake. Then I now Oppose the proposal. So long as the template is present, then as with {{Taxonbar}}, I think it's better to explicitly document the connection. A tracking category is enough to flag up cases where none of the stated commons cat links matches Wikidata, as happens for {{Taxonbar}}. What I favour is removing the template altogether when the link will be in the sidebar. Peter coxhead (talk) 11:12, 6 May 2019 (UTC)
  • Support - as long as the Commonscat template is kept available for non-standard situations, this should be an unproblematic and reasonable change. GermanJoe (talk) 11:08, 6 May 2019 (UTC)
  • Support with the general expectation that only the matching values are removed. --Izno (talk) 11:38, 6 May 2019 (UTC)
  • Support Pages that link to more than one cat or have special need to keep the local link should be exempted, otherwise this is good. – Ammarpad (talk) 14:28, 6 May 2019 (UTC)
  • Fine by me. I can't comment on the technical details as they're beyond me (as usual). But in principle I don't see any issues. GMGtalk 20:58, 6 May 2019 (UTC)
  • Support - the Commonscat template should be kept available for non-standard situations. --Robby (talk) 21:22, 6 May 2019 (UTC)
  • Support this as a sensible next step — Martin (MSGJ · talk) 21:46, 6 May 2019 (UTC)
  • Oppose: The commons category listed in the Wikipedia article is the "ground truth", that is, users who actively contribute/watch to that article are presumably in consensus that this (or these, where there are multiple commons categories) is the most appropriate Commons category for this article. The information on Wikidata is merely a copy. Users who contribute to articles care about keeping them correct and safe from vandalism and often have real world topic knowledge, users who contribute to the Wikidata Qnumber are acting more in the role of a database administrator and are generally not familiar with the topic. By all means, take a copy of this into Wikidata but do not destroy the original information on Wikipedia. Firstly because that is a generally poor practice to remove authority over information from subject matter experts to database administrators, but more specifically because if someone vandalises the information on Wikidata, it will not show up on the watchlists of those who watch the Wikipedia article and damage will go undetected. It is one thing to exploit Wikidata information where the information starts its life on Wikidata (e.g. as an uploaded data set from some authoritative source). Rather than remove the information from Wikipedia, it would be better to add a template to flag on both Wikipedia and Wikidata where there is an inconsistency between Wikipedia and Wikidata, as I have seen done with coordinates, which is an invitation to investigate the matter and not impose the presumption that what is on Wikidata is always the "truth". We already have the ability for a commons category template on Wikipedia to default to the article title, and I never use that feature as I have seen too many times when the articles is renamed and nobody thinks about the implication of that move on the commons category (which has normally not been renamed). Kerry (talk) 23:50, 6 May 2019 (UTC)
  • Support I don't see any issues. Go on. Sincerely, Masum Reza 04:40, 7 May 2019 (UTC)
  • Support seems like a smart move -- reduces clutter in the markup, Sadads (talk) 18:13, 7 May 2019 (UTC)
  • Oppose Per Kerry's extremely well written and reasoned comments above. Beeblebrox (talk) 20:23, 7 May 2019 (UTC)
  • Oppose - If Wikidata isn't stable & nuanced enough for short descriptions, then I don't think it is for this either. I think it would be better to keep the info locally and have a bot set up a list or drop a notice on the talk pages of articles with differing cats or where only Wikidata has a cat. DaßWölf 22:17, 7 May 2019 (UTC)
  • Oppose. Compare the Commonscat box at right with the Wikidata link in the toolbar, and imagine a Commons link, or any other inter-project link, in the toolbox at left. Which one's more visible? As a longtime admin on both sites, I'm quite familiar with our layout, but I virtually never think of inter-project links appearing on the left, aside from other languages' Wikipedia articles. What about the newbies or those who never edit: do we expect them to find Commons links amid all the other stuff? It's much more reader-friendly to have a sizeable right-side box or an entry in the external links than to bury a link on the left side with lots of other things that are mostly irrelevant to someone who's not editing. Nyttend (talk) 22:44, 7 May 2019 (UTC)
    @Nyttend: You may want to reread the proposal. The box would stay in either case. ARR8 (talk) 00:28, 8 May 2019 (UTC)
  • Support per nomination. ARR8 (talk) 00:28, 8 May 2019 (UTC)
  • Oppose An edit that does nothing but remove local information that is already on Wikidata is functionally cosmetic. Bots performing cosmetic edits are not allowed per policy. * Pppery * survives 00:42, 8 May 2019 (UTC)
    You seem to have mischaracterized Wikipedia:Bot policy#Cosmetic changes. A bot implementing community consensus is specifically allowed regardless of whether the edit is cosmetic or not. Anomie 11:19, 8 May 2019 (UTC)
    @Pppery: As well as Anomie's point, I think it falls under "administration of the encyclopedia" - it's preventative maintenance. Thanks. Mike Peel (talk) 19:04, 8 May 2019 (UTC)
  • Oppose I agree with what Kery has said, to me the bigger issue is creating a process with excemptions as we know from practice that exemptions are rarely accepted once a policy is written, as groups of editors haunting the discussion boards see it as means to enforce uniformity and standidise everything to their preferred format. What could could be done is to allow for Qnumbers in {{Commonscat|Q00000}} to make the link Gnangarra 05:56, 8 May 2019 (UTC)
  • Oppose. Kerry put it well. I have long been troubled by persistent efforts for systematic bulk deletion of content from Wikipedia, in favor of obscure remote-ownership of everything by the bot-farm known as Wikidata. One of these days we need to reach a community consensus on the practice in general. Either we should transfer everything possible over to Wikidata and accept that that Wikidata is going to manage everything from now on, or we need to roll back Wikidata to tracking-categories and rare purposes of specific value. This endless struggle to roll Wikidata forwards (or backwards) one inch at a time is wasteful at best and disruptive at worst. Alsee (talk) 16:26, 8 May 2019 (UTC)
  • Support This is safe, raises quality, saves humans from tedious labor, stages content from English Wikipedia to migrate into other languages of Wikipedias, and this small project is a model for greatly scaling up integration of English Wikipedia with automated tools. I am keen on eventually using more automation in English Wikipedia for quality control and monitoring. We do not have the technology to apply automation generally everywhere, but for mundane things like limited category maintenance, automation and integration with Wikidata is a good fit for being unlikely to cause problems and likely to prevent problems. I recognize that people here fear wiki editors developing annoying edit bots, but personally I fear and am seeing bad actors with malicious bots attacking Wikipedia. We are entering an arms race and I want us to develop our technology and also advance conversations about how humans and bots will collaborate to sustain Wikipedia. The bad actors do not follow rules, and I want us to start the slow conversations with good actors and safe cases as we see here. I do not see this primarily as a technical experiment, because this proposal is so small in scope and so safe. Instead I see this as a social experiment for how we negotiate the introduction of quality control bots into English Wikipedia and across Wikimedia projects. I interpret the opposition here as resistance to Wikidata, slippery slope that this change pre-approves future risky changes, and resistance to bots consuming human attention on English Wikipedia. I definitely agree that bots cause stress to humans, but I see the solution to that as research, discussion, planning, and experiments, and not in an ongoing prohibition of this necessary and inevitable change. Relatively low-impact proposals like this are good experiments to get information about how bot-Wikidata-Wikipedia interactions play out. Blue Rasberry (talk) 19:43, 8 May 2019 (UTC)
  • Support As reduces issues when categories are renamed. -- WOSlinker (talk) 07:50, 9 May 2019 (UTC)
  • Oppose this scope creep of the obscure, poorly monitored Wikidata needs to stop. Plus, Kerry says it well, especially in the discussion below, eg: And please don't bother to say that Wikipedians can watch directly on Wikidata, because that is unlikely to happen and we all know it. In IT it is never a good idea to remove the authority over data from the subject matter experts to database administrators, as it usually disengages the subject matter expert and then data quality falls as a result of the disengagement. . - Sitush (talk) 07:58, 9 May 2019 (UTC)
  • Strong support (and actually, for most sister links). The links do often not lead to significant / more information - what is the use of looking on commons if I see exactly the same image or see 11 images on commons while 10 of them are already used in our article. And if there are images there that are of real significance, then they should be used (e.g. in a gallery). Commons categories often contain mostly the images already used in the article (and a promise that the commons category will/can grow is WP:CRYSTAL). I can see that there is sometimes a reason to include sisterlinks, but that should absolutely not be a standard, it should be a well considered and one should be allowed to challenge existing links based on content, not being countered with the argument 'it is standard' or 'we do that always'. --Dirk Beetstra T C 08:23, 9 May 2019 (UTC) I read this wrong, Oppose, this is not removing the sisterlinks from the bottom of the article, this wants all to be done through WikiData. WikiData is poorly monitored, local content should always have preference. --Dirk Beetstra T C 08:26, 9 May 2019 (UTC)
  • Support. Vulphere 12:26, 11 May 2019 (UTC)
  • Oppose per Kerry, and because of problems of consistency when more than one commons link is desirable in a Wikipedia article, which I think would be confusing after this suggested change. I think that Gnan's suggestion "What could could be done is to allow for Qnumbers in {{Commonscat|Q00000}} to make the link", could be worth pursuing as a compromise. -- PBS (talk) 17:01, 11 May 2019 (UTC)
  • Oppose per Kerry. I'm all for flagging pages where the template and wikidata don't match by putting them in a category for manual review, but vandal-fighting over at Wikidata isn't robust enough for us to be trusting it as an authoritative source. --Ahecht (TALK
    PAGE
    ) 21:57, 15 May 2019 (UTC)
  • Support This is a change that will allow us to better serve readers and editors alike by automatically updating data for the 99% of cases where Commons/Wikidata was updated correctly – Instead of preventing 1% of potential incorrectness at the cost of being outdated and likely wrong by default for 100% of cases, with no notification to editors that watch articles to know whether something might need fixing, until someone manually realise it (which is what we do today). There is currently no technology in place to notify us about a Commons category rename. What we do have is Wikidata. Commons users update this for us already (or even automatically, in case of simple page rename on Commons). This data can in turn be queried from articles. In addition, Wikidata has the ability to notify us (as Wikipedia editors) directly on our watchlists whenever such manual or automated change from Commons/Wikidata affects an article we watch. As such, we would still have the ability to review and fix these as-needed. I believe this fits in with a wider theme of giving ourselves more time to focus on the things that matter (e.g. reviewing meaningful changes to articles on our watchlist, improving the quality and breadth of our content), and demand less wasted effort on people manually fixing things that we could have prevented from breaking in the first place using a bit of automation. --Krinkle (talk) 22:35, 15 May 2019 (UTC)
    For those that oppose, I wonder what their opinion would be on a proposal for a bot that updates these templates automatically as an edit whenever the previous value on Wikidata matches the current value on Wikipedia (effectively the same proposal with similar Watchlist events, but more wasteful toward the limited time and resources that volunteer bot operators would spend). --Krinkle (talk) 22:35, 15 May 2019 (UTC)
    Krinkle if we were to run a bot, why would we want the bot to look at Wikidata at all? The bot should directly watch for Commons category moves. I think most opposes would spot that, and see your proposal as motivated by serving Wikidata advocacy itself. Alsee (talk) 00:08, 19 May 2019 (UTC)
  • Oppose now; maybe later. I looked at a few examples from Category:Commons category link from Wikidata to see how well it works at the moment. I found Category:5 Kanal (Ukraine) where {{Commons category}} generates "Wikimedia Commons has media related to commons:Category:Kanal 5 (Ukraine)." Well, that turns out to be a redirect; the Commons category was moved and then merged in October 2018. This demonstrates that the Wikidata links are not currently being adequately maintained. Therefore we should not yet increase our reliance on them. Bots would be better employed in tracing and fixing errors such as that one. – Fayenatic London 09:39, 16 May 2019 (UTC)
  • Oppose The use of a template without a parameter is very confusing for new users who scratch their head wondering where the data comes from. We should be making things easy for users by making it clear what we are linking to and where the data is coming from. It gets even more confusing for uses where there is 2 templates in an article 1 with a parameter and 1 without a parameter. There is also the unreliability of wikidata entries and no visibility that there has been a change to the destination of a link, unless you are also watching wikidata changes on an article. Watching wikidata changes just adds to watchlist length and can cause the limit of 1,000 changes to be reached far to easily. Report differences in the entries by tracking categories (removing the tracking category that it is on wikidata). By the way I did not get either of the pings that this was taking place. Keith D (talk) 12:26, 18 May 2019 (UTC)

Discussion (Commons category links)Edit

  • I think we have cases when one article has two commonscat templates pointing to two different categories. I suggest that these cases be kept. If there is only one commonscat template, I agree with the proposal to remove it. Whereas we do have vandalism instance at Wikidata, in which case the sitelink disappears or is invalid, we have way more cases of commonscat templates pointing out to redirects just because the Commons category was moved and the template has not been updated.--Ymblanter (talk) 18:24, 4 May 2019 (UTC)
    @Ymblanter: In cases where there are multiple commonscat templates in one article, this proposal would only remove the local text from the one that matches the sitelink. I can add an exception to avoid those cases if that's what we want to do, though. With that type of vandalism, that would be a cross-project problem to fix, and it would be caught by tracking categories both here and on Commons. Thanks. Mike Peel (talk) 18:39, 4 May 2019 (UTC)
  • @Mike Peel: FYI, I didn't receive your ping, and I assume the rest didn't either. Probably you've not signed the edit with the mentions. – Ammarpad (talk) 04:58, 6 May 2019 (UTC)
  • Request for example @Mike Peel: Can you provide an example where this proposal would change things? Can you talk through what the bot would check in that case to determine the need for a change? Blue Rasberry (talk) 13:55, 6 May 2019 (UTC)
    @Bluerasberry: For example, Category:2012 in the Maldives linked to commons:Category:2012 in Maldives, which was correct until the commons category was renamed. That was automatically updated on Wikidata, but required a bot edit here rather than updating automatically (as it would have if the locally defined text didn't exist). You can look through the edits of Pi bot to find many more examples like this. You can also dig through the other commons category tracking categories to find cases where the bot hasn't managed to catch it for some reason. The new bot would check for cases where the commons sitelink exactly matches the locally defined one, and would only remove it if that was the case. Thanks. Mike Peel (talk) 19:21, 8 May 2019 (UTC)
    I see, thanks. Blue Rasberry (talk) 19:43, 8 May 2019 (UTC)
  • When pulling from Wikidata, is there a link to the page where an edit may need to be made to correct the issue of a bad link (whether that's the same item or the category item)? --Izno (talk) 18:56, 7 May 2019 (UTC)
  • @Kerry Raymond: A sensible argument. If there were only the two sites, Wikipedia and Wikidata, then it could be said that Wikipedia, as the more active site, would be a good place to keep the data, since more people will monitor it. But consider: there are more than two sites. Besides the English Wikipedia, there hundreds of other Wikipedias, not to mention sister projects and all of their languages. Is English Wikipedia really the more active site for every page? Many of our pages are stubs, and some of those same pages are flourishing on other language editions. Wikidata is the natural central location to keep all of these links, so all of the Wikimedia family wikis can benefit from each others' work. ARR8 (talk) 00:34, 8 May 2019 (UTC)
    Is this RfC occurring on all Wikipedias and only proceeds if all WPs agree? This village pump can only decide policy for en.WP and not impose it on other Wikipedias and vice versa, so I don't see this as a relevant issue unless it's a global proposal. I don't have a problem with a Commons category being suggested based on information held in Wikidata but not to impose it. Kerry (talk) 02:01, 8 May 2019 (UTC)
    @Kerry Raymond: This RfC is enwp-specific, I'm not sure there's a good place to raise it globally across the different Wikipedias? But regardless of that, I'd contest that the 'ground truth' of this is now the sitelinks on Wikidata, not the locally defined text here. The sitelink is used on Commons to add the interwiki links to the various Wikipedias in the sidebar (the same as interwikis work here), and to display information from Wikidata about the topic of the category (through the infobox there). If that sitelink is wrong, then a Commons editor can fix it by editing Wikidata. However, that won't currently fix the link to the category from here, unless they also come to enwp to fix it, which they won't if it's a topic in a non-English country (I know you mostly edit about Australian topics, but think about editors that work on Portuguese or Spanish content both on their language wikis and on commons). Vandalism of the sitelinks is possible, but it's not trivial - you have to change the sitelink to point to a different, existing, category (compared with just changing some text in an article), so it's unlikely. For the cases that this RfC is concerned about, the information here is merely a copy that can easily go out of date. I'm out of energy to argue about your other points now, I'll follow up on them another day. Thanks. Mike Peel (talk) 19:39, 8 May 2019 (UTC)
First, I note it has not been raised on Commons:Village_pump/Proposals and that's just one place, but if the benefits are for all WPs as sugggested above, surely all WPs should be in this conversation. Kerry (talk) 23:22, 8 May 2019 (UTC)
Second, I don't think you understand what is meant by "ground truth", which Wikipedia defines as "information provided by direct observation (i.e. empirical evidence) as opposed to information provided by inference". In science, the ground truth is the laboratory notebook; you never destroy them, just because the information has been copied elsewhere, because in the event of questions/dispute, you always go back to the lab notebook. When it comes to Commons categories, the ground truth is the decision/consensus of editors on Wikipedia. Are you seriously proposing that Wikidata editors should decide from now on which Commons categories should be added to a new article and not Wikipedia editors? How will it work in practice? Let's say I have an article on the Marian sugar mill which has its commons category set as Category:Sugar mills in Queensland. Let's say someone takes a lot of photos of that mill and creates a sub-category on Commons called Category:Marian sugar mill, which is a better commons category for the article to use. Who will update it and how? A Wikipedian do so by updating the template in the Wikipedia article to add the new category, or will they be forced to go to Wikidata to do this? Can we have this proposal spelled out for the whole lifecycle please, currently all it deals with is taking existing information away from Wikipedia and does not explain what happens next, how updates will be oversighted, how and where disputes will be conducted. If we go down this path, I think we need Wikidata watchlist notifications that affect the Commons category to be propagated through into the watchlists of Wikipedia articles (on all WPs) that are affected by it. Not *all* Wikidata updates to the Qnumbered thing, just the ones affecting Commons category. If the watchlist situation can be resolved and the ability to update the Commons category locally from Wikipedia (and not having to learn anything about Wikidata), then I would be much less worried. Because who on Wikidata is putting their hand up to watch the Queensland sugar mill edits that I would normally watch on Wikipedia? And please don't bother to say that Wikipedians can watch directly on Wikidata, because that is unlikely to happen and we all know it. In IT it is never a good idea to remove the authority over data from the subject matter experts to database administrators, as it usually disengages the subject matter expert and then data quality falls as a result of the disengagement. Kerry (talk) 23:22, 8 May 2019 (UTC)
@Kerry Raymond: I'd be happy to point this proposal out on Commons and elsewhere, but then I'd probably be accused of WP:CANVASS. :-/ With most of what you say, substitute 'Commons' in place of 'Wikipedia', and it changes the perspective. The point is that Commons editors also play an important role in linking Wikipedias<->Commons, and using Wikidata to do this in one place is a lot better than doing it in multiple places. I'm not proposing to remove the ability to set a local link here if needed, so in the example you give you could still define that manually, I just propose to remove the duplication of exact data. There are over 2 million commons sitelinks now, and the 600k or so here is just a subset of that. Thanks. Mike Peel (talk) 06:08, 9 May 2019 (UTC)
It's only canvessing if you do so in a way to influence someone and, yes, the RfC as written does run that risk as it is supposed to be written to be NPOV. So rewrite the RfC to be NPOV and then advertise it on other sites that it affects. Kerry (talk) 07:20, 9 May 2019 (UTC)
In practice, I see a lot of Commons categories which were set here on the English Wikipedia long time ago and then moved on Commons. Our template leads nowhere (or sometimes to a category redirect) because nobody cared to go here (and to 200 other Wikipedias) and update the commonscat template. However, if a category has been moved on Commons, the record has been automatically updated on Wikidata, and the sitelinks in the same articles are usually correct.--Ymblanter (talk) 15:00, 11 May 2019 (UTC)
Oh, I see, Mike Peel has already made above the same point.--Ymblanter (talk) 15:02, 11 May 2019 (UTC)
@Ymblanter: It's a good point, worth repeating. :-) A lot of the work I've been doing here recently has been to try to fix these (by bot/manually), but it takes time, and it would be better if the problem didn't exist in the first place, hence this proposal. I hope you consider !voting on it. Thanks. Mike Peel (talk) 15:38, 11 May 2019 (UTC)
  • One of the concerns with {{Commons Category|<no parameter>}} was that if the article was moved, the category would then be wrong. This is the reason we have been adding parameters. Ideally this would track moves of the Commons category too. I'm not sure if this proposal addresses the first issue. All the best: Rich Farmbrough, 12:59, 16 May 2019 (UTC).
  • @Rich Farmbrough: - Yes, that's the idea. If things work correctly (they don't always), when you move a page on a local project that is linked to Wikidata, the software will automatically update WD with the new location. This applies equally to local moves here and it does on Commons. GMGtalk 13:05, 16 May 2019 (UTC)
    • But could the WD entry be manually overwritten, thus allowing a vandal to play havoc? - Sitush (talk) 06:39, 18 May 2019 (UTC)
      • @Sitush: How do you mean? The sitelink must link to an existing page, which should avoid most vandalism. Thanks. Mike Peel (talk) 16:30, 18 May 2019 (UTC)

Template capitalizationEdit

Hi there, forgive me if I posted it in the wrong thing or if I repeated something. But my proposal is that if we have a page "Template:ABC", then {{ABC}}, {{abc}}, or even {{AbC}} should link to "ABC". Basically we don't check capitalization when transcluding or subsituting templates.

Sometimes I type things wrong (for example, the WikiCat userbox). If I use the search bar, typing "Template:ABC" and "Template:abc" automatically redirects to "Template:ABC", but for transclusion, it does not. – Ben79487 04:31, 15 May 2019 (UTC)

This is in the realm of "not going to happen". --Izno (talk) 12:48, 15 May 2019 (UTC)
Page names are not case sensitive except for the first letter of the title and (except in the mainspace) the first letter of the main part of the title after the namespace name. To make transclusions work differently, or to make the Template: namespace work differently, is unlikely to happen. In cases where a particular letter would be likely to be uppercase where it should be lowercase, we have redirects (for example, {{Automatic Taxobox}}->{{Automatic taxobox}}); however, we don't create these except where we believe them to actually be necessary. עוד מישהו Od Mishehu 13:39, 16 May 2019 (UTC)
Removing case-sensitivity on second and subsequent letters would create difficulties where we already have two (or more) templates whose names differ only in capitalisation yet have very different functions. For instance {{ESP}} and {{ESp}}; there is also {{Esp}} which now redirects to {{ESp}} but until about five years ago it had another purpose, it's been moved to {{E-sp}}. --Redrose64 🌹 (talk) 16:34, 18 May 2019 (UTC)

Add BibLaTeX citation entry to MediaWiki:CiteThisPage-contentEdit

Please check out my proposal at MediaWiki_talk:Citethispage-content#Add_BibLaTeX_citation_entry. metarmask (talk) 07:46, 15 May 2019 (UTC)

Expanding InternetArchiveBot to handle book referencesEdit

Since May 2015, User:InternetArchiveBot, aka IABot, has been continuously working to restore dead URLs by relinking them to archive snapshots. While IABot primarily links to Wayback Machine URLs, it’s able to handle over 20 different archive services. To date more than 10 million “broken” links have been repaired. This has helped a great deal to enforcing and maintaining WP:VERIFIABILITY.

Today, I am proposing a new feature of IABot to add links to referenced books from Archive.org. IABot will search for books referenced in enwiki articles and link to any it finds available at archive.org. Book references containing page numbers will link straight to those pages allowing editors and readers to more easily verify the contents of an article referencing the book. Here is an example of such an edit IABot would be making to an article.

An example of the benefit of this proposal can be seen on this article: Martin Luther King Jr. where pages from 54 referenced books are now just a click away from readers. For example Citation #1. As can be seen, any book reference with page numbers will make the title and the page numbers link straight to the desired page of the referenced book. References that have the title wiki-linked elsewhere will only have the page numbers linked.—CYBERPOWER (Chat) 17:45, 17 May 2019 (UTC)

SupportEdit

  • Support, provided that Archive.org's books are available everywhere. It'd be a more universal version of Google Books, although I wonder whether/how it would work for "short form" references. (e.g., given a book "Book" by John Doe, with an entry in a Bibliography but with inline citations of the form "Doe p. 54", would the bot work just on the Bibliography, on each short-form reference, or both/neither?) – John M Wolfson (talkcontribs) 18:06, 17 May 2019 (UTC)
  • Support. Vulphere 10:07, 19 May 2019 (UTC)
  • Support. The Internet Archive is a top-notch, efficient, highly helpful, diligent nonprofit and this proposal would make our references more useful and open for our editors and readers, which is the same as what IABot and the Internet Archive have already been helping us do with web citations. In response to the oppose, IA books that are public domain are accessible for free without registration, and other books can be electronically "borrowed" free of charge (account registration is required in order to fulfill a legal requirement). No money ever changes hands, nor is there any advertising. We're being handed a wonderful service here, and I can't see any good reason not to take it. Making it easier to access references that are otherwise time-consuming and expensive to check will also improve the overall verifiability of our articles. Best, Kevin (aka L235 · t · c) 23:37, 19 May 2019 (UTC)
  • (Summoned by bot) Support Sounds like a good idea. SemiHypercube 12:24, 20 May 2019 (UTC)
  • Support. Always great to see non-profit projects working together for the benefit of the users of both and our shared vision of free access to knowledge. This is a no-brainer. Gamaliel (talk) 21:56, 21 May 2019 (UTC)

OpposeEdit

  • Oppose This is part of a paid effort by Internet Archive (Cyberpower678 has declared) to advertise their new book loan service. There is nothing in it for us. The previews are by and large useless (they only display the covers, table of contents, and index), with the suspicious exception of books cited by the Martin Luther King Jr. article: I want to know if Internet Archive or the article has been modified specifically to feature pages that are "just a click away from readers", whereas this is overwhelmingly not the case with Internet Archive's preview with any other set of books. (see my comment below) – Finnusertop (talkcontribs) 16:58, 19 May 2019 (UTC)
    Finnusertop, See my response to your comment below. —CYBERPOWER (Chat) 17:11, 19 May 2019 (UTC)
    To be pedantic, the service isn't new; it's existed for at least a few years. The Open Library, which may or may not be the same service, has existed since 2006. Jc86035 (talk) 17:24, 19 May 2019 (UTC)
    I might also add that archive.org isn't advertising anything. User's are not required to loan out the book to see the referenced pages on the book. While the standard link only shows the covers of the book, IABot would insert a link going straight to the page of the book that is being used to reference material on an article. User's are however required to checkout the book, which is free, if they wish to access the complete copy, i.e. more than what is being referenced on the articles and the covers.—CYBERPOWER (Chat) 17:28, 19 May 2019 (UTC)

DiscussEdit

Per my above support concerning various forms of inline citations, such as short-form citations common in FA's, parenthetical citations, and use of Template:Rp. I think the bot could and should work to link such citations as well. Here are some putative examples, using the Main Page as a dummy link:

  • Doe p. 54 -> Doe p. 54
  • (Doe p. 54) -> (Doe p. 54)
  • [1]:54 -> [1]:54

References

  1. ^ a b Doe

I think the above assertion that we should apply the bot to such various cases if this proposal passes is fairly obvious. Less obvious is HOW the IABot would do so. I think it would have to see the text that's enclosed by <ref> tags (less such stuff as page numbers), and look through a section titled "Bibliography" or "Further Reading" to see if the matched text is present in a last name parameter of a template, and then scan the rest of the book data and make the requisite links. I'm not the most technically skilled and I don't mean to be an armchair coder, but just some food for thought. – John M Wolfson (talkcontribs) 18:23, 17 May 2019 (UTC)

Would there be a check on publication date / edition / isbn? Page numbers and textual contents can change between editions. If shortened footnote citations are used would it be best to leave these alone and only alter the "works cited" listings without the page number links? Thincat (talk) 19:36, 18 May 2019 (UTC)

Thincat, right now, the idea is to do ISBN matching, but our analysis of the ISBNs shows that this can be problematic sometimes. So we are working to expand beyond ISBN matching. Right now IABot’s dataset is very conservative to ensure more accurate results. —CYBERPOWER (Chat) 18:12, 19 May 2019 (UTC)

Internet Archive has two kinds of books: Public domain books are immediately accessible to anyone and useful to link to. But that is not what this proposal is primarily about. The rest of the books on Internet Archive only provide highly limited previews. In order to access these books, you need to register and loan the book. Usually, the preview is just the covers, table of contents and index (so parts of the book that are unlikely cited). Extremely suspiciously, the pages that Martin Luther King Jr cites are the only pages those books have on preview. Cyberpower678: have you asked Internet Archive to enable preview of certain pages that are cited at Martin Luther King Jr, or modified the article to cite pages that are offered on preview?

This is a service that the Internet Archive is desperate to advertise on Wikipedia. After their plans to have our citations say "Donate book to Archive.org" fell through, this is probably the next best thing for them – but not us. We would be introducing en masse "convenience links" that simply privilege one provider over countless of others that loan or sell books. For this very same reason, WP:NOTADVERTISING, we don't add "convenience links" to Amazon or any other subscription service en masse. We already have metadata and ISBN, and that's enough for anyone interested in the book to find it through their preferred method, which may or may not be Internet Archive's loan service. – Finnusertop (talkcontribs) 16:58, 19 May 2019 (UTC)

Finnusertop, any book being linked straight to a page number is immediately visible to the reader clicking it. Try it out for yourself by inserting a page number into the URL. I am being paid to implement the bot, but I am not being paid to promote archive.org. I'm a Wikipedian first here. Unlike what you claim, I propose to the community gadgets, or bots, that benefit the community. This is not an advertisement whatsoever, as archive.org is a non-profit organization. This is a coordinated effort between the WMF and archive.org to make sources more readily accessible to ANY reader. So your claims of me pushing this out as a last ditch effort is unfounded. It was already planned since before the gadget came out to have IABot blue link books. The gadget was just an intermediate step to make it more quickly accessible to users. Note that we didn't push this after it fell through. —CYBERPOWER (Chat) 17:09, 19 May 2019 (UTC)
@Cyberpower678: thanks for answering my question and explaining how the preview works with specific page numbers as well as the development process. I'll have to give some thought to this. – Finnusertop (talkcontribs) 17:28, 19 May 2019 (UTC)
Finnusertop, Sure. I will be happy to answer any questions for you. Just know, our goal is to serve Wikipedia and the community. Not to advertise on it. Our goal is to make references more readily accessible. FTR, the donate book link was just an experiment to help archive.org expand its free library and in turn provide readers with free access. It will not be a part of this bot task as the very notion of it was rejected in the previous RfC. —CYBERPOWER (Chat) 17:34, 19 May 2019 (UTC)
How legal is this service for copyrighted books? Wayback gets away with archiving webpages, as does google, and while Google offers some limited book previews, I'm not sure how archive.org's racks up. I know archive.org generally strives to be legal, so I'm not thinking they are purposing violating copyright, but... --Masem (t) 23:55, 19 May 2019 (UTC)
IANAL, but to my understanding, for non-PD books, the way that the Internet Archive grants access to full books is by asserting that it's a library and merely digitally loaning the book to visitors. (They actually keep all the physical books for this reason.) That's why you have to "borrow" and electronically "return" the book if it's not PD in order to view beyond a snippet preview. Best, Kevin (aka L235 · t · c) 00:51, 20 May 2019 (UTC)

Remove "suspected perpetrator" field in Template:Infobox civilian attackEdit

(Discussion moved from Template talk:Infobox civilian attack#Suspected perpetrator field? on recommendation to gain full consensus.) I struggle to see the benefit of listing a "suspected perpetrator" in an infobox, especially when a suspect is part of an ongoing case and will be either removed or moved to "perpetrator" when that is complete. Looking at Christchurch mosque shootings and the contention over how prolific suspect Brenton Tarrant's name should be (see ongoing RfC about keeping suspect's/suspects' name in lead), I don't think his name in an infobox offers any encyclopedic value (officially and legally, as little doubt as there is over his guilt, it has not been proved yet) and if anything only unduly promotes his name which we should also avoid. When a suspect is proven to be a perpetrator, they become part of the historical/encyclopedic record of the attack rather than the subject of a current matter/desire for notoriety. Christchurch is one particular case, but I don't think it's unique in this regard. I suggest this field be removed. U-Mos (talk) 03:28, 22 March 2019 (UTC)

(Comment copied from original discussion) I concur. There's no reason for this parameter to exist – when the identity is known and certain, the appropriate parameter is "perpetrator", and when it is not, it doesn't belong in the infobox at all to begin with. TompaDompa (talk) 08:17, 22 March 2019 (UTC)
  • I agree. This gets into NOTNEWS territory. We have to be aware that a reported “suspect” can be falsely accused (for example: the reports that Richard Jewell was a suspect in the bombing that took place during the Atlanta olympics). At a minimum, we need to wait until a “suspect” is actually charged with the crime before we report names. Blueboar (talk) 12:59, 22 March 2019 (UTC)
  • I also agree. If suspects are to be named in the article then we can word things to make it clear that they are only suspects, and to say whether they have been charged or prosecuted, but an infobox entry is too blunt an instrument for such sensitive content. Phil Bridger (talk) 13:33, 22 March 2019 (UTC)
  • The idea makes sense, but I know from how less experienced editors see infobox fields and if you took out the suspected perp field, they will want to fill the name in on the actual perp field because they feel it would complete the infobox (unaware of the implications of this towards BLPCRIME). --Masem (t) 13:36, 22 March 2019 (UTC)
    • Well, that gets us into the murkier question of what fields should be included in an infobox in the first place. Perhaps we shouldn’t even have a “perpetrator” field. Indeed, when it comes to this sort of topic, we probably need to question whether an infobox is aporopriate at all. Is an infobox an appropriate method for conveying information in an article about a mass killing? Blueboar (talk) 13:55, 22 March 2019 (UTC)
      • Arguably yes, it just shouldn't be filled in until after conviction. (Contrast that to a religon= field in the BLP infobox ) Its that well-intentioned editors unaware of why the field is blank will think to fix it blindly. --Masem (t) 14:09, 22 March 2019 (UTC)
        • Deprecate |perpetrator= and add |convicted_perpetrator=. --Izno (talk) 14:15, 22 March 2019 (UTC)
          • That would of course mean that when the perpetrator dies and there is no trial, there is nowhere to add them. Which is not necessarily a bad thing. TompaDompa (talk) 17:28, 22 March 2019 (UTC)
            • I think we should find a way to identify the perpetrator in some such cases, for example if there is a mass shooting that ends with the perpetrator killing himself (it's nearly always a "him"). The best way to deal with this whole issue would be for Wikipedia to stop trying to be a news service and only to have articles about events when good secondary sources (which breaking news reports are not) exist, but people putting forward that point of view always seem to get shouted down by people saying, "of course it's notable, it's front-page headlines in all the newspapers." Phil Bridger (talk) 17:50, 22 March 2019 (UTC)
              • +1. Never lose the dream, even if forced to drop the stick. ―Mandruss  21:56, 22 March 2019 (UTC)
            • And in cases where the perpetrator dies and there is no trial I believe that there's a difference between jurisdictions. In some places an inquest into the death of a victim will name in its verdict the person who caused the death, and in others it will not. Phil Bridger (talk) 17:54, 22 March 2019 (UTC)

I support changing "perpetrator" to "convicted" - feels more appropriate for factual record rather than mere description of an event, and hypothetically if there was an appeal in process or new doubts over a historical case it wouldn't invite any unnecessary infobox changes. U-Mos (talk) 06:23, 23 March 2019 (UTC)

Changing Wikipedia's infoboxes because some politicians want to play damnatio memoriae is not a good idea. Offering a choice of a "convicted" field per User:U-Mos is reasonable, but a plain "perpetrator" field should remain as an option even so. Because sometimes, for example, a widely known perpetrator might flee to ISIS territory or the next equivalent and not be prosecutable. Suspected perpetrators also should be described when sources widely describe the accusation. (WP:WELLKNOWN) Wnt (talk) 07:42, 23 March 2019 (UTC)

I don't see how describing suspected perpetrators in the infobox, where the room for nuance is scant to none, would be helpful. In prose is a different matter. TompaDompa (talk) 10:34, 23 March 2019 (UTC)
Why not? There are a lot of cases where the perpetrator is known beyond reasonable doubt but will never be convicted. Judicial sentences are not the only reliable source of information. On contrary there are cases where the person convicted is known not to be the perpetrator! Would not it be helpful to describe convicted but not guilty persons in the inforbox where the room for nuance is scant to none helpful? You seem to put to much trust in formal convictions. In addition, what is conviction? There is no clear definition of this term. Ruslik_Zero 08:45, 24 March 2019 (UTC)
That a convicted person may not be the perpetrator seems a very good reason for the change to me. Having the field as "convicted" removes any form of supposition, leaving any nuances or complications to the prose where they can be outlined in all necessary detail. U-Mos (talk) 08:53, 24 March 2019 (UTC)
This is incredibly poor reason. 90% people do not read beyond the infobox. Ruslik_Zero 13:47, 27 March 2019 (UTC)
  • Convicted is not quite the right answer. If the perp dies he is not convicted. If he confesses or brags/claims responsibility we can name without conviction. I'd venture that at least half the places this box would be used never see a conviction. Legacypac (talk) 09:28, 24 March 2019 (UTC)
    • Why's that an issue? If they die, and are therefore not convicted, do they need to be in an infobox? U-Mos (talk) 23:05, 25 March 2019 (UTC)
      • Yes, they need to be in the infobox because this is important information. Ruslik_Zero 13:47, 27 March 2019 (UTC)
        • +1 to LegacyPac's point about conviction being the wrong standard for this, with suicide bombings and most unprosecuted war crimes being two obvious cases where the perpetrator is known with certainty but there is no judicial process confirming guilt.--Carwil (talk) 17:15, 1 April 2019 (UTC)
  • Creating an additional template for suspects and one for perpetrators would remove all the confusion. ~^\\\.rTG'{~ 23:35, 25 March 2019 (UTC)
  • Oppose. In some cases it is appropriate for us to name the perpetrator prior to his conviction (e.g. when extremely widely reported in highly public events, or when the suspect evaded capture and trial (which in many places can't be done in absentia) - but it known with a high degree of certainty). In other cases - e.g. historic cases, events in warfare, etc - while we might not have a definite perpetrator it might still be appropriate to name in the infobox those covered extensively in RSes. Icewhiz (talk) 11:45, 2 April 2019 (UTC)
  • The template should first be merged into {{Infobox event}}; then the parameters should be rationalised. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:40, 2 April 2019 (UTC)

Note: This proposal was restored from the archive for the purpose of consensus being assessed and the discussion closed. TompaDompa (talk) 22:31, 18 May 2019 (UTC)

  • Not sure if this means it's still open for votes, but if so support per WP:NOTNEWS, etc. Any time it's actually warranted can be covered in article prose. – John M Wolfson (talkcontribs) 23:35, 18 May 2019 (UTC)