Commons:Village pump/Archive/2021/10

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

What is the difference between my "c" on a Latin keyboard and "с" on probably a Cyrillic keyboard?

There is something strange going on. I made a new category, Category:Traditional сlothing of ethnic groups of Russia, copied the text for the title from Commons:Categories for discussion/2021/09/Category:Russian national costumes, it was a proposal by User:Лобачев Владимир. But when I type the name of the new category with my own key board, Category:Traditional clothing of ethnic groups of Russia (in the search window), it looks like Commons does not recognize it. The problem is the "c". Can you tell me what is the matter/problem? JopkeB (talk) 10:40, 3 October 2021 (UTC)

@JopkeB: category moved. The c in "clothing" was indeed cyrillic small c (0x441), I have moved the category to clothing with latin c (0x63). MKFI (talk) 13:09, 3 October 2021 (UTC)
@MKFI: Thank you for your explanation and action. I did know about and could not see this difference. This issue might be closed. JopkeB (talk) 14:25, 3 October 2021 (UTC)
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. De728631 (talk) 16:12, 3 October 2021 (UTC)

Commons delinker mishandling links

Hi. An example is here.

That is, when I move a file on Commons, and Commons changes the name in all WPs linking to the file, sometimes (not always), the "file:" part get dropped, along with the first letter of the file name. This has happened with at least two files, and on multiple WPs for each, including those using Latin script (e.g. here, also French, Spanish, Swedish).

On some WP's (e.g. the Turkish one), my fixes are pending review, whereas the name change has gone through.

I don't know how to trace the changes, since the broken WP's no longer show up as using the file, but this has likely affected dozens of projects.

Kwamikagami (talk) 05:34, 1 October 2021 (UTC)

Also, can you move File:Irene symbol.svg to File:14 Irene symbol.svg, to be consistent with other asteroids? The target is just a rd. Kwamikagami (talk) 06:03, 1 October 2021 (UTC)

Thanks. I'll check there for any cleanup. Kwamikagami (talk) 18:12, 1 October 2021 (UTC)
Unfortunately, 'Global user contributions' also appears to be defective. It doesn't show a single one of the errors, and only shows a fraction of the wikis that the global replace affected. I'm sure there are lots of fixes I need to make, since I only noticed them if I manually visited a page (and even then probably missed some), but this unfortunately didn't work. Kwamikagami (talk) 18:34, 1 October 2021 (UTC)
That surprises me. I've never used Global Contributions to check my own contributions, but I've used it to check others'. Does anyone know what's up with that? - Jmabel ! talk 02:19, 2 October 2021 (UTC)
The edits are in the contributions of User:CommonsDelinker bot, so they will not show up in Kwamikagamis contributions. In the turkish Wikipedia diff the wiki used translated name for File namespace (Dosya). CommonsDelinker certainly should be able to handle that. @Kwamikagami: could you give a few more examples to compare? MKFI (talk) 07:14, 2 October 2021 (UTC)

User:CommonsDelinker contributions are listed separately for each WP. That's part of the problem with giving more examples: I don't know where to look for more until I run across them.

I'm checking the Wikis for just the 'asteroid' article, for just the Pallas img, where the error occurred for Armenian and Turkish. Sorry, I don't recall what other files generated errors when I moved them, and this one was probably in more than just the main asteroid article. But this should give some idea.

Vietnamese, Russian, Indonesian, Sundanese,

but no error at Belarusian, Afrikaans,

Weird that Russian would generate an error but not Belarusian, since it's 'Файл' in both.

Kwamikagami (talk) 23:05, 2 October 2021 (UTC)

I have left a note in User talk:CommonsDelinker, there was also one older example where the file name also started with a 2. I suspect this is some regex problem. Note how in the vietnamese example the local file namespace has a space, and the latter half was removed. MKFI (talk) 07:40, 3 October 2021 (UTC)
Just had it happen again. Different WP, different file: [1] In this case [[Kuva:8 Flora ... was miscopied as [[ Flora .... Kwamikagami (talk) 11:12, 5 October 2021 (UTC)
[2] [3] [4]
Sometimes these show up in my user contributions, sometimes they don't. Maybe it depends on the wiki? Kwamikagami (talk)
Ah, here's one on English WP, so it's obvious that the language or script of the wiki is not the issue: [5] [6] Again, no error when there is no leading digit: [7] Kwamikagami (talk) 04:38, 6 October 2021 (UTC)
@Kwamikagami: I have created a bugzilla report: https://bitbucket.org/magnusmanske/commons-delinquent/issues/81/commonsdelinker-strips-file-namespace, although I now notice that there were already similar existing reports. MKFI (talk) 13:06, 7 October 2021 (UTC)

Unclear provenance

What should be done about an important file with unclear provenance? (See File talk:Lake nyos.jpg)

If it helps, I found a possible substitute image by Jack Lockwood of the US Geological Survey. (See PD-USGS) https://web.archive.org/web/20060203220519/https://volcano.und.nodak.edu/vwdocs/volc_images/africa/nyos.html

Thank you for your time! --Mbrickn (talk) 21:30, 2 October 2021 (UTC)

@Mbrickn: I nominated File:Lake nyos.jpg for deletion. Apparently there was no PD licence at the original source. De728631 (talk) 16:32, 3 October 2021 (UTC)
The question is, did he take the photograph as his official duty as an agent of the government of the United States of America? If not then the image isn't in the public domain at all, if he did make it in his official capacity it is. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 16:47, 3 October 2021 (UTC) Struck, I clicked on the wrong link. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 16:48, 3 October 2021 (UTC)

How do I request deletion of >only< an older image from earlier in the File History?

I just uploaded an image to Commons, but afterwards I discovered that my location was attached with the metadata. I have now replaced it with a purged version, but the old version with my private information is still available in the File History. How do I petition a deletion of ONLY that old file? --Christoffre (talk) 09:52, 3 October 2021 (UTC)

✓ Done. Usually you should post such a request at COM:AN and ideally specify the to-be-deleted version by its time-stamp .--Túrelio (talk) 10:23, 3 October 2021 (UTC)

100,000,000+ pages at the Wikimedia Commons

I was checking out some website statistics comparing the Wikimedia Commons, the English-language Wikipedia, and Wikidata and from what I can find the Wikimedia Commons seems to be the only Wikimedia website with more than 100.000.000 pages (although Wikidata has around 20.000.000 more content pages). I guess that a lot of this has partially to do with all the Deletion Requests (DR's) and other maintenance pages, but as only a couple of months ago the Wikimedia Commons had significantly less pages than Wikidata (this was due to Wikidata quickly making A LOT of items for basically every known celestial body (think exoplanets, asteroids, nebulae, Etc.) and other major expansions), but the Wikimedia Commons' growth seems to be meteoric.

My guess is that this is likely due to the Internet Archive's legal troubles during the SARS-CoV-2 pandemic, but I can't seem to find any month-for-month statistics on uploads, deletions, overwrites, Etc. Where can I find those?

My guess is that most of this growth can be attributed to literary works from the Internet Archive. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 13:53, 3 October 2021 (UTC)

Negative category search ("deep not_in_category")?

Hi,

is there currently a way to do a "deep negative category search"? I'd like to search all media files with a certain string anywhere (file name / description) that aren't assigned to a certain category or it's descendants. I've tried -deepcat: and -deepcategory: but both yield files with an "excluded" subcategory assigned.

Example: Find all files with "Apia" in name or description, but exclude those files that are in the "Apia" Category or one of its subcategories. Goal: Find media files without/with wrong/ imprecise categories that may fit the "Apia" Category or one of its subcategories.

The "Search not in category" seems to work insofar as it ignores files that don't have the category "Apia", but it still returns files from the Apia subcategories ("People of" / "History of" / "Port of" and so on). The CirrusSearch option "-deepcategory" as well as the (deprecated?) "-deepcat" returns content from subcategories as well.

--Fl.schmitt (talk) 09:38, 4 October 2021 (UTC)

Wiki loves monuments - how to repair a mistake

I am interested in participating in Wike loves monument this year. For that purpose, I have uploaded to Commons some pictures of Portuguese monuments. Only later have I realized that the uploads should have been made through the page of Wike loves monuments, using a special Upload wizard. Can someone help? Of course, I want to avoid (propose) deleting the files and uploading them again. Thanks, Alvesgaspar (talk) 12:50, 4 October 2021 (UTC)

Diffusing a category

Category:Manchester is hugely overloaded and in dire need of diffusion. It has been neglected for years and allowed to get filled up with carelessly categorised images. There are hundreds, perhaps thousands of images. It is a real mess. Is there an automated tool that can help to clear this out and categories images more accurately? Cnbrb (talk) 21:31, 4 October 2021 (UTC)

2,008 images. Not so many. Category:Buildings in Manchester looks like it would be a start. Andy Dingley (talk) 21:52, 4 October 2021 (UTC)
I would organise them by time + subject, put them in a yearly category like "2021 in Manchester" and "Buildings in Manchester" and then investigate what more specific categories need to be added. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 22:01, 4 October 2021 (UTC)
I can't see any option to sort by time. I'm just going to go with your Category:Buildings in the City of Manchester suggestion, thanks. Cnbrb (talk) 09:13, 5 October 2021 (UTC)
That's trivial to do mechanically, therefore not worth doing – unless something is a dated event. Most of these photos are 'contemporary', but no more than that. Dating them (even if we did) should be to no more than a decade, because they're just not any more specific than that. Over-specific sub-division in just a barrier to navigation and browsing, so unless it also adds something, we should avoid it. Andy Dingley (talk) 22:19, 4 October 2021 (UTC)
Dosn't help that I have to distinguish between "Manchester‎" "City of Manchester‎" and "Greater Manchester" Oxyman (talk) 22:08, 4 October 2021 (UTC)
That's already a mess. The category has a description saying that it means the city, and many of the subcategories are redirects from " in Manchester" to " in the City of Manchester". Yet the actual content is often Greater Manchester, or even Salford (another city). Andy Dingley (talk) 22:23, 4 October 2021 (UTC)
Allot of northern towns are like this eg; "York", "City of York" The whole thing just inspires me to give up and go to another Category Oxyman (talk) 22:28, 4 October 2021 (UTC)
It just refers Manchester proper, i.e. Manchester City Centre, which is within the City of Manchester, which itself is a borough within Greater Manchester. Confusing at first but lots of urban places are organised like this - West Midlands county within the West Midlands region, Vienna within Vienna state...... Anyway I'm just looking at Manchester centre for now. — Preceding unsigned comment added by Cnbrb (talk • contribs) 08:04, 5 October 2021‎ (UTC)
I'm afraid it's not as simple as that and not comparable to West Midlands or Vienna which are at least by now clear and constantly applied because other sorted the issue out, take another look. per Andy Dingley The category has a description saying that it means the city The category has subcats such as "Buildings in the City of Manchester‎". I never heard of the City centre being refereed to as the city name, so it's not surprising others also seem to be confused. It should really be properly described and applied consistently throughout the category tree. It's people not understanding the issue and therefore not using a consistent category tree that is such a great motivation to give up Oxyman (talk) 14:06, 5 October 2021 (UTC)
One particular cause of trouble is that OpenStreetMap links the border of the Metropolitan Borough to Manchester (Q18125), which in turn has a Commons category (P373) of Category:Manchester. This means that when GeographBot uploads a picture taken anywhere in the Metropolitan Borough, it places it in Category:Manchester even though that's probably inappropriate. Correcting the OSM→Wikidata→Commons connections would at least ensure that future uploads end up somewhere more appropriate, but it's not clear to me which of the two links is incorrect. Possibly they both are, and OSM should link to Manchester (Q21525592) while Category:Manchester should be attached to Manchester city centre (Q2166304), leaving Manchester (Q18125) as a rather fuzzy concept that doesn't correspond with any Commons category. --bjh21 (talk) 14:36, 5 October 2021 (UTC)
Following on from this, I've made a couple of bold changes. On OSM, I've linked the City boundary to Manchester (Q21525592)[8], and on Wikidata I've made sure that Manchester (Q21525592) is only associated with Category:City of Manchester and not with any other category (d:Special:Diff/1508560833). This should mean that future GeographBot uploads in the City of Manchester end up in Category:City of Manchester rather than Category:Manchester. That doesn't really solve anything, but it at least moves the problem to the correct place. --bjh21 (talk) 11:17, 6 October 2021 (UTC)
OK, well I'll just use Cat-a-lot (surprised no-one has suggested this) and a visual search to filter out some obvious things like buildings. I was really hoping for something that could tell me which images are also in another more specific category to make it easier. 09:13, 5 October 2021 (UTC)
You can use Petscan for that, or VisualFileChange for simpler cases, but the trouble with the Manchester cat is that most things are only in that one. Andy Dingley (talk) 09:58, 5 October 2021 (UTC)
  • Is this still 2002 and we’re just spitballing here on how to use categories in Commons…? Obviously it needs to be split by year and month, obviously each photo should have 5-10 cats before it’s deemed minimally categorized, obviously more work and less hand-wringing is needed here, obviously categorization is independent from searching and from other forms of curating (such as SDC and galleries), and obviously there are thousands of uncategorized, miscategorized, and undercategorized photos in Commons that should be added to the already bloated main Category:Manchester — so that knowledgeable and hard working editors can attack the issue there and split it properly. (That said, I’ll now go back to work on the very bloated Category:Lisbon, constantly being depleted by properly done dissimination, and yet constantly replenished with new photos — and that’s a good thing!) -- Tuválkin ✉ ✇ 10:51, 5 October 2021 (UTC)
One thing that a lot of users seem to forget is that categories are optional. The MediaWiki Upload Wizard doesn't stop users from uploading uncategorised files which is good, someone can always come along and categorise it, as long as the file is educational and freely licensed (with all the baggage that takes with it) it should be acceptable. If users want to categorise they are free to do so, while the level of categories here are a unique feature that sets the Wikimedia Commons above many other media websites, the "burden" for categorisation should fall on those that like to categorise. We shouldn't be discouraging photographers because they used "Manchester" instead of "City of Manchester", we should be grateful that they uploaded it in the first (1st) place. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:17, 5 October 2021 (UTC)
I don't think anyone criticised file uploaders here (Though I have been criticised for using generic cats). For me the issue is that the category tree is inconsistent about what "Manchester" means. Oxyman (talk) 16:45, 5 October 2021 (UTC)

OK thanks, well I'm making headway with Category:Manchester and should have it done in a couple of days. Most of my recategorising is still pretty broad, but an improvement nonetheless. Cnbrb (talk) 09:26, 6 October 2021 (UTC)

I totally agree with Andy Dingley, when he said Dating them (even if we did) should be to no more than a decade, because they're just not any more specific than that. Over-specific sub-division in just a barrier to navigation and browsing, so unless it also adds something, we should avoid it.. Categorising beyond that, is legalized vandalism. Broichmore (talk) 10:11, 7 October 2021 (UTC)

Searching inside multiple PDFs

Category:Camera Work, for example, consists of a set of subcategroies, each containing several PDFs.

If I want to search for something accross the content of all of those PDFs, and nowhere else, is there a way to do so? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:57, 5 October 2021 (UTC)

@Pigsonthewing: deepcat:"Camera Work" filetype:pdf searchterm seems to work, but be aware of the PDF content search limitations: Commons:Village_pump/Technical/Archive/2021/01#Problem_with_Commons's_search_index_and_OCR_text. MKFI (talk) 18:59, 5 October 2021 (UTC)

Publications by volume

In the middle of organizing Category:Publications by volume, should there be a category for, say, volume 11 of publications? Would that then go under Category:Number 11 on objects or Category:Items numbered 11 or both? Some use Arabic 11 while a number use Category:XI (numeral) so should that be a subcategory? Also, does it make sense for every issue number to also be included under the item numbered category to distinguish from volume number? -- Ricky81682 (talk) 00:49, 6 October 2021 (UTC)

I'm sure your intentions are good, but you are making things twice as complicated, and twice as hard to find. Category:Volume 11 publications is functionally identical to Category:Volume XI publications. XI is the same number as 11, just a different writing system. Ditto for every other Roman numeral/Arabic numeral category pair created. --Animalparty (talk) 02:35, 8 October 2021 (UTC)

COM:NOTHOST Vs. COM:INUSE (again)

I just saw this on my watchlist, and I didn't check any further to see where this file has been delinked from, but in the original nomination the nominator asserted that the file is a user-generated fantasy flag, but how aren't we certain that it's not a mere unsourced flag? Asking if "COM:INUSE" should be applied got me accusations of "trolling" and being "not here to educate", but I am genuinely curious why the Wikimedia Commons is making decisions what content other Wikimedia websites should be allowed to use if a file is locally used and no known copyright © issues exist. As I had the impression that the Wikimedia Commons' original mission was to be the central file repository for other Wikimedia websites (but others seem to disagree). Is "COM:INUSE" not applicable if a file isn't locally sourced at the Wikimedia Commons? Proposals for the flag certainly do exist, I haven't seen the removed flag but does a file need to be sourced here or is "COM:INUSE" enough? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 09:59, 6 October 2021 (UTC)

  •  Let me be absolutely clear here, fantasy flags have no place on Wikipedia unless they are a common misconception that needs to be debunked, I am not an advocate for user-generated flags on Wikipedia's, my issue is that someone can source a flag locally, upload an SVG here as "Own work" and have it being deleted here as "a fantasy" as had happened with the flag of the Autonomous Republic of Cochinchina. Wikipedia's have their own sourcing standards and these are perfectly adequate to deal with most forms of disinformation, so my question is, does the Wikimedia Commons already have a de facto (unwritten) sourcing standard for symbols? As I have seen many "COM:INUSE" files being deleted over the lack of a local source (the Cochinchinese was sourced at Wikipedia). Also note that we have "Disputed" templates that essentially act like "Citation needed" templates. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 10:33, 6 October 2021 (UTC)
    • Regarding the particular photo you brought up:
      • I can confirm that the image is similar to (but better quality than) https://tse2.mm.bing.net/th?id=OIP.Mde-ja1deKDMOe6YG9oyUwHaFY&pid=Api.
      • I see no source that this flag was seriously proposed, here or on enwiki (the page you linked was the only page it was linked).
      • I'm not aware of any requirement that the flag have a third-party source here on Commons (a) at all, but especially (b) if it is sourced somewhere else.
      • On the Commons side: the flag should not have been deleted as out of scope IMO. It "is in use on another project (aside from use on talk pages or user pages)", and "that is enough for it to be within scope". See COM:INUSE. I intend to start an undeletion request on this image for this reason. As you said, we aren't in the business of "making decisions what content other Wikimedia websites should be allowed to use if a file is locally used and no known copyright © issues exist".
      • On the Wikipedia side (which is outside of our purview here), I can't see how that image should have been in use there. There is no indication there that the flag was actually seriously proposed, which I imagine ought to be the standard for a list entry.
    In general, my opinion of what our practice ought to be with these fantasy flags is:
    • If it's COM:INUSE, absent reasons to take it down other than its fictionality, it should stay up (with appropriate disclaimers) on Commons.
    • Even if it isn't in use, if there is an indication that the flag was part of a serious proposal (as opposed to one person's idea that no one noticed), received any real-world coverage, had any measurable impact whatsoever, et cetera, it should stay on Commons.
    • If neither of those criteria are met, we ought to take it down as out of scope.
    Thoughts? —‍Mdaniels5757 (talk • contribs) 18:26, 6 October 2021 (UTC)
    Agree that use on any other Wikipedia project - even use that we disagree with or think is incorrect - means that we should not delete the image. If we delete images being used by other projects, we would be extending an unwarrantable jurisdiction over the files that other projects can or cannot use. Issues of image use must be dealt with locally before they are elevated to Commons.
    Agree that the standard for inclusion on Commons is far lower than the "notability" standard required on many Wikimedia projects. A fantasy shared or promoted by multiple people outside of the Wikisphere is more deserving of inclusion than some random user's artwork. (That does not mean that I think personal fantasies should be deleted, however.)  Mysterymanblue  22:15, 6 October 2021 (UTC)
        • The "list of X flags" on Wikipedia(s) are permanently rife with problems because they are little more than scraped from Commons categories, which, because of laissez-faire attitudes to reality on Commons, are replete with erroneous, self-promotional material completely undifferentiated from the real-world images. If any of these "flags" were "shared or promoted by multiple people outside of [sic] the Wikisphere" then that might be a much more of a reason for hosting this "free web host" material than anything that is apparent at the moment. There are literally thousands of "some random user's artwork", I don't see why Commons policy demands that we facilitate a hoax just because no-one outside Commons has noticed the deception (or doesn't care). As for the various cautionary labels, it is more than obvious that these are blithely ignored; I have frequently seen files in use with two or three such labels clearly affixed. Adding them avails naught. Removing unusable flags from being in use without deleting such material will inevitably end in them being re-added to mainspace. If a file is added to mainspace by the file's own uploader, why would that count as acceptably COM:INUSE? GPinkerton (talk) 23:10, 6 October 2021 (UTC)
          Fraudulent files added to the main namespace of other projects may be removed, but they must be removed according to the policies of that project before they are deleted here. How those files got on the other project is largely irrelevant - we must keep the files until a local process deletes them because we presume that local projects are capable of handling things themselves. I'm certainly not saying there has to be a lengthy bureaucratic process behind every image deletion; the local process that removes these files can be as simple as an editor in good standing going and removing a poorly sourced file from an article (though these files should obviously not be removed from talk and user pages without the owner's consent). Once that process is done, the image is no longer in use and can be deleted under the most widely held interpretation of policy. If the files are truly problematic, removing them from projects in accordance with local policy should not be a hurdle to deletion and is, in fact, a good way to ensure that we don't remove valuable media from other projects.
          The issue with deleting a file added to the mainspace of another project by the uploader is that it still requires us to make a policy judgement on behalf of another project, which we are not empowered to do. We certainly will not delete all uploader-added images, only those ones we deem to be "uneducational"; that assessment can be made, but it has to be made on each project locally and not on Wikimedia Commons.  Mysterymanblue  02:10, 7 October 2021 (UTC)

Photo challenge August results

Contre-jour: Entries • Votes • Scores
Rank 1 2 3
image
Title Chephrenpyramide in Gizeh Sunrays shining through trees and
weak fog near Walchwil, Switzerland		 Echinopsis Oxygona
Author Sadarama Roy Egloff PtrQs
Score 15 9 8
Playgrounds: Entries • Votes • Scores
Rank 1 2 3
image
Title Playground with a view Детская площадка в
холодное время года		 Tiny playground (rather playboard),
Berkeley, Jan 1970
Author GabrielleMerk Vitaliy VK Foeniz
Score 19 11 8

Congratulations to Sadarama, Roy Egloff, PtrQs, GabrielleMerk, Vitaliy VK and Foeniz. -- Jarekt (talk) 02:33, 8 October 2021 (UTC)

InstantCommons

What is the official position of Commons with regards to InstantCommons? (i.e. com:inuse, com:host) --C.Suthorn (talk) 03:20, 8 October 2021 (UTC)

Can we see InstantCommons use somehow? I would suppose that COM:WEBHOST takes precedence, but if there is no pressing need to delete the file then it would be polite to not break external uses. MKFI (talk) 13:54, 8 October 2021 (UTC)
I don't think there is an "official position" but NOTHOST shouldn't be a particular issue as long as material is within scope and credits are correctly given. Ddeep linking is generally welcome. Obviously, material on Commons still needs to meet the usual requirements for COM:SCOPE, and reuse outside of WMF projects does not automatically put the image "in scope". However, I use deep linking to Commons myself on my own sites (though not with InstantCommons), both for pictures I took and uploaded here and for other material (usually PD). See, for example, http://weillproject.com/blog/2021-09-27-burgschaft.htm. Note that besides the overt credits, any photos from Commons link to the Commons page, just like they would in one of our own wikis. - Jmabel ! talk 14:42, 8 October 2021 (UTC)

Error when I upload files with Commonist

Since october 7th, the upload files with Commonist can't works. See this error message (temporary link. It expire at lundi 8 novembre 2021 06:03).

--ComputerHotline (talk) 05:04, 9 October 2021 (UTC)

@ComputerHotline: Please see Commons talk:Commonist#missingparam: The token parameter must be set.   — Jeff G. ツ please ping or talk to me 13:52, 9 October 2021 (UTC)

File attached to incorrect Wikidata item

This file shows a mythological painting, but it seems to be attached to a Wikidata item for a still-life painting. I removed the incorrect Wikidata item number from the Artwork template and tried null edits and clearing the cache, but it's still wrong. Can someone help break this incorrect connection? Thanks. --Auntof6 (talk) 07:41, 10 October 2021 (UTC)

@Auntof6: I think this has fixed it (also removing the link in structured data). Thanks. Mike Peel (talk) 07:48, 10 October 2021 (UTC)
@Mike Peel: Yes, it looks like that took care of it. Thanks. --Auntof6 (talk) 07:52, 10 October 2021 (UTC)

Name conventions for artists

Hi. Am searching for some guidelines on which name to apply to artists who changed name during their lifetime. In Wikidata we can give alternative names, making other names searchable, but still the category for the artist has to have a specific name. The question arises from a series of edits by a user who moved Category:Paintings by Lili Elbe to Category:Paintings by Einar Wegener with the comment that they were all signed as Wegener. Lili Elbe (a.k.a. The Danish Girl) was the name the artist wished to be known as, so the naming convention is up for discussion. The user who made the edits might have followed the guidelines in Commons:Ownership_of_pages_and_files and started a discussion on the relevant talk page, but chose to make the changes immediately, and they are now appearing as unpatrolled edits. Before patrolling them (or reverting them) it would be nice to hear if the community could share some thoughts on the naming conventions. Cheers --Rsteen (talk) 06:41, 11 October 2021 (UTC)

Let's talk about the Desktop Improvements

Hello!

Have you noticed that some wikis have a different desktop interface? Are you curious about the next steps? Maybe you have questions or ideas regarding the design or technical matters?

Join an online meeting with the team working on the Desktop Improvements! It will take place on October 12th, 16:00 UTC on Zoom. It will last an hour. Click here to join.

Agenda

  • Update on the recent developments
  • Sticky header - presentation of the demo version
  • Questions and answers, discussion

Format

The meeting will not be recorded or streamed. Notes will be taken in a Google Docs file. The presentation part (first two points in the agenda) will be given in English.

We can answer questions asked in English, French, Polish, and Spanish. If you would like to ask questions in advance, add them on the talk page or send them to sgrabarczuk@wikimedia.org.

Olga Vasileva (the team manager) will be hosting this meeting.

Invitation link

We hope to see you! SGrabarczuk (WMF) 15:09, 4 October 2021 (UTC)

  • @SGrabarczuk (WMF): Thanks for your reply. It is interesting that you say that you will archive the meeting notes in the usual way — a meeting that’s all about changing the usual way users interact with the “desktop”: I guess subverting and disrupting the status quo ante is good for us, users, who need to be forced into new work habits for our own good, while WMF employees really really must paste your meeting notes into a Google Docs file and cannot instead even consider using a WMF project page instead. -- Tuválkin ✉ ✇ 15:46, 12 October 2021 (UTC)

How is "zandblazen" called in other languages?

Recently I created the Category:Zandblazen. It is described on the Dutch WP. It is a technique to transport dry material such as sand, ground, clay granules, shells, insulation material and gravel to places that are difficult to access such as a roof terrace or crawl space. I was surprised not to find an article in the DE, EN or FR Wikipedia. I asked a company in the Netherlands if they knew what it is called in other languages but they didn't. Because I can't imagine that this is unique to the Netherlands, my question is what is this called in other languages so I can fill it in at wikidata? Wouter (talk) 08:37, 10 October 2021 (UTC)

It would be literally "sand blowing", and that term seems to be used in a few places, but it would usually refer to sand blowing in the wind. I suppose Category:Sand pumps would transport sand mixed with water, but what you want is transport of dry sand, like in Category:Sandblasting? --ghouston (talk) 09:01, 10 October 2021 (UTC)
German company "Putzmeister" invented the self-driving concrete pump. Maybe it would be a start to look through the different language versions of the Putzmeister article in Wikipedia and look for links from there? --C.Suthorn (talk) 09:42, 10 October 2021 (UTC)
As far as I could see are these concentrated on Slurry pumps. Not on transport of dry materials. Wouter (talk) 10:25, 10 October 2021 (UTC)
I'm certainly aware of the technique for insulation material, which, in the US anyway, is called "blow-in insulation" and the machine is simply called a "insulation blower." Beeblebrox (talk) 18:18, 10 October 2021 (UTC)
@Wouterhagens, Ghouston, and Beeblebrox: Google Translate calls zandspuiten "sand spraying".   — Jeff G. ツ please ping or talk to me 18:44, 10 October 2021 (UTC)
de:Vakuumförderer is about transporting loose dry materials (sand, gravel, fertilizer, …) by means of a vaccuum pump. Note that the article's title is referring to the device that does the job; the general priciple of doing it like this would be Vakuumförderung. Saugförderung seems to be an alternative term (saugen = to suck), sometimes in combination with Blasförderung (blasen = to blow) as Saug-/Blasförderung. --El Grafo (talk) 07:22, 11 October 2021 (UTC)
And companies based in German-speaking countries selling these things internationally seem to use the term (vacuum conveying on their english-speaking websites: [9], [10], [11]. There's also at least one US-based company using that term [12] – that's where I stopped looking … --El Grafo (talk) 07:28, 11 October 2021 (UTC)
Thank you very much! I found with that info also the French word "Transport pneumatique". Wouter (talk) 08:49, 11 October 2021 (UTC)
There is also pneumatic conveying (Q1749024), of which vacuum conveying (Q94677056) would be a child, so I'll move the non-vacuum terms over there. — Huntster (t @ c) 13:28, 11 October 2021 (UTC)
We also have Pneumatic transportation, but as a redirect to the capsules-in-a-tube type of system. Otherwise I’d like to point out that sprayer suggests a dispersing action that fills space or covers a surface; blower is better for something with linear flow. A similar device for grain elevators is apparently an ensilage blower, Fr. souffleuse à ensilage.—Odysseus1479 (talk) 03:55, 12 October 2021 (UTC)

Wrong categories added by CropTool

Hi,

this file, like many others, is not a featured picture. Nevertheless, the CropTool adds it in these wrong categories. I've fixed the issue here, and in other files (none were my own derivative works), but that's not finished. Other photographers are not active on the project, or not ready to fix others' mistakes. Thus, how to deal with the problem? Best regards -- Basile Morin (talk) 03:50, 11 October 2021 (UTC)

The flaw also occurs with other categories. Example Mac Donald's sign removed because there is no Mac Do anymore on the picture. There are many others, not yet done. Thus, waiting for a clarification. Greetings -- Basile Morin (talk) 05:24, 11 October 2021 (UTC)

  • I did not use CropTool. Other users do (with my pictures). And many photographers like me find their images listed in wrong categories. I don't think the uploaders of original contents, here and outside, should be considered responsible for the mistakes generated by this tool employed by others. Example of a so-called "Featured Picture" (363 × 364 pixels). There are hundred files like this one. Where's the official user manual? -- Basile Morin (talk) 14:16, 11 October 2021 (UTC)
  • @Basile Morin: Yes, that's happened to me, too. The tool does tell people to adjust descriptions and categories, but there's no real way to force them, since we don't have a way to know if the resulting image still fits the old descriptions & categories. You should get a notification if someone uses CropTool to extract an image from something on your watchlist. You can choose to follow up if it matters a lot to you. I know that's not the answer you wanted to hear, but I believe that is the reality of the situation. - Jmabel ! talk 01:31, 12 October 2021 (UTC)
  • Dear Jmabel, your opinion is very welcome. Thanks for sharing your experience. I agree with your idea written above, that the user is responsible "to go in and edit after using the tool". Could someone else confirm? A fresh input would be very appreciated. It may be obvious to some of you, but it is not for many users. They consider "the CropTool should do the job", full stop. At least a consensus on this simple point will certainly bring a considerable support -- Basile Morin (talk) 04:06, 12 October 2021 (UTC)
CropTool can't possibly know if something in the image has been cropped out and the category should no longer be present - if it could do that then we could let an AI handle categorisation.
That said, perhaps featured / good / valued image categories should be a special case and not copied to the cropped version. MKFI (talk) 06:04, 12 October 2021 (UTC)
Agree. But right now, in practice, who is responsible for checking the categories? The user of the tool, or the photographer? Also a question to @Jmabel: where do you see "The tool does tell people to adjust descriptions and categories"? I can't find such a recommendation anywhere. -- Basile Morin (talk) 07:41, 12 October 2021 (UTC)

 Comment If an image is accessed as "good", "featured", ... Croptool does not allow to upload the crop under the same file name. Croptool could filter assessments when uploading under a new name, croptool could show an input area with the file description for the cropper to edit the description and croptool could notify the original uploader at them user talk. --C.Suthorn (talk) 09:08, 12 October 2021 (UTC)

Examples of CropTool's errors:

  1. Assessing false featured files like this one, that one, or that one, displaying explicit yellow templates on the page, whereas the real ones are here, there, and there.
  2. Automatically placing files in wrong categories like Category:Commons featured widescreen desktop backgrounds (example 1, example 2), Category:ESC 2013 featured picture candidates (example 1, example 2), or Category:Featured pictures of Tokyo (example 1, example 2).

To make a test, I installed the gadget, and the interface didn't ask me much, did not warn about the categories, it just created a new file with a new name, and the errors were automatically generated. -- Basile Morin (talk) 11:57, 12 October 2021 (UTC)

  • Confirmation granted that "Croptool does not allow to upload the crop under the same file name", but disagree that "croptool could show an input area with the file description for the cropper to edit the description". On the contrary, no such area in the interface. Just a very tiny section "Upload comment", automatically filled with the parameters, and no possibility to edit the description, the templates, nor the categories. -- Basile Morin (talk) 01:11, 13 October 2021 (UTC)

@Basile Morin: I see now that CropTool tells you to change the filename if that is not appropriate, but does not say that about description & categories. It probably should. - Jmabel ! talk 15:33, 12 October 2021 (UTC)

Proposal to change MOTD to MOTW at VPR

Last month, there were two threads here about the high number of low quality material showcased in MOTD. Among the proposed fixes was to change MOTD to Media of the Week, to allow for selecting higher-quality media (at least until we can reliably surface good content on a daily basis). See here: Commons:Village_pump/Proposals#Change_Media_of_the_Day_to_Media_of_the_Week. Pinging participants of that thread: @Ellywa, Yann, Multichill, RZuo, and De728631: @Geni, Eatcha, King of Hearts, and Colin: — Rhododendrites talk |  18:32, 11 October 2021 (UTC)

Today, it appears indeed "no media of the day". I did not analyze the cause of problem. Is it a matter of not enough material, or are there not enough people willing to search for material an put it on the list? But perhaps the solution would be the same, as you propose. I am not against it, it can be easily changed if there is more material available. Elly (talk) 19:32, 11 October 2021 (UTC)
Or perhaps there is not enough material because it is near impossible to upload a video of more than 60MB for some time now. --C.Suthorn (talk) 09:11, 12 October 2021 (UTC)
I agree with Rhododendrites, per previous discussion. The material is generally extremely weak, to the point where we are wasting viewers time with it. Are there even enough nuggets of gold to have it weekly, or have they all been spent already? Maybe weekly + a period off the main page to build up new material. -- Colin (talk) 10:36, 12 October 2021 (UTC)

Main page revamps

In light of this comment by user "Geni" comparing our main page with the English-language Wikipedia's and mentioning "Did You know?" (hereafter "DYK") I began to think about how to improve the main page, most of the main page actually isn't about the content on the Wikimedia Commons. (Well, being about broad categories but no clear examples.)

I was thinking about emulating several things from the English-language Wikipedia such as DYK, for example we can have a trio of photographs with captions about some uncommon facts, these could display a diverse number of topics like mathematics, biology, economics, anthropology / ethnology, Etc. with some minor information about what is pictured. Likewise, we can have a "On this day in media", photographs illustrated or other media types don't have to be of high quality, just of high educational value. For example, showcasing an event that happened on this day two-hundred (200) years ago, or an illustration of a scientific discovery, or just a portrait of an important person born on that day.

The main page has so much potential that it is not being used for, I don't think that we should exclusively strive for the best quality but just for the best educational value, have an image that explains difficult concepts in simple ways and put it on the main page. Make the main page into "an event" and it will likely motivate more people to upload works and showcase the works we already have. I can create a concept main page when I find the time but I first wanted to discuss it here to get some feedback. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 09:48, 12 October 2021 (UTC)

this page hasn't been updated since 2018. There is nothing wrong with that, but it is simply not the same as a potential "This day in media". --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 09:55, 12 October 2021 (UTC)
Did you know ...
... that the Djamaâ El Djazaïr is the largest mosque in Africa. It houses the world's tallest minaret and is the third-largest mosque in the world after the Great Mosque of Mecca and Al-Masjid an-Nabawi of Medina both in Saudi Arabia.
... that the Bảo Đại Emperor served as the Supreme Advisor to the government of the Democratic Republic of Vietnam as "Citizen Vĩnh Thụy" following his abdication.
... that in 1966, James Island was removed from surrounding Quillayute Needles National Wildlife Refuge by the United States Department of the Interior, and returned to the Quileute when the island was discovered to be part of the Quileute Indian Reservation.

I made the above concept, obviously that template wouldn't be used but I couldn't find the exact templates used on the main page for emulation, I thought that this would be sufficient to showcase the general idea of what could be done with it, perhaps it might be best to only limit entries to Quality Images (QI's) and Valued Images (VI's) as I literally just used random images, but as the Wikimedia Commons is a more mediacentric Wikimedia website I think that every entry should have an image, likely these images should only rotate every two (2) days or more, until enough people work at it to make if a daily occurrence. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 12:58, 12 October 2021 (UTC)


  • Ultimately the commons main page is fair less significant the EN one. Commons gets around 150K a day against EN's 5 million. It also has far more editors interested in engaging with it. Until we get a decent sized group of people interested in doing things with the commons main page I suspect its best to keep it as static as possible.Geni (talk) 14:24, 12 October 2021 (UTC)
I don't disagree with that assessment but this might also be a "Chicken and egg" situation, the Wikimedia Commons doesn't seem to have that many collaborative pages that actively invite people, in many cases "people are islands" here who just upload stuff and leave, some just categorise and leave, some just nominate some stuff for deletion and leave, even if someone does all three (3) they aren't often likely to engage with other users to work together, people here don't seem to create taskforces to upload specific works or "tackle" specific websites. Sometimes this happens with people wanting to import as much as possible from the Internet Archive following its lawsuits and its future being in jeopardy and I have seen some collaborations in file talk pages and with graphics, but generally speaking people rarely search media together, despite it not being so different from discussing topics and comparing research and sources like one would do at a Wikipedia. I do think that these things are more suited for a larger community, but the Wikimedia Commons has existed 17 (seventeen) years and while I do think that in the future there is certainly hope for it becoming a larger website (by sheer volume it's already the largest Wikimedia website), the factors for why we haven't seen a large growth haven't been properly explored yet.
I asked a friend why he thinks that the Wikimedia Commons doesn't have more contributors, his response was basically that it's more collaborative to work on texts together and that it's easier for people to simply write a text than it is to make good photographs, he further elaborated that when people want to upload a photograph that they are met with a message promptly informing them that their works will be "Free forever" and that many professional photographers don't like the idea of having to give up control of their photographs and that contributing to the Wikimedia Commons is like taking the full costs of being a photographer but having $ 0,- reward for it. He said that this is something that people like him and I would cheer on but is simply too unattractive for the vast majority of people that would theoretically want to contribute here as a hobby. I tend to agree with these points. He said that when writing for Wikipedia someone can "just sit on their ass and do something" but that contributing (content) to the Wikimedia Commons require more effort. I think that there are many factors why we have a small community compared to the English-language WIkipedia. We should try to look for more ways to motivate people to join, my friend basically summed the Wikimedia Commons up as "Less "reward" for more work". I think that having your photographs on the main page might incentivise some people, I know that people are often "trophy chasers" and I think that something like a DYK would motivate more people to contribute, as I think that the reason why the Media of the Day (MOTD) failed is simply because it takes even more effort to upload to the Wikimedia Commons.
I asked people who have photography as their hobby about joining the Wikimedia Commons and nothing scares people off more quickly than our licensing terms (I see this as an issue with a copyrights obsessed culture rather than ours), so I understand why getting more volunteers is difficult, but we should also try to present the Wikimedia Commons as "a home for public domain books", "a home of art", "a home of online museums", Etc. I think that presenting the diversity of Wikimedia Commons content on the main page helps, for a lot of people viewing the main page will make a good "first (1st) impression" of the website so I think that at least some improvements could be made. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:33, 12 October 2021 (UTC)
 Comment, comparing the Wikipedia page on the "Wikimedia Commons" before September and after September it reveals that very little people actually discuss the Wikimedia Commons outside of its controversies (and I can find a number of controversies that haven't been listed there yet), the Wikimedia Commons doesn't seem to have any "outreach" programmes nor does it seem to try to actively promote itself to the outside world. I see armies of people to warn new uploaders but I rarely see people actually trying to get new volunteers to join, we have Wiki-drives for Wikipedia's but we don't have events where we teach librarians to scan documents or something. The people who are here now are the people that chose to join despite its lack of outreach rather than because of any efforts to present itself to the outside world. There is a lot of media here, yet we rarely present it, most of it is actually being presented by other Wikimedia websites... --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:44, 12 October 2021 (UTC)

Broken svg file: Transnistria map

I noticed https://upload.wikimedia.org/wikipedia/commons/8/89/Transnistria_in_Moldova_(de-facto)_(semi-secession).svg reporting an error, there seems to be a problem with the file. This is the file: https://commons.wikimedia.org/wiki/File:Transnistria_in_Moldova_(de-facto)_(semi-secession).svg. Maybe someone can fix this. Thanks. — Preceding unsigned comment added by DarthBrento (talk • contribs) 10:46, 14 October 2021 (UTC)

@DarthBrento: Hi, and welcome. Thanks for the report, please see COM:SIGN. Pinging @Nicolay Sidorov as uploader.   — Jeff G. ツ please ping or talk to me 11:06, 14 October 2021 (UTC)
Fixed. Bad entity replacement for i: namespace. Glrx (talk) 16:32, 14 October 2021 (UTC)

Voting begins for the MCDC Election

Voting for the election of the members for the Movement Charter drafting committee is now open. In total, 70 Wikimedians from around the world are running for 7 seats in this election.

Voting is open from October 12 to October 24, 2021.

The Movement Charter committee will consist of 15 members in total: The online communities will vote for 7 members, 6 members will be selected by the Wikimedia affiliates through a parallel process, and 2 members will be appointed by the Wikimedia Foundation. The plan is to assemble the committee by November 1, 2021.

You can learn more about each candidate to inform your vote here

You can also learn more about the Drafting Committee here

We are piloting a voting advice application for this election. Click through the tool and you will see which candidate is closest to you! To try out this tool, visit: App

Go vote at SecurePoll: Vote

Read the full announcement: here

Best, Zuz (WMF) (talk) 15:04, 14 October 2021 (UTC)

WikidataCon 2021

Hi all. I'm posting here as a co-curator of the 'Sister projects' track for WikidataCon 2021, which will take place online on 29-31 October 2021. The conference website is at [13].

Integrating Wikidata content has mostly been welcomed here. We would really like to see case studies both about how this has gone well, and where issues have been encountered. Whether you like Wikidata or not, please consider submitting a session proposal to explore the issues that you are most interested in.

You can find information about how to submit a session proposal at [14], and you can access the submission form at [15]. Please submit a session proposal through the Pretalx process so that we can review and schedule it appropriately - and make sure to mark it as a 'Sister projects' track proposal. Please note that we cannot accept a session outside of the Pretalx process. We also encourage you to submit talks to other tracks if you are interested!

Note that the deadline for submitting proposals is the 20th October - sorry for the short notice! Thanks. Mike Peel (talk) 19:55, 15 October 2021 (UTC)

User uploading again the same images after mass deletion

Hi. A mass deletion has been performed 2 days ago for images uploaded by Exxelia Groupe. The user has uploaded again some of the same images with the same problems without any attempt to start a discussion. What should be done ? --NicoV (talk) 12:21, 15 October 2021 (UTC)

Thank you. The Exxelia site is licensed under CC 3.0 (we are in the process of modifying the legal notices page to indicate CC). The images were uploaded with the CC 3.0 license. If this is still not suitable, please let me know exactly what to do.

Thank you. --Exxelia Groupe (talk) 12:32, 15 October 2021 (UTC)

  • How does "blocked for not starting a discussion" work then? They're claiming that this content is now acceptable, but it isn't as yet without further editing. Which won't now happen until after the files have been deleted, because they've now been blocked for _just_ long enough to allow that to happen. Andy Dingley (talk) 15:01, 15 October 2021 (UTC)
  • @Yann: They seem to be finally ready to talk, and trying to fix things. It looks like all their uploads predated the discussion here. I would suggest unblock, with a firm warning not to upload anything else until we work this all out, and block only if they violate that. - Jmabel ! talk 17:31, 15 October 2021 (UTC)

@Exxelia Groupe: Once you have this sorted out on your own site: assuming you put the licensing information in one central place, you will want to add a link to that to the "Permission" field of the {{Information}} template for each image. Also, you will want the license you indicate on Commons to match the license granted on your site. Further, the "Source" field of the {{Information}} template for each image should be the URL of the page on your site where the image is displayed.

An alternative (or addition, if you prefer) would be to go through the COM:VRT process and send an email that clearly comes from you organization, indicating that this account is operated on behalf of your organization, and that licensing granted by this account is effectively licensing granted by you organization. - Jmabel ! talk 15:32, 16 October 2021 (UTC)

New file names including old name

When a file has a bad name it gets a new one, e.g. File:---The alleys of the city.jpg becomes File:Alley in Bou Saâda, wooden ceiling 1.jpg.
But there are many renamings by @MONUMENTA that needlessly immortalize the old name in the new one:

I think these parts should be removed, and this scheme should not be used anymore. --Watchduck (quack) 09:47, 16 October 2021 (UTC)

I had been doing it so that his previous name was recorded, if you consider it incorrect, I myself will eliminate that scheme from all my past transfers.MONUMENTA Talk 13:39, 16 October 2021 (UTC)
@MONUMENTA and Watchduck: I think it's best not to do this, but no need to clean it up where it has already happened. - Jmabel ! talk 15:34, 16 October 2021 (UTC)
@MONUMENTA: It is enough to preserve the old name in the redirect. I would change at least the last one, to get rid of the equals sign. (maybe to File:Melilla town hall at night.jpg) --Watchduck (quack) 17:14, 16 October 2021 (UTC)

License of Images of Works by Artist Anna Ostroumova-Lebedeva

The artist Anna Ostroumova-Lebedeva died in 1955 which is less than 70 years ago. Most of the images in this category have a license tag of PD-old-70-1923 which seems wrong to me. There seems to be a way to keep the images. They are PD in USA because published before 1926 and there is a similar license for Russia. I don't know enough about this topic and don't want to change the license tags myself. Anybody else? -- Andreas Stiasny (talk) 09:56, 16 October 2021 (UTC)

Some of her works may be {{PD-RusEmpire}}. Rest should be deleted and restored in 2026. Please use batch deletion request and add Category:Undelete in 2026 there. --EugeneZelenko (talk) 14:29, 16 October 2021 (UTC)

Flickr Foundation

Flickr have announced the "Flickr Foundation":

We believe the establishment of a non-profit Flickr Foundation will combine with Flickr to properly preserve and care for the Flickr Commons archive, support Commons members to collaborate in a true 21st-century Commons, and plan for the very long-term health and longevity of the entire Flickr collection. We’re also in the early stages of imagining other educational and curatorial initiatives to highlight and share the power of photography for decades to come.

More at https://www.flickr.org/ - Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:25, 16 October 2021 (UTC)

User:Fæ

It sadly looks like User:Fæ isn't coming back. Unsurprising, given how he was treated.

Is anyone going to pick up his regular tasks, such as periodic Portable Antiquities Scheme uploads? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:55, 16 October 2021 (UTC)

American Antiquarian Society

Hi, Was there any attempt to upload images from the American Antiquarian Society? According to their website, their graphic arts collection contains 400,000 historic American objects. They also have books, manuscripts, newpapers, etc. On Commons, we only have a a few paintings. Regards, Yann (talk) 08:36, 10 October 2021 (UTC)

What is their licensing policy? Ruslik (talk) 20:35, 14 October 2021 (UTC)
I don't know about online, but my university library had a collection of early Americana from them on microfiche, and they all had copyright notices on them. (And the university library had no microfiche printers, either.) — Preceding unsigned comment added by Prosfilaes (talk • contribs) 22:26, 15 October 2021 (UTC)
@Ruslik0: Sorry, I didn't see your message. All their collections are PD due to age. Paintings and photographs are PD-Art, and small/medium resolution images of other items are under a CC license. Regards, Yann (talk) 19:04, 18 October 2021 (UTC)
Unfortunately, it looks like they're using a non-commercial CC license according to [16], but as you said, any 2D reproductions should be fine per PD-Art/PD-Scan. clpo13(talk) 19:47, 18 October 2021 (UTC)

The (in)visibility of the Wikimedia Commons

While reading this article looking for news coverage of Wikisource I came across something interesting, while this article discusses the Creative Commons movement on the internet and online free image resources it doesn't even mention the Wikimedia Commons at all, it does mention Wikipedia but not this website. I don't really want to create another section but as I would consider this to be "Out of scope" for the main page revamps discussion above I thought that it might be wise to do so. One thing I have been wondering for quite is why the Wikimedia Commons has remained "such an obscure website", despite its massive size and already existing for 17 (seventeen) years I have yet to meet a person in real life (IRL) know what the Wikimedia Commons is if I mention it to them, there also seems to be very little press coverage of this website and its events (unlike with Wikipedia) and despite its images being used in a lot of highly visible places I rarely see people reference it. Likewise, Wikisource as a project would be quite ambitious and theoretically it could become one of the largest libraries in the world but as of now it almost has 5.000.000 (five-million) or so works, only a third of any of the world's largest libraries, the Wikimedia Commons only hosts 3,032,762 office files (the category which includes books and other texts).

So my question is, why hasn't the Wikimedia Commons grown as much? Are there any outreach programmes? Would it be wise to try and start such a programme? I personally am inclined to think that our focus should be on trying to convince organisations to donate their works, like GLAM organisations but also private collections. If there are currently 500.000.000 or so freely licensed images on the internet (according to the aforementioned article) then the Wikimedia Commons hosts 70,051,301 of those which is more than a tenth (1/10th), yet it is rarely discussed when discussing free media files and GLAM's seem to want to come up with their own solutions rather than donate here, would Structured Data on Wikimedia Commons (SDC) be a good solution for them and did it have an effect on GLAM's donating? The Wikimedia Commons doesn't seem to have a newsletter where announcements of GLAM donations are reported in or what has been donated so I wouldn't know where to find such information. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:35, 14 October 2021 (UTC)

"why hasn't the Wikimedia Commons grown as much" - In my experience, many new users find it too comlicated and too unwelcoming. "Are there any outreach programmes?" - Many, both small and large: not least the Wiki Loves... series, and Wikimedians in Residence. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:55, 18 October 2021 (UTC)

How to upload images from a Flickr account with 8000 images? Flickr2Commons doesn't work

Hi all

I'm looking at uploading images from a Flickr account of natural history images (including some holotypes) which has around 8000 CC licensed photos, almost all will be useful for Commmons. I've attempted to use Flickr2Commons to upload them but its too large and the tool doesn't load. It does have some albums but I don't think it includes all the images, maybe not even half. Is there another tool or process I could possibly use? I'm not able to use any python tools or anything complicated like that. Is there maybe a bot I can request to do it and tidy up the metadata while they're on Commons?

Thanks

John Cummings (talk) 11:37, 14 October 2021 (UTC)

@John Cummings: Sounds like a job for Commons:Bots/Work requests. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:51, 18 October 2021 (UTC)
Thanks very much Pigsonthewing, hopefully its a simple request copying from Flickr. John Cummings (talk) 18:47, 18 October 2021 (UTC)

Tagging probably miss-identified cityscape

Hi. Which would be the best existing template to tag a probably miss-identified cityscape? Strakhov (talk) 08:06, 15 October 2021 (UTC)

Thanks, Jmabel. I had used {{Inaccurate description}} but I was sure there had to be something better. {{Fact disputed}} is much better indeed. This is the file: File:Blick über den Hafen und die Stadt Triest c1900.jpg -> it bears a suspicious resemblance to Palma de Mallorca. Strakhov (talk) 12:24, 16 October 2021 (UTC)
Thanks! Mystery solved. :) Strakhov (talk) 13:54, 18 October 2021 (UTC)

May a file be deleted due to disinformation?

Death rates from energy production per TWh.png

Apart from hiding the source, which is here, the maker has omitted the lower part of the original chart. That makes it quite misleading, because precisely the with nuclear power competing non-fossil fuels are removed.--Wickey (talk) 14:40, 17 October 2021 (UTC)

@Wickey: It's in use, so I suggest your best approach would be to add your concerns on the image description page; and on the talk pages of the articles where it is used. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:06, 17 October 2021 (UTC)
I don't believe that page is the source. This is purely impression, but looking at it, I think it was copied directly as is from some other page on Our World in Data, which would mean we were violating the license. It is too precisely a copy to be a new creation--logo in the same place, logo included at all, citation and text in same font--yet too different to be an edit--different citation, different colors. I'm not sure quite misleading is fair; if you want the numbers for solar versus nuclear, they're not included on that graph.
I've uploaded File:Death rates from energy production per TWh (including solar).svg from the source, since it is CC-BY-4.0. --Prosfilaes (talk) 22:32, 17 October 2021 (UTC)
@Wickey: @Pigsonthewing: @Prosfilaes: I nominated this file for deletion, because it violates the terms of the license. --Ooligan (talk) 03:13, 18 October 2021 (UTC)
Thank you. I actually was not sure if there was such a reason for deletion. There is another issue, though. Can everyone produce such images, whether disinformation, misinformation or original research and upload it to Commons? Upload of course, but will it be accepted?--Wickey (talk) 08:49, 18 October 2021 (UTC)
@Wickey: COM:EDUSE is the relevant policy here – all files on Commons need to be potentially useful for an educational purpose (within a rather large margin, and with some exceptions for personal images on user pages). If something is purposefully and blatantly misleading, it is not educationally useful. Unless, of course, it is clearly marked as such and used as an example for misleading information. That's why we keep things like Category:Nazi propaganda and Category:Donald Trump tweets. If a file is being used in an article on Wikipedia (or another sister project), it is automatically considered to be useful for an educational purpose.
In practice, that means: If you want something removed from Commons for not being useful for an educational purpose, you better first check if it is used on Wikipedia. If it is, start a discussion there first, proposing to remove it from the relevant article for being wrong/misleading/… Only after that has been agreed on and done does it make sense to start thinking about how to remove it from Commons as well.
NB: Copyright issues are a much stronger argument for deletion. So if you can prove that a file is a copyright violation in some kind of way, it's not worth the effort wasting time and energy on lengthy discussions about educational use. --El Grafo (talk) 10:13, 18 October 2021 (UTC)
Such images? On the DR for this image, the exact source has been pointed out. It is neither misinformation or disinformation. We prefer not dealing with these arguments when possible, and leaving such arguments of fact and NPOV to Wikipedia where possible, for just such reasons.--Prosfilaes (talk) 21:02, 18 October 2021 (UTC)
Thanks all for your time.--Wickey (talk) 15:25, 18 October 2021 (UTC)

North London Regent's Canal

A silly basic question. From a Lumix, I tried to upload a batch of scenes along the north London Regent's Canal quickly using Upload Wizard. All are geotagged in the exif. Upload Wizard did not transfer the Latitude and Longitude from the exif into the Location fields. Look at the image- and there is no geotag in the description. Download the image to your local PC, right click on properties/image and there it is -the original geotag. The data is there but not displayed or displayable on the server. I tried it again on my Nikon and it did the same. Why? Is this a feature? Is this on someones to-do list? ClemRutter (talk) 18:21, 18 October 2021 (UTC)

@ClemRutter: it does look like a bug; I can verify that there are “Camera Location” data in the image file, visible in Photoshop and Apple Preview for example, that do not even appear in the metadata box on the file page, let alone getting read into the info template (which I wouldn’t necessarily expect). COM:VPT might be a better place to ask if this is symptomatic of a known issue (or simply an absent feature), or to get a bug report made at Phabricator.—Odysseus1479 (talk) 21:58, 18 October 2021 (UTC)

A tiny bugbear. On upload wizard, one can copy down the description fields from the first image to each image below- which I do a lot. What you can't do is copy down the description from any other image to all the images below that one. For example 20 images of Acton's Lock of which image 14-20 are of a Heron at Acton's Lock. All 20 take the same description and categories but the last 6 need a few extra words about the bird-and an additional category. Should be easy to code. ClemRutter (talk) 18:21, 18 October 2021 (UTC)

Delinker (cont.)

No response at User talk:CommonsDelinker about file links breaking when a file is moved. I've added a few more examples there.

But this is interesting: this move was done through my acct, and it's correct. This similar move on the same article was done through the CommonsDelinker acct, and got messed up. Could it have anything to do with one having spaces and the other underscores? Also, I don't know why one would be in my acct and the other in the bot acct: in both cases, I simply moved a file here at Commons, and the links were handled automatically. Kwamikagami (talk) 01:51, 20 October 2021 (UTC)

Two templates (Info and Artwork)

As I need to upload a few hundred images, all with the same info, I've had to split the information into two, so that I can use the Wizard to mass upload. The Information template is not detailed enough. Half the info is in the Information template, and the other half in the Artwork template, as you can see here: File:Jesus-College-MS-119 00002 Inside-upper-cover.jpg. The old uploader could use the Artwork template on its own, with no problems (as I did here), but that's not an option on Wizard, for some reason. (Pattypan hasn't worked now for around 3 weeks). Any thoughts please on using two templates ok? Llywelyn2000 (talk) 06:39, 20 October 2021 (UTC)

Jmabel Many thanks! We can always amend with AWB if a better option comes up. Llywelyn2000 (talk) 15:00, 20 October 2021 (UTC)

Cambridge lectures

https://www.youtube.com/results?search_query=cambridge+lecture&sp=CAISAjAB especially the law faculty has made many talks CC.--RZuo (talk) 08:44, 20 October 2021 (UTC)

Learn how Movement Strategy Implementation Grants can support your Movement Strategy plans

Movement Strategy Implementation grants now provide more than $2,000 USD to put Movement Strategy plans into action. Find out more about Movement Strategy Implementation grants, the criteria, and how to apply here.

Also, the Movement Charter Drafting Committee election is still ongoing. It would be great to increase community participation. If you haven't voted now is the time. Please vote here before October 24. Regards, Zuz (WMF) (talk) 15:57, 20 October 2021 (UTC)

User:Спасимир

I'm sad to report that our friend and colleague User:Спасимир has sadly passed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:01, 20 October 2021 (UTC)

Importing from OSM wiki

Do we have a tool to import images (such as this one) from the OSM wiki? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:59, 21 October 2021 (UTC)

Policy of flags

I recently came across wikipedia:Talk:Pashtuns#Inclusion of Flag proposed where someone proposed putting a separatist wikipedia:Pashtunistan flag onto Wikipedia. The flag in question is this one, File:Pashtunistan Flag.png, however it is flagged on Commons as fictitious or proposed but not adopted.

I wanted to dig in further and I do know that a seperatist flag for the Pashtun lands does exist: namely, these official postage stamps produced by the government of Afghanistan back then, File:Stamp of Afghanistan - 1961 - Colnect 670472 - Pashtun with Pashtunistan Flag.jpeg, File:Stamp of Afghanistan - 1962 - Colnect 485282 - Man and Woman with Flag.jpeg, File:Stamp of Afghanistan - 1965 - Colnect 429977 - Pashtu Flag.jpeg, I believe do give enough evidence that this is a flag that is real and has been used once upon a time. Therefore, File:Pashtunistan Flag.png (or a variation) should be unflagged and be allowed to appear on Wikipedia. --Weaveravel (talk) 13:45, 21 October 2021 (UTC)

About our tab-separated files

I've been searching for about 15 minutes for a page about our tab-separated files, but I've had no luck. I expected to find something via Com:TSV. Do we have such a page? Where is it hidden? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:21, 21 October 2021 (UTC)

Special keyboard characters not properly interpreted

Since yesterday I've been unable to type special characters like the asterisk, plus sign or tilt when editing. Not a problem of my computer because I tried in different machines (I'm not even able to sign properly) -- Alvesgaspar (talk) 16:56, 22 October 2021 (UTC)

MediaWiki sites have a language selector (with an input method selector) in the head of the page (kanji letter as icon). Probably you changed the input method without even noticing that you used that function (and do not ask me about the selector, I neither understand what it is meant for nor how it actually works) --C.Suthorn (talk) 15:46, 22 October 2021 (UTC)

Talk to the Community Tech

Read this message in another language

Hello!

We, the team working on the Community Wishlist Survey, would like to invite you to an online meeting with us. It will begin on 27 October (Wednesday) at 14:30 UTC on Zoom, and will last an hour. Click here to join.

Agenda

  • Become a Community Wishlist Survey Ambassador. Help us spread the word about the CWS in your community.
  • Update on the disambiguation and the real-time preview wishes
  • Questions and answers

Format

The meeting will not be recorded or streamed. Notes without attribution will be taken and published on Meta-Wiki. The presentation (all points in the agenda except for the questions and answers) will be given in English.

We can answer questions asked in English, French, Polish, Spanish, German, and Italian. If you would like to ask questions in advance, add them on the Community Wishlist Survey talk page or send to sgrabarczuk@wikimedia.org.

Natalia Rodriguez (the Community Tech manager) will be hosting this meeting.

Invitation link

We hope to see you! SGrabarczuk (WMF) (talk) 23:00, 22 October 2021 (UTC)

Index of free websites

Do we have a centralised index of websites that host free media where we can import from? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:04, 28 October 2021 (UTC)

Hi Donald Trung. We have Commons:Free media resources. I hope that helps. --Askeuhd (talk) 20:19, 28 October 2021 (UTC)
Thanks. Apparently it's already on my watchlist so I must've known about it before but forgot. Odd that it isn't being promoted in more visible places. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:33, 28 October 2021 (UTC)
This section was archived on a request by: --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:33, 28 October 2021 (UTC)

Automatically review audio & image files - BRFA

More input from other users is required before I start implementing anything and end up wasting time on stupid/unwarranted features. See Commons:Bots/Requests/LicenseReviewerBot 2. Thanks! -- Bd9a119b5d05019d7c923207398ef3c3 (talk) 07:17, 23 October 2021 (UTC)

Request on Meta for CentralNotice for the Slovakian Wiki Science Competition

Under the flag od PreWiki.sk I am organising a multimedia wiki science-themed competition for Slovak public. As I have asked for a CentralNotice on Meta to be shown also on Commons for users with Slovak lang interface from Slovakia, I am announcing it also here for transparency. --KuboF Hromoslav (talk) 18:26, 23 October 2021 (UTC)

For more context, please see discussion about the proposed grant for ELiSO.--Jetam2 (talk) 20:56, 23 October 2021 (UTC)

I would like a guess about copyright of an image

Hello editors of this page. I was writing an article about a species of snail and found this image in a Flickr page. It is from the year of 1913, but I got the impression that it might not be accepted here, because the author died in 1935. Mário NET (talk) 04:55, 23 October 2021 (UTC)

I'll download this image then. If I have misunderstood what has been exposed to me here, I will face the consequences of this act. Thanks to everyone who gave me information. Mário NET (talk) 14:41, 24 October 2021 (UTC)

  • @Mário NET: I presume [File:Cephalaspidea mollusks by Philippe Dautzenberg (1913).jpg]] was the image in question. After asking all of these questions here, you still seem to have gotten the licensing completely wrong. You dated it as 23 October 2021 even though you said here it is from 1913. You gate the license as {{Cc-by-sa-4.0}} which implies you own the copyright (you don't, there is none) and are granting rights. I'll go in and fix this all based on the info you give above, but it looke like you have a lot to learn about how to do this sort of thing. - Jmabel ! talk 16:23, 24 October 2021 (UTC)
Some time ago I changed the copyright of several images I downloaded. It really is continuous learning. That's why I comment on what I comment on my Wikimedia Commons user page ("I would like to make it clear that, because I deal with issues beyond my technical knowledge, any action taken contrary to an activity I have done will be accepted"). I'm usually changing pages that work with Commons licenses under the same license, now. Mário NET (talk) 19:33, 24 October 2021 (UTC)

How do I add a depicts property to an entire category of files?

For example, every image in this category: https://commons.wikimedia.org/wiki/Category:Ara_macao_in_different_color_palettes depicts an Ara macao. How would I add the "depicts: Ara macao" property to every file in this category at once instead of one-by-one? — Preceding unsigned comment was added by 141.193.81.56 (talk) 19:27, 24 October 2021 (UTC)

If you have a user account, you can use the SDC tool (see here for tips on installing user scripts). --Animalparty (talk) 01:19, 25 October 2021 (UTC)

Backlog of DR's

I suppose it has been discussed before, the backog of deletion requests. As a beginning admin, I was optimistic. I thought I could keep up with the daily requests and would be able to close the remaining old DR's of a single day in less then a day. I concluded however that the backlog is getting longer every day. Just today I managed to finalize Commons:Deletion requests/2021/01/28, and tomorrow I will start with Commons:Deletion requests/2021/01/29, which currently contains 91 individual requests. I know other admins are busy as well. Has there ever been thought of a different approach to manage these old requests? Elly (talk) 11:02, 23 October 2021 (UTC)

P.S. I estimate that I deleted around 75% of the files based on the nomination and discussion, and kept 25%, however, I could start to substantiate these statistics if that would help thinking of another approach. Elly (talk) 11:06, 23 October 2021 (UTC)
Some kind of overview can be seen at: [18] I think getting this down to acceptable values can only be achieved by some automated processing, which has always been controversial. --Krd 11:21, 23 October 2021 (UTC)
Number of DR's versus time 2021
Krd, thanks for the link, interesting. The trend is not bad, the number of DR's from March 2021 is slightly deminishing over time, very slowly. But it is hard work for us all.
However, I would be in favour of automation. I would suggest for a start to delete all files with only a nomination of a single person, without any comments of any other person, which are waiting longer then 6 months. I estimate that I am deleting a very large portion of these, because I consider most of these nomination justified, the uploader did not comment or explain, nor did anybody else. I think such automated action can be based on COM:PRP. Of course there will be some collateral damage. But we as a community should take our responsibility to protect copyright holders rather quickly, and especially to protect third parties which use "our" material. Could such a proposal get consensus of the Commons community?
By the way, several admins helped to solve old DR's, so Commons:Deletion requests/2021/01/29 currently lists only 25 request, Thank you all. Elly (talk) 10:49, 24 October 2021 (UTC)
@Ellywa: I, for one, really do not like the idea of automatically deleting uncontested DRs. Sometimes, people file DRs for frivolous or incorrect reasons, but they are not commented on because they are "lost in the logs." These should not be deleted, and much of the point of having administrators at all is to recognize the situation and make policy-based closes. Like you said, protecting copyright holders needs to be a big priority for us, so clearly the year-long backlog is a problem. As someone who files copyright-related regular DRs relatively often, I am often reasonably confident that a file is non-free but have to wait months for it to get deleted because the issue does not fall within the narrow band of speedy deletion. Although I can't get behind automation, I could get behind is normalizing the speedy deletion process for FOP and more-than-non-trivial copyright-related situations, or possibly creating a special DR queue/process for complicated copyright issues. Fundamentally, though, the issue is about a lack of administerial resources, so thank you for taking this task on. Now, maybe if people weren't so nitpicky during R4A, the issue wouldn't be as bad as it is.  Mysterymanblue  11:18, 24 October 2021 (UTC)
+1 to that. It would be easy for malicious nominations to slip through. It would also help if we had more admins; you know, ones with substantial experience of copyright issues, a proven track record of dealing with vandals, and some commitment to this project. Rodhullandemu (talk) 11:48, 24 October 2021 (UTC)
FoP cases aren't always trivial. There have been quite some nominations based just on lack of FoP without taken into account that the photo doesn't contain any copyrightable works (what structures get copyright protection varies between countries), or includes such works only as de minimis. –LPfi (talk) 11:34, 25 October 2021 (UTC)
Hi, I am against automatically deleting uncontested DRs, as said above. The only long term solution is more man power, i.e. more admins. Regards, Yann (talk) 12:06, 24 October 2021 (UTC)
I agree that automatical deleting of files would be controversial. But from the point of view of automation, wouldn't be helpful to add to every DR some quick summary about the files by bot? (E. g. "copyright holder" from EXIF, resolution, claims of the "own source" – it might be similar to the info that you can get from the OgreBot subpages – I personally find this info very useful.) IMO these quick summaries would minimize time to resolve many DR, at least the straightforward cases. — Draceane talkcontrib. 15:02, 24 October 2021 (UTC)
Being able to see the source from COM:VFC would be very useful to ease review of a large number of files. Currently, VFC only shows the license, the categories, and the metadata. Yann (talk) 15:13, 24 October 2021 (UTC)
I have to second the idea of automated deletion for uncontested DR's. I have personal experience with a good faith user that simply tagged a lot of files as being "Unsourced" (that were often sourced) and because they didn't know how the Wikimedia Commons worked didn't notify any of the uploaders (nor did any bot did it), in some cases this user got 19th (nineteenth) works deleted that were surely in the public domain where also the author was listed and the correct licensing template was at the file, but because the source was usually a URL or website they just tagged them as "No source" and I didn't notice this until I saw a talk page notification at the English-language Wikipedia, apparently this user has been tagging lots of Vietnamese images as "No source" and never going through a single DR meaning that most of these would get deleted without a single human eye ever seeing what was deleted, I uploaded a lot of rare works from a now defunct website that dedicated itself to 19th (nineteenth) century books in the public domain in French written about the Vietnamese language and Traditional Chinese characters, in all cases the website listed the author and their date of death. While going over the user's contributions I found that they tagged a few of the books I uploaded as "No source" and I didn't receive a single notice or notification (despite the files being on my watchlist) and the fact that I had properly tagged these files with the correct copyright templates and authors, but because I listed the source as a website this user probably just thought "External website = Copyright violation", I advised them to user Deletion Requests instead of these templates so at least the uploaders would get notified and they would eventually do this. The issue is, I still have no idea if any of their tagging was successful for these books as it's (near) impossible to search for deleted content like this and from my own personal experiences with undeletion requests it is extremely difficult to get files undeleted. Even if one provides evidence for undeletion the closing admin can just ignore it (if the authenticity of a file is disputed) and with copyright a lot of people make arguments that go far beyond the PCP.
I am not saying that humans never make mistakes, this year I contested speedy deletion tagging of very old files that were obviously in the public domain including an American passport from the 1800's issued during the Napoleonic era for use in France, I contested the "No source" tagging and no further comments were written below "my" DR, an admin wanting to clear backlog deleted the files but when I pinged her and explained that I was contesting automated deletion she undeleted them and closed them as "Keep", in this case human error actually deleted valuable public domain images but because I was dealing with a human calmly explaining why the deletions were wrong got it overturned, this simply isn't possible with a bot. Sure, some admins will make up their minds and will utterly refuse to give justifications and if you ask them at their talk page any further questions will ignore you because to them "the conversation is done" even though you gave evidence another admin can review the evidence and undelete the file. The moment you leave deletions for bots you remove the human element and bad deletions become nearly unappealable. You can't reason with a bot, it just deletes and because bots can't read they can't make decisions based on complicated nominations.
I very much agree that the backlog is an issue, but we shouldn't try to "fight backlog" at the cost of quality, in the end this will cause more issues than what it's supposed to be solving. In fact, most of our deletion infrastructure is very much based on the idea that it's the uploader that's always wrong meaning that "the deletion advocate" (being a nominator or a speedy-tagger or such) is always assumed to be right until an admin says otherwise. We recognise repeated copyright violation uploaders as bad, but we don't see a repeated bad nominators as bad. In fact, a lot of these deletion nominations would have likely been successful if the nominator wasn't a vandal evading an active block. In fact, the active section "User:Rs-nourse, a valuable contributor on heraldry under misguided attack, help needed!" is very much an example of where automated deletion could have have a big negative effect on the Wikimedia Commons. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:46, 25 October 2021 (UTC)

DDR tram year classifications

I started to reorganize the DDR year tram classification for 1989 (the last full year of the DDR) Category:1989 in tram transport in the German Democratic Republic

The templates of 'Tramtransportyear-Berlin', 'Tramtransportyear-Dresden', 'Tramtransportyear-Leipzig' will have to be changed and be made conditional: The German Democratic Republic existed from 7 october 1949 to 3 october 1990. It is unclear how to handle the split years of 1949 and 1990.

I would appreciate some help.Smiley.toerist (talk) 09:44, 20 October 2021 (UTC)

I guess anything happening until October 2nd 1990 happened in DDR, while anything happening from October 3rd 1990 on happened in unified Germany. I've seen that at least for 1989, many pictures say the date they were taken. Taking that into account, very few pictures would be in doubt (DDR or Germany). B25es (talk) 15:42, 20 October 2021 (UTC)
There is a complication that West-Berlin trams also ran until 1967. The other DDR tramcities are no problem. There are at present no 1990 Berlin tram pictures after 3 october. One can always add a the '1990 in tram transport in Germany' category to the few exceptions. I see no way to refine the conditionality of templates beyond the year. I do have examples of a single conditionality xx<1986 (Template:Urkyear) but not a 1946<xx>1990 situation.Smiley.toerist (talk) 09:32, 21 October 2021 (UTC)
However: 'Tram transport in Leipzig by year' goes only back to 1949.Smiley.toerist (talk) 09:36, 21 October 2021 (UTC)
I have added short comments to Category:1949 in tram transport in the German Democratic Republic and Category:1990 in tram transport in the German Democratic Republic and except for Berlin I have also updated the tramtransportyear-city templates. I guess Berlin has to be handled individually, even Category:1988 in tram transport in Berlin contains a tram image of West Berlin. Regards, --Kleeblatt187 (talk) 16:21, 26 October 2021 (UTC)

Upload wizard other license box is unclickable

Tracked in Phabricator
Task T294389

When you use the upload wizard and go to "another reason not mentioned above" under the licensing information, you are given an input box to paste the text of the license tag into. I am unable to move my cursor around in this box by clicking with a mouse; I must use my arrow keys if I want to edit the text of the license, which I often want to do because many license tags accept parameters.

Is this just me? Or is this how the upload wizard acts for everyone? If this is how the Wizard is designed, what is the reasoning for making it like this? For desktop users, it is a mild inconvenience, but for mobile users it actually makes editing the license text without deleting everything very difficult, because mobile devices generally do not have arrow keys for traversing text.  Mysterymanblue  09:58, 25 October 2021 (UTC)

@Mysterymanblue: I haven't tried to work out why, but I can at least confirm that it's not just you, since I get the same behaviour (Firefox 88.0.1 on Debian 11). --bjh21 (talk) 18:48, 25 October 2021 (UTC)
I have added a phabricator task to fix this issue.  Mysterymanblue  20:33, 26 October 2021 (UTC)

Purpose of Template:DuplicatePNG

There is {{DuplicatePNG}} and {{duplicate}}. What is the purpose of the former? It seems that files tagged with {{DuplicatePNG}} do not get properly deleted by administrators.  Mysterymanblue  07:03, 26 October 2021 (UTC)

The former categorizes images into the hidden Category:DuplicatePNG, which nobody checks. Ruslik (talk) 08:50, 26 October 2021 (UTC)
@Ruslik0: Yes... so perhaps deprecation and deletion is in order?  Mysterymanblue  09:18, 26 October 2021 (UTC)
@Huntster: Thanks for putting Category:DuplicatePNG in Category:Duplicate.   — Jeff G. ツ please ping or talk to me 12:37, 26 October 2021 (UTC)
I'll nominate for deletion in a bit, once I get through the tagged files. There's no added value represented there that I can see. — Huntster (t @ c) 12:46, 26 October 2021 (UTC)
@Mysterymanblue: It looks like its purpose was to allow GifTagger to tag GIF files where it had uploaded a replacement PNG version. {{U|GifTagger hasn't run since 2015, so there's a reasonable argument that the template and category are obsolete.
Thanks all for bringing this up. It's now nominated for deletion since the previous "Keep" rationale has been addressed. — Huntster (t @ c) 13:49, 26 October 2021 (UTC)

Request for mass deletion of Fair Use images

Can someone please delete just over a hundred unused FU files on cy-wikipedia please? Many thanks! Llywelyn2000 (talk) 07:46, 26 October 2021 (UTC)

Please ask help on m:Steward requests/Miscellaneous. --EugeneZelenko (talk) 14:58, 26 October 2021 (UTC)
Thanks EugeneZelenko! Just done so now. Llywelyn2000 (talk) 15:31, 26 October 2021 (UTC)

Categorising individual days

We have a category for each day, such as today, Category:2021-10-11. I have just categorised this with the newly-created Category:Individual Mondays, and created six other categories one for each day of the week.

I propose that we subdivide these by years, so that we have, for example, Category:Individual Mondays in 2021 (or, if preferred Category:Individual Mondays in the 2020s) - I do not think we need to subdivide further, such as by month.

I further propose that we apply these categories automatically either through adding code to {{Date navbox}}, or better by merging that into {{Wikidata infobox}}, and applying that.

Otherwise, I will ask a bot operator to apply them directly. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:09, 11 October 2021 (UTC)

i have the same opinion that such categories are not needed.
and even if they were, it should be handled by {{Date navbox}}.--RZuo (talk) 08:44, 20 October 2021 (UTC)

The categories currently exist, so from my point of view, they should either be fully integrated, or deleted (I have no strong opinion about which way we should go). Assuming they are integrated (since no-one commenting here seems to have started a deletion discussion about them), I've set up Pi bot to look through the subcategories of Category:Days by day and add a Wikidata sitelink where it can (most of them weren't previously linked because the category names here are a different date format from the Wikidata labels - but it's easy to convert between them for a bot run). That means that the Wikidata Infobox *could* be added to a lot of them.

I've set up an example at Category:2021-10-27. I think the infobox could replace everything shown by {{PhotoOfTheDay}} (the main bit of which seems to be an image - which you can add via Wikidata using image (P18)). It would also be fairly straightforward to auto-include {{Date navbox}}. Making this change would simplify the wikicode displayed here; would improve multilingual support (using Wikidata labels); would enable auto-categorisation as Andy suggests; would add more helper links to the categories; and would help standardise how Commons categories look; but would also increase the complexity of information shown in the category.

Deployment would be simple - after a few tweaks to the infobox code, I can just remove the bot code that avoids these categories so that Pi bot adds the infobox to them while removing the old templates. If we want to do that. Thanks. Mike Peel (talk) 19:55, 27 October 2021 (UTC)

Inputbox for category search

Hello gurus,

I would like to create an input box in which I could enter the name of a category that I think may already exist, resulting in it returning one or more categories.

I have succeeded as far as searching for articles with the typed-in name:


 

-- but I would like the input box to return a category or categories. (I don't really need "Try exact match" but that seems to come with the code, and it doesn't bother me.)

Help will be greatly appreciated!  –  Cheers, Simon: SCHolar44 (talk) 09:26, 25 October 2021 (UTC)

i believe the prefix option should work?

Karl Oblique (talk) 20:11, 27 October 2021 (UTC)

CommonsDelinker leaving a residue

CommonsDelinker is usually doing good work, however if there's a second article linked to the image, it's not clearing up all image names, text etc, which subsequently appear as broken, red links. Is there a Talk page where this can be discussed please? If it happens on one wiki, I'm sure it's happening on all 300+. Here's an example (on the right; file named 'Ty'r Cymry, Caerdydd ffenest.jpg') where it wasn't deleted. We have a discussion on this on cywiki and I'd like to know the reasons why this is happening. Thanks! Llywelyn2000 (talk) 15:06, 25 October 2021 (UTC)

@Llywelyn2000: You can see from the CommonsDelinker log (linked from the banner at the top of File:Ty'r Cymry, Caerdydd ffenest.jpg) that CommonsDelinker tried to update the page, but it couldn't find the image link there. In cy:Mudiad Ysgolion Meithrin the file was referred to as File:Ty&#039;r Cymry, Caerdydd ffenest.jpg and my guess is that the bot didn't understand that &#039; was just another way to write '. It's notable that on cy:Tŷ'r Cymry (Caerdydd), which the bot updated correctly, the filename was written with a '. --bjh21 (talk) 00:16, 27 October 2021 (UTC)
Thanks for the explanation, and yes the two instances were two different codes. Do we have a tool to find other similar residues / red-links? Secondly, as this is an issue, can CommonsDelinker be corrected so that it doesn't happen? Llywelyn2000 (talk) 06:33, 27 October 2021 (UTC)
@Llywelyn2000: I don't know of any such tool. If you want to report a problem with CommonsDelinker, the "bugtracker" link at the top of m:User:CommonsDelinker may be helpful. --bjh21 (talk) 10:50, 27 October 2021 (UTC)

Account too new to use Twinkle

My account is over 18 years old. I made my first edit on this project on 5 April 2007. Ive just got a notification that "Your account is too new to use Twinkle." How much longer must I wait? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:57, 29 October 2021 (UTC)

Commons:Twinkle says "Twinkle does not work on Commons." --Magnus (talk) 11:12, 29 October 2021 (UTC)
Page marked as inactive since 2014. If it really does not work, then maybe it's time to remove the instructions on how to enable it and everything else that's not relevant for Commons. Basically keep the page for users who might look for it but reduce the content to "does not work on Commons, here's what else you can try". --El Grafo (talk) 11:22, 29 October 2021 (UTC)
@Pigsonthewing, Tsungam, and El Grafo: Of course, it would be nice if someone could get the actual Twinkle to work here. In the meantime, I use the following code in my m:User:Jeff G./global.js (yours would be m:Special:Mypage/global.js) for some functionality:
if ( (mw.config.get("wgDBname") !== "wikidatawiki") && (mw.config.get("wgDBname") !== "testwikidatawiki") ) { // Don't work in Wikidata
    // Fork of Twinkle intended to work on as many wikis as possible, copied from JavaHurricane
    mw.loader.load('//meta.wikimedia.org/w/index.php?title=User:Xiplus/TwinkleGlobal.js&action=raw&ctype=text/javascript');
}
  — Jeff G. ツ please ping or talk to me 11:30, 29 October 2021 (UTC)
I can confirm that TwinkleGlobal works well for basic tasks. I've also been looking into twinkle-starter as a way to import some additional features of Twinkle from en.wiki, such as file tagging. clpo13(talk) 18:32, 29 October 2021 (UTC)

Archiving user talk pages that are too long?

from time to time some user talk pages will be too long to properly load transcluded templates.

i have an idea -- those pages should probably be obliged to set up automatic archiving (at least an one-off archiving) by other users/a bot. is this idea reasonable? has this issue been discussed before?--RZuo (talk) 21:42, 23 October 2021 (UTC)

Automatic archiving makes sense in those cases. Actually we just need to add
{{User:MiszaBot/config
|archive = User talk:***/archives %(counter)d
|algo = old(15d)
|counter = <s>48</s> 1
|maxarchivesize = 100K
|minthreadsleft = 4
|minthreadstoarchive = 1
|archiveheader = {{talk archive navigation}}
}}

to these talk pages, replacing *** with the username. Yann (talk) 15:07, 24 October 2021 (UTC)

... and replace 48 with 1. -- Andreas Stiasny (talk) 13:09, 25 October 2021 (UTC)
@RZuo and Yann: In my experience, "maxarchivesize = 100K" can be way too large, 18K is much safer.   — Jeff G. ツ please ping or talk to me 14:07, 25 October 2021 (UTC)
Right, counter = 1.
@Jeff G.: My experience is quite the opposite. 100K makes moderately long archive pages, while a smaller size would create too many pages. Ultimately it is up to eachone to ajust the parameters. Regards, Yann (talk) 18:29, 25 October 2021 (UTC)
@Yann: Please see revision 569666601, only 18,855 bytes but in Category:User talk pages where template include size is exceeded.   — Jeff G. ツ please ping or talk to me 21:54, 25 October 2021 (UTC)
Is there a way to get the bot to count templates instead of bytes?—Odysseus1479 (talk) 03:30, 27 October 2021 (UTC)
@Odysseus1479: That is not likely, but I am Pinging @-revi, Whym as ArchiverBot's maintainers just in case.   — Jeff G. ツ please ping or talk to me 12:56, 27 October 2021 (UTC)
I suppose another possibility is to have the bot subst: or expand the templates for archiving purposes—I noticed Fæ’s bot doing that on a few prolific uploaders’ pages—but unless it can discover the user’s language preference the i18n would be lost.—Odysseus1479 (talk) 19:09, 27 October 2021 (UTC)
@Jeff G.: OOPS... I wonder why users with such a long list of warnings were not blocked before... Yann (talk) 14:43, 26 October 2021 (UTC)
@Yann: No Admin acted on Commons:Administrators' noticeboard/Blocks and protections/Archive 30#Bull-Doser before automatic archival.   — Jeff G. ツ please ping or talk to me 15:15, 26 October 2021 (UTC)
  • Support archiving. Andy Dingley (talk) 18:50, 25 October 2021 (UTC)
  • Honestly, I never got why the welcome-bot doesn't also add an automated archiving template (like the above) on user talk pages for any thread older than 365 (three-hundred-sixty-five) days, some users only come here to upload stuff and never check their talk pages which could be extremely long. Some users simply don't know that they can archive, and unlike other Wikimedia websites, the Wikimedia Commons has a much, much stronger culture of automation and automated messages (only less so than Wikidata) so having automated archiving would make sense. Another issue is that for some users seeing all the deletion request templates makes them think less of the users, even though the copyright issues are for vastly different subjects, there is a difference between a user that only uploads copyrighted FOP violations of statues in a country with no FOP and a user that travels around and sometimes uploads images of statues from a country with no FOP.
Automated archiving would keep all the records of past discussions and deletions easy to find, while it would also let users leave these old warnings behind them. Most users probably don't know how any of this works and some users have extremely long talk pages with messages that are over a decade old, it would work better as an opt-out system than an opt-in (if people don't like the automated archive they can remove it, but if they do like it they could just leave it alone). --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:19, 25 October 2021 (UTC)
 Support. See also Commons:Administrators' noticeboard/Archive 76#Messaging 37 accounts about their transclusion count problem.   — Jeff G. ツ please ping or talk to me 14:04, 30 October 2021 (UTC)

File:De-Acre.ogg

This file should be deleted. It's a weird pronunciation that's apparently an attempt at an English spelling pronunciation by a German speaker. It's neither English nor German, which it should be. --Espoo (talk) 08:28, 31 October 2021 (UTC)

Espoo, if I am not mistaken, the deletion can be requested at Commons:Deletion requests. Hulged (talk) 08:39, 31 October 2021 (UTC)
@Espoo and Hulged: There are multiple methods of requesting deletion, as detailed at COM:D.   — Jeff G. ツ please ping or talk to me 12:54, 31 October 2021 (UTC)

Berlin rail transport maps before the wende and after WW II

There are a lot of recent S-Bahn maps, but no maps with the city wall border, where many lines where interrupted. It would be usefull to illustrate the breakup of the rail network into a east and west part, with some trough running of Western S-Bahn trains in East Berlin territory.Smiley.toerist (talk) 15:18, 31 October 2021 (UTC)

PS: in the Category:Train stations in Berlin there are a lot of 'Station in Berlijn 1990 x' with unidentified stations.Smiley.toerist (talk) 15:21, 31 October 2021 (UTC)

Mis-labelled months

Hello, as of now various categories, which use Template:Date, display wrong month names, such as Category:September 2014 in Leipzig, Category:February 2021 in Dresden and Category:April 2019 in Prague. It seems to me that everywhere February, April, June, September and November are affected in any language, not only english. I assume that there is recent edit mistake somewhere in the „backgrounds“ of Template:Date or Module:Date. But I cannot find the place ... Could someone please have a look? Thanks in advance! Regards, --Kleeblatt187 (talk) 15:35, 31 October 2021 (UTC)

The last edits to Module:DateI18n were made by @Verdy p: in the September. Ruslik (talk) 20:32, 31 October 2021 (UTC)
Which language are you trying to display? I looked there, and labels (for months?) are shown correctly in the languages specially translaterd in the Category template (German, English, French, Polish, Swedish...).
May be this is data specific to a language that is incomplete for month names, or there's a need of a special form (e.g. changing the grammatical case) for specific languages.
If you are speaking about the abbreviated month names (shown in the horizontal table), they are not translated by Template:Date but inside the navigation template (showing counters of pages per month below each month of the year).
I've tried cleaning a bit one of the nav template for Months in Leipzig (before that, I did not edit anything there, when you posted your comment). May be this makes things clearer, and can be applied to similar templates for Dresden, Prague.
But there was nothing wrong in the displayed labels, that correctly display the expected months and in the appropriate language (and abbreviations used in the table look ok for me, in English, German and others, and correctly fallback to English abbreviations for missing translations, e.g. when viewing these pages in Russian or Italian). I did not create these Categery nav templates. So please explain better what looks wrong for you. May be it's just the presentation that is misleading you, or there are problems of caches in your browser?
verdy_p (talk) 14:17, 1 November 2021 (UTC)
Thanks for your replies. I was only talking about the labels below the table (which display the respective category's month name in cs / de / en / pl / sv etc.), not the table itself. The table was always correct as far as I did watch. For example in the before mentioned february categories there was displayed the word for March in all displayed languages, in the november categories the word für december in all displayed languages. But anyway, the problem which I mentioned seems to be fixed as of now (not only for Leipzig) – by whatever and by whoever. Nevertheless I would be interested in what happens. The phenomenon has been watched and mentioned by further users before, e.g. here. Then, back in February 2021, the unknown misspelling was also gone after a few days. Regards, --Kleeblatt187 (talk) 09:18, 2 November 2021 (UTC)

User:Rs-nourse, a valuable contributor on heraldry under misguided attack, help needed!

User:Rs-nourse has contributed thousands of premium quality images on heraldry, all his own work, but he is now being threatened by User:JuTa with mass speedy deletions for supposedly not having credited authors of derivative work. We are lucky to have such a talented artist contributing his work to our site. All the work is his own, as he states in the licences, there is no derivative work to credit! What can be done to halt this misguided threat by User:JuTa and make him discuss his concerns before he jumps to what are totally erroneous conclusions? Please see recent posts by User:JuTa at User talk:Rs-nourse which set out his erroneous concerns. Is he really able to just delete all this great work so casually and negligently?Lobsterthermidor (talk) 16:53, 21 October 2021 (UTC)

Pinging @Rs-nourse, JuTa as a courtesy.   — Jeff G. ツ please ping or talk to me 16:56, 21 October 2021 (UTC)
You raised this on JuTa's user page 15 minutes before bring it here, then did so without waiting for their response. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:58, 21 October 2021 (UTC)
User's uploads are coats of arms. Appear to be historical ones, so user is not designs' authors. --EugeneZelenko (talk) 17:06, 21 October 2021 (UTC)
Sorry, Pigsonthewing, I am panicking a bit, as it seems speedy deletion is threatened. Similar threat being made to his work by another admin, who as you advise I won't name here, but have raised it on his talk page.Lobsterthermidor (talk) 17:21, 21 October 2021 (UTC)
Hi EugeneZelenko, thanks for your rapid response. I'm not sure I follow your point, please elaborate/clarify. Are you saying that he's not allowed to reproduce a design seen on a coat of arms, i.e. following the pattern set down but in his own unique way with his own artistic interpretation? The arrangement of a coat of arms, i.e the "blazon" (written instruction for artists, i.e. Gules, a chevron or - meaning, "a gold chevron on a red background") is not subject to copyright restrictions, that would be a misunderstanding I think. Is that the problem?Lobsterthermidor (talk) 17:21, 21 October 2021 (UTC)
Please see Commons:Coats of arms: "Coats of arms drawn by users based solely on the definition (blazon) without any reference to the original drawing (representation) are usually safe for upload." The coats of arms created by Rs-nourse seem to be based on the blazon (which is mentioned in the description, for example in File:Coat of Arms of NEFYDD HARDD, of Caernarvonshire, Lord of Nant Conway.png "Argent a chevron sable between three spear heads of the second, embrued, points upward"), so they are OK imho. COM:AGF should apply too. BrightRaven (talk) 08:58, 22 October 2021 (UTC)
I have not looked at all the files, but File:Coat of Arms of the See of Hereford (ancient).png, for example, is perfectly legit. The blazon and its source are clearly mentioned in the description (moreover, it is a PD book published in 1848). It is not right to flag it as "no source". BrightRaven (talk) 09:09, 22 October 2021 (UTC)
BrightRaven, thanks for your input and for directing us to the guideline Commons:Coats of arms, which seems pretty clear. However, even the statement of the blazon or source is surely unnecessary in the file description - although much encouraged for its usefulness to students of heraldry - there is no copyright on coats of arms - unless reproducing original artwork. In other words we should not set a precedent that any coat of arms image which does not quote the blazon is liable to speedy deletion. It is important to clear up this issue definitively, there are hundreds of thousands if not millions of images of coats of arms on wikimedia, which would all qualify for speedy deletion under these misguided criteria. The use/bearing of another person's coat of arms, for example displaying it on one's tomb, used to be a serious offence a few centuries ago, dealt with by the Heralds' Court, in at least one famous case meriting the death sentence. The unauthorised display of the royal arms in England will still today cause a visit from the police, but the reproduction of coats of arms, in one's own artistic interpretation, for academic/exposition purposes, has never been a legal/copyright issue. We await a fuller response - and hopefully retraction - from the two persons concerned who have threatened speedy deletion of all these images, due it seems to a genuine misunderstanding of the issue, which is no doubt somewhat distressing to Rs-nourse - and to others here interested in heraldry, like myself, as his work (with other notables such as Sodacan, etc) forms the backbone of the heraldry project on wikimedia. I'm copying your statement to Rs-nourse's talk page, as a handy riposte in case of future ocurrences.Lobsterthermidor (talk) 14:03, 22 October 2021 (UTC)
  • JuTa seems to have already speedily deleted a few thousands (!!) of these CoA images. Of the few that remain, it would seem that the few that are not 100% Rs-nourse’s {{Own work}} (assuming COM:AGF) are derivative works including (as “clipart”) what is obviously {{PD-old}}. These should be tagged as such, but the whole thing needs to be undeleted and reevaluated by users interested in making/keeping Commons as a repository of free media. (It is especially commendable that some Heraldry artists are willing to freely license their work, by the way, as so few do it.) -- Tuválkin ✉ ✇ 19:37, 22 October 2021 (UTC)
    I agree (and with much that Lobsterthermidor and BrightRaven say above), and am quite disappointed to see that the tagging and deletions were done so hastily and without discussion or detailed rationale—especially considering the quantity.
    Regarding blazons, where official (or at least recorded) versions are available they’re a valuable inclusion for provenance, educational value, and verification, but their omission should not be sufficient ground for deletion in itself. More generally I would argue that illustrating arms from a blazon is exactly the artistic equivalent of paraphrasing a piece of writing in one’s own words: as long as you’re not copying or imitating others’ creative expression, you’re not infringing on their IP. The ‘Platonic form’ of the arms described in a blazon (whether explicit or deduced from a given emblazonment) is a non-copyrightable idea. (I might add that there’s little scope for individual style in many heraldic elements, which have highly conventional forms making them more like letters of an alphabet than pictures. The example mentioned above, Gules a chevron Or, would certainly fall below the American ToO and probably many lower ones as well, unless executed with an extraordinary amount of w:diapering, ornamental contouring or suggestion of dimensional moulding with light & shade. That said, human & animal figures, among other more complex elements, can exhibit considerable creativity and distinctiveness.)
    Regarding laws regarding misappropriation of arms, these are non-copyright restrictions, which I think of as a combination of personality rights & trademark protection. (At any rate I believe the only heraldic authority that still has any legal teeth of its own is the Lord Lyon’s court. Of course one would expect misrepresentation that’s outright fraudulent to be criminal anywhere.)—Odysseus1479 (talk) 01:24, 23 October 2021 (UTC)
  •  Support mass restoration of all deleted images. It is not reasonable to expect a contributor to respond to thousands of these tags in a single week. If any individual images appear to be problematic, they can be nominated through a regular DR. -- King of ♥ ♦ ♣ ♠ 06:02, 23 October 2021 (UTC)
this is unacceptable behaviour. the user has been active for two days after being notified, but did nothing to reverse the obviously wrong tags.
if it had been any ordinary user, s/he would have been blocked for disruptive editing.--RZuo (talk) 21:42, 23 October 2021 (UTC)
I also  Support the mass restoration of the deleted files. BrightRaven (talk) 08:25, 25 October 2021 (UTC)
While this is not a vote I also (morally)  Support their undeletion, having gone through the quagmire that was "Commons:Deletion requests/Files in Category:Media without a source as of 30 May 2021" and similar bad tags like "Commons:Deletion requests/File:1815 US passport - LONDON.jpg" (yes, a US GOVERNMENT file from 1815 tagged for speedy deletion) I wonder how much of this automated deletion is has already destroyed. I think that we should have a new version of deletion requests where these tags create new pages where users can challenge them, also because they are not permanently recorded in a searchable archive (unlike DR's) we can't know how many good files have been deleted because of such tagging. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:52, 25 October 2021 (UTC)
Well, the drastic action of mass deleting these files does not appear to have received any support here at all. I am not surprised. The question now is: how do we go about getting these images restored? I have had no response from User:JuTa, to my post on his talk page, and it seems the user who did the deletions was User:Fitindia, again I have left a message on his talk page. As I said these images are the backbone of the wikimedia heraldry project, we cannot afford to be without them.Lobsterthermidor (talk) 11:11, 27 October 2021 (UTC)
Great news guys, User:Fitindia has restored the thousands of images he deleted. Still no reply from User:JuTa who may be on a wiki-break, we need confirmation from him that this will not happen again. Thanks for all the support - sadly Rs-nourse now seems inactive, but as he generously donated his valuable images to the project, we can say we've fought on his behalf with success. I am copying this discussion to his talk page, for future reference.Lobsterthermidor (talk) 12:23, 30 October 2021 (UTC)
  •  Comment, for anyone interested in this, I opened another discussion down below about the same type of misguided "No source" tagging by the same Bureaucrat, in all the cases I found the files were both properly tagged and properly sourced, so if anyone would want to help out save those images from automated deletion then please do and then comment in the relevant section below (named "9.4 Missing source?! What am I missing here? (16Exul82)"). In this case it concerns centuries old German documents and drawings with proper source and authorship information. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:33, 4 November 2021 (UTC)

WikiMemes User Group

(Sorry for using an IP)

WikiMemes User Group (on Meta) does very weird things. They have groups on Facebook, Telegram and Instagram, called "wikishitposting" where they post pictures like 1 or 2, featuring real people. The name of the groups is publicly published, the users are identifiable (at the bottom of the page). -- 115.84.96.174 08:47, 30 October 2021 (UTC)

1) As far as I can tell, that's 100% standard internet behavior. Questionable, but normal. See en:Internet meme in general, en:Image macro in detail and en:Bad Luck Brian in particular.
2) This has nothing to do with Commons in particular, meta would probably be a better place to complain about that.
--El Grafo (talk) 15:50, 30 October 2021 (UTC)
@El Grafo: Please see m:WM:RFH#Report concerning User:Sabas88 then.   — Jeff G. ツ please ping or talk to me 23:45, 30 October 2021 (UTC)
  •  Comment, just to be clear, this page is not spam as it clearly also States to seek to document internet meme culture on Wikimedia websites (which has both educational and historical value) and its founder, Sabas88, has been an active member of Wikimedia websites for over a decade. I don't see what's wrong with the page, especially since it has the potential to introduce Wikimedia websites to more demographics that we're currently not reaching through exposure. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:01, 31 October 2021 (UTC)

COM:PEOPLE and COM:L broken. This group uses non-free pictures on the social networks and pretends its actions compatible with Commons. This is counter-educational. -- 115.84.95.158 23:30, 31 October 2021 (UTC)

Small change to Upload Wizard coming regarding EXIF geolocation metadata

Tracked in Phabricator
Task T284941
Mockup of proposed EXIF geolocation warning for users

Hello everybody! A small change to the Upload Wizard is coming regarding EXIF geolocation metadata, that will inform users about the risks of sharing the geolocation of their images.

An audit conducted by the WMF Security Team earlier this year revealed that this kind of data may pose privacy risks for Wikimedia editors, as bad actors may deduce (or try to deduce) their likely location from their uploaded media.

The suggested measure to counteract this is to inform the uploader very clearly, through a note in Upload Wizard, that such geolocation metadata will be collected and made public - making it, in the end, an informed decision of the editor to upload the media or not.

This change will be rolled-out in the next few days, I will keep you updated on this. I am here in case you have any questions or requests for more information. -- Sannita (WMF) (talk) 17:38, 26 October 2021 (UTC)

@Sannita (WMF): Can you confirm that, as shown in the mockup, the warning will be shown for all uploaded files, whether or not they include geolocation metadata? --bjh21 (talk) 22:08, 26 October 2021 (UTC)
Beseitigt doch besser die Fehler des Uploaders. Das wäre wichtiger. Gruss --Nightflyer (talk) 22:42, 26 October 2021 (UTC)
@Bjh21: Yes, it will be shown for all uploaded files. Sannita (WMF) (talk) 12:31, 27 October 2021 (UTC)
@Sannita (WMF): This seems like a terrible idea. Showing a warning every time a tool is used simply teaches users to click through the warning without thinking. The warning should be shown only when it is relevant! Even better would be to display the actual metadata (if any). Brianjd (talk) 14:20, 4 November 2021 (UTC)
@Sannita (WMF): thanks for the heads up. Where does the "learn more" link go and can we please be selective about which parts of the meta data we suggest to be removed? It's a good idea to remove position information from pictures taken at home, but there's really no good reason to scrub the whole meta data and remove things like shutter speed or camera model. --El Grafo (talk) 11:33, 29 October 2021 (UTC)
@El Grafo: thanks for the question, and sorry for the delay (for some reasons, the notification system didn't work). The "learn more" link will link to Commons:Exif, and the request is and will be limited only to geolocation. Sannita (WMF) (talk) 19:53, 3 November 2021 (UTC)
@Sannita (WMF) thanks, that makes sense. El Grafo (talk) 12:18, 4 November 2021 (UTC)
@Sannita (WMF): This does not make sense at all. Commons:Exif starts:
Photos taken with a digital camera are likely to be JPEG images with embedded Exif data, with automatically recorded date and time the photo was taken, exposure settings, focal length, and so on.
It does not say anything about location. Later, there is this heading:
Display of geolocating Exif metadata on image description pages
I almost got a headache just trying to read that heading. Even if a user finds that section somehow, they will find a single paragraph about user interfaces, uploaders and bots. If the aim is to provide clear warnings about location data, this is a clear failure. Brianjd (talk) 14:20, 4 November 2021 (UTC)
@Brianjd: Then I guess either the page should be updated, or we need to create a shortcut to that paragraph. Or we need to find (or create?) another landing page. Anyway, this part of the decision is going to be a community-led decision, so all suggestions are welcome. Sannita (WMF) (talk) 14:26, 4 November 2021 (UTC)
Yes, that page could certainly benefit from an update. In general, we prefer EXIF data to be present, to the point that photos without EXIF data are seen as suspicious from a copyright perspective. But privacy concerns should be discussed on that page as well. Be aware though, that there are different view points. A professional photographer may actually want to be identifiable through the meta data for publicity and copyright reasons. It's not that easy … El Grafo (talk) 14:54, 4 November 2021 (UTC)
@El Grafo: Does non-location information matter? The answer is right there at w:Exif#Privacy and security (emphasis added):
For example, a photo taken with a GPS-enabled camera can reveal the exact location and time it was taken, and the unique ID number of the device - this is all done by default - often without the user's knowledge.
This may not be the end of it. I have been wondering whether a large collection of Exif data can form a fingerprint; I am not aware of any research into this issue. Brianjd (talk) 14:20, 4 November 2021 (UTC)
Yes, it may be a good idea to remove things like that if privacy is a concern. That should be an informed decision made by the individual user. My comment above was directed at photographic parameters that pose no risk and can be useful. El Grafo (talk) 14:47, 4 November 2021 (UTC)
@El Grafo and Brianjd: Just to be 100% sure: this is a message intended to make users aware of this problem - if they want to continue uploading their files with geolocation, it's fine. We are just saying that they should be aware of this problem, and decide if they want to go on or not. This is not intended to force people to not upload those data in any case. Sannita (WMF) (talk) 15:49, 4 November 2021 (UTC)
Yes, I got that – I was just thinking out loud about how the info page should look like. Sorry if that was confusing, I think we're actually all more or less on the same page here. El Grafo (talk) 17:25, 4 November 2021 (UTC)
I clicked on the section hoping to see a message telling me that the bug that caused UW to fail to pickup and display the geotag from the exif had been fixed. Has it?
I can see why a specific editor may be reticent about revealing their location and should have a global option to prevent it occurring on all their images- but if that is the case they shouldn't be uploading an image here. Removing location information is like adding NC to their copyright tag. An image is the exif, and the visual content it contains.
As this appears to be a fait accompli, can you add a global preference so an uploader can reject the addition of this tag. I do see the situation in the future where some faction will write a bot that will go to tagged files and remove exif data regardless. When testing a mod, all variations must be considered, not just the simplest case I don't find the graphic on one file helpful. Is Commonist working yet, is vicuna working- at the moment UW is all we have got and it needs to be reliable for mass uploads. You have to know that the exif is secure from future actions. --ClemRutter (talk) 15:34, 4 November 2021 (UTC)
@ClemRutter: regarding the bug you're referring to, can you please link me something? I really don't know anything about it, but probably I can link you the correct Phabricator link.
Regarding the advice: again, I made it very clear in my initial message. The intention of this is to inform the uploader very clearly, through a note in Upload Wizard, that such geolocation metadata will be collected and made public - making it, in the end, an informed decision of the editor to upload the media or not. No further actions are planned, nor wanted. Sannita (WMF) (talk) 15:49, 4 November 2021 (UTC)
Thanks, @Sannita (WMF): the bug is (T223051)-but it is a questions of resources and priorities, and the more people that are aware of this bug the greater the chance of a fix. in the conversations above we are talking of a privacy improvement that is great for a single upload but very clumsy for multiple geographical shots. I have a queue of 250 images waiting to be uploaded of images along a canal in North London- they are sufficiently similar to copy down one description leaving the differences in the filename which is prepared offline. I won't be looking at each uploaded image- and don't need or want each one to be tagged with a privacy warning. It doesn't add any value to the potential user, and will confuse when included on a non en wiki. As to future actions by zealots- we need to make their deletionist ambitions as hard as possible to achieve. We see disruptive zealots all the time on en:wiki. If the intention is to leave a message to the uploader then it need not to be visible to the general user- or more feasible is to give prolific users the chance to opt out. --ClemRutter (talk) 17:46, 4 November 2021 (UTC)
I think I got the message, and I'll relay it to the team. :) Moreover, I see that there are already some suggestions about how to make the message more user-friendly. I'll try to suggest to somebody also to look at the bug, but on this I cannot promise you anything specific, except that I'll talk to someone and hopefully I'll let you know. Sannita (WMF) (talk) 15:39, 5 November 2021 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Archive/2021/10&oldid=606806605"