This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
Allow users to delete their sub-pages (pages like User:UserName/ThisIsASubPage ) - Reduce Admin backlog
DECLINED:
As many participants of this discussion have pointed out, these proposals have many flaws and easily prone to abuse. Admins are trusted members of the community and they are expected to make good judgements even in deletion process. There is no evidence that this will help to reduce admin backlogs. In fact, inexperienced users may increase the workload of admins by poor deletions. I think there is pretty much consensus that delete right should be restricted to admins. In fact some of these ideas are not supported in current Mediawiki software. A bot could be created to serve these purposes, but it still seems to be open to abuse. I am closing this thread per w:en:WP:SNOW. Thanks. Masum Reza📞22:21, 22 October 2019 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Note : The community need not to worry about a user moving something to subpage, can easily be stopped by detecting contributors. And it's possible, I have used this in User:FVCBot. The api is good enough for task like detection of contributor to a page. -- Eatcha (talk) 02:33, 19 October 2019 (UTC)
Give ALL users right to delete subpages (includes Autoconfirmed/confirmed )
Strong oppose Unless you are going to remove the ability to move pages from everyone as well. Allowing for the deletion of subpages is the same as allowing deletion of everything. Incredibly unwise. --Majora (talk) 20:44, 18 October 2019 (UTC)
Strong oppose Unless you are going to remove the ability to move pages from everyone as well. Allowing for the deletion of subpages is the same as allowing deletion of everything. Incredibly unwise. --Majora (talk) 20:45, 18 October 2019 (UTC)
And we shouldn't be relying on a bot to catch something that shouldn't be technically possible in the first place. --Majora (talk) 02:49, 19 October 2019 (UTC)
User:Masumrezarock100, what do you think it would get approved ? Coding is the easiest part in this case, to have an administrative bot is same as running for an Rfa(I'm not interested, but I will fail anyway. Just 9 months on commons. It's the hardest part ) . Would you trust a user with 9 months of editing history to write/operate an administrative bot ? That deletes pages ? 'Crats: run for RFA. I had my one bot on hold, as it takes much more time than necessary to get a non adminstration bot approved, it was quite simple. Used vision AI api to review. License but I didn't had enough time to keep looking at that request and now it's on hold. Eatcha (talk) 03:49, 19 October 2019 (UTC)
@Eatcha: my name is not Masumrezarock100, but anyway.. At the very least, the bot would have to check the page has never been moved. It would have to check the page isn't linked or transcluded from anywhere. And that you didn't just remove all links and transclusions. It would have to check that you are the only contributor. It would have to check if the page has been deleted before, which could indicate trouble. And it would have to check if the page was created recently.
But even with all that, I don't think anyone should be allowed to do it. Perhaps autopatrollers. I just realized there could be legal issues otherwise. Theoretical, but still. - Alexis Jazzping plz06:47, 20 October 2019 (UTC)
@Alexis Jazz:
What I know can be done(becasue of api easier to code):
Move detection
contributor detection
creation date detection
creator detection
linked page detection
I don't know If deletion detection is supported in wikibot api, it can be supported (without using the api). If this gets approved I can write it(if communty approves me, higly unlikely IMO), any admin can then operate it using commandline arguments(Command line arguments is best way to make a bot easier to run by non-tech users). I don't think this would get approved though, community is clearly against it. Best, Eatcha (talk) 09:23, 20 October 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
When somebody uses e.g. the de:WP it should be well known that there are many 'search' abbreviations; as an example, H:T will make some suggested expansions, like Hilfe:Tabellen, or H:V like Hilfe:Vorlagen. That simplifies the access to many pages - not only to Help pages.
Spoiled by such comfort, I am missing a comparable service in the commons, where I am doing a lot. On busy days I type hundreds times the long namespaces Template: or Category:, wishing it would as well be possible with only T: or C:. To install such a possibility could not be a problem to the relevant people!
In the English language, many terms are pleasantly short (Help, File, User); really longs things are abbreviated (i18n); I just miss the mentioned cases - therefore I ask the community about that idea. -- sarang♥사랑15:07, 16 June 2019 (UTC)
@Sarang: C: is not desirable because this is the recommended interwiki code for Commons. We have COM:, templates can be linked with {{Tl}} and when using templates you don't usually need to enter Template:. See also COM:Shortcuts. - Alexis Jazzping plz16:20, 16 June 2019 (UTC)
Thank you. Ok, C: is not desirable, I understand that it is the wrong example. But when I want to enter a special template, or category, I always have to type the full namspace: first. I know that we have short-named templates, like {{C}}, {{F}}, {{T}}, {{U}}. But that's only for using/linking them - not for searching. -- sarang♥사랑16:41, 16 June 2019 (UTC)
@Alexis Jazz: I guess that is the problem of future, not now. In my opinion, WMF already hosts too many projects, and new projects should not be added too easily, and I guess we have not had a new project for many years (excluding Wikidata). 4nn1l2 (talk) 20:42, 16 June 2019 (UTC)
Support the aliases mentioned by @4nn1l2, plus U for User, F for File, and T suffixes for associated talk namespaces (UT for User Talk, GT for Gallery Talk due to conflict with Template). — Jeff G. ツ please ping or talk to me20:33, 16 June 2019 (UTC)
I only support t for template and cat for category. Inclined to oppose the others. Use shorthands only for the most frequent words.--Roy17 (talk) 19:02, 18 June 2019 (UTC)
Strong support I think we have pretty much consensus here. This proposal has been proposed since June. Would someone close it and open a phab ticket? Masum Reza📞21:31, 21 September 2019 (UTC)
I would support CAT: and MOD:, but I have doubts about T. Would support TEM: for template though. UT: for user talk also seems fine. - Alexis Jazzping plz01:01, 23 October 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Support Obviously, given my comments at AN. As I said there, that this is not available on Commons currently almost seems via technicality, as we have no page mover right, and therefore no user right with suppressredirect un-bundled from the sysop toolkit, while other large projects do. I understand that we don't normally want to suppress redirects at all, and this would, I imagine, mostly be used in the case of round-robin moves (a to c, b to a, c to b). In these cases it seems simple enough just to have some template saying that a redirect was suppressed/the file renamed and replaced. Guidance may need to be updated in that respect, although the current guidance (These redirects should almost never be deleted.) seems fairly straightforward. Even so, we have seven times more file movers than we have sysops, and it seems that someone who is experienced enough to understand the comparatively complex criteria for moving files should be competent enough to know whether suppression is necessary. GMGtalk14:58, 21 August 2019 (UTC)
Support - I too have occasionally had to do moves like this and it's frustrating having to rely on an admin to do it (I could apply to be an admin but I prefer a non-admin easy life tbh). –Dave | Davey2010Talk18:27, 23 August 2019 (UTC)
Support but would strongly prefer this to go along with a new flag per 大诺史. I can easily envision filemovers persistently forgetting not to leave redirects when they should, and I'd rather not have to remove their whole filemover right. Storkk (talk) 19:00, 23 August 2019 (UTC)
Strong support: i don't agree with new flag thing but allowing file movers to suppress redirect will be very useful. -- CptViraj (📧) 18:05, 27 August 2019 (UTC)
Note The Ajax moving script will not allow the suppression of redirects if a file is in use. There are ways around this restriction but that fact, I believe, is not well known and in any case the suppression of redirects of an in use file should simply not be done. The creation of redlinks by the purposeful suppression of redirects of an in use file would be considered abuse of the right and grounds for removal in my mind. Just thought I would put that out there. --Majora (talk) 21:29, 28 August 2019 (UTC)
Oppose Deleting or suppressing redirects is a very disruptive practice in most cases and there's no need to make it simpler. In the very rare cases where it's appropriate, an admin can take care of it. See also m:Don't delete redirects. Nemo20:33, 12 September 2019 (UTC)
Weak oppose I have seen filemovers wanting to get rid of redirects for the wrong reasons. What comes to mind are the misspelled "Caribean" redirects. I'm also not entirely convinced that file movers need to suppress redirects so frequently that admins can't handle it. Perhaps if I can be convinced this is needed more often and potential damage from the removal of redirects that didn't need removal can be kept under control somehow.. Until then, weak oppose. - Alexis Jazzping plz20:53, 12 September 2019 (UTC)
Alternative proposal: bot to handle round robin moves
A bot could be created to handle the round robin moves. The bot could be set to only respond to requests by specific users or user groups. It should not allow for nonsysop users to perform moves on heavily used or protected images. MorganKevinJ(talk)12:51, 24 September 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Currently, users who are not autopatrolled either use Flickr2Commons or they cause problems when trying to upload by hand. Copy-pasting the wrong source link, accidentally upload thumbnails, directly uploading crops without the originals, things like that. License reviewers are left to clean up the mess. UploadWizard can take care of many of these issues as it automatically inserts the correct information. Similar previous proposals like "Allow all users to use Upload Wizard's flickr option" didn't succeed because at the time there was no server side license check for these uploads. This has been fixed nowadays.
To ease the concern of mass Flickr uploads, the proposal limits users to 4 (four) images each run for Flickr imports. This should be enough to allow a new user to upload a few images they need for an article, which is the primary purpose of this proposal. The maximum number of Flickr imports will be disconnected from the maximum number of files that can be uploaded with UploadWizard. (this is technically feasible) This proposal does not affect anyone who has the autopatrolled flag. Users without autopatrolled flag will be granted the upload_by_url right limited to whitelisted domains (this is required to enable Flickr import) and be given a limit of 4 images each run for Flickr imports. - Alexis Jazzping plz16:36, 16 September 2019 (UTC)
Enable Flickr import (upload_by_url) for all users (four images each run): votes
Support, the democratisation of Wikimedia Commons is here! We should place functionality front and centre and not hide it behind user rights. Someone who mostly edits Wikipedia and finds an amazing photoshoot in a museum on Flickr released with a compatible license who doesn't know that Flickr2Commons exists and doesn't look at Wikimedia Commons beyond the MediaWiki Upload Wizard and the images they published will never upload it. We should work to maximise content creation and the MWUW already knows how to prevent Flickr uploads with incompatible licenses. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:33, 10 June 2019 (UTC)
For Flickr uploads, definitely Support. But upload by url user right can be used import media from sites other than Flickr using Special:Upload. Unless the import URL gets automatically included in the upload summary, or in the file summary, Oppose. Because some inexperienced users claim own work even when they copy a file from other sites and then upload here. It will be very helpful to detect the original source. Masum Reza📞17:34, 16 September 2019 (UTC)
Oppose - I would support if the system could somehow identify what licences are used and what are accepted (basically the same as Flickr2Commons which rejects files that don't have the accepted licence here), I certainly agree in that things should be made easier for people absolutely agree with that but I feel newbs could easily upload any given file from URL regardless of licence ..... which would then mean it's down to us to tag and delete. –Davey2010Talk18:41, 16 September 2019 (UTC)
Support - My bad I assumed the Flickr upload by URL option allowed all files willy nilly ....I didn't realise a restriction to upload non-CC content was placed on it, I now fully support this proposal. –Davey2010Talk21:29, 16 September 2019 (UTC)
Support Uploading a picture from flickr manually isn't easy for everyone (especially for new users). I assume that most users with autopatrol right already know how to manually upload a picture from Flickr, so the tool only makes it easier for them. But when talking about new users willing to upload a picture from Flickr, it isn't just about making their job easier. In addition to what Alexis Jazz mentioned above, I think some new users who aren't familiar with licencing policy might mistakenly upload non-free files from Flickr. About uploading non-free files from url, I think it isn't much of a problem since new users don't use Special:Upload very often; they are much more likely to use upload wizard or perform a cross-wiki upload from their home wiki. Ahmadtalk18:29, 18 September 2019 (UTC)
Support sounds like a good idea. gonna save lots of time fixing all the problems that arise from nonstandard transfers.--Roy17 (talk) 15:51, 19 September 2019 (UTC)
Support Since the feature is whitelisted (and not many people use Flickr anymore anyway) it seems like it shouldn't be a huge risk. If copyvios become a problem we can always go back to having it restricted. Kaldari (talk) 18:36, 20 September 2019 (UTC)
Oppose It is actually easy to upload flickr images which seem free enough, but are not. I unintentionally attempted to upload one of those images to commons, but fortunately that image is not on commons anymore. Sure, there are safeguards for flickr uploads, but they really do not go far enough.--Snaevar (talk) 23:23, 8 October 2019 (UTC)
Enable Flickr import (upload_by_url) for all users: discussion
@Masumrezarock100: see phab:T20112. But upload_by_url doesn't allow anything you can't accomplish by downloading a file and uploading it here. New users are unlikely to use Special:Upload and as the feature is limited to a whitelist anyway, the potential for abuse is quite tiny. - Alexis Jazzping plz18:30, 16 September 2019 (UTC)
Yes but let's assume that a newbie wants to overwrite another file. How they would do? Using Special:Upload, because UploadWizard currently doesn't support overwriting files. Now we know that Flickr hosts non-free(copyrighted) and free files. So if that newbie intentionally or unintentionally copies files direct download URL to the URL field, Special:Upload would accept the file because flickr.com is whitelisted! I understand what you're saying but there is this slight chance of misuse, that's what bugging me. The proposal below should solve the problem, and I suppose UploadWizard can be configured in a way that anyone can use the Flickr upload feature. Until then my vote is Neutral, leaning towards Weak support. Masum Reza📞14:41, 7 October 2019 (UTC)
@Masumrezarock100: Thank you, and yes, that's absolutely right, though overwriting files that are not yours is restricted to autoconfirmed users. Granted, those are still newbies. But also, the scenario you are describing is a direct violation of COM:OVERWRITE and is typically met with revision deletion. I've seen it happen sometimes. Not very frequent, but it happens. Copying the right link from Flickr is not entirely straightforward though (you can't right-click the image), so while there could be some freak occurences, I don't see this becoming a substantial thing. If we saw a large number of newbies performing bad overwrites (regardless of method), it would be more sane to increase the requirements for autoconfirmed. - Alexis Jazzping plz15:02, 7 October 2019 (UTC)
@Davey2010: If I try to upload https://www.flickr.com/photos/normengadiel/10117715954 (all rights reserved) with UploadWizard, I get the error "The file is under the following license on the source site "Flickr": All Rights Reserved. Unfortunately, this wiki does not allow that license.", isn't that what you mean? And to upload from other whitelisted domains one would have to use Special:Upload, the existence of which newbs aren't even aware of. Newbs who upload copyvio download their images from any website (not restricted by the whitelist) and upload them here with UploadWizard or cross-wiki upload. Upload_by_url doesn't assist them with that. - Alexis Jazzping plz19:15, 16 September 2019 (UTC)
Ah thank you Alexis Jazz - I just assumed you could upload via a URL and the system never picked it up, Also I didn't even realise Flickr upload was only available to us, Changed my vote accordingly :), Thanks, –Davey2010Talk
@Alexis Jazz: Right now, users with upload_by_url can import up to 50 images at once via UploadWizard. Users with upload_by_url and mass_upload can import up to 500 images at once. I'm assuming your restriction to 4 images at a time would not affect users with mass_upload. Is that correct? And this would only be in relation to Flickr importing via UploadWizard. Correct? Kaldari (talk) 18:11, 20 September 2019 (UTC)
@Kaldari: All correct. As the proposal also states: "This proposal does not affect anyone who has the autopatrolled flag.", and only users with the autopatrolled flag have mass-upload. By the way, users with upload_by_url but without mass_upload currently don't exist on Commons. In theory a user could have the GWToolset right, but all the users on Commons who do are also autopatrolled. The restriction of 4 images each run only applies to Flickr imports with UploadWizard. Non-Flickr uploads with UploadWizard are not affected and any other upload methods are not affected either. - Alexis Jazzping plz18:29, 20 September 2019 (UTC)
Thank you. To be even more clear for anyone else who might still be confused: the restriction of 4 images each run will only apply to users who currently are unable to use UploadWizard Flickr imports at all. This proposal will not limit anything users currently have. - Alexis Jazzping plz18:42, 20 September 2019 (UTC)
@Snaevar: Which file was that? You don't seem to have any recently deleted files. Perhaps filters/checks can be improved. Things like people not knowing about FoP and the like equally apply to own work uploads. That's not Flickr-specific. - Alexis Jazzping plz23:29, 8 October 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Question What if a global renamer doesn't have autopatrolled permission on Commons? Do you plan to make an exception for them? Masum Reza📞17:36, 16 September 2019 (UTC)
@Perhelion: There are 36 stewards and 68 global renamers. I'm guessing most if not all could be granted autopatrol anyway? Only those who are active on Commons outside of renaming and require patrolling would be an issue. Alternatively I guess you could add move-rootuserpages to another user group (file mover maybe, or an entirely new group) and give stewards and global renamers that. - Alexis Jazzping plz18:17, 16 September 2019 (UTC)
@大诺史: Where does it say that? Anyway, it's stranger than that. Deepfriedokra is blocked here, but that doesn't stop Deepfriedokra from renaming accounts here. - Alexis Jazzping plz03:10, 17 September 2019 (UTC)
Correct. Centralauth would probably freak out if one of the various account pages couldn't be moved during the process. So the global renamer extension overrides local blocks. That way if something like a self requested local block is in effect renames can proceed as normal. --Majora (talk) 03:20, 17 September 2019 (UTC)
Global renamer is a local group on meta. "Global" is a misnomer. Their local edits to meta are autopatrolled. I don't believe that right extends globally. --Majora (talk) 03:28, 17 September 2019 (UTC)
Note that Stewards get autopatrol from the global group (which is truly global unlike "global" renamer). — regards, Revi00:48, 4 October 2019 (UTC)
Global renamers (i.e including stewards) do not have nor use move-rootuserpages permission when renaming users. That ability comes from the extension which already provides many other things like bypassing local blocks, abuse filters as well as non-existent renamer's local account on a particular wiki. – Ammarpad (talk) 06:39, 17 September 2019 (UTC)
So all this filter technique talk here doesn't matter. If the (right) filter is enabled only Global renamers (and users explicitly excluded) can do the action. But your inactive filter was incomplete and could be optimized. – Ammarpad (talk) 23:21, 17 September 2019 (UTC)
Oppose This is a confusing and bureaucratic change based on hypotheticals. Changes of this type, which increase the bureaucratic burden of administering or understanding Commons processes, should only be passed when there is a driving need based on actual cases of disruption or abuse, not theory. --Fæ (talk) 08:59, 17 September 2019 (UTC)
What? The contrary is the case, I've linked an actual example. Why this should not simplify the admin activity? There are already 219 filter on Commons and e.g. on the EnWP over 800, so your arguments seems rather hypotheticals. This filter is already active in some Wikis for this reasons. -- User: Perhelion09:28, 17 September 2019 (UTC)
The link you gave was to a user page without any explanation. The case was a user apparently thinking that moving their user page would somehow rename their account, no harm was done, and the response can be to advise the user on how to request a name change. So far, there have been zero examples of meaningful cases of disruption or abuse that need to make the process of renaming pages on Commons more complex. Putting constraints on page moves for all users does not automatically "simplify the admin activity" as there has been no attempt to assess how much admin burden not restricting page moves creates compares to the burden on all users of making page moves more restricted and therefore increasing this project's bureaucracy.
@Fæ: Can you give any example, anything at all, where it would be valid for a user to move a user page? (other than undoing faulty moves by inexperienced users) - Alexis Jazzping plz17:04, 17 September 2019 (UTC)
Not sure why you are painting this as weird. I have seen admins draft policies and funded collegial project pages drafted in user space, including role accounts. The is no evidence that more restrictions on doing this on "root" pages would reduce this project's maintenance or administrative burden, quite the opposite.
Come on people, this is Commons, called the Wild West by other other projects due to our lack of rules. Do you really want to keep on adding rules and bureaucracy to Commons until us four legs have all the same problems as the two legs? --Fæ (talk) 20:10, 17 September 2019 (UTC)
I don't see why we can not add it as a precautionary measure. Just because no one did doesn't mean no one ever will. There is a say "Precaution is better than cure." Masum Reza📞20:20, 17 September 2019 (UTC)
That is a useful report that appears to show that the systemic change is very much not needed. 2 of the 6 are the case already raised, and the institutional move looks like it may be right. The fact is that "not fixed by anyone" is in truth "nobody cares and it does not affect anyone". The proposed bureaucracy is neither urgent, nor does it fix anything that was causing anyone a headache. --Fæ (talk) 20:51, 17 September 2019 (UTC)
In fact it are much more (e.g User:Jubair Bin Iqbal from yesterday). More examples300 potentially hits (forked query, not all checked).
Based on your query, that's still 6 cases in 30 days as it already included Jubair Bin Iqbal, and I have no idea why you think any of those 6 cases are a cogent argument to make this system wide change for all users. Some of these moves may be mistaken, but they are not damaging the project as far as I can see and have not affected anyone else, or at least you have not linked to cases where anyone cared enough to complain about it. BTW, the institutional page move, Institution:Fravahar Choir, is exactly the sort of thing you might do when drafting a template, so that fits with the 'drafts' question above. Hardly "all are crap". --Fæ (talk) 21:48, 17 September 2019 (UTC)
@"already included Jubair Bin Iqbal" not really, I refreshed the query with raised editcount, so the hit count is raised.
@Hardly "all are crap": Institution:Fravahar Choir is neither an institution in his Commons intention nor a template nor used. Maybe "crap" was too hardly expressed, but using the root userpage as 'drafts' is is certainly not the purpose of it, not to mention to leave redirect to this (and I've also never seen this before). The discussion becomes unnecessarily bloated and too pointless for me. -- User: Perhelion23:11, 17 September 2019 (UTC)
That's still 6 cases in 30 days. At worst there are 300 pages that might be examined as relevant but may be double counting some cases in 5 years, based on your own report. This is a trivial number in comparison to other backlogs and issues that cause real measurable disruption to the project. None of the evidence or cases so far is in any way convincing that time and effort should be spent making a systems change to make special protection and distinctions in user rights for "root" user pages. The principle of sticking to the least bureaucratic systems is one that should be the default for Wikimedia Commons, not one of increasing bureaucracy "as a precaution" for hypothetical issues. --Fæ (talk) 06:27, 18 September 2019 (UTC)
There are proven to be some screwups. On the other hand, I'm not convinced by the actual use case for moving root user pages. For example, if a user were to create a draft on a user root page (did that even ever happen?), by default, when moving that page the checkbox for "Move associated talk page" is enabled by default which is really not desirable. Now, you could maybe create an abuse filter that warns the user that moving a root user page does not accomplish a rename but allows the user to ignore that warning, but still.. Who actually needs this? - Alexis Jazzping plz15:43, 18 September 2019 (UTC)
Question I'm confused by the talk of abuse filters. Isn't this just a matter of flipping some bits in the user group data? – BMacZero (🗩) 06:13, 19 September 2019 (UTC)
Indeed, we could also use a local JavaScript hack to hide only the Move-link at the relevant root-userpages (as the relevant user variables are stored on each page, without need of additional Api request). -- User: Perhelion21:08, 19 September 2019 (UTC)
Okay, I see. I'd Support preferably the config change but alternatively the Abuse Filter. This seems to occur primarily when users think they can use it to change their username or display name, which they can't, so cluing them in to that before they do it is a good thing. I'd Oppose any client-side Javascript for such a low-frequency problem, though. – BMacZero (🗩) 04:01, 20 September 2019 (UTC)
This seems to be an interesting proposal for Mediawiki in general. No one is expected to move their userpages to another root userpage.--Roy17 (talk) 15:51, 19 September 2019 (UTC)
It's indeed a minor issue, but I support this proposal. I moved back several pages where users tried to rename their accounts. A similar case that happened as well (though rarely) is moving a userpage intentionally to a gallery page because an "article" page looks better. That should be prevented, too. --Achim (talk) 16:39, 20 September 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Update: I misinterpreted AKlapper (WMF) when he said agreement was needed as a need for community consensus. Regardless, your input on the task is welcome to help craft the most optimal message.
The dreaded message. Often all that's left after a deletion. It doesn't allow us to verify if a deletion was justified. It doesn't allow us to verify a new upload is a re-upload that could be speedied. It tells re-users nothing when they suddenly find the source for the file they were using deleted, which can also easily break the attribution requirement of Creative Commons if the re-user relied on just a link to the file page.
I created a task on Phabricator, but community consensus is required. So the proposal is:
Include information like source, author and license in the upload comment when using UploadWizard.
For uploads with Special:Upload, the description in the wikitext that's copied to the upload comment may be shortened or moved to increase the odds of the author and source being included. (by default, description comes before author and source, a long description causes author and source to be truncated) The actual wikitext is not affected, only its (truncated) copy in the upload comment.
Cross-wiki upload comments are not affected right now because they only allow "own work", but will be changed in similar ways if/when cross-wiki uploads become more flexible.
Other upload methods (Video2Commons, Flickr2Commons, other upload tools) are not affected. (the developer of those is responsible for the generated upload comment)
It is unclear what is being asked for in this proposal. Could you outline something like a state-machine for how comments would be generated and therefore make it clearer what would be improved and how? Thanks --Fæ (talk) 10:48, 30 September 2019 (UTC)
Looks simples, maybe it can include a bit more intelligent harvesting? No firm feelings about this because I'm unsure how easy it would be to harvest other useful data like whether the source URL is actually readable, or stuff from the EXIF if absent from the Commons info template. --Fæ (talk) 11:55, 30 September 2019 (UTC)
@Fæ: I don't know about checking the source url (might be vulnerable to abuse?), but I'd guess that getting information from the EXIF would be possible. But I'm not a programmer, so I don't quite know how to realize that. I'm sure there are others here who do know. - Alexis Jazzping plz13:17, 30 September 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
DjVu is dead. We should deprecate it for new uploads.
I withdraw the proposal, as it seems to have been premature. More discussion on improving MediaWiki's PDF support is welcome however. Kaldari (talk) 05:17, 9 October 2019 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The DjVu file format has been dying a slow death for many years. The reference implementation for DjVu hasn't been updated since 2015; WinDjView also hasn't been updated since 2015. DjView for Mac hasn't been updated since 2013; The Java DjVu Viewer hasn't been updated since 2005; Internet Archive dropped support for DjVu in 2016 (for new uploads); the main DjVu community website hasn't had a news update since 2013; PlanetDjVu, the main discussion forum for DjVu, was closed in 2014. Wikimedia Commons is the only place left on the internet that still uses it. It's only a matter of time before the basic DjVu software stops working with current operating systems. (It already has problems with newer versions of MacOS.) We should deprecate accepting DjVu files for new uploads, as those files will eventually become unusable and all need to be converted to PDFs (or some other format). Kaldari (talk) 18:23, 7 October 2019 (UTC)
Just to clarify, this proposal is only about deprecating the acceptance of new DjVu files. What to do with the existing DjVu files will have to be dealt with separately. Kaldari (talk) 18:53, 7 October 2019 (UTC)
Sorry for not being clear. I support this proposal about deprecating the acceptance of djvu files. And also converting existing files to PDF sounds like a good plan to me. Masum Reza📞22:11, 7 October 2019 (UTC)
Leaning towards support, but some questions: can DjVu files be converted to another format without serious issues? And are there any possible sources for freely licensed DjVu files around which haven't been imported to Commons yet? - Alexis Jazzping plz19:05, 7 October 2019 (UTC)
An alternative proposal, why not have a bot to automatically tag and/or convert any newly uploaded file to .pdf? It is not necessarily ideal, but we should not discourage new users from uploading files by letting the MediaWiki Upload Wizard deny their uploads of free works. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:17, 7 October 2019 (UTC)
Both Hathitrust and IA allow downloading as PDF. In fact, Hathitrust doesn't even offer a DjVu download option, so I'm not sure how that file ended up as a DjVu unless it was converted from PDF to DjVu by the uploader. I'll ask the folks at IA about the quality of their PDFs vs DjVu files and try to find out why the PDF files are so much smaller. Kaldari (talk) 22:52, 7 October 2019 (UTC)
For equal quality, DjVu is generally going to be smaller due to more advanced (and complicated) format features and compression algorithms. For files found in the wild, PDF files are going to tend to be smaller because they are almost universally of lower quality. Once you need to doctor the text layer of the file (because the original OCR was missing or broken; or MediaWiki chokes on it, as it tends to do, since that bug too sits untouched in Phabricator), the almost universal answer (mostly due to Google's truly craptacular job scanning works) is that PDF files are useless. In every single case I've actually ran into, I've had to go back to original .jp2 images and do the OCR on them to get reasonable results. At which point it is much much easier to generate a new DjVu file then try to fix the PDF. Better tools for working with PDFs would alleviate this some, but I suspect limitations of the format would still apply. DjVu files, on the other hand, can be readily doctored and in practice, in my experience, tends to produce OCR-able extracted page images when needed (unless they've been artificially capped to get around the 100MB upload limit here or similar). --Xover (talk) 09:22, 8 October 2019 (UTC)
@Kaldari: As for " I'm not sure how that file ended up as a DjVu unless it was converted from PDF to DjVu by the uploader" ... yes, that is right: I have uploaded that file from Hathitrust and converted it to DJVU, because Phabricator is not willing or able to fix the broken OCR tool and so I have to rely on the original OCR layer, but MediaWiki is not able to extract it properly from PDFs, while after conversion to DJVU the results are amazingly better. --Jan Kameníček (talk) 19:00, 8 October 2019 (UTC)
Oppose DjVu files work better than PDF on Wikisource, due to reasons of the Wikimedia software that are largely out of our control. That is why people are still uploading DjVu files, including converting them from PDFs.--
OpposeHold the phone! DjVu has features of the format that do not exist in PDF (not even PDF/A, so far as I know). The tooling for working with DjVu files has functionality that I have yet to find in tooling for PDF files (and, btw, I'm not sure what Kaldari was smoking when claiming DjVuLibre hadn't been updated since 2015 while linking to a thread discussing using a 2017 release, and which also, by the way, suggests the problem discussed is most likely an OS bug affecting more than just DjVu. Did I mention the WMF has open bugs in MediaWiki core that dates back to 2005? I guess it's time we migrate away from it. I hear Atlassian has nice tools for a small fee. Or there's always SharePoint. What do you say?). And that's just the off-the-shelf tooling, in addition to which is the investment in custom tools that the community has made (since we can't get the WMF to assign any resources to Wikisource). And it really doesn't help that MediaWiki botches even the format features that are actually available in PDF resulting in crappy OCR text layer extraction (which is probably at least partially fixable if the WMF would actually assign some resources to…). For the Wikisources, PDF is a second-rate alternative you use in a pinch and definitely not the preferred choice.In order to migrate to PDF we would need to resolve all these issues first. At which point, the effort required to find and fix the relevant bugs (if there are any) in DjVuLibre is probably far less. Given we have extremely simple fixes (two-line diff to PHP code) sitting untouched in Phabricator for DjVu text extraction, the probability of getting the PDF support fixed seems pretty much nil; and that's the small and easy first step.While, yes, there is a concern regarding the DjVu ecosystem and risks that the tools will stagnate and bitrot eventually, there is currently no credible alternative for our purposes. I suggest energies are directed towards finding better solutions that people will want to migrate to, rather than trying to outlaw "stuff I don't like". Because it's currently enough of a hassle to keep our media on Commons given various impedances (policy, purpose, culture, etc.) and deprecating our primary and preferred format will affect that calculus significantly.PS. @Kaldari: Since I happen to know that you're aware of Wikisource's existence, I've got to say making this proposal here without notifying the projects most affected by it is a bit of a crap move. Thank you to Donald Trung for taking the time to notify English Wikisource; and now we've got to go notify the remaining 70 language-specific Wikisources that will to various degrees be affected by this. --Xover (talk) 09:07, 8 October 2019 (UTC)
@Xover: I would be very happy if I was wrong, but I can't find any version of DjVuLibre newer than 2015. There are some bundles with newer versions of DjView, but I don't see any newer versions of DjVuLibre. Where is this 2017 version you speak of? Kaldari (talk) 17:44, 8 October 2019 (UTC)
@Kaldari: I didn't do too much digging, so I won't venture into distinctions on what exactly constitutes a "new version" of what, but in one of the bug threads you linked above, from 2017, they referred to a then-new version and compared results with the 2015 version. I didn't check whether that was of the library or the viewer (or a bundle). In any case, the last commit to DjVuLibre's Git repo was on September 10, 2019. And I'll note that DjView 4.10 works just fine on my macOS 10.14.6; as do whatever the Homebrew version of the command line tools is (different box, can't check just now). --Xover (talk) 18:01, 8 October 2019 (UTC)
@Xover: I was trying to use DjView 4.9 which won't even launch in High Sierra (which is a 2 year old operating system). 4.9 is the most recent binary release but I guess I can try building 4.10 myself. Kaldari (talk) 18:54, 8 October 2019 (UTC)
Oppose Really premature proposal. Although generally I agree that DJVU is dead and libraries also switched to PDF, Wikimedia software for some reason prefers DJVUs which work better at Wikisources than PDFs. What is more, Wikimedia programmers are also not very accustomed to PDFs as well: when the last technical problem with PDFs appeared (in June 2018), it took many months before they were able to solve it (in February 1919) – if there were no DJVUs, Wikisources would be paralyzed. For these reasons I oppose the proposal until Wikimedia environment gets friendlier to PDFs. --Jan Kameníček (talk) 11:35, 8 October 2019 (UTC)
Oppose As said above, there is a lot of technical work to be done before PDF can fully replace DJVU, especially on Wikisource. I'd be open to deprecating DJVU when PDF becomes a viable alternative, but that is still a long way off. -- Beleg Tâl (talk) 12:19, 8 October 2019 (UTC)
Oppose Spent an inordinate amount of time trying to work with PDF files from Internet Archive and they are terrible!!!
Most if not all were donated by Google and the quality is very poor.
Google removes photos. When they do include it it's impossible to clean and resize.
As stated above, .Djvu is much cleaner to read and the images are superior. Please see my upload contributions.
Oppose Depreciate, maybe. An removal of an file format needs to be considered with the sister projects in mind. In this case wikisource uses djvu files extensively. Sure, Internet Archive does not make OCR DjVu files, but there are extensions for Tesseract, namely gscan and ocrdjvu who have both been updated in this year (2019) and through them Wikisource editors still can make OCR DjVu files. On wikisource the support for djvu for readers is irrelevant, because that is not the end result of the work at wikisource. Instead the books are shown with on-wiki with the option to make epub, pdf and mobi files through wsexport.--Snaevar (talk) 22:52, 8 October 2019 (UTC)
DjVu is dead. We should deprecate it for new uploads. (Discussion)
Comment DjVu is dead? Is it really? Arguments pointed by Kaldari are a bit general and can partly apply to other formats (for instance SVG 2.0 has a complicated history since 2013) or untrue (other places still use DjVu, a lot of digital libraries still provide it, even if IA stop generated them in 2016) and to be honest, it has never really been alive, since the beginnings it's a niche format. My main question is: how alive is DjVu in the Wikimedia ecosystem? For instance, can we have the number of uploads per year/month on Commons? (can it be done with quarry?) and what do the Wikisourcerors think? (as we/they are the only users of DjVu) If we deprecate the format, will the Wikisourcerors just upload them locally on their Wikisources instead of Commons (which will only create more problems). Then, and only then, there is all the technical details. Cheers, VIGNERON (talk) 08:57, 8 October 2019 (UTC)
Keep DjVu files are used by the Wikisources, and are within scope. Commons is not here to determine what the other sites should use, it is here to host the files for the sisters that are within scope. — billinghurstsDrewth09:56, 8 October 2019 (UTC)
As a serious comment, what is missing from this proposal is any actual reason to deprecate a format that is used, and fully supported. Jarnsax (talk) 14:50, 8 October 2019 (UTC)
@Jarnsax: The reason, as I mentioned, is lack of good software support for viewing, creating, and editing DjVu files locally. The small amount of software that does exist is no longer being supported or updated, so it is becoming increasingly hard to actually work with DjVu files (unless you just stop updating your operating system). This problem is only going to get worse. GIFs are another story as they are widely supported by hundreds of programs on all platforms. Kaldari (talk) 15:50, 8 October 2019 (UTC)
@Kaldari: So your answer is to break Wikisource? Your proposal is to remove existing, working functionality, with no actual working replacement, on the theory that what actually works now might break someday in the future. The sensible answer would simply be to not break things... go actually do the work to duplicate the existing 200,000-odd existing files as PDFs (if you think the lack of them as PDFs is a problem), do the work to actually make PDFs work properly here and on Wikisource, then start automatically converting uploaded DJVU files to PDFs, and deprecate them if or when they actually break. Note that PDF/A is currently explicitly broken. Jarnsax (talk) 17:44, 8 October 2019 (UTC)
Then your operating system sucks. If it works today with Windows, Microsoft has basically pledged to support it indefinitely, to make Windows 10 the final version of Windows. Linux doesn't gratuitously break old software either. I don't really see a day when DjVuLibre stops running on those systems.--Prosfilaes (talk) 01:28, 9 October 2019 (UTC)
Improving MediaWiki's PDF support
From the feedback above, it sounds like better PDF support in MediaWiki would be a pre-requisite to ever deprecating DjVu support. Can you provide a rough idea of which issues with PDF support should be the highest priority? Maybe we can put together a wishlist proposal for this year's Community Wishlist (which is specifically limited to non-Wikipedia projects). Even if we never deprecate DjVu, we still have to face the fact that software support for it is slowly dying and we're going to need alternatives in the future. Kaldari (talk) 17:33, 8 October 2019 (UTC)
Highest priority should be fixing extraction of an existing OCR text layer from PDF files. Currently there is something in how that's done that produces markedly poorer results than opening the PDF in Acrobat and copying the text out (there are some tests on enWS from earlier this year, but I don't have the link handy). This is where MediaWiki actually falls down regarding PDF. Second priority would be fixing PDF/A support (phab:T188885) because this is what several archives and repositories use. Plus the issues Beleg Tâl brings up above.But the biggest hurdles aren't in MediaWiki. I've yet to find a toolset for PDF that comes anywhere near what DjVuLibre provides for DjVu files. I can construct and manipulate DjVu file programatically to my heart's content, including creating them from page scan images including structurally tagged OCR text; inserting, reordering, or removing pages; redacting whole or partial pages; combine multiple DjVu files; etc. In fact, I'm currently investigating setting up something toolserver-y that others can use based on my local hacky scripts; most critically to provide ad hoc per-page OCR since the current best tool is down (T228594), but also, hopefully, to interactively manipulate DjVu files (inserting or removing missing or duplicated page scans is a common need (see Google's utter lack of care when scanning)).I would also be significantly concerned about format features. DjVu was designed specifically for our use case, so it provides separation of background (the empty space of a page) and foreground (the text) into separate layers, structured storage of annotations and hidden text layers (see e.g. djvused), and a wavelet-based compression system that gives you both good compression, high performance, and a reasonable lossy—lossless compromise (I'd say, informally, we're in JPEG territory for visible artifacts; but much much better on recompression, which is some times needed). PDF is oriented solidly towards print production (it's based on PostScript, after all) and so it is clearly superior for born digital works (it can reproduce a lot of the features of word processing and typesetting software), but suffers from significant impedance mismatch for representing the scanned print works that are our bread and butter on Wikisource. Without a deep-dive I won't go so far as to claim the format is inherently harder to work with for our purposes, but anyone that's ever tried editing PostScript by hand will at least admit it is a valid thing to be worried about. And my search for existing tools to work with PDF in the same way DjVuLibre provides for DjVu files only tends to reinforce that impression. I hold it entirely possible that PDF as a format will always be inferior to DjVu (though good tooling can compensate for that).And just to be clear, I share your concern about the software ecosystem for DjVu. For the long term this is a problem, and long term it may necessitate migrating away from DjVu. But as of right now the DjVu tools exist, work well, do not appear in imminent danger of stopping working (there are 64bit binaries available, for example), and there are no credible alternative formats. --Xover (talk) 19:29, 8 October 2019 (UTC)
Thanks for all that info. Also, as Slowking4 mentioned on Wikisource, we would want to make IA Uploader produce PDFs before we ever deprecated DjVu. Kaldari (talk) 15:30, 9 October 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
This section was archived on a request by: While not actually resolved (it won't be anytime soon), this discussion doesn't really have to linger on VPP anymore. The work shall continue on Phabricator, for further discussion COM:VPT is a better place. - Alexis Jazzping plz08:19, 24 October 2019 (UTC)
Offer a method to view and edit MIDI files online
The MIDI Files category only has 946 files. Most of them are more than 10 years old, and many of them only have a few seconds of audio.
One reason for the low participation in this category is that there was previously no method to view and edit a MIDI file online; you had to download a program.
The first Online Midi Editor was created two years ago, and it was recently moved to a new domain:
https://OnlineMidi.com
I would like to request permission to create a page in Commons which describes OnlineMidi.com, since it is the only Online Midi Editor on the entire web. I noticed that the VicuñaUploader received its own page in Commons, and a special mention on the Commons 'Welcome' page (under 'Additional services and software').
I would also like to propose adding a link to each midi file's thumbnail and profile, which will import and display that midi file at OnlineMidi.com. For example, the following link displays the midi file for "Giant Steps" by John Coltrane:
https://OnlineMidi.com?s=aNVf
This will be very simple to implement. The link from WP to OnlineMidi.com will include a 'wp_url' parameter, which will allow OnlineMidi.com to import and display that midi file. — Preceding unsigned comment added by ToolCreator (talk • contribs) 8 October 2019 21:00 (UTC)
I personally have no issue with a page that describes how to use onlinemidi.com, as long as it's educational. If there are people who would find this useful, a gadget could probably be created to link to onlinemidi.com with a file from Commons loaded. There are 5,645 MIDI files on Commons by the way.- Alexis Jazzping plz01:10, 9 October 2019 (UTC)
I feel the same way as Alex. But that website literally doesn't have any API or anything of the sort. At least I couldn't find any similar features either. It doesn't even support upload by URL, meaning files have to be uploaded by a user's device. So creating a gadget might be a difficult task. Masum Reza📞01:38, 9 October 2019 (UTC)
This URL (https://commons.wikimedia.org/wiki/Category:MIDI_files) displays "The following 200 files are in this category, out of 946 total."
Please indicate why this count differs with your search, which showed "5,645 MIDI files on Commons".
@ToolCreator: Because not all MIDI files are in that category. For example, Category:MIDI files of music by Johann Sebastian Bach has 78 files in it. (and its subcategories another 21) Citations are no issue. We'd mostly be concerned about whether or not something is in scope. A general page about MIDI would be better suited for Wikipedia or Wikibooks. For general instructions for a universally known tool like Photoshop, Wikibooks is probably best. Of course, it should be relevant for Commons. For example, the checklist on COM:Colorization is relevant. And finally it shouldn't be spammy. Considering onlinemidi.com appears to be ad-free and not selling subscriptions, I'd say that's fine. - Alexis Jazzping plz03:16, 9 October 2019 (UTC)
@Alexis Jazz: The example I described will be shown here tomorrow (which will import and display the midi file when the upload.wikimedia.org URL is sent as a GET parameter to OnlineMidi.com). How long will it take for an [Edit MIDI] link to be added to each midi file's thumbnail and profile at Commons? ToolCreator (talk) 03:27, 9 October 2019 (UTC)
@ToolCreator: No links will be added directly to files. A gadget could be made for this (not by me, I lack the knowledge) which could be enabled by users who want it. It shouldn't be too hard though because we already have gadgets for Google Images and Tineye which do the same kind of thing. - Alexis Jazzping plz03:39, 9 October 2019 (UTC)
I've created a pretty basic version of the gadget based on the TinEye gadget. But it is for some reason, loading on image file pages instead of mid file pages. It is located here. I can't seem to figure out where I made a mistake. We'll need to work on it more. @Perhelion: perhaps you can lend me a hand? Masum Reza📞06:01, 10 October 2019 (UTC)
/* OnlineMidi gadget code start.Depends on mediawiki.util. */$.when(mw.loader.using('mediawiki.util'),$.ready).then(function(){'use strict';if(mw.config.get('wgNamespaceNumber')==6&&mw.config.get('wgAction')==="view"&&document.getElementById('file')){varmid=document.getElementsByClassName('fullMedia')[0].getElementsByTagName('a');varmidURL=mid[0].href;//Conditionally add the portlet linkif(midURL.substr(midURL.length-4,midURL.length).toLowerCase()=='.mid'){mw.util.addPortletLink('p-cactions','https://www.onlinemidi.com/Editor.php?wp='+encodeURIComponent(midURL),'Edit MIDI','ca-midiedit',null).children[0].target='_blank';}}});
I needed to change the element to source/construct the actual media url from, and added a condition. It should only activate if the extension is .mid. I tested the generated url at onlinemidi for a couple and it seems to work. You might need to tinker with the condition if you need to allow for any different extension, but that should be easy enough to do... --Begoon09:39, 10 October 2019 (UTC)
@Masumrezarock100: @Alexis Jazz: Thank you for your efforts. I think everyone will want to view the midi notes, so I hope you can make this gadget run by default. Otherwise, very few people will know that this feature exists.
Also, please mention Commons:OnlineMidi.com on the Commons Home or Welcome page. I noticed that VicuñaUploader received a special mention on the Commons 'Welcome' page (under 'Additional services and software'), so I hope that OnlineMidi has the same relevancy. If more people knew about the capabilities of MIDI files (as demonstrated by the Sample Midi Files listed at Commons:OnlineMidi.com), then you would receive more new submissions.
It should say "This page does not currently exist. You can search for this page title in other pages or create this page." and the words "create this page" are a link, which you can click to create the page. --Begoon15:16, 10 October 2019 (UTC)
Yes, create the page with the code I posted. Navigate to a mid file, and click the more collapsible drop-down. And you should see a Edit MIDI link. Masum Reza📞15:20, 10 October 2019 (UTC)
@Masumrezarock100: You may not want the link to appear on the mobile website, because the midi editor requires more screen space than most mobile devices can handle.
Ah, I didn't think about that. It makes sense to me. We can change it's definitions so that it won't load on the mobile. However, I suggest the Minerva skin part to be kept, since there are some users who use Minerva skin on desktop site. On English Wikipedia, a discussion usually takes place for minimum 7 days. You can assume the same for Commons. All gadgets on Wikimedia Commons are listed at Special:Gadgets. -Masum Reza📞17:16, 10 October 2019 (UTC)
Alphabetical order. Unless I am mistaken, there is no way to sort out files in a category at the moment. Perhaps a gadget could be created to support changing sort order. Masum Reza📞16:09, 10 October 2019 (UTC)
I do not endorse making special mentions and/or creating a default gadget to a proprietary tool that does not even have a privacy policy. If one uses this tool to edit MIDI, then it is their own choice. --Zhuyifei1999 (talk) 17:21, 10 October 2019 (UTC)
"Proprietary": Release your source code under FOSS license
"Privacy Policy": List clearly what data you will collect from end users, and explain what you will do with the data, and under what circumstances will you release the data to third parties. See foundation:Privacy_policy for an example.
Privacy Policy for OnlineMidi.com:
No information whatsoever is collected from users of the Site without their permission. No information is sent to the server while the user is using the Site, other than the HTTP parameters that are sent to all websites (IP Address, Browser Type, and Referrer). Those parameters shall never be released to any other entities. If a User chooses to Register (which is not required), the information they submit (Email, Username, Password, and URL) shall never be released to any other entities.
Cookie Usage: Cookies are only used when the [Remember me] box is checked when a registered user logs in. The Site does not use Cookies for any other purpose whatsoever.
Regarding the Proprietary nature of the website: The Midi Editor and Player are entirely run from the browser, using client-side javascript. There is no server-side processing whatsoever. Anyone can click 'view source' in their browser to see all the code that the website uses.
After reviewing the gadgets that have been "Enabled for everyone by default", it appears that this proposed gadget meets the same standards as those gadgets. If that is not the case, then please indicate any other changes that I should make. ToolCreator (talk) 18:41, 10 October 2019 (UTC)
By under 'FOSS' I mean 'free and open source software', free as in libre, free as in free speech, not free beer. We need the right to run your code for any purpose, study your code, modify, fork, redistribute, for any purpose, including commercial, without restrictions. Your 'Copyrights' section clearly differs. --Zhuyifei1999 (talk) 19:02, 10 October 2019 (UTC)
The All content included on the Site, such as text, graphics, logos, button icons, images, audio clips, digital downloads, data compilations, and software, is the property of OnlineMidi.com or its content suppliers and protected by United States and international copyright laws. The compilation of all content on the Site is the exclusive property of OnlineMidi.com and protected by U.S. and international copyright laws. No part of this program may be copied, reproduced, translated, or reduced to any electronic or machine readable form without the prior written consent of OnlineMidi.com.
Am I understanding it correctly that all media files taken from the website are copyrignted including the mid files uploaded to the the website after an user edits them? So let's say a user uploads a file to OnlineMidi, and then edits it using the website. Who is the copyrignt holder of the new (edited) file and what it is new license? We have a goal to provide free educational files. Does this website meets our licensing requirements? 19:12, 10 October 2019 (UTC)
@Zhuyifei1999: As per your suggestion, I changed the Terms of Use for OnlineMidi.com to clarify that the user's data "...shall never be released to any other entities (unless legally ordered to do so)".
Regarding the justifiable concern that uploaded midi files would become the ownership of the site, I have added the following sentence to that paragraph: "This copyright does NOT include data that is created or uploaded by a user.".
There are other gadgets that have been "Enabled for everyone by default" which do not allow others to "redistribute, for any purpose, including commercial, without restrictions.", so that is apparently not a requirement. ToolCreator (talk) 19:31, 10 October 2019 (UTC)
@ToolCreator: I'm not a lawyer, but here's a suggestion:
This service embeds content from Soundcloud.com which may use cookies and collect the data from your HTTP-request. Please refer to the Soundcloud privacy policy for details. OnlineMidi.com may log the information that results from requests (like HTTP-requests) to the service like IP address, user agent and referrer. This information may be used to generate statistics and detect abuse of the service. OnlineMidi.com only uses functional cookies. When the user registers an account, their information like e-mail address, username, password hash and any other entered information will be stored by OnlineMidi.com. None of the aforementioned information that is collected by OnlineMidi.com will be shared with third parties unless required by law.
Again, I'm not a lawyer, but this is probably more likely to be legally sound than the current text. Also, make sure you actually are storing password hashes and not passwords like your policy currently states.. - Alexis Jazzping plz11:27, 13 October 2019 (UTC)
Revised Privacy Policy for OnlineMidi.com:
This service embeds content from Soundcloud.com which may use cookies and collect the data from your HTTP-request. Please refer to the Soundcloud privacy policy for details. OnlineMidi.com may log the information that results from requests (like HTTP-requests) to the service like IP address, user agent and referrer. This information may be used to generate statistics and detect abuse of the service. OnlineMidi.com only uses functional cookies. When the user registers an account, their information like e-mail address, username, password hash and any other entered information will be stored by OnlineMidi.com. None of the aforementioned information that is collected by OnlineMidi.com will be shared with third parties unless required by law.ToolCreator (talk) 12:54, 13 October 2019 (UTC)
@ToolCreator: The help page of OnlineMidi on Wikimedia Commons contains 99% of copied words (according to copyvio detector tool). Your website states that even texts are copyrignted. Please license it to us and update your Copyrignt policy, or rewrite the whole help page on Commons using your own words. Pages with excessive copyrighted are subject for speedy deletion per G11 criteria. Thanks you for your understanding. Masum Reza📞21:31, 10 October 2019 (UTC)
So here's the thing, Wikimedia Foundation provides free access to open knowledge and allows anyone to use it's content. As you might have noticed, the footer of every pages has the following text.
Files are available under licenses specified on their description page. All structured data from the file and property namespaces is available under the Creative Commons CC0 License; all unstructured text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply.
As Wikimedia Commons is one of Wikimedia Foundation's projects, anyone can copy, modify, and distribute its content (which are hosted on this site), or use it for any other purposes (even for commercial purposes), provided he/she abides by the terms of licensing. You gave only Wikipedia and Commons to use your website's content. So if I were to copy/use the texts from the OnlineMidi page on Wikimedia Commons, it would be a copyrignt violation, because I don't have permission! You see what I mean? Unfortunately Wikimedia projects can not host such content. Please update your Copyrignt policies and license it under one of the free licenses. Masum Reza📞22:19, 10 October 2019 (UTC)
The wording depends on what license you choose. It is generally recommended to license it under one of the Creative Commons licenses. There are plenty of CC license tags that you can use. See Category:CC_license_tags. Masum Reza📞22:53, 10 October 2019 (UTC)
@Masumrezarock100: If I place the following statement in the Terms of Use, will that suffice:
Ah, drop the non-commercial part. Commons doesn't allow Non-commercial and non-derivative works licenses. Also why only freely license the help page? It doesn't hurt to license all texts of the website under a free license. Those are just simple texts nothing special. Masum Reza📞23:26, 10 October 2019 (UTC)
@Masumrezarock100: The https://creativecommons.org/licenses/ website says "This is the license used by Wikipedia", so I assume this will work. Do I have to do anything other than adding this sentence to my Terms of Use webpage?
It doesn't explicitly states what license Wikimedia Commons uses. Per COM:L, ND and NC licenses are not acceptable on Commons.
Do readers a favor and clearly state how text portion in the help page can be used and what is it's copyrignt status. Just simply linking to a CC license page doesn't help. See Template:CC-by-sa-4.0 for an example. Masum Reza📞00:04, 11 October 2019 (UTC)
@Masumrezarock100: I added the text from the template that you suggested, to the Terms of Use for OnlineMidi.com. Please see paragraph 8 in that document.
I also added the following statement to Commons:OnlineMidi.com: "This page contains text from the OnlineMidi.com Help Page, which is licensed under the Creative Commons Attribution-ShareAlike CC BY-SA License."
@Zhuyifei1999: The gadget itself will be 'free and open source software', as are all the javascript gadgets on the Special:Gadgets page. Each gadget is simply a javascript snippet that is free for anyone to use; that is a condition for the gadget to be placed on the Special:Gadgets page.
However, the websites, software, and data that the gadgets access are obviously not all 'free and open source software'. For example, if a gadget launches a PDF file, that doesn't mean that everyone can "redistribute, for any purpose, including commercial, without restrictions" all of Adobe's software.
Here are two examples of gadgets that are "Enabled for everyone by default" that access software and/or data that is not "FOSS":
2. https://meta.wikimedia.org/wiki/WikiMiniAtlas
"additional data courtesy of the US National Park Service, Landsat7 data courtesy of NASA."
The US National Park Service and NASA do not allow others to "redistribute, for any purpose, including commercial, without restrictions" all of their data and software.
The proposed gadget will be FOSS: the javascript code will be FOSS. The site that it accesses (OnlineMidi.com) has the Terms of Use for OnlineMidi.com.
You will be tremendously limiting the capabilities of gadgets if you do not allow them to access websites, software, and data that are not FOSS. ToolCreator (talk) 22:02, 10 October 2019 (UTC)
Stock photo does not explicitly launch any proprietary software. Some of us use FOSS email clients, such as Thunderbird to handle emails. If a client binds mailto: to Gmail or Outlook, then they are expected to be fully aware that they are using such service. Again, we don't endorse proprietary software; if you use them as your email client it is your choosing.
Since when has NASA claimed copyright? Maybe 'some' of their data and software, but the data being displayed is libre.
You claim that "the javascript code will be FOSS"; if you mean that the gadget itself is FOSS, yes; however, setting it as a default gadget imply that we endorse your site. No, we don't endorse any specific proprietary software. --Zhuyifei1999 (talk) 22:45, 10 October 2019 (UTC)
I don't see any benefit in making this gadget default. If someone wants to use this gadget to edit MID files they should enable it by themselves. It would be just advertising your site if we make it default. Masum Reza📞20:40, 11 October 2019 (UTC)
1. Can I use the midi player that is on your site to hear what a file will sound like before I upload it?
2. After I upload a file, can I delete or replace it?ToolCreator (talk) 17:43, 11 October 2019 (UTC)
The MIDI -> waveform conversion is done by one of the two extensions: mw:Extension:TimedMediaHandler & mw:Extension:Score. I think you can either host a MediaWiki install yourself with these exiensions, and you can refer to our onfigueration. Another way would be that you can try to figure out what commands these extensions use to do the conversion by reading its source code.
You will see that this midi file includes audio for live drums, guitars, and female vocals. There is no other website that does this.
I noticed that nearly every midi file in your directory contains just a few notes (and usually only one instrument), which causes them to normally receive less than 5 page views in the past 30 days.
Many musicians would like to include your fantastic collection of audio files within their midi files, but if they don't know about OnlineMidi, then they won't know that they have that capability. I am friends with several film composers who would not use the OnlineMidi gadget unless it was a default gadget.
Your team has been fantastic in patiently guiding me through the WikiMedia process (which I am obviously new at). I sincerely believe that if this gadget is made to run by default, it will increase the quality of midi files in your directory. If it is not a default gadget, then very few people will know it exists. ToolCreator (talk) 01:43, 12 October 2019 (UTC)
Obviously, galleries would only be visible on the DR page like Commons:Deletion requests/File:Example.jpg. They would not be included on overview pages like Commons:Deletion_requests/2019/09/30.
Weak support, I like the idea, but as a mobile user this will mean minutes of scrolling per large deletion request. And some random IP that spots potential child pornography would probably nominate it for deletion because they don't know that speedy deletions exist, but I don't think (hope!!!) that much child pornography gets uploaded to Wikimedia Commons anyhow. There should be a way to (temporarily) disable these galleries for mobile users until we can collapse templates. This is also the only time when less functionality might actually benefit mobile users. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 13:22, 10 October 2019 (UTC)
Yes plz. Long overdue. I always copy a long list into regexr.com, trunc the brackets, put it into a page and preview. This should be done by the suggested template or a gadget/script at least.--Roy17 (talk) 21:28, 10 October 2019 (UTC)
For many DRs, that would be helpful. If there are say 200 images, I'm less sure about that. And sometimes people mark comments on the end of the filename line, which you can't do in a gallery. But I guess you could do the same in that collapsed section. Carl Lindberg (talk) 23:18, 9 October 2019 (UTC)
@Clindberg: I've now limited the template to 80 files+comments total by default. (funny thing: there is no way to tell how many files there are, only the total of files and comments is known) This means that by default, you'll see somewhere between 40 and 80 files. (depending on how many have comments) Also, the thumbnails over 40 are hidden by default under a "Show more thumbnails" link. So by default, you'll see between 20 and 40 thumbnails and another 20 to 40 hidden under that "Show more thumbnails" link. - Alexis Jazzping plz19:13, 16 October 2019 (UTC)
@Donald Trung: Such uploads are rare as far as I know. I encountered it once (and reported it, it was only nudity IIRC, no interaction, though I didn't check the other uploads from the user), back when I was a newbie. I actually think it wouldn't have shocked me as much if I had only seen a gallery thumbnail. The gallery can be removed by editing the wikitext in individual cases anyway. (just remove "mode=gallery") It's possible to collapse the gallery, and this could be enabled/disabled with a gadget. I don't know if it is possible to make a template always behave differently on mobile. It would make sense to further restrict the maximum number of thumbnails on mobile. @Perhelion: do you know if that's possible, making mobile-specific tweaks? - Alexis Jazzping plz15:31, 10 October 2019 (UTC)
Some clarification, the main reason for adding "weak" to my support vote is actually not related to child pornography which is extremely rare on Wikimedia Commons (things like "the black web" or "deepweb" serve things like this), and Wikimedia Commons' new page patrollers (the general grouping of people, not just people with the user right) and the Wikimedia Foundation (WMF) actually handle it really well. I really like this idea as it will allow for people to make better decisions without opening lots of tabs. With "COM:SCOPE"-based deletion requests I expect this to be very helpful.
I actually only think that this might be bad when using the mobile browser view for "large" deletion requests, maybe we could make something like "<nomobile></nomobile>" that doesn't display when someone has the "Mobile view" enabled. But again, 99% (ninety-nine percent) of the time this gallery won't be a disadvantage, only with deletion requests that concern more than like 50 (fifty) or so files. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 17:51, 10 October 2019 (UTC)
@Donald Trung: Yes, I will be adding some limits. For mobile, I think there probably is a CSS class that would display:none on mobile but be ignored otherwise. I just don't know what the name of that class might be. If it doesn't exist, we could probably add it. This maybe won't stop the extra thumbnails from being downloaded (depending on your browser maybe), but they won't be displayed. - Alexis Jazzping plz14:34, 11 October 2019 (UTC)
@Donald Trung: if you add ".delreqgalover25, .delreqgalover50, .delreqgalover100, .delreqgalover200 { display: none !important }" to User:Donald Trung/common.css you'll never see more than 25 thumbnails. And with ".delreqgalunder25, .delreqgalover25, .delreqgalover50, .delreqgalover100, .delreqgalover200 { display: none !important }" you would see no thumbnails. This could be made into gadgets or default for mobile. - Alexis Jazzping plz07:27, 16 October 2019 (UTC)
Undo feature in mobile website (Minerva skin) is a long sought feature. But it is possible to undo a diff using mobile website manually. Reading web team is currently working on Advanced mobile contributions project. They have added a undo button to history pages. But a undo button on diff pages is still missing. This task has been tracked in phab:T191706 but Reading web team isn't working on it despite it had been triaged as high priority. It is clear that there is a demand for this feature, see some related discussions on Mediawiki - mw:Topic:V8wxfm4a02x9glpw, mw:Topic:V77gwos6xmvslqz2, mw:Topic:V484smre28nqxvdh. In the meantime, FR30799386 has developed an user script to replicate this feature. There are many mobile contributors, but only a handful of them know about this script. Because of that many editors can not undo edits on mobile. We would like to implement this user script as a gadget. But I thought we should gain support from the community, and which is why I am proposing to make this script a gadget. Jon Robson also proposed the same thing on English wikipedia. All mobile users especially those who are active in countering vandalism and use mobile, will benefit from this. It works cross-wiki and also supports internationalization meaning it can be translated to one's preferred language. Thanks. Masum Reza📞01:58, 11 October 2019 (UTC)
Support, though I am certain that it will become the rule once "the Advanced Mobile Mode" will become the standard mobile mode, in fact I can't wait for the featureless Mobile mode to be completely abolished. Why is a dumbed down version of the MediaWiki software somehow "friendlier" for mobile users? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 05:48, 11 October 2019 (UTC)
Question, I have a question, shouldn't this request better be filed in the Phabricator? As far as I can tell this is an uncontroversial change. There is no policy and/or guideline stating that mobile users shouldn't be able to undo edits using the "mobile view", in fact this is a mere technical restriction. Yes, it is still a proposal, but it's not like if someone would enable it today that it would be seen as controversial in any way. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:27, 11 October 2019 (UTC)
We don't have plans to make advanced mode default for everyone. But we'll transfer some of its features to all logged in users. Masum Reza📞15:43, 11 October 2019 (UTC)
I Genuinely can't see the logic behind this, most users start editing Wikimedia projects / websites usually after first making edits without registering a Wikimedia SUL account, if we hide user-friendly features from novice users then they are less likely to become editors who could have been major editors to this (and other Wikimedia) website(s). I do not see how it serves anyone to give them "a dumbed down experience", especially for new markets like India where desktop users will be rarer. This policy is almost certainly one that will be a disadvantage for users from developing countries. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:14, 11 October 2019 (UTC)
I understand what you are saying but some editors prefer the old version mostly because of its simplicity. And some old mobile browsers don't even support JavaScript. There was 81% retention rate when AMC first had been deployed to 7 Wikipedias. This means that some still use the non-AMC mode. And 19% is still a big number. See some related discussions on Mediawiki - mw:Topic:V5fyhptg7yeuhi1s and mw:Topic:V64xirqg9ncsv7dh. Though I agree that IP editors should have access to this mode. OVasileva (WMF) is Reading web teams' product manager, and she makes all decision for this project. She might know more. If you have more questions, please don't hesitate to ask at mw:Talk:Reading/Web/Advanced mobile contributions. Thanks. Masum Reza📞19:56, 11 October 2019 (UTC)
Some days ago, I was reading an article in enwiki using my mobile phone in old, non-advanced mode. I noticed some kind of CentralNotice there, inviting users to enable Advanced Mode. I think having such notice here would be useful. Ahmadtalk16:50, 16 October 2019 (UTC)
Make it easier for the Commons community to identify from which wiki FileExporter file transfers are coming using a template which applies maintenance categories
Votes (Make it easier for the Commons community to identify from which wiki FileExporter file transfers are coming using a template which applies maintenance categories)
Support Would make it easier for Commons to patrol, and would make it easier for admins/interested users on other projects to help patrol transfers from "their" project. No real downside that I can see. --Xover (talk) 11:48, 13 October 2019 (UTC)
Support, BUT on the condition that supporting this option 3 doesn't mean we completely rule out option 2. They don't exclude each other. @Johanna Strodt (WMDE): if we greenlight option 3, are you taking option 2 off the table? - Alexis Jazzping plz01:31, 18 October 2019 (UTC)
Support It will make it easier for patrollers who are familiar with languages other than English to patrol edits from other wikis, and can also help in backlogs. Ahmadtalk12:51, 20 October 2019 (UTC)
Discussion (Make it easier for the Commons community to identify from which wiki FileExporter file transfers are coming using a template which applies maintenance categories)
Comment, I would preferably see the imports organised like OrgeBots daily uploads by users with less than 250 (two-hundred-fifty) edits + (PLUS) these files being added to a larger more general maintenance category per non-Wikimedia Commons wiki. That way files could be patrolled more easily, if they would all be dumped into a single category that only allows us to see them alphabetically and not based on upload date then we won't be able to properly find new files. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:52, 12 October 2019 (UTC)
Offer 'File Filter and Sort' features not offered by Special Pages, Templates, and API
I would like to create a Filter and Sort WikiMedia Commons Files website that offers features that are not currently offered by Special Pages, Templates, or the WikiMedia Commons API.
In addition to Filtering by all available fields, this website will also Sort by all available fields, including the following:
Uploaded Date
File Size
Page Views
Downloads
To accomplish this, the website will cache the data so it can be filtered and sorted by any field.
Here are two examples of features that I could not find in WikiMedia Commons, which this website will offer:
Display the most recently uploaded Midi files.
Show files in order of their File Size, PageViews, or Downloads.
Wikimedia Commons has pages that offer some of these features, but you can't combine the filter and sort. For example, this page lists all 'audio/midi' files, but you can't see the most recently uploaded files:
https://commons.wikimedia.org/wiki/Special:MIMESearch/audio/midi
This page indicates that searching by Mime Type (aimime) is "Disabled due to miser mode". Therefore, using the current API, you can't search for 'audio/midi' files (I don't know how the **MIMESearch** page does it):
https://www.mediawiki.org/wiki/API:Allimages
Please confirm that I can create a WikiMedia Commons page which describes the Filter and Sort WikiMedia Commons Files website, and that I can display this page in the "Pages in category" section of all WikiMedia Commons pages that list files.
@Masumrezarock100: Thank you for your suggestion. Unfortunately, Toolforge has strict limitations upon the usage of cron, which would be required to create this application. Without those limitations, a poorly created Toolforge application could bring the entire system down. For that reason, a dedicated server is usually required for unlimited cron usage. For more information about this issue, search Google for "toolforge cron".
That is probably why no one has yet created the application that I described, even though there should be a huge demand for the ability to sort the files.
I understand your concern. However, please note that this application would be read-only, so there is no risk of negative effects upon your data. ToolCreator (talk) 23:14, 22 October 2019 (UTC)
Regarding Special Search: Where is the "filemime" parameter documented? Also, the only sorts offered are Relevance and Date. My website would allow you to sort by any field; including File Size, Page Views, and Downloads.
Regarding the cloud server: There are always more limitations upon a cloud server, than on a dedicated server. For that reason, I would not want to incur that inconvenience, for a read-only website that does not require any additional permissions. That's why I pay thousands of dollars a year for a dedicated server.
I could have this website up in 1-2 weeks. If you can find someone else to create it on your cloud server, then go for it. Otherwise, I would need to know that you would not be hostile towards it. Your users would need to know that it exists. ToolCreator (talk) 23:53, 22 October 2019 (UTC)
Also, thank you for the information that you provided. I did not know about that Special Search page, which is very useful. I also did not know that WikiMedia offers usage of their cloud server for free, which I will definitely look into. I guess there is no reason for anyone to pay Amazon! ToolCreator (talk) 00:17, 23 October 2019 (UTC)
Show the FileExporter's "Export to Wikimedia Commons" button only to users on other wikis with certain rights
Nah File exporter automatically exports page history and all old versions of a file. If we show the button to only user with certain rights, others will find alternatives such as Commonshelper. And this will only raise the backlog of Bot move to Commons category. Files transferred using Commonshelper usually needs cleanup. And it doesn't even transfer old versions and page history which is required for attribution. File exporter automatically cleans up file pages, blocks files from transferring with unsupported license, detects abuse filter blocking, and it has many more feature that Commonshelper doesn't. Besides just because a user has few more rights doesn't necessarily mean that user has more experience. So suppose that a experienced editor (on Commons/or a wiki) wants to move files from another wiki (where they don't have the necessary rights) to Commons using file exporter. They wouldn't be able to use this feature and they would just use alternative methods as I've mentioned. We can not give out rights to every experienced user on every wikis. Also even if we hide that portlet link, it can be easily replicated using user scripts. And anyone can easily use this feature that way. Masum Reza📞22:58, 12 October 2019 (UTC)
Seeing that FileImporter is optimized for mobile and there is no direct links to the FileImporter in mobile site, I've created a script for mobile which adds an Export to Wikimedia Commons button. Just import it in your minerva.js in English Wikipedia and navigate to a local file to see the demo. This means anyone can create a script to use the FileImporter. Masum Reza📞15:53, 13 October 2019 (UTC)
NO. What's the purpose of this? To increase the amount of files in the bot script backlog? I hate using CommonsHelper. Calvinkulit • t • c23:24, 24 October 2019 (UTC)
Discussion (Show the FileExporter's "Export to Wikimedia Commons" button only to users on other wikis with certain rights)
@Donald Trung: I would hope so. An example "file exporter" user right could be held by members of a "File Exporters" group on (for example) Arabic Wikipedia, once the coding and infrastructure are in place. It might also make sense to have a corresponding "file importer" right and "File Importers" group here if importation gets out of hand. — Jeff G. ツ please ping or talk to me12:05, 12 October 2019 (UTC)
@Jeff G.: , that is a really good idea, especially if any user can then tag a file for transfer to Wikimedia Commons, but that then a "File exporter" with sufficient knowledge of copyright (and perhaps Wikimedia Commons categorisation, rules, and guidelines) will then actually decide if it is or isn't compatible with Wikimedia Commons. If this proposal asks for the creation of this specific right I would support it, otherwise it should be "an option on the ballot 🗳". --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:49, 12 October 2019 (UTC)
@Jeff G. and Johanna Strodt (WMDE): Certain rights where? On Commons? On the Wiki someone tries to import from? Certain rights here is probably not workable. Certain rights on the exporting wikis is possible, but I suspect we can't actually enforce that. Even if we forced a new user group upon them, they could give the right to anyone who asks for it. I think this will only make sense if Commons gets the right to block a wiki (or even individual users) from importing their files here. That will force them to make sure only users who understand imports do them. - Alexis Jazzping plz01:42, 18 October 2019 (UTC)
Regardless, it wouldn't work. FileImporter is available on Commons and unless you do something here to restrict imports from other wikis, it wouldn't work. As I've said the button can easily be replicated. I suppose they could restrict files from importing from some wikis. That would mean, the FI would have to check the source wiki every time an user tries to import a file, check their user groups on that particular wiki, and then block/allow from importing accordingly. Too many steps here to do IMO. Just hiding that button from public view would not work. And as I've said, people would find alternative methods. Though the proposal below makes sense and should be implemented asap. Masum Reza📞12:19, 20 October 2019 (UTC)
@Jeff G.: Actually no. I do no have auto-confirmed rights on Arabic Wikipedia so I didn't see the "Export to Wikimedia Commons" button there but with my script I replicated the button. And guess what? I was able use to the import feature. For example, the Commons URL for importing this file from Arabic Wikipedia is this. And I could easily import it if I wanted (I didn't because the author field is missing). Care to guess what does this mean? This means that the Export to Wikimedia Commons button is only shown to auto-confirmed users on wikis. The FileImporter tool on Commons doesn't check for user rights on the source wiki. Only the button is hidden for non-autoconfirmed users. Any logged-in user can import files from other wikis even if they don't have auto-confirmed there. Masum Reza📞17:55, 20 October 2019 (UTC)
Module categorization
is currently done only with the related documentation. When no docu is generated, the module remains uncategorized - and can be encountered just accidently.
Sandboxes of modules (and all modules containing a subname after a slash) cannot get a documentation, it's only possible for the main name.
This situation is not at least satisfying. I suggest as a remedy the following:
The latter one may serve somehow also as a maintenance category – but at least it will contain all the modules not visible in the other categories.
This will make easier the navigation in that namespace. -- sarang♥사랑08:39, 27 October 2019 (UTC)
I like the sandbox categorization idea, we have the same thing in template sandboxes. Combining it with SQL, this can also be useful to detect and delete old module sandboxes (though I don't recommend it because creating a sandbox version for a module with several submodules can sometimes take some time). I'm not sure about tagging every single uncategorized module with a maintenance category. Besides the technical challanges (I personally can't find a way to implement it), do we really need to categorise all modules? In some cases, it can be very useful, but we don't even categorise all templates. Nonetheless, you can always create a module /doc subpage and only include some categories in it. Ahmadtalk16:56, 30 October 2019 (UTC)
Give right to delete within first 24 hours of upload to the up-loader
This should decrease a lot of backlogs, why do I need to ask an admin to delete a file that is uploaded by mistake?
votes
Support - What if you upload your private photos, wouldn't it be a good idea to delete that silently within seconds of upload, Instead of waiting for a sysop? -- Eatcha (talk) 05:31, 18 October 2019 (UTC)
{{S}} Won't help backlogs all that much, but I can't think of any severe downside. Should likely be done by a bot, not by MediaWiki feature request. (feature request could follow if the bot gets used extensively) - Alexis Jazzping plz16:03, 18 October 2019 (UTC)
Oppose, at least "for all users". I just realized there's a theoretical legal issue here. If someone were to upload material that the WMF isn't allowed to have on their servers, it could go unnoticed when deleted shortly after upload. I'm not talking about copyvios, I'm talking about the stuff that will send you straight to jail which the WMF scrubs from their servers as soon as it's detected. Perhaps deletion of own uploads within 24 hours could be acceptable for autopatrollers, but absolutely not everyone. - Alexis Jazzping plz06:53, 20 October 2019 (UTC)
Oppose No. There is not a backlog of these cases and you open an enormous can of worms when you take into account overwrites. If you have an image you want to delete and it is within the normal bounds of G7 tag it {{G7}}. It is literally that easy. If you need something deleted quicker because of personal information in it you didn't want, tell no one publicly and email oversight. This is a solution looking for a problem and will do nothing to actually help a nonexistant backlog. --Majora (talk) 20:43, 18 October 2019 (UTC)
WeakOppose, I have often see some users nominate their own files for deletion because they don't want their image to be released under a free license despite irrevocably releasing it under one. While I certainly think that wrongly uploading something private is an issue, sysops can still view deleted files so it's not a mistake we can truly fix today. I am just afraid that this will enable too much deletion of otherwise high quality uploads at the whim of the uploader. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:45, 18 October 2019 (UTC)
I do not think this is a problem. According to present rules, user can request deletion up to a week after upload without any explanation: this is a valid rationale for speedy and it is much longer period than the suggested 24 hours. Ankry (talk) 15:33, 31 October 2019 (UTC)
Oppose - My concern is that people will upload their files and then change their mind.... Licences are irrevocable but allowing this would provide a loophole meaning people could revoke the licence under "I uploaded it by mistake". –Davey2010Talk20:48, 18 October 2019 (UTC)
We would generally respect a deletion request of "changed my mind" within 24 hours (or should). Very recent uploads are treated differently than ones that have been here for a long time. Carl Lindberg (talk) 20:55, 18 October 2019 (UTC)
I agree they are and I've endorsed deletion on a few of those .... however we've always gone by once the file is uploaded it cannot and will not be deleted, Not all uploader requests have been fulfilled, Reading the comments below I don't know if it is legally binding but I've always assumed it is. –Davey2010Talk09:16, 19 October 2019 (UTC)
The speedy deletion guideline is to allow seven days. If someone made a mistake in the file they intended to license, let them fix it. But just not sure it's possible to give a full deletion right in that situation, so the current speedy process may have to be enough. Carl Lindberg (talk) 20:25, 19 October 2019 (UTC)
Oppose as it's unnecessary IMO. Such speedy/deletion requests are usually processed rapidly, if legitimate, as they don't require any discussion. Commons:Deletion requests/File:SharafkhanehPort00007.jpg was an exception, resulting from misunderstandings; I've deleted the image now. A problem is that we have contributors who, despite being active since years, think to have a right to delete their uploads, which had been on Commons for years, simply because they "want to". --Túrelio (talk) 09:25, 19 October 2019 (UTC)
Oppose I have requested speedy deletion for many thousands of deletions of my own uploads, which includes most often not using the standard speedy process/template and for files which may well have been hosted for much longer than a day. If anything we need to advise people a bit more openly on how courtesy deletions work, and perhaps spell out example scenarios in guidelines so that administrators make those choices more consistently and fairly. --Fæ (talk) 09:31, 19 October 2019 (UTC)
comments
@Eatcha: - None of these proposals are currently technically possible. The ability to delete pages is granted across the board by the delete flag. (See also Special:ListGroupRights.) There is no technical method of granting the ability to delete only certain pages or pages within a certain time frame, and this would have to be implemented from scratch. It is unlikely to be implemented even if we had a local consensus for it. If it somehow were implemented, the difficulty in doing so would almost certainly outweigh the marginal benefit. GMGtalk15:22, 18 October 2019 (UTC)
Yeah. That's doable. At the same time, Synchbot was created to implement a global software change already implemented by the Foundation. I'm not sure you're going to get a local admin bot approved for a comparatively small qualify of life change, that's probably only going to be rarely used anyway. GMGtalk16:15, 18 October 2019 (UTC)
Syncbot can delete user pages because it's operator has the "global deleter" right. Syncbot account doesn't do anything. Pathoschild is the one who deletes and edits userpages across Wikimedia projects. Masum Reza📞18:22, 18 October 2019 (UTC)
@GreenMeansGo: such a bot could actually simply handle G7 taggings for recently uploaded files, so one doesn't need to be aware of the existence of the bot. In addition it could check deletion requests to see if someone nominated their own file, and consider those as G7 requests as well. - Alexis Jazzping plz20:00, 18 October 2019 (UTC)
G7 is for the unused content, and though I don't see me either why Ellin said it is 4 year old, a DR is fully appropriate for the content that is in use. We need approved users for the "delete" tool, we need users that are supposed to be familiar with our policies for this kind of tools. Christian Ferrer(talk)20:39, 18 October 2019 (UTC)
Furthermore, it is not because a speedy tag is possible that the administrators have to delete it inevitably, if they thing that there is a good reason to keep the file, or to discuss about the deletion. Christian Ferrer(talk)20:43, 18 October 2019 (UTC)
I think the cases where an uploader requests deletion of an unused file within 24 hours that shouldn't be deleted are really quite sparse. Oh, and that file was unused both when the DR was started and when I tagged the file for G7. It only became used after that. We can't allow random editors to sabotage G7 requests like that. - Alexis Jazzping plz22:37, 18 October 2019 (UTC)
@Majora: I agree this shouldn't be done to help with any backlog. I also agree a bot should ignore files that were overwritten, or even ones that are linked from other files. But tagging {{G7}} is not "that easy". You have to know about that. (which newbies never do) What about a bot that checks DRs and appends G7 where appropriate? - Alexis Jazzping plz01:07, 19 October 2019 (UTC)
I'd be much more amenable to that. When I'm closing old DRs I take into consideration if the {{Delete}} tag was applied during the normal seven day window. If the file is not in use I almost always courtesy delete the file such as this example. A bot to do that tagging I would probably support. --Majora (talk) 01:12, 19 October 2019 (UTC)
@Donald Trung and Davey2010: I think legally the Creative Commons license may not be enforceable if someone changes their mind within 24 hours. At least on Commons. We don't ask uploaders to sign anything, we don't ask for confirmation. It is possible to upload the wrong file by accident, or upload a file without realizing you're releasing it under a free license, or what a free license even means. This could vary from country to country, probably even from judge to judge. But a contract is generally not valid unless all parties can be reasonably assumed to have understood its terms. - Alexis Jazzping plz01:07, 19 October 2019 (UTC)
@Masumrezarock100: CC license may not yet be valid at that point. This is no case of revoking a CC license (which, indeed, is not possible) but a case of the CC license having never been valid to begin with. The UploadWizard doesn't inform uploaders sufficiently and confirm they understood the terms sufficiently to be able to instantly turn an upload into a binding contract. This will vary from country to country. - Alexis Jazzping plz02:38, 19 October 2019 (UTC)
Tell that to the Terms & Conditions that accompany all apps, websites, etc. that nobody reads or understands but are definitely legally binding. Ignorance of the legal ramifications of what you are doing does not indemnify you to those consequences. --Majora (talk) 02:52, 19 October 2019 (UTC)
Is there no difference between those for profit companies and us. If no, why are we here ? Instead of volunteering for Apple or Ford. WMF must not become one of those companies. I'm asking for a single day, not even a week. -- Eatcha (talk) 03:09, 19 October 2019 (UTC)
@Majora: Actually it can in some cases. At least in the EU. In the US Terms & Conditions are not always enforceable either. And in the UploadWizard, we don't even have a button that says "I release this work under a free license" or even "I accept", no.. we have "Next", which is legally nonsense. - Alexis Jazzping plz03:30, 19 October 2019 (UTC)
I was thinking of the "clickwrap" types which the US link you mentioned pretty much states are legally enforceable. While I am not a lawyer and therefore this is not legal advice, the UploadWizard has a notification that you are releasing it under <insert license here> with a link to the full legal code. You have to acknowledge that you are agreeing to this action by clicking the "Next" button (which by the way is stored at MediaWiki:Mwe-upwiz-next and therefore could always be changed). Not as good as "I agree" but I would imagine these would fall under a clickwrap type scenario if someone would really decide to sue someone else over a reuse of a CC release image that they had deleted 12 hours later. --Majora (talk) 03:45, 19 October 2019 (UTC)
@Majora: That, and there is one more difference. Terms & Conditions usually contain ordinary stuff. "We use Google statistics, we store cookies on your computer, underwear can not be returned if the packaging has been opened, you give us a non-exclusive license to use photos you upload, if anything bad happens we are not responsible for nothing" A user can expect such terms, they are generally reasonable. "You will release your work to the general public under an irrevokable free license" is not expected and quite possibly (from a legal point of view) not reasonable. (but I am also not a lawyer) The EU is probably more restrictive in this than the US. - Alexis Jazzping plz04:19, 19 October 2019 (UTC)
Comment Furthermore this kind of thing, in the case that it is technically possible, will potentially lead to a few other problems, e.g. some prolofic uploaders may be involved in conflicts with other members of the community and so then decides within an emotional "diva-like" behavior to delete all the upload they did in the past week. That is simply inacceptable as one of the pillars of the Wikimedia projetcs is that we don't really own the content that we add. The current situation at the discretion of the administrators, and in cases a little more complicated with formal DRs is quite good IMO. Christian Ferrer(talk)17:06, 19 October 2019 (UTC)
True, but impact of 24 hours is quite small. Regardless, I've changed my vote to oppose, albeit for different reasons. - Alexis Jazzping plz07:05, 20 October 2019 (UTC)
Autopatrol edits made with the translation tool or create a new group
When translators who do not have autopatrol right translate things, their edits stay unpatrolled until a patroller marks them as patrolled. We have a different translation reviewing system, translation can be reviewed by those who have the translate-messagereview right. Currently any logged-in user can review translations. In addition to that, translations have to be approved by translation admins. So let's count the steps for reviewing an unautopatrolled translator's translations.
Review by a patroller and marking the edits as patrolled
Review by another translator (optional)
and lastly acceptance by a translation admin.
This unnecessarily increases the backlog of unpatrolled edits. So if we can just omit the first step, we'll be able to reduce a lot of unpatrolled translations from the backlog. We have plenty of trusted translators here and their translations do not need to patrolled. Autopatrol might not be the best fit for users who are only here for translating things.
For example, this user Worrida (just a random example I found while patrolling). Their upload count is zero, and they are only here for translating pages and templates.
Some links to recent changes and new pages backlog
Oppose the translation tool can be used for the same vandalism like every page. And there is a huge backlog of unchecked translations. I think it would be better to give autopatrol rights to users doing more translation. --GPSLeo (talk) 09:37, 31 October 2019 (UTC)
Autopatrol edits made with the translation tool or create a new group: discussion
Are you sure about the last step: "lastly acceptance by a translation admin"? As far as I know, translations do not need to be accepted by a translation-admin. 4nn1l2 (talk) 11:59, 30 October 2019 (UTC)
@GPSLeo: Autopatrol rights are given to trusted editors who understands our policies (including copyrignt policies). IMO there is no reason to assume that a user who is only here for translating things would also be familiar with our policies about copyrignts. But you do have a point. How about we just create a group called "Translators" or something? Their edits related to translation will be autopatrolled. Masum Reza📞09:49, 31 October 2019 (UTC)
I only want translations automatically marked as patrolled it the user is trusted. The texts are getting translated are often guidelines and other important pages. If I can not trust the user I want to patrol the edits or at least some and mark all manually as patrolled. Autopatrolled users do not have to understand every copyright rules for this we have the license reviewers. --GPSLeo (talk) 13:25, 31 October 2019 (UTC)
Oppose Normally, users should not visit (or even watch) other users' talk pages, because it most probably causes drama. No need to facilitate this. 4nn1l2 (talk) 16:23, 27 October 2019 (UTC)
@4nn1l2: Yes, but someone who wants to visit someone else's talk page will most probably check it, whether with UT or without it. I think this can be useful mostly when you are busy doing something and you want to request help, ask questions etc from someone you know. I mean, can this, solely, become a problem (or at least, a somehow important part of the process that creates the problem)? Ahmadtalk19:41, 27 October 2019 (UTC)
@Ahmad252: I splitted this off to allow more votes to come in. If the next two votes support, UT: can be requested. If the next two oppose, there's no consensus. - Alexis Jazzping plz07:42, 5 November 2019 (UTC)
Oppose Abbreviations tend to form a cryptic language readable only by experts. They can be a problem for new users if they are too many. --GerakiTLG14:53, 11 November 2019 (UTC)
Discussion
Are the redirects automatic, or would they need manual creation? If they are automatic (e.g., TEM:Wikidata Infobox), then this seems reasonable, but if they need to be manually created then it sounds like it would be an unnecessary mess... Thanks. Mike Peel (talk) 15:24, 28 October 2019 (UTC)
@Mike Peel: They will be automatic. In fact, it isn't a "redirect", but another way to type the namespace's name (maybe we can call it an alias). It also works vice versa; you can type Commons:VPP instead of COM:VPP, there is no difference. Ahmadtalk16:46, 28 October 2019 (UTC)
While WatchlistNotice has been used fairly actively until 2018 there were only 4 in 2019 and it's plenty of legacy code, including the now deprecated jquery.ui. As the system's importance is ceasing, I suggest de-registering the gadget, reverting the MediaWiki pages that transclude the messages into the Watchlist and the Community portals so the system doesn't bind JavaScript maintainer's resources. -- Rillke(q?)23:07, 26 October 2019 (UTC)
Well, I suggest to drop the possibility to broadcast messages through watchlist messages as described in Help:Watchlist messages. I expect nothing else to break. If itsn't dropped it probably won't break tomorrow, however a lot of this site's code needs a major overhaul and reducing features helps to focus. -- Rillke(q?)23:28, 26 October 2019 (UTC)
Yes, you will still have the site notice. Watchlist notice was introduced to have a more fine-grained, compact messaging system capable of handling many messages without becoming too annoying. However, as it isn't used, it fails its purpose. -- Rillke(q?)21:40, 30 October 2019 (UTC)
Support Having a second notice system that works differently than the main one is quite confusing anyway. Sebari– aka Srittau (talk) 16:25, 30 October 2019 (UTC)
@El Grafo: No, not really. Watchlist notices are built into the system by MediaWiki itself. You can't turn them off by disabling a gadget. The gadget in question certainly makes it easier to post watchlist messages but removing it won't affect the implementation of the other proposal. --Majora (talk) 21:31, 19 November 2019 (UTC)
I'm not sure if this is strictly within our current scope. Educational, yes, totally, but COM:SCOPE isn't really clear about datasets like these. "representative merely of raw text, e.g. ASCII files" kind of suggests it falls outside of our current scope. But that line seems to have been written with text that should go into articles in mind, not gigabytes of tab separated data. Apparently we do have mw:Help:Tabular Data (I learned something today), but I'd also like to see the original files on Commons. (also I don't know if tabular data will even be suitable for this)
This will probably involve:
Declaring that at least for Google Ngrams, we are making an exception for COM:SCOPE.
Temporarily enable .gz uploads for either bots, administrators or a particular user who will upload it.
Support - Commons has more useless(Ngrams are not useless BTW) files than these, why shouldn't we host these ? -- Eatcha (talk) 17:22, 17 October 2019 (UTC)
Conditional support If this is generalised to "Allow dataset uploads with prior community agreement". Oppose If this is a Google-only exception. ℺ Gone Postal (〠✉ • ✍⏿) 04:37, 30 October 2019 (UTC)
Oppose - First off, these are mostly zipped and gzipped csv files. Shouldn't those go somewhere like CommonsArchive or Internet Archive rather than here? Second, Google is more than capable of backing up their own files and generally gives a year or two notice before discontinuing any services. What's the point of creating a 2nd (3rd?) back-up on Commons when there is no reason to believe that Google is discontinuing Ngrams any time soon? Surely, there are more productive uses of our time and space. Finally, hosting data files is out of scope for Commons. According to Commons:Project scope, "Every file must be a media file." Kaldari (talk) 21:52, 7 November 2019 (UTC)
Oppose I agree with Kaldari. Commons is for media files, backup is already existing in Internet Archive.--So9q (talk) 10:51, 16 January 2020 (UTC)
Oppose - I agree with Kaldari and am of the opinion that this is out of scope. The Internet Archive is a better place to host a backup of datasets like this. GFJ (talk) 12:34, 27 January 2020 (UTC)
@El Grafo: Doesn't even include the 2012 dataset. But why shouldn't Commons and archive.org both retain a copy? There is no technical or copyright reason why we couldn't. - Alexis Jazzping plz16:21, 17 October 2019 (UTC)
@Gone Postal: What's the difference? Prior community agreement will always be needed due to file formats. I guess you mean datasets should be added to COM:SCOPE? I agree with that, I'll create a proposal for that as well. Consider this proposal the finding of community agreement to upload Google Ngrams. - Alexis Jazzping plz15:36, 30 October 2019 (UTC)
@Alexis Jazz: Ok, fair enough. I just want to be sure that if I were to spend lots of resources and collect a good dataset about word useage on forums, newsgroups (yes, they still exist), etc, then they would be treated in a similar manner to Google's. ℺ Gone Postal (〠✉ • ✍⏿) 13:21, 31 October 2019 (UTC)
@Kaldari: El Grafo suggested CommonsArchive above. According to Zhuyifei1999, the storage space of CommonsArchive would have to be buffed up considerably. It only has 317 files at the moment and it is unofficial, so I wouldn't be surprised if CommonsArchive itself disappeared at some point. The Ngram files are in an open format, so there's no problem there. We just couldn't allow gzip for everyone because a gzip file can contain anything. As for Google backing it up themselves: we shouldn't rely on Google. Why import anything from anywhere? Others can take care of themselves right? And I'm not watching the Ngrams download page all the time. They could give a notice a year in advance and I would probably miss it. As for time, if someone runs a script to perform the upload (which shouldn't be exceptionally hard, I can provide a nice clean list of links if needed), I will take care of descriptions/categories/etc. - Alexis Jazzping plz21:21, 22 November 2019 (UTC)
@Kaldari: any comment? Our space is barely a concern, WMF doesn't even seem interested in permanently deleting obvious copyvios and abuse. (I doubt even the Wikizero abuse has been permanently deleted) Our time is also no real concern, I will do the categorizing and everything else for the file pages. Running an upload script is not really time consuming either, it just runs in the background. Uploading to CommonsArchive would cost a lot of time though, because I don't have any tools there and services would need to be reconfigured to add space. - Alexis Jazzping plz19:52, 22 December 2019 (UTC)
@Alexis Jazz: I concede every point to you except "we shouldn't rely on Google". Google has a gzillion times more resources than us and isn't going anywhere, so why not just let them host it? Is there a Wikimedia project that is actively wanting to use this data? Kaldari (talk) 00:51, 23 December 2019 (UTC)
@Kaldari: Google as a company, sure. But any particular Google service or a part of any given service? No. Remember links to other videos on YouTube, usually on end cards? Vanished. Just gone. Even if Ngrams remain available, there's no guarantee the downloads will. Or they could be protected by a CAPTCHA at any point, making it much harder to get them.
Your second question: Ngrams can certainly be used for Wiktionary. Dutch Wiktionary already has a header "gangbaarheid" (prevalence) which currently contains a link to the official word list (if the word is in the word list) and statistics from a research project. (if the word was included in that) In case of w:wikt:amai, only 58% of Dutch people recognized it while 90% of Flemish people did. Which makes sense because that word is rarely used in The Netherlands. Adding a statistic to indicate how common any given word is (and how it's use progressed over time) would add value. - Alexis Jazzping plz01:12, 23 December 2019 (UTC)
@Alexis Jazz: Sure, it could add value, but I'm not convinced anyone is actually going to use this data on our projects. If there was an actual plan to use it or even better, some existing uses, I would be more open to hosting it. Another issue (that you already mentioned) is that data files are not within the scope of Commons. According to Commons:Project scope, "Every file must be a media file." There are countless data files out there on the internet that could have educational value and are under open licenses (for example, data supplements for open license scientific papers). Are we going to start hosting all of them just because they might disappear one day? That sounds like a job for the Internet Archive, not Wikimedia Commons. Kaldari (talk) 23:19, 14 January 2020 (UTC)
@Kaldari: Chicken and egg. I may work on bringing something to Wiktionary (I must admit, with my schedule and everything, it could take quite some time, hard to say) but if Commons doesn't host the raw data, I probably won't. Because I don't want to rely on Google and see it all vanish one day. As for open data from scientific papers, I say: sure, let's host it! Why not? Why does data have to be restricted to the data: namespace? Or do you want to get rid of the data: namespace as well? - Alexis Jazzping plz17:15, 15 January 2020 (UTC)
Support AS an impatient user, deletion process is too slow -- Eatcha (talk) 05:24, 18 October 2019 (UTC)
Oppose I can't think of anything to stop me from moving my talk page full of copyvio notices to User:Username/ExpungeMyRecordPlease and have it deleted! - Alexis Jazz ping plz 16:09, 18 October 2019 (UTC)
Strong oppose Unless you are going to remove the ability to move pages from everyone as well. Allowing for the deletion of subpages is the same as allowing deletion of everything. Incredibly unwise. --Majora (talk) 20:44, 18 October 2019 (UTC)
Strong support. --予弦 06:14, 25 August 2019 (UTC)
Comment Without new comments, SpBot is just gonna archive it again. - Alexis Jazz ping plz 03:42, 22 October 2019 (UTC)
Weak oppose I have seen filemovers wanting to get rid of redirects for the wrong reasons. What comes to mind are the misspelled "Caribean" redirects. I'm also not entirely convinced that file movers need to suppress redirects so frequently that admins can't handle it. Perhaps if I can be convinced this is needed more often and potential damage from the removal of redirects that didn't need removal can be kept under control somehow.. Until then, weak oppose. - Alexis Jazz ping plz 20:53, 12 September 2019 (UTC)
Neutral, leaning towards 
Weak support. Masum Reza📞 14:41, 7 October 2019 (UTC)
Question I'm confused by the talk of abuse filters. Isn't this just a matter of flipping some bits in the user group data? – BMacZero (🗩) 06:13, 19 September 2019 (UTC)
Keep DjVu files are used by the Wikisources, and are within scope. Commons is not here to determine what the other sites should use, it is here to host the files for the sisters that are within scope. — billinghurst sDrewth 09:56, 8 October 2019 (UTC)
) too. The image width in the gallery needs to be adjusted. - Alexis Jazz ping plz 02:45, 10 October 2019 (UTC)
Done (wasn't entirely as simple as I thought) - Alexis Jazz ping plz 19:13, 16 October 2019 (UTC)_02.png)
--Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:59, 11 October 2019 (UTC)
