Commons:Village pump

Wikimedia Commons est� disponible en espa�ol de Am�rica Latina

From Wikimedia Commons, the free media repository
Jump to navigationJump to search
Shortcut: COM:VP
Community portal
introduction
Help desk Village pump
copyright proposals technical
Administrators' noticeboard
vandalism user problems blocks and protections
? Skip to table of contents ? ? Skip to discussions ? ? Skip to the
last discussion ?
?? Village pumps for other languages
COMMONS DISCUSSION PAGES (index)
Commons Help desk
Village pump (general discussion)
Copyright
Proposals
Technical
Graphics and photography discussion
Photography critiques
Image improvement
Illustration workshop
Map workshop
Photography workshop
Video and sound workshop
Categories for discussion
Undeletion requests
Deletion requests
Volunteer Response Team/Noticeboard
Translators' noticeboard
Work requests for bots
Contact administrators
Vandalism
User problems (Dispute resolution)
Blocks and protections
Bureaucrats' noticeboard
CheckUser requests
Telegram
IRC webchat
Commons mailing list (archive)
Commons' bugs on Phabricator
Welcome to the Village pump
This page is used for discussions of the operations, technical issues, and policies
of Wikimedia Commons. Recent sections with no replies for 7 days and sections
tagged with {{Section resolved|1=--~~~~}} may be archived; for old discussions, see
the archives; the latest archive is Commons:Village pump/Archive/2022/02.

Please note:

If you want to ask why unfree/non-commercial material is not allowed at Wikimedia

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

Please do not make deletion requests here: use the relevant process for it instead.
For technical support and graphics talks (PNG, SVG, GIF, etc.), please post on the
Graphics village pump.
To ask for image improvement, see:
Graphic Lab/Photography workshop for photographs.
Graphic Lab/Map workshop for maps.
Graphic Lab/Illustration workshop for other illustrations.
To ask for video or audio improvement, see Commons:Graphic Lab/Video and sound
workshop.
For translation requests, please post at Commons:Requests for translation.
For media requests, please post at Commons:File requests.
Search archives:

Search the main Village pump archives

Search all Village pump archives

Start a new discussion

Water pump next to the church in the town center of Doel. Doel, Beveren, East
Flanders, Belgium. [add]
Centralized discussion

See also: Village pump/Proposals � Archive

Should "China" without disambiguator be used to mean a country or a cultural
region? (25 December 2021)
Concern regarding revocability of KOGL licenses (22 December 2021)
File:Flag of Afghanistan.svg redirect target (9 December 2021)
Should deleting content from your own talk page be forbidden? (11 November 2021)
Using imagery from VOGUE Taiwan (21 August 2021)
Copyright law change in the European Union: do we need a new PD-EU-ToO tag? (6 June
2021)
Copyright law change in Mainland China (4 May 2020)
Deprecating Template:PD-Switzerland-photo (18 April 2021)
Revise the COM:FOP Sweden section (1 February 2021)
Future of file metadata (2 November 2020)
Indonesian laws on copyright (21 August 2020)
Remove text from Commons:Rollback. (20 August 2020)
Template: View � Discuss � Edit � Watch

Contents
1 January 18
1.1 Subscribe to the This Month in Education newsletter - learn from others and
share your stories
2 February 16
2.1 On moving file request declination
3 February 20
3.1 cc-by < 4.0 not ok any more
3.2 "Process duplicates" tag
4 February 21
4.1 The absurd redundancy of categories and structured data
5 February 22
5.1 English synonyms can now be used in MediaSearch
6 February 23
6.1 Your edit was saved
7 February 25
7.1 Numerical sort keys
7.2 Backup Commons files?
8 February 26
8.1 Mis-categorized images in Category:Highlights
8.2 Monuments database/Images without id
8.3 Flagging digitally upscaled images
8.4 Is File:Pizza Hut Veneto Layer Pastry.jpg actually a food of Venetian origin?
8.5 Format of 3D models
9 February 27
9.1 Best practice for indicating when an image is part of a set?
9.2 Import file from en.wiki to commons
9.3 Deprecation of unused files, "Category:Superfluous images"
9.4 Category for Free food pantries?
10 February 28
10.1 Coming soon
10.1.1 Several improvements around templates
10.2 How to download a single shape from OpenStreetMap to upload to Commons?
11 March 01
11.1 Extremely contentious category
11.2 Wikimedia Commons Query Service (WCQS) beta 1 now decommissioned
12 March 02
12.1 Data:*.map
12.2 Could Commons host the Zelenskyy /Ukraine war video files?
12.3 Confusing categories
12.4 Lakhdar Amar vs. Lakhdar Amar
12.5 Ukrainian Govt twitter feed cc-by licensed
13 March 03
13.1 Thank you for your feedback about the Board of Trustees elections
13.2 Template help?
13.3 Google Art Project grab
14 March 04
January 18
Subscribe to the This Month in Education newsletter - learn from others and share
your stories
Dear community members,

Greetings from the EWOC Newsletter team and the education team at Wikimedia
Foundation. We are very excited to share that we on tenth years of Education
Newsletter (This Month in Education) invite you to join us by subscribing to the
newsletter on your talk page or by sharing your activities in the upcoming
newsletters. The Wikimedia Education newsletter is a monthly newsletter that
collects articles written by community members using Wikimedia projects in
education around the world, and it is published by the EWOC Newsletter team in
collaboration with the Education team. These stories can bring you new ideas to
try, valuable insights about the success and challenges of our community members in
running education programs in their context.

If your affiliate/language project is developing its own education initiatives,

please remember to take advantage of this newsletter to publish your stories with
the wider movement that shares your passion for education. You can submit
newsletter articles in your own language or submit bilingual articles for the
education newsletter. For the month of January the deadline to submit articles is
on the 20th January. We look forward to reading your stories.
Older versions of this newsletter can be found in the complete archive.

More information about the newsletter can be found at Education/Newsletter/About.

For more information, please contact spatnaik@wikimedia.org.

About This Month in Education � Subscribe/Unsubscribe � Global message delivery �

For the team: ZI Jony (Talk), Friday 12:12, 04 March 2022 (UTC)
February 16
On moving file request declination
Hey, I have a question about person's names' capitalizations in the files' names.
Is it fair if a filemover declined the request on renaming the file because of
"does not comply with renaming guidelines, files shouldn�t be renamed just because
it�s not correctly capitalized" and "~, incorrect capitalization isn�t the same as
misspelling"? I'm not trying to please English langauge above Russian, written in
Latin script, but imho if the person's name and/or surname in the file's name
written without capitalization, it's a typo that should be fixed.

For example, if the file would be named like this: File:Francois holland et
emmanuel macron meeting in UNESCO.jpg, and then requested its renaming into this:
File:Francois Holland et Emmanuel Macron meeting in UNESCO.jpg, aren't these the
typos, but not incorrect request for the capitalizaion?

Original file I was requesting the rename was File:Anatoli malkin.ogg, where the
surname "Malkin" with respect to the person should be written from the "M".

Thanks a lot for your opinions in advance, � Pacha Tchernof (talk) 07:52, 16
February 2022 (UTC)

The guideline says "Files should NOT be renamed [...] because the filename is not
correctly capitalized." Lowercase and odd capitalisation is quite common for
filenames, and Commons has the oddity of capitalising the first character (if a
letter), so this is an ordinary lowercase filename with the Commons modification.
Names should of course be correctly capitalised in descriptions etc., but changing
the filename causes some interruption, which should be avoided. The file was
uploaded seven years ago. �LPfi (talk) 13:36, 16 February 2022 (UTC)
Thank you for detailed explanation! So it seems a bug... It's sad, because all
other files from that project have the same name pattern Name_Surname_voice.. I
read the guidelines, but I was thinking that the typo in the personal name has more
priority beyond the rule of not doing re-capitalization. Ok, I'll deal with that.
Thanks! � Pacha Tchernof (talk) 15:21, 16 February 2022 (UTC)
@Pacha Tchernof: Since each file can be sorted in the category however people want,
it does not actually make a significant difference how the file is named. Although
the files in Category:Echo of Moscow voice samples are organized alphabetically by
file name, that is actually their first name and someone could (although I would
not find it that helpful) go to each file and have it resorted by last name or even
by date. That is why the file name isn't terribly important enough for minor
renamings. -- Ricky81682 (talk) 20:43, 16 February 2022 (UTC)
Given that "all other files from that project have the same name pattern
Name_Surname_voice." I'd say it's a pretty clear case for valid renaming under
Criterion 4 'To harmonize the names of a set of images so that only one part of all
names differs'; rename to File:Anatoli Malkin voice.oga - MPF (talk) 15:39, 20
February 2022 (UTC)
I agree with MPF. This file can easily be renamed "to harmonize the names of a set
of images so that only one part of all names differs". De728631 (talk) 15:51, 20
February 2022 (UTC)
@De728631 and Pacha Tchernof: I'll do so shortly; one quick query before I do,
should it be to File:Anatoli Malkin voice.oga (spelling per his commons category)
or File:Anatoly Malkin voice.oga (spelling per his wikidata item)? - MPF (talk)
16:42, 20 February 2022 (UTC)
Ack, transliterations... Well, as we are at Commons, I would say we should match
the spelling of the Commons category. De728631 (talk) 16:45, 20 February 2022 (UTC)
@De728631 and Pacha Tchernof: - done :-) MPF (talk) 17:06, 20 February 2022 (UTC)
@MPF and De728631: Oh, thank you so much both! :-) � Pacha Tchernof (talk) 17:11,
20 February 2022 (UTC)
@De728631 and Pacha Tchernof: I agree with Bjh21 below that renaming might be
warranted here, but I strongly oppose the notion that spelling in the category name
should be used by default. Category names on Commons use the name most commonly
used in English, while file names may be in any language. File moving is explicitly
disallowed for changing a name into English. �LPfi (talk) 10:59, 23 February 2022
(UTC)
The original file name File:Anatoli malkin.ogg was already in English or in Latin
script for that matter, so I fail to get your point here. 11:31, 23 February 2022
(UTC)
Renaming criterion 4 has a very important footnote that people seem to overlook.
It's at COM:FR#cite note-4 and says: Just because images share a category does not
mean that they are part of a set. There are two scenarios that this criterion is
designed for. First, certain complex templates (such as those that use BSicons or
that display football kits) assume that the images used in them will follow a
specific naming convention. Wikisource also uses a specific naming convention for
the source files they transcribe. Second, files that form parts of a whole (such as
scans from the same book or large images that are divided into smaller portions due
to Commons� upload size restriction) should follow the same naming convention so
that they appear together, in order, in categories and lists. None of those seems
to apply here, though to be honest I'd be inclined to ignore all rules in this
case. I'm just mentioning it so people don't think criterion 4 is broader than it
is. --bjh21 (talk) 18:06, 20 February 2022 (UTC)
@Pacha Tchernof and Pacha Tchernof: Commons:File renaming says: Commons aims to
provide stable filenames as there might be external file clients and file moving
involves significant human and computing resources. Thus renaming should be used
with caution.
Archaic formats of file names existed in the past, and they are not a bug. An
example is that for years the limitation was the 8.3 filename system used by MS-
DOS. Non descriptive file names were commonplace. All thats changed now with a few
exceptions. I prefer (for artwork) the original published title, however some
titles include colons for example, so we have to substitute it with a comma which
is acceptable. Changing filenames requires re-directs and on foreign sites causes
link rot. That's why its resisted.
Getting the description right is more important, especially for artwork.
Spelling mistakes and case changes are in themselves insufficient reasons for a
name change. However if the file is unused elsewhere (or you take responsibility
for fixing the link rot) then there's not usually a problem with renaming. It's at
the discretion of the file mover.
As for resorting the sequence of images, there are ways of forcing that within a
category, and if all else fails you can create a gallery page. You can also upload
new (better defined image) files of the old image, correctly named, and get rid of
the old by superseding them. Broichmore (talk) 15:27, 26 February 2022 (UTC)
February 20
cc-by < 4.0 not ok any more
w:Cory Doctorow was targetted by a copyleft troll. as a consequence, doctorow,
former european director of creative commons, discourages the use of CC-BY licenses
prior to 4.0 in his post A Bug in Early Creative Commons Licenses Has Enabled a New
Breed of Superpredator. should pre-4.0 be discouraged on wikimedia commons as well?
--ThurnerRupert (talk) 06:48, 20 February 2022 (UTC)

There was a discussion here a few weeks ago which unfortunately didn't result in
any actions: Commons:Village pump/Archive/2022/01#Cory Doctorow post on "copyleft
trolls" mentions Commons. I think it's worth discouraging pre-4.0 at Commons, and
taking some form of action in the 3 areas Doctorow recommends: to prompt users to
upgrade to 3.0+ upon upload, prompt existing users to upgrade their existing
content (ideally with a tool), and warn re-users on the importance of complying
exactly with pre-4.0 terms. -M.nelson (talk) 10:27, 20 February 2022 (UTC)
sorry for my spelling error, pre-4.0 it should have been and not pre-3.0. 4.0 and
onwards have the "heal" clause and easier reference. i changed it in my text, and
yours M.nelson if it is ok for you? --ThurnerRupert (talk) 13:43, 20 February 2022
(UTC)
Then we would no longer allow uploads from Flickr, which still only allows
licensing media under 2.0 licenses. --Jonatan Svensson Glad (talk) 16:00, 20
February 2022 (UTC)
I feel that would be a major pushback for Commons since Flickr is one of our major
sources for useful uploads of third-party works by non-Commons users. Instead of
disallowing the earlier CC versions, we should better adjust the licence tags with
a warning as M.nelson suggested. Also, on a general note, Flickr has Public Domain
Mark and PD images too which are not subject to this issue. De728631 (talk) 16:21,
20 February 2022 (UTC)
My feeling (and I've not yet organised this feeling as far as a proposal) is that
our templates could do a much better job of making it easy to reuse CC content. The
licence templates have a single "attribution" field, where the licences specify
explicit lists of information (varying by licence version) that are required for
attribution. --bjh21 (talk) 18:18, 20 February 2022 (UTC)
"discourage" should be not the same as "not permit". i love @Glrx: s proposal to
include the metadata within the image files, which then permits viewers then
display additional info without wasting screen space, is fool proof, as many people
just copy paste images. there is even a phabricator ticket for it. i created
another phabricator ticket to remove cc-by 3.0 from the default upload form. could
be cool to get other ideas and create tickets for them, or edit, just like M.nelson
suggested. --ThurnerRupert (talk) 07:45, 21 February 2022 (UTC)

Regarding bjh21's thoughts about the licence template, I fear that we might have a
general licensing problem that has been ignored so far: CC licenses require you to
indicate if changes from the original work were made if you create a derivative
work. So e.g. still pics and audio tracks that were extracted from YouTube videos
or cropped image uploads where the original is larger might need a special hint in
the licence template like "This file was extracted from the original work". It may
seem obvious to a reuser that a single JPG file is not the whole original video,
but the licensing terms do ask for such a disclaimer. See e.g. the "Attribution "
section for CC BY 3.0. An automated note in the template should make such files
less prone to attacks by copyleft trolls. So what may be needed is a |derivative=
parameter for the CC templates where "yes" triggers a message like this. De728631
(talk) 10:19, 23 February 2022 (UTC)
like User:Geni said in the last discussion, i dont think enforcing the licences (by
demanding money) is 100% wrong. on the other hand, this business model of issuing
legal threats can be used quite broadly, not just in the area of copyright. they
could send out millions of emails alleging "you have been caught red-handed in
buying counterfeit products online! pay us or we will sue you!" and definitely some
people will pay.
so i'd say there's nothing so wrong about the licences, and their tactics will
still work with 4.0 or whatever versions. alamy does the exact same thing with PD
photos https://en.wikipedia.org/w/index.php?oldid=1060341513#Criticism .--RZuo
(talk) 11:15, 23 February 2022 (UTC)
The difference is that if for 15 seconds I published photo without attribution and
fixed problem immediately after spotting it means my license is actually
terminated! It is not just a lie that I have a legal problem! (I am not a lawyer,
maybe I misunderstood the article) Mateusz Konieczny (talk) 17:54, 25 February 2022
(UTC)
I support strong discouragement (make impossible to select it for own work in
upload wizard, notify all people who uploaded work licensed <4.0 CC, on upload of
<4.0 CC work send message asking to relicense). That is a nasty trap and I was
unaware about it (feel free to notify me about my own images that I uploaded under
this license) Mateusz Konieczny (talk) 17:52, 25 February 2022 (UTC)

I tested upload wizard, it still allows to select cc-by-sa-3.0 and cc-by-3.0 for
own work. Is there any good idea for allowing this nowadays? Mateusz Konieczny
(talk) 12:12, 4 March 2022 (UTC)

"Process duplicates" tag

The instructions for doing this are far from clear - several times when I've
clicked on the "Process duplicates", it has merged into the file with less detail
(less info, fewer categories, etc.), resulting in the loss of the information in
the merged destination. It needs to be made much clearer which file is being merged
into which, and how to chose which of the two duplicates one should chose to click
on the 'merge' template. - MPF (talk) 14:54, 20 February 2022 (UTC)

I've never seen this "tag" - where do you see it? Andy Mabbett (Pigsonthewing);
Talk to Andy; Andy's edits 21:42, 20 February 2022 (UTC)
@Pigsonthewing: it is generated automatically when there are two identical
duplicates of an image with different names; it is pretty infrequent that it occurs
as uploading duplicates usually generates a warning that you are doing so. I can't
show you any examples as I always merge them when I come across them, and doing so
makes the tag disappear ;-) I'd guess you could try uploading the same pic twice as
an experiment (tick 'ignore warnings' the second time!) and it should appear. - MPF
(talk) 01:58, 21 February 2022 (UTC)
@Pigsonthewing: - found an example pair: File:Little Grebe (Tachybaptus
ruficollis), Parc de Woluw�, Brussels (19847854714).jpg (older) and File:Little
Grebe (Tachybaptus ruficollis) with chicks, Parc de Woluw�, Brussels
(19847854714).jpg (more recent) are duplicates; scroll down to the 'File usage on
Commons' header to see the '[Process Duplicates]' tag. There are NO clear
instructions on how to merge the newer into the older, rather than vice-versa, nor
how to avoid losing data (categories, etc.) that might be present in one of the
files but not the other. - MPF (talk) 09:12, 25 February 2022 (UTC)
Thank you. I can see both image pages, but no such tag. Is it perhaps an admin
function? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:03, 25
February 2022 (UTC)
Screenshot of Commons 'Process duplicates' tag.png
@Pigsonthewing: - thanks for looking! I guess it could be an admin perk, though I
don't know. Here's a screenshot of what I get - MPF (talk) 18:03, 25 February 2022
(UTC)
February 21
The absurd redundancy of categories and structured data
Can I rant for a minute about how unfortunate it is that we have two separate,
largely overlapping systems for describing our content? This comes from a place of
occasionally trying to encourage friends to share some of their photos to Commons,
and the thing they invariably say after checking it out is that the upload process
is too long and complicated. They're used to services like Google Maps, which makes
it extremely easy to upload photos since they want you to do it: just click on a
place and upload your photo of it. Some things unavoidably make our process more
complicated, such as the fact that we actually care about licensing, but asking
people to add categories and then also structured data on top of that is just a
self-inflicted wound. I'm not familiar with the history of how structured data got
introduced (links welcome), but I wish it was done in a way that was integrated,
e.g. adding something to Category:Empire State Building automatically gives it the
structured data depicts: Empire State Building (Q9188) because of the value of
category's main topic (P301) at Category:Empire State Building (Q8412843). The
structured data would be so much more comprehensive if we'd done that. {{u|Sdkb}}?
talk 06:01, 21 February 2022 (UTC)
Symbol support vote.svg Support Yug (talk) 07:50, 21 February 2022 (UTC)
Symbol neutral vote.svg Neutral I am not sure if our systems are sophisticated
enough to achieve this. There are cases where categories are added that are
unrelated to what is depicted, such as date, location, creator and collection
categories. Can system logic be written to correctly filter those many categories
out of the depicts statement? If not, this suggestion will just be migrating our
messy category structure into the structured data. From Hill To Shore (talk) 08:19,
21 February 2022 (UTC)
My issue has always been that we can't synchronise the data, nor mark things as
"prominent" and "not prominent", for example a photograph of New York City where
the Empire State Building is in the background could have a Structured Data on
Wikimedia Commons (SDC) tag of "Empire State Building" marked as "not prominent",
but the complete lack of having a comprehensive system that takes the best of what
came before it makes using Structured Data on Wikimedia Commons (SDC) less useful
than it could be. I think that as a system it has a lot of potential, but it's
currently underutilised because of the fact that the legacy MediaWiki category
system doesn't synchronise with the Structured Data on Wikimedia Commons (SDC)
system. An automated system could mark all assigned categories as "prominent"
structured data and then users could manually add "less prominent" tags such as
minor things included in a photograph and other things where the inclusion wouldn't
"overfill the category system". --Donald Trung ????? (No Fake News ??) (WikiProject
Numismatics ??) (Articles ??) 09:14, 21 February 2022 (UTC)
"adding something to Category:Empire State Building automatically gives it the
structured data depicts: Empire State Building (Q9188)" should never be assumed.
Suppose the subject is, for example, an audio file which someone discusses the ESB.
Or is a photograph of the view from the ESB. Or is a picture of a model of the ESB.
Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:01, 21 February 2022
(UTC)
@Donald Trung: Whats wrong with just adding a cat such as Remote views of the
Empire State Building or Empire State Building from Rockefeller Center? Broichmore
(talk) 11:12, 21 February 2022 (UTC)
I think it is extremely fraught with danger to automatically give "depicts"
structured data based on category. There is a huge amount of poorly categorized or
miscategorized content already (almost no files in the top level of Category:United
States depict the United States for instance, but rather miscategorized people who
live there, or towns in the country). Also, many categories contain related files
that do not depict the subject named by the category, for instance PDFs of works by
an author, or pictures of the subject's, spouse, children, house, commemorative
plaque, etc. that don't warrant devoted subcategories of their own. It would be
helpful if some model uses categories as starting points for suggestions in various
human-operated structured data games (e.g. asking a thinking human: "this file is
in Category:X: does it depict X?"). Automation is only as good as the input, and
when bots (or humans) add incorrect or impractically vague structured data it
becomes twice as hard to remove/correct it (see the countless thousands of 100-
year-old photographs with "inception" date being the date some dunce uploaded it to
Commons, and some bot mindlessly copied to SDC). --Animalparty (talk) 01:26, 26
February 2022 (UTC)
May I point out this discussion. We seem to have surrendered the right of any user
to edit commons successfully. Category:Gartenlaube (Magazine) for example has been
made particularly tedious. As for structured data within commons, the majority of
it seems to be detail on scanners, and cameras used in making the image; detail of
no use whatsoever to the substance or significance of the image. I have seen no
evidence those enhancemets or wikidata's take over of the project has in any way
enhanced or improved search. Having said that I do find it useful for displaying
profile data of an artist. As I alluded to, in my earlier query herein, we need to
keep the project simple and accessible. Broichmore (talk) 16:16, 26 February 2022
(UTC)
I agree that simply tying Wikidata to categories is not going to be helpful. I
think what is really needed is simplifying the default upload wizard for new users,
and providing hints for power users who are getting used to Commons and want to
start doing more advanced things with it. aismallard (talk) 16:52, 1 March 2022
(UTC)
February 22