Commons:Village pump/Technical/Archive/2019/09
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. |
mysterious alphabetising?
Greetings - I can't figure out why "Cimitero comunale di Condera (19 F)" is alphabetised under "R" in the Commons Category:Cemeteries in Italy by city . I edited in a DEFAULTSORT template, but it still goes under "R". (Is it because of its location in Reggio Calabria? I can't see what template or instruction might be causing this.)
Seauton (talk) 23:35, 4 September 2019 (UTC)
- Fixed See Special:Diff/364664668. 4nn1l2 (talk) 01:48, 5 September 2019 (UTC)
At English something weird appeared to me on files using this template:
"Template loop detected: Template:Autotranslate <includeonly></includeonly>"
In Pt is okay, for example.
Could you pleas check it out? -- Rodrigo Tetsuo Argenton m 05:41, 16 September 2019 (UTC)
Challenge speedy deletion button
Clicking the button gives a form to start the DR. If, at this point, you decide not to proceed and cancel, the DR is not created, but the SD tag is removed from the file - or at least that's what happened for me when I mis-clicked the button and cancelled. Is this desired behaviour? I would have assumed that cancelling would leave the SD tag in place, and I worry this could lead to "accidental" tag removals. -- Begoon 08:38, 11 September 2019 (UTC)
- Pinging @Perhelion. — Jeff G. ツ please ping or talk to me 08:52, 11 September 2019 (UTC)
- This is indeed not an expected behavior. But this was always present for admins in this way. I'll look for a fix. Thanks for ping. -- User: Perhelion 13:46, 11 September 2019 (UTC)
- Fixed -- User: Perhelion 14:12, 11 September 2019 (UTC)
- Thank you for fixing that so quickly. It now works as I would have expected. When I tested 'cancelling' again I did need to refresh the page afterwards for the 'challenge' button to reappear on the page, but that doesn't seem particularly important. -- Begoon 23:38, 11 September 2019 (UTC)
- @Perhelion: there seems to be something wrong now. I saw that some files still retained the nxd notices, so I just tested two. Both times I was stuck at Notifying Username... and the npd notices were not removed: File:برج الساعة مكة.jpg File:جامعة عفت1W9318.jpg.--Roy17 (talk) 16:03, 30 September 2019 (UTC)
- Done ups* Thanks for ping. -- User: Perhelion 17:07, 1 October 2019 (UTC)
- This section was archived on a request by: -- User: Perhelion 17:08, 1 October 2019 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
- You can use the new termbox interface if you edit Wikidata on a mobile device. This is to edit labels, descriptions and aliases easier on the mobile pages. [1]
- The new version of MediaWiki has been deployed during the last week.
- The previously announced change of positions of the "Wikidata item" link on all wikis has been rollbacked due to unexpected cache issues. [2]
- The limit for rollbacks has been increased from 10 to 100 rollbacks per minute. [3]
- The advanced version of the edit review pages (Recent Changes, Watchlist, and Related Changes) now include two new filters. These filters are for "All contents" and "All discussions". They will filter the view to just those namespaces. However the "All discussions" filter does not include pseudo talk pages, like discussions that are in the Project: or Wikipedia: namespaces. But it will include changes happening on Project talk: or the Wikipedia talk:. [4]
Changes later this week
- The new version of MediaWiki will be on test wikis and MediaWiki.org from 3 September. It will be on non-Wikipedia wikis and some Wikipedias from 4 September. It will be on all wikis from 5 September (calendar).
- When you log in, the software checks your password to see if it follows the Password policy. From this week, it will also complain if your password is one of the most common passwords in the world. If your password is not strong enough, please consider to change your password for a stronger password. [5]
Meetings
- You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 4 September at 15:00 (UTC). See how to join.
Future changes
- You will be able to read but not to edit Wikidata for up to 30 minutes on September 10 at 05:00 (UTC). [6]
- You will be able to read but not to edit some mid-sized wikis for up to 30 minutes September 17 at 05:00 (UTC). You can see which wikis. [7]
- You will be able to read but not to edit some mid-sized wikis for up to 30 minutes September 24 at 05:00 (UTC). You can see which wikis. [8]
- You will be able to read but not to edit Wikimedia Commons for up to 30 minutes on September 26 at 05:00 (UTC). [9]
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
09:07, 4 September 2019 (UTC)
Subcategories not alphabetized by person's surname
For example, in Category:Female poets. Over time I've spot-checked and edited to manually add the DEFAULTSORT template with surname-comma-given name, but this is time-consuming and erratic. I don't understand why some subcategories are automatically alphabetized by their surname. Does it have to do with the Wikidata Infobox template? Can a bot take care of it? I should think this would be systematic, whether or not automated. How can I effectively intervene? -- Deborahjay (talk) 10:06, 3 September 2019 (UTC)
- @Deborahjay: {{Wikidata Infobox}} will automatically set the DEFAULTSORT if family name (P734) and given name (P735) are set in the corresponding Wikidata item, otherwise it adds them to Category:Uses of Wikidata Infobox with no family name and Category:Uses of Wikidata Infobox with no given name accordingly. There's quite a backlog of categories without the infobox (i.e., without matched Wikidata items), and Wikidata items without those properties set, though. Thanks. Mike Peel (talk) 17:42, 3 September 2019 (UTC)
- @Mike Peel: , I'm delighted to discover this - because it's exactly the sort of task I enjoy undertaking, and as a multilingual, multicultural former museum archivist, speed typist and professional proofreader, I can be counted on to do it well. Many thanks for steering me this way! -- Deborahjay (talk) 18:12, 4 September 2019 (UTC)
- @Deborahjay: That's fantastic, have fun! You may also be interested in having a look at d:Wikidata:WikiProject Names. :-) Thanks. Mike Peel (talk) 19:19, 4 September 2019 (UTC)
- @Mike Peel: it's really valuable that you so quickly got me connected with that Wikidata project, as I'd already created two items whose native label (Hebrew) spellings differ but with identical romanized transcription - and according to the guidelines I read on the project, I have to tweak them to conform with standards. Besides my experience with the vagaries of Hebrew romanization, my museum archival work dealt with Holocaust content, so I learned to identify many versions of names that appear in that population base (including in Cyrillic and the Yiddish variant of the Hebrew alphabet). Head's up also to @Ijon: to show how I can turn the corner with manual DEFAULTSORT fixes and do the work at the item level in Wikidata, as well I might. -- Deborahjay (talk) 19:46, 4 September 2019 (UTC)
- Great! :) Ijon (talk) 23:59, 5 September 2019 (UTC)
- @Mike Peel: it's really valuable that you so quickly got me connected with that Wikidata project, as I'd already created two items whose native label (Hebrew) spellings differ but with identical romanized transcription - and according to the guidelines I read on the project, I have to tweak them to conform with standards. Besides my experience with the vagaries of Hebrew romanization, my museum archival work dealt with Holocaust content, so I learned to identify many versions of names that appear in that population base (including in Cyrillic and the Yiddish variant of the Hebrew alphabet). Head's up also to @Ijon: to show how I can turn the corner with manual DEFAULTSORT fixes and do the work at the item level in Wikidata, as well I might. -- Deborahjay (talk) 19:46, 4 September 2019 (UTC)
- @Deborahjay: That's fantastic, have fun! You may also be interested in having a look at d:Wikidata:WikiProject Names. :-) Thanks. Mike Peel (talk) 19:19, 4 September 2019 (UTC)
- @Mike Peel: , I'm delighted to discover this - because it's exactly the sort of task I enjoy undertaking, and as a multilingual, multicultural former museum archivist, speed typist and professional proofreader, I can be counted on to do it well. Many thanks for steering me this way! -- Deborahjay (talk) 18:12, 4 September 2019 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Changes later this week
- You will be able to read but not to edit Wikidata for up to 30 minutes on 10 September at 05:00 (UTC). [10]
- When you log in, the software checks your password to see if it follows the Password policy. From this week, it will also complain if you are a "privileged user" and your password is too short. If your password is not strong enough, please consider to change your password for a stronger password. [11]
- The new version of MediaWiki will be on test wikis and MediaWiki.org from 10 September. It will be on non-Wikipedia wikis and some Wikipedias from 11 September. It will be on all wikis from 12 September (calendar).
Meetings
- You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 11 September at 15:00 (UTC). See how to join.
Future changes
- Soon, the AbuseFilter will recognize new syntax errors. Specifically, it will recognize errors about empty operands. You can see a list of examples in phab:T156096. Any active filter with such an error will stop working; hence, please take a look at the list of affected filters, and fix the ones that you can fix. Note that there is also an ongoing RFC on meta-wiki about the creation of a new abusefilter-manager global group.
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
17:42, 9 September 2019 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Changes later this week
- You will be able to read but not to edit Wikidata for up to 30 minutes on 10 September at 05:00 (UTC). [12]
- When you log in, the software checks your password to see if it follows the Password policy. From this week, it will also complain if you are a "privileged user" and your password is too short. If your password is not strong enough, please consider to change your password for a stronger password. [13]
- The new version of MediaWiki will be on test wikis and MediaWiki.org from 10 September. It will be on non-Wikipedia wikis and some Wikipedias from 11 September. It will be on all wikis from 12 September (calendar).
Meetings
- You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 11 September at 15:00 (UTC). See how to join.
Future changes
- Soon, the AbuseFilter will recognize new syntax errors. Specifically, it will recognize errors about empty operands. You can see a list of examples in phab:T156096. Any active filter with such an error will stop working; hence, please take a look at the list of affected filters, and fix the ones that you can fix. Note that there is also an ongoing RFC on meta-wiki about the creation of a new abusefilter-manager global group.
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
17:43, 9 September 2019 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Changes later this week
- You will be able to read but not to edit Wikidata for up to 30 minutes on 10 September at 05:00 (UTC). [14]
- When you log in, the software checks your password to see if it follows the Password policy. From this week, it will also complain if you are a "privileged user" and your password is too short. If your password is not strong enough, please consider to change your password for a stronger password. [15]
- The new version of MediaWiki will be on test wikis and MediaWiki.org from 10 September. It will be on non-Wikipedia wikis and some Wikipedias from 11 September. It will be on all wikis from 12 September (calendar).
Meetings
- You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 11 September at 15:00 (UTC). See how to join.
Future changes
- Soon, the AbuseFilter will recognize new syntax errors. Specifically, it will recognize errors about empty operands. You can see a list of examples in phab:T156096. Any active filter with such an error will stop working; hence, please take a look at the list of affected filters, and fix the ones that you can fix. Note that there is also an ongoing RFC on meta-wiki about the creation of a new abusefilter-manager global group.
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
17:49, 9 September 2019 (UTC)
Can anyone help to put Template:The Stand News into machine-readable license
Can anyone help to put Template:The Stand News into machine-readable license? The administer mention if nobody done it, all the files will be delete. I don't know how to use it and hope someone can help.--Wpcpey (talk) 16:14, 14 September 2019 (UTC)
- Yes, I am not involving myself further in this undeletion, but it's important that at least the files are no longer in Category:Files_with_no_machine-readable_license, because this is our only way to detect files without a license and this category has to be monitored file by file on a regular base, so that it is highly disruptive to this maintenance job if these files are cluthering this problem category permanently. So anybody with knowledge of template coding, your help will be appreciated. Jcb (talk) 16:25, 14 September 2019 (UTC)
- I did sniff around the code some, then checked the successive DR discussions, and… decided to leave this aside, though regretting: I am convinced that whoever will cause this template to keep files transcluding it off the mentioned maintenance cat — will find themselves on the fast lane to block town. -- Tuválkin ✉ ✇ 18:27, 14 September 2019 (UTC)
Resolved by Roy17. Jcb (talk) 20:40, 14 September 2019 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Problems
- Last week's Tech News had delivery problems. Some did not get the newsletter. Some got it more than one time. The developers are working on the problem. [16]
- There was a problem with the new MediaWiki version last week. The new version was paused. [17]
Changes later this week
- You will be able to read but not to edit some mid-sized wikis for up to 30 minutes on September 17 at 05:00 (UTC). You can see which wikis. [18]
- The new version of MediaWiki will be on test wikis and MediaWiki.org from 17 September. It will be on non-Wikipedia wikis and some Wikipedias from 18 September. It will be on all wikis from 19 September (calendar).
Meetings
- You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 18 September at 15:00 (UTC). See how to join.
Future changes
- The Wikipedia app for Android invites users to do small tasks. This is to get more readers to edit. If they get reverted too many times it will pause or block the tasks for that user. All normal editing will still work if the community doesn't block the user. The developers want to know if the plan looks OK. You can see what it could look like and give feedback.
- When you look at an old version of a page you get a warning that this is not the newest version. This uses the CSS class
.mw-revision
. It will use the CSS class.warningbox
for styling instead. If your wiki uses templates to change how the warning looks they will have to be updated. This will happen later. If this would cause problems you should tell the developers in the next couple of weeks. [19]
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
15:07, 16 September 2019 (UTC)
No preview for this PDF?
File:广东省安全生产委员会办公室转发国务院安委会办公室关于实施遏制重特大事故工作指南构建双预防机制的意见的通知.pdf. A buggy file, or a bug in mediawiki?--Roy17 (talk) 23:23, 10 September 2019 (UTC)
- Also, the 81 PDFs uploaded on September 16 to Category:Finlands Allmänna Tidning 1878 have no previews. --LA2 (talk) 23:26, 17 September 2019 (UTC)
Video player regression in Safari 13.0
If you've just installed Safari 13.0, beware that the first video playback attempt on each page view may stall; closing the video popup and playing a second time works.
I have a fix in the works, but as it's late in the week it may or may not get applied immediately.
Note that you can enable the "new video player" in beta features which does not encounter the same bug. --Brion Vibber (WMF) (talk) 21:13, 19 September 2019 (UTC)
Unable to move categories
Whenever I go to click on "Move", my action gets immediately throttled, with the default message displayed, despite my last move having been more than a month ago, not a few minutes ago. What's going on here, exactly? – PhilipTerryGraham (talk) 03:34, 19 September 2019 (UTC)
- Hi, I am having the same problem. My last move was 2 days ago. --LamBoet (talk) 04:07, 19 September 2019 (UTC)
- I don't know what that problem is, but I just successfully moved a test category; maybe the problem is gone now. Ahmadtalk 13:44, 20 September 2019 (UTC)
- Yes, I was able to move one too, it seems to be gone. --LamBoet (talk) 15:18, 20 September 2019 (UTC)
- It was fixed in phab:T233308, and deployed here yesterday Sept. 19. – Ammarpad (talk) 21:26, 20 September 2019 (UTC)
- Yes, I was able to move one too, it seems to be gone. --LamBoet (talk) 15:18, 20 September 2019 (UTC)
Closing the mediaplayer doesnt stop playing?
Try Category:License_review_needed_(video) for example. Dont click into the file but simply open the player on the cat page. Then close it. It is still playing in the background. Is this happening for you? I use firefox win10.--Roy17 (talk) 20:59, 15 September 2019 (UTC)
- As I tried today, this doesnt happen to Opera, so it could be firefox's bug, or the player is not compatible with firefox.--Roy17 (talk) 21:55, 23 September 2019 (UTC)
JFIF files
I'd like to ask how JFIF is best handled on Commons. Do we convert them to jpeg? (Hopefully your advice will be summarised into a page help:jfif so that future users wont need to ask again.)
The specific issue that troubles me, is how to extract a best possible copy of File:明治時代の万世橋駅 .png from http://dl.ndl.go.jp/info:ndljp/pid/762376/42 . If you figure out a way better than its jfif previews, please go ahead and use that method.--Roy17 (talk) 19:33, 20 September 2019 (UTC)
- @Roy17: I extracted File:明治時代の万世橋駅.jpg from the PDF. Let me know if the PDF download doesn't work for you. - Alexis Jazz ping plz 19:53, 20 September 2019 (UTC)
- Oops.. The preview is better than the PDF. Sorry. - Alexis Jazz ping plz 19:54, 20 September 2019 (UTC)
- @Roy17: JFIF is just a kind of JPEG file (Exif being the other common one). So there's no conversion to be done: just upload them with a ".jpg" or ".jpeg" extension. --bjh21 (talk) 22:05, 20 September 2019 (UTC)
- @Bjh21: thx for the tip! But I just wanna play safe. Do you mean that the file extension could be simply changed without any technical problems?--Roy17 (talk) 21:29, 21 September 2019 (UTC)
- @Roy17: Yes. I could be wrong, but at worst we'll find out how Commons fails to handle these files. --bjh21 (talk) 12:45, 23 September 2019 (UTC)
- Thx a lot! But strangely the library website exported a jpg this time when I tried again today...--Roy17 (talk) 21:55, 23 September 2019 (UTC)
- @Roy17: Yes. I could be wrong, but at worst we'll find out how Commons fails to handle these files. --bjh21 (talk) 12:45, 23 September 2019 (UTC)
- @Bjh21: thx for the tip! But I just wanna play safe. Do you mean that the file extension could be simply changed without any technical problems?--Roy17 (talk) 21:29, 21 September 2019 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Problems
- Some edits that used the visual editor were not working. This has now been fixed. [20]
- Last week's Tech News had delivery problems. Some did not get the newsletter. Some got it more than one time. The developers are working on the problem. [21]
Changes later this week
- The new version of MediaWiki will be on test wikis and MediaWiki.org from 24 September. It will be on non-Wikipedia wikis and some Wikipedias from 25 September. It will be on all wikis from 26 September (calendar).
- You will be able to read but not to edit an important number of mid-sized wikis for up to 30 minutes on 24 September at 05:00 (UTC). You can see which wikis. [22]
- You will be able to read but not to edit Wikimedia Commons for up to 30 minutes on 26 September at 05:00 (UTC). [23]
Meetings
- You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 25 September at 15:00 (UTC). See how to join.
Future changes
- Internet Explorer 6 and 7 might not be supported in the future. This means the browsers might start looking a bit weird. They would not get security support. This is because almost no one uses the browsers anymore. Supporting them makes the wikis less secure for everyone else. [24]
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
20:20, 23 September 2019 (UTC)
Deleting an inferior duplicate of a different extension
It's quite common to find cases in which a worse version had been uploaded before a good one with another extension (for example a gif/png downsized thumb from the net). If the worse one is to be deleted, should the original filename in say PNG be redirected to the JPG? Or should users simply replace all global usage and then delete without leaving redirects?--Roy17 (talk) 21:55, 23 September 2019 (UTC)
"You are trying to add a OTRS permission tag ..."
Hi! I noticed this file has a dupe otrs permission template. (template otrs is a redirect to template PermissionOTRS) So I set out to remove it as it looks silly to have the otrs box twice. But!
1) First, there was a broken error massage at the top of the page. It read
Error: {| style="width:90%; margin:0 auto; background:#fff8f0; border:1px solid #b22; border-left-width:10px;" | style="width:52px; padding:2px 0 2px 0.5em; text-align:center;" class="com-mobile-handheld-hidden" | Wikimedia OTRS logo.svg | style="color:black;" | Warning You are trying to add a OTRS permission tag to this page. In general, such tags should only be added by OTRS members. You should not add such tag unless explicitely instructed to do so by the OTRS member. You may press "Save page" again if you like to save this edit. If you do so, your edit will be tagged for review. In case you aren't sure if your edit is okay, it's best to ask for help, on the OTRS Noticeboard. |}
I.e. that's the text I see on the wiki page, not some source view mode. It kinda looks like [25] But not exactly.
2) The text tells me to press again the save button. However that leads back to the very same page again... Is this because of some cookies silliness? -2001:14BA:984A:F200:0:0:0:8EA 20:32, 24 September 2019 (UTC)
Center appearance problem
Templates like Template:Vote archive and Template:Mbox are not appearing properly as they are supposed to be centered. 1989 (talk) 04:43, 19 September 2019 (UTC)
- I asked the very same here. No replies so far. -- Tuválkin ✉ ✇ 09:49, 19 September 2019 (UTC)
- This was a recent change in the MediaWiki css, due phab:T232553. Maybe ask for a fix there. -- User: Perhelion 15:17, 19 September 2019 (UTC)
- That was a side-effect of a change introduced a few days ago. We're tackling it in phab:T233359 --Volker E. (WMF) (talk) 03:13, 20 September 2019 (UTC)
- I think the problem is gone now, since the patch has already been deployed. Ahmadtalk 12:36, 29 September 2019 (UTC)
Coming soon: FileExporter default on first wikis, making imports to Wikimedia Commons easier
The FileExporter and FileImporter extensions make moving files from a local wiki to Wikimedia Commons easier. Together they allow to move files with all their original data intact, while documenting the move in the version history. The feature originates in a top wish from the Technical Wishes survey on German Wikipedia.
The FileExporter, which lives on the local wiki, has been a beta feature on first wikis since June 2018, and on all wikis since January 2019. Currently, 15,000 people on the Wikimedia projects have activated the feature, and more than 12,000 files were imported successfully with this new tool. The first version from June 2018 was improved continuously, based on feedback by its beta testers. Thanks to everyone who gave feedback!
Now, the FileExporter will become a default feature on the first few wikis: de, fa, mr, ko Wikipedias and on the Wikisource for multilingual books (so called sourceswiki). This means that as an auto-confirmed user on these wikis, you'll see a link “Export to Wikimedia Commons” on local file pages. If you click on this link, the FileImporter then checks if the file can in fact be moved to Commons, and whether any replacements need to be made. These checks are performed based on the wiki’s configuration file which is defined by the local community.
The planned date for this deployment is September 24th, 2019. Deployment on more wikis is planned for later this year. As always, feedback on this feature is very welcome on this talk page. -- Best, Johanna Strodt (WMDE) (talk) 08:57, 23 September 2019 (UTC)
- Excellent news! -- Tuválkin ✉ ✇ 12:51, 29 September 2019 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Problems
- Last week's Tech News had delivery problems. Some did not get the newsletter. Some got it more than one time. The problem where some pages got it three times should now be fixed. [26]
Changes later this week
- The new version of MediaWiki will be on test wikis and MediaWiki.org from 1 October. It will be on non-Wikipedia wikis and some Wikipedias from 2 October. It will be on all wikis from 3 October (calendar).
Meetings
- You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 2 October at 15:00 (UTC). See how to join.
Future changes
- The Wikimedia Foundation Community Tech team is working on a watchlist expiry feature. This means you can put things on your watchlist for a period of time instead of forever. They are looking for feedback on the questions they have.
- Special:Contributions will get the standard OOUI look. This makes it easier to use on mobile and makes it look like other
Special:
pages. There is a script you can use to make the form smaller if you want to. [27]
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
16:49, 30 September 2019 (UTC)
FileExporter/FileImporter: Suggestions how to deal with files from wikis that have a higher amount of copyright violations
Hello, the FileExporter/FileImporter extensions make it easier to import files to Commons in a technically correct way. It was discussed on MediaWiki and Phabricator (T222445) how these two extensions should deal with files from wikis that have a high amount of copyright violations.
In the discussion, three ideas were suggested:
- Disable the FileExporter button "Export to Wikimedia Commons" for all users on a certain project.
- Show the button only to users with certain rights. (T232480)
- Make it easier for the Commons community to identify from which wiki imported files came. (T232481)
Disabling the export feature for all users on a project would mean that no Commons-compatible files could be transferred from there either, which is why the team behind the FileExporter/FileImporter would refrain from doing this. But the team can investigate if options 2 and 3 are doable. Could you please discuss which of these changes are wanted, and which aspects should be considered if these changes were implemented? -- Thanks a lot, Johanna Strodt (WMDE) (talk) 10:35, 13 September 2019 (UTC)
- Option #3. This is a universal problem on Commons. It would be easier for me to work on files from Iran and Afghanistan (or anything related to Persian "fa" language), so I regularly patrol Campaign:fa or User:OgreBot/fawiki images, but these capture only a small size of relevant files. Obviously I can't monitor User:OgreBot/Uploads by new users everyday and every hour. If you enable option #3, I will monitor files imported from fawiki. 4nn1l2 (talk) 11:06, 13 September 2019 (UTC)
- Why choose? Options 2 and 3 don't exclude each other. Option 3 is a no-brainer. Option 2 should be considered on a case-by-case basis, but I wouldn't rule it out. - Alexis Jazz ping plz 11:35, 13 September 2019 (UTC)
- I have an idea that requires no technical changes. Steps:
- Require all wikis that want to opt in to apply for an inspection from Commons volunteers. Commons vote on applications.
- Those that pass the inspection, can have their setup pages at mw:Extension:FileImporter/Data unprotected.
- Lock up setup pages (sysop-create-and-edit only) for all wikis that have failed or not applied. Make everything bad and nothing good on the setup pages.
- Criteria for pass would be: 1. local users check newly uploaded files regularly. 2. bad files are deleted in time regularly. 3. the effort does not rely on very few users, i.e. even if someone becomes inactive the work is still carried on smoothly.
- This does not prevent them from manually transferring or using commonshelper though.--Roy17 (talk) 22:54, 13 September 2019 (UTC)
- If it's preferrable to have a review process for imported files, I suppose it's not difficult to make the gadget automatically add {{BotMoveToCommons}} or something similar, which adds files into maintenance cats.--Roy17 (talk) 23:03, 13 September 2019 (UTC)
- I add a coment abut this issue at mw:Topic:V3ytxmfmk93xu7lg. In general, I do think that FileImporter is a good idea but need some modification.
- One of the issues I have mentioned there raised in MediaWiki talk:Gadget-AjaxQuickDelete.js#Notifying File Importers by Jeff G. and solved by Perhelion. I have also mentioned there a solution to #3. I do agree that some kind of template that gives the all the info saye something like: "This file was moved to Commons in DD/MM/YYYY by user:XYZ using FileImporter from en:File:ZZZZZ.jpg" or "This file originally uploaded to XX.wiki. It was moved to Commons in DD/MM/YYYY by user:XYZ using FileImporter from en:File:ZZZZZ.jpg". This at least, setting somehow the info about the history of uploading and importing of the file which is missing. I have created a basic template for my own imports (see File:Shlomo lorentz.jpeg). Also, the situation where the file was allegedly uploaded by an active user in Commons is simply not correct. The local wiki user must be linked to his local account.
- I agree with #2: specify certain user-rights which users on certain wikis need to have in order to use the extension to move files to Wikimedia Commons.
- Not sure about #1. Normally should be decition by Commons (Community-consensus) but problems of bad moves can be solved in other ways like limiting user rights (#2). -- Geagea (talk) 23:56, 13 September 2019 (UTC)
- I add a coment abut this issue at mw:Topic:V3ytxmfmk93xu7lg. In general, I do think that FileImporter is a good idea but need some modification.
- See also COM:VPP#Show the FileExporter's "Export to Wikimedia Commons" button only to users on other wikis with certain rights and COM:VPP#Make it easier for the Commons community to identify from which wiki FileExporter file transfers are coming using a template which applies maintenance categories. — Jeff G. ツ please ping or talk to me 12:31, 11 October 2019 (UTC)
I am inclined to disagree with option #1 (number one) because the fact that a person has acquired more user rights doesn't signify that they have more knowledge, and most certainly doesn't mean that they have more knowledge of copyrights and copyrighted materials. Also having a knowledge of how copyright works on a Wikipedia doesn't mean that they will understand “Commons:Licensing”, some Wikipedia's will basically accept anything (image-wise) because of fair use, which is great… for Wikipedia, but not for Wikimedia Commons, Wikimedia Commons is designed for absolutely free files (or at least free enough to re-use in any context), on the other hand limiting more users from transferring files isn't good. It should be easier to import files to Wikimedia Commons, but it should also be more easy to patrol these imported files. The Community TechBot should probably add daily or weekly galleries of new uploads PER WIKI so it’s easier to patrol what's coming in.
Also I often see good high quality own works on the Japanese- and Vietnamese-language Wikipedia's and would prefer to see those files imported to Wikimedia Commons, it's best to not limit users, it's odd but over the years I've seen a culture rise that is more centred around preventing content creation for the sake of "preventing" things (copyright violations, backlog, non-notable subjects, Etc.), it would be better to create more tools and options to patrol things, rather than trying to limit the people who can contribute, it's better to increase the tools and options for those patrolling the new content. The benefits always outweigh the risks. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 18:47, 11 October 2019 (UTC)
The "Show contributions of new accounts only" checkbox filter no longer appears on Special:NewFiles. Is this just for me, or has it been removed? Is there a way to restore it? (The "Newbies" button, which links to a wmflabs tool, remains, but is inferior to the new files gallery.) Эlcobbola talk 19:07, 4 September 2019 (UTC)
- @Эlcobbola: It appears to have been removed. :( — Jeff G. ツ please ping or talk to me 19:23, 4 September 2019 (UTC)
- [ec] @Elcobbola: It was removed for performance reasons, sorry. See m:Tech/News/2019/34 (posted a few sections up at #Tech_News:_2019-34). Using the "newcomers" and "learners" filters on Recent Changes for new File: creations will probably help (but doesn't show the thumbnail of the file, which is not quite as useful). Jdforrester (WMF) (talk) 19:26, 4 September 2019 (UTC)
- Well, that was a bad idea. Copyright violations will be hanging around a lot longer unless there is a tool to replace this functionality. World's Lamest Critic (talk) 20:21, 4 September 2019 (UTC)
- @World's Lamest Critic: As elcobbola mentioned, there is already a community-supported Toolforge tool which, unlike the removed functionality, doesn't take the site down. Jdforrester (WMF) (talk) 21:05, 4 September 2019 (UTC)
- Can you supply any examples of when that functionality "took the site down"? World's Lamest Critic (talk) 21:12, 4 September 2019 (UTC)
- @World's Lamest Critic: As elcobbola mentioned, there is already a community-supported Toolforge tool which, unlike the removed functionality, doesn't take the site down. Jdforrester (WMF) (talk) 21:05, 4 September 2019 (UTC)
- @Jdforrester (WMF): Thank you for the response, but is there anything to be done about this? I find "The secondary feature is rarely used, complicates the code, and massively complicates the user experience" [28] untrue ("Massively complicates the user experience" Really?) Being able to see images unloaded by new accounts is how I detect well over 90% of sockpuppets, which is a lot. And, I believe echoing per World's Lamest Critic above, I understand this actually to be a very commonly used method of copyvio detection ("The secondary feature is rarely used" Where are data on this? Rare relative to what?) Now, without a corresponding throttling of "established user" uploads (which I don't advocate), "newbie files" will disappear among the constant and voluminous bulk/script uploads. This seems an incredibly short-sighted and ill-informed change, especially without ensuring the existence of a reasonable alternative before the discontinuation. Эlcobbola talk 20:37, 4 September 2019 (UTC)
- @Elcobbola: Fair questions.
I made the determination from roughly eyeballing the request data; it was about 100000:1 (as in, I could barely find any uses of /newbies in the logs I briefly looked at).
I don't understand your comment about established users? The link I gave you for Recent Changes explicitly excludes them, as does the tool to which you linked (which is much more powerful in terms of setting arbitrary limits on what counts to you as a "newbie").
The core tool was removed because it kept breaking the site, and had no reasonable path to performance improvements that would make it stable enough to retain. In general, power tools support is carried out by the wonderful Community Tech team based on the community voting exercise each year (next time starting in a few months' time). However, even if it "won" a vote, that wouldn't get you a fix for many months. I'm not sure what path for solution I can offer, sorry.
Jdforrester (WMF) (talk) 21:05, 4 September 2019 (UTC)- @Jdforrester (WMF): You keep saying it "broke the site" but hasn't this functionality been around for years? Did something change to make it no longer acceptably efficient? And, as I asked above, can you give us some examples of when it "broke the site"? World's Lamest Critic (talk) 21:29, 4 September 2019 (UTC)
- @Jdforrester (WMF): As you noted, the recent changes link does not show the thumbnail of the file, which is the critical functionality (i.e., it is necessary to see the image to assess whether it is a recreation, has the traditional hallmarks of a copyvio, etc.); the newbies tool is, among others, a) based on edits, not account age; b) does not include resolution data; c) has smaller images (making visual judgments more difficult); d) is not in a gallery format (less dense, thus more cumbersome to use); and e) is on tools.wmflabs.org which, in my experience has been very unreliable in terms of both performance and availability, at least relative to proper project space. If the tool was poorly coded (I know nothing of code; I'm reading between the lines of the issues you seem to be having with it), why is the solution not to code it properly? I have a hard time believing a gallery of new files uploaded by accounts aged less than a week (or whatever time is deemed appropriate) would be difficult to create and to make stable based on functionality that exists and remains. How, for example, is the "Show uploads by bots," which remains, significantly different? If reliant on an account flag, couldn't the code just do the inverse--exclude all accounts that are autoconfirmed (automatically granted at 4 days) and implicit members of autoconfirmed users? Эlcobbola talk 21:35, 4 September 2019 (UTC)
- @Elcobbola: Details given by the Performance team at https://phabricator.wikimedia.org/T220447#5388610 as to the ways in which as a function it was unworkable (short version: the databases aren't designed for this kind of query, and we can't reshape them to make this one performant without breaking the performance everything else).
Adding a gallery view mode to Recent Changes is theoretically do-able but I don't think it's likely to work out well. I'm not sure whether Steinsplitter is actively maintaining the tool to which you linked; I suppose they could extend it to add a gallery view mode, and I'd be happy to help them in that.
Bot-flagged edits are encoded individually into the database so that we can do row-level operations against them, in a way that we cannot for account's relative "age". User flags/age/block status changes over time, but whether or not an edit/upload/etc. was bot-flagged is stored permanently and cannot be altered.
Jdforrester (WMF) (talk) 21:47, 4 September 2019 (UTC)- @Jdforrester (WMF): I wrote a dissertation on a manual typewriter, which tells you something of my vintage and familiarity with this stuff. That said, overgeneralising for what I am able to understand, is my understanding generally correct that the issue boils down as such: because NewFiles goes "to the beginning of time," asking it to sort out new users from established users for millions of files over more than a decade is too burdensome of a query (i.e., causes slowdown and/or timeout errors, etc.)? If so, given that there exist and remain a from and to date field (i.e., date limiting functionally is implemented), could the "Show contributions of new accounts only" option be made to tie into that and just force a, say, 30-day look back? Эlcobbola talk 22:10, 4 September 2019 (UTC)
- @Jdforrester (WMF): Thanks for the link. The task description doesn't mention performance and is based on the incorrect assumption that the functionality was seldom used. It appears your contention that it "breaks the site" is
bullshitunsupported by the evidence. Please rethink this change. I'm sure if you asked people about how they use it, you can find a way to do it more efficiently. World's Lamest Critic (talk) 22:15, 4 September 2019 (UTC)
- @Elcobbola: Details given by the Performance team at https://phabricator.wikimedia.org/T220447#5388610 as to the ways in which as a function it was unworkable (short version: the databases aren't designed for this kind of query, and we can't reshape them to make this one performant without breaking the performance everything else).
- @Elcobbola: Fair questions.
- Well, that was a bad idea. Copyright violations will be hanging around a lot longer unless there is a tool to replace this functionality. World's Lamest Critic (talk) 20:21, 4 September 2019 (UTC)
@Jdforrester (WMF): Nthep made a comment on Phabricator that seems to have been ignored. They told you the same thing we are telling you now. Why didn't you pay attention to that comment? World's Lamest Critic (talk) 22:21, 4 September 2019 (UTC)
- @Jdforrester (WMF): It's been about a week now. Are you coming back to discuss this? World's Lamest Critic (talk) 22:17, 11 September 2019 (UTC)
- @World's Lamest Critic: Sorry, discuss what? I responded carefully, and you swore at me and made statements that were totally inaccurate which showed that continuing wasn't productive. What more is there to say? Jdforrester (WMF) (talk) 15:09, 2 October 2019 (UTC)
- @Jdforrester (WMF): I neither swore at you nor do I believe I made any inaccurate statements. If you believe I did, you are welcome to point them out, but I don't think that will solve the problem we are discussing here. This change has removed functionality that facilitates detection of copyright violations, uploads of revenge porn, and uploads of child porn. You were alerted to this prior to the making the change but ignored the warning. It seems likely that any performance issues can be mitigated as elcobbola suggested above. That would seem to be a win-win solution. If the Newfiles search was limited to 30 days, would that solve the performance issue? World's Lamest Critic (talk) 19:49, 3 October 2019 (UTC)
- @Jdforrester (WMF): A week has gone by with no response. I can only assume you had no real intention of working with the community to address this. World's Lamest Critic (talk) 17:13, 10 October 2019 (UTC)
- @Jdforrester (WMF): I neither swore at you nor do I believe I made any inaccurate statements. If you believe I did, you are welcome to point them out, but I don't think that will solve the problem we are discussing here. This change has removed functionality that facilitates detection of copyright violations, uploads of revenge porn, and uploads of child porn. You were alerted to this prior to the making the change but ignored the warning. It seems likely that any performance issues can be mitigated as elcobbola suggested above. That would seem to be a win-win solution. If the Newfiles search was limited to 30 days, would that solve the performance issue? World's Lamest Critic (talk) 19:49, 3 October 2019 (UTC)
- @World's Lamest Critic: Sorry, discuss what? I responded carefully, and you swore at me and made statements that were totally inaccurate which showed that continuing wasn't productive. What more is there to say? Jdforrester (WMF) (talk) 15:09, 2 October 2019 (UTC)
- Info use this link to get a list of unpatrolled uploads by new users. MorganKevinJ(talk) 02:47, 19 October 2019 (UTC)
I will no longer be looking for copyvios or child porn
- @Jdforrester (WMF): @Elcobbola: It's been over two weeks now since you stopped participating in this discussion, leaving unanswered questions and abandoning what seemed like a promising proposal from elcobbola to alter Special:Newfiles to mitigate any performance issues. The "newbies" tool mentioned above does not provide the same functionality. OgreBot's galleries of uploads by new users is very useful, but still "a work in progress". Since you seem to have no desire to help me help the project (even to the point of responding to questions) I am no longer going to look for copyright violations or license issues in new uploads. That means I probably won't notice child porn uploads either (yes, I have found and reported a few in my short time here). I doubt this will make much of a difference to you, but it will make a difference to the project and it is the direct result of your decision. World's Lamest Critic (talk) 16:51, 23 September 2019 (UTC)
- Yeah, hopefully computers will do that job in the near future and we have just to undelete misidentified stuff. @Jdforrester (WMF): what are the plans on that? -- Rillke(q?) 00:46, 3 November 2019 (UTC)
- What a shit show. - Alexis Jazz ping plz 20:13, 19 November 2019 (UTC)
- @Jdforrester (WMF): @Elcobbola: It's been over two weeks now since you stopped participating in this discussion, leaving unanswered questions and abandoning what seemed like a promising proposal from elcobbola to alter Special:Newfiles to mitigate any performance issues. The "newbies" tool mentioned above does not provide the same functionality. OgreBot's galleries of uploads by new users is very useful, but still "a work in progress". Since you seem to have no desire to help me help the project (even to the point of responding to questions) I am no longer going to look for copyright violations or license issues in new uploads. That means I probably won't notice child porn uploads either (yes, I have found and reported a few in my short time here). I doubt this will make much of a difference to you, but it will make a difference to the project and it is the direct result of your decision. World's Lamest Critic (talk) 16:51, 23 September 2019 (UTC)
https://tools.wmflabs.org/newbie-uploads/ written on Toolforge by Steinsplitter in 2016 has been linked from where the checkbox used to be. EllenCT (talk) 08:54, 20 November 2019 (UTC)