Open main menu

Wikimedia Commons β

Commons:Village pump

Shortcut: COM:VP

Community portal
introduction
Help desk Village pump
copyrightproposals
Administrators' noticeboard
vandalismuser problemsblocks and protections
↓ Skip to table of contents ↓       ↓ Skip to discussions ↓       ↓ Skip to the last discussion ↓
Welcome to the Village pump

This page is used for discussions of the operations, technical issues, and policies of Wikimedia Commons. Recent sections with no replies for 7 days and sections tagged with {{section resolved|1=--~~~~}} may be archived; for old discussions, see the archives.

Please note


  1. If you want to ask why unfree/non-commercial material is not allowed at Wikimedia Commons or if you want to suggest that allowing it would be a good thing, please do not comment here. It is probably pointless. One of Wikimedia Commons’ core principles is: "Only free content is allowed." This is a basic rule of the place, as inherent as the NPOV requirement on all Wikipedias.
  2. Have you read our FAQ?
  3. For changing the name of a file, see Commons:File renaming.
  4. Any answers you receive here are not legal advice and the responder cannot be held liable for them. If you have legal questions, we can try to help but our answers cannot replace those of a qualified professional (i.e. a lawyer).
  5. Your question will be answered here; please check back regularly. Please do not leave your email address or other contact information, as this page is widely visible across the internet and you are liable to receive spam.

Purposes which do not meet the scope of this page


Search archives


 

Centralized discussion
See also: Village pump/Proposals • Archive

Template: View • Discuss  • Edit • Watch


April 23Edit

Wiki Loves FoodEdit

Curd Rice

Hello! After the successful pilot program by Wikimedia India in 2015, Wiki Loves Food (WLF) is happening again in 2018 and this year, we are going International. To make this event a grant success, your direction is key. Please sign up as a volunteer or sign up on behalf of your affiliate here.--Abhinav619 (talk) 08:46, 27 A

Anthroponym cats with unclear onomasticsEdit

There are >200 thousand subcats under Category:Uses of Wikidata Infobox with no family name. Anyone taking care of this? -- Tuválkin 19:18, 3 June 2018 (UTC)

  • I put some thoughts on bot-adding family names to Wikidata at [1]. I haven't had chance to look into that further yet, though. Thanks. Mike Peel (talk) 22:19, 3 June 2018 (UTC)
  • Unimpressive, sorry. Short-sighted regex juggling of incomplete data might be a nice addition to one’s coder portfolio, but it’s not the way to get actual content added. (Aint it “funny” how the supressing of wikitext because it enthrones geeks at the supposed expense of regular users ends up lionizing whoever can fiddle with data through a backport, bypassing a gamified, dumbed-down UI? The Wikidata way is spearheading that wedge between low-caste casual contributers and code gods, salting the middle grown whence the whole ecosystem of Wikimedia project grew! But I digress:) The way to have data added to Wikidata is, ironically and as usual, syphon it off from Commons whenever there’s any data to do so, usually mangling it on the way and locking the door for its further improvement (as it has been done with geolocation data for categories). -- Tuválkin 10:07, 4 June 2018 (UTC)
  • @Tuvalkin: I'm not trying to put together a coder portfolio or to demonstrate my (very limited) knowledge of regex. I'm trying to use the structured data format that Wikidata provides, and my (also limited!) knowledge of Python and pywikibot, to consolidate the information that has already been contributed to the Wikimedia projects so that editors don't have to repeat an edit that's already been made, in the hope that they can spend their time on contributing new information instead. Category:Uses of Wikidata Infobox with no family name tracks cases where the family name isn't set on Wikidata, which means that {{Wikidata Infobox}} can't provide an automatic DEFAULTSORT or add the category to the family name categories. However, that information is probably already available here through manually-defined DEFAULTSORTs and categories, but not in a format that can be used by the infobox here (or other infoboxes on other projects). Hence my why I'm trying to think of ways to use code to add that information to (and then extract it from) the structured database, so that we can focus on manually sorting out the more difficult cases. Thanks. Mike Peel (talk) 00:46, 5 June 2018 (UTC)
  • Well then, soon there will be a lot of new data ready for the harvest. -- Tuválkin 00:57, 5 June 2018 (UTC)
  • Or we could collaborate on ways to add (or encourage others to add) information once, and to then use that information more widely? You can clearly think through the ways that the data can be organised, could we either work together to do that, or avoid disparaging each others' work? Thanks. Mike Peel (talk) 01:24, 5 June 2018 (UTC)
  • Ah, collaborate: That’s what I (try to) do everyday here. Usually not by discussing would-bes and could-bes (as often done here) but by creating stuff others can build on (example) and/or adding my work to efforts initiated by others (example: any of so many things created by ). In the case at hand, it is needed some general knowledge about Onomastics worldwide and/or willingness to research it (got any? — add below). As for disparaging Wikidata and Structured Data in Commons, well, unless their underlying phylosophy changes radically, you can count on me for that also. -- Tuválkin 23:24, 8 June 2018 (UTC)
The bot was approved on Wikidata and is now running through the basic cases (label minus given name == family name) to add the family name property. Category:Uses of Wikidata Infobox with no family name is down from 232k entries by circa 2k entries, with many more to come. There was a bug with "Saint" that has now been resolved. Please let me know if the bot causes any problems, or if it is missing something, and I'll look into it. Thanks. Mike Peel (talk) 00:30, 16 June 2018 (UTC)
  • Coming August, if nobody does it sooner, I’ll be working on a new categorizing template that accepts as parameters each of a name’s constituent words and a flag to determine how they should be shuffled around for presentation, sorting, addressing, shortening / abbreviation, and categorization. Off the top of my hand, here’s some of those possible different ways of treating human idividual names:
    • Hungarian
    • East Asian
    • Russian
    • Portuguese
    • Spanish
    • Icelandic
    • French
(and probably more). -- Tuválkin 10:07, 4 June 2018 (UTC)
Having played around with two entries, I ran into problems with Dutch names containing a so-called tussenvoegsel like van (von in German and de/d’ in French). While it is part of a family name, it is disregarded for alphabetic sorting purposes: e.g. Category:Gijs van Aardenne is sorted manually as "Aardenne, Gijs van", but if it has to follow Wikidata, it will be auto-sorted as "Van Aardenne, Gijs" (to make things even more complicated, Belgian Dutch does sort it as "Van Aardenne, Gijs"). Please take this into account when working on the new template. --HyperGaruda (talk) 08:17, 9 June 2018 (UTC)
(!) "Two people who speak the same language and have the same name will sort next to each other" trumps pretty much all of this classic list IMO. Storkk (talk) 09:37, 9 June 2018 (UTC)

Warning! Mobile uploads are getting the wrong location!Edit

I've notified the app maintainer, but people should know--it looks like the Commons app is geotagging images with the phone's current location, not the media's geotagged location. This has been happening at least as far back as March; see VTA light rail station at Lockheed Martin Transit Center.jpg for an example. grendel|khan 20:53, 6 June 2018 (UTC) (Edit: since last October, at least.) grendel|khan 20:55, 6 June 2018 (UTC)

Hi, I don't see how it could be otherwise. The location is added automatically from the phone location, and there is no option to change it. Regards, Yann (talk) 20:57, 6 June 2018 (UTC)
@Grendelkhan: It seems in these two cases that the uploaders did not include GPS coordinates in their photos' EXIF metadata, so the app assumed upload location was good enough. Would you rather it not assume that?   — Jeff G. ツ please ping or talk to me 21:11, 6 June 2018 (UTC)
  • I think that is a poor assumption for geotagging. That must be why we so often get 20 pictures of a city all geotagged to one hotel or cafe! - Jmabel ! talk 22:52, 6 June 2018 (UTC)
  • Can we trust the geolocation capabilities of a phone/user combo whence a photo lacking gelocation is being uploaded? I’d say no. But in that rae case that some actually usable info comes that way, tag it in some easily spottable way, like a hidden cat. -- Tuválkin 00:27, 7 June 2018 (UTC)
  • I always set the phone's camera app to put the geotag into the photo, so the errors merely put the location across the street or with similarly small errors. When there's no geotag in EXIF, an upload location is usually better than none, but yes, there ought to be a note that this is the upload location, not the photo location. Jim.henderson (talk) 02:16, 7 June 2018 (UTC)
  • @Jeff G.: I was the uploader in all of the cases I linked. There's some kind of bug where the geolocations show up in Google Photos, but sometimes not as EXIF data in the JPEG files I share to the Commons app. (I'll follow up on that issue separately.) This would be an annoyance if the geodata was sometimes lacking, but this is a disaster; I have to go back through all ninety-odd mobile uploads so far and manually check them. Rather than leaving a blank sometimes, the app is actively inserting bad data--an unknown number of images uploaded via mobile have been essentially randomly geotagged. (I've used the mobile uploader to upload vacation pictures from the other side of the world after getting home.) Furthermore, this could very well silently be leaking the locations of users' homes without their intent. This would be understandable as a bug; it is tremendously misguided at best as a feature. grendel|khan 07:41, 7 June 2018 (UTC)
@Grendelkhan: So have you confirmed that the original photos you took with your Pixel XL and Nexus 5X were correctly geotagged and that you didn't tell the app not to share the correct geotags?   — Jeff G. ツ please ping or talk to me 08:08, 7 June 2018 (UTC)
@Jeff G.: The photos that were incorrectly located were not geotagged due to some kind of problem with my phone or Photos or something. It looks like if the EXIF data is present in the photo, the app sets the upload's location correctly, and if it's absent, the app sets the upload's location to the current location of the phone. The latter behavior is the problem; it should leave the location metadata blank in that case. grendel|khan 16:30, 7 June 2018 (UTC)
A further problem with the current policy: let's say someone uploads when they get home. Without their explicit consent, we are uploading the geocoords of their home. Similarly if someone deliberately omitted geocoords to keep a location confidential, and did an immediate upload, so the geocoords are correct, but were not deliberately uploaded. I think this, as it stands, is very bad policy. - Jmabel ! talk 16:34, 7 June 2018 (UTC)
Actually I believe that is Oversight-able offense from the app. — regards, Revi 16:36, 7 June 2018 (UTC)
I'll ping @Misaochan: We should probably have the developer in here as well. grendel|khan 16:38, 7 June 2018 (UTC)
Hi all, app maintainer here. If there is no GPS coordinates in the photos' EXIF metadata, the app should use the phone's location ONLY if TWO conditions are met: (1) the user has manually enabled "automatically get current location" in the app's Settings, and (2) the user has enabled the optional Location permission in Android. If either one of those conditions is false, the app should not be retrieving the user's current location, much less geotagging images with it. It is also worth noting that the "automatically get current location" setting should be disabled by default. Ergo, a user has to explicitly go to Settings and enable it, and then grant the app Location permissions, in order for this to happen. Could you please check and see if this is not the case for you? We will do a high-priority release to fix this otherwise. Misaochan (talk) 16:48, 7 June 2018 (UTC)
That 'automatically use current location' should come with a big warning that this will reveal your current location. While I’m not an oversighter, I think OSers often receive a request for removal of such data. — regards, Revi 16:56, 7 June 2018 (UTC)
@Misaochan: It is enabled for me--that's a relief, at least, that this isn't affecting everyone. The text under the option says 'Retrieve current location to offer category suggestions if image is not geotagged'. If this option automatically geotags untagged images with the phone's current location, it gives no indication of doing so. (Maybe the option is named something like 'use_current_location' internally, and the flavor text didn't keep up with the parameter's usage?) grendel|khan 17:10, 7 June 2018 (UTC)
grendel|khan and Revi, good point! We should certainly include a mention of the geotagging as well - indeed the text hasn't been updated to reflect that. Will push it through for the next release. Misaochan (talk) 17:27, 7 June 2018 (UTC)
@Misaochan: Thank you for the quick response! Given that the option, up until now, didn't say anything about geotagging photos, I think we should run a bot to remove location metadata from all mobile uploads which have geotags unchanged from their initial uploads and which don't contain EXIF data; in no case did a user tell the app to geotag those uploads, and the data is at best useless, at worst a privacy violation. Maybe there should be an announcement made somewhere as well? grendel|khan 17:38, 7 June 2018 (UTC)
Given that this is pretty clearly a privacy incident of unknown scope, I've escalated it to the admin noticeboard: Commons:Administrators'_noticeboard#Ongoing_privacy_incident_involving_the_Commons_Mobile_App.. grendel|khan 23:25, 7 June 2018 (UTC)
  • Just letting everyone know that we have released v2.7.2 to production on the Play Store with a hotfix that modifies the "automatically get current location" setting subtext to emphasize that it will reveal the user's location. As always, the setting should be disabled by default. If anyone is experiencing further issues with this, please let us know. Thanks for the report and the testing grendel|khan! Misaochan (talk) 08:37, 12 June 2018 (UTC)
    • I'm not sure if this is related, but I recently uploaded three pictures made shortly after oneother. I uploaded them as a group (File:De leyen bilthoven - 1.jpg, File:De leyen bilthoven - 2.jpg and File:De leyen bilthoven - 3.jpg) - which btw means that the app doesn't allow you to add a description, which is also annoying. When I checked the locations - something I or probably most people would rarely do anyway - I found the first one was correct but the second picture had been given the coordinates of the first and the third one was correct again. This really seems to be a bug in the app and not in my phone. --Joostik (talk) 19:06, 14 June 2018 (UTC)
Hi Joostik, thanks for reporting this. It's definitely a bug with the existing multiple upload implementation (via "Share"), we hope to solve it in the 2.9 release along with the implementation of proper multiple uploads from within the app. :) Misaochan (talk) 07:01, 15 June 2018 (UTC)
FYI: I'm trying to run a sysop bot for redacting location information caused by this issue. whym (talk) 13:11, 15 June 2018 (UTC)

File:Enchiridion geistlicher Gesänge 28.jpgEdit

and maybe more or even all files in Category:Enchiridion geistlicher Gesänge. The source's title is incorrect. It's not:

Enchiridion Oder eyn Handbuchlein, eynem yetzlichen Christen fast nutzlich bey sich zuhaben, zur stetter ubung unnd trachtung geystlicher gesenge, und Psalmen, Rechtschaffen unnd kunstlich vertheutscht. 1524 [books.google.com/books?id=5Ws9AAAAcAAJ]

but:

Eyn Enchiridion oder Handbüchlein. eynem ytzlichen Christen fast nutzlich bey sich zuhaben, zur stetter ubung unnd trachtung geystlicher gesenge und Psalmen, Rechtschaffen und kunstlich verteutscht. 1524 [cf. File:Enchiridion geistlicher Gesänge 01.jpg ]

w:en:Erfurt Enchiridion explains that there are two editions... -22:08, 6 June 2018 (UTC) —Preceding unsigned comment was added by 84.161.16.167 (talk) 22:08, 6 June 2018 (UTC)

June 07Edit

How many images are uploaded to Commons per day?Edit

Hi all

Is there any kind of counter of uploads per day?

Thanks

John Cummings (talk) 19:15, 7 June 2018 (UTC)

Wikimedia Commons started in September 2004, almost 14 years ago. It has now 47 million items, which means that over these years on average 9,400 items were added per day. Vysotsky (talk) 21:48, 7 June 2018 (UTC)
Make that a net average: many images are also deleted every day.—Odysseus1479 (talk) 23:42, 7 June 2018 (UTC)
There's https://stats.wikimedia.org/wikispecial/EN/TablesWikipediaCOMMONS.htm, column F. I'm not sure exactly what's included in "Articles new per day", but there are currently around 20k uploads per day. --ghouston (talk) 03:15, 8 June 2018 (UTC)
At that rate, we are due to hit 50 million uploads in about 135.6 days. That calls for a celebration!   — Jeff G. ツ please ping or talk to me 03:25, 8 June 2018 (UTC)
Mark it on the calendar, 21 October 18:00 UTC. --ghouston (talk) 05:48, 8 June 2018 (UTC)
I'll take the slight over on that. I'd bet some time in the evening of 24th of October. Storkk (talk) 14:50, 8 June 2018 (UTC)
Commons Growth

There is exponential growth of images on commons, but flatlining of editors, see: https://stats.wikimedia.org/wikispecial/EN/ReportCardTopWikis.htm#lang_commons . See also Special:MediaStatistics and Commons:Database_reports. --Atlasowa (talk) 09:37, 12 June 2018 (UTC)

I don't have a source but at some point last year I recall looking through the deletion logs and estimating that about 65,000 files had been deleted in a four week period. I'm not sure how many we delete now but the daily rate is probably around the 1,500—2,000 mark. Green Giant (talk) 10:36, 12 June 2018 (UTC)
@Green Giant: The daily file deletion rate is around 1,100—1,600 currently. --Atlasowa (talk) 21:22, 12 June 2018 (UTC)
@Atlasowa: near enough, give or take 400! :) —Green Giant (talk) 21:35, 12 June 2018 (UTC)

The EU Copyright Directive effect on Wikimedia projectsEdit

Hi all

As some of you may know there is a law being proposed in the EU that poses several threats to Wikimedia projects, Cory Doctorow has written an outline of how this law will effect Wikimedia projects.

There's also a discussion on Jimbo's talk page you might like to read/join.

Thanks

John Cummings (talk) 20:23, 7 June 2018 (UTC)

  • The EFF link isn’t loading for me (with Firefox). Anyone else experiencing the same? -- Tuválkin 13:34, 8 June 2018 (UTC)

See also german discussion (with links) here: Commons:Forum#DSGVO_..._Auswirkungen_auf_Wikimedia_Commons,_KUG_und_Co. Sorry that is about the data protection directive. --Atlasowa (talk) 08:56, 12 June 2018 (UTC)

Houston, we have a quality problemEdit

Stumbled across 2 year old vandalism around the Popes [2] in Turkish and German, partly removed the next day, but remains kept for more than 2 years now. I do not want to blame anybody, but if the user who created that vandalism is globally blocked, is there any idea on how to check his or her edits on all wikis more accurately? At least 5 users could have seen the problem with the gallery. Luckily, only few people ever view gallery pages [3]. best --Herzi Pinki (talk) 23:26, 9 June 2018 (UTC)

The "Global contribs" link at the bottom of Special:Contributions/Coconaut is helpful for this. --bjh21 (talk) 11:31, 10 June 2018 (UTC)
this was not a technical, but an organizational remark. --Herzi Pinki (talk) 16:32, 10 June 2018 (UTC)
@Herzi Pinki: guc has been mighty slow lately. :(   — Jeff G. ツ please ping or talk to me 18:31, 10 June 2018 (UTC)

June 10Edit

Implausible License InformationEdit

Is there any kind of process to challenge licenses provided by an uploader I deem unlikely to have the necessary rights to do so? --Abderitestatos (talk) 02:25, 10 June 2018 (UTC)

  • You could ask the user first, but it's OK to go directly to nominating for deletion. Often, it's best to do just one or two images first as test cases. - Jmabel ! talk 03:40, 10 June 2018 (UTC)
But is there no place to evaluate a license before discussing about deletion (again)? --Abderitestatos (talk) 22:34, 14 June 2018 (UTC)
@Abderitestatos: As I said, you could ask the user first. - Jmabel ! talk 23:17, 14 June 2018 (UTC)
But in this case it was not really the uploader who provided the license, he just adopted the license information given by a collection’s website, whose operators seem to put their items by default under a cc-license, even when the creator is unknown, or when copyrights obviously have expired. --Abderitestatos (talk) 13:04, 15 June 2018 (UTC)
The uploader is the one who is responsible to the Commons community. When you upload here, you are implicitly saying you believe the image is within Commons scope in all respects, including that it is either public domain or sufficiently freely licensed.
@Abderitestatos: If you don't think the uploader will have any particular insight, an believe they were taken in by copyfraud, as I said, it is your prerogative to head directly into the deletion process without first consulting the uploader. Of course, you could be more specific here so that there is some chance to discuss the substance of the matter. But as long as all you are saying is a generic statement that there are some files on Commons that you think have copyright problems, all anyone here can do is to give you generic advice. - Jmabel ! talk 16:11, 15 June 2018 (UTC)

June 11Edit

File:Vvedenskoye House.jpgEdit

If someone knows the license of this image, please feel free to pass or fail it. Thank You, --Leoboudv (talk) 06:35, 11 June 2018 (UTC)

Tech News: 2018-24Edit

21:55, 11 June 2018 (UTC)
  • «The MonoBook skin was changed to make it work better for mobile users. This caused some problems. The change was rolled back to fix them. The new version is now back on the wikis. MonoBook users can opt out from the new responsive design.» You guys understand that if this was the synopsis for a lampooning of certain tendences in web development these days it would have to be toned down because it would feel over-the-top even for the most staunch opponents — and yet, here it is: Reality funnier/scarier than any satire. -- Tuválkin 00:02, 12 June 2018 (UTC)

June 12Edit

Crop tool down?Edit

Is it? https://tools.wmflabs.org/croptool/ -- Tuválkin 18:20, 12 June 2018 (UTC)

  • Seems to be. - Jmabel ! talk 01:32, 13 June 2018 (UTC)

Cannot display updated thumbnail on WP pageEdit

I corrected an existing file and uploaded it to be used on the WP page Transverse Ranges File:SoCal Transverse Ranges.svg.

I had to try updating a few times but it worked, so the new figure can be seen from the WP page if I click it. But, the thumbnail didn't update and I can't figure out how to correct that. Any help? --BrucePL (talk) 18:59, 12 June 2018 (UTC)

The thumbnail updated spontaneously. I guess it takes time. --BrucePL (talk) 19:31, 12 June 2018 (UTC)

@BrucePL: I doubt it. I did purge. --jdx Re: 19:43, 12 June 2018 (UTC)
Thanks @Jdx --BrucePL (talk) 00:42, 13 June 2018 (UTC)

Update on page issues on mobile webEdit

CKoerner (WMF) (talk) 20:58, 12 June 2018 (UTC)
  • @CKoerner (WMF): Why was this posted here in Commons too? Are you working in any of our warning templates here? Which ones? -- Tuválkin 21:50, 12 June 2018 (UTC)
  • Hi @Tuvalkin: I posed here as Commons uses message box templates like {{mbox}} and {{ambox}}. The focus is on English Wikipedia at the moment, but whatever effort the Readers web team makes in better formatting for templates on mobile will be able to be used by all projects. CKoerner (WMF) (talk) 14:34, 13 June 2018 (UTC)
  • Thanks, @CKoerner (WMF): I added Template:Mbox to my watchlist (ambox is a redirect to it). Beware: it is heavily transcluded! I suppose that the changes for mobile visibility will not affect the layout as it is displayed now. -- Tuválkin 18:04, 13 June 2018 (UTC)

June 13Edit

Help needed with translationEdit

Template:PD-1996-text is running out of Lua memory (whatever it is) and we are in the process of moving the translations from Template:PD-1996-text {{LangSwitch}} based template to Template:PD-1996-text/i18n translation extension based template. We moved so far English, German, Polish and Hungarian text. If you speak other languages please help by translating text in Template:PD-1996-text/i18n to your language or by moving (and verifying) translation from Template:PD-1996-text. Thanks --Jarekt (talk) 12:47, 13 June 2018 (UTC)

✓  Done for French. Yann (talk) 13:54, 13 June 2018 (UTC)
Thanks, We still need about 10 translations moved by people who know the languages. --Jarekt (talk) 14:14, 14 June 2018 (UTC)

Which wiki project best for old Mayan archeology material?Edit

An acquaintance reached out to me for help in disseminating some photographs she made of archeological survey maps of Mayan sites and a monograph about Mayan archeology. The works are in public domain because they were created in the 1930s and published without copyright notice. There are actually two works she digitized, via photographing the pages with a camera:

1. The Inscriptions of Peten Volume 4, by Sylvanus Griswold Morley, published 1938 This is mostly text, so perhaps Wikisources would be a better project to submit this to?

2. The Inscriptions of Peten Volume 5 Part 2, by Sylvanus Griswold Morley, published 1937 Mostly very oversized plates with maps on it. The person who digitized it unfolded the maps and photographed them from above. She made overall photos showing the entire map, then individual close-up shots showing details.

(Note: She wrote some additional copy about her process and how the individual images relate; she is prepared to give any creative common license necessary to cover her own contribution of these few explanatory paragraphs and of the photography.)

Here is a link to volume 1 in this series to give an idea of what type of work this is: https://babel.hathitrust.org/cgi/pt?id=mdp.39015019759706;view=1up;seq=51

Note that the person who did the digitization is not a professional photographer. She studies Mayan hieroglyphics and was frustrated that these 2 volumes have not been digitized and made available online, so she was scratching her own itch. The hope is that the historical/scholarly importance will outweigh any technical imperfections. The maps are combined into a single pdf though I have reached out to see if she can provide the separate files of individual photographs. She no longer has access to the volumes so there can be no do-overs.

So: 1) Should both of these works go straight to Wikisources?

2) Should the monograph (vol 4) go to Wikisources and the maps (vol 5.2) go here to Commons?
— Preceding unsigned comment added by Eve Teschlemacher (talk • contribs) 23:15, 13 June 2018 (UTC)

(Sorry, forgot to sign original.) My acquaintance says she has original files but they are "a mess" with different scales and foreshortening. I assured her that those still have value and that a skilled photo editor could work with them. —Eve Teschlemacher (talk) 23:32, 13 June 2018 (UTC)

  • Yes, absolutely. Bring it over! -- Tuválkin 23:39, 13 June 2018 (UTC)
  • Since they are photographs, both should be uploaded to Commons first. Wikisource only hosts readable texts, that is to say: the text has to be typed out digitally, a proces called proofreading. --HyperGaruda (talk) 02:39, 14 June 2018 (UTC)
  • English Wikisource also hosts works that are PD in the US but not in their source nation.--Prosfilaes (talk) 02:52, 14 June 2018 (UTC)

Anti-Arpitan vandalism in WikidataEdit

Our Category:Arpitan/Francoprovençal is transcluding d:Q15087 to state that this minority Romance language is an «Instance of Chino mandarin» — which, I fear, is a form of xenophobic insult some some bigot’s addled perspective. Now, some questions:

  1. How can it be reverted or corrected?
  2. How can the culprit be identified?
  3. How can other such cases be detected?
  4. How can further such cases be prevented?

-- Tuválkin 23:20, 13 June 2018 (UTC)

  • From what I can tell, at the moment all languages are instances of Chino mandarin...someone renamed the language Wikidata item. Cookies4ever (talk) 23:39, 13 June 2018 (UTC)
  • It’s d:Q315, but its history page is not clear for me. Was it this diff? -- Tuválkin 23:58, 13 June 2018 (UTC)
  • @SandraF (WMF): Any thoughts? -- Tuválkin 00:01, 14 June 2018 (UTC)
  • No, apparently Wikidata has several items for language (no clue why). In this case someone edited d:Q34770. I fixed it and the other edits by the IP seem to have been undone as well so everything should be fine again. Cookies4ever (talk) 00:13, 14 June 2018 (UTC)
  • It looks like some languages, e.g. French, make a distinction between language as a means of communication (langage) and language as a dialect (langue, "tongue" as in mother tongue). --HyperGaruda (talk) 02:33, 14 June 2018 (UTC)
  • More like "speech" (s.l.) v.s "language", but we digress. -- Tuválkin 07:04, 16 June 2018 (UTC)
  • Wikidata uses ORES for vandalism detection. Like many other Wikidata editors, I myself have (in my volunteer capacity) many 10s of thousands of Wikidata items on my watchlist and check those daily (I think I catch and correct one instance of vandalism via my watchlist every two days on average), and I keep a watchful eye wherever I see Wikidata items integrated in our other projects and in external websites. Thanks for catching, flagging and correcting this! SandraF (WMF) (talk) 07:25, 14 June 2018 (UTC)
  • @SandraF (WMF): So, this is not a bug of Wikidata, but a feature? Therefore any transclusion from Wikidata into another project (in the form of infoboxes and stuff) is a Trojan Horse for all kinds of abuse, one that needs 3 experienced users to track down and revert. Truely enlightening. -- Tuválkin 13:03, 14 June 2018 (UTC)
  • Okay. -- Tuválkin 07:04, 16 June 2018 (UTC)
  • I dunno... perhaps I was just more dense than normal, but I remember wasting over an hour trying to figure out why the Wikipedia Android app was calling someone a "moutineer" and how to change it. This is despite me being relatively familiar with Wikipedia, and a reasonably technical person. Had I not been so irritated, I would have given up much earlier. Storkk (talk) 09:14, 16 June 2018 (UTC)
  • The Trojan Horse analogy is may be slightly over-the-top, but I think it's undeniably true that false claims that would otherwise be immediately reverted as test edits or vandalism, because they stem from a Wikidata item, can last for years. Presumably, this is because first finding the source of the error and then fixing it is such an obscure and difficult process. I still can't figure out why I was recently unable to update an image on Wikidata before deleting the old one as a duplicate. I spent about 10 minutes trying, noting that I was not blocked, the page didn't seem protected, and I could edit some things just not the image, then gave up and told a bot to do it. I would have spent less time and just washed my hands of the situation had not a huwiki article been somehow pulling the image from Wikidata, so I could not fix the huwiki article without finding and fixing the wikidata item. When things go right, it seems almost magical... when things go wrong, it feels byzantine and purposely obscurantist. Storkk (talk) 10:31, 16 June 2018 (UTC)

June 14Edit

Weird Error MessageEdit

Last couple of days - everytime I hit edit, I get an error message (below) slide in from right. I've changed nothing that I can see. Everything still works...

Error:
https://commons.wikimedia.org/w/load.php?debug=false&lang=en-gb&modules=ext.3d%2CCodeMirror%2Ccharinsert%2CeventLogging%2CnavigationTiming%2CwikimediaEvents%7Cext.CodeMirror.data%2Clib%7Cext.CodeMirror.mode.mediawiki%7Cext.centralNotice.geoIP%7Cext.centralauth.ForeignApi%7Cext.centralauth.centralautologin.clearcookie%7Cext.echo.api%2Cinit%7Cext.eventLogging.subscriber%7Cext.math.editbutton.enabler%7Cext.uls.common%2Ccompactlinks%2Ceventlogger%2Cinit%2Cinterface%2Cpreferences%2Cwebfonts%7Cext.visualEditor.desktopArticleTarget.init%7Cext.visualEditor.supportCheck%2CtargetLoader%2CtempWikitextEditorWidget%2Ctrack%2Cve%7Cext.wikimediaEvents.loggedin%7Cjquery.accessKeyLabel%2CcheckboxShiftClick%2Cclient%2Ccookie%2CgetAttrs%2ChighlightText%2ClengthLimit%2CmakeCollapsible%2Cspinner%2Csuggestions%2CtextSelection%7Cjquery.makeCollapsible.styles%7Cjquery.uls.data%7Cmediawiki.ForeignApi%2CRegExp%2CString%2CTitle%2CUri%2Capi%2Ccldr%2CconfirmCloseWindow%2Ccookie%2Cexperiments%2Cicon%2CjqueryMsg%2Clanguage%2Cnotify%2CsearchSuggest%2Cstorage%2Ctemplate%2Ctoolbar%2Cuser%2Cutil%7Cmediawiki.ForeignApi.core%7Cmediawiki.action.edit%7Cmediawiki.action.edit.collapsibleFooter%2CeditWarning%7Cmediawiki.api.options%7Cmediawiki.language.data%2Cinit%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.ready%2Cstartup%7Cmediawiki.page.watch.ajax%7Cmediawiki.template.regexp%7Cmediawiki.ui.button%7Cmediawiki.widgets.visibleLengthLimit%7Coojs%2Coojs-ui-core%2Coojs-ui-widgets%2Csite%7Coojs-ui-widgets.styles%7Coojs-ui.styles.icons-editing-advanced%2Cicons-editing-styling%2Cicons-moderation%2Cicons-movement%7Cschema.UniversalLanguageSelector%7Cskins.monobook.mobile%7Cskins.monobook.mobile.echohack%2Culs%7Cuser.defaults%7Cwikibase.client.action.edit.collapsibleFooter&skin=monobook&version=1n6m8l6 at line 6: TypeError: $button.toggleClass(...).data(...) is not a function

Ronhjones  (Talk) 16:21, 14 June 2018 (UTC)

Does not happen on other wikis. Ronhjones  (Talk) 16:26, 14 June 2018 (UTC)
I reported this some days ago: phab:T196512. Maybe you can give some more details about which settings you are using. -- User: Perhelion 16:30, 14 June 2018 (UTC)

June 15Edit

Wikimedia Commons app {Explore/Search Feature}Edit

Hi everyone, I am a Ujjwal, contributor from Commons Android App team. As a part of my internship project, I was working on search images feature in Commons app in Phase 1 of my Internship(GSoC 2018). I am attaching a prodDebug APK for the same. Feel free to create an issue regarding any bugs or feature request that you have at our GitHub repository. APK Link: https://drive.google.com/file/d/1THe_I3PRixktLQcOSMMvzymLhHN6_ERq/view?usp=sharing --Ujjwalagrawal17 (talk) 10:58, 15 June 2018 (UTC)

In other words, we can now browse Commons media from the app :-) Just install the APK linked above on your Android phone and enjoy! (if you have Commons installed already, you must uninstall it first) Syced (talk) 11:05, 15 June 2018 (UTC)

SVG validationEdit

I noticed some changes in the W3 SVG validator; a lot of files that were considerd valid in the past generate now the message "Sorry! This document cannot be checked." For example this:

--Carnby (talk) 16:27, 15 June 2018 (UTC)

Seems to be a bug in the W3C validator per this error message:

Error External Checker not available Checking the Document Type of this document requires the help of an external tool which was either not enabled in this validator, or is currently unavailable. Check in the validator's system configuration that HTML5 Validator is enabled and functional.

The error encountered was: 403 Forbidden

--Sebari – aka Srittau (talk) 16:44, 15 June 2018 (UTC)
@Carnby: Adding DOCTYPE declaration solves the problem:<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">. However it solves it partially because now the validator reports errors related to RDF – AFAIR earlier version(s) of the validator reported these issues as warnings. Anyway, I've uploaded manually fixed, valid version. --jdx Re: 07:40, 16 June 2018 (UTC)

June 16Edit

Category:Historical agricultural equipmentEdit

@Witia: I notice this category and a complete matching set was created recently. Why is it useful? Surely everything becomes historical? Do we have a date like 2015 and events before that or images taken before that date are regarded as historical? Eddaido (talk) 01:42, 16 June 2018 (UTC)

And the same with Category:Historical images of ploughs. What happens when we move into the 2020s. Won't 2018 images need to be moved to historical? Eddaido (talk) 02:12, 16 June 2018 (UTC)

  • Yes. That’s why I avoid such terms when creating new categories. Usually, cats named Category:History of Soandso however include things like Category:2018 in Soandso down to Category:1234 in Soandso, etc. A simpler way to put it is Category:Soandso by date, but simetimes there’s media to justify both categories (with Category:History of Soandso as the parent of Category:Soandso by date). -- Tuválkin 07:01, 16 June 2018 (UTC)

請求快速刪除Edit

✓  DeletedYann (talk) 04:31, 16 June 2018 (UTC)

Kitagawa Utamaro's "Mother and Child" offeringEdit

I am not sure of the Japanese title of the image; this artist did multiple artworks on this subject. The print I have (and have scanned) is of a woman holding a red baby and a pipe and exhaling smoke. The print I had would not fit on my scanner bed and is thus done in four parts which will need to be stitched together and used to eliminate process artifacts.

Each image is a little less than 5100×7000 pixels and has significant overlap, so the final image would be a bit larger than that. To compare to a small version hosted online (actually the only copy I could find with a quick shallow search), see http://player.slideplayer.com/14/4427142/data/images/img54.png (340×504 but that site allows download of a .ppt with embedded 754×1166 version). Obviously a museum-quality scan would be best, but this would allow a filename over which such a file, if later found, could be written.

Is there any interest in this? Arlo James Barnes 20:47, 16 June 2018 (UTC)

  • Yes, this would be welcome. - Jmabel ! talk 09:17, 17 June 2018 (UTC)

June 17Edit

Moving from Commons to en:WikipediaEdit

Plenty of files are moved from en:Wikipedia (or other Wikipedias) to Commons. What about the reverse direction?

Most or all of the contributions by ACTVR appear to be carefully and praiseworthily edited versions of copyright material. If I'm right, they should be deleted from Commons. I've put up one for deletion, saying so. (No response yet.) For at least one of them, I can immediately see a beneficial and legitimate use at en:Wikipedia. I tried uploading it, under a different filename, to en:Wikipedia (of course with a "fair use" rationale). This turns out to be impossible (the server detects that the file is a duplicate). I've described what I did and what didn't happen at en:Wikipedia, asking for suggestions. (No response yet.) Any ideas? -- Hoary (talk) 06:26, 17 June 2018 (UTC)

I uploaded File:Ruston_&_Hornsby_logo.png as en:File:Birmingham_Small_Arms_Company_logo1.png (under wrong name actually) without any problem. Ruslik (talk) 20:05, 17 June 2018 (UTC)
I uploaded File:MPP_logo.jpg as en:File:MPP_logo_foo_foo.jpg without any problem. The error I got when when I tried with just en:File:MPP_logo.jpg was that the filename was too short/nondescriptive, not that the file was a dup. DMacks (talk) 20:25, 17 June 2018 (UTC)
Well that is odd. But thank you to both of you. ¶ I'm not so well-versed in Commons. Is demotion from Commons to a Wikipedia for reasons such as this a common occurrence; and if it is, can it be (part-) automated in some way? -- Hoary (talk) 22:42, 17 June 2018 (UTC)
Incidentally, I've undeleted en:File:MPP_logo_foo_foo.jpg, provided it with a pile of justificatory small print, and moved the result to en:File:MPP-logo.jpg, a filename that of course is no longer or more descriptive than the one you, DMacks, had tried but failed to give it. I encountered no problem in doing this. I now have to attend to my paid job, but a few hours from now I'll do something similar for currently deleted en:File:Birmingham_Small_Arms_Company_logo1.png. -- Hoary (talk) 22:49, 17 June 2018 (UTC)