Shortcut: COM:VP

Centralized discussion See also: Village pump/Proposals   ■ Archive Commons:Requests for comment/Hosting of free fonts in Commons (18 July 2024) How do we organize categories by date (14 May 2024) Should PD-CQ Roll Call be used for recent images? (5 January 2024) Technical needs survey (17 December 2023) When does PDART apply to textile works? (15 November 2023) Does this image contain "love hearts"? (17 August 2023) Overhaul of categories by period (5 December 2022) Version of Saudi flag to use (11 July 2022) Concern regarding revocability of KOGL licenses (22 December 2021) Should deleting content from your own talk page be forbidden? (11 November 2021) Revise the COM:FOP Sweden section (1 February 2021) Change technical name of LRs to license-reviewer from image-reviewer(2 November 2023) Template: View   ■ Discuss    ■ Edit   ■ Watch

	SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 7 days.

The proposal to restrict non-autoconfirmed users from using cross-wiki upload tools has received unanimous support so far, despite proposer's attempts to withdraw the proposal. Do I need to notify all wikis at Tech News or something? Actually, I'm thinking about writing a Phabricator task requesting implementation of such restriction. Furthermore, I'm unsure whether re-proposing this at Meta-wiki is necessary. George Ho (talk) 07:05, 19 July 2024 (UTC)[reply]

It was already in the m:Tech/News/2024/29. But we should of course add it again when we have the final date when it comes into force. The idea was to simply do this with a abuse filter as a new functionality for this might take a while to be developed. The other changes need to be done on the lokal Wikis. GPSLeo (talk) 08:10, 19 July 2024 (UTC)[reply]

I'm not sure how that will work. What will "the other changes" look like? Isn't it going to require a large scale coordination with sister projects and local sysops, or otherwise cause a major disruption in that many new users will still be invited to do cross-wiki upload locally, prepare uploads, and be told "sorry, you cannot do that" at the end of the workflow? It seems like we need some significant time investment in any way. whym (talk) 11:37, 19 July 2024 (UTC)[reply]

The warning that the tool only works if the user was on Commons before and has the rights can simply be added to the default text of mw:Manual:$wgUploadDialog. If local Wikis have overwritten the default text they need to make the change locally. GPSLeo (talk) 14:10, 20 July 2024 (UTC)[reply]

Can you suggest an example of the warning text? Will it be clear if the user is allowed to upload or not, and where is the workaround if they are not allowed to proceed? (Something along the lines of "Click here (link), and if it says ___ you cannot upload", "You can still upload if you go to ___"?) Note that not every average user understands what "autoconfirmed" means, or how their centralauth-connected accounts work. I think many will be surprised to see they have "new" Commons accounts when they have contributed to Wikipedia for a long time. whym (talk) 01:36, 21 July 2024 (UTC)[reply]

@GPSLeo: All right. Abuse filter first then. After that, "the other changes" can be proposed then, but I think Meta-wiki RFC is one of best options, especially for larger wikis, for central discussion. Unsure why this matter should be resolved locally. George Ho (talk) 00:12, 20 July 2024 (UTC); amended per replies below, 18:28, 20 July 2024 (UTC)[reply]

After the tech news and the message on m:Wikimedia Forum there were no responses from other projects. Therefore I think the other projects do not really care about this and therefore I think an additional RFC on Meta is not needed. GPSLeo (talk) 14:05, 20 July 2024 (UTC)[reply]

+1. Having an RfC about it on Meta-wiki is super redundant at this point. There's been more then enough time and cross project notifications for people from outside of Commons to comment on this if they wanted to. --Adamant1 (talk) 14:58, 20 July 2024 (UTC)[reply]

This phab ticket has been made: phab:T370598. --George Ho (talk) 22:14, 21 July 2024 (UTC)[reply]

@Adamant1@GPSLeo@George Ho@Whym one more reason to restrict cross-wiki to experienced users only: File:Unitel Headquarters at Ulaanbaatar, Mongolia.jpg. We restored this since Mongolia now has compatible FoP, but we seem to have failed to take into account its relatively-low resolution for a 2017 upload. Checking through reverse image searching via Google Lens, it appeared it was used in this 2014 Japanese tech article. Note that it was a cross-wiki upload through mn.wikipedia. JWilz12345 (Talk|Contrib's.) 02:10, 28 July 2024 (UTC)[reply]

I don't know if not allowing the crosswiki upload tool would have prevented that. Don't we regularly see similar copyright violations uploaded using the normal upload wizard? whym (talk) 12:46, 29 July 2024 (UTC)[reply]

Does anyone know how to do this? See image. Everything in this German newspaper has been made un-editable by the common man. Unless, whoever is converting all these files to sole control by WD, takes responsibility for making these entries perfect, then maintenance here, is hopeless. Who, even, is doing this? Broichmore (talk) 16:47, 22 July 2024 (UTC)[reply]

@Cryptic-waveform: : your template, so you can presumably answer better than anyone else. - Jmabel ! talk 17:24, 22 July 2024 (UTC)[reply]

It looks to me like author = {{various}} is hardcoded in the template with no override possible, which I think should not be the case. - Jmabel ! talk 17:25, 22 July 2024 (UTC)[reply]

Hello. First of all I've only modified the file to use a more general template rather than a template-by-year, to remove duplicate code and differences between templates. Additionally I've also extensively documented the template.

As for the question of why, there are a lot of benefits to the current approach. It ensures that all files looks similar, link to previous and next page, and automatically link extracted images.

@Broichmore: : What change are you trying to make? I can look into making it possible. Cryptic-waveform (talk) 20:06, 22 July 2024 (UTC)[reply]

Small questions, potentially big answers.

I'm concerned with images, rather than pages.

Most of these points are covered in the existing artwork template.

Regarding engravings, We, would want to include for, the engraver/etcher, the artist of the intermediate drawing, and the author of the original sketch, photographer, painter, or sculptor.

We would want to include for caption (title), ability to augment the description. Adding translations of same.

Perhaps, issue number, page number, volume number.

Expanding on the date, if known.

Adding in depicted place or people? Place of creation? Credit line?

Flexibility on choice of License?

As to the benefits? The artwork template already makes one file look similar to another, and automatically links extracted images.

I understand? your idea for the use of templates. However, in the long term, what we need to do is have choice of license linked in some way to last or most appropiate creator. Wikidata could do that, because it contains death date, citizenship, and workplace. Broichmore (talk) 08:44, 23 July 2024 (UTC)[reply]

@Cryptic-waveform: Can we can also add, into your template, the Other versions function. Here's an example. _ Broichmore (talk) 12:13, 27 July 2024 (UTC)[reply]

The Gartenlaube, has drifted away, from how we treat newspapers of this era on the project. One thing thats needs cleaning up, is this page, and how the all date cats on it are sorted. See 1920 in particular. Can you fix?

Already Gartenlaube images suffer from very little or no content development. It's not a place for casual visitors. It's very niche, only really accessible to editors with a German background and language, and we don’t have enough of them. It's use of gothic script, and the way that artists and engravers signed work their work, makes for highly specialized work.

French periodicals, suffer from a similar lack of interested contributors, only they don’t use a difficult typeface, and they don’t have the added handicap, IMO of being Wikidata centric. Broichmore (talk) 09:10, 23 July 2024 (UTC)[reply]

To sum up, the kind of people, who can easily read the text and identify the artists are not the kind of people, that relate to, or want to be tied up in wikidata. Broichmore (talk) 09:13, 23 July 2024 (UTC)[reply]

(Preventing this from being archived while unresolved. - Jmabel ! talk 14:40, 30 July 2024 (UTC))[reply]

Optional "author" parameter added. - Jmabel ! talk 18:23, 30 July 2024 (UTC)[reply]

@Broichmore: was there some other specific change you want to this template? - Jmabel ! talk 18:27, 30 July 2024 (UTC)[reply]

Thanks for asking. Think, I've actually covered everything in 3 posts. Others may think differently.

The Artwork template covers dimensions, but I've never known it to be used for newspaper clippings, though it probably should be, if only for centerfolds, or full pages.

This Gartenlaube template may only have been in use, since November 2022? It may be a child of an earlier global Gartenlaube template from September 2007 by Joergens.mi. Other newspapers of the era, did not attract, such attention in commons, till around 2012? Since 2012, we have treated newspapers in a simpler and more accessible way by using the standard artwork template, which is easily accessible by casual visiting editors, etc. Perhaps this is what's needed here. _ Broichmore (talk) 11:21, 31 July 2024 (UTC)[reply]

Hey All We at Wiki Project Med have funded an image annotation tool that meshes with Commons. It is still a little rough around the edges with further ongoing development. If you have suggestions please add them here Doc James (talk · contribs · email) 02:06, 25 July 2024 (UTC)[reply]

I totally don't understand what this does. I put in the name of a file on Commons and it offered to upload it to Commons. - Jmabel ! talk 04:23, 25 July 2024 (UTC)[reply]

@Jmabel: It looks like the tool works if you just copy and paste the URL for the page instead of the actual image. --Adamant1 (talk) 04:47, 25 July 2024 (UTC)[reply]

I can still make no sense of what the tool is supposed to do. It seems to be offering to upload the image over itself. - Jmabel ! talk 17:49, 25 July 2024 (UTC)[reply]

@Jmabel:

My take is the tool is a simple web-based graphics editor. The goal of the editor is to take bitmap files (e.g., a JPEG medical image), and add leader lines and text labels to that bitmap (e.g., labeling muscles). After editing, the file can overwrite the original on Commons or write to a new location.

Think about downloading a bitmap file to a Windows machine, using MS Paint to add some text, and then reuploading the file to Commons.

Glrx (talk) 18:23, 25 July 2024 (UTC)[reply]

So this is for on-image annotations? And if you overwrite with it on anyone's images except your own, you are almost always violating policy? - Jmabel ! talk 18:49, 25 July 2024 (UTC)[reply]

@Doc James: Glrx (talk) 19:47, 25 July 2024 (UTC)[reply]

Per Commons:Overwriting existing files one is allowed to make minor improvements followed by overwriting existing files. Otherwise one should upload it as a new file. Doc James (talk · contribs · email) 22:46, 25 July 2024 (UTC)[reply]

Adding text to an image almost always means limiting its use to a single language, so it is rarely an uncontroversial modification. - Jmabel ! talk 23:41, 25 July 2024 (UTC)[reply]

It looks like you can also draw on the image and add shapes to along with the annotations. So it properly shouldn't have the option overwrite files or at least have a warning regardless. Otherwise there's no way people using the tool won't just overwrite images when they should be uploading a new version instead. --Adamant1 (talk) 04:23, 26 July 2024 (UTC)[reply]

Both options are present. We can set new image to be the default. Here is a user script to make its use easier https://commons.wikimedia.org/w/index.php?title=User:Doc_James/common.js&diff=prev&oldid=904480749 Doc James (talk · contribs · email) 01:41, 29 July 2024 (UTC)[reply]

The amount of data on Commons (most recent file versions) surpassed 600 Terabytes (ca. 546 TiB) recently. --PantheraLeo1359531 😺 (talk) 08:11, 26 July 2024 (UTC)[reply]

Special:MediaStatistics for verification --PantheraLeo1359531 😺 (talk) 08:12, 26 July 2024 (UTC)[reply]

Are there any reliable offline backups of the data, by the way? I think I have read somewhere that Commons data is stored on two servers or something like that, but do we have a backup that could be used if some large-scale corruption of data happened? It wouldn't take much, really: For 600 TB, about 20 LTO Ultrium 8 tapes with a capacity of 30 TB each would suffice. And such tapes could be safely stored in different places. Gestumblindi (talk) 16:54, 27 July 2024 (UTC)[reply]

@Gestumblindi We're a distribution service, so recovery and restores can be crowdsourced for less than the cost of your tapes Elizium23 (talk) 03:21, 28 July 2024 (UTC)[reply]

lmao, sure. Good luck with that project. —TheDJ (talk • contribs) 08:11, 28 July 2024 (UTC)[reply]

I'd be extremely surprised if the WMF didn't have backups of all their websites. --Adamant1 (talk) 08:14, 28 July 2024 (UTC)[reply]

1. It’s more than 600tib, because this doesn’t count old and deleted versions. The same system also contains all the OTHER wikis files, so we can add that as well

2. Wikimedia Commons and wmf didn't have media backups between 2005 and 2022 (and up to 2012 there wasnt even a second server), but they finally exist.

3. As far as I know, there isn’t a public copy right now, because the deleted images would have to be filtered out. But im not 100% sure, i cant find details about it atm. —TheDJ (talk • contribs) 08:32, 28 July 2024 (UTC)[reply]

It's to bad there's no way to easily create backups of specific folders on here because it would be cool if there were backups of the more important ones on somewhere like archive.org or a similar website. --Adamant1 (talk) 08:44, 28 July 2024 (UTC)[reply]

You probably read about it here I think which has more info and proposes (an) additional backup(s): Commons:Requests for comment/Technical needs survey/Media dumps.

I think it would be great if people could come to WMF with some large hard drives and get a subsection copied on them such as all files that are in use in any Wikimedia project or all files except for >1 GB video files and a large .tiff files folder.

And I don't think the amount of data by file-size is a good measure of success, e.g. there are a lot of 4K videos of the same unnotable boring event that don't get watched at at all taking up lots of storage space or many duplicate large files and so on. Instead, there probably should be greater focus on the large gaps there are, such as various specific illustrations for concepts where illustrations would be very useful. I kind of doubt there were no backups until 2022 or would consider a second server a backup. More offline backups would be good and a good way for that would be to better enable third parties to copy over things, which is also useful for many other applications. Prototyperspective (talk) 10:34, 28 July 2024 (UTC)[reply]

Backups are very crucial, and I was surprised that there were not any until 2022, also because only backupping files should not be so expensive, as they only need to be stored on several disks. --PantheraLeo1359531 😺 (talk) 10:41, 28 July 2024 (UTC)[reply]

Maybe there is a chance to establish some sort of decentral service (like Mastodon), where every instance gets maybe 10-20 TB, so files are stored in many different areas of the world, so complete data loss in one point of the world becomes more unprobable --PantheraLeo1359531 😺 (talk) 10:43, 28 July 2024 (UTC)[reply]

Maybe there could or should be some central place – like Commons:Backup or Help:Backup and/or Commons:Media dumps or a Commons WikiProject – where things like those in this thread can be discussed over longer term, people can organize or collaborate and ask questions, and there is some WMC-specific info on backups similar to wikitech:Media storage/Backups. Maybe you and @MGeog2022: could set it up and aggregate+organize all the info on this subject in one place. Prototyperspective (talk) 11:32, 28 July 2024 (UTC)[reply]

I can understand why they wouldn't want to provide a full backup of everything on their servers to the public but there really should be publicly available backups of the files that we can already access because they clearly aren't copyrighted. If nothing else just for our own purposes. There's lots of situations where I could see something like that being useful outside of just having it available if the servers ever go down. Plus like why not? Everything is already there, organized, just needs to be mass downloaded, put in zip file, and reuploaded to archive.org. Does anyone if there's an easy way to download everything in specific folders? I'm tempted to do it myself but I have no clue how to. --Adamant1 (talk) 12:17, 28 July 2024 (UTC)[reply]

600 TB or 1 PB are peanuts to the Internet Archive, as they store over 200 PB of data :) --PantheraLeo1359531 😺 (talk) 13:09, 29 July 2024 (UTC)[reply]

One does not simply just download and then upload 600 TB over the internet. At these sizes you would probably transfer via physical hard disks being handed over to someone in person. Bawolff (talk) 08:35, 30 July 2024 (UTC)[reply]

Obviously. That's why I said there shoulfd be a way download specific folders. Most of the stuff on here probably comes from Flickr anyway. So there's no reason to back it up. --Adamant1 (talk) 09:12, 30 July 2024 (UTC)[reply]

@Prototyperspective, sorry I wasn't around here last days. Yes, it would be fine to have a page with such information in Commons itself, I can create it at some moment over the next days. I agree with @Adamant1in both things: there's no reason (besides the needed technical work) not to allow mass downloading of freely licensed media files, and not all media in Commons has the same level of quality an importance, but it can be very difficult to identify all the important ones. Dumps don't need to be only one 600 TB file (in fact, much smaller Wikipedia dumps are composed of lots of files).

@Gestumblindi, yes, there are now full Commons backups in 2 datacenters. Backups were never better than they are now, and the vast majority of files were never lost over many years, but things can and should be improved even more (more copies, more places, publicly downloadable dumps). MGeog2022 (talk) 14:21, 1 August 2024 (UTC)[reply]

I think the best way, if we're talking about a backup as a precaution against catastrophic data loss, is still a backup on media physically separated from any live system such as the large-capacity LTO Ultrium tapes I mentioned, which can be safely stored in different locations. Only if you have your data on tapes (or maybe large harddisks) in a vault, you can rest assured that the media / data will survive even some catastrophic large-scale event that affects whole swathes of the internet and possibly people's online / "cloud" backups as well. Gestumblindi (talk) 16:55, 29 July 2024 (UTC)[reply]

Just to clarify - the files were stored on several (geographically separated) disks prior to the 2022 point. Its not like they were on a single computer where a single disk failing would have caused the files to be lost. Generally for backup you want more than just mirroring across multiple disks - ideally you want it disconnected from the system and stored off site, so for example if the system was hacked the hacker couldn't just issue a command to delete all the files or some sort of natural disaster can't just take out the whole data center. I'm not exactly sure what the wmf backup strategy is, but my understanding is that is the part that only came into place in 2022. Bawolff (talk) 08:32, 30 July 2024 (UTC)[reply]

@PantheraLeo1359531, when I learned that there were no backups before 2021 or 2022, I was very surprised too. Fortunately, I became aware of it (and I started contributing to Commons) when there were already backups in place, so the scare was not so bad :-). But it's scary to think in what danger were all images and videos we saw in Wikipedia and other wikis. Before 2021-2022, there were (as there are now) multiple (more than just 2) copies of each media file in both main datacenters (each one stored in RAID disks), but that couldn't be called as true backups. MGeog2022 (talk) 17:01, 1 August 2024 (UTC)[reply]

Of course, a backup is absolutely needed! But now it's there :). I always have local backups of my files I contribute here, but many maybe don't, and when we take into account that some images may be out of reach to collect again, it could be a huge loss. But now we can be more relaxed :D --PantheraLeo1359531 😺 (talk) 17:06, 1 August 2024 (UTC)[reply]

+1, better safe than sorry :) --PantheraLeo1359531 😺 (talk) 19:00, 29 July 2024 (UTC)[reply]

I took this photo years ago, and then noticed a wikimedia user claimed it as their own. How can I remedy this issue? I've gone on both the photo's talk page and the users talk page and have gotten no response.

— Preceding unsigned comment added by Criticalthinker (talk • contribs) 10:15, 26 July 2024 (UTC)[reply]

@Criticalthinker: Hi, You uploaded your photo under the name File:10 Lansing Center.JPG to the English-language Wikipedia on 2 April 2006. The other user merely transferred it to Commons in 2011. You can correct and complete the information in the description page. An administrator on en.wikipedia should check what license you gave the file on Wikipedia. -- Asclepias (talk) 11:21, 26 July 2024 (UTC)[reply]

Licensing was {{PD-self}}, uploaded by User:Criticalthinker. I believe this is now fixed, but feel free to edit further if I didn't have it right. - Jmabel ! talk 18:33, 26 July 2024 (UTC)[reply]

Oh, wow. Thanks! Criticalthinker (talk) 07:09, 27 July 2024 (UTC)[reply]

@Criticalthinker: Just a side note, as you released the file into the public domain through "PD-self", you have relinquished your right to be named as the creator of the file. It's still a good idea to do so, so people see who has released the file and that everything is in order license-wise, but basically, anyone can now do with this file what they want without mentioning you. If you want to prevent this, you should use an attribution license like CC-BY or CC-BY-SA. That being said, it would probably still be inappropriate for any other person to claim that they're the author, but as others pointed out, that's not what happened here. Gestumblindi (talk) 16:49, 27 July 2024 (UTC)[reply]

Okay, so this wasn't "fixed." What do I do? I've been on Wiki for awhile, but I have no idea of the process you've spoken of. What do I need to do, specifically? Criticalthinker (talk) 00:12, 28 July 2024 (UTC)[reply]

You start uploading your photographs under the Creative Commons Attribution-Share Alike 4.0 license. Thats what you do now Trade (talk) 03:44, 28 July 2024 (UTC)[reply]

For this specific image and any images that you may have uploaded as "PD-self" in the past, you can't "fix" it - it means you have irreversibly released them into the public domain and people don't need to mention you as the creator. As said above, if you want to be credited, just use CC-BY or CC-BY-SA for future uploads. Gestumblindi (talk) 08:42, 28 July 2024 (UTC)[reply]

As was said, it was uploaded in 2006. I'd not even remembered that I'd uploaded it until I came across it, again, years and years later, let alone the licensing. I don't even remember what the old wiki would have looked like, then, and I don't imagine many of you do, either. The rudeness was completely unnecessary in the replies. But if that's how you're going to deal with it, thanks for absolutely nothing. Criticalthinker (talk) 06:36, 29 July 2024 (UTC)[reply]

I didn't mean to be rude, I thought I was just stating the facts for your information; if that came across as rude, I apologize. Gestumblindi (talk) 17:08, 29 July 2024 (UTC)[reply]

"it would probably still be inappropriate for any other person to claim that they're the author" Would it be against policy tho? Trade (talk) 03:45, 28 July 2024 (UTC)[reply]

• You can convert the image to a png and then reupload the image, and ask that the jpg be deleted. --RAN (talk) 15:49, 30 July 2024 (UTC)[reply]

That's not a helpful comment. What exactly would the uploader achieve with that? The file format wouldn't change the PD-self license. Also, I don't see the advantage from a technical point of view of converting a JPEG photo to PNG. Gestumblindi (talk) 18:43, 30 July 2024 (UTC)[reply]

Is this category exclusively for "proper" languages or are we also allowed to put dialects and accents here? — Preceding unsigned comment added by Trade (talk • contribs) 04:59, 27 July 2024 (UTC)[reply]

"A language is a dialect with an army and a navy."

Either a dialect can be handled as a subcat (see, for example, Category:Videos in Serbo-Croatian) or directly placed in Category:Videos by language (Category:Videos in Judaeo-Spanish and Category:Videos in Leonese are not currently subcats of Category:Videos in Spanish. The latter approach seems to be the more common. (Aside: I'm very surprised that the only Hochdeutsch dialect that gets a category separate from just Category:Videos in German is Category:Videos in Yiddish. Do we have nothing else in distinct German dialects? Similarly for Italian.)

Accents, if relevant, should certainly just be subcats. - Jmabel ! talk 17:29, 27 July 2024 (UTC)[reply]

Category:Videos by accent

Category:Videos by dialect

Is there any other categories in Category:Videos by language that belongs here you think?@Jmabel: --Trade (talk) 23:31, 27 July 2024 (UTC)[reply]

What you did makes just this side of no sense to me. Among other things, Serbo-Croatian is not a dialect, it is a language that (largely for political reasons) is usually specified as "Serbian" or "Croatian" (at least theoretically two dialects, that may indeed be moving farther apart). But why would Category:Videos in Serbo-Croatian be in Category:Videos by dialect? Serbo-Croatian is certainly not a dialect.

I suppose French-accented English is a possibly interesting accent, though I've never before heard it called "French English accent". Presumably the interesting accents/dialects of English would mostly be geographical and to some extent ethnic, etc., by native speakers whose English is distinct from one another, not by non-native speakers. And in many cases I would hesitate to classify those unless someone self-identifies. The boundaries from language to dialect and from dialect to idiolect are tricky, and I'm not sure they really belong in our categorization system except where very "broad strokes" are useful. - Jmabel ! talk 01:24, 28 July 2024 (UTC)[reply]

When you said "Either a dialect can be handled as a subcat (see, for example, Category:Videos in Serbo-Croatian)" i interpreted it as you calling Serbo-Croatian a dialect Trade (talk) 02:14, 28 July 2024 (UTC)[reply]

If you had any impression that Serbo-Croatian is a "dialect" that would suggest that you are working in an area where you have very little knowledge.

No, what I meant was to look at the linked page, Category:Videos in Serbo-Croatian, which has subcats for the Serbian and Croatian languages. - Jmabel ! talk 17:00, 28 July 2024 (UTC)[reply]

an older discussion: Commons:Village pump/Archive/2023/04#Cat names of accents and dialects. RZuo (talk) 10:59, 31 July 2024 (UTC)[reply]

I'm trying to download the images in this album from Flickr using Flickr2commons. All the images are of scanned postcards that are in the public domain. It seems that the user has uploaded them as "all rights reserved" though. Which it appears Flickr2Commons doesn't support. Is there any way around that or another tool I can use to import the images since they are clearly PD? Adamant1 (talk) 08:06, 28 July 2024 (UTC)[reply]

The uploader forbids the download of files, hmm. I think the only way is to download them by hand by showing all file sizes and choosing the highest available --PantheraLeo1359531 😺 (talk) 10:46, 28 July 2024 (UTC)[reply]

I know right. I hate it when people do that. I at least found a terminal program called Gallery-dl that can be used to download files from Flickr to the computer. Although it doesn't seem to retain file names which is just a hassle. But I'm in the process of downloading everything from their account lol. Hopefully someone will come up with a better solution though. --Adamant1 (talk) 12:09, 28 July 2024 (UTC)[reply]

Fingers crossed ;). Yes, it's really frustrating, especially on these questionable cases --PantheraLeo1359531 😺 (talk) 14:06, 28 July 2024 (UTC)[reply]

I have a long-standing request for Flickr2Commons to allow trusted users to upload such images. I also requested the same when Flickrpedia was in development, to no avail. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:23, 28 July 2024 (UTC)[reply]

• You set your default license at Flickr when you create the account, so even when you change from original photographs to scans of historical public domain images, you are probably not aware you are still getting the default license. Have you contacted them? It would be easier for them to change the license rather than you download and then reupload. You can change licenses with a single click. --RAN (talk) 15:47, 30 July 2024 (UTC)[reply]

In the map are missed Argentina, Azerbaijan, Cabo Verde, Cambodia, Chile, Comoros, Gabon, Greece, Guinea, Haiti, Ireland, Netherlands, Philippines, Sweden, Tajikistan, Timor Leste, Uzbekistan, Vanuatu and Venezuela. Is there any chances to fix? Many, many and many thanks in advance for all your answers!!! --Gatto bianco (talk) 10:47, 28 July 2024 (UTC)[reply]

There is some discussion about this at File_talk:Flag_map_of_the_world.svg. I suppose it should be unfeatured in the meantime. Enhancing999 (talk) 14:09, 28 July 2024 (UTC)[reply]

@Enhancing999@Gatto bianco the likes of the Philippines "disappeared" during the remaking of the map in 2010 (so more than a decade has passed). Ping @Transparent 6lue: who made the remaking. JWilz12345 (Talk|Contrib's.) 14:30, 28 July 2024 (UTC)[reply]

Oh .. then it's easy to fix: I reverted it to the version that was actually a featured picture on Wikimedia Commons. Different versions should be uploaded under other filenames. Enhancing999 (talk) 14:37, 28 July 2024 (UTC)[reply]

Good call. I have renamed the file to "File:Flag map of the world (2009 version).svg". It would be good if an admin could do a history split, and make the more recent version(s) into separate files, named according to date. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:31, 28 July 2024 (UTC)[reply]

@Enhancing999: Angola is still missed... Gatto bianco (talk) 17:55, 28 July 2024 (UTC)[reply]

File:Flag-map of the world.png seems to have it.

Maybe Commons:Graphic_Lab/Map_workshop finds you somebody who wants to make a 2024 version. Enhancing999 (talk) 12:41, 29 July 2024 (UTC)[reply]

Should Chromista, Hacrobia, Protozoa and other non-monophyletic groupings be replaced in the taxonavigation templates, or should they stay? Alfa-ketosav (talk) 11:48, 29 July 2024 (UTC)[reply]

With what do you want to replace them? Ruslik (talk) 20:06, 29 July 2024 (UTC)[reply]

Before when I uploaded 4K videos they would be encoded and offered as a playback option. Now it only encodes up to HD and there is no option to play 4K except to play source. Example ref: File:Koayu river - summer day - 2024 July 28.webm I'm just curious if I am missing an option or doing something wrong or if something was changed in the backend? Nesnad (talk) 11:59, 30 July 2024 (UTC)[reply]

Correct. They take an enormous amount of processing power and we were getting more and more uploads. This then (multiple times) caused the transcode servers to overload to the point where all servers were tied up transcoding humongous files almost no one was watching, and never getting around to the audio files and smaller variants of the videos that are actually used. For this reason higher resolution transcodes were put on hold. This is documented in phab:T368364 and phab:T368433.

The transcode pipelines are currently being rewritten so that they can run on Wikimedia's Kubernetes platform. Once that is done, it might be easier to tweak the capacity and priority of transcoding, but that is going to take a while. —TheDJ (talk • contribs) 13:56, 31 July 2024 (UTC)[reply]

It is sensible to suspend transcoding of high resolution versions, when ressources are limited. It is also sensible to annoucnce that on site. A significant number of users ignore Phabricator completely for example because it is monolingual and many people simply do not speak or read english. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 15:28, 1 August 2024 (UTC)[reply]

Not prioritizing audio files and lower resolution videos before 4K is an absolutely bonkers design decision i gotta say Trade (talk) 03:48, 2 August 2024 (UTC)[reply]

As a very general rule: 4K video is usually overkill unless you're using a very good camera and some form of stabilization (e.g. a tripod or Steadicam, or optical image stabilization in the camera). This video looks like it was taken with a handheld camera, and it is not a good use case for 4K video; most of it is heavily affected by motion blur, so the 4K resolution is largely wasted. Omphalographer (talk) 00:24, 1 August 2024 (UTC)[reply]

Got to agree. 4K is super pointless with something like this. A lot of people can't even stream video at 4K to begin with anyway. --Adamant1 (talk) 03:59, 1 August 2024 (UTC)[reply]

Are we talking about the Western world Trade (talk) 15:07, 1 August 2024 (UTC)[reply]

I usually shoot in 4K when doing documentations, but only with fullframe camera that can profit from the high resolution, but there are several cases where 4K brings not more details than Full HD --PantheraLeo1359531 😺 (talk) 11:51, 2 August 2024 (UTC)[reply]

I must point out that the issue was not stabilization of handheld, it was the framerate. At least from what I can see from my computer. To your point, 4K is indeed useless if, and only if, it doesn't go with an above-than-avarage fps and bit rate. This is based on my experiments on YouTube -- should probably do more of such experiments here to back my claim. Miguel Angel Omaña Rojas (talk) 05:49, 2 August 2024 (UTC)[reply]

Wikipedia asserts that only two movies have been released on 4K Blu-Ray at 48 FPS or higher, and only a few films were shot at that speed. Most feature films are 24 FPS. 4K does need high bit rates, but FPS is irrelevant.

YouTube is not a good tool for this; there's a complex proprietary system trying to send a stream that is playable on the receiving system and maximizes quality without taking up too much expensive bandwidth. It will not replicate what will happen on Commons.--Prosfilaes (talk) 17:32, 3 August 2024 (UTC)[reply]

Good to know. I remember when people said HD was a waste because most people couldn't play it. 4K is future proofing. But I understand it was taking a lot to transcode the video. Are there plans to go back and transcode 4K video once pipelines are rewritten? Any case, thank you for the explanation guys! :) Nesnad (talk) 05:16, 1 August 2024 (UTC)[reply]

Using a higher video resolution is only "future-proofing" when there is high-resolution detail to preserve in the source video. That isn't the case here; the source video is blurred, and saving those blurry frames at a high resolution doesn't make them any less blurry. Omphalographer (talk) 05:53, 1 August 2024 (UTC)[reply]

The source video is available without limitations. Only transcoded versions with same resolution but possibly lower bitrate are not available. GPSLeo (talk) 06:07, 1 August 2024 (UTC)[reply]

This is exactly what I was talking about. It is all about the FPS numbers going along with 4K. It’s not that I’m against 4K, but when it comes to a lot of people (obviously not you) they shoot 4K in small FPS. That is what 4K is making 4K useless today. I don’t know in the future, but that whole 4K + High FPS numbers makes the files bigger, and that’s a biggie as well. Miguel Angel Omaña Rojas (talk) 22:10, 2 August 2024 (UTC)[reply]

Does framerate really matter? It's a video not a PC game Trade (talk) 04:06, 3 August 2024 (UTC)[reply]

Framerate matters for video, 30 fps can look different from 60 fps and sometimes details are not properly shown at 30. Abzeronow (talk) 21:02, 3 August 2024 (UTC)[reply]

I can bring up concerns about 4K videos at the Commons Video Meetup at Wikimania. I plan on attending the meetup in person so I'll try to remember to mention the challenges of 4K and the desire for support where appropriate. Abzeronow (talk) 00:11, 2 August 2024 (UTC)[reply]

Could you propose a way to request exceptions to the 4K "ban" for individual videos? Those in cases where the improved resolution heavily benefits. Or at the very least find a way to allow for a limited number of 4K uploads of high quality Trade (talk) 05:01, 2 August 2024 (UTC)[reply]

But no cases, where the improved resolution heavily benefits, have been presented?!? Just kill it. Alexpl (talk) 17:22, 2 August 2024 (UTC)[reply]

I appear to be using the wrong LOC number in the template here: File:G. David Schine in 1954.jpg. Can someone help me find the correct # to put in the template? RAN (talk) 16:19, 30 July 2024 (UTC)[reply]

cph.3f05899 ? -- Asclepias (talk) 16:44, 30 July 2024 (UTC)[reply]

Besides, {{Library of Congress-no known copyright restrictions}} doesn’t seem quite right for the image. --Geohakkeri (talk) 08:18, 31 July 2024 (UTC)[reply]

I'm proposing an experiment to temporarily increase the number of Quality Image nominations allowed each day during August for active reviewers. Please see, and comment at, Commons talk:Quality images candidates. Thanks. Mike Peel (talk) 20:50, 30 July 2024 (UTC)[reply]

i just wrote Commons:Nudity category as a summary of a common practice. please feel free to edit it. RZuo (talk) 12:02, 31 July 2024 (UTC)[reply]

Hi all! CParle (WMF) and I will be attending Wikimania 2024 in Katowice, Poland. Despite not having any presentation in the program, we wanted to let you know that, if you're attending Wikimania too, you can come meet us at all time during the conference and discuss with us about UploadWizard improvements or about the logo detection tool or just Commons issues. We'll be around during the whole conference, so from August 7 to 10, don't be shy and come to say hi! Sannita (WMF) (talk) 14:38, 1 August 2024 (UTC)[reply]

Currently, there are 184 sysops.

Edited by RZuo (talk).

Commons Gazette is a monthly newsletter of the latest important news about Wikimedia Commons, edited by volunteers. You can also help with editing!

--RZuo (talk) 22:12, 1 August 2024 (UTC)[reply]

Think we could export this to Commons as a simple logo?--Trade (talk) 04:34, 3 August 2024 (UTC)[reply]

No. I think this just meetsCOM:TOO-US via American Airlines. Glrx (talk) 14:21, 3 August 2024 (UTC)[reply]

Definitely above the ToO in France. Abzeronow (talk) 21:04, 3 August 2024 (UTC)[reply]

Hi,

could someone please delete the files File:Reljefna karta Hrvatskog zagorja.png and File:Administrativna karta Hrvatskog zagorja.png? I uploaded these files as they were licensed under free CC licenses, but I later learned that Commons doesn't accept CC BY-NC licenses.

Sorry for the trouble! --Ashune (talk) 14:26, 3 August 2024 (UTC)[reply]

@Ashune: Will do, but for the future please see Template:My bad upload. - Jmabel ! talk 17:06, 3 August 2024 (UTC)[reply]

Thanks! I'll use that template in the future.

P.S. I'll make my own maps and upload them under the same names in the near future. (Just a heads up so someone seeing this doesn't also delete those. Ashune (talk) 20:34, 3 August 2024 (UTC)[reply]

This section is resolved and can be archived. If you disagree, replace this template with your comment. Jmabel ! talk 17:08, 3 August 2024 (UTC)

Following this discussion - Commons:Bots/Work requests#Convert Category:Photographs by Carol M. Highsmith to JPEG (bot request), I'm trying to assess what sort of consensus we have regarding the conversion of TIFFs to JPEGs in general. Also, see past discussion in the archive. -- DaxServer (talk) 16:36, 3 August 2024 (UTC)[reply]

Reasons to prefer JPEG over TIFF for our purposes:

• Easier to view, download & use for people with slower internet connection
• JPEG is generally much easier to use for average people without specialized programs/knowledge about file types
• Often significantly smaller file size while preserving the image quality (often over 1000% smaller (sometimes over 10000% (TIF|JPG))
• TIF has issues with displaying correctly as thumbnail
• raw .tif files cannot be displayed in browsers (URL ending .tif (TIF example, JPG example) - this means properly zooming is not possible without downloading a large file to your PC (or even better your phone)
• TIF is not indexed by Google and presumably other image search engines (as the format is unsuitable for web purposes, see above)

Proposed solution is to convert the TIF file to JPG and upload as such, copy all information, and make both files cross reference each other. This has been done already with ~250,000 NARA/LOC files (see e.g. here)

TheImaCow (talk) 17:05, 3 August 2024 (UTC)[reply]

All these problems are solved by the jpeg thumbnails they are available. GPSLeo (talk) 18:14, 3 August 2024 (UTC)[reply]

TIFF is the world's most featureful image format, so not all TIFFs are good candidates for conversion to JPEG. Multipage TIFFs might be converted to PDF, and non-photographic TIFFs would be better off as PNGs.--Prosfilaes (talk) 17:38, 3 August 2024 (UTC)[reply]

We don't need to align 100%. Anything that goes "we do this here, so we should do it everywhere" is flawed. We shouldn't waste resources on this. Targeted approaches might make sense sometimes, but most of this material isn't even in use, nor will it ever be. —TheDJ (talk • contribs) 17:40, 3 August 2024 (UTC)[reply]

•  Oppose. Let sleeping dogs lie. (BTW, I have some old LoC code that will read TIFF but not JPEG.) Glrx (talk) 18:26, 3 August 2024 (UTC)[reply]

•  Oppose convert master images (ie. the file what Wikimedia Commons uses as source when scaling jpg) from lossless format to lossy ones. It just means lower image quality. If user needs smaller files user can already download the jpeg versions of the files from Wikimedia Commons instead of original file. --Zache (talk) 19:23, 3 August 2024 (UTC)[reply]
• Comment Nothing prevents you from converting a tif into a jpg and uploading it alongside the original tif. Ruslik (talk) 19:41, 3 August 2024 (UTC)[reply]

  Time does.

  It is finite, and either it is spend

  - downloading the TIF

  - converting the TIF to something else

  - uploading the tif

  - copy & adjust file info

  - adjust file info of the tif

  -- repeat x1000

  or

  -doing anyting else that cannot be easily automated. TheImaCow (talk) 20:59, 3 August 2024 (UTC)[reply]

  It's already available for each tif, so no need to duplicate it. Enhancing999 (talk) 05:06, 4 August 2024 (UTC)[reply]

•  Support Yes, for most Wikimedia projects, JPEG is better. Yann (talk) 19:44, 3 August 2024 (UTC)[reply]
• Comment: I have been thru this issue here in the case of an archived TIFF and subsequent JPEG with suitable cross‑linking. So please consider this use case given an original high‑quality TIFF scan and a downstream usable JPEG image. And please add some nuance to the algorithm that goes thru converting everything "in general" and explicitly identify and exclude this corner case. TIA RobbieIanMorrison (talk) 22:06, 3 August 2024 (UTC)[reply]
• Of course, converting of all images from lossless to lossy format is unacceptable. This can be discussed only for some particular cases. In the general case TIFFs can be converted to PNGs, they will become smaller (but not as small as JPGs). Sneeuwschaap (talk) 23:27, 3 August 2024 (UTC)[reply]
•  Oppose I can see the benefit of this, but then it would also create needless duplicates that just screw with search results and take extra curation. I'd probably support it if there was a way to hide or suppress TIFF images though, but it's hard enough dealing with multiple images formats as it is. Some TIFF files probably aren't worth converting to JPEG in the first place either. One thing I'd like to see fixed is how TIFF images display in thumb nails though. I think that would solve a large part of the problem with them. --Adamant1 (talk) 01:32, 4 August 2024 (UTC)[reply]
•  Comment How many edits were already done on the 250,000 existing duplicates? How much time was wasted in duplicated curation somebody uploaded two formats of the same photo? Enhancing999 (talk) 05:12, 4 August 2024 (UTC)[reply]

 Oppose I think tiff files are higher-quality aren't they? So if they are converted then to something that is lossless and I don't know if there is such a filetype. More useful would be converting gifs that are not animated to another filetype. Prototyperspective (talk) 10:18, 4 August 2024 (UTC)[reply]

I see that the Village Pump is now semi-protected, which strikes me as quite inappropriate. Yes, vandalism is a pain, but this is the Village Pump, where users, including new users and IPs, should be able to come to start or participate in a discussion.--Prosfilaes (talk) 17:40, 3 August 2024 (UTC)[reply]

For instance File:Spring has arrived^^^^^ 🌼🌼🌼🌼🌼🌼 - Flickr - rossomoto.jpg. I was thinking about renaming to something without them but I don't want to waste my time on it if they aren't an issue. It seems like a super weird way to name files though. So Yes, no, or does it depend on the circumstances when it comes to file names with emoji? --Adamant1 (talk) 02:04, 4 August 2024 (UTC)[reply]

If you know specifically what the plant in the photo is, a rename to a more specific name would be in order (under criterion 2 - "meaningless or ambiguous name"). But renaming just to remove the emoji is harder to justify, especially when the filename is still meaningless without them. Omphalographer (talk) 04:02, 4 August 2024 (UTC)[reply]

@Omphalographer: Hhmmm. The Emoji seem to show up as different flowers depending on the platform. So I'm not even sure how I'd figure that out to begin with. Maybe they could just be replaced with "flowers" though since it doesn't seem to be a specific plant. --Adamant1 (talk) 04:22, 4 August 2024 (UTC)[reply]

I mean the budding flowers seen in the photo, not the ones represented by emoji in the filename. As you've astutely observed, the exact appearance of emoji is font-dependent. Omphalographer (talk) 05:13, 4 August 2024 (UTC)[reply]

The emoji is the same on every platform, but the rendering can change depending on which device/browser/etc. you view it with. ReneeWrites (talk) 07:09, 4 August 2024 (UTC)[reply]