Commons:Village pump

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

Shortcut: COM:VP

↓ Skip to table of contents ↓       ↓ Skip to discussions ↓       ↓ Skip to the last discussion ↓
🌐 Village pumps for other languages
COMMONS DISCUSSION PAGES (index)
Welcome to the Village pump

This page is used for discussions of the operations, technical issues, and policies of Wikimedia Commons. Recent sections with no replies for 7 days and sections tagged with {{Section resolved|1=--~~~~}} may be archived; for old discussions, see the archives; the latest archive is Commons:Village pump/Archive/2024/07.

Please note:

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

Purposes which do not meet the scope of this page:

Search archives:

   

Start a new discussion

# 💭 Title 💬 👥 🙋 Last editor 🕒 (UTC)
1 Pre-implementation discussion on cross-wiki upload restriction 11 5 Whym 2024-07-29 12:46
2 What are outgoing and incoming wikilinks? 9 3 Enhancing999 2024-07-26 05:56
3 Adding an artist to an image within Wikidata 12 3 Broichmore 2024-07-31 11:21
4 A Gartenlaube mystery 3 3 Enhancing999 2024-07-27 13:20
5 Category:Videos by subject 4 3 Trade 2024-07-27 04:36
6 Managing overpopulated categories 14 5 Sinigh 2024-07-27 23:38
7 My historic .svg Inkscape images now showing as blank 11 5 Glrx 2024-07-25 21:27
8 Need help with correct naming 4 2 Palu 2024-07-25 07:23
9 Image Annotation 11 4 Doc James 2024-07-29 01:41
10 URAA-restored copyrights of old European postcards 1 1 Smiley.toerist 2024-07-25 11:39
11 New Light rail station in Hannover 2 1 Smiley.toerist 2024-07-25 10:46
12 TIFF to JPG potential loss of quality 15 7 RobbieIanMorrison 2024-07-27 07:03
13 Complete map of the moon (luna) 1 1 PantheraLeo1359531 2024-07-25 18:19
14 >600 TB of recent media files 19 7 Adamant1 2024-07-30 09:12
15 Self-talken photo 12 6 Gestumblindi 2024-07-30 18:43
16 Rename error 3 1 Inertia6084 2024-07-26 20:53
17 Vote now to fill vacancies of the first U4C 1 1 RamzyM (WMF) 2024-07-27 02:46
18 Category:Videos by language 6 3 RZuo 2024-07-31 10:59
19 Question about Flickr2Commons 6 4 Richard Arthur Norton (1958- ) 2024-07-30 15:47
20 Some country missed on File:Flag map of the world.svg 7 4 Enhancing999 2024-07-29 12:41
21 Chromista, Hacrobia and other non-monophyletic groupings 2 2 Ruslik0 2024-07-29 20:06
22 Are 4K videos discouraged now? 4 4 Adamant1 2024-08-01 03:59
23 Library of Congress # 3 3 Geohakkeri 2024-07-31 08:18
24 Quality Images nomination experiment in August 1 1 Mike Peel 2024-07-30 20:50
25 Nudity category 1 1 RZuo 2024-07-31 12:02
Legend
  • In the last hour
  • In the last day
  • In the last week
  • In the last month
  • More than one month
Manual settings
When exceptions occur,
please check the setting first.
People of Ngadisan (Java, Indonesia) are filling their cans at the village pump. The old well is defunct and replaced by a water tap. [add]
Centralized discussion
See also: Village pump/Proposals   ■ Archive
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.

July 19

Pre-implementation discussion on cross-wiki upload restriction

Tracked in Phabricator
Task T370598

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]

July 21

What are outgoing and incoming wikilinks?

What needs to be done to get pages out of "Pages where lack of wikilinks indicates a problem"? (Source: Commons:Editor's index to Commons)

  1. What are outgoing and incoming wikilinks exactly?
  2. Do these gallery pages just need categories (which a lot of them got a long time ago, but they still continue to appear on this list), do they need a Wikidata Infobox, or something else?

JopkeB (talk) 10:05, 21 July 2024 (UTC)[reply]

I think on Commons these are not a problem. We don't particularly interlink our galleries. Of course, on other wikis where the analogous space is "article space", the same thing would represent a problem. - Jmabel ! talk 19:17, 21 July 2024 (UTC)[reply]
@Jmabel: Thank for your reaction. Next question: are these two Special pages still needed on Commons? JopkeB (talk) 04:55, 23 July 2024 (UTC)[reply]
I see no purpose for them. - Jmabel ! talk 19:13, 23 July 2024 (UTC)[reply]
@Jmabel: So they might be deleted. What is the deletion procedure for such pages? Where can I drop a request for deletion? JopkeB (talk) 10:42, 25 July 2024 (UTC)[reply]
Not sure it's worth the effort, but you could probably file something in phabricator, or you could ask at COM:Village pump/Technical. That is, presuming no one would object; it might be worth running this by COM:Village pump/Proposals first to see if someone disagrees. - Jmabel ! talk 17:42, 25 July 2024 (UTC)[reply]
Sounds good. If you find some other that are not really useful here, please have them deactivated too.
You could also add some info to: MediaWiki:Deadendpages-summary, MediaWiki:Deadendpagestext displayed on Special:DeadendPages, etc. Enhancing999 (talk) 18:30, 25 July 2024 (UTC)[reply]
MediaWiki:Deadendpages-summary and MediaWiki:Deadendpagestext exist no longer.
I'll follow Jmabel's advice and make a request on COM:Village pump/Technical, see Commons:Village pump/Proposals#Request: delete "Pages where lack of wikilinks indicates a problem". I do not know any other pages that are not useful, but if you know one, please add it to my request on Village pump/Proposals. JopkeB (talk) 05:52, 26 July 2024 (UTC)[reply]
They exist, just currently not locally. The second has the text "The following pages do not link to other pages in Wikimedia Commons." if you look at it. Enhancing999 (talk) 05:56, 26 July 2024 (UTC)[reply]

July 22

Die Gartenlaube: Adding an artist to an image within Wikidata

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]

A Gartenlaube mystery

I've noticed a phrase within a cropped file, as follows: This file has been extracted from another file: Die Gartenlaube (1856) 561'.jpg. The source image was deleted for reasons that do not affect this image, like a derivative work which is not a part of this cropped image.

What does, this gobbledygook mean?

The file, must have been extracted from a collected volume (or issue) of the magazine, surely? What's deleted is not derivative, it's the source. The very opposite of derivative? That source, might have in it an article, about what, that the image depicts? Here's an example. What am I, missing, here?_ Broichmore (talk) 12:40, 27 July 2024 (UTC)[reply]

See my edit. The template tried to find a file for page 561' (with an apostrophe). --Geohakkeri (talk) 13:16, 27 July 2024 (UTC)[reply]
(ec) Yes, this fixed it. You borked the pagenumber and this made Template:Extracted from deleted/en appear. Enhancing999 (talk) 13:20, 27 July 2024 (UTC)[reply]

July 23

Category:Videos by subject

Is there any guidelines or consensus as to how granular the subjects of this category should be? Trade (talk) 04:18, 23 July 2024 (UTC)[reply]

I think the general categorization guidelines apply here. The subjects can be as granual as they can get, provided you don't end up with a whole bunch of categories with only 1 media file (Commons doesn't have an official guideline for this I believe, but generally speaking the minumum number of media files should be 3). If a lot of categories share a common trait they can be put in a container category. ReneeWrites (talk) 09:40, 23 July 2024 (UTC)[reply]
Less granular than most categories we already have :) —TheDJ (talk • contribs) 13:50, 24 July 2024 (UTC)[reply]

Is it okay to include two different subjects into the category scope? --Trade (talk) 04:36, 27 July 2024 (UTC)[reply]

Managing overpopulated categories

Hello! There are many categories containing hundreds or thousands of files but no subcategories. In some cases, I've found that templates like {{ImageTOC}} make these categories a lot more navigable for future subcategorization, but only if most files are named in a way that allows for it.

What other ways are there to make manually sorting files a bit more manageable? Is it, for example, somehow possible to order images in a given category by the date= parameter in {{Information}} so that they can be more easily sorted into by-year categories? Sinigh (talk) 21:10, 23 July 2024 (UTC)[reply]

@Sinigh: Can you give any examples of these categories? That would make it easier to discuss what to do. In most cases, subdividing by date is not the most useful; it's better to subdivide by subject. Pi.1415926535 (talk) 23:20, 23 July 2024 (UTC)[reply]
@Pi.1415926535: Yes, "by subject" is of course the most useful one. Here are a few different examples:
Since images have dates and are in other categories that define their subjects, I'm essentially wondering if this could somehow be used to make sorting easier. Bit of a vague question and a long shot. Sinigh (talk) 02:15, 24 July 2024 (UTC)[reply]
If topical categories can be broken down by subject, this should be done. Another possibility is by view. I think it's generally a non-issue.
The "Mountain Warfare Training Center"-category may be an illustration of what shouldn't be done: make subcategories by date rather than topical categories:w:Mountain_Warfare_Training_Center#Installation_capabilities can provide suggestions for topics. "Winter" could be another option.
Personally, I think it's terrible habit to make subcategories by subject in photographer categories. Enhancing999 (talk) 10:13, 25 July 2024 (UTC)[reply]
What I'm asking for here isn't advice on appropriate subcategories. As for the actual topic of this discussion, I suppose going through images manually and using Cat-a-lot will have to do. Sinigh (talk) 11:48, 25 July 2024 (UTC)[reply]
I don't think it's a good idea to break down a user's category merely because you think it's "overpopulated" and you found a tool to do so. Enhancing999 (talk) 11:52, 25 July 2024 (UTC)[reply]
And I agree. What do you mean by "a user's category"? Sinigh (talk) 14:36, 25 July 2024 (UTC)[reply]
The one above where you mentioned: "it's probably a good idea to begin with "by year/month" because of the large number of files". No. Enhancing999 (talk) 14:38, 25 July 2024 (UTC)[reply]
Of course, I misunderstood. Ellgaard was indeed a Wikimedia user late in life, but he was also a photographer for over half a century. That category was created by someone else almost a year after he passed away. I assume that most of his contributions are relatively recent creations intended for Commons, but his uploads are from the 1950s and onward, so I thought (perhaps mistakenly) that chronological categories would be useful there. Sinigh (talk) 14:58, 25 July 2024 (UTC)[reply]
Regarding Category:Photographs by Holger Ellgaard, best to leave that well alone. If we want to find items from that collection of a practical use, we would not be looking in that particular cat; we would be looking in whatever cat applied to the content of the file, the fact that the photo was taken by Holger Ellgaard is purely incidental and of no real value. The content however assuredly is.
On the other hand, unlikely, if your interest was Holger Ellgaard, you would be using a search query based on ‘’ Holger Ellgaard’’ against content. Sub catting against photograph, with these volume levels is useless. I can understand if he were an artist in the true sense, painting in oil. Where there is a limited portfolio. Photographers of this type are different, far too prolific. Again, catting against him, even in time is useless. Don’t cat, wherever ‘’search’’ would be the more efficient. _ Broichmore (talk) 19:59, 27 July 2024 (UTC)[reply]
All right. :) His Swedish Wikipedia page does say that he had a long career as a photographer and that he documented urban environments that have since changed due to redevelopment, so I just thought it might make sense to try and sort files chronologically in that particular case. Not necessarily to create subcategories, but at least to find out whether any historically notable photos of his even exist on Commons, other than the five examples given in the Wp article. It just felt intuitive at the time. I only had that fleeting idea with regard to that one category, not that whole type of category. This is just to make it abundantly clear that I've never intended to add unnecessary subcategories anywhere. :)
I've had a look at many "Photographs by" categories and created a number of them myself, and I've only ever found two cases where I would even consider adding subcategories: one already had the one subcategory I thought it needed, and the other one is the one we're talking about here. But of course, I don't intend to add anything to it – we're all on the same page. :) Sinigh (talk) 23:38, 27 July 2024 (UTC)[reply]
Such a feature would indeed by very useful. Does somebody have a phab issue about that, probably it has been proposed already earlier.
One can only sort by upload date by using incategory:"Cat name" (or deepcategory if it has few subcats) and then sorting the results accordingly, but one can't do so for the data in the Date field.
However, your examples really aren't good and only highlight why it may be important to clear a few things up before such is enabled – I agree with Enhancing999 that files in 'photographs by {name}' cats for example shouldn't be subcategorized by date or subject.
There's many cases where the year or decade would be very useful to have as subcat. Moreover, in many cases such subcats already exist but miss many files which could more easily be fixed if this feature was there. A main issue is that having so many subcats make things often more cumbersome than being helpful to 1) the user seeking images (e.g. any high-quality ones) and 2) contributors seeking to populate/complete a cat where relevant files are buried in deep subcategories rather than being at the top-level; and I have proposed a remedy for that via a proper deepcategory wall-of-images view for cats. Likewise, being able to sort by date in a given cat would also be helpful for users seeking images...especially when for example looking for a recent statistic and a good example is Category:Commons statistics which has many files but most of them being quite old. Prototyperspective (talk) 12:29, 25 July 2024 (UTC)[reply]
Oh, I'm not particularly invested in the subcategories I suggested above! I just gave a few different examples of categories because I was asked to, and added a few potential subcategories to quickly show what I was hoping could be done. I did not wish to say or imply that the categories must be structured that way. I'm just here asking for that sorting feature, or method, or any other ideas anyone may have.
But I can definitely see how it seemed that I was arguing for a particular kind of categorization. I hope you can now rest assured that I'm not. (One of the categories has since been divided into subcategories, but not by me.)
I think it's unfortunate that categories like the Ellgaard one aren't very navigable, though. If it shouldn't be subcategorized by date or subject, what then should be done? Should it be left the way it is, with tens of thousands of images all in one place?
As for images being buried in deep subcategories, that is most certainly a problem and a valid complaint, but I always assumed we could have it both ways. Shouldn't it already be possible to automatically sort all images under e.g. "Photographs by John Doe" into a category like "All photographs by John Doe"? Isn't that essentially what happens in flat-list metacategories, like Category:Categories by setting (flat list)? I'm sure there are several other possible or existing solutions that I'm unaware of; this is just one example.
Sinigh (talk) 14:34, 25 July 2024 (UTC)[reply]
Sure, I see, this was basically just meant as a note regarding these examples, I didn't took them as being very intentionally chosen or anything of that sort.
In regards to your question of what should be done my proposal in the tech survey mentioned that it could be sortable by number of file uses on Wikipedia or similar things so that most relevant or highest quality files show at the top. Shouldn't it already be possible to automatically sort all […] into a category like "All photographs by John Doe"? good question and I wondered about things like that but currently it's not done and is asked to not be done by COM:OVERCAT. If the category tree is not too deep or the deepcategory search operator is improved one can already see all files in a category branch in one place so this is redundant so I don't think deviation from (a change to) that Commons policy would be a good approach.
On a related note, one thing that seems more considerable is whether files should be removed from a higher level of a category once it's in any subcategory of it or only once its main aspects related to the broader category are captured by subcategories. For example: if a category has subcategories by country/location and by year, should the file already be removed from the broad category once it's in a by-year category (but missing in the by country one)? I think not, but that's probably a topic for another day of which there are too many (topics/tasks not days per contributor). Prototyperspective (talk) 15:13, 25 July 2024 (UTC)[reply]

July 24

My historic .svg Inkscape images now showing as blank

Hello, I have been uploading .svg Inkscape coats of arms images for many years. Suddenly now many of them are showing up on Commons as blank shields. For example File:FinchArms.svg. To test it and examine it I saved the blank image from Commons back to my computer, and when I opened it on my Inkscape package, it showed up properly. So the image is still in there somewhere! Can anyone suggest what might have happened, and how to fix the problem? Probably many hundred of my images over many years have been affected, from a brief review of my upload history.Lobsterthermidor (talk) 14:52, 24 July 2024 (UTC)[reply]

@Lobsterthermidor: Over time, the software to "render" SVGs (turn SVGs into PNGs shown to users) changes. I'm not a particular expert on SVGs, but I recall that Inkscape's SVGs often have issues in practice over time. If you export as "Plain SVG" I think they will work correctly. Jdforrester (WMF) (talk) 17:02, 24 July 2024 (UTC)[reply]
Maybe add a gif version if svg keeps breaking? Enhancing999 (talk) 18:23, 24 July 2024 (UTC)[reply]
Gifs in 2024? Sjoerd de Bruin (talk) 18:29, 24 July 2024 (UTC)[reply]
Replacing vector files with bitmap files is going backward. Just fix the SVG files. Glrx (talk) 19:46, 24 July 2024 (UTC)[reply]
It's an Inkscape bug that is now apparent because WMF uses a stricter SVG rendering engine. The files also do not display on Chome.
Inkscape emits illegal clipPath elements. For example, FinchArms.svg has 
    <clipPath clipPathUnits="userSpaceOnUse" id="clipPath2877">
      <g id="g2881" inkscape:label="Layer 1" transform="matrix(0.28222223,0,0,0.28222223,-7.7612925,19.376908)" style="fill:none">
        <path sodipodi:nodetypes="ccscssc" inkscape:connector-curvature="0" id="path2879"
           d="M 79.678451,149.81749 H 646.03583 v 258.58398 c 0,285.48607 -283.17773,397.82031 -283.17773,397.82031 0,0 -196.71555,-78.03561 -262.23435,-269.31836 C 87.532751,498.68407 79.678451,455.94392 79.678451,408.40147 Z"
           style="opacity:1;fill:none;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:3;stroke-linecap:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
      </g>
    </clipPath>
A clipPath element may not contain a g element. It is only allowed to contain simple shapes such as circles, rectangles, and paths (and a little more).
Glrx (talk) 19:46, 24 July 2024 (UTC)[reply]
Thanks for that explanation. Unfortunately I'm not a computer programmer, merely an amateur heraldic artist who has devoted hundreds of hours to creating images for Commons, which always used to show up without any problems. It would be impossible for me to go back over my work of a decade altering the computer code. It seems that the error is on the part of the WMF switching to a "stricter SVG rendering engine". Shouldn't they have considered what effect that might have on existing images? Surely Commons would want to retain all work that has been submitted to it? We trust Commons to value and to securely store and protect our work, not to trash it because they want to move to the inevitable next technological standard? What can be done to bring this problem to the notice of the powers that made this change? Many thanks,Lobsterthermidor (talk) 11:58, 25 July 2024 (UTC)[reply]
@Lobsterthermidor: It is not WMF's fault but rather Inkscape's fault. The files were never legal SVG 1.1. https://www.w3.org/TR/SVG11/masking.html states

A ‘clipPath’ element can contain ‘path’ elements, ‘text’ elements, basic shapes (such as ‘circle’) or a ‘use’ element. If a ‘use’ element is a child of a ‘clipPath’ element, it must directly reference ‘path’, ‘text’ or basic shape elements. Indirect references are an error (see Error processing).

Any file with this bug will not validate.
It is not upto WMF or Gnome (the author of the render that WMF uses) to accommodate Inkscape's errors.
Inkscape should be told of the error, and Inkscape should figure out how to fix its tools and the faulty files it produced.
I will fix the FinchArms SVG.
Glrx (talk) 16:51, 25 July 2024 (UTC)[reply]
User:Glrx, that is very much appreciated. I have been uploading files like File:FinchArms.svg for many years with no problems at all. What can I do about the several hundred other images I have uploaded which are now blank? Surely this is the result of some recent change made at WMF, which now handles such files differently? Can I try to persuade the person responsible for making this change to keep the old "SVG rendering engine" as an option? Are they aware that the change they have made will be affecting files in this way? Surely I cannot be the only person affected? Thanks again for your invaluable help.Lobsterthermidor (talk) 17:05, 25 July 2024 (UTC)[reply]
@Lobsterthermidor: I understand your frustration, but think about what you are asking. The broken SVG files also do not display on Chrome; are you going to ask Chrome to modify its browser to also display your files? Commons wants files to not only display as expected on Commons, but also in browsers all over the world. Things should be fixed where they are broken, and the broken parts here are the SVG files.
I believe there are thousands of SVG files on Commons that will no longer render correctly. That hurts. But those files also do not display correctly on Chrome. The files need to be fixed. The renderer is not broken. Files that violate the SVG specification may not display as we expect.
WMF going back to an old renderer is not a solution for other reasons. The renderer has many other bugs that the newer version fixes. The current version does a much better job at supporting CSS. Furthermore, the current WMF renderer is still out-of-date by several years. We want WMF to update to even more recent renderers rather than going back to one that is essentially 6 years old.
Yes, it is frustrating. But it is not WMF's fault: it is Inkscape's fault.
Glrx (talk) 18:13, 25 July 2024 (UTC)[reply]

Lobsterthermidor uploads Glrx (talk) 21:27, 25 July 2024 (UTC)[reply]

July 25

Need help with correct naming

Hello, I was searching for Czech term "výstaviště" and its category here - výstaviště is place for exhibitions (and sometimes can be also for lunaparks, food festivals, etc.). First my opinion was that in english it is Category:Fairgrounds but according to dictionaries this is only for lunaparks. So I found english term Exhibition grounds and made category. But then I was searching and searching and according this it looks that Fairgrounds is for exhibitions and also lunaparks, not only lunaparks. So I can use this already existing tree of categories. Am I right or...? (if you can, you can shift categories to correct naming immediatelly if its wrong). Thank you very much for your help and sorry for my bad dictionaries :D Palu (talk) 00:57, 25 July 2024 (UTC)[reply]

@Palu: May I assume that by "lunapark" you mean "amusement park"? "Amusement park" is not really interchangeable with "fairgrounds". Disneyland is an amusement park, but not a fairground. Fair Park in Dallas is a fairgrounds, but only once a year, as far as I know, does it host anything like an amusement park. - Jmabel ! talk 04:20, 25 July 2024 (UTC)[reply]
Yes, correct. So what term is best for "místa kde se dějí primárně výstavy"? Thank you for your help and patience :) --Palu (talk) 06:43, 25 July 2024 (UTC)[reply]
So in the end I used artificial intelligence and it told me that both terms are interchangeable, however "exhibition grounds" is more exclusively for exhibitions, while "fairgrounds" is more benevolent (also for entertainment), therefore more universal. So I will unify it on the "fairgrounds". If somebody will evaluate better solution, feel free to correct it. Thank you for your help provided. --Palu (talk) 07:23, 25 July 2024 (UTC)[reply]

Image Annotation

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]

URAA-restored copyrights of old European postcards

Moved to Commons:Village pump/Copyright#URAA-restored copyrights of old European postcards Smiley.toerist (talk) 11:39, 25 July 2024 (UTC)[reply]

New Light rail station in Hannover

This is a new Light rail station in Hannover, that is not yet present on the OpenRailwayMap. It is on the Empelder Strabe just before the turn to Badenstedter Strabe. As the closest side street is Riechersstrabe, I suspect the station wil be called Riechersstrabe, but I am not certain. Smiley.toerist (talk) 10:39, 25 July 2024 (UTC)[reply]

Solved: https://en.mapy.cz › ?source=pubt&id=24659906.Smiley.toerist (talk) 10:46, 25 July 2024 (UTC)[reply]

TIFF to JPG potential loss of quality

I just collected some high quality scans of some Ilford HP5 135 monochrome negatives, shot at 400 ASA, and developed by a professional lab some thirty years back. They are now in TIFF format. So I duly ran a test file through convert from ImageMagick 6.9.11-60 on Ubuntu Linux. The file size shrunk from 74 MiB to 11 MiB — hence just 15% of the original. Should I be worried? Are their options I should apply when using this ImageMagick utility to keep the quality up? TIA. RobbieIanMorrison (talk) 12:39, 25 July 2024 (UTC)[reply]

Regardless of whether a solution to the problem mentioned can be found, you can also upload the TIFF scans directly (ideally uncompressed). --Túrelio (talk) 13:29, 25 July 2024 (UTC)[reply]
I would prefer to do that and "archive" the original scans on Wikimedia (these images are historically significant, shot in Prague during the Velvet Revolution of 1989). Thanks for your answer Túrelio. RobbieIanMorrison (talk) 13:54, 25 July 2024 (UTC)[reply]
Just noting that file --brief reports (edited output): TIFF image data, height=4134, compression=none width=6218. So uncompressed. And the converted JPG is also 6218x4134 and doubtless very compressed. RobbieIanMorrison (talk) 15:24, 25 July 2024 (UTC)[reply]
Further question: If I upload the file scan.tif, then I assume that any modifications that I upload must also be in TIFF format. In addition: GIMP prompts to convert from Adobe RGB (1998) to GIMP built-in sRGB and I guess I should reject this suggestion (these images are monochrome so I am really asking for future reference). TIA RobbieIanMorrison (talk) 16:09, 25 July 2024 (UTC)[reply]
Yes, sRGB is better from web browsing. And yes, I would upload the original TIFF and a 98%-compressed JPEG. Yann (talk) 10:18, 26 July 2024 (UTC)[reply]
@Yann: Please correct me if I am mistaken. But to upload a TIFF file and a JPEG file would be two different file uploads to two different locations. I cannot start with a TIFF and shift to a converted JPEG as a modification at the one location. Surely not? And is there then a template I can use to link these two locations? TIA, RobbieIanMorrison (talk) 23:57, 26 July 2024 (UTC)[reply]
@RobbieIanMorrison: correct. See (for example) File:"1775...167th Anniversary...1942" - NARA - 513783.tiff and File:"1775...167th Anniversary...1942" - NARA - 513783.jpg. Note in particular how they link to one another. - Jmabel ! talk 01:01, 27 July 2024 (UTC)[reply]
@Jmabel: Exactly what I wanted to know. Many thanks as always! Best, RobbieIanMorrison (talk) 06:51, 27 July 2024 (UTC)[reply]
@RobbieIanMorrison you probably want to use compression (the more compatible LWZ or the better compressing ZIP format). magick mogrify -compress LZW -path /target/directory/ /input/path/*tif (or -compress Zip) vips tiffsave input.tif output.tif --compression deflate. —TheDJ (talk • contribs) 22:48, 26 July 2024 (UTC)[reply]
Converting the images to JPEG at a near-lossless quality (i.e. convert -quality 100 image.tiff image.jpeg) is probably fine. There should be no visually distinguishable difference from the TIFF format scans, especially at that high a resolution, and JPEG images are a bit easier to work with on Commons. Omphalographer (talk) 22:07, 25 July 2024 (UTC)[reply]
@Omphalographer: That quality option bumps the converted file size to 22 MiB. Perhaps this is the best workflow in this context? Along with rejecting the suggestion from GIMP to switch to its native color‑space for any subsequent edits. Thanks, RobbieIanMorrison (talk) 06:22, 26 July 2024 (UTC)[reply]
TIFF allows for more than 16.7 Million colors (the limit of jpeg). Within the 16.7Millions of colors are only 256 scales of gray from black to white. If the TIFF file actually uses an encoding of more than 16.7M, you would loose that with your monochrome images when converting to jpeg.
The size of a jpeg file does not really tell about the loss by lossy compression. JPEG files use a Huffman table and in most files this is a precomputed standard table. If you generate an indivdual Huffman table optimized for the specific file, the file size is only between 6% and 60% of the input file without quality loss. Tools like jpegrecode use this "trick" and the whole webp file format is based on this trick. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 04:36, 27 July 2024 (UTC)[reply]
@C.Suthorn: Thanks. I am going to upload the original TIFFs and converted JPEGs as separate exercises as Jmabel suggests. The scans were made by a high‑end lab in Berlin and quite expensive. So I'd like to keep that primary detail, even if unnecessary in many downstream applications, like viewing on a mobile device. Best, RobbieIanMorrison (talk) 07:02, 27 July 2024 (UTC)[reply]
Resolved
My thanks to all who responded. RobbieIanMorrison (talk) 07:03, 27 July 2024 (UTC)[reply]

Complete map of the moon (luna)

Does the NASA actually offer a complete map or a dataset that covers the moon's whole surface (or at least a big part of it) in form of a webpage or online service? Might be interesting to depict mariae, craters etc. :) --PantheraLeo1359531 😺 (talk) 18:19, 25 July 2024 (UTC)[reply]

July 26

>600 TB of recent media files

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]
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]
+1, better safe than sorry :) --PantheraLeo1359531 😺 (talk) 19:00, 29 July 2024 (UTC)[reply]

Self-talken photo

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.

Lansing Center

— 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]
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]

Rename error

Hi, I had a rename error and a screen message from the Wikimedia Foundation that something was wrong. Now "[1]" this file is gone. It's not in the redirect either. Normally it's a redirect-fix, but I don't know what to do now. Maybe someone has a solution? - Grtz. - Inertia6084 (talk) (talk) 20:49, 26 July 2024 (UTC)[reply]

I found it! File:Helsinki before the Olympics 1952 (JOKAHBL3D C08-19).tif - Inertia6084 (talk) (talk) 20:53, 26 July 2024 (UTC) ✓ Done - Inertia6084 (talk) (talk) 20:53, 26 July 2024 (UTC)[reply]

July 27

Vote now to fill vacancies of the first U4C

You can find this message translated into additional languages on Meta-wiki. Please help translate to your language

Dear all,

I am writing to you to let you know the voting period for the Universal Code of Conduct Coordinating Committee (U4C) is open now through August 10, 2024. Read the information on the voting page on Meta-wiki to learn more about voting and voter eligibility.

The Universal Code of Conduct Coordinating Committee (U4C) is a global group dedicated to providing an equitable and consistent implementation of the UCoC. Community members were invited to submit their applications for the U4C. For more information and the responsibilities of the U4C, please review the U4C Charter.

Please share this message with members of your community so they can participate as well.

In cooperation with the U4C,

RamzyM (WMF) 02:46, 27 July 2024 (UTC)[reply]

Category:Videos by language

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]

July 28

Question about Flickr2Commons

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]

Some country missed on File:Flag map of the world.svg

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]

July 29

Chromista, Hacrobia and other non-monophyletic groupings

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]

July 30

Are 4K videos discouraged now?

Tracked in Phabricator
Task T368433

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]
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]

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]

Library of Congress #

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]

Quality Images nomination experiment in August

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]

July 31

Nudity category

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]

August 01

Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump&oldid=905610693"