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.
Changes in Translatewiki are in the moment only updated here once a week, but do not ask me about the specific date. — Speravir– 04:19, 1 February 2019 (UTC)
This is none of your business. If a contributor wishes to obscure, or even lie, about their physical location, they are free to do so and we should presume they have good reason to do so. Please respect the privacy of others, your badgering has crossed the line into harassment. --Fæ (talk) 14:47, 31 January 2019 (UTC)
What means a “native American”? Certainly the USA isn’t China, Australia, or Russia, but yet there are many nations established for generations and different from the Anglo-Saxon plurality. Incnis Mrsi (talk) 18:17, 31 January 2019 (UTC)
This was a confusing thread. Typically, in English "Native American" means "indigenous peoples of the United States", and neither "natural born citizen of the United States" nor "native English speaker". Also, those two categories have less than 100% overlap, and there are several million people in the US who do not speak English as a first language, or at all. GMGtalk18:32, 31 January 2019 (UTC)
So what if 1989 is an undocumented Mexican immigrant? Or dyslexic? Or a jar of peanut butter? What difference does it make? - Alexis Jazzping plz15:34, 1 February 2019 (UTC)
What app produces shit like this? I can see more and more of it. It makes patrolling recent changes harder, so I think the author(s) should be informed about the problem. --jdxRe:10:25, 26 January 2019 (UTC)
@Roy17 and Jdx: I do not think that this is the solution. Note that for all templates using {{TemplateBox}} there is the recommendation to use the parameter useTemplateData with value 1(true) or even only. {{Information}} makes use of it, already before your changes, Roy. I see that the linked edit is a recent one, but I know that derivativeFX had this kind of issue in the past (it also added a second date parameter If I remember correctly). — Speravir– 01:22, 2 February 2019 (UTC)
The issue was the info template became inline, (I think) because the user was using Visual edit, and the doc page did not specify which format to use such that the format was inline by default. My solution was to specify block in its templatedata, so that the visual editor would automatically spread the template out.--Roy17 (talk) 02:12, 2 February 2019 (UTC)
Yes. I know (now). Your TemplateData wasn’t used at all, I had checked this – but the dedicated parameter I just added, neither … — Speravir– 03:34, 3 February 2019 (UTC)
-- Fæ Hello and thanks for the ping! The giveaway program was paused during the winter so the team could focus on the Fundraising campaign. Feel free to add any new nominations to the giveaway page as we have started to catch up.
How can a user add one regular category, and 4-5 hidden categories, using Upload Wizard? No info found by google. It is a multiple pictures upload, 100's of pictures. How to do the same, using Commonist? --Janwikifoto (talk) 17:49, 1 February 2019 (UTC)
Hidden categories are added the same way as regular categories. If your batch of images shares all or most of the same categories, you can enter the categories on the first image in Upload Wizard, then copy them to all subsequent images. You can create new hidden categories by adding {{Hiddencat}} to the category page. You might also use Cat-a-lot to add files to categories after they've been uploaded. --Animalparty (talk) 19:40, 1 February 2019 (UTC)
Not working when I test. Upload file does not create Hidden categories, but regular categories. Someone will manually have to over it. Upload wizard does not accept another catgory, after the first that does not exist. (Yeah, we could create categories first, but...) --Janwikifoto (talk) 20:13, 1 February 2019 (UTC)
Instead of [[Category:Https://commons.wikimedia.org/wiki/Category:Community driven project Melodifestivalen 2019 funded by Wikimedia Sverige]], try [[Category:Community driven project Melodifestivalen 2019 funded by Wikimedia Sverige]]. The easiest way is to finetune a test file and then use it as a template for the others. — Racconish💬21:21, 1 February 2019 (UTC)
@Jmabel: On the Russian, Ukrainian, Spanish, and Portuguese Wikipedias the file I want to change is in the templates (portal, discussion etc.) and I couldn't change the templates because I couldn't find them. Moreover, I connect to the VPN because I live in Turkey and I can not change in the Russian and Dutch Wikipedias. - Ullierlich (talk) 06:03, 3 February 2019 (UTC)
@Ullierlich: Can you at least give links to pages where this appears so someone can follow up & work out where it is coming from? I don't see any obvious use on those Wikipedias. - Jmabel ! talk`
Please check out "User:Alexis Jazz/DWDD archief" where there are multiple videos whose licenses used to be Creative Commons but have recently changed, as this is from television programme which often features Dutch celebrities many of its images are used on the Dutch-language Wikipedia. Historically Jan Arkesteijn uploaded a lot from this source but since his block uploads have this less steady. I'm pinging @Alexis Jazz: so he could better explain it, but this is a rather high profile television programme which runs on a Dutch government channel and features some rather high profile individuals.
And many videos haven't been uploaded (yet), but the YouTube URL and the license that was found at Bing can be found there. But a license reviewer or administrator needs to confirm that. (unless I fucked up it's 100% accurate) By the time we have sifted through what to upload, Bing will have lost many licenses. They disappear as we speak. - Alexis Jazzping plz21:37, 2 February 2019 (UTC)
I wanted to add a category to an image with a bothy. The English Wikipedia gives a link to 11 other Wikipedias and to Commons for Category:Bivouac huts. That category has a link to itself and to the category Bivacchi on the Italian Wikipedia. How do I get also the links to the Bothy pages? Wouter (talk) 08:29, 3 February 2019 (UTC)
Thanks. I added in Mountain huts in the United Kingdom the links to the 12 Wikipedias and added in the English and Dutch WP a Commonscat to link to that category. It is remarkable to see that in the French WP there is also a link to the Commons category “Huts in Africa”, in the Swedish WP a link to “Wilderness huts in Finland” and in the Spanish WP a link to the page “Dry stone cabins” with images about huts in France and Spain. Wouter (talk) 08:06, 4 February 2019 (UTC)
UK National Archives Flickr
Doing an upload run from this Flickr Commons account, I noticed https://www.flickr.com/photos/nationalarchives/8517400481 and several other images in the stream, have what appear to be encoded files in the description text. Could some take a look and advise what this is about.
I might have not paid much attention, but I am getting a lot of of files rejected by the API with "verification-error: This file contains HTML or script code that may be erroneously interpreted by a web browser." --Fæ (talk) 16:15, 4 February 2019 (UTC)
There is an online museum named the Hitler Historical Museum which hosts a lot of sketches and painting by Adolph Hitler (or "Adolf Hitler"?) with many documents and other works related to his life. I have quite a very long list of things to import so I don't have the time to import from this website, but as there might be other people interested here in preserving this history I am sharing this here for anyone interested to import.
By the way, maybe it would be an idea 💡 to organise websites which contain lots of free content and content in the public domain somewhere on Wikimedia Commons and divide it per topic (for example this could fall within the subject of "Politics" or "the 20th (twentieth) century"). There must be a good way where people can share links to free websites with useful educational content so people on Wikimedia Commons can collaborate to watch and import from them. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 17:48, 4 February 2019 (UTC)
Please, please, please: be VERY RELUCTANT in attributing paintings to Hitler. Only a handful of paintings are known to be from Hitler, many hundreds, if not thousands, are FAKE. I don't think Wikimedia Commons should at this point in time want to upload any picture of a piece of art by Hitler if it's not hundred procent sure it's his – many research has still to be done, and it will most likely never become clear in the end. For dutch readers: read this article. Please, Donald Trung 『徵國單』, do not upload any of the pictures from that site. Jürgen Eissink (talk) 18:00, 4 February 2019 (UTC).
Complicating on this point is that there are hardly any, if any it all, experts on the subject, so the basic line in my opinion should be: don't trust any source, especially if they have something to gain, and stay far from the subject anyhow. I doubt whether there are contemporary photographs of his real work. Jürgen Eissink (talk) 18:09, 4 February 2019 (UTC).
Many attention to this subject has been brought the last year by Dutch poet and researcher en:Bart FM Droog. Many articles have appeared the last months, like this one in WaPo, and last week in Berlin 3 fake Hitlers were seized by German police (many articles worldwide, f.i. this). The subject is hot, don't let Commons get burned. Jürgen Eissink (talk) 18:19, 4 February 2019 (UTC).
@Donald Trung: It’s spelled with an "f". Only English and French spellings cling to that romanization of Greek "φ" (apart from Latin itself). This case is even simpler, as this name is Germanic in origin, being spelled originally (if at all) with a Runic "ᚠ" — see en:Adolf. -- Tuválkin✉✇06:35, 5 February 2019 (UTC)
Here is an example of a file which Flickr-to-Commons will not upload creating a block of red with the note at the bottom left, "Flinfo says 'bad user'"
https://www.flickr.com/photos/hugo90/44169474901
In the last hour I have had three others like this. I have been uploading Flickr images from this photographer for almost ten years. When I go to Flinfo I can't find him on the banned list. Flinfo seems to apply only to users of Flinfo, this is Flickr-to-Commons. Is there something I'm missing? I know I can be slow. Thanks, Eddaido (talk) 04:16, 5 February 2019 (UTC)
Thanks, that'd be great. Commons holds 5,631 images by him and 228 by Vetatur Fumare (10047629@N04). I'm anxious to get two by Vetatur Fumare, will the block be avoided by uploading those images with Upload Wizard? Eddaido (talk) 06:02, 5 February 2019 (UTC)
In these cases, I suggest to be bold and move the files to the correctly named category. Just don't forget to create a category redirect. --MB-one (talk) 14:04, 5 February 2019 (UTC)
Wayback Machine archive links
Medieval brooch from PAS, uploaded today with Wayback Machine link.
Good news everyone!
The very large upload project importing photographs of British treasure trove from the Portable Antiquities Scheme (PAS) database, has become the first major batch upload project (as far as I'm aware) to ensure that the source web pages are available at the Internet Archive before uploading to Commons. The Internet Archive Wayback Machine is an independent archive of web pages and content, with a 100 year archive strategy. As of today, Wikimedia Commons hosts over 480,000 photographs from PAS.
A major benefit of taking this extra step of precautionary independent archiving of live sources, is that should the source website later suffer from link rot or be taken offline, we have a high level of confidence that the copyright and metadata can be verified. As the Wayback Machine stores snapshots of the web pages over time, this gives meaningful evidence to support our actions in uploading and hosting the images, should the website change its release statements and there is a future challenge, such as a take down notice or a deletion request. Interestingly, a number of legal cases have already relied on Wayback Machine evidence.
I encourage other batch uploaders, especially those interested in GLAM collections, to consider adding similar archive links when planning their projects. Doing so should reduce the burden of volunteer time in adding license review templates as these become unnecessary, and we avoid potential debate about the history of files that have suffered from link rot. Commons may be added to Wikipedia's IABot, which could automate adding archive links, but no date for such an improvement has been set.
Here's the science bit.
Batch uploaders can check for existing archives in their favourite programming language by requesting URLs of the form https://archive.org/wayback/available?url={your website page here}, example. This returns some JSON with the date of the latest snapshot, or an empty array if it is not archived.
To save a webpage from scratch, you request a URL of the form https://web.archive.org/save/{your website page here}. This can then be confirmed by checking availability as per the link above.
For more examples, including a real JSON response, see User:Fæ/Wayback.
Sounds good, but so far I assumed that WayBack snapshots can be killed post facto with a newer robots.txt disallowing their crawler. Please correct me if that's wrong. –84.46.53.19818:49, 5 February 2019 (UTC)
I've just had a good meal at a pub I visit regularly near Penkridge, and spotted a nice black and white copy of this photo, one of mine, on the wall, unattributed. I'm really not sure whether to feel flattered, or sue them for breach of copyright. Any thoughts? O Still SmallVoice of Clam22:09, 2 February 2019 (UTC)
If you had written a piece of software, someone might sue on your behalf (see gpl-violations.org, en:BusyBox#GPL_lawsuits etc.). That's not going to happen with a photograph, unfortunately. Since it's not a large corporation involved, and they're not really directly making money off of your photo, I would advise starting with a light touch (ask for publicly-displayed credit, rather than threatening a lawsuit)... AnonMoos (talk) 03:04, 3 February 2019 (UTC)
Don't go in with lawsuits and lawyers, just inform them of your terms, and have them put your name below or on the image. Heck, offer to sign it! Maybe you'll get a free beer out of it. --Animalparty (talk) 03:08, 3 February 2019 (UTC)
Alternatively, you could simply grant the pub a single-use permission to use the image without a displayed credit, just like the majority of contemporary wall art in the world. Stamping "CC-BY-SA-3.0 & GFDL-1.2.", and providing a link to the license (a QR code? URL?) risks marring the aesthetics. While you have released the image under a free CC license, you have the power to selectively grant a non-attribution license to whomever you wish. --Animalparty (talk) 03:15, 3 February 2019 (UTC)
I don't see how putting a title and author below a piece of art, like every museum in the world, mars the aesthetics. I'd argue that taking the CC attribution requirements seriously would help make a world where more people get credit for what they do, which is a good thing.--Prosfilaes (talk) 07:34, 5 February 2019 (UTC)
I would prefer to feel flattered, if I found one of my photographs on Commons displayed in a pub. Perhaps the publican was thinking that, since he found your photograph on Wikipedia, he could use it as a decoration of his premises without breaking any rules. Have you considered telling him that you are the photographer, and asking him to add your name to it? I don't think calling up your lawyers is a good idea. Not a good idea at all, actually. (Having been a lawyer myself, and being a contributor to Wikipedia and Commons.) MartinD (talk) 08:55, 6 February 2019 (UTC)
February 03
Zilla macroptera or Zilla spinosa?
I am certain this is a Silla plant, but wich type? I would be nice if it was a Macroptera, because we dont have any pictures of it. Unfortunatly the picture is not detailed enough. At the time (1981), I looked for the biggest impressive bush and did not think about a detail picture. There must a lot off desert pictures with these plants on it.Smiley.toerist (talk) 10:13, 3 February 2019 (UTC)
Came across this picture while searching for another and uploaded it, but I don't know what the name is for such a painted scenery with holes where people can stick their heads through to be photographed. There must be millions and millions of pictures of this kind, but I'm unable to find a Commons Category. Is there even any Wikipedia article on this? Help? Jürgen Eissink (talk) 13:31, 4 February 2019 (UTC).
As far as I can figure out from Googling, "face hole board" and variations on that phrase ("face-in-hole board", "face in the hole board") seem to be the most common or recognized terms. According to this page[1], other names are photo cutout boards, comic foregrounds, and tintamarresque... AnonMoos (talk) 14:38, 4 February 2019 (UTC)
Ah, okay. So the French have a word for it: tintamarresque, which brings up the English term photo stand-in and indeed face in hole. Jürgen Eissink (talk) 01:35, 5 February 2019 (UTC).
We could only host these if the board was made using a freely licensed image. To obtain an example of a "face in the hole" board, your best bet is probably a board based on a classic painting. - Alexis Jazzping plz09:16, 5 February 2019 (UTC)
There is nothing to be found about Coolidge it seems. "Dogs playing poker" is everywhere, his other work virtually undocumented. No dates on anything. At least, none that I can find. It must be out there. - Alexis Jazzping plz16:06, 6 February 2019 (UTC)
Searching for variants "C. M. Coolidge" or "Cassius M. Coolidge" yields art of the non-gambling canine variety (including several works on Commons). An editorial cartoon is found here. Coolidge's "grotesque foregrounds" or "photo-caricatures" are discussed briefly here, and here and some of Coolidge's ads (presumably his art?) are found here. Another common vernacular synonym for "face in hole" is "Carnival cutout". --Animalparty (talk) 18:51, 6 February 2019 (UTC)
What characterizes the publications that are included in the category? If it's just three random publications, that category doesn't make sense. - Jmabel ! talk00:54, 6 February 2019 (UTC)
Do we have a category for this bizarre (indeed, in an earthquake zone, insane) method of laying rail tracks? If not can someone suggest/create one? - Jmabel ! talk01:33, 6 February 2019 (UTC)
In both cases that cribwork is temporary and will be replaced (structurally, at least) by something more solid: Rammed dirt in the first case (plus the cable conduit masonry, usually shared by the roadwork foundations), iron lattice trusswork in the second. Maybe it all could be bagged in something like Category:Scaffolding in rail track construction and then later dissiminated when there’s enough files and expertise around to do so? -- Tuválkin✉✇04:11, 7 February 2019 (UTC)
Wikimediacommons Pro Flickr account
After politely asking on Twitter, Flickr have kindly given the long term experimental account wikimediacommons a free Pro upgrade. Most of the 75,000 photos hosted there are mirrored from Commons and link back to their Commons source page. See https://www.flickr.com/people/wikimediacommons
There are potentially several interesting ways this informal Flickr account could assist our GLAM related projects, though there are no plans to create an official Flickrcommons account as we are not a legally recognised institution. --Fæ (talk) 13:31, 6 February 2019 (UTC)
Czech Money
A DR raises that the category of Czech banknotes might be running afoul of a non-copyright restriction. There are no files listed and thusly no uploaders have been notified, which means it should be closed on procedural grounds. Template {{PD-money-CZ}} mentions this non-copyright restriction (it also mentions that Czech banknotes are not copyrighted).
I believe I got all the random cleanup bits as well except for one thing. When the extended uploader group was disabled a script was used to grant autopatrol to all those that did not already have it. Unfortunately, this means that some patrollers now are also autopatrolled when they should not be. I'll fix those soon but I wanted to note that in case someone else notices. --Majora (talk) 02:21, 7 February 2019 (UTC)
Commons:Categories for discussion currently has open discussions dating back to 2013!. That's six years. I know things go a little slower here than on Wikipedia (or at least the largest language Wikipedia), but I think anything more than a couple months is a bit absurd. For comparison, w:en:Wikipedia:Categories for discussion are generally resolved within or after 7 days, and the oldest discussion dates to December of last year. Sometimes they're closed as simply "no consensus", in which case the status quo remains until someone musters up the rationale or persuasive skills to try again. What's preventing something like that from occurring here? How about a recommended standard time limit of, say, two weeks, with an additional two weeks if no consensus is apparent. Then maybe a final, last ditch 2-week period, after which a decision is made, even if the decision is no consensus? Or are we hoping that children entering kindergarten today will eventually wander into an open conversation with the wisdom and clarity to end debate and save us from purgatory? --Animalparty (talk) 02:46, 3 February 2019 (UTC)
One very big basic problem with the whole "Cfd" process (as I've said several times before) is that you could have hundreds of images in categories that are under discussion on your watchlist, but unless you have the categories themselves on your watchlist, then you have no way of knowing that a discussion is even going on. This basic flaw leads to the situation that many "Cfd" discussions receive very few comments, but as soon as the "Cfd" is closed, and the image files involved are edited (for the very first time at the END of the "Cfd" process after the decision is already made), then complaints and objections start pouring in. I found myself in exactly that position with respect to the infamous "Adolescent girls" category fiasco some years ago, where an extremely stupid decision was made to robotically rename all categories with "Young women" in their names to have "Adolescent girls", without any effort whatsoever being made to ensure that the new categories were in fact appropriate for the images contained within them. I had no idea that the discussion was even going on until the renames were done, but it took many months of sporadic effort to clean up after the resulting mess... AnonMoos (talk) 03:19, 3 February 2019 (UTC)
I think both of your comments are related. Because few editors are notified, most CfDs receive only comments from one or two editors. That makes establishing a general consensus almost impossible if the proposer and the creator disagree (effectively giving the creator a veto). Shortening the window for discussion to two weeks would only aggratvate that situation. Leaving discussions open makes them far more likely to involve others, who may help find a suitable compromise. In fact, that has happened repeatedly. Moreoever, those involved in a discussion may both agree that the category has a problem, but fail to come up with any better proposal. Again, leaving it open encourages others to step in. Once discussion is closed and linked on the talk page to an archive, it's unlikely to ever be seen again. I don't know if the comparison to wikipedia is fair - categorization is a far greater part of the work on Commons than it is on Wikipedia, as evidenced by the fact that most Commons categories link to Wikipedia articles (not wikipedia categories). Finally, I don't really see the harm in leaving unresolved discussions open, or the benefit of closing discussions as "no consensus". A better way to remedy the backlog is to fix the problem AnonMoos raised and find a way to encourage additional participation in CfDs. - Themightyquill (talk) 15:01, 7 February 2019 (UTC)
I wonder if User:MusikAnimal (WMF) or User:MaxSem (WMF) could wrangle User:Community Tech bot into doing something similar to what it does on the English Wikipedia, where if an image on an article is nominated for deletion here, then it leaves a message on the talk page of the article over there. So here, if a category is nominated for deletion, it can leave a message on the file talk pages of media in that category. GMGtalk15:09, 7 February 2019 (UTC)
I want to place on some particular category the best (in my most exclusive opinion) photos of nature that come daily to the warehouse of wikimedia photos. I want to do it every day. Some category is needed, but I don’t know in which space. Desirable not in the main categories. Please help me.--Алексей Потупин (старший) (talk) 05:04, 7 February 2019 (UTC)
When I try to add the soundfile for Afrikaans môre on Dutch Wiktionary it doesn't show the audio player, rendering it useless to the reader. I noticed the same phenomenon on French wiktionary and on the Commons page, so I guess it is not something I can fix on Dutch Wiktionary. VLC media player is able to play Af-môre.wav, so it seems there is something wrong with the mechanism that connects .wav files with the player. I noticed this is the only Lingua Libre file with a redirect, but neither page will work. As this is the only file in this batch that doesn't play, maybe restoring the situation before the creation of the redirect would solve the problem. Although I agree that it is desirable to stick to clear naming conventions, we need to find a better solution; in the meantime it would be nice if the file remained useful. I put this question first to Marcus Cyron who moved the file originally. He was not sure about the technical implications and suggested I'd ask here. --MarcoSwart (talk) 11:54, 7 February 2019 (UTC)
@MarcoSwart: the inline audio player used by MediaWiki apparently doesn't support WAV files. Normally, audio files are transcoded to Ogg Vorbis and MP3 after upload, which the audio player does work with. You can check the status of transcoding at the bottom of the file page. In this case, the transcoding didn't happen automatically. I've noticed that this often happens when files are renamed, though I don't know why. I reset the transcode status by purging the file page, and now it should be working. clpo13(talk)16:22, 7 February 2019 (UTC)
Notification of DMCA takedown demand - RussellMNelson
In compliance with the provisions of the US Digital Millennium Copyright Act (DMCA), and at the instruction of the Wikimedia Foundation's legal counsel, one or more files have been deleted from Commons. Please note that this is an official action of the WMF office which should not be undone. If you have valid grounds for a counter-claim under the DMCA, please contact me.
The takedown can be read here.
Notification of DMCA takedown demand - Estelle Maersk
In compliance with the provisions of the US Digital Millennium Copyright Act (DMCA), and at the instruction of the Wikimedia Foundation's legal counsel, one or more files have been deleted from Commons. Please note that this is an official action of the WMF office which should not be undone. If you have valid grounds for a counter-claim under the DMCA, please contact me.
The takedown can be read here.
I am not joking you, if you can't afford Cakewalk or something, I recommend "Music" for the Playstation One. It is simple, has all the orchestral sounds, with a limited but functional variety of manipulation tools. After that, "Music 2000", for the Playstation 2 is also in the realm of simplicity and can utilise a sampler though I assume samplers for the PS2 have become rare. These programs are designed for children and that makes them the most intuitive that I have tried. They are become rare now but can still sometimes be found on like of ebay. PS2 machines can still be bought. There seems to be a lot of sheet music going around and people wanting to hear it but no files. Digital reproduction of orchestral sounds has been perfected way before synthetic so the sounds are true. Maybe there is a little bit of quality issue on the machines themselves but I doubt that is major on either machine. ~ R.T.G12:21, 8 February 2019 (UTC)
I didn't realise that stuff was being synthesized rather than just played! But I don't think a widget would do for a multi track ensemble or tweak it to sound played rather than synth. Music is so underrated when it comes to free art tools and projects, unless you just want to work with wavs, which can be used to create anything, but sure doesn't replace keyboard/riff functions and distortion. ~ R.T.G23:43, 8 February 2019 (UTC)
International Journal of Earth Science and Geophysics
I made a hiking trip in februari 1981 and took a lot of pictures (slides). I am scanning them and plan to upload them. Is there any detailed map of the trails in the mountains so that I can reconstruct the route/location? It is a spectacular mountain range, but due to the later security situation it has very little tourism.Smiley.toerist (talk) 23:05, 26 January 2019 (UTC)
I dont think it is a Cedrus. The trees live under extreme conditions. It only rains once every few years for a short time. The water is concentrated in the dry river beds. After a flooding the water remains present underground for a longer time. These plant have deep roots to exploit this. But even then the water is eventualy used up and the plant loses al leaves and waits for the next rain. In the summer the temperature goes up to 50 C and in the winter it freezes at nigth and in the day the temperature runs uo to 25/30 C.Smiley.toerist (talk) 10:30, 1 February 2019 (UTC)
Working on adding categories I came across some high quality photos, but the description is in arabic. I tried with Google translate to find out where the photos have been taken, but that did not help. If somebody can help me to tell in which country for example this photo has been taken. That is sufficient to categorize most photos to “Landscapes of ….”. Then they are out the uncategorized state and others can put them in a more detailed category. Thanks Wouter (talk) 17:21, 8 February 2019 (UTC)
Hello, I already asked the question in the German Forum, but didn't get an answer. Normally, I create my articles in the German Wikipedia in the user namespace. When they are finished, I move them to the main namespace. Recently, the links in Commons under global usage were not updated after moving the article and still point to the deleted user page. Examples are Ben Schultz, the McCains and Obama, Biden & Jay Carney. What is the reason for that and how can this be fixed? --Redrobsche (talk) 20:49, 8 February 2019 (UTC)
Hi, recently an editor named RainbowSilver2ndBackup has uploaded some images that link Houthis to North Korea [2][3][4] . He says that these images are fictional but I say they are controversial and offensive for some. They aren't sourced flags. He made up these flags from his mind. These images promote a biased POV. Could you please help. Are we allowed to create fictional flags to promote our POV??!! E.g creating the US flag with the Natzi flags etc? . Thanks.--شرعب السلام (talk) 15:15, 9 February 2019 (UTC)
Bjh21 -- we have many hundreds of "special or fictional flags" on Commons, and traditionally they're not usually deleted just for being special or fictional, unless there's some additional aggravating factor, such as being hoaxing or hatemongering... AnonMoos (talk) 05:57, 10 February 2019 (UTC)
The relationships among Category:Landfills, Category:Municipal solid waste, Category:Solid waste management and quite possibly some other related categories are a mess: lots of recursive inclusion of categories. Can someone who has worked in this are of Commons please try to sort this out to be acyclic? @Closeapple: pinging you as the most recently active on Commons of people whose names I see in the relevant history, even though your contributions in this area may not be recent, hoping you might be able to sort this out. - Jmabel ! talk00:08, 10 February 2019 (UTC)
I don't see myself in the edit histories. Where did I appear? I've now tried unknotting those three categories, on the theory that "municipal solid waste" is basically the same as household/office trash, per en:Municipal solid waste; and that "landfill" is a form of municipal solid waste management and therefore a subcategory of each of the other two. I don't immediately see any other subcategories of Category:Waste with problems. Anything else look odd? Should Category:Garbage, Category:Rubbish, and Category:Trash be redirected to Category:Municipal solid waste instead of just Category:Waste, or is that too much of an assumption? --Closeapple (talk) 07:06, 10 February 2019 (UTC)
Looking again, I have no idea why I thought you had worked on that. Apologies & thanks for helping. I have no thoughts on the possible changed redirects, I'd probably leave them be. I do find myself wondering whether "landfills" necessarily relate to solid waste, though: I'm thinking of things like Seattle's Industrial District and Harbor Island, which were created at least in part from earth from hills that were regraded downward. In some sense, I guess, that was waste, but not what "waste" usually connotes. - Jmabel ! talk07:54, 10 February 2019 (UTC)
I'm confused: so if someone creates a breakdown of (say) the Washington Territorial Legislature in 1885 and it isn't promptly used in an article it should be deleted by a bot? Why? - Jmabel ! talk16:44, 8 February 2019 (UTC)
I can imagine someone going through the history of some legislative body turning out diagrams without concerning themselves about any Wikipedia. Not that I'm against deleting fictional crap: just don't see it as clearcut enough for a bot. A bot could notify a human, but the human needs to make a decision. - Jmabel ! talk17:47, 9 February 2019 (UTC)
User:B noticed this problem a while ago, and upon his suggestion, I've tried to make the user interface clearer about the fact that only diagrams that are for use on Wikimedia projects should be uploaded. I'm not sure how to check whether that's working, though. There are definitely lots of diagrams that should be deleted. Ultimately, it would be better if the diagrams could be created on the fly in the pages where they're used, ideally from Wikidata, but I don't have an idea how to do that. I support automatic deletion of unused diagrams without detailed descriptions. --Slashme (talk) 05:16, 11 February 2019 (UTC)
Commons is not a webhost; these fantasy diagrams are being made by editors who have no intention to contribute to Commons. Given the scope of the problem, I think speedy deletion of files and short blocks for the non-contributing editors (with the intention of that being frustrating enough for them to find a new webhost, while leaving open the possibility of productive contributions in the future) is the best way to go. I've seen several very similar usernames which indicates that some of these users may be using multiple accounts. Pi.1415926535 (talk) 05:54, 11 February 2019 (UTC)
The image File:Samuel Walker McCall circa 1920.jpg was being used for the wrong person with the same name, I fixed them and then purged my cache to make sure I got them all, but it still lists being used in the Catalan wikipedia. Can someone take a look and see why? RAN (talk) 20:52, 9 February 2019 (UTC)
I found some images contain not necessary detail information like GPS locations, I uploaded a new version which has removed these information, however I have no permission to remove the old one, how to remove the history version? -- Porsche613 (talk) 04:48, 10 February 2019 (UTC)
File:Natascha McElhone.jpg was given through OTRS. I believe it is not appropriate to overwrite it with a cropped and retouched one, but I cannot upload the retouched pic separately because of duplicating. What is the standard procedure for this kind of files?--Roy17 (talk) 21:16, 10 February 2019 (UTC)
@Ghouston: Thanks a lot! It's kinda weird though. I had this problem before and I did revert-this-and-upload-that. No idea how the software works...--Roy17 (talk) 22:44, 10 February 2019 (UTC)
I'm not sure, it seems like it checks for for checksum matches, sometimes, but not always. Maybe it depends on the upload method. --ghouston (talk) 22:46, 10 February 2019 (UTC)
February 11
Brexit
There's less than two months to the date that the UK is due to leave the EU. That date could easily change but when the actual withdrawal happens, it will affect Commons. For instance, most of the files in Category:Maps of the European Union will become inaccurate overnight.
I suggest that we make more preparations for this than the British government and mark any content that will need updates in advance. Then when (or if) the actual withdrawal happens, then we will know which files need updating or replacing. A bot could handle any category changes.--Nilfanion (talk) 13:52, 2 February 2019 (UTC)
They won't become "inaccurate", they'll become historical. That said, yes, someone should have a bunch of maps ready to show the new situation. - Jmabel ! talk17:52, 2 February 2019 (UTC)
While that may appear true, many of the maps will be updated by an overwrite instead of an upload to a new location. That's because the subject doesn't really care about boundary and this is reflected in a simple undated file name, with the description and actual usage on WP (and elsewhere) just indicating it shows the EU [as it is right now]. The old version will become historical, but has very limited educational value. File:European Union Sudan Locator.svg would be an example of this. If the files instead showed the EU at a fixed date, with a description and file name backing that up, then yes it would become historical. Providing that level of detail isn't really necessary.
It is conceivable that the “sweat-of-the-brow doctrine” (with implications for PD-Art and possibly TOO) could be reinstated; IIRC it was struck down in a case a few years ago to comply with an EU court ruling. Someone might just reopen the question post-Brexit.—Odysseus1479 (talk) 21:12, 3 February 2019 (UTC)
PD-Art is something that Commons has decided on, irrespective of local laws, so changes in local laws won't have an effect on PD-Art.--Prosfilaes (talk) 07:28, 5 February 2019 (UTC)
IIRC "sweat of the brow" affects commons, unless the servers are moved to another country: So coins no (sweaty 3D thingies needing a lot of moving around by the photographer to catch a nice perspective), photos of PD paintings yes (mere scanning of silly 2D cruft), and never try Germany, where everything requires sweat (that's related to our singing and marching and other ugly habits.) –84.46.52.214:15, 11 February 2019 (UTC)
Structured data licence.
What licence(s) cover the new structured data being rolled out across Wikimedia Commons?
My understanding is that the data will be replicated in some form on Wikidata which states: "All structured data from the main, property and lexeme namespaces is available under the Creative Commons CC0 License; text in the other namespaces is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply."
One specific test case I'm interested in is as follows: A machine learning algorithm is trained using images from the Commons licensed under various permitted schemes and their associated structured data. Does ShareAlike prevent the resultant software from being proprietary?
In that specific test case, ask your lawyer, and know that whatever they say can't stop you from being sued. The legal issues of machine learning are far from being beaten out.--Prosfilaes (talk) 06:00, 6 February 2019 (UTC)
The structured data portion of Commons will be CC0 by necessity to live and work in the Wikidata ecosphere. The footer at the bottom of pages on Commons is in the process of being modified for these new licensing obligations (links available at my Village Pump/Copyrights post), and there are designs available for review for notifying editors about CC0 in the structured data space.
I am uneasy about the blanket adoption of CC0 for structured data on the Commons as my cynical suspicion is that doing so leaves the time and effort of volunteers open to commercial exploitation, specifically with regards to data trained machine learning algorithms. Of course the optimistic view would be that doing so makes it easier for open-source alternatives to emerge so one can but hope...
If existing description text is CC-BY-SA does that mean that it cannot be copy-pasted as a caption?
If existing description text is CC-BY-SA, it can not be taken as CC0. Note that much description text is clearly subcopyrightable, and much of the rest is on the line.
The CC-BY-SA specifically permits commercial exploitation, and someone using CC-BY-SA photos is likely safe if they keep the results in house. If the machine learning application is distributed, then it might have to be under a license compatible with the CC-BY-SA. It doesn't really matter if the CC0 or CC-BY-SA is used in claiming a photo is of a white-tailed antelope squirrel; that's a fact and not copyrightable.
The copyright problem comes from the fact that if you have just one photo of a certain creature, a machine learning program that recognizes that creature can be driven in reverse to basically produce that photo; the same is true, but in a more complex way, if you have more photos. The rules are unclear, but I really hope they don't stop anyone from producing a program that can properly tell what species my photo is of.--Prosfilaes (talk) 14:07, 11 February 2019 (UTC)
Not all new URLs work. Anyways we should review all of them asap. Someone also has to move reviewed ones out once every few hours.--Roy17 (talk) 14:51, 7 February 2019 (UTC)
That's an understatement, if anything. You should see the last two tests Alexis gave the last two license reviewer candidates! Really, Alexis, I'd support you in a heartbeat. --GRuban (talk) 01:47, 8 February 2019 (UTC)
@Strakhov and GRuban: thank you. I was considering to apply again, but I applied half a year ago and was turned down not because of questions about my knowledge, but due to trust issues. Nothing has changed in that regard. - Alexis Jazzping plz02:04, 8 February 2019 (UTC)
@Strakhov: when things calm down a little, I plan to request undeletion of my essays. (I will make adjustments to the Everipedia essay though) Majora's comment almost pushed me to re-apply, but your comment about my essays makes it clear I really shouldn't. - Alexis Jazzping plz11:40, 8 February 2019 (UTC)
Looking at the LR debate out of curiosity (triggered by the image caption), it's no "vote" (by definition), 2 objections with reasons (ignoring one harmless confusion about "canvas" or not), 1 of 2 mitigated by "opinions change" a few lines above, this is commons, it cannot get better (by definition). –84.46.52.216:44, 11 February 2019 (UTC)
Info Thanks everyone! Almost all the files were saved, except for one gallery containing 26 images: Category:Chama Ice Cave. I will try again a few days later for Bing and Google cache. If still unsuccessful, I will delete them (or nominate them for deletion). 4nn1l2 (talk) 13:05, 8 February 2019 (UTC)
@4nn1l2: best to go to DR. I had some ideas to try and find them (if they are still there), but I can't navigate the site very well because I don't understand the language. Besides, they are watermarked and have EXIF which can probably be matched to other (reviewed) photos from this photographer. It may be beyond COM:PRP to assume they don't originate from Farsnews. Hanooz would have had to insert the watermark and fake the EXIF..right.. And we have accepted self-reviewed files in the past from license reviewers who were unaware they were not supposed to self-review. In this case, if we can't verify the files another way, I would allow Hanooz to self-review them. - Alexis Jazzping plz13:57, 8 February 2019 (UTC)
Done Alexis, I am highly tempted to draft you into being a license reviewer. By force. With an army of other License Reviewers bearing torches and pitchforks. --GRuban (talk) 17:47, 8 February 2019 (UTC)
I didn't quite catch in what sense those 20k category additions are considered "indiscriminate". From that discussion I see that at least some users believe that "Every aircraft file should have categories for registration, type, operator, date and location". Presumably the same users may find it useful to have a way to find the files which don't. Are you saying you will remove {{Check categories}} from the files after checking that they actually have all those desired categories, or did you find some other criterion? Thanks, Nemo16:53, 9 February 2019 (UTC)
Two days have passed. If an uploader tagged their uploads with {{Check categories}} at upload time without actually checking the categories themselves it would be bad practice, but whatever. If someone wants to dump thousands of files in some Category:Unidentified aircraft category, no problem. Indiscriminately dumping thousands of unrelated uploads in a general maintenance category years after upload? No. In a few hours, I will finish what I started. - Alexis Jazzping plz18:04, 11 February 2019 (UTC)
vertical bar problem
When media is imported via video2commons etc, if | is included in the displayed text of a link, it would be replaced by {{!}}. This causes one problem, that if the source field is such a link, and a reviewer copies the link as the site parameter in {{Licencereview}}, the resultant template will be malformed. (See also Template_talk:LicenseReview#malformation_due_to_template:!.) Should those tools substitute & #124; instead of {{!}}?--Roy17 (talk) 18:37, 9 February 2019 (UTC)
Wanted to point out that I modified the license reviewer script that I maintain to replace the instance of {{!}} with the vertical bar escape (& #124;) in both the source parameter and in the LR template once the LR is passed. The {{!}} template is a special use magic word that really shouldn't be used this way anyways. --Majora (talk) 19:24, 9 February 2019 (UTC)
JFTR, it's a magic word for years now, and it was always intended for cases, where | wasn't good enough (note decimal notation, my netscape 2.02 was too stupid for hex. back in 2006). –84.46.52.217:44, 11 February 2019 (UTC)
Parade royalty
We seem to lack a category for the concept of "parade royalty", pretty common in the U.S. and probably to some extent elsewhere. We have some things that should be subcategories of that: Category:Seafair royalty, Category:Queens of the Tournament of Roses, Category:Carnival Queens. Some parade royalty (e.g. queens of the Tournament of Roses) are beauty contest winners but others (like this and this, the two that sent me looking for a category like this) certainly are not.
Complicating factors in creating such a category:
I'm not even sure "parade royalty" is the proper generic term, though its the one I've always used. Very often their duties extend to other civic activities besides their appearances in one or more parades.
What would the parent categories be?
As I said, some but not all are beauty contest winners.
Should this descend from Category:Royalty? That has subcat Category:Fictional royalty but that's for fictional figures like Snow White and Prince Charming, not for real people whose royal title is fictional.
The Lord Mayor of London has never been a "lord" in the sense of a peer of the realm, and similarly, no one thinks that the Rose Bowl queen is a real "queen" in the sense of a territorial sovereign, so I don't think such categorizations are useful. I don't know that there's always a parade, necessarily -- some of them are crowned at county fairs and such... AnonMoos (talk) 05:54, 10 February 2019 (UTC)
Again: I'm not talking specifically about beauty pageant winners, even though the concepts overlap. But there is a role in parades that is an identifiable thing, and we have a lot of pictures of people doing that thing. - Jmabel ! talk07:14, 10 February 2019 (UTC)
We have Category:Women called queens (which oddly includes those called "princesses" as well); no analogous category for male winners of drag pageants given that title, nor a Category:Men called kings. If anything, AnonMoos's remark about "Lord Mayor" would be more of an objection to this existing category than to what I'm proposing. - Jmabel ! talk07:21, 10 February 2019 (UTC)
It's another example, but it is specific to Carnival (a celebration on or just before Shrove Tuesday a.k.a. Mardi Gras, Fat Tuesday, etc. What I'm saying is that we lack a broader category for this not tied to a particular time of year. - Jmabel ! talk17:58, 10 February 2019 (UTC)
The description for Category:Carnivals says: Carnival, the carnival season, and other holidays called "carnival" or similar that include masquerade. It seems your interpretation of the Word Carnival is unusually specific here. Cambridge Dictionary defines Carnival as: (a special occasion or period of) public enjoyment and entertainment involving wearing unusual clothes, dancing, and eating and drinking, usually held in the streets of a city: https://dictionary.cambridge.org/dictionary/english/carnival it seems this category suffices Oxyman (talk) 18:13, 10 February 2019 (UTC)
I'm pretty sure that even though "carnival" doesn't always mean Shrove Tuesday, "Carnival corte" is pretty specific to the holiday. I'd be interested in seeing an English-language citation that uses the term in a context unrelated to Mardi Gras.
Feel free to subcategorize as appropriate. I think if someone is well known as Carnival royalty over the years, and we have a category for that person, then their role as Carnival royalty belongs as a parent of their subcat; otherwise, it should just go on photos of them related to that role. Note that we had that issue even before adding Category:People with fictional royal titles. - Jmabel ! talk16:47, 11 February 2019 (UTC)
Do not categorize Bob Hope as Category:People with fictional royal titles just because he appeared in a parade once or twice. Would we categorize every actor who played the titular role of King Lear? IMO, unchecked hyper-, meta-, and over-categorization leads to inefficient searching, clutter, and confusing, unhelpful cross-categorization . For just 1 example, searching for Good images of "Category:Kings brings up this image of a seagull, merely because it's in a subcategory of Cities named after monarchs. Is it realistic to expect that a user looking for images of Kings wants to find a bird? Is it realistic that anyone beyond us constant gardeners will be looking for Bob Hope (or anybody) based on the trivial fact that they (once) had "Queen", "Prince" or "Duke" in their name or title? --Animalparty (talk) 21:10, 11 February 2019 (UTC)
Having now observed that "carnival" doesn't always mean Shrove Tuesday, Corte means good breeding ie royalty. I find it odd to add more meaning then what is contained within the words used. I'd be interested in seeing an English-language citation that claims the term can only be used for Shrove Tuesday. Oxyman (talk) 23:11, 11 February 2019 (UTC)
The word “carnival” can indeed refer to several different things, but IME the unqualified, capitalized “Carnival” almost always means a Mardi Gras festival.—Odysseus1479 (talk) 23:33, 11 February 2019 (UTC)
Besides agreeing with what Odysseus1479 just said... @Oxyman: , what you are asking is as if you asked for a source explicitly saying that we only call something a "Halloween costume" when its worn on or around Halloween, or that we only call something a birthday present when it is given on or near the recipient's birthday, or that when we talk about an animal that "has feathers" we don't mean a cat that just ate a hummingbird and has feathers dangling from its mouth. If you think the term Carnival Corte is ever used to refer to things at other times of year, I really think the burden of proof is on you. Certainly all of the first 50 Google hits I found used it in the sense I understand the term. - Jmabel ! talk00:25, 12 February 2019 (UTC)
Most categories start with a capital letter including Category:Carnivals which states that it doesn't just mean Shrove Tuesday carnivals, I do not think your similes are relevant as we have already observed the word carnival doesn't always mean Shrove Tuesday. I find your peculiar definitions extremely archaic and irrelevant. I am also not seeing the same 50 Google hits as you claim. As i stated before and restate as it is extremely relevant carnival doesn't always mean Shrove Tuesday, Corte means good breeding ie royalty. I really think the burden of proof should be on you. You are claiming the words mean something that is not in the meanings of the words themselves and backing that claim up with irrelevant similes. A bit like saying a Christmas decoration is not a Christmas decoration when it is in storage waiting for that time of year. Maybe you come from an extremely religious culture and that is coloring your thinking here. Oxyman (talk) 02:18, 12 February 2019 (UTC)
Wow, let's go all ad hominem here, shall we? For the record, I'm a secular person of Jewish background. And I've never seen the term Carnival corte used to refer to anything other than Mardi Gras. In particular, I have never heard anyone apply the term to, say, Seafair royalty or Pasadena's Rose Queen or anything of the sort, but it's almost impossible to demonstrate a negative that the term is never used that way. I believe it is incumbent upon you to come up with at least a couple of citations of such uses -- not just that it would in theory make etymological sense, but that the term is actually used that way. And until you have such citations, I'm done discussing it. - Jmabel ! talk 04:29, 12 February 2019
Wow let's get all offended here shall we, I said Maybe you come from an extremely religious culture and that is coloring your thinking here. Not that you are religious yourself. I can only know how words are used in the society I live and by using other sources like the dictionary one I linked to (I note you have provided no such links to your claims). I find your peculiar definitions extremely archaic and irrelevant. Having said yourself it makes etymological sense. What more can be expected from a category name? I believe it is incumbent upon you to demonstrate that we should add our own meanings to combinations of words as we see fit. Where is the policy on that? I also know that for instance buskers in Metro stations or subway underpasses are contained within Category:Street musicians. So think it well within reason to use this existing category. You do realise that you started this conversation asking for a response and then you pinged me for a response. I see no reason for you to fain offense that I answered your posts and attempted to point out that perhaps your vision is a little blinkered here. But if you're done discussing it then fine, I do not see why you post here at all. Oxyman (talk) 04:54, 12 February 2019 (UTC)
For years now I’ve observed the practice of users blanking the user pages of indefinitely blocked users, this seems to happen cross-wiki and seems to happen, how the practice basically works is that if a user gets blocked with no expiration data their user pages will typically get blanked by another user, this user can be the blocking admin or a casual observer, more often than not it's done by someone who has a dispute with the user and their user page will then be replaced with a template indicating that this user is indefinitely blocked. In many cases these people have been contributors for a long time and have had their fair share of contributions to the project, one would think that as a bit of decent courtesy we (as a community) would allow these people who involuntarily have to depart from the project could at least have a little space dedicated to them and how they feel about the project(s) that they have contributed to, but that really is too much to ask if you'd ask most Wikimedians for some reason. Now conversely if one would look at the common tactic of vandals used where the blank their target’s user pages this is seen as “disruptive vandalism” and gets rightfully reverted, but somehow what is considered vandalism when the target is some users becomes wholly acceptable when other users are being targeted.
I remember in 2017 I was looking at the image “File:Qing Dynasty 500 Cash.jpg” and by coincidence clicked on the uploader’s name to land on this page (Mobile 📱), now looking at its history we see this:
The previous version looked like this (Mobile 📱), an inoffensive user page containing a couple of high quality paintings and a quote, this user was a dedicated photographer who went out of his way to visit museums all over Poland and take high quality pictures that grace many pages across Wikimedia websites and beyond. Yet today any photograph he took is only two (2) clicks away from an empty page with essentially “a go away message” and no evidence that this user was ever anything more here than forever banned from contributing.
I haven't been able to find any local policies that advocate the blanking of user pages, but it seems to be a de facto standard across almost all Wikimedia websites, in fact it's quite odd how often this unwritten rule gets applied, it seems to be the only consistent thing among almost a thousand different projects. A few exceptions exist but in cases of a WMF Global Ban the Wikimedia Foundation office account always blanks all content, including talk pages (Mobile 📱), and also on Wikimedia websites where blanking blocker users’ user pages isn't even a thing (Mobile 📱) which means that the Wikimedia Foundation (WMF) simply doesn't respect local policies and adopts the most punitive ones on a whim. Of course the exception is when there are already tags indicating that this user has been blocked and/or banned before, this seems like a move that would superficially legitimise the Wikimedia Foundation’s actions by saying “look, see the community didn't want this human being here either, so we're not circumventing any community consensus here”, but the Wikimedia Foundation ignoring the independence of local communities is a whole other issue I’d rather not get too deep in here.
The former Wikimedia Commons admin INeverCry and several others even went so far as to first deleting user pages before tagging them with a block notice, this seems overly punitive, let’s say that Wikimedians would actually have to stay true to the original principles of the community and not the heavily Exclusionist principles later adopted which have become the de facto (and unwritten) standards every rule has to be interpreted with today, and blocks were actually seen as a preventive and temporary measure. Let’s take the example of page “User:DLindsley” which if you would look at its history (Mobile 📱, as of January 17th (seventeenth), 2019) only contains a single edit by the user known as “INeverCry”, the argument usually goes that after a user gets unblocked that they could restore their own user page and/or that if anyone is interested in seeing a prior version of the user page that one can visit the “History” of that page, but the user “INeverCry” (later with their ADMINSOCK “Daphne Lantier”) constantly deleted user pages of indefinitely blocked users, what message does this send to both the community and the human being behind the blocked account? In fact, people went out of their way to restore INeverCry’s user page after he deleted it, himself (Mobile 📱, I couldn't find the original discussion). But if you look at logs of the page “User:DLindsley” you could see that this was deleted (Mobile 📱) at “02:34, 3 March 2015 INeverCry (talk | contribs) deleted page User:DLindsley (Userpage of indefinitely blocked user) (thank)”, but nowhere does the rejected user page policy state that they have to be deleted if a user has been indefinitely blocked. So why do we allow sysops to create their own rules and unwritten guidelines relating to actions only they are permitted to take? In fact this makes the legitimacy of INeverCry’s half a million log actions (Mobile 📱) even more questionable. On Wikimedia Commons every file links to its uploader, and if a banned uploader has so many uploads that if you click on “random” that you keep running into them then an empty page with only a tag could be very discouraging to newcomers (“noobs”) and outsiders.
This brings me to the question who benefits from blanking user pages? Seriously, which party actually has a benefit from seeing a user page blanked? Because the casual readers surely don't benefit from it. When I look at the systematic blanking of indefinitely blocked users’ pages I see the same behaviour vandals or otherwise good contributors who are disgruntled at a certain person do, they blank the pages of users they don't like but in this context it is rightly seen as vandalism, but in this specific case it's somehow acceptable. It is gravedancing, no matter how you spin it, in fact if you Ecosia search “legitimate gravedancing” among the first results is the Wikipediocracy article “‘Tis the Season to be Banning at Wikipedia” by Mason, this article notes that the practice of blanking is not only a form of gravedancing but one that’s mostly performed by people who dislike the banned person.
But one of the main reasons why I dislike this practise sends a bad message to the blocked person, while officially the Wikimedia Commons blocking policy states “blocking is designed to be a preventative measure and not a punitive one”, but blanking a user page completely negates this intention, also if a user is expected to be able to return if they can successfully appeal their block, then why blank their user page? This sends the message that it's permanent (which is probably is seeing how few users successfully return from indefinite blocks), it is simply not a collegial thing to do and does not benefit either “the community” or the project, so I suggest ceasing the blanking of blocked user pages altogether.
TL;DR version:
When user pages are basically CV or promotional or contain personal attacks or otherwise content that’s not allowed we remove the content or delete the user pages, this is normal as user pages are not meant for these things and such content is harmful for the community, meanwhile acceptable user pages which may contain instructions on how re-users should attribute them or could directly link to featured images or other high quality images uploaded by them (Mobile 📱) which potential re-users might be interested in, but for whatever reason it's acceptable to treat these pages as if they’re pure vandalism and blank them (Mobile 📱). For this reason I would like to propose to treat the blanking of indefinitely blocked users’ user pages like the blanking of “regular user pages” that if they do not contain anything offensive or advertising something external (excluding GLAM’s) should not simply by blanked because it comes off as petty and uncollegial. Furthermore the current practice of blanking (or even deleting) user pages of indefinitely blocked users is not a community policy and just seems to be an unwritten rule the community never voted on and can not be seen as anything other than bad faith editing or even gravedancing as it appears as a punitive measure.
I agree that blanking pages that would otherwise be acceptable is pointlessly aggressive. Obviously, we have to be free to blank indef-banned users' pages if the page content would be unacceptable from an active user, and maybe there should be a little more leeway to remove self-promotional content from the user page of an indef-banned user than one in good standing, but that's about it. - Jmabel ! talk00:36, 12 February 2019 (UTC)
Was it really necessary to write a 15,000 byte rant with multiple, line interrupting, unnecessary, emojis to say that? It is standard practice to replace the user pages of blocked socks with the sock notice both here and on the English Wikipedia where you are taking your policy advice from. As for regularly indefinite blocked individuals, I agree that deleting the user pages is a bit much but replacing them is also pretty standard practice here and on enwiki depending on the circumstance. The page's history maintains a record of what was once there provided the page isn't actually deleted. Using INC to justify your rant is just poor form. We are not all INC. --Majora (talk) 01:49, 12 February 2019 (UTC)
Support Blanking a blocked or banned user's page should only be done where there is a clear rationale for doing so. This may include harassing other users or other ranty stuff, but if the page is neutral and informative, there are no good reasons for blanking and it should not happen because "bureaucracy". P.s. yes this proposal is far too long, please consider collapsing most of the text/essay. P.p.s I believe this issue was discussed, perhaps 3 years ago, though I am unsure there was ever a vote about it. --Fæ (talk) 10:58, 12 February 2019 (UTC)
I agree with Donald's point that most user pages should not be replaced by a single block notice. The first few times I had seen this on other wikis, I found it unreasonable. Most user pages do not contain stuff harmful to the project. Why not simply put the block notice on top and leave everything else in its shape? It's also often troublesome to find out who the blocked user is and why s/he was blocked. Most block logs contain some one-liners that do not link to the actual grievances.--Roy17 (talk) 11:56, 12 February 2019 (UTC)
Comment Although I mostly agree with which was exposed about unnecessary "gravedancing" and being over-"vindictive", having ad æternum a picture of themselves, their name or other personal data next to templates such as {{autotranslate|1=|base=indefblockeduser}}{{WMF-legal banned user}} or {{Sockpuppeteer}} may be detrimental to the blocked user, and (in fact) administrator removing that stuff may be doing the blocked user a favor. Strakhov (talk) 16:22, 12 February 2019 (UTC)
I'd probably support this, but this is really TLDR. Also, if a blocked user requests their user page to be blanked or have some elements (like a photo) removed from it, such a request should be honored. - Alexis Jazzping plz16:58, 12 February 2019 (UTC)
February 12
Way to exclude PDF from search?
Is there a way to exclude books from searches for images? They are starting to clog the whole thing, on some search parameters there are thousands of hits for books with much much less images to be found. The images mostly come before the books, but not all... Anybody got a solution? ~ R.T.G18:04, 12 February 2019 (UTC)
No, because the actual change would be WD side, based on their notability criteria. Local community has to change local policy. GMGtalk20:03, 12 February 2019 (UTC)
These (see 10 Dec, 'Captions are live', at the top of this page) have reappeared on every file, even though I've got them set to Hidden in my preferences. How can I get rid of them again, please? MPF (talk) 23:15, 12 February 2019 (UTC)
The development team is currently deploying some new code to notify users about the CC0 license (there's some bug fixing ongoing to fix a problem with system messages that didn't show up on TestCommons). There may need to be some tweaking to the gadget (@Jean-Frédéric: ), I'll know more very shortly. Keegan (WMF) (talk) 23:30, 12 February 2019 (UTC)
User:FOX 52 has uploaded a number of digitally manipulated photographs. Many of which are cropped out ground aircraft superimposed on sky. The following gallery are some examples.
Modified, background, FOD mesh, and landing gears removed; rudder modified, pitot tube shortened.
Original
Modified, propeller blurred, landing gear struct removed, whip antenna bent, person and ladder removed.
Original
en:Wikipedia:No original research states that "[i]t is not acceptable for an editor to use photo manipulation to distort the facts or position illustrated by an image." In at least one instance, people have been misled by a manipulated image. Considering that Commons have photos of these aircrafts in flight, do those digitally manipulated images realistically serve an educational purpose? -Mys_721tx (talk) 08:17, 8 February 2019 (UTC)
Copyright fraud? - All image(s) that have been modified have been given their proper attributes, if any have any missing it's purely unintentional & can be rectified – And I don’t appreciate the accusation - FOX 52 (talk) 17:53, 8 February 2019 (UTC)
Cropping out background and replacing with sky is one thing; adding insignia of another country to an F-16 is something altogether different. We do NOT want to imply that this is an actual photograph of an Egyptian F-16, because it isn't. Even if it's not copyright fraud, it is not an accurate representation of what it claims to represent. Either the title and description need to be changed, or the image needs to be deleted. --GRuban (talk) 17:59, 8 February 2019 (UTC)
It would be nice if Fox saved the intermediate images with a transparent background, that way it would help identify them as manipulated, and users may prefer no background, which gets rendered as white in Wiki projects. RAN (talk) 21:17, 9 February 2019 (UTC)
I think if both the filename and descriptions clearly state they are modified images, then ok. Removing or altering a background is not too bad. However, I think changing the insignia on the planes to imply the plane belongs to another air force is a step way too far. That's getting into user-generated art and fantasy, and not compatible with our educational mission. So I think that change should be reverted or the photo deleted. -- Colin (talk) 21:58, 9 February 2019 (UTC)
I think removing the background and making it transparent would be fine. (and quite nice, actually) Replacing the background with sky however, I'm not a big fan of that. There should be a footnote in the image to explain the background was swapped out. Alternatively, an image of some very cartoonish sky drawing could be used so nobody will be fooled. Replacing flags/insignias is not done. As depicted, that plane doesn't even exist. If a plane like it does exist in real life but there is no free picture available, a drawing of that plane could be made with those insignias. Simply photoshopping the "right" insignias on another plane, no. - Alexis Jazzping plz00:04, 10 February 2019 (UTC)
To me, altering the background is debatable. Removing the background to make the aircraft more presentable is not encyclopedic. But removing components from the aircraft is already too far. To assert that the altered picture is what the aircraft would look like is well into the original research territory. -Mys_721tx (talk) 00:27, 10 February 2019 (UTC)
Cutting out aircraft that are long out of service which there are limited photographs available is useful. But they should be on solid color background, not sky, as it misleads. [[:]] is purely false and should be deleted. File:Bulgarian mig-29 (altered).jpg unless reference images are provided, should also be deleted as false.--BevinKacon (talk) 11:20, 10 February 2019 (UTC)
This is a list of FOX 52's uploads with "remix" or "mod" in the file name. This list does not necessarily include every manipulated photo as files such as File:Chengdu J-10 - 殲-10.jpg will not be detected by the SQL query. There are actual in flight photos on Commons for most, if not all, fake ones. -Mys_721tx (talk) 18:54, 10 February 2019 (UTC)
It is really unfortunate that so much effort was put into this. Despite these being many many many hours of tedious editing, I agree with most above that the misleading files should be deleted. Rehman14:08, 12 February 2019 (UTC)
How exactly dose an aircraft in the Sky misled the reader? Putting the aircraft in outer space upside down flown by a monkey is MISLEADING!!! - FOX 52 (talk) 19:28, 12 February 2019 (UTC)
@FOX 52: If you pretend you shot a good photo in the air while matching speed with one of the fastest jet fighters in the world today (or any aircraft, really), and it turns out you ripped off someone else's work on the ground, that's a pretty big deal. So is canvassing. — Jeff G. ツ please ping or talk to me22:33, 12 February 2019 (UTC)
OK that really didn't answer the question, and share alike – If you alter, transform, or build upon this work, you may distribute the resulting work in NOT ripping off someone's work. - FOX 52 (talk) 03:17, 13 February 2019 (UTC)
@Jeff G.: - You mean this file which was kindly corrected by Mys_721tx? out of roughly 1,500 files I've uploaded there's one file? (And that shows my history of trying to steal the work of other's?)- Assume good faith on your fellow editors Jeff - FOX 52 (talk) 05:03, 13 February 2019 (UTC)
@FOX 52: No, that's just the first I came across. How about the following ones?
Hmm? You also should be using internal links. In addition, you are responsible for every edit you make, not just the finished product, and you should explain the modifications you made with {{Retouched}} and mention your work at the source pages. — Jeff G. ツ please ping or talk to me06:47, 13 February 2019 (UTC)
Quite. Once one has removed the landing gear etc., and placed the aircraft in a different attitude with a different background, portraying it in a totally different scenario than that in which it was photographed, it's not a photograph any more - it's an artist's impression of what the aircraft might look like in that invented scenario. If it's not very clearly described as such, with a proper, clear audit trail then it really is basically deceptive. Applying fictional liveries without such clarity is especially 'gob-smacking'. I'm disappointed, because I've known FOX as a good, helpful, capable graphist for a long time, but these examples overstep many lines and are really not acceptable like this. --Begoon09:43, 13 February 2019 (UTC)
Is anyone working on uploads from Watercolour World, a new initiative which styles itself "a digital database of all pre-1900 documentary watercolours in the western tradition"? Sample page are [10] and [11]. Note that the latter can be zoomed, the former cannot, and misleadingly claims to be "All Rights Reserved". Their press release says "The project already comprises around 80,000 images, many of which have been digitised for the first time by The Watercolour World." Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits13:38, 9 February 2019 (UTC)
Possibly, though not right now. Have to think through handling at least some paintings classic copyfraud. Not sure those uploads should be on my (openly UK based) account.
I recently notice early uploads are tagged with no source and deleted afterwards, even though the uploaders provided enough information. They appear no source because someone else puts the {{Information}} but does not write down anything. Examples:
File:Cotes-Inde du Sud.png Yann: Source is there, but I am not sure, it is OK. Wrong tag anyway. Roy: Source (S) is user-created. upct.org can be found in Internet Archive (IA). Free indeed. Licence (L) is GFDL.
File:Carnaval2005.jpg R: S+L=PD-self. Could Markatú be a nickname/diminutive of Marcmacia? I don't speak Spanish so I don't know, but I assume good faith in this.
File:Carmen Bozak.jpg Y: Source is there, but dead. Wrong tag. R: S is there but dead (found in IA, PD indeed).
File:Carl Chinn Nov 2008.jpg Y: Source is there, but ARR. Wrong tag. R: S was not really there, but it could be seen in the original upload log. It was cut short by the file transfer bot. Until the time of tagging, no one had asked for the flickr source. I did that a few hours ago so an enwiki admin filled it up. (The image does not match the source though. Now it is no source indeed.)
It becomes even worse when admins delete such files without checking carefully. Non admins would not be able to check afterwards, because most deletion summary is a one liner no source since some date.
I do not think this is a new phenomenon. I have no idea what can be done to prevent such things happening again and again. To follow hasty deletion constantly is impossible.--Roy17 (talk) 17:32, 10 February 2019 (UTC)
I find File:Cam_degree_ceremony.jpg quite discutable. In 2005, {PD-self} was added by just leaving a standard checkmark in place. There is no explicit own work statement for this file at all. UDR was based on no more than assumptions. Jcb (talk) 18:20, 10 February 2019 (UTC)
I added more comments inline. All these had actual sources. Whether or not they are questionable is another story. I also think it's understandable that users may overlook and put a wrong tag, but all these instances above were tagged by the same user.--Roy17 (talk) 00:16, 11 February 2019 (UTC)
A few years ago I have proposed to dismantle the 'no source since' (and even the 'no permission since') process and to demand a regular DR instead. This has the big advantage that the nominator has to tell what's wrong. In case of the taggings, often the admin has to guess why it was tagged. Taggings are often poorly used. E.g. blatant copyright violations are tagged as 'no source' while the source link is present. Such a file gets deleted in the end, but not for the reason it was tagged for. At the time there was no consensus for my proposal, but I would still support such a thing. Jcb (talk) 19:36, 10 February 2019 (UTC)
Notice the two examples given by Alexis Jazz were tagged by VFC. I wonder whether the person who tagged had actually looked at the files one by one or not.--Roy17 (talk) 21:27, 10 February 2019 (UTC)
when is it that you will trout those editors who persist in abusing the "no license" prod, rather than fixing licenses, or using consensus deletion process? look at all the waste of everyone else's time. Slowking4 § Sander.v.Ginkel's revenge10:50, 12 February 2019 (UTC)
Unlike speedy deletion templates, these tags of No XX Since do not have explicit instruction on how to properly get rid of them. Are only admins allowed to remove them? Or can any user remove them after problems are fixed?--Roy17 (talk) 22:34, 10 February 2019 (UTC)
There is no general agreement about that. I used to remove those speedy deletion tags. After a few "out of process removal" remarks from admins (no sanctions though), I stopped doing that. It only stopped me from being able to actually see admins perform bad actions as I was doing their work for them. Now I would watch such file pages. An admin should remove the speedy tag after some time, possibly open a DR. If they delete the file instead, I go to COM:REFUND. Anyone is allowed to remove those speedy tags if they open a DR at the same time. - Alexis Jazzping plz00:43, 11 February 2019 (UTC)
How do I search my Upload log just for images that were deleted?
I am trying to find the original version of an image I took in a cemetery 2006 and added at sometime here. My notes said that the original was deleted and I had to upload a cropped version which lost the metadata. I want to find the filename of the original so that I can get it restored and read the metadata. RAN (talk) 21:04, 10 February 2019 (UTC)
En.wiki's page uses North Macedonia now as the country's name. Perhaps a large categories for discussion entry is in order, but I don't see anything wrong with updating categories so they reflect the new name of the country. Abzeronow (talk) 18:15, 13 February 2019 (UTC)
I'm not sure I understand what the problem is. They've been talking about this for quite a while. I'm not sure there's very much chance that it's going to be reversed. GMGtalk18:21, 13 February 2019 (UTC)
According to the link offered by Blackcat, this Michaeldsuarez account would be moving the categories but not the files inside of them. I agree a bot-like approach would be welcomed, less time-consuming. Strakhov (talk) 18:34, 13 February 2019 (UTC)
Of course @GreenMeansGo: , nobody talks about rolling the changes back. But the current situation is - at the best - very messy because it's being handled poorly and without a schema. As @Strakhov: said, such major changes must be bot-made, not hand's -- SERGIO(aka the Blackcat)00:27, 14 February 2019 (UTC)
If someone does manually what a bot might do otherwise, have we really lost anything but redundant effort? Is it causing any active damage? I presume much of what I currently do on this project can be taken over by a bot in the next 20 or so years when facial recognition becomes better tuned. GMGtalk00:33, 14 February 2019 (UTC)
Lasvegasvegas.com
Lasvegasvegas.com has been dead for a while.. I recently requested license reviews for Category:Images from lasvegasvegas.com that should have been requested at upload time. It appears the LR queue has now gotten to these.
Now that I think about it, we may also need to check in those cases of re-use that they didn't get it from Commons. Sadly, poker-base got it here. We may need to find some other way. - Alexis Jazzping plz16:54, 13 February 2019 (UTC)
Will look, eventually; but honestly, most of these images that we don't find in the Internet Archive should be fairly safe. They're not professionally posed, they're just "person at an expo taken by another person at the same expo", which we generally accept without difficulty, and the lasvegasvegas.com permissions statement is archived. Also, I reiterate the call for Alexis to reapply for License Reviewer status. --GRuban (talk) 17:38, 13 February 2019 (UTC)
@GRuban: I mocked something up in my incubator that would take care of most of these if accepted. I noticed many images were uploaded by an OTRS member and also some do have a license review. Me becoming a license reviewer.. Strakhov's poke at not reviewing my own essays suggests a "no", sadly. Ruthven's suggestion for me to apply for adminship is even more certain to go unanswered. (for more than one reason) If any position impairs my freedom of speech, I'm not interested. - Alexis Jazzping plz17:58, 13 February 2019 (UTC)
Strakhov was joking, they said so right there. You can be a license reviewer and keep your acidic essays; if you're talking about the contents of your user page, then I can't see anything there that says either "I will approve copyright violations" or "I will not approve free images I don't like". Admin, maybe not, but that's because that involves interacting with and even blocking people, and, yes, some of your user page comments may well offend people. I'd encourage you to soften them (admins, even deleting ones, are trying to make things better here too, honest), but it shouldn't be a requirement. I think we can trust you with not hurting the feelings of image files. See, you are knowledgeable and have a huge amount of energy. That's a valuable combination. We're a volunteer project, we don't have limitless resources, we can't let that get away. --GRuban (talk) 18:10, 13 February 2019 (UTC)
@Alexis Jazz: I was certainly joking (i would not do that anymore!). I liked some of those essays and, most important, I just can't see the relationship between writing essays-some-commons-users-do-not like and the ability of stating "OK" to a license in the internet. Strakhov (talk) 01:43, 14 February 2019 (UTC)
@Strakhov: I am glad to hear that! It's hard to keep track of who said what. There are some users who were overjoyed with the deletion of my essays, while some others were deeply uncomfortable with it and probably questioning what it means for freedom of speech on Commons. And just because I haven't filed a UDR yet doesn't mean I accept their deletion. I haven't accepted The Huntington deletion fiasco or the TechCrunch deletions either. If I am to apply for LR, I don't want that to be controversial. It all comes down to trust. @Sixflashphoto: you were one of the opposers on my original LR request. Would you still oppose me? - Alexis Jazzping plz02:26, 14 February 2019 (UTC)
Based just on what I remember form June to a few months ago; I still have some concerns on a penchant for conflict but that shouldn't stop you from LR. I sometimes thought you tried to work around policies rather than by policy but I have less of a concern about that then I had previously. I want to say I’ve been taking care of some very serious family medical issues now and these past few months so I haven’t been able to be around and my thoughts should be taken into account accordingly. -- Sixflashphoto (talk) 17:59, 14 February 2019 (UTC)
Removal of watermarks, watermarks being within scope
I thought it was permissible to simply remove a watermark from an image uploaded with one of our compatible licenses. But it looks like Commons:WATERMARK is only a proposed policy/guideline and I'm having trouble finding something definitive. To me, if we cannot remove them, images with destructive watermarks should simply be deleted, but I cannot find where anything about this is written. Of course, enwiki's image use policy forbids such destructive watermarks, which is perhaps why I thought that was the case here, too... — Rhododendritestalk | 01:44, 14 February 2019 (UTC)
While COM:WATERMARK isn't policy, you can work out something pretty similar from COM:OVERWRITE and COM:EDUSE. Under COM:OVERWRITE, removing a watermark will generally be a minor improvement, so the cleaned image can be uploaded over the watermarked one, but if someone objects then you should upload under a new name. Under COM:EDUSE, if a watermark is so disruptive as to make an image unusable (or useless given other images we have of the subject), it can be deleted. I think the major difference from COM:WATERMARK is that promotional but non-destructive watermarks are not usually a cause for deletion. --bjh21 (talk) 09:54, 14 February 2019 (UTC)
Do we have a tag to mark text that needs cleanup?
When I scan a document, or clip a newspaper article I add the raw OCR and duplicate it as Annotated text where I do cleanup and add wikilinks. I used to not add the text here, but to Wikisource, but many were deleted as not meeting the standard for Wikisource notability if they did not have a corresponding English Wikipedia entry. So do we have a tag to remind me to go back and do another round of cleaning up the text? See: as an example. RAN (talk) 03:21, 14 February 2019 (UTC)
Thank you! But I was looking for a category or other tag that reminds me that the OCR needs more cleaning. The text still has some gibberish. If I had a tag or category, I would be reminded to go back and continue cleaning up the text. RAN (talk) 13:53, 14 February 2019 (UTC)
On the Commons side, it might be worth asking whether transcribing and annotating text is inline with project scope and What Commons is not. Transcribing public domain text from a .jpg is probably ok, while annotating, wikilinking, etc risks creating essentially a shadow Wikisource/Wikipedia. On the Wikisource side, I don't see why published newspapers articles would conflict with Wikisources's Deletion policy, What Wikisource includes, or Wikisource for Wikipedians ("Wikisource does not use notability as a basis for inclusion. Instead, professional publication is necessary for a work to be added to Wikisource."), although casual viewing of Wikisource:Proposed deletions suggests they're somewhat more prone to delete rather than improve incomplete or problematic scans and transcriptions. --Animalparty (talk) 20:36, 14 February 2019 (UTC)
Analphabetism on Commons
There are a lot of people who don't know what capital letters, full stops, commas, etc. are for. Very basic things. So what to do with edits like this? Fixing it requires some effort for someone who uses Latin alphabet and I am rather lazy. Just revert it, especially that the caption is not too descriptive? --jdxRe:05:37, 14 February 2019 (UTC)
In this case, I'd revert it. It's as if someone had written "barbara durer" as the caption in English: probably worse than nothing. - Jmabel ! talk06:01, 14 February 2019 (UTC)
Probably "durer's barbara" given the case ending, but still not too useful. By the way, "analphabetism" is a semi-esoteric word in English (my spell-check doesn't recognize it)... AnonMoos (talk) 18:15, 14 February 2019 (UTC)
Thanks for the clarification, AnonMoos. Russian is probably not even one of my 10 best languages; I suppose any time I remark on something in Russian it should be taken with not just a grain of salt but a pound of salt. - Jmabel ! talk02:23, 15 February 2019 (UTC)
@Jmabel: My opinion is the same, so I have just reverted the changes. @AnonMoos: Spellchecker in my Firefox also doesn't recognize it. But at least one dictionary defines it (and at least one doesn't). Enwiki redirects "analphabetism" (and "illiteracy") to "literacy" and says inability to do so is called "illiteracy" or "analphabetism". Here, in Poland, we say "analfabetyzm". --jdxRe:03:47, 15 February 2019 (UTC)
"Watercolor drawings" are a thing, although it's debated where the line between drawing/painting can be um, demarcated. There's a spectrum from colored pencil washes to ink and watercolor in combination to gouache (basically opaque watercolor). I don't know if the Getty's classification scheme is representative of other museums. --Animalparty (talk) 09:52, 14 February 2019 (UTC)
"very much painting to me" = [citation needed]. i see a google search is very much split on these phrases. it is a deep philosophical discussion of demarcation of medium: is it by base support medium, application technique medium, or binder medium? how much of the activity on this site is personal interpretation unhinged from scholarship? see also PRP. Slowking4 § Sander.v.Ginkel's revenge13:24, 14 February 2019 (UTC)
Report copyright violation by a user?
Hello, I haven't been active for a number of years, only occasionally make small edits and such. I just came across a copyright violation by a user here, it concerns several images at least. How do I correctly report these? --Caranorn (talk) 16:10, 14 February 2019 (UTC)
I believe I have now completed my report. All images involved are minor derivatives of a single copyrighted original or a hybrid of several such hand drawn originals by a single author with minimal variation.~I will wait and see how the process goes and provide additional information if in my means and needed. --Caranorn (talk) 18:16, 14 February 2019 (UTC)
Notification of DMCA takedown demand - Video Call Santa
In compliance with the provisions of the US Digital Millennium Copyright Act (DMCA), and at the instruction of the Wikimedia Foundation's legal counsel, one or more files have been deleted from Commons. Please note that this is an official action of the WMF office which should not be undone. If you have valid grounds for a counter-claim under the DMCA, please contact me.
The takedown can be read here.
What is all this computer code for? are all the brackets and slashes and abbreviations on every page here supposed to do? Where is there an interpretation for them.
What are all the brackets and slashes and abbreviations on every page here supposed to do? Where is there an interpretation for them? How am I supposed to figure this out.
There are NO explanations anywhere for the layman to understand how all this coding gibberish works, what it means or even if it is important.
Nobody has explained that, tho I have asked several places on here. Who can TELL me this stuff and DO NOT refer me to any other pages, because none of them address this.
I am trying to understand and am not getting any help.
Multiple people have already tried to help you. Your user talk page, found here: User talk:Gsdcraig, contain many messages to that affect. Wikipedia also has a tutorial where you can learn how to edit here: w:Wikipedia:Tutorial. You can also avoid all the coding that you are talking about by clicking on the "Beta" link in the upper right hand corner and enabling the "Visual editing" beta feature. This will turn on a "what you see is what you get" type editor that allows you to edit pages directly. --Majora (talk) 03:07, 12 February 2019 (UTC)
consider this a periodic reminder of just how opaque the UX is to newbies. wiki'splaining will not help; not everyone can edit; there is a threshold of understanding of computer interfaces required. Slowking4 § Sander.v.Ginkel's revenge17:38, 13 February 2019 (UTC)
Maybe we should try and make a wiki without the use of any computers? Though I suspect that there will always be someone moaning about what’s this paper and pencil geekery, pushing for fingerpainting-only. -- Tuválkin✉✇19:11, 15 February 2019 (UTC)
Ramiro A. Fernández
Ramiro A. Fernández photo of Cuba, 1912
Hello, the above name is of a photographer who made popular collections of Cuban life photos, from about 1910s to 1950s. I cannot find exact information about his dates of birth or death. He is widely covered having collections in USA museums and many, many write ups, but no dates of birth and death and I read somewhere while I searched something about a Ramiro A Fernandez experience with the internet. I saw a something on the internet about a Ramiro A Fernandez using the internet himself. That would put this photograph in copyright so I just want to check if anyone is familiar with his story and ultimately if I should just tag it for deletion. ~ R.T.G14:43, 15 February 2019 (UTC)
Ah okay. Don't know how I missed that! It's just this one I am aware of so I'll just change it to "unknown", thanks o/ ~ R.T.G18:05, 15 February 2019 (UTC)
Multilingual file captions will be released this week, on either Wednesday, 9 January or Thursday, 10 January 2019. Captions are a feature to add short, translatable descriptions to files. Here's some links you might want to look follow before the release, if you haven't already:
Read over the help page for using captions - I wrote the page on mediawiki.org because captions are available for any MediaWiki user, feel free to host/modify a copy of the page here on Commons.
Leave feedback about the test on the captions test talk page, if you have anything you'd like to say prior to release.
Additionally, there will be an IRC office hour on Thursday, 10 January with the Structured Data team to talk about file captions, as well as anything else the community may be interested in. Date/time conversion, as well as a link to join, are on Meta.
Thanks for your time, I look forward to seeing those who can make it to the IRC office hour on Thursday. I'll add a reminder to this post once I confirm exactly what day captions will be turned on for Commons. Keegan (WMF) (talk) 20:18, 7 January 2019 (UTC)
Captions are scheduled to go live tomorrow, Thursday 10 January, between 15:00 and 16:00 UTC. The time window may change at the last minute, and the team my hold the deployment (or roll it back) if last minute problems occur. Should that happen I will keep you all informed, and I'll see you all at the IRC office hour tomorrow. Keegan (WMF) (talk) 20:13, 9 January 2019 (UTC)
Captions are live
Captions can now be added to files on Commons. There's a bug with abusefilter sending errors to new accounts adding captions, the bug is being investigated and fixed right now. IRC office hours will be in a little over one hour from now, I look forward to seeing you there if you can attend. Keegan (WMF) (talk) 16:47, 10 January 2019 (UTC)
Is there a way to turn this off? The huges block that appears between the image and the file information is hindering me. Jcb (talk) 16:59, 10 January 2019 (UTC)
It's not a feature with a built-in disable as it's part of the file page. I imagine a gadget can do this, if someone is inclined to make one. I'm hearing some issues about the box being very large for people with many languages listed in babel boxes on their userpage; this was done by design based on how Wikidata functions (we had feedback that people wanted the same behavior). If this is a big deal for people, we can probably work something out to reduce the size of the box if Commons doesn't want the same behavior as Wikidata. I will note that future SDC releases like structured metadata in statements will be hidden behind tabs. This is one of the only features that shows directly on the file page. Keegan (WMF) (talk) 19:44, 10 January 2019 (UTC)
@Mike Peel: thanks, it partly works for me. The caption block is gone now, but the large "Structured data" heading still remains at the top of real file descriptions. --Te750iv (talk) 20:03, 10 January 2019 (UTC)
@Te750iv: You mean the "Captions" header? Try doing the same as before but for "mediainfo-captions-header", if that doesn't work then a screenshot would be useful as I'm not sure if we're seeing the same thing. Hopefully a css id can be added to the box soon, which will provide a better handle to use css/js to change the display of the box. Thanks. Mike Peel (talk) 20:11, 10 January 2019 (UTC)
Sho'nuff. Thanks. Now (independently of my use as an individual) if someone could make this so it was a thing you could readily toggle on & off, that would be very good. How could that possibly not have been part of the design of this?! - Jmabel ! talk05:23, 11 January 2019 (UTC)
"If this is a big deal for people, we can probably work something out to reduce the size of the box if Commons doesn't want the same behavior as Wikidata." @Keegan (WMF): is THAT why Wikidata always shows me a long list of languages that are like gibberish to me? If only someone had told me! I've searched forever to figure out why it was behaving like this. (and failed) - Alexis Jazzping plz23:28, 10 January 2019 (UTC)
Alexis Jazz, I do not see any Babel box on your user page in Commons, so apparently your Meta page info is used, right? My suggestion: Remove all these lang-0 entries, and add only the one(s) you really speak on a certain level. Change your Babel box to something like this (the key here is in the switch and String module usage):
{{#babel:en-N|fr-2|de-1|es-1|<!--
-->{{#switch:{{#invoke:String |match |{{int:lang}} |%w+}}
|en=|fr=|de=|es=<!-- show nothing for spoken languages already added before -->
|#default={{#invoke:String |match |{{int:lang}} |%w+}}-0
}}<!--
-->}}
@Speravir: that's right, it somehow used the babel box from my global user page. I want to have all these lang-0 entries to make it clear nobody needs to complain to me in Chinese or Bulgarian when I replace an image on their wiki as part of regular maintenance. And Mediawiki shouldn't be using something on a user page as a preference setting. So my babel box is now botched, and everything is working fine once again. - Alexis Jazzping plz02:21, 14 January 2019 (UTC)
This change is craptastic for Commons. Was any consensus established for this, or are Wikidata purists forcing this terrible half thought out implementation on us Commoners? --Fæ (talk) 17:35, 11 January 2019 (UTC)
How can I get rid of these wretched annoying 'Captions' boxes - or at least, shove them down to the bottom of the page so I don't have to scroll for ages down every single image page to get to descriptions, categories, etc. PS I read @Mike Peel: 's comment above but I don't have a "css" (or if I do, don't know where it is, nor how to change it) - MPF (talk) 22:56, 13 January 2019 (UTC)
They've reappeared, even though I've still got them 'hidden' in my preferences - how do I get rid of them again, please? - MPF (talk) 23:13, 12 February 2019 (UTC)
Good practice ?
I am sligthly confused by the potential overlap between the description field and the caption. What are the good practices in that respect? Where can I find examples? — Racconish💬17:07, 10 January 2019 (UTC)
Racconish, think of this new element as a brief description, rather than the sometimes expansive descriptions we tend to put in the Information template. — Huntster (t@c)18:08, 10 January 2019 (UTC)
I can't speak to how others would use this but I will use it for the intended purpose of a caption which is to supplement media with words that provide a context. Something like "Information" may well include all kinds of extraneous details that shouldn't (e.g.) be inserted into an encyclopedia article alongside an image. —Justin (koavf)❤T☮C☺M☯18:37, 10 January 2019 (UTC)
(Edit conflict) Sure, if the description is short, then there's really no need. To be perfectly blunt, there's no need for these captions, period. Every scenario I can imagine is just as easily solved, and creates a more unified appearance, by simply editing the description page. If WMF really wanted to improve functionality, they would simplify the ability to add descriptions in different languages to the Information template that is already in overwhelmingly widespread use on the site. This new functionality just feels redundant. — Huntster (t@c)18:40, 10 January 2019 (UTC)
Potential benefit from these "captions" is vague and don't worth this cluttering of pages. If description of some file is not understandable at a glance, you can edit it. No need for another field. Fields for these "captions" are a junk, it would be better to remove it. Sneeuwschaap (talk) 18:32, 10 January 2019 (UTC)
No, I don't get it either. Can anyone please explain: what is the added value of the new caption feature to the already existing caption in file description? Is it the fact that captions can be made multi-lingual? Obviously no, as file descriptions may be multi-lingual as well. Are the captions maybe visible on other projects now? If yes, I don't get the sense, because, as we know, captions in WP articles are often context-depending and may vary for the same picture. Is it now easier to create a caption? I don't think so either: for each language, the caption still has to be translated/added by hand, just the same way as in file description. So, what is exactly the point of this new feature, please? On the other hand, it looks very poor now that the caption block is placed below the file, so you cannot see anymore the picture and the description at the same time without having to scroll. Any way to turn it off? --A.Savin18:37, 10 January 2019 (UTC)
From a technical standpoint, captions are like labels on Wikidata. They will be searchable through the API, making it easy to find/filter/pull captions from files as metadata. There are a lot of possibilities of what this can be used for, from filling in infoboxes, building lists for translation of important files needing a caption localized for a project or campaign, searching for and finding captions, etc. So in comparison to description templates, while they potentially contain similar data to a caption, their function and reuse purposes are very different. Keegan (WMF) (talk) 18:55, 10 January 2019 (UTC)
Sure. It's up to the community to decide (probably at someplace like Commons:File captions?), but here's an example I made just now as a community member. File:201San_Mateo,_Rizal_Landmarks_17.jpg has a long description that goes "off topic" from describing what's in the file, including OSM links and a licensing summary of sorts. So, I made a simple caption from the first line of the description. This is an immediate kind of use case that comes to mind, I'm sure we can catalog more. Keegan (WMF) (talk) 19:18, 10 January 2019 (UTC)
Thank you. I have to say this is not a very clear example for me, as it took me a while and some blue links clicking to understand it. It would be appreciated to see some more examples of what to do and what not to do. — Racconish💬19:33, 10 January 2019 (UTC)
(ec)That's still redundant and no good example. If the caption is too long and you are, say, using the picture in a WP article and need only its first sentence (like in your example), you just copy the sentence and add to caption in the article. There is no point to add an extra feature for it, let alone if the feature spoils the appearance of file pages on Commons. --A.Savin19:36, 10 January 2019 (UTC)
As I've mentioned above, while captions may contain the same information as a description, from a technical standpoint the implementation and reuse applications are completely different. Keegan (WMF) (talk) 19:49, 10 January 2019 (UTC)
Keegan, I'm sorry, but this is horrible. I work in software development, and I know bad justification of bad design when I see it. This is a textbook example of that. (Hint: It's founded in implementation rather than use cases.) Commons talk:Abuse filter is already getting hit with reports from users who don't give a tiny rat's ass about your "implementation and reuse applications". Real reuse would be to give the APIs access to the existing descriptions. Disable this monstrosity, and please, for once, try to get it right next time. —LX (talk, contribs)01:41, 11 January 2019 (UTC)
Would "SM Supermall in San Mateo, Rizal" be better or worse? Is it good or bad to have the same caption on two files? — Racconish💬19:44, 10 January 2019 (UTC)
Using that same file as an example, this is what media file page curation looks like; I skipped the captions thingy (and it was there, I did it before this other edit), as I went from Cat-a-lot (yes, I have cats showing on page top) to wikitext editing. Better find a way to gather data to fill up this new thing from existing workflows or see it gathering dust and left unattended. -- Tuválkin✉✇02:30, 11 January 2019 (UTC)
I would say the long term idea of that is to replace the image title with this caption to have the it multilingual and no problems with file-renaming. --GPSLeo (talk) 18:49, 10 January 2019 (UTC)
This is unlikely, as the file name is unique and cannot be replaced by a caption which may be the same for several files. --A.Savin19:12, 10 January 2019 (UTC)
I mean that the name displayed everywhere can be changed the filename dose not change but it will only be used to embed this file in a Wiki. But I would prefer to replace the Filenames by IDs like on Wikidata, of course there have to be redirects at the current filenames then. --GPSLeo (talk) 19:18, 10 January 2019 (UTC)
Note that a unique ID, stored in a base, is created when you create a caption for the first time, that is already working like that, that is called "entity" here. But we should no more see it : a few more infos. In any case it makes the images unique, even with the same caption. Christian Ferrer(talk)19:34, 10 January 2019 (UTC)
I get 4 lines for the captions: Nederlands, Deutsch, English and français. Why only these and not also Spanish? Why is after each language mentioned “Add a one-line explanation of what this file represents” and not in Nederlands, Deutsch and français? Wouter (talk) 21:07, 10 January 2019 (UTC)
@Wouterhagens: the lines are shown to you based on your babel boxes. If you add one for Spanish, it will show up too. This mirrors the Wikidata label functionality, I believe.
As to why the "Add a one-line..." is only appearing in English, some apparent issues are happening in syncing up with translatewiki.net, where MediaWiki system messages are translated. It's being investigated in order to be fixed, the instructions should be localized to language settings. Keegan (WMF) (talk) 21:12, 10 January 2019 (UTC)
These captions are a huge clutter imo, they should at least disappear when there is no info to show and/or show up below the standard infobox. --Trougnouf (talk) 21:47, 10 January 2019 (UTC)
I agree fully with you. The new tool in not integrated with the current description practices (the file name and the description field). As we have 3 methods how to describe the file, the description will be most likely incomplete and chaotic. --ŠJů (talk) 22:39, 10 January 2019 (UTC)
Just curious, but how are "Captions" structurally more beneficial than "Description"? I would imagine that "Captions" exist as a machine-readable format to help improve search engine results, but does that mean that machines will ignore “Description”? Do “Captions” work like tags the same way for example “#MeToo” works on Twitter? Why would one be included in “Structured Data” and the other shouldn't? Wasn't the whole point of structured data on Wikimedia Commons to organise everything? Wouldn't properties (like on Wikidata) fulfill this practice way better? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 07:14, 11 January 2019 (UTC)
@Donald Trung: good question. Above I likened captions to Wikidata labels, a brief summary/description of the rest of the data contained within. Captions are stored as wikitext within Wikibase, and the structural benefit is in and will be in putting them in Wikibase with the rest of the forthcoming SDC data. Coming in the next month is the next feature releases, depicts and other statements, which is that part that truly starts to organize things. Following that, we'll fill out the rest of the structured data like what one finds on Wikidata, with licensing/copyright, attribution, and advanced search coming by the end of the year. In other words, caption is a single part of the whole features package for Structured Data on Commons, and they will work and play well together once the project is nearing completion. Keegan (WMF) (talk) 17:45, 11 January 2019 (UTC)
I have to agree with Herzi Pinki’s comment below here, it baffles me that SDWC is being applied only to the files and not the categories, it's as if the Wikimedia Foundation heard complaints about how categories are being used and then thought about a new way to completely circumvent categories altogether rather than reinvent how to properly use them. Why not just structure the way Wikimedia Commons categories are used and integrate them better with Wikidata categorisation. For example on Wikidata an instance should be able to be linked to both a Commonswiki gallery and a Commonswiki category, but to this day Wikimedia Commons is listed on Wikidata as one of “other websites” and clearly an afterthought, linking Wikimedia Commons categories and gallery pages with Wikidata pages would also structure which properties should (automatically) be added.
Furthermore in order for people to find the best and/or most relevant pictures in a large category tree the way files in all these sub-categories should be accessible without having “to hunt through sub-categories” could be realised by adding certain filters like “show all quality images”, the ability to see the entire category tree and navigate it, how organised and structured statistics of how many files there are in a certain category and/or all of its sub-categories. There are many ways to add structured data to categories and it would eliminate the need to add certain properties to every file. I have the impression that the Wikimedia Foundation just wants to completely do without the current system of categorisation and completely miss its potential, the ways categories are organised reflect the type of structure the people who contribute to Wikimedia Commons prefer to work, ignoring this already structured system does a disservice to all of us and to the actual potential structured data on Wikimedia Commons has.
I can’t edit a “Caption” using the “Mobile view”.These are all things a bot can read and ascribe properties to, why should we do all of this manually?
Also let’s use “Captions” as an example, while editing using the “Mobile view” mode I can’t edit captions. But let’s use a random file 📁 to illustrate how shortcomings with “Captions” could be solved by using already existing “Descriptions”, let's look at File:Oligotricha striata exuvia2.jpg where no caption is noted, meanwhile the description “exuvia of pupa of Oligotricha striata from Southwest-Germany between the towns Rottweil and Tuttlingen at 700 m.o.s at 2014-06-04 out of garden pont” from this a bot could add properties like “Oligotricha striata”, “Photographs taken in Southwest-Germany”, “Photographs taken in June 2014”, and “Self-published photographs”. I actually have a system of how existing structures could be used to properly organise data but as I don't have that much time I'll draft it later. Also as Wikidata only has 56,238,701 pages (53,846,977 content pages) Vs. Wikimedia Commons’ 69,674,025 pages (51,041,630 content pages & 51,622,895 uploaded files) it's clear that while Wikidata may be “the sum of all other Wikimedia website” the fact that Wikimedia Commons has no notability standards means that there are a lot of subjects on Wikimedia Commons than in all other Wikimedia Commons combined. Now forcing everyone to basically re-invent the wheel, I don't think that Wikimedia Commons mirroring Wikidata is a bad idea, I just think that there are better ways to implement Wikidata’esque forms of structure at the “Category:” level rather than at the “File:” level. As I’m really busy now I’ll write a concept in a follow up comment. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:12, 11 January 2019 (UTC)
Now let me try to illustrate how existing Wikimedia Commons categories could be better used to structure data than only individual files ever could. Now let me illustrate how we could implement Wikidata’esque organisation with a fictional cash coin from a fictional Vietnamese Emperor. Let’s say that there is a category called “An Hưng Thông Bảo” (安興通寶) which is a subcategory of “An Hưng Emperor”, “Coins of the Nguyễn Dynasty”, and “Coins of French Indochina”. Now any file in the category “An Hưng Thông Bảo” would automatically be given the properties “An Hưng Emperor”, “Coins of the Nguyễn Dynasty”, and “Coins of French Indochina” after their master-categories, now let’s say that every property is also a family of properties, as a fictional property “Coins” is “P641” and then “Coins of Vietnam” is “P641.5849” and “Coins of French Vietnam” is “P641.99586”, now these properties are non-editable when included in a category in the same way that all pages that use a certain license are categorised in certain maintenance categories. Properties could then be manually added if necessary, let’s say that there is an image of an exposé in Paris where the An Hưng Emperor is present in the audience alongside other notable people, rather than adding the category “An Hưng Emperor” a property or tag indicating that he is present would suffice.
So how would these properties differ from contemporary categories? Well, they would serve very similarly to “tags” on other image-based websites, a person can click on a property and then introduce filters by searching certain subproperties or excluding certain subproperties. “Captions” would also be more fit for categories.
Don't think that it will be possible to collect structured data in such an unstructured way. The wiki way - we define the content, the rules and the tools in iterated and intermingled community processes - might not work here. Structured data (as it is now) for me is presenting a box without warning, without guidance, without concept, without transition strategy, without use cases, without purpose. Three or four years ago they told me that structured data will solve the bottleneck of categorization, now it seems that instead of easing some pain, structured data will add more pain by expecting community to enter descriptions twice. This will not work for the >50M Media we already have. I have disabled the box, like others. Full ACK to LX above. best --Herzi Pinki (talk) 17:56, 11 January 2019 (UTC)
Captions is only the first feature release for structure data - putting a wikitext file description into wikibase. I understand how captions may seem out of place when they're all alone, but there's some infrastructure behind them that had to go out first before we can add anything else. Within a month comes the first statement support, starting to shape out the structure of the metadata, with more to follow after that. Additionally, with further structure support comes tooling to help convert at least half of the file here without having to do everything manually (without touching the current summary/licensing/category system!). The release cycles for structured data are going to take a full calendar year to get everything out, and doing so without overwhelming everyone and everything. Keegan (WMF) (talk) 18:36, 11 January 2019 (UTC)
I've ignored the "enter caption" thingy for weeks as seriously bad idea, after all there are multilingual descriptions for all media, and I know how to add or edit those. Then enwiki started its odd WP:SHORTDESC crap (40 characters) with an intention to overrule Wikidata descriptions. Now commons gets 255 character captions overruling its established and working descriptions, for a total of four thingies (worst case) claiming to describe an item: d: + SHORTDESC + caption + {{information}}.
I tested it on a picture found in LinkedIn, File:ArtAndFeminism 2017 Livrustkammaren 06.jpg, it now has a German caption (maybe, that's what I tried), an English description, and a Swedish description. That can't be as it should be, the German caption should automatically populate the missing German description, and the plain text (no fancy markup, even no Interwiki) English description is perfectly suited as English caption.–84.46.53.12617:48, 30 January 2019 (UTC)
Proposal to remove captions feature
The captions feature is not ready for 'live' rollout across the entire Commons project. There is no opt out, there is no way of using the API to batch create captions, i.e. for GLAM sources where an equivalent to captions may already exist. The use case for captions has not been tested with the wider Commons community, in practice only an extremely tiny proportion of the files hosted on Commons will ever have captions. It remains unclear why having captions is worth the additional investment or distraction of volunteer time from adding meaningful multilingual descriptions. In the case of my own uploads of several million GLAM related photographs, not only would duplicating captions from the description data be pointless, it would probably result in less than meaningful clipped titles. From the explanations and discussions so far, the captions are useful for Wikidata, but a messy and poorly implemented feature for Wikimedia Commons that is more likely to confuse rather than add specific value to this project. If Wikidata wants to have captions, then let that be a plugin for Wikidata-ists, rather than forcing every Commons viewer and contributor to see this on every image page.
It is proposed that this feature is removed until there is a supermajority consensus vote on the Wikimedia Commons Proposals noticeboard to implement it. --Fæ (talk) 19:29, 11 January 2019 (UTC)
Comment I think captions feature is good for two reasons. Some images should carry some sort of accompanying text to briefly explain the subject and context. Take an image of Donald Trump. He's US president, a subject that would be interesting for people from all over the world. If each most popular writing scripts (latin, cyrillic, chinese, arabic, Devanagari, japanese, korean, etc. if by languages much more, EU alone has 20+) were to have one description, the description field ends up with a large chunk of text, most of which is foreign to any reader. With the new captions, it automatically displays the one the reader uses. The second benefit is that this short accompanying text becomes structured data that can be retrieved by machines. Perhaps what it needs is more customisation, like letting users switch on/off.--Roy17 (talk) 19:48, 11 January 2019 (UTC)
On "it automatically displays the one the reader uses", there is no magic solution. I'm currently shown 4 languages and these are not the 4 languages I'm most likely to understand. The pre-existing language select feature does pretty much the same. Nemo19:56, 11 January 2019 (UTC)
Support. Instead of offering a boon to vandals (IP included), developers should seek smart multilingual solutions (along the lines of my experimental {{3b}} template intended for descriptions). Incnis Mrsi (talk) 20:05, 11 January 2019 (UTC)
This is an odd critique - nearly all aspects of wikis by their very nature are "boon to vandals." This doesn't seem logical. -- Fuzheado (talk) 20:14, 11 January 2019 (UTC)
@Fuzheado: of course we spend resources fending off vandals and other disruptive users who use various gadgets against Commons. But there is a large crowd of Commoners qualified to rollback mess with categories or revert an abusive {{db}}. Not so for a vandal adding captions, for example, nominally in Sanskrit or Albanian. Incnis Mrsi (talk) 20:46, 11 January 2019 (UTC)
Oppose Another example of our proud tradition of immediately shitting on improvements to Mediawiki software. Maybe we try something different this time. Gamaliel (talk) 20:10, 11 January 2019 (UTC)
It is perfectly normal to expect a proper consensus process to be followed for significant project wide changes, not "shitting" on anything, but having reasonable respect for the unpaid volunteer community. No such consensus has been established before rolling out this change, in fact there has been hardly any meaningful engagement with the community to explain what this would look like, or the burden it introduces for all future work on this project. Actually, looking at discussion, nobody has even tried to work out how much applying captions this way in addition to the current way images are described will cost in unpaid volunteer effort. --Fæ (talk) 20:32, 11 January 2019 (UTC)
Oppose removing the feature. As stated by Roy17, this is the first step to the long overdue development of multilingual structured metadata and has been publicly discussed and proposed for many months at Commons:Structured_data. New things can be jarring, but this can peacefully co-exist and thrive alongside the existing norms. Nothing in the proposal identifies anything that would qualify as disruptive and functions like API access are in the pipeline. -- Fuzheado (talk) 20:14, 11 January 2019 (UTC)
Comment@Keegan (WMF) and Fæ: I can't support Fæ's proposal because "supermajority" is not defined and I don't think every new feature requires having a vote, but I do think the captions feature should be disabled for now. At the very least, there should be an option (without hacks) to disable it. The issue with huge boxes appearing needs to be fixed/made collapsible. phab:T213571 needs to be fixed. A clear plan on how this works together with descriptions needs to be presented. Realistic use cases need to be presented. - Alexis Jazzping plz20:20, 11 January 2019 (UTC)
On Wikimedia projects a supermajority vote is always a default of 60%. This is the norm for RFCs where significant changes to policy are involved. --Fæ (talk) 20:28, 11 January 2019 (UTC)
Oppose removal for now. This could be a potentially great way to expand the multilingual nature of Commons and make things work better with Wikidata. Let's revisit this in a month or two to see how rollout is fixed or improved on. Abzeronow (talk) 20:41, 11 January 2019 (UTC)
Let Mike Peel explain how to suppress this kind of edits in the watchlist… and yes, perhaps he could invent a solution making them invisible, but these edits likely will eat from my limit of events, clutter the browser’s memory and slow updates down, and will certainly interfere with such functions as rollback anyway. Incnis Mrsi (talk) 20:59, 11 January 2019 (UTC)
Have you asked the developers to do that by filing it on phabricator or elsewhere yet? Presumably it needs another option adding to the watchlist filtering. Mike Peel (talk) 21:10, 11 January 2019 (UTC)
CSS kludges aren't attractive for users not logging in (such as Be..anyone, who would support the proposal, while still telling you that supermajority was never a thing on c: d: de: en: m: mw: in 2005…2016, unlike superprotect.) –84.46.53.19818:23, 5 February 2019 (UTC)
WeakOppose, I can't say that I like the "Captions" feature, in fact I very much hate them as I have mistaken them for "File descriptions" a couple of times and after a file is uploaded I can't edit them using the mobile editing interface (which is bullocks!!!), but there is a lot of potential for them, and while I found the "feature" rather useless on Wikidata, "Captions" could be really helpful if they were extended to other pages on Wikimedia Commons beyond just files as they would be really helpful for categories. I really don't like them, in fact I personally hate them, but they do have potential. I would say that they might confuse uploaders and could seem to make the whole upload process more complicated for novice users and as us experienced users can't understand their exact usefulness I suggest that the MediaWiki Upload Wizard should explain what they do in the tutorial and give out more information on how to properly use them and what to fill in. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:20, 11 January 2019 (UTC)
You do not get to censor people from voting here, all contributors are welcome to vote regardless of whether they want to add comments. --Fæ (talk) 22:24, 11 January 2019 (UTC)
Comment We’re happy to see robust discussion around structured captions, and we'll keep working to improve and build new features for structured data. We're investigating the option to show/hide for all users so individuals don't have to mess with their own css (although you CAN do that as discussed below), and we are considering other design fixes based on your feedback. Additionally, for those interested, we've got things working with adding captions via an API. Here's some initial documentation and we'll get some additional info up on mediawiki.org next week. Thanks! RIsler (WMF) (talk) 21:39, 11 January 2019 (UTC)
Oppose As described by others above, this be feature is not a surprise or an insignificant change. It is highly publicised and a first “live” step in a major revamp of what Commons can do when combined with/supported by the power of Wikidata. Doubtless there will be bugs or unforeseen issues, however, it is hardly Assuming Good Faith to propose the removal of a major new feature on a Friday evening, shortly after it was turned on, because you don’t think it will be of much use or have much traction within the community. Wittylama (talk) 21:46, 11 January 2019 (UTC)
What is a surprise is that "captions" is where the Structured Data team want to start. Compared to dates, authors or copyright release, "Captions" are not currently part of Commons and Structured Data was promoted as not introducing new content to Commons, but to abstract existing data into better formats. Forcing 60 million new entries that need to be created across all of Commons content is bizarre and unexpected. Such a major change should have had a proper proposal to gain the community's consensus, not discussions on technical subpages that nobody follows, or technical posts that anyone not already involved will skip over; you know, because unpaid volunteer time is an ever more scarce commodity around here. This change should be reverted and go through a proposal when it has been properly tested and the impact understood. --Fæ (talk) 22:19, 11 January 2019 (UTC)
There is nothing in the software requiring captions for a file. A caption is completely optional, as far as development is concerned. Keegan (WMF) (talk) 22:32, 11 January 2019 (UTC)
I hereby authorise you, and any other editor, to ignore captions, or indeed any other part of Wikimedia Commons. In fact, not doing so has never been compulsory. I thought everyone knew that. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits23:10, 12 January 2019 (UTC)
You should be more protective with scarce resources such as "admin time", not everybody is free to ignore vandalism, spam fighters are not, by definition. –84.46.53.25114:17, 17 February 2019 (UTC)
Oppose, Captions are already adding value by being easily machine readable, one example is that they could already be used to improve accessibility for users with screen readers. Also there is an API that allows for editing of Captions so batch editing is possible. Abbe98 (talk) 22:15, 11 January 2019 (UTC)
Standard information templates are already machine readable, if anyone wanted to sort them out. The API changes have literally just been tacked on and at the time of starting this vote were in read only mode, so nobody has used these yet, more evidence that this was rolled out without understanding what the issues were. --Fæ (talk) 22:19, 11 January 2019 (UTC)
It wasn't as easy as just calling wbgetentities. The Caption editing feature itself has been using the wbsetlabel API action since it was deployed as far as I know and the wbgetentities was there 12 hours ago when I first used it. The Commons community was invited to contribute with feedback very early on and this feature should not have came as a surprise. Abbe98 (talk) 22:49, 11 January 2019 (UTC)
Oppose after all these years we are finally taking the first steps to deploy structured data on Commons and now you want to sabotage this effort? The grumpy old guys can just hide it in their Monobook css. Multichill (talk) 22:41, 11 January 2019 (UTC)
And not a hint of irony in this ad hom demeaning attack. Try to focus on the issue rather the people. --Fæ (talk) 23:12, 11 January 2019 (UTC)
@Multichill: am I grumpy and old because I don't want to scroll through two pages of structured data captions on every single file page? I don't oppose the idea, but it must be properly tested before rolling it out. And as Roy17 pointed out below, redirects are getting captions too, which doesn't make any sense. Things like that should be fixed before implementation. - Alexis Jazzping plz23:22, 11 January 2019 (UTC)
i am grumpy and old, and object to the pattern of disabling any change to UI. some stoicism is called for. the perpetual whinging against VE, mediaviewer, timeless, wikidata, etc, etc... would be amusing if it weren't a dead weight against UX design. no wonder the devs do not want to engage with the kindergarten, Slowking4 § Sander.v.Ginkel's revenge03:41, 12 January 2019 (UTC)
The Media Viewer – yes, a purely UI question. Not entirely so for the Visual Editor, as if—for example—some specific wiki code syntax became persistently mangled by it, then all users should be advised against that syntax. is not much about UI – it creates some new space. Who must look for it, Wikidatans will, perhaps? If we, experienced Commons users, eventually desert the corporation for some rival sites, then “devs” will not save Wikimedia with all their cool kludges. Incnis Mrsi (talk) 07:07, 12 January 2019 (UTC)
While it would be cheap and easy to suggest that kindergarten is where people are still struggling with basic literacy concepts, such as letter case, this ad hominem reference to a kindergarten does echo my feelings on the matter. Repeatedly we see how the community that is actually creating the content that has put some of the WMF websites among the most visited worldwide has its prefered workflows hindered by WMF employee’s pet projects, which often need to be either dismantled or more or less quietly set aside — where’s the responsible adults here and who are the whiny brats? -- Tuválkin✉✇11:55, 14 January 2019 (UTC)
i do sympathize with the knowledge workers being besieged by thoughtless coders, but this is not a pet project; they are not toying with you. you cannot cast you UI in stone; you cannot improve it without trying new things. the constant refrain of "turn it off" is not helpful, or healthy. Slowking4 § Sander.v.Ginkel's revenge01:20, 15 January 2019 (UTC)
Comment The motivation of caption feature is confusing, but from previous discussions it seems that it's intended an alternative to the filename. If we were designing Commons from scratch, an interesting design would be to give each file page a unique number (say an integer, like Flickr uses) which would be used when linking to the page, and then the multilingual captions would be available so that one could be displayed at the top of the page as the heading. This would be really convenient, since captions would be a) multilingual b) could be changed at any time without breaking incoming links. However, with the design presented, we still have filenames, and still have the inconvenient file renaming process. Now we also have captions competing with filenames as yet another way of describing the image. We also have a very poor user interface design, where the box for entering caption data for some reason has been given a lot of screen space, even for anonymous users who probably just want to see the image description, not enter a caption themselves. --ghouston (talk) 23:12, 11 January 2019 (UTC)
@Ghouston: actually, each file got a unique number because each MediaWiki page has a unique number. For files the pageid is combined with "M" to get a unique identifier like "M52611909", you can see it in this edit. Based on the ID you can get the json, rdf or the page. Multichill (talk) 23:58, 11 January 2019 (UTC)
That's the idea, although a link like [18] could be shortened obviously. I wonder if the entity numbers stay the same if the file is renamed. --ghouston (talk) 00:30, 12 January 2019 (UTC)
Oppose We already have over 50 million files and we really need to do something to turn them into a well-organised collection. Caption is the first step, probably not a perfect one but a much needed one. Please do not kill this attempt to improve Commons at the very beginning — NickK (talk) 23:17, 11 January 2019 (UTC)
Risible. May a reasonable person believe that yet another cumbersome Wikidata thing may actually help with collections? It may have some other merits, such as helping reusers, but it’s a pure hindrance for tasks of Commons proper which has all devices necessarily to manage collections. Incnis Mrsi (talk) 06:48, 12 January 2019 (UTC)
Oppose, this feature is really important to have, especially for smaller languages. Even if its not how everyone would like it to be displayed on Commons (the information is likely to be used in many more places). Maybe having a user preference option to display it in a different way would be helpful for people who dislike the current arrangement which they could define in an additional discussion? John Cummings (talk) 00:11, 12 January 2019 (UTC)
Will John_Cummings charge speakers of “smaller languages” for looking after respective activity and fighting vandalism? Are they willing to waste their precious time for it? Waiting for reports from outposts of “smaller languages” in the captions. Incnis Mrsi (talk) 06:48, 12 January 2019 (UTC)
WeakOppose I think the more sensible way forward is to allow users to turn of the feature, thus being able to build on the work already done without annoying so many users Oxyman (talk) 03:06, 12 January 2019 (UTC)
WeakSupport -- The bugs still need ironing our. The addition of the Captions field makes Upload Wizard even more cumbersome when uploading more than a single image: it's very easy to mistakenly add text meant for a description to a caption or vice versa, as I've already experienced. Plus, the caption box on file pages is garish and distracting: most users aren't going to interact with it, so it's an eyesore for them, and an eyesore plus an inconvenience to people that devote their time to curating files. --Animalparty (talk) 04:14, 12 January 2019 (UTC)
Oppose I think this feature will help increase findability of commons files, both inside and outside the Wikimedia ecosystem of projects. I also think it is an important first step to increase accessibility of files for people with visual impairments and audio impairments. Until now only a tiny group has been adding captions using complicated templating. This enables multi-lingual captions in a much more obvious way. I hope it will draw more contributors to Commons, and maybe bring back people who used to contribute to the old captions projects. I haven't used it much yet, but I am quite happy to see how prominent the feature is while viewing files on Commons. I expected it to be much more unobtrusive. I am not scared of vandalism. In my experience the more eyes, the better, and this should theoretically draw more eyes. Jane023 (talk) 09:42, 12 January 2019 (UTC)
Oppose Captions are annoying, but we have to get used to them. It's a step towards the right direction. Although for some time at the beginning they might be foldable, i.e. only a button should be visible. --jdxRe:10:07, 12 January 2019 (UTC)
Oppose I agree with most of what has been said against removal. Plus: the new system is not perfect? no suprise there and so what? it's new, it will be improved, give it some time. Maybe if in 6 months or 1 year, nothing changed, then we can reassess but let's give it a chance at least for now. Cdlt, VIGNERON (talk) 16:10, 12 January 2019 (UTC)
Oppose the feature is an important step towards Structured Data. Surely one can opt out by writing a common.js file. Rama (talk) 16:15, 12 January 2019 (UTC)
Support temporarily disabling the feature until the rest of Structured Data is live. It's just not realistic to expect Commons users to manually fill out several billion text fields without the rest of Structured Data, so having the feature at this point in time is rather pointless anyway. Jc86035 (talk) 08:43, 13 January 2019 (UTC)
I honestly don’t understand this line of argument. Who said anything about expecting users to manually fill out billion text fields? That’s obviously not going to happen. Really, it was the same when Wikidata was launched, pretty much empty, with the promise "when the millions of items will be created, then interlanguage links will be easier to manage!" ; as such, Wikidata was then also at that point virtually "useless" − you could create items manually (which I did, because it was fun ^_^) but that was obviously never really going to make much of a difference. Then we figured out bots to do that job for us. The same can, should, and most certainnly will happen here. Jean-Fred (talk) 13:01, 13 January 2019 (UTC)
"Who said anything", you ask. The new giant white box did, holding one third of my screen hostage to scream its desire that I (manually) "write a very short description". Are we talking about the same thing? The giant white box presumably being discussed in this sectionNemo14:29, 13 January 2019 (UTC)
The currently enabled version is clearly a net negative for Wikimedia Commons and just a way to scream for attention and make users give feedback on this project. Nobody could possibly think it useful to make all users see an empty box which takes one third of the screen and pushes away actual content, so I'd suppose users don't need to scream for it to be obvious. I do wonder if this willing torture of our users is going to last multiple days or even weeks: if so, it would be a symptom that whoever is in charge thinks of Wikimedia Commons as some kind of backend project that people don't need to use, is dead set on making the Wikimedia Commons' users' life miserable, and will do anything they can to avoid changing mind even on the most pointless "design" choices (see all the absurd things MediaViewer still does years later, just because we didn't push back strong enough to kill it when we could). If that's the case, then it would be a sign that the entire structured commons project is doomed, which would a pity given it's very important. If they can't even manage a reasonable deployment of such a minor function as empty multilingual description boxes (which just replicates what we already have with a slightly different technology), one can't help worrying what's going to happen with the bigger parts of the project. Nemo11:55, 13 January 2019 (UTC)
Two days later, the empty blockade box is still there, obstructing the users' work and usage of Wikimedia Commons. This is not promising. If it's not fixed by Friday, I guess we should start considering a more specific proposal, i.e. the hiding of all such experimental HTML via site-wide CSS until the thing is fixed. Nemo15:36, 15 January 2019 (UTC)
Comment The proposal does not specify what “Remove” means in this context (could be hide on the front-end, undeploy on the backend, or still something else) − as such, I don’t believe this poll will be very actionable. Jean-Fred (talk) 13:09, 13 January 2019 (UTC)
Well that's nonsense. It's perfectly actionable, as remove has only one meaning in the context of unwanted recent additions to a public wikiproject. Take the thing out by the root, burn it, and spread the ashes around. That's what every support vote is supporting and every oppose vote is opposing. — LlywelynII18:45, 2 February 2019 (UTC)
Oppose As others have said, we need to make progress on this front, and in my opinion this is not by removing things that are not perfect. We have to start the whole Structured Data somewhere. Now, if the frontend part of things needs to be changed (smaller font, collapsed by default…), I’m sure that the WMF would be more than willing to look into it, and lots of it we can also implement locally in the meantime − a few lines of code in the common CSS? Enabling the Collapse-Captions gadget by default for all users? If a consensus is reached for any such things, this can be implemented really esaily. Jean-Fred (talk) 13:09, 13 January 2019 (UTC)
Oppose not because I am any great fan of Wikidata (I'm not) but it does no harm to English-speakers and it may help users in minority languages. There are improvements to be made e.g. moving captions and other structured data when it comes along after the file summary information, it needed the css hack to make it hideable. The look I doubt anything can be done about as it's all web 2.0 & OOUI. Nthep (talk) 13:40, 13 January 2019 (UTC)
Support -- obviously not thought through. Temporarily disable the feature or make it non-mandatory at least. Otherwise I will end up, mistakenly of course, typing crap into the required "Captions"- or the "Description"-field whenever uploading something. Alexpl (talk)
Support Obtrusive, disintegrative, not very promising. Until recently, the description was contained at two places: in the file name and in the Description field of the Information template. To add a third place, without any connection with the current description system, causes only chaos and disruption. --ŠJů (talk) 22:36, 17 January 2019 (UTC)
StrongSupport Late to the party, but since I'm here... There's nothing the "captions" feature does except duplicate the information that should already be in the title and description fields. If Wikidata somehow needed more or less information than what those already provided, edit them. If there was some problem with bots understanding or using the description data, make better bots or handle the formatting on the server side. Disabling the current eyesore should be far more intuitive than personal css coding. Getting rid of it altogether is far more helpful than making everyone go back through everything we have, creating "y'know, descriptions, but shorter and with worse formatting". — LlywelynII18:36, 2 February 2019 (UTC)
special:diff/334447812 Captions on redirects should be redundant, innit? It'd be best to disable it on redirects. If this is not fixable in a short while, I think we should come up with a new bot, to 1. remove any captions on redirects on the spot; 2. issue templated warnings to user talk pages; 3. report recurrent offenders.--Roy17 (talk) 23:48, 11 January 2019 (UTC)
I tried to link both tasks on phab, but I'm now sure how to. @RIsler (WMF): can you (either as a team or alone) please care for the the proper maintenance on phabricator? --Herzi Pinki (talk) 02:13, 12 January 2019 (UTC)
poor descriptions of files (Proposal for improvement)
We could have better descriptions as we do have in many cases. If we have descriptions at all. My proposal to ease the task of entering captions to files (for the benefit of the WMF and the world), is: Add a copy button to the Upload-Wizard that allows to copy captions to descriptions and vice versa, on a single file level as well as for all files in a multifile upload. But respect individual changes after copy.
Furthermore the upload wizard could create captions from descriptions automatically as the last step, if the caption is missing. Reduce any wiki-text to the readable result and fail deliberately in case of line-limit is exceeded or the text contains non-convertible wiki-text. In most cases this will work. You can add a maintenance category for human attention when the conversion fails. --Herzi Pinki (talk) 01:39, 12 January 2019 (UTC)
Are any lessons going to be learned from the disruption that very poor design and poor engagement demonstrated in this forced rollout of the unrequested captions feature, or can we look forward to more of the same argument and beating down anyone with sarcastic derision by treating them as stupid "grumpy old men" who should be ignored or put in a care home?
I am genuinely concerned that the community will be split into Wikidata promoters that appear to want to revolutionize the way editing and reading of Commons works, and the long term Commons content creators that want to get on with content projects without having to learn to to use what could become an entirely different project. At the current time this feels like a repeat of the volunteer time sink Visual Editor disputes which tediously went on for bloody years and basically was split between those with project funding based on theoretical improvement, keen to show results, and the majority of volunteers that wanted a stable continued project. Thanks --Fæ (talk) 12:02, 14 January 2019 (UTC)
I think Fæ has a point here about how the feature was implemented, rather then the merits or otherwise of the feature. Oxyman (talk) 22:43, 17 January 2019 (UTC)
Braveheart, think different about the short-term solutions, maybe. I certainly don't see a "majority of volunteers" saying that no lessons can be learnt. Nemo13:01, 20 January 2019 (UTC)
certainly, there should be some training on how to implement open source UX design changes in a open source community. but this is a soft human resource management practice, so is too hard for the average coder. we should expect the lesson to remain unlearned. just as the "constructive feedback in open source communities" lesson is unlearned. Slowking4 § Sander.v.Ginkel's revenge17:12, 24 January 2019 (UTC)
The giant white box is still unfixed in that it hampers usage of file descriptions, ruining the Commons life of most people (especially unregistered users who cannot do anything about it). I guess we need to start considering how to remove/hide/move it by community consensus. Nemo08:38, 26 January 2019 (UTC)
I think the project already knows about and deals with vandalism, but yes of course the giant empty "comment here" space on every image is just asking for a huge uptick in stuff like this. If it weren't, it would be able to use the existing titles and description data. — LlywelynII18:54, 2 February 2019 (UTC)
Although there are a number of good images with recognizable Schinus terebinthifolia in them or that are clearly related in some way, there are far too many that were swept up with the on-topic ones from someone's flicker account because they had the botanical name in their filenames. I'm guessing that the photographer went on trips to Florida and Hawaii primarily related to the trees (they're a serious invasive threat to habitats in both states), and labeled all the images from those trips with the botanical name.
I'm busy enough at Wiktionary to be unable to spend time on this, but I thought I would bring this up so someone with more time might deal with it. Thanks! Chuck Entz (talk) 05:55, 16 February 2019 (UTC)
Uploaded files have the wrong name (users can not find them easily). Urgent name change, as this is happening-now eurovision. Change all files uloaded by "DollyStyle" to "Dolly Style", and change the category as well accodring to same name. Or, is it quicker if I re-upload with new names and categories? --Janwikifoto (talk) 10:44, 16 February 2019 (UTC)
Rename is better. As I will upload many more pictures of the group, and the new uploads will have the "correct" name. One name style is preferred. Re-upload and speedy delete opf the old ones is an alternative. Thanks, --Janwikifoto (talk) 21:34, 16 February 2019 (UTC)
@Janwikifoto: Please do not speedy-delete and re-upload to cause a filename change. If you wish to rename these files, then better add this to their filepages:
However be advised that other users may upload photos or other media of this band and there’s no requirement that those new files will have "Dolly_Style" in their filenames — and that then changing those filenames to add it would be against COM:FR. -- Tuválkin✉✇10:12, 17 February 2019 (UTC)
Ah great, now I know how to tag name chane! Question - how do I "mass-tag" the maybe 60 files, in one operation? (re-upload wastes bandwidth, but saves my personal time). I am aware that others may upload under another name, but I only think about my own pictures now. I would not generally re-name another users file, unless the name was totally wrong, offensive, or anything such. These files could just as well have been named "Melodifetsivalen...." in the beginning, makes sense for thos looking for such files, and we can go on with other reasonale name variations. Question - if I had filemove rights, would it be a simple operation for me to change the names, in one operation? Thanks --Janwikifoto (talk) 10:35, 17 February 2019 (UTC)
Today I uploaded media from www.securityconference.de to the 55th Munich Security Conference category, using the {{MSC}} template. This template references the imprint notice under [20], and the respective English version. I just noticed that both now return a ”page not found” message.
Does this mean that MSK no longer grants a cc-by-sa license on its media? Or that I should address my query to them?
I used to be a regular contributor on Wikimedia and the English Wikipedia but due to various other commitments my involvement has largely lapsed. I am hoping someone here can put me in touch with the right person to request a bot to do some clean up work on my uploads. I have in the past linked my images to my website www.flagstaffotos.com.au, but unfortunately this website has also lapsed. I am hoping that I can get someone to run a bot over all my files and replace this link with an email address?
Automated method to create Template and Categories
Hi, I am seeking for advice how to create Wikmedia Commons Template and Categorie Pages automated way. Would you please suggest the tools I need to look for. Thank you. Grybukas (talk) 15:00, 12 February 2019 (UTC)
Is it still imposible to upload kml files into Commons? In some NL Wikipedia articles I use Google my Map links. example: nl:Buurtspoorwegen van de provincie Brabant.
It works fine, but if I die and my Google account is cancelled, all these links disapear. I saved all my kml files, so in theory someone can reload them on his Google map and remake the links. A lot preventable hasle.Smiley.toerist (talk) 22:56, 13 February 2019 (UTC)
@Smiley.toerist: Yes, and I don't think it will ever come given that we now have Geojson support. You can now replicate this on commons alone (compare e.g. Data:Bannister Street, Fremantle.map for a very simple example). http://geojson.io helps with creating (drawing) the data from scratch and there seems to be quite a bunch of free online KML-to-Geojson out there. Wikivoyage (at least the en: edition) makes heavy use of these through mw:Extension:Kartographer, compare e.g. the dynamic map at the beginning of voy:en:Saint_Petersburg. I don't know if the kartographer extension has been enabled on any of the Wikipedias yet, though. --El Grafo (talk) 09:30, 14 February 2019 (UTC)
Though it might be interesting, knowing that one person with sysop rights proportionately has closed twice as many DRs as Delete compared to the average, does not in practice mean much. Administrators are attracted to different types of maintenance task, and so one person attracted to simple copyvio based deletions will be highly likely to have a very high Delete rate compared to another attracted to complex debatable copyright cases.
Thinking through the meaningfulness of statistics related to individual administrators would take a fair amount of further research, and does not stop with proving that person A appears to Delete or Keep three times as much as person B. --Fæ (talk) 12:57, 16 February 2019 (UTC)
I agree. My reason for asking is because on the German-language "Forum", a contributor wrote about a perceived increase in the number of deletions, and I now wonder about the actual numbers and trends. Gestumblindi (talk) 13:07, 16 February 2019 (UTC)
Had a look there, too, but haven't found any deletion statistics there either ("Previously deleted files" is just a report of new uploads of previously deleted files). Gestumblindi (talk) 19:25, 16 February 2019 (UTC)
I have extracted a number of statistics of uploaded and deleted files per month. I expect many things to influence this, from number of days of the month, special anniversaries (eg. Public Domain Day) to active contests, but having some numbers should be the first step before attempting to reach any kind of conclusion.
Platonides (talk) 22:12, 18 February 2019 (UTC)
Wikimedia Commons upload and deletion statistics per month
Month
Action
Count
201801
upload
662478
201801
overwrite
35995
201801
delete
52352
201801
restore
1110
201802
upload
723608
201802
overwrite
55067
201802
delete
45711
201802
restore
439
201803
upload
778723
201803
overwrite
64418
201803
delete
58628
201803
restore
1269
201804
upload
613293
201804
overwrite
73492
201804
delete
39981
201804
restore
549
201805
upload
724171
201805
overwrite
51671
201805
delete
41216
201805
restore
541
201806
upload
603980
201806
overwrite
52108
201806
delete
40781
201806
restore
1129
201807
upload
665610
201807
overwrite
38012
201807
delete
52893
201807
restore
2066
201808
upload
790859
201808
overwrite
40721
201808
restore
1254
201808
delete
43246
201809
upload
826464
201809
overwrite
44269
201809
delete
52579
201809
restore
1267
201810
upload
567080
201810
overwrite
92158
201810
delete
41844
201810
restore
526
201811
upload
573695
201811
overwrite
46070
201811
delete
46800
201811
restore
759
201812
upload
535198
201812
overwrite
37706
201812
delete
47792
201812
restore
804
201901
upload
569726
201901
overwrite
48963
201901
delete
61533
201901
restore
3519
Wikimedia Commons upload and deletion statistics per month / pretty printed
It seems that for January 2019, we have indeed an unusually high number of deletions (the highest since January 2018) compared to the number of uploads which hasn't increased proportionally. But I have no idea what the reason might be. Will copy your statistics over to the German discussion. Gestumblindi (talk) 20:38, 19 February 2019 (UTC)
Thanks, Gestumblindi. I have been digging a bit more at what could have been a factor in that there were more deletions this January (+13741 when compared to December, +9181 when compared to previous January). A few things I found that happened on January 2019:
Redcat Category:De (given name) keeps being populated with people with the words "de" or "De" in their names in spite the fact that neither is really a given name, nor even, in most cases, a standalone name word.
Can we finally accept that Wikidata, in spite of the lavish funding and all the praise from bigwigs, is simply an unreliable GIGO machine whose flunkies cannot find their way out of the proverbial wet paper bag — and therefore we need to keep our hard researched and mantained data stored locally in a way (i.e., wikitext) our community can easily go on curating it? -- Tuválkin✉✇10:27, 17 February 2019 (UTC)
Wikidata has a useful purpose, but the {{Wikidata infobox}} has a way of FORCING itself upon Commons by creating categories that in many cases don't need to be made, without the ability to override locally. We're all just supposed to accept what Wikidata spits out. --Animalparty (talk) 00:19, 18 February 2019 (UTC)
Ugh, Creator:Al Franken currently describes Franken as an "American-American Jew politician and writer", which is redundant, stupidly worded, and possibly offensive: we don't generally append race, ethnicity, or religion to occupations. But Wikidata blindly combines fields without thinking, because raw data lacks wisdom. --Animalparty (talk) 00:24, 18 February 2019 (UTC)
“Wikidata blindly combines fields” Sorry, but this is just plain wrong. That combination of fields is done here on Commons, using Templates and Lua modules stored here on Commons, created and maintained by Commons users. Now, maybe this should not be done, sure, and let’s discuss it, talk to the Lua module creator (@Jarekt: ), boldly change the templates/modules… This is not about Wikidata, but about what Commons users are doing with it. Jean-Fred (talk) 10:18, 18 February 2019 (UTC)
That one was pretty straightforward - the Wikidata entry simply had both Edward and Eduardo as Given Names. I removed Eduardo from there because Given Name shouldn't have other ethnic variants. It's the same for the "de" ones. It took me only a few seconds to track those down. Some of them were added by a bot, so I notified the operator. BMacZero (talk) 01:58, 18 February 2019 (UTC)
If you say so... Kings and their relatives are different from regular guys. At least in Spanish, their names are usually "translated" (popes too). You don't wanna store that translated names in Wikidata, [...psstt...], but concluding from there alternative "ethnic" [sic] variations should be never included (but one (which one?))... I wouldn't agree such a thing. Strakhov (talk) 04:06, 18 February 2019 (UTC)
I’m all in favour of an Edward cat being somehow cross-referenced to Eduardo, with a {{Cat see also}} or similar: it was the direct categorization that bothered me. I wouldn’t be the least surprised if Spanish or Portuguese sources translate the name, and there are quite a few less obvious equivalencies of names among different languages. Many years ago I was puzzled for some time by a historical atlas’s mention of various German kings & dukes called Louis, until the penny dropped that they were the same guys that most English-language sources call Ludwig. At least nobles are very rarely given shortened nicknames: here Duarte would be a much less apparent equivalent of Ted.—Odysseus1479 (talk) 04:21, 20 February 2019 (UTC)
I've raised my concerns at Module talk:NationAndOccupation. Just because we can categorize/label someone as an "American Jewish politician" or "African American female lawyer", doesn't mean we should, especially when it would result in in marking, othering, or ghettoization of the person from other members of the occupation. Nationality+occupation is almost always sufficient. Race/religion/ethnicity/gender, and intersections thereof, are often not defining and probably should generally not be used in infoboxes and templates. --Animalparty (talk) 03:00, 19 February 2019 (UTC)
Question about resolution of photos
I am in discussions with a photographer who is happy to submit one of her photos for an article I have been working on, and just working our way through the process. She has asked the question "May I ask if this means that anyone can use the low res image on wikipedia for whatever purposes (which is fine to me), or you'll be handing out the high res file to them too and it will be used for commercial purposes without my permission?"
I'm afraid that I'm not very cluey about things photographic, only having uploaded one or two photos in the past, so searched through the archives and FAQ, and only found this guidance. What I'm not sure about in the last sentence there (In case the full scale original is too large to process for the software, upload it anyway, but then please overwrite it with a scaled down version (around 6 megapixels in size); the full scale version will still be available in the upload history, and you can add a reference to it in the image description.) is whether this means that the full scale version would be available for others to use? Should she just submit whichever version she is happy with sharing? I just want to give her the right advice. Laterthanyouthink (talk) 02:31, 18 February 2019 (UTC)
We've had a lot of discussion about whether it is possible to free-license a low-res image without free-licensing the "work" in question, which would necessarily mean free-licensing high-res versions as well. Did we ever reach a solid conclusion? I don't remember. - Jmabel ! talk07:11, 18 February 2019 (UTC)
The discussion is here (long!). If I remember correctly, a former WMF person, then CC member, stated that depending on each country's legislation, a photographic shot might be considered as 1 work, independant of the image-resolution, which might have the consequence that releasing a low-res version under a free license might automatically include any higher-res version. This, sort of, contradicted advises in CC's FAQ of that time.
However, among the participants of our discussion there was some consensus, hope to remember correctly, that we would not act against the will of the licensor, aka author/photographer. I.e., if a photographer uploads an own mage to Flickr/whereever under a non-free license and also uploads a lower-res version of the same image to Commons, we would not grab the higher-res version from Flickr and claim it also to be under a free license. --Túrelio (talk) 07:27, 18 February 2019 (UTC)
@Laterthanyouthink: , also, just to be clear, images released under free licenses like {{CC-BY}}, regardless of their resolution, can be used by anyone for any purpose, including commercial, and not just on Wikipedia. Some people mistakenly grant permission under the assumptions that their images will only be used on a single Wikipedia article, but such restrictions cannot apply to material uploaded to Commons. See COM:LICENSES and COM:OTRS for details. --Animalparty (talk) 23:36, 18 February 2019 (UTC)
Thanks for that, @Animalparty: . I have sent the wording and further explained the consequences of CC 4.0 and she is happy with that. (She isn't using her award-winning photo, probably for that reason!) Laterthanyouthink (talk) 23:52, 18 February 2019 (UTC)
Laterthanyouthink although Commons has discussed this, the licences themselves are from Creative Commons. Their FAQ covers this question. As you can see, it isn't a yes/no, but I would go further than the above "might" and suggest "almost certainly does". If the two files are merely the same work saved at different resolutions, then I doubt any country would view these as separate works of copyright (after all, the MediaWiki thumbnailer, Google Image search, etc all generate different sized images automatically). The difficulty for us Commoners was that given two random files on the internet that appear to be merely different resolution copies of the same work, can we upload the larger one if the smaller one has a CC licence? What we can't easily know in general (without asking) is that resolution was the only difference between the two. It may be the larger one had additional processing done on it, or indeed could be a different photograph from a series of shots take, which just looks very similar. WMF/CC for a long time, gave misleading information about this and encouraged the practice of donating low-resolution copies as CC. That's only fine as long as you never release the high resolution copy onto the internet or give it to anyone without contractual obligations.
If your photographer friend is actively expecting to make serious money from their photo (e.g., with exclusive licensing through Getty) then they probably should not donate the small version as then it will no longer be "exclusively licensed". If they are merely worried that someone will take their photo and use it commercially without giving them a cut of the profits, but are not actively trying to sell or licence it, then I might suggest your friend reconsiders their mindset and stop being worried: they weren't going to make any money from it anyway. -- Colin (talk) 09:07, 19 February 2019 (UTC)
Thanks for that additional explanation, @Colin: - that's useful to know. I don't think that she was planning to make any serious money out of the photo she submitted, but I will follow up with this (although she may have already submitted the email - not entirely sure as she's in a spot with poor reception for a day or two). I think that she was just interested in understanding exactly what she was signing up for. The photo is 300dpi but I have no idea what other versions she has or may have published (if any). Laterthanyouthink (talk) 10:53, 19 February 2019 (UTC)
Laterthanyouthink, "300dpi" doesn't really mean anything for a JPG. It only really concerns a graphic designer who has chosen how large they intend to print it. The more common measurement for a JPG is megapixels (MP). If someone wants to print at high quality (e.g. 300DPI) then the MP will determine how big they can print it. For example, a 3000×2000 image is 6MP and could be printed 10" wide at 300dpi. -- Colin (talk) 12:17, 19 February 2019 (UTC)
Oh, I see - thanks for that extra explanation, @Colin: . (As I said up there ^, I'm fairly clueless when it comes to this kind of thing. But you have expanded my knowledge a little, and I appreciate that!) Laterthanyouthink (talk) 23:33, 19 February 2019 (UTC)
SVG and embedded javascript stripping
Friends on a site embedded various platforms. Now they're considering adding GIF and SVG formats too.
But my friend said...
"Maybe we'll support svg too but that's harder because they can have embedded javascript that needs to be stripped/sanitized. Svg isn't supported in a lot of systems because of this."
I wasn't even aware this was possible.
How does Wikimedia Commons deal with this issue and can you please share advice, links, and code? Asking for a friend. While I don't do code, I will pass it on.
I would usually tag such things with {{Retouched image}}, and replace the "source" in {{Photograph}} with {{Derived from}} referring to the source file. This is based on my experience dealing with images from Geograph Britain and Ireland, though: pictures from more serious archives may have other considerations. If you could tell us which bot is complaining, that might help. --bjh21 (talk) 15:54, 20 February 2019 (UTC)
Will you mind doing that for me to this photo, bjh21? And I will know then from the dits exactly how to do that? The numbered version is the original and the one with "adj" in the end is the one I changed the colours in and cropped. ~ R.T.G16:55, 20 February 2019 (UTC)
It's not in my opinion but it gives the message. If there is another I'll find it some time. Thanks v much o// ~ R.T.G19:04, 20 February 2019 (UTC)
The wording of the template seems to me to impart a special or local definition of retouched, broader than usual, meaning digitally altered. I suppose it could be given some aliases referring specifically to various types of alteration, but it’s generally simpler to settle on a single term despite the slight cognitive dissonance it may create in some contexts.—Odysseus1479 (talk) 20:07, 20 February 2019 (UTC)
The Wikimedia Foundation is planning a global consultation about communication. The goal is to bring Wikimedians and wiki-minded people together to improve tools for communication.
We want all contributors to be able to talk to each other on the wikis, whatever their experience, their skills or their devices.
We are looking for input from as many different parts of the Wikimedia community as possible. It will come from multiple projects, in multiple languages, and with multiple perspectives.
We are currently planning the consultation. We need your help.
We need volunteers to help talk to their communities or user groups.
You can help by hosting a discussion at your wiki. Here's what to do:
Next, create a page (or a section on a Village pump, or an e-mail thread – whatever is natural for your group) to collect information from other people in your group. This is not a vote or decision-making discussion: we are just collecting feedback.
Then ask people what they think about communication processes. We want to hear stories and other information about how people communicate with each other on and off wiki. Please consider asking these five questions:
When you want to discuss a topic with your community, what tools work for you, and what problems block you?
What about talk pages works for newcomers, and what blocks them?
What do others struggle with in your community about talk pages?
What do you wish you could do on talk pages, but can't due to the technical limitations?
What are the important aspects of a "wiki discussion"?
You can also help build the list of the many different ways people talk to each other.
Not all groups active on wikis or around wikis use the same way to discuss things: it can happen on wiki, on social networks, through external tools... Tell us how your group communicates.
Getting informed of recently added pictures in a category
Hello,
As some of you may know, I’m a marine biologist, and I’m working on identifying underwater pictures that are imported into Commons, to make them usable on wikis. Somebody had created this link, now dead, which allowed me to see at a glance all the latest imports to the sub-categories of the Category:Echinodermata (this phylum contains 7000 species and nearly as much sub-categories, so I can't patrol them all everyday). It was very practical, but it doesn’t work anymore. Would anyone know how to develop a similar tool? It was very useful for my work of curation.
It seems that the link works only with Internet Explorer but not with Firefox, I don't know why. About the OgreBot service, it looks interesting but I don't understand how to use it : the page begins with "edit this page" but I have no "edit" button on it... Thanks, FredD (talk) 06:10, 20 February 2019 (UTC)
The link worked for me using Waterfox. Only admins can edit the page directly, the instructions for all other are on the talk page User talk:OgreBot/gallery. I can add your wishes if you tell me the details (which categories you want to monitor, how should your gallery be named, how many subpages per month etc.) --Rosenzweigτ09:48, 20 February 2019 (UTC)
Hi Rosenzweig. Yes, I would be interested if you could add me on the Ogre thing : I would like to monitor Category:Echinodermata and all of its sub-categories (just like the catfood link did). You can call this gallery "Echinoderm news". There are not too much new items normally, so twice a month could work to begin with. Thanks and cheers, FredD (talk) 19:23, 21 February 2019 (UTC)
I uploaded this under PD-old-70, as the timetable is pre WW II. However it is also 'own work' due to the unusual circomstances of the picture. In 1990 the walls of the station where being renovated and the old prewar timetable became visible. Is keeping a scharp eye for unusual things also 'creative works'? It is certainly different than the usual scan of an old document.Smiley.toerist (talk) 12:40, 23 February 2019 (UTC)
PS: There is also a NL:wikipedia discussion about the year date of the timetable. It is 7 octobre and from 1935, because the line to Brussels was only electrified in 1935.Smiley.toerist (talk) 12:44, 23 February 2019 (UTC)
Just being observant does not create new works. The one who took the photograph of the timetables, however, can claim "own work", because the photographer in this case made a derivative (more than just a slavish copy like a scan) in deciding on composition, lighting and so on. --HyperGaruda (talk) 07:42, 24 February 2019 (UTC)
"Rectification" is kind of a vague term in this context. Do you mean that there's something wrong with the image itself, or with the image description? AnonMoos (talk) 05:55, 27 February 2019 (UTC)
Hi folks. I REALLY welcomed the new caption feature. While I took every precaution to give my uploads meaningful names (for English-speaking readers), other contributors didn't. And changing inappropriate filenames is no fun at all. The caption feature seemed to be helpful, and it allowed for different language versions.
But I will NEVER make a substantial contribution to Wikimedia or Wikipedia under the CC-0 license. If Amazon, Google, Facebook or any other commercial venture wants to make profit out of my work, they have to recognize my authorship (BY) and redistribute their derived work under the same license (SA). Alternatively, they are allowed to send me a job offer BEFORE taking my work for granted.
Sometimes in the last 24 hours the upload wizard has been updated, it requires the uploader to accept CC-0 for the caption line. As a consequence, I will stop contributing caption lines. And I think over, whether contributing to a Wikidata-dominated pile of poop (Wikimedia Commons), or another Wikidata-dominated pile of poop (Wikipedia), steered and paid by multinational tax defrauding a**hole groups like Google, is acceptable at all. Love, --Natalie Freyaldenhoven (talk) 21:02, 13 February 2019 (UTC)
Yep. If you see your previous captions being given CC0 status, you may wish to send WMF Legal a take down notice. --Fæ (talk) 21:05, 13 February 2019 (UTC)
This is really rather distasteful. When now editing a caption, you get the pop-up shown here. There doesn't seem to be an uncheck option for future edits, so with one click you irrevocabily accept the new regime. Jürgen Eissink (talk) 22:28, 13 February 2019 (UTC).
The design for the popup mimics the behavior of the CC0 notice on Wikidata. The acknowledgement is currently set by cookie here on Commons, but the development team plans on implementing a hidden preference as well. A user would be able to reset the warning by pressing the "Reset all my preferences" in Special:Preferences after this code is implemented. The development team is always interested in new ideas on how to show this notice without overloading the user for every caption edit made, so let them know if other options come to mind and we'll see if it's been considered already. Keegan (WMF) (talk) 22:50, 13 February 2019 (UTC)
You can point to the development team all you like, Keegan (WMF), but WMF should have announced, in all clarity, to all users a major change like this. But I think clarity is not part of the plan. Behavior like this might very well lead to a backfire you could not even have imagined. I, for one, am sort of disappointed, but I suddenly see quite clear what this is all about. And it ain't a pretty sight. Jürgen Eissink (talk) 01:57, 14 February 2019 (UTC).
Do you want a ban on expressing feelings and insights, Slowking4? Is that the affection and behavior you would like to see established? A prohibition on criticism? Not in my world and life, Slowking4. Jürgen Eissink (talk) 02:19, 14 February 2019 (UTC).
don't know why you want to rant to the point of farce. wikidata has good reasons to use CC0, if you you do not want to work with that license, boycott, see what little impact it has on structured data. Slowking4 § Sander.v.Ginkel's revenge02:28, 14 February 2019 (UTC)
I would be glad to have played you a little farce, but time will tell you if that is what I did. My indignation is sincere, whether you like trying to belittle it or not. Jürgen Eissink (talk) 02:41, 14 February 2019 (UTC).
While there is very little guidance on how captions should be worded, I suppose that a good caption would be simple enough to fall below the threshold of originality. A caption like "A picture of a chair" or "Painting by Pablo Picasso of a man reading" is probably not copyrightable anywhere. Anything more elaborate should probably be relegated to description field, which like all other text on Commons is CC-BY-SA by default. --Animalparty (talk) 22:48, 13 February 2019 (UTC)
I see now that this is already mentioned on COM:File captions: Only text which is so short that it is not copyrightable should be copied into captions, as it is likely that captions will be made available under a CC0 ("public domain") licence. (And yes, I'm replying to myself.) --Animalparty (talk) 02:47, 14 February 2019 (UTC)
Structured data on Commons must be CC0 out of necessity for the ecosystem of the project to interact with Wikidata, it's simply not optional. CC0 licensing only applies to captions and structured data spaces; the rest of licensing on Commons does not change. Keegan (WMF) (talk) 22:59, 13 February 2019 (UTC)
While I agree with you on the technicalities of having the caption fields being licensed as CC0 if we want it to interact with Wikidata (as it is currently structured), but I still am lacking the community consensus of requiring it to be licensed under such a license. Implementing something on a WMF-level and later claiming something to be "not optional" is totally overruling the community and playing the "superuser" card (even if I agree and am in favor of the feature). Simply having a formality-vote on the matter would have been much more beneficial for the relation between Commons <> WMF. --Jonatan Svensson Glad (talk) 23:07, 13 February 2019 (UTC)
@Keegan (WMF): Structured data on Commons must be CC0 out of necessity for the ecosystem of the project to interact with Wikidata This simply isn't true. Wikidata is licensed CC0, so SDC can take anything it needs from Wikidata. But that doesn't mean SDC has to be licensed CC0 -- we could equally well choose it to be licensed CC-SA or ODBL or whatever we wanted. If SDC was licensed ODBL, then one couldn't take content from SDC and transfer it to Wikidata. Which might be regrettable, but is hardly a "necessity for the ecosystem". In the other direction, data from wikidata would be freely combinable with data from SDC, so long as the combination was licensed ODBC (or whatever we went for for SDC). There genuinely was a choice to make here, and it is not clear that it was for the dev team to take, without consultation. Jheald (talk) 23:34, 13 February 2019 (UTC)
Which I think is misunderstanding what the captions are. They are Wikidata in Commons, not any generic form of structured data. It was created by and for Wikidata people.--Prosfilaes (talk) 23:48, 13 February 2019 (UTC)
Correction: Short texts have no copyright is fakenews, spin, a fiction, a deliberately misleading untruth. WMF legal will never give volunteers immunity from later claims of damage. Go read some short poems or read up on database rights. --Fæ (talk) 07:16, 14 February 2019 (UTC)
If captions are cut and paste, they will be short text extracts, not short phrases. Any copyrighted work can be cut up into short texts, that does not mean those extracts must be copyright free. Similarly many databases of images I upload require attribution, including the metadata. Systematically extracting that data and calling each piece CC0, is a failure to respect the moral rights, which can end up as a claim of damages. --Fæ (talk) 20:49, 14 February 2019 (UTC)
I don't buy your distinction between short text extracts and short phrases. Any copyrighted text on the Internet is made up of a series of numbers, 0-255 (or even 0 and 1), and these numbers are copyright free. At a certain point, when you assemble enough of these uncopyrightable elements into a longer work, it may be copyrightable. (Note that your interpretation calls into question any collection of possible copyrighted quotations, like Wikiquote.)
The US Copyright Office specifically refused to register "Sorry boys, Daddy says I can't date until I'm 30". Factual matters have weakened copyright; how many ways can you reasonably say "A stuffed Solenodon paradoxus at the Harvard Museum of Natural History, from San Domingo."?
Database rights are not an aspect of US law. Adding an entire database of works that have a claim of database on them does seem problematic. Why is CC0 any worse than a CC-BY-SA that doesn't bother clearly providing attribution?--Prosfilaes (talk) 22:12, 14 February 2019 (UTC)
So, I just checked the caption field again. There is still the requirement to publish captions under CC-0. No way, I won't contribute to Wikimedia Commons any longer. No captions, and nothing else. Bye, --Natalie Freyaldenhoven (talk) 11:00, 14 February 2019 (UTC)
Is the Wikimedia Commons community ready for another vote to remove "CC0 Captions", perhaps one not dominated by hardcore Wikidata fans? Similar to the Brexit vote, it is only after some time that everyone is a bit clearer on why speedily rolling this out, without having credible testing or an understanding of the consequences, might be damaging for Wikimedia Commons. In terms of copyright, this change is screwing around with the ethical respect for preserving attribution, fundamental to this project. --Fæ (talk) 11:37, 14 February 2019 (UTC)
Have you ever thought that maybe trying to stop Structured Commons is the equivalent of the Brexit vote. Much like Leave, some have an irrational hatred for Wikidata(the EU in this analogy). But sure, force the WMF to disregard the community here, what could possibly go wrong? Abzeronow (talk) 15:03, 14 February 2019 (UTC)
LOL! "Force the WMF to disregard the community" is the EXACT OPPOSITE of what having a consensus vote means. This really is bizarro Brexit style thinking. What next, having a vote is anti-democracy, having a vote is anti-consensus? Nuts. --Fæ (talk) 15:14, 14 February 2019 (UTC)
Some people here are like presbyters mongering fear for WMF, it's ridiculous and grotesque, not to say it's the voice of evil itself. Be aware of those that have something to gain in denying reason. Fascism and tiranny are not something of the past, and it's always little men that are eager to pave the ways. Jürgen Eissink (talk) 15:38, 14 February 2019 (UTC).
Correct me if I'm wrong, I think this is the first time I have been called a "fascist" or someone who wants "tiranny" because I asked if a vote might be a good idea. Very strange, do folks really think that the WMF is infallible, and unlike other companies, must never be criticised or held to account? At this point it does feel like complaining about this change, is as controversial as saying that not everything in the Bible is literally true.
Would anyone object to me creating the alternate account of Voice_Of_Evil, so that I can play up to being a figure for irrational hatred when I create proposals, or would that tip the drama scale over into utter farce? --Fæ (talk) 16:37, 14 February 2019 (UTC)
@Fæ: Dear Fæ, I wasn't referring to you, in fact quite the opposite. It must be my non-native English that is making my comment apparently wrong directed. I support your view, but not the views of some that I think you were opposing too. Sorry for the inconvenience - my fury must have been causing this misunderstanding. I will retract from this discussion, for now, since I am obviously doing it no good. I am not happy with the way WMF has introduced Structured Data, I think the whole project is a failure and in the current form should be canceled. Jürgen Eissink (talk) 16:57, 14 February 2019 (UTC).
Thanks, much clearer. Let's also be clear, the WMF is not evil, not even as evil as Google, and nobody working for them is a fascist or is known to worship Satan, all those I've met over the years have been jolly nice. Keep it non personal folks. --Fæ (talk) 17:17, 14 February 2019 (UTC)
Jolly nice people can be ignorant of carrying intrinsicly bad ideas. There is no need to point to other tech giants or external laws when the problem lies inside. Jürgen Eissink (talk) 17:28, 14 February 2019 (UTC).
Other = Google was introduced in the 1st paragraph by Natalie Freyaldenhoven. I like WikiData, I like CC0 even more, and I trust Google as far as I can throw them, but those captions without a plan how to sync them with descriptions are silly. OTOH folks insisting on some "copyright" for captions are beyond hopeless. –84.46.53.25115:13, 17 February 2019 (UTC)
The ethical respect for attribution is essential to this project? If you look at the Terms of Use, it says "When you contribute text, you agree to be attributed in any of the following fashions: Through hyperlink (where possible) or URL to the article to which you contributed (since each article has a history page that lists all authors and editors) ..." So a publisher can reprint an article for Wikipedia, that you wrote in full, with or without minor editing from others, and only have an obligation to print a note about CC-BY-SA from en.wikipedia.org/wiki/Your_Subject. In practice, the attribution on these captions is likely to be as good as an Wikipedia article; you'll almost invariably have a link to the Commons page wherein the editors can be looked up. Attribution on Wikimedia, except for photos, is a farce, and rationally, meaningfully assigning attribution is incredibly hard on something like a Wikipedia article, where the "real" authors are controversial and hard to figure out, and the authors who arguably have copyright interest can number in the hundreds.
I'm stunned by the number of people who seem to think that Wikimedia CC licenses are anti-business. Wikimedia doesn't use NC licenses for a reason. The CC-BY-SA is more than enough for big business to do amazing things within the license; it may be more of a restriction for open source authors who have to publicly distribute work, instead of avoiding copyright licenses by not copying work.--Prosfilaes (talk) 20:41, 14 February 2019 (UTC)
Sharing information and knowledge is key to the project. You don't get the point that through Wikidata and Stuctured Data WMF itself will be more and more able to exploit the submissions of its volunteers, the volunteers that are the reason for it's existence already. If monetizing the 'Data' is indeed the goal (and if not: why not use CC-BY-(SA)?), the whole project is entering a complete different universe. Jürgen Eissink (talk) 20:54, 14 February 2019 (UTC).
Exploit is an emotionally loaded word; it's one I'm sure the BSD developers would reject as they've rejected licenses like the GPL and CC-BY-SA. I don't understand what you mean by it. Do you consider Google's use of the Linux kernel in Android as exploiting the submissions of the volunteer coders on the kernel? At which point you're rejecting the Free Content idea that I think Wikimedia sees as being key to the project; certainly being involved in the Free Software community before Wikimedia existed colors my views on this matter.
Someone proposed making a translation dictionary from the English Wiktionary, but the problem was that if you take one line ("apple: tuffieħa) from ten thousand articles, the attribution required is larger than the text you borrowed. Wikidata suffers the same problem; any sort of mass use is likely to copy (probably uncopyrightable) text/information from thousands of separate items.--Prosfilaes (talk) 22:28, 14 February 2019 (UTC)
As far as I know Linux wasn't part of WMF. Every word can be framed 'emotionally loaded', but be assured that I meant to express the dominant meaning of 'exploit', whether someone else would go along with or confirm my suspicions (because that's what they are, nothing more, but certainly nothing less) or not. Every sentence – mine, yours – expresses some personal affection, that is no reason not to talk. The idea of Free Content becomes contorted when a Foundation that is established to promote Free Content suddenly would start to sell Free Content, and I cannot but sense that that is what will turn out to be the goal of Structured Data. It really only takes a few people to get implemented a tool that will serve first and foremost their personal interests – hat tricks like that are not rare and every growing organisation is prone to corruption. Convince me otherwise, the communication on the subject so far has not. Every apple within the project can without any legal problem be connected to every tuffieħa, and a dictionary can easily be compiled on Wikibooks, but indeed selling those same apples requires a special kind of salesmanship that I personally would not recommend to WMF. Jürgen Eissink (talk) 23:19, 14 February 2019 (UTC).
@Prosfilaes: The "oh we cannot expect attribution" is a weird argument to justify turning CC-BY text into CC0 text, because it simply is irrelevant in practice to Commons. On this project 99% plus of files only ever have one person editing the descriptions, dates or author entries. Even then, it may well be that it is not the editor than needs attribution, but the off-wiki source where the metadata or text came from. You cannot set up a project that harvests images and texts from the public, with an unambiguous legal commitment to attribution, and then years later change your mind, waive a technical wand, and haphazardly declare that text might be reused as CC0 and freely sold on losing all chance of attribution. That really does seem to make the word exploit entirely accurate, though I would also encourage the use of copyfraud. --Fæ (talk) 09:56, 15 February 2019 (UTC)
This seems inappropriately threaded. There's a big difference between the existence of CC-0 captions and the copying of material nominally under CC-BY-SA into the captions, and given the complexity of this thread, I think the latter should be pulled out into its own topic.--Prosfilaes (talk) 18:00, 15 February 2019 (UTC)
The first Free Content foundation, the Free Software Foundation, sold Free Content from day one, and it's generally in Free Software circles considered entirely reasonable for organizations to raise a little money by selling copies of their Free Content, provided it's not done in a way to make it proprietary. Now that the Internet has become so dominant, few see any point in doing so. Linux is part of the history of the WMF, with the success of the GNU project and Linux offering the basis for the idea that a bunch of people working under Free Content licenses could produce something like an encyclopedia.
A dictionary can't be easily compiled on Wikibooks while following the CC-BY-SA, because including the histories of 50,000 entries or links to 50,000 entries is technically difficult. But if a book is on Wikibooks, then by the clear intent of the CC licenses that Wikimedia uses and the GFDL that Wikimedia used from day one, the book can be sold by all and sundry. You have a right to feel about that as you will, but if that's what you mean by
That's not what I meant, Prosfilaes. Maybe my words don't suffice for you to grasp what I wanted to say, but I can not be more clear than I already was. I'm leaving Commons now. Jürgen Eissink (talk) 00:49, 15 February 2019 (UTC).
TBH, even I'm still waiting to see more stuff deployed before "throwing the structured commons baby", they should've been clearer when presenting this thing. I remember some WMF guys putting some effort in differentiating "captions", "descriptions" and "filenames" (oh no no no, they are not descriptions, this is a whole different thing blablabla). Now, when captions are already in Commons... everyone has (apparently) assumed these 'captions' are the very same thing a description is (maybe without wiki markup?) just... under a CC0 license. There are even talks about bot-license-washing (!) the copyright of our descriptions claiming "too short". Why didn't they start there? Strakhov (talk) 21:10, 14 February 2019 (UTC)
Which reminds me: why was it decided to invent a new piece of metadata for images? I thought structured commons was about increasing the efficiency the things we do, yet it starts with adding more work for no clear benefit. Why didn't we start with making descriptions multilingual? Just because it was too hard? Now we might spend years nitpicking about the difference between a caption and description (which probably does not even exist in some languages) but we should first focus on why we need such a distinction in the first place. In the long term we might have a huge technical debt due to having to maintain yet another parallel system which attempts to replace the descriptions but not quite (just like with Flow for talk pages before). Nemo08:13, 23 February 2019 (UTC)
I previously aired my grievances with the 6 year backlog of Categories for discussion. That's still not resolved (apparently some people think it's totally cool that it takes years to make a decision, so hi to the ents among us) but I'd also like to shine a spotlight on stale move proposals at Category:Requested moves, which creates much more of an eyesore of a notification template, but only appears to have a backlog dating back to the past 12 months or so. Some are rather clear cut and uncontroversial (I boldly moved turned one category into a redirect, hope I don't offend Morla), but the sooner they can be resolved or moved as uncontroversial, the better. Cheers, --Animalparty (talk) 00:15, 20 February 2019 (UTC)
Hey, thanks for trying to make it personal, Animalparty. If you'd like to help out with CFDs beyond the 5 contributions you've made there this year, your input would be most welcome. - Themightyquill (talk) 11:14, 20 February 2019 (UTC)
yeah, sorry i cannot muster much excitement. a sure sign of a broken process is a backlog, and it is a common feature of most processes on wiki. process redesign is called for. i have my own work lists, and am not interested in working broken process backlogs, after BLP hysteria. Slowking4 § Sander.v.Ginkel's revenge02:18, 24 February 2019 (UTC)
New feature implemented.....and I don't like it. How can I undo it?
Since about a week ago, the categories, etc in every file have colours.
That is, {{Wikidata Infobox}} is purple, all categories are blue, etc.
AFAIK, I haven't changed any of my preferences lately(?), so I assume this is something "sent from above."
@Jeff G.: I have never changed anything in the preferences, AFAIK, so this is the default. If anyone else have had I change in how they are presented things, please tell me, Huldra (talk) 20:52, 22 February 2019 (UTC)
@Huldra: could you please elaborate? Like, what exactly has colours? The text? Links? Backgrounds? Infobox fields? Is this in the desktop or mobile version? Even better: upload a screenshot like Jeff suggested. --HyperGaruda (talk) 07:50, 24 February 2019 (UTC)
February 22
template "published" - three questions
Three questions regarding the template "published":
Do the weblinks created in this template have any value in the context of SEO? Does it help or benefit the websites linked with it in some way?
I am wondering how to deal with a user whose only contributions to Commons is to put this template on the discussion pages of images that are used by one certain site (Special:Contributions/Ückref)? He's creating a "little" link farm here on Commons for this one website that uses a lot of images published here. For those who do not know that site: It is closely linked to the far-right political party FPÖ in Austria and the texts published there are basically propaganda, including rumors/lies about immigrants, representatives of other political views etc.
As I am starting to remove the template from the discussion pages of images I contributed, just to be sure: There is no rule that says, this template has to be set and kept?
Most outbound links from Wikimedia projects - including this template, which I just checked - use the rel="nofollow" attribute in the link. Thus, in theory they should not influence SEO rankings. However, given that these are the editor's only contributions, I find this tremendously fishy. If he does not reply to your talk page message with an explanation, I can hardly assume this is being done in good faith. Pi.1415926535 (talk) 00:40, 23 February 2019 (UTC)
I have checked theirs five random contributions and under the links given there "our" photos actually are used and properly attributed. Although all links point to the same website, but to different pages, so I don't think it is SEO, at least not a blatant one. --jdxRe:07:09, 23 February 2019 (UTC)
I did not assume they are using Commons pictures for SEO. They use them for a couple of years already because our images are freely available. What makes me wonder is the behaviour of User:Ückref and the reason why the only thing he does is to add the published template for pictures reused on that site. --Tsui (talk) 13:25, 23 February 2019 (UTC)
Hi. I consider myself pretty ignorant wrt this area of Commons. I'd wanna gather some feedback on to which extent is an enhancement creating these derivative works and using them in wikipedia and wikidata instead of the "original" ones.
These color enhancements are below TOO and therefore the new images are not derivative works. However, please, do not overwrite old files with them as not all people will enjoy your personal vision of colors. Ruslik (talk) 19:52, 24 February 2019 (UTC)
Thanks. The point is not about the nominal thing (whether calling these modifications "derivative works" or "minor photoshop changes which do not merit being called derivative works") but about to which extent are useful for "encyclopaedic" purposes (depicting Summer as Spring, and Central/Dry Spain as the "Wet/North Spain" because I'd like things to be green rather than brown). I could ask in other projects, but I guess people in Commons are more knowledgeable when it comes to photograph modification (and the thin line between enhancing a photograph and entering the realms of fantasy and Toxic Avenger movies). I mean, I could enter here, open photoshop and start heavily modificating the colour balance and saturation, spreading through wikipedia a more Alpine-meadow-ish and eye-candy-ish version of Lybian highlands. Thing is... when do that 'modifications' lose their "encyclopaedic" value? Strakhov (talk) 20:13, 24 February 2019 (UTC) PD: clarifying: these modifications are not mine
Ah maybe... Commons files are already on Wikipedia, if that helps. I thought it said he understands you can move from commons to... but he didn't want..., apologies o/ ~ R.T.G14:58, 15 February 2019 (UTC)
@Marc Lacoste: As far as I know there isn't a tool for this, because it rarely comes up and typically wouldn't be desirable. Can you give the specific example of what you are trying to do and why? - Jmabel ! talk17:05, 15 February 2019 (UTC)
@Jmabel: Fair use of files which we can't host here on Commons because we have insufficient permission, like some 20th Century photos of persons who are no longer alive. — Jeff G. ツ please ping or talk to me17:18, 15 February 2019 (UTC)
Yes, those are examples of valid reasons to do this. I was mostly trying to work out whether Marc wanted to do one photo or a bunch. Sounds like a bunch. Also, sounds like in each case there is going to need to be a different non-free use justification written on the Wikipedia side, in whichever Wikipedia is involved, and it will be impossible in some (e.g. the German-language Wikipedia has more or less the same criteria as Commons in this respect).
Unfortunately, no, there is no special tool to do this. I suggest that you "rescue" the full-res versions of the images in question to your own hard-drive; probably ditto for the info on the file page, in case that is deleted before you get to upload to Wikipedia; and expect this to be a manual task unless you can either automate it yourself of convince someone with the relevant skills to put the time into it. (FWIW, even the tools to transfer from the various Wikipedias to Commons are mostly pretty crappy, in my experience.) - Jmabel ! talk21:28, 15 February 2019 (UTC)
The question there was, whether files could be moved back after they had somewhen in the past been moved to Commons, and Johanna’s answer refers to this (content: restore on the the orignal wiki after deletion in Commons, needs an admin, of course). This does not help for files originally uploaded to Commons. — Speravir– 22:20, 22 February 2019 (UTC)
@Speravir: I am interested in an easy way to copy files which are here but shouldn't be here on Commons to other projects where they are acceptable. Move2Commons style would be acceptable, but FileExporter style would be preferable. — Jeff G. ツ please ping or talk to me16:50, 23 February 2019 (UTC)
Jeff, I am not the right one to be asked about this. I just wanted to point out that the question on Wikidata is more specific than Marc’s question here. — Speravir– 18:59, 23 February 2019 (UTC)
I don't know of an "easy" way, or specific tool, sorry - although one might be useful. I often do it manually, for instance: w:File:Jadavpur University Logo.svg which I [a] tagged copyvio here, and [b] transferred to en.wp as fair-use at the same time. It does worry me a bit sometimes that images might be lost to projects if folks do [a] but don't consider [b], and a well thought-out tool might help with that. Reviving the bot which SK4 points to above might be an option, I guess, if anyone has the time, resources and know-how - better still if deletion processes could present it as an option when appropriate - but I'm perhaps wishing too hard there... --Begoon15:42, 24 February 2019 (UTC)
@Jeff G.: As Speravir mentioned above, the FileExporter/FileImporter feature doesn't support moves from Commons to other wikis yet, but there's a Phabricator task for this request: T214280. I've added a link to this conversation in the ticket. -- Best, Johanna Strodt (WMDE) (talk) 13:35, 25 February 2019 (UTC)
Which bot is in charge of marking uncategorised new files? It should be tweaked to patrol files from the new FileImporter feature as well.--Roy17 (talk) 19:29, 15 February 2019 (UTC)
Bots have done this previously, e.g., User:YaCBot, but I don't know if any is running currently. There will also be files that have no categories because somebody removed them. --ghouston (talk) 01:54, 16 February 2019 (UTC)
I'm not sure if there's a way to detect files that lack non-hidden categories except by scanning recent changes, and that's not perfect because it misses changes to the categories themselves (when they are deleted or changed to hidden. Distinguishing hidden vs non-hidden categories is part of the problem.) --ghouston (talk) 20:57, 22 February 2019 (UTC)
Yeah, but you can only get that by examining the category. It would be easy to find files with no categories at all from SQL, but most files will have at least one hidden category, for the license. --ghouston (talk) 23:07, 22 February 2019 (UTC)
Sounds good. I suppose the hidden status can only be found by reading the wikitext of the category? Although, I wouldn't be surprised if there's a shortcut like a flag in the database, since the standard user interface somehow displays the hidden categories separately. --ghouston (talk) 22:13, 23 February 2019 (UTC)
@Ghouston: Just for the remark: The categories are nowadays not hidden anymore by default even for unlogged users, so the old name is wrong in strict sense, now. They just are shown in smaller font size after all other categories (well, you knew this part already) for all users. Check it out yourself. As a logged-in user you can disable this behaviour now. — Speravir– 19:17, 25 February 2019 (UTC)
Yes, that has been the case for users who get their preferences from Commons. However, a while ago a feature was added that retrieves user's global preferences from Meta instead. I think hidden categories will actually be hidden for many users. --ghouston (talk)
@Paclogic: Signing your posts on talk pages is required by Commons:Signatures policy. To do so, simply add four tildes (~~~~) at the end of your comments. Your user name or IP address (if you are not logged in) and a timestamp will then automatically be added when you save your comment. Signing your comments helps people to find out who said something and provides them with a link to your user/talk page (for further discussion).
Okay, but it should be spelled kilowatt (no capitals, no plural) per meter squared per nanometer = kW/m²/nm (proper superscript 2 and kilo in lowecase) = kW m⁻² nm⁻¹ (negative exponents instead slashes, as per SI rec.). -- Tuválkin✉✇14:10, 25 February 2019 (UTC)
February 25
Wrong translation of captions licensing notice into German
Sorry to raise another point about captions and SD. After changing the description of an image, I get the following message when saving:
By saving changes, you agree to the Terms of Use, and you irrevocably agree to release your contribution under the Creative Commons Attribution-ShareAlike 3.0 license and the GFDL. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Durch das Anklicken von „Veröffentlichen“ stimmst du den Nutzungsbedingungen und der unwiderruflichen Veröffentlichung deines Beitrags unter der Lizenz „CC0 1.0 Universell (CC0 1.0) – Public Domain Dedication“ zu.
Beschreibungsbeiträge I would translate as contributions to descriptions (google translate says description posts), which is anything else but the raw media file in my understanding.
tried again with uselang=en, then it says:
License for caption contributions only
By clicking "publish", you agree to the terms of use, and you irrevocably agree to release your contribution under the Creative Commons CC0 License.
So, you're right with uselang=en, but I still insist that you are wrong with uselang=de. I'm not a lawyer, but IMHO license related translations of texts must be waterproof and mean the exact same thing independent from any uselang=xx. Or is this to be understood as: whatever text I get presented in my upload process, only the original English text is the valid text? Only the original English text is the one I have to agree with?
This license text is presented at the end of the describe step. Nobody can guess by the German text, that this applies to captions only. --Herzi Pinki (talk) 02:07, 19 February 2019 (UTC)
The translation into German is simply wrong. "Beschreibung" is "description", so I agree with Herzi Pinki that "Beschreibungsbeiträge" translates as "contributions to descriptions". As translation of "License for caption contributions only" into German, I would suggest "Lizenz nur für Bildlegenden" or "nur für Bildunterschriften". I'm sure that this can be easily changed somewhere, but I'm going to sleep now, so I will not look further into this matter today. Gestumblindi (talk) 02:31, 19 February 2019 (UTC)
Do we really create license relevant texts with the wisdom of the crowd? Or by LEGAL of the WMF?
Wouldn't it make sense to turn it just the other way and put everything (Captions, Descriptions, annotations, results of cat-a-lot and VFC; but not the media itself) under CC-0 to be able to copy those information to the captions later using bots? (My first idea was in that direction).
No...no it wouldn't make sense since we cannot turn previous CC-BY-SA 3.0/GFDL material into CC0 without the express authorization of authors. That would be voiding their copyright. The only reason we can do CC0 for captions is because the captions are new and doing so now at the beginning is plausible. Previous material cannot be changed and I would very strongly oppose the splitting of licenses anymore than we already are being forced to do with captions. --Majora's Incarnation (talk) 15:22, 19 February 2019 (UTC)
@Herzi Pinki: I agree with Majora. Changing the licensing of descriptions would to lead to one of two undesirable effects: Either change the licensing of existing descriptions retroactively, which (even though it's IMHO reasonable to assume that most descriptions don't reach the threshold of originality needed for protection) would result in protests by community members who insist on their original licensing; or create a mix of old CC-BY-SA and new CC0-licensed descriptions, which would be a muddle certainly no one wants. Gestumblindi (talk) 20:25, 19 February 2019 (UTC)
@Majora: I don't see the text "Lizenz nur für Beschreibungsbeiträge" (the wrong translation of "License for caption contributions only") at the link given by you; furthermore, it seems that this "translatewiki" is its own wiki for Mediawiki translations and not connected to our SUL login? I haven't an account over there and, frankly, don't quite feel like creating one just for that fix, so please could somebody else fix it? Wherever the text might be located, please:
replace "Lizenz nur für Beschreibungsbeiträge" with "Lizenz nur für Beiträge zu Bildunterschriften"
Also, if possible:
check if "caption" is (wrongly) translated as "Beschreibung" in other places. We need to reproduce the differentiation between "caption" and "description" from English in German; "Beschreibung" is the established German term for "description" and should not be used for "caption" in our context. Another possible translation of "caption", apart from "Bildunterschrift", is "Bildlegende", which might in theory seem even better, because the word "Unterschrift" might be seen as implying a placement "below" ("unter") an image and "Legende" is more general, but it is a less common word, I'd say, slightly scholarly. Gestumblindi (talk) 20:15, 19 February 2019 (UTC)
I have an account on translate wiki (it is a bit lengthy to get one, you have to make some translation probes) - technically I'm able but I do not have any idea about processes on translate wiki. I was waiting for better ideas.
My proposal about changing everything to CC-0 of course was only for description stuff to be entered from now on. But I understand it will add extra complexity depending on the date the file was uploaded.
I have already changed Beschreibung to Titel ([23]), as there have been two Beschreibung for the caption and for the description, so the current situation is Bildtitel, Titel and Beschreibung. Which is also ugly. Why can't we use Filename (Dateiname) for what is now Image title (Bildtitel)? Which will end up in Filename / Caption / Description in English and Dateiname / Titel / Beschreibung in German. But "Bildlegende" is ok for now. We can change Image title to Filename later, for now we will have Bildtitel, Bildlegende and Beschreibung. Is this ok for everyone here? @Gestumblindi and Majora:
It still seems to be wrong for media that are not images (e.g. videos or audio). On meta level, my question about LEGAL was ignored. We obviously do make our own rules. --Herzi Pinki (talk) 20:47, 19 February 2019 (UTC)
Due to the wonderful flexibility of our German language, we could probably use the brand-new word "Medienunterschriften" or "Medienlegenden" instead of "Bildunterschriften" without too much raising of eyebrows by our German-language users (or "einzeilige Legende zu Medien"?)... still, currently in the German version users are told that they have to license descriptions as CC-0, and that's simply not the case, so it should be corrected quickly before continuing meta level discussions. Gestumblindi (talk) 20:54, 19 February 2019 (UTC)
Regarding the legal question... CC-zero for captions was not a decision by the Commons community but was rather imposed upon us as part of the "Structured data" project. Personally, I don't object, but some do, see Commons talk:Structured data. So, the discussion here is not about making any (new) rules at all - the descriptions were already licensed as CC-BY-SA, that stays the same and I don't think someone wanted to change that, the new thing are the captions which, including their licensing, didn't originate here. We simply have them now and it's all fine IMHO, but of course the German version should be correct. Gestumblindi (talk) 20:57, 19 February 2019 (UTC)
@Gestumblindi: would Metadaten-Beiträge (Legende, Strukturierte Daten) be ok? And please don't put me in a hurry. It will anyhow take some days until texts from translate wiki are deployed here. --Herzi Pinki (talk) 22:45, 19 February 2019 (UTC)
See my changes, now they are correctly describing the intention behind, the wording still might have to be improved (let's wait for complaints). Finally I have chosen the wording: Metadaten-Beiträge (Legende, Strukturierte Daten) in license context and Medienlegende elsewhere. --Herzi Pinki (talk) 23:10, 19 February 2019 (UTC)
@Herzi Pinki: Thank you. Although I agree with the wording as such, isn't this more than a translation? It's an improvement over the English text, but maybe we should rather try to translate it as accurately as possible, even if it's less clear? Gestumblindi (talk) 23:27, 19 February 2019 (UTC)
I find a problem, I discuss a problem, I fix a problem, I raise a problem. :-) Thanks for your contributions. I felt that deine Metadaten-Beiträge is a no-go for non-nerds. So I added the (Legende, Strukturierte Daten) explanation. The meta description of that message translatewiki:MediaWiki:Mwe-upwiz-license-metadata-content/de says: Content for instructions about metadata (e.g. captions) licensing (maybe you will only see that if you have an account). We could skip Strukturierte Daten for now, as this is the future. I prefer to make things as clear as possible (translating contribution in the same context with various meanings seems to be tough). If someone complains, we can change it again? --Herzi Pinki (talk) 00:03, 20 February 2019 (UTC)
And @Herzi Pinki and Majora: (also thanks for the additional pointers, Majora) If it takes days for the translations to propagate from translatewiki to Commons, maybe we should in addition fix the translation locally, as an emergency measure? I feel somewhat uncomfortable if we tell the German-language uploaders wrong stuff even for a few days... Majora, you say that editing MediaWiki:Mwe-upwiz-license-metadata-title/de should override the translatewiki version, but currently it is in English (despite being a /de subpage) and it seems that it didn't override translatewiki's (wrong) German text previously? Will it start to override it if I change it into German? Apologies for being so clueless in this area :-) Gestumblindi (talk) 23:34, 19 February 2019 (UTC)
The local version is not actually created. You can tell because there is no history tab. This is pretty common for interface messages that we just have as the defaults. It probably displays the English version because it is not locally translated and the default version of the message is created. Defaults in the MediaWiki space are strange when it comes to where it pulls from. If it is not created locally it defaults to translate wiki. That much I know. Worst case is you try it. It doesn't work. And you delete the page. It will default back to what it was before. I've done that. --Majora (talk) 23:40, 19 February 2019 (UTC)
Oh and yes, Gestumblindi. To my knowledge it takes around a week for changes to translatewiki to be pushed down to the other projects (but don't quote me on that). It is definitely not instantaneous. --Majora (talk) 23:50, 19 February 2019 (UTC)
Nevermind, I just grabbed the translatewiki version and copy/pasted it to our local page. Close all tabs. Reopen. And you should be good to go until the push comes from translatewiki. --Majora (talk) 00:03, 20 February 2019 (UTC)
Thank you very much! :-) So we can discuss the precise wording of the translation unhurriedly now, as at least its content is not wrong anymore. Gestumblindi (talk) 00:06, 20 February 2019 (UTC)
No problem. To be perfectly honest if you just want to keep the /de translations locally overridden you could do that. It is generally expected that localization translations would come from translatewiki but there is nothing that I'm aware of that says they must come from there. If having it local makes it easier to make small tweaks like this so be it. I really don't see a problem with just leaving it. --Majora (talk) 00:10, 20 February 2019 (UTC)
Sorry @all for writing German @Herzi Pinki and Gestumblindi: Herzi, ich stimme Gestumblindi zu, dass deine Übertragung mehr macht, als nur zu übersetzen. Das Wort Beitrag war streng genommen nicht falsch, „nur“ missverständlich: Gemeint war es im Sinne von „der Text, den Du beigetragen hast“. Die Ergänzung von „Legende“ war insofern nicht korrekt, weil (zur Zeit?) Captions als „Kurzbeschreibungen“ übersetzt ist (das vorherige Bildtexte war auf jeden Fall nicht korrekt, weil die Strukturierten Daten ja für alle Commons-Medien benutzt werden). Ich habe soeben contribution als „beigetragenen Inhalt“ übersetzt. — Speravir– 23:37, 22 February 2019 (UTC)
@Speravir: , ich sehe semantisch überhaupt keinen Unterschied zwischen Beitrag und beigetragenen Inhalt, außer dass zweiteres noch komplizierter ist (und dem vorgegebenen your contribution auch nicht entspricht). Sind Bilder kein Inhalt? Natürlich sind sie Inhalt, der Hauptinhalt sogar. Das englische Wording your contribution entspricht schon nicht der Beschreibung der Meldung, die sich nur auf Content for instructions about metadata (e.g. captions) licensing bezieht. Lizenztexte müssen für den User klar verständlich sein, sind sie das nicht, wird eventuell etwas verschleiert und es entsteht Misstrauen. Das wirkt sich dann auf die Beteiligung aus. Ich geh fotografieren, hochladen werde ich aber erst, wenn das hier klar formuliert ist. Wir sind jetzt wieder am Anfang, ich mische mich nicht mehr ein. lg --Herzi Pinki (talk) 07:47, 23 February 2019 (UTC)
Herzi Pinki, dass auch Bilder (oder besser allgemein: hochgeladene Medien) beigetragenen Inhalt darstellen, damit hast Du Recht, nur geht es hier doch in der Meldung um die neuen Strukturierten Daten, die keine Mediendatei sein können. Wenn dich bereits das englische your contribution stört, dann wäre besser – vielleicht besser in einem eigenen (Sub-)Thread mit anderem Titel danach fragen – zuerst darüber zu diskutieren. Es hilft jedenfalls nicht (oder nur Nutzern mit deutscher Einstellung der Oberfläche), in der Übersetzung mehr zu schreiben als in der englischen Vorlage.
Zu bedenken ist aber auch, dass sich das auf den Titel bezieht, der Stand jetzt License for caption contributions only heißt, caption contributions. Innerhalb der Strukturierten Daten findet man dann genau diese Überschrift Captions. Da kann und muss man mich durchaus kritisieren, denn das habe gestern ich selbst übersehen. Man muss im Deutschen also neben den beiden Upload-Wizard-Meldungen auch noch translatewiki:MediaWiki:Wikibasemediainfo-entitytermsforlanguagelistview-caption/de im Auge haben und eventuell erneut anpassen, vgl. Nemo‘s Beitrag (no pun intended) unten. — Speravir– 19:50, 23 February 2019 (UTC)
Note, the fact that it takes days for translations to propagate is a recent bug and regression introduced by the WMF deployment system: phabricator:T203737. You can search for translations of caption from English to German (currently they include Überschrift, Beschriftung, Legende, Medienlegende, Kurzbeschreibungen, Beschreibung, Bildbeschreibung, Galerieüberschrift). Nemo08:04, 23 February 2019 (UTC)
Yes, Nemo, and the right choice depends on the usage. But everything with Bild and Galerie is too specific here. Is this Special:SearchTranslations somewhere linked in TranslateWiki? — Speravir– 19:50, 23 February 2019 (UTC)
In a related discussion in German-language Wikipedia, H-stt pointed out an additional issue. Currently, the German-language translation of the Upload Wizards translates "Image title" as "Bildtitel" and "Caption" (above the caption box) as "Titel". That's not differentiated enough IMHO, but there's an issue in the English original as well - because now that we have captions, it seems strange to have both an "Image title" and a "Caption" if you don't know that image title is actually asking for a file name. Users are only indirectly told that the so-called image title becomes the file name: "Create a unique descriptive title using plain language with spaces. Omit the file extension, if any". I would suggest to change "image title" to "file name" in the English original and then, of course, fix the translations accordingly. But as said above, I don't think I will create an account in translatewiki, as it's not a SUL wiki (I really don't feel like adding another account for another platform to my long list of accounts right now)... Gestumblindi (talk) 00:20, 24 February 2019 (UTC)
except "image" and "file" are internal namespace jargon. we need a UX redesign, with some uploader surveys to pick the most uploader friendly nomenclature. anything less is projection. where is the upload wizard team? with native speakers since they seems to want to be multilingual. -- Slowking4 § Sander.v.Ginkel's revenge18:16, 26 February 2019 (UTC)
I wouldn't say that the concept of a file name (every computer user is naming files all the time) is "internal namespace jargon", or maybe I'm not quite understanding what you mean... Gestumblindi (talk) 00:18, 27 February 2019 (UTC)
The only way to avoid that would be to turn off subpages for the entire category namespace. It is a technical limitation of the mediawiki software. Not something that we can really fix I'm afraid. --Majora (talk) 01:31, 24 February 2019 (UTC)
is the cropped version of [24]. This original version is interesting (round pillars no longer exist in the Netherlands) and should be visible. Maybe with a light (levels) correction.Smiley.toerist (talk) 12:18, 25 February 2019 (UTC)
And how is that an explanation for Category:Buildings in Sydney defaulting to be categorized as a biology topic? This, by the way, is not a weird one-off: Last week I noticed the very same in two completely different categories in my watchlist, being both categorized via WD with two obviously unrelated categories concerning Biology. I wanted to fix that, but it vanished as mysteriously as it appeared (without any trace in the page history, which is 100% the Wikidata way and against all things wiki). -- Tuválkin✉✇01:02, 27 February 2019 (UTC)
Good idea, however a separate full list could also be made and maybe the number of deleted files (if such a thing is technically possible) per domain could also be listed ("full" meaning every external domain or maybe limit it for domains with more than a hundred (100) uploads). Anyhow the report should probably be posted as a subpage of "Commons:Database reports" and be updated on a daily basis. Could a Phabricator ticket be opened for this? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 18:22, 26 February 2019 (UTC)
Wow, this issue is getting stranger by the day. I'm not sure why this is happening. To clarify for others: previously (i.e. yesterday) the image appeared normal at all preview sizes except the original size or when downloaded, in which case it was rotated 90 degrees. Now the image is incorrectly rotated at all preview sizes, and is disrupting the many pages the image appears on. Tech wizards: would a simple bot-rotation request fix this, or is there something internally screwy with the file? --Animalparty (talk) 18:59, 27 February 2019 (UTC)
Reminds me of the few vertical videos I took with my previous phone: the orientation was fine on the phone, but once stored on my PC, it would turn to landscape mode regardless of the recording orientation. Perhaps there is something in the exif data that tells the Wikimedia software to turn the photo where it should not. --HyperGaruda (talk) 20:32, 27 February 2019 (UTC)
I hit the "Purge" button on it, expecting that would at least make it consistent. At least now the thumbnails are consistent with the original, but MediaWiki is apparently getting a width and height that disagree with the thumbnailer. When I've met this in the past it turned out there was a manufacturer-specific Exif tag that indicated the orientation of the picture, and only some bits of the system understood it. --bjh21 (talk) 20:52, 27 February 2019 (UTC)
Thanks @Jeff G.: . Well, now that it's right side up it appears stretched in preview mode: I'm not terribly familiar with the building but I think the intended orientation is portrait not landscape (hamburger not hot dog). Edit: But at least it seems to appear normal on articles. More weirdness! --Animalparty (talk) 23:33, 27 February 2019 (UTC)
Inappropriate pushing Palestine POV into file names
User:Huldra has been moving numerous files replacing the word "Israel" in their file names with "Palestine". I can't find any discussion reflecting community's approval of such action; anyway I consider it wrong and violating the NPOV policy. Even for photos from the "disputed territories" in Jerusalem, where a removal of the reference to Israel could be defensible, there is no reason to push Palestinian POV which has absolutely no backing in the state of facts.--Shlomo (talk) 22:06, 26 February 2019 (UTC)
Yes, I am moving aricles (just now) from "Jericho, Israel" to "Jericho, Palestine"; "Hebron, Israel" to "Hebron, Palestine", "Bethlehem, Israel" to "Bethlehem, Palestine", etc, etc.
FYI: NO officials claim that say, Jericho, Bethlehem or Hebron is Israeli territory. This is not even the official Israeli policy. (Although some extreme Israeli settler organisations claim this)
As for places in eastern Jerusalem: Israel claims this to be Israeli territory, but NO other country has accepted this.
I think we should react against those who are pushing for the extreme Israeli settler claims (contrary to international law) into various files, Huldra (talk) 22:14, 26 February 2019 (UTC)
I don't mind removing "Israel" from the file names, I oppose your pushing "Palestine" instead. Jericho, Bethlehem and a significant part of Hebron are under Palestinian administration now, but they were part of Jordan in 1950's, hence palestinizing filenames of photos from this period was also wrong. Photos from Israeli occupied Sinai have surely absolute nothing to do with Palestine. As for Jerusalem: Palestine claims it to be it's capital and no other country has accepted this. And the UN insists it should be an international territory and nobody accepts this either. I suggest to leave the reference to the country out of the file name in all these cases. If somebody desperately needs to know, where is Jerusalem situated, that's what the description page is for.--Shlomo (talk) 23:05, 26 February 2019 (UTC)
Shlomo, The file names should state where the locations are. We can't put Jordan in the title and we can't put Israel, the viewers need to know where these places are located when they view the image we can't make them without mentioning their location and Jordan is mentioned in the description of the images that you were referring to. Also what Huldra did wasn't pushing a point of view. It's stating facts. --SharabSalam (talk) 23:29, 26 February 2019 (UTC)
Well, presently the info box on, say, https://commons.wikimedia.org/wiki/Category:Dome_of_the_Rock say that it is in "Jerusalem District, Israel". Only Israel think this, the rest of the international community does not accept that it is part of Israel. Therefore, I think we should change it...does anyone know how? Also, about older pictures (1948–1967) of the West Bank: I think they should both have a Jordanian and Palestinian label. Huldra (talk) 23:36, 26 February 2019 (UTC)
I agree with Shlomo that the most neutral solution would be to just leave the country out of the file names. There is nothing in our COM:File naming policy anyway that requires the file name to contain the location. Such information can be presented through either file description fields or categories if it is absolutely necessary. --HyperGaruda (talk) 05:43, 27 February 2019 (UTC)
There's a kind of precedent, in that long ago User:Just1pin uploaded several rolls of film with generic names "Palestine occupation1.jpg" through "Palestine occupation999.jpg" (or whatever) despite the fact that many of the photos were taken in Tel Aviv! That was received quite poorly, and most of the photos were deleted and reuploaded with proper descriptive names (it wasn't so easy to rename images back in those days). I can't find the centralized discussion of this, but File:Urinal in Ben Gurion airport.jpg was one of the images originally uploaded as "Palestine occupation247.jpg" (or whatever)... AnonMoos (talk) 08:03, 27 February 2019 (UTC)
When editors upload files named "Hebron, Israel", or "Kedumim Israel" (see eg [link]), then that can be compared with uploading files of Tel Aviv named "Palestine occupation247.jpg". I have changed them, Huldra (talk) 21:43, 27 February 2019 (UTC)
The facts are that exactly 0 countries in the world claim that Hebron (a city on the West Bank) or Kedumim (an illegal Israeli settlement on the West Bank) are in Israel (only some extreme Israeli settlers claim so). Not even the Israeli govenment claims this. It should be uncontroversial to add, say Palestine to Hebron. (There are Hebron's many other places, too)
As for places in East Jerusalem: Israel has oficially annexed it, but no other country has accepted this. Reading Commons:Disputed territories, I think that removing both "Israel" and "Palestine" from the file name would possibly be the best solution for places here, Huldra (talk) 21:37, 27 February 2019 (UTC)
Deleting previous versions of files
Hi,
Is there any way to delete previous versions of my uploads, for example if I have subsequently uploaded a higher resolution version?
It's possible (see COM:REVDEL) but you'd need a good reason. For instance, if the first version was a copyright violation but the new version was not. If the old version really is just a scaled-down version of the new one then there's no reason why the old one should be deleted. --bjh21 (talk) 12:37, 27 February 2019 (UTC)
The Wikimedia Foundation is planning a global consultation about communication. The goal is to bring Wikimedians and wiki-minded people together to improve tools for communication.
We want all contributors to be able to talk to each other on the wikis, whatever their experience, their skills or their devices.
We are looking for input from as many different parts of the Wikimedia community as possible. It will come from multiple projects, in multiple languages, and with multiple perspectives.
We are currently planning the consultation. We need your help.
We need volunteers to help talk to their communities or user groups. You can help by creating a discussion page and hosting a discussion. You can sign up your participant group here.
You can also help build the list of the many different ways people talk to each other. Not all groups active on wikis or around wikis use the same way to discuss things: it can happen on wiki, on social networks, through external tools... Tell us how your group communicates.
Soon, we will invite you to leave individual feedback about talk pages and other ways that you communicate. Then we will discuss ideas with the group.
Hope not. I already am on email lists, IRC, Twitter and Telegram, so already too many Wikimedia related comms to follow. --Fæ (talk) 22:27, 18 February 2019 (UTC)
Are these images free from copyrights or would they get nominated for deletion
File:Haram 40.jpg — Preceding unsigned comment added by SharabSalam (talk • contribs) 12:03, 24 February 2019 (UTC)
Hi, so yesterday I uploaded some photos that are according to DASI free from copyrights ( DASI is a project that share photos of ancient Arabian inscriptions). I want to know if I should continue uploading other photos and whether they are really free from copyrights or not according to Wikimedia policy. This is the first time I upload images that aren't my own work and I don't want to waste my time uploading photos and then they get nominated for deletion. Thanks in advance--SharabSalam (talk) 12:02, 24 February 2019 (UTC)
I see. These are plates from a book published in 1992 by Christian Robin. On Commons, photographs of 3D objects are not considered as mere mechanical reproductions, therefore IMO these should be considered as still in copyright as far as the photographer's work is concerned. — Racconish💬12:54, 24 February 2019 (UTC)
Sorry for replying so late. I don't understand; the site says they are free from copyright, does that mean Dr. Robin has made them free? Because I think there is almost no chance that the website would state they are free from copyright while they aren't.--SharabSalam (talk) 13:28, 24 February 2019 (UTC)
IMO, the only 2 ways for these images to be "free of copyright" are to be non eligible for copyright protection, which is unlikely in France where the book was published, or to have entered the public domain, which is too early. — Racconish💬13:40, 24 February 2019 (UTC)
The other way would be if they are older photographs that merely appear in that 1992 book, which from the style of the photos looks at least possible. Does the book have photo credits? I wouldn't presume that the author of a book is the photographer. - Jmabel ! talk18:05, 24 February 2019 (UTC)
In any case I really doubt that a project like DASI would state that an image is free from copyright while it's not. I will try to get access to Dr. Robin's book and get more informations about who took the image. I think what Jmabel said could be true since the inscription was found long time ago (before the 19s) but I can't tell if Mr.Robin was the photographer or not considering that he has been in Yemen--SharabSalam (talk) 15:15, 25 February 2019 (UTC)
According to the extract there, the book is a compilation of the authors’ and earlier researchers’ work, so some of the photos could indeed be quite old. Note also that Italian law (if & where relevant here) gives a short term to non-artistic photos, and France (ditto) seems to have a high TOO for photos in general.—Odysseus1479 (talk) 21:38, 25 February 2019 (UTC)
Hi, I am the same editor who started the thread I just changed my username into English. Anyway, I still can't have access to that book. In the meantime what do you suggest I should do?. How can I get more opinions about this issue??!. I want also to point out that the website states also that the inscription(Haram 40) was used in other books that are from the 80s and 90s. Also in other inscription images (that I didn't upload) the website states (when images aren't free) that they were used with kind permission from the author so it unlikely that the site is lying about the copyright of unfree copyrighted images. As of what Odysseus1479 said; Italian law might be relevent but I am not sure..i am not an expert on these things. That's why I asked here. Thanks--SharabSalam (talk) 22:38, 26 February 2019 (UTC)
Ok I just found the book[25]. First the photo was taken from kunsthistorisches museum, Vienna, Austria. Robin says this under the image (Sigles: Gl 1052 = CIH 523. D'après Ryckmans G. 1945, pp. 1-2, le sigle ne serait pas 1051 [sic} mais l 789 (d'après une communication épistolaire
d'Adolf Grohmann); précédemment, Fritz Homme! avait donné Hofner 1944 ne permet pas de résoudre la contradiction.) I dont know French and google is not helping in this.
A friend of mine told me that CIH 523 means that the image is in the collocation book Corpus inscriptionum semiticarum ab Academia Inscriptionum et Litterarum Humaniorum conditum atque digestum. and Gl 1052 means it is in Glaser collocation. Both are too old. note I just saw that the website actually say that the other name of inscription is CIH 523 and Gl 1052--SharabSalam (talk) 00:57, 27 February 2019 (UTC)
Could you give a page number in that book? I can't readily find this, and it looks like the transcription above is imperfect. I'm guessing this will be OK to use, but I'm still not sure. - Jmabel ! talk02:40, 27 February 2019 (UTC)
OK. Transcribing more accurately (it was only a little off): "Sigles: Gl 1052 = CIH 523. D'après Ryckmans G. 1945, pp. 1-2, le sigle Glaser ne serait pas 1051 [sic] mais 1789 (d'après une communication épistolaire d'Adolf Grohmann); précédemment, Fritz Hommel avait donné 1652. Hofner 1944 ne permet pas de résoudre la contradiction." But all that is just about the object itself. There's nothing here about when the photo was taken, which is the issue for any possible copyright.
Just in case it's not clear: the issue is that the object itself is sufficiently three-dimensional that a given photo of it inevitably involves some creative choices, and hence is copyrightable. Working out its copyright status is going to involve knowing in what country it was first published, when it was first published, and (for most countries) who took the picture, whether they are alive, and (if they are dead) when they died. Sadly, so far we have nothing on that.
I tend to agree that DASI probably know what they are doing, but there is a chance that they overlooked the issue of the object itself being three-dimensional. Maybe it would be worth contacting them to see if they can help sort this out.
For what it's worth, if it were up to me personally I'd trust that it is public domain, but almost certainly someone will say that under Commons' "precautionary principle" we haven't got enough evidence of that, and I'd hate to see you put a bunch of work into this and still have it deleted. - Jmabel ! talk05:10, 27 February 2019 (UTC)
The photo itself can be found in part B (contains all images) of the book, which starts at ~½ of the document. You will have to scroll down to Pl. 15. Then again, nothing useful there about the photo's copyright status. Going back to the textual description, page 110 has a line about Illustration, saying "CIH vol. II, pl. XXI; Janata 1989, p.68 (Kat.Nr. A 5 = GI 1052)." I wonder if this is where the picture came from. --HyperGaruda (talk) 06:12, 27 February 2019 (UTC)
Thanks Jmabel, I will try find where the image is originally from and do more research about it
HyperGaruda, CIH means from this book collection: Inscriptiones Himyariticas et Sabaeas Continens. Corpus inscriptionum semiticarum ab Academia Inscriptionum et Litterarum Humaniorum conditum atque digestum.
Glad to hear it. Because this is all potentially a bit tricky, you might want to create a PD template specific to that book (incorporating the appropriate templates that show why it is PD). E.g. Template:PD-Seattle-Neighborhood-Atlas, but in this case without involving OTRS. - Jmabel ! talk16:44, 27 February 2019 (UTC)
I will definitely try to do that. Thank you for this information. I believe this problem is now solved. I have found all the inscriptions images some are in other volumes of the same book books but all are in public domain because they are too old. Thank all of you guys for helping me.--SharabSalam (talk) 20:46, 27 February 2019 (UTC) edited--SharabSalam (talk) 17:02, 28 February 2019 (UTC)
Can anybody spot what I've missed here? I'm planning to roll out quite a few description pages like this, so it would be good to identify the issue if possible so I could fix it. Often previewing the page will give a red message identifying any template errors, but the page above doesn't seem to be throwing any. Thanks! Jheald (talk) 10:32, 28 February 2019 (UTC)
If you haven't noticed the large banner yet, the WMF are doing a Wikimedia-wide consultation about how they could improve wiki-related communication. I've set up a page on this project at Commons:Talk pages consultation 2019 so that Commons users have a centralized place to provide input. Feel free to add new sections to discuss particular topics. Jc86035 (talk) 15:00, 28 February 2019 (UTC)
— Speravir – 03:34, 3 February 2019 (UTC)
wikimedia.org. SHust (WMF) (talk) 20:49, 12 February 2019 (UTC)
Done. Sealle (talk) 08:17, 5 February 2019 (UTC)
.jpg)
--Fæ (talk) 12:48, 31 January 2019 (UTC)
O Still Small Voice of Clam 22:09, 2 February 2019 (UTC)
Info Since there's now some overlap to be sorted out, I've started a discussion at CfD. --El Grafo (talk) 12:58, 5 February 2019 (UTC).jpeg)
.jpg)
Comment We have {{Factual accuracy}}. - Alexis Jazz ping plz 17:03, 9 February 2019 (UTC)
Resolved
Support Blanking a blocked or banned user's page should only be done where there is a clear rationale for doing so. This may include harassing other users or other ranty stuff, but if the page is neutral and informative, there are no good reasons for blanking and it should not happen because "bureaucracy". P.s. yes this proposal is far too long, please consider collapsing most of the text/essay. P.p.s I believe this issue was discussed, perhaps 3 years ago, though I am unsure there was ever a vote about it. --Fæ (talk) 10:58, 12 February 2019 (UTC)
Modified, background and landing gears removed
Original
Original
Modified, background and elevon removed.
Original
Modified, background and landing gears removed
Original
Modified, background, FOD mesh, and landing gears removed; rudder modified, pitot tube shortened.
Original
Modified, propeller blurred, landing gear struct removed, whip antenna bent, person and ladder removed.
Original
_(5).jpg)
.jpg)
.jpg)
.jpg)
.jpg)
_(remix).jpg)
_(7499934890).jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.png)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.svg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.png)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
_copy.jpg)
_copy.jpg)
.jpg)
.jpg)
).jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
_CAC_Sabre_Mk.32_landing_at_Avalon_during_the_2015_Australian_International_Airshow.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
_copy.jpg)
.jpg)
.jpg)
.jpg)
as an example. RAN (talk) 03:21, 14 February 2019 (UTC)
.png)
.png)
–84.46.53.126 17:48, 30 January 2019 (UTC)
Oppose Another example of our proud tradition of immediately shitting on improvements to Mediawiki software. Maybe we try something different this time. Gamaliel (talk) 20:10, 11 January 2019 (UTC)
) –84.46.53.198 18:23, 5 February 2019 (UTC)
not necessary.
) — Speravir – 01:11, 2 March 2019 (UTC)
Before
After
.jpg)
Before
After.jpg)
.jpg){kind=link}
.jpg){kind=link}
_(14759741131).jpg){kind=link}
.jpg&action=edit&redlink=1){kind=link}
.jpg&action=edit){kind=link}
.jpg&action=edit&redlink=1){kind=link}
.jpg&action=history){kind=link}
.jpg&limit=999){kind=link}
.jpg&action=watch){kind=link}
.jpg){kind=link}
.jpg){kind=link}
![[2]](https://commons.wikimedia.org/wiki/File:Flag_of_the_Houthis_(fictional).svg){kind=link}
![[3]](https://commons.wikimedia.org/wiki/File:Naval_flag_of_the_Houthis_(fictional).svg){kind=link}
![[4]](https://commons.wikimedia.org/wiki/File:Air_Force_flag_of_the_Houthis_(fictional).svg){kind=link}
-2019-02-09T20:52:00.000Z-File:Samuel_Walker_McCall_circa_1920.jpg){kind=link}
.jpg){kind=link}
_front_side_20130321_103546.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpeg){kind=link}
.jpeg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg&oldid=270006968){kind=link}
.jpg&oldid=259030339){kind=link}
.jpg&oldid=259132178){kind=link}
.png&oldid=277454003){kind=link}
_copy.jpg&oldid=274077057){kind=link}
.jpg&oldid=286444051){kind=link}
.jpg&oldid=299581393){kind=link}
.jpg&oldid=304242350){kind=link}
.jpg&oldid=315030447){kind=link}
.jpg&oldid=317557973){kind=link}
.jpg&oldid=259385570){kind=link}
.jpg&oldid=319485448){kind=link}
.jpg&oldid=319519374){kind=link}
.jpg&oldid=319910610){kind=link}
.jpg&diff=270007184&oldid=270007138){kind=link}
.jpg&diff=259030366&oldid=259030339){kind=link}
.jpg&diff=299581855&oldid=299581393){kind=link}
.jpg&diff=259132431&oldid=259132178){kind=link}
_copy.jpg&diff=274077260&oldid=274077189){kind=link}
_-_S%C3%A8te_02.jpg&diff=334302749&oldid=334302696&diffmode=source){kind=link}
![[19]](https://commons.wikimedia.org/w/index.php?title=File:East_Haven_Church_1789_VT_Rte_114_East_Haven_VT_March_2013.jpg&action=info){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg&action=edit&redlink=1){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
_Naturalis_Biodiversity_Center(1).jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
![[24]](https://upload.wikimedia.org/wikipedia/commons/archive/2/2d/20080925212306%21Stationsplein_nijmegen.JPG){kind=link}
![Commons:Deletion requests/Archive/2006/06#"Palestine_occupationN.jpg" by User:Just1pin](/wiki/Commons:Deletion_requests/Archive/2006/06#"Palestine_occupationN.jpg"_by_User:Just1pin){kind=link}
_p2.042_-_Map_of_Cumberland.jpg){kind=link}
Fixed. Jheald: Turns out that when the "external" option was added for the "warp status" field, "external" was not added to the error check function at the bottom of the template. It's now been added. Hopefully this will also clear out a lot of the files in Category:Map templates used with incorrect parameters. — Huntster (t @ c) 16:14, 28 February 2019 (UTC)