Commons: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/2025/02. Please note:
Purposes which do not meet the scope of this page:
Search archives: |
| Legend |
|---|
|
|
|
|
|
| Manual settings |
| When exceptions occur, please check the setting first. |
 A village pump in Burkina Faso [add] | |||||||||||||||
| |||||||||||||||
 |
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 7 days. |
January 24
Vector 2022 will be the default skin
Hello. We are the Wikimedia Foundation Web team. We are here to announce that the Vector 2022 skin will become the default desktop skin here on 10 February. We will gladly answer your questions, concerns, or additional thoughts! We will also help you adjust things which Vector 2022 may not be compatible with. Check out our FAQ – you will find many useful answers there.
If you are using Vector legacy skin, you may find yourself receiving the Vector 2022 skin. You may select Vector legacy as your global preference to avoid seeing the change. Logged-in users can at any time switch to any other available skins, or stay with Vector 2022 and enjoy choosing between its light and dark mode. Users of other skins will not see any changes.
Why are we changing the skin now
For technical reasons (listed below), we need to deploy the skin soon. After deployment, we will continue discussing issues and questions about the interface, and we'll be ready to work with you on various issues like gadget compatibility.
- Due to releases of new features only available in the Vector 2022 skin, our technical ability to support both skins as the default is coming to an end. Keeping more than one skin as the default across different wikis indefinitely is impossible. This is about the architecture of our skins. As the Foundation or the movement in general, we don't have the capability to develop and maintain software working with different skins as default. This means that the longer we keep multiple skins as the default, the higher the likelihood of bugs, regressions, and other things breaking that we do not have the resources to support or fix.
- Vector 2022 has been the default on almost all wikis for more than a year. In this time, the skin was proven to provide improvements to readers while also evolving. After we built and deployed on most wikis, we added new features, such as the Appearance menu with the dark mode functionality. We will keep working on this skin, and deployment doesn't mean that existing issues will not be addressed. For example, as part of our work on the Accessibility for Reading project, we built out dark mode, changed the width of the main page back to full (T357706), and solved issues of wide tables overlapping the right-column menus (T330527).
- Vector legacy's code is not compatible with some of the existing, coming, or future software. Keeping this skin as the default would exclude most users from these improvements. Important examples of features not supported by Vector legacy are: the enriched table of contents on talk pages, dark mode, and also temporary account holder experience which, due to legal reasons, we will have to enable. In other words, the only skin supporting features for temporary account holders (like banners informing "hey, you're using a temp account") is Vector 2022.
How to request changes to the skin
We are guessing that some of you may want to see some changes to the skin. We are still improving Vector 2022 and the overall reading experience. If you have a feature request or a bug report, we encourage you to comment here or open a ticket in Phabricator. We will decide on the priority of these requests alongside our regular processes after deployment. Some fixes may be done via gadgets or user scripts, too.
About the skin
We encourage you to try out Vector 2022 by going to the Appearance tab in your preferences and selecting it from the list of skins. Getting used to it may take a few days, and that's the standard for interface changes.
Vector 2022 is the modernized version of the currently default skin Vector legacy. It is the default on almost all Wikimedia wikis (there are about 10 left now). Most of the active editors use it and do not opt out of the skin at statistically noticeable rates despite easy access to the opt-out link. (Check the source here.)
[Our 2022 answer to why is a change necessary] When the current default skin was created, it reflected the needs of the readers and editors as these were in 2010. Since then, new users have begun using the Internet and Wikimedia projects in different ways. Although there were changes to features the skin supported, the structure, navigation, visual layout, and overall readability of the skin did not change. The old Vector does not meet the current users' needs.
[Objective] The objective for the Vector 2022 skin is to make the interface more welcoming and comfortable for readers and useful for advanced users. It introduces a series of changes that aim to improve problems new and existing readers and editors were having with the old skin. It draws inspiration from previous user requests, the Community Wishlist Surveys, and gadgets and scripts. The work helped our code follow the standards and improve all other skins. We reduced PHP code in the other available skins by 75%. The project has also focused on making it easier to support gadgets and use APIs.
[Changes in a nutshell] The skin introduces changes to the navigation and layout of the site. It adds persistent elements such as a sticky header and table of contents to make frequently-used actions easier to access. It also makes some changes to the overall styling of the page. The analysis of the data collected concluded that these changes improve readability and usability, and save time currently spent in scrolling, searching, and navigating – all of which can be interpreted to create an easier reading experience. The new skin does not remove any functionality currently available on the old Vector skin. On wikis with this skin as the default, there are no negative effects to page views, account creation, or edit rates. On our project pages you will find findings and results in a nutshell.
A summary of findings and results
- On average, 87% of logged-in users on our early adopter wikis (incl. French Wikipedia) continue to use the new skin once they try it.
- The sticky header makes it easier to find tools that editors use often. It decreases scrolling to the top of the page by 16%.
- The new table of contents makes it easier to navigate to different sections. Readers and editors jumped to different sections of the page 50% more than with the old table of contents.
- The new search bar is easier to find and makes it easier to find the correct search result from the list. This increased the amount of searches started by 30% on the wikis we tested on.
- The skin does not negatively affect page views, edit rates, or account creation. In fact, there is observational evidence of increases in page views and account creation across partner communities.
How can editors change and customize this skin?
- We make it possible to configure and personalize our changes. We are happy to work with volunteers with technical skills who would like to create new gadgets and user scripts. So far, many gadgets and user scripts have been built by volunteer developers. These aspects include making the background gray, turning off sticky elements, bringing back the old table of contents, and more. We encourage you to check out our repository for a list of currently available customizations and changes, or to add your own.
- In Vector 2022, logged-in and logged-out users can change the font size and color scheme based on their individual needs. Dark mode is now available for logged-in users of Vector 2022, and we would like to make it available to logged-out users as soon as most articles are dark-mode friendly.
How will we go through the change
- Wiki page: we would like to kindly suggest creating a page similar to English Wikipedia's w:WP:V22. It may explain the basics like how to opt-out or customize the skin.
- CentralNotice banner for logged-in users: before and shortly after deployment, we will display a banner announcing the change. It will be linking to Commons:Vector 2022 if you decide to create such a page. Otherwise, it will be linking to this announcement. This should limit the confusion and the number of repetitive questions about the change.
If you think there are any significant technical issues, let us know – perhaps we've missed something. We're looking forward to your comments and reactions from readers after deployment. Thank you! OVasileva (WMF) and SGrabarczuk (WMF) (talk) 01:06, 24 January; Unarchiving to keep this here SGrabarczuk (WMF) (talk) 19:20, 14 February 2025 (UTC)
- This is great news! I've been using Vector 2022 here for over a year now without issue, and it's important that Commons looks the same to users as the other Wikimedia projects. Thanks. Mike Peel (talk) 19:25, 10 February 2025 (UTC)
- Personally I'm hating it.StarTrekker (talk) 07:06, 11 February 2025 (UTC)
- I think I don't like some things either. However, it takes some time to get used to it and afterwards one likes it more than the prior skin. It would be good to name some things that may be problematic if there are any so it could get improved upon. For example, I think it may make the links to the Welcome and Community portal pages and possibly a few other things like the link to the page information page with the Pageviews link too hard to find. Prototyperspective (talk) 13:18, 11 February 2025 (UTC)
- I think the links to the Wikipedia articles are now too hidden, especially for users not very familiar with the site. I think the Wikipedia article of the language the user has configured with a fallback to the English article if there's no article in that language should be linked well-visibly, for example right before the category description at the top of the page. Prototyperspective (talk) 18:14, 12 February 2025 (UTC)
- It has been around for a quite long time in Wikipedia and other wikis. Software changes are often disruptive at first, but once you get used to them, you don't want to go back. MGeog2022 (talk) 18:30, 12 February 2025 (UTC)
- I use the skin since 2019, so no huge changes at all :D --PantheraLeo1359531 😺 (talk) 14:20, 5 March 2025 (UTC)
- I think I don't like some things either. However, it takes some time to get used to it and afterwards one likes it more than the prior skin. It would be good to name some things that may be problematic if there are any so it could get improved upon. For example, I think it may make the links to the Welcome and Community portal pages and possibly a few other things like the link to the page information page with the Pageviews link too hard to find. Prototyperspective (talk) 13:18, 11 February 2025 (UTC)
- Amazingǃ Comfortable visual consistent across the projects. Thanks. Ong Kai Jin (talk) 13:02, 11 February 2025 (UTC)
- @OVasileva (WMF) @SGrabarczuk (WMF): I think it makes sense as a whole. But there are a couple of things that I don't understand and that I think are relevant to all readers and users. I suppose this has been discussed before.
- I don't really see how other Wikimedia projects are "Tools." I doubt readers will look for them there. It also doesn't seem ideal to have to scroll in a drop-down menu, in a lot of cases. Why not a separate "In other projects" tab?
- In the file namespace, perhaps the "Download," "Use this file" etc menu shouldn't be to the right of the previewed filed, since it can overlap awkwardly with the default position of the "Appearance" settings. Or is it an intentional choice that "Appearance" can overlap with other elements?
- Sinigh (talk) 14:18, 11 February 2025 (UTC)
I've seen Appearance panel was overlapped on right side. [1] -- Great Brightstar (talk) 05:39, 16 February 2025 (UTC)
- I've just edited Commons:File_renaming to match the new skin. Is the "More" menu completely replaced by "Tools"? CMD (talk) 08:28, 16 February 2025 (UTC)
- Yes, I can see the "Rename" link in the "Tools" menu after logged in. -- Great Brightstar (talk) 17:43, 17 February 2025 (UTC)
- Now I see the stockphoto layout panel moved to the top of image. This is fixed. -- Great Brightstar (talk) 14:22, 3 March 2025 (UTC)
February 03
Brunei Darussalam Newsletter
Hello! I came across the Brunei Darussalam Newsletter, where some of the older issues contain a sidebar on the left side of page 2 that states: "Brunei Darussalam Newsletter is published fortnightly by the Department of Information. It reports on government, social and business events in the country. All money values are expressed in Brunei dollars $, unless otherwise stated. Any information in this newsletter may be reproduced; a clipping of the publication would be appreciated. For free subscription (Excluding postage) write to Information Department, Jalan Stoney, Bandar Seri Begawan 2041, Brunei Darussalam." An example would be here. So my question is whether the term "information" in that specific issue could also apply to images.
This has been previously used in "Category:Ministry of Foreign Affairs (Brunei) News Digest issues". — Preceding unsigned comment added by Pangalau (talk • contribs) 13:52, 3 February 2025 (UTC)
February 04
Discussion of sockpuppetry issue for Anonymous Hong Kong Photographer 1 on Meta
Hello. I recently opened a request for comment on Meta regarding sockpuppetry issue of User:Anonymous Hong Kong Photographer 1. You can join the discussion here. 〈興華街〉📅❓ 13:48, 4 February 2025 (UTC)
|
February 24
Many files have languished in Category:License review needed so long (e.g. over a decade) that there is no hope of ever definitively resolving whether they were appropriately licensed at time of upload. As a result, it is very difficult to find files that are capable of being effectively reviewed, because that category and its subcats are so clogged with hopeless cases.
I would like to see us clear these one way or another. I have several ideas of what we could do, but it's not an area I've worked in much, and for all I know some good decisions may already have been made and I'm just not aware of them. Does anyone have more sense of what is going on here? - Jmabel ! talk 21:33, 24 February 2025 (UTC)
- probably no file has "languished... over a decade", since at some point many years ago the category was close to empty. rather, some users recently slapped the template on old uploads.
- use the TOC to jump to recent uploads.
- RoyZuo (talk) 09:55, 25 February 2025 (UTC)
- Probably the decade-plus-old files were not initially tagged, but they never had their licenses reviewed. They were tagged later. E.g. File:Tiziano Ferro on Radio Bruno.jpg, File:Tradlinx logo.png, File:Image of Timothy Elisha McPherson Jr.jpg (just under a decade). - Jmabel ! talk 20:51, 25 February 2025 (UTC)
This pops up every once in a while, see Commons:Village_pump/Archive/2024/10#Almost_400k_files_need_license_review, Commons:Village_pump/Archive/2023/05#License_reviews and Commons:Village_pump/Archive/2023/04#103,857_unreviewed_files. Let's add a timestamp just like {{Uncategorized}}. That doesn't solve the problem, but does break it into small blocks people can work on. Multichill (talk) 21:43, 25 February 2025 (UTC)
- @Multichill: I like that idea. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 21:51, 25 February 2025 (UTC)
- Category already sorted by time. RoyZuo (talk) 14:28, 26 February 2025 (UTC)
- There is a proposal at Commons:Village_pump/Proposals#Add_an_outcome_of_LicenseReview and it can't solve the problem, but it can help. We need more people (or bots) to help review files but there are a number of files there are hard to fix. And my guess is that when someone meet files they can't fix they are likely to skip it and if the next files are also hard to fix then there is a risk they give up and stop reviewing files. So we need to make it possible to do something about those hard files. And I do not think the solution is always to delete. --MGA73 (talk) 07:54, 28 February 2025 (UTC)
February 26
Standard way to add an image ID in {{Information}}
Is there an already existing way/template to include the image/object ID information with template {{Information}} (for example for objects photographed in a museum or as inventory number of larger image collections)?
An example what I'm looking for would be something like {{Object location}}. I know that you can create your own information fields with {{Information field|name=|value=}}, so I'm asking if there already exists a solution for this. --D-Kuru (talk) 07:48, 26 February 2025 (UTC)
- So basically a template for this item on Wikidata Q1417099 - accession number --D-Kuru (talk) 07:52, 26 February 2025 (UTC)
- @D-Kuru: I think what you're looking for might be in one of the derivative templates like {{Artwork}}, which has parameters for collections or museum exhibits. ReneeWrites (talk) 09:31, 26 February 2025 (UTC)
- Seconding ReneeWrites here. {{Art Photo}} may be what you want. See File:Frederic Storck - Muncitorul pietrar - 1896 - 01.jpg for a recent example where I used it this way. - Jmabel ! talk 06:35, 27 February 2025 (UTC)
- @Jmabel: |accession number = sounds pretty much like the thing I am searching for, but I wonder if this can also be included in {{Information}}. The general parameters of {{Artwork}} work somewhat, but don't really fit all that well either. Additionally it looks a little bit of overkill to the one line I actually need in the information template. --D-Kuru (talk) 07:16, 27 February 2025 (UTC)
- @D-Kuru: A slightly less cumbersome way to do it (output will be clear to humans, but not to bots) would be to set the "other fields" parameter of {{Information}} to {{InFi|accession number|the actual number}}. - Jmabel ! talk 17:25, 28 February 2025 (UTC)
- This is what I thought would be the easiest (not necessarily best) option for now (the so called "temporary"-forever). IMO the ID could be made machine readable if included in the structured data with Property:P217 - inventory number. --D-Kuru (talk) 21:23, 28 February 2025 (UTC)
- @D-Kuru: A slightly less cumbersome way to do it (output will be clear to humans, but not to bots) would be to set the "other fields" parameter of {{Information}} to {{InFi|accession number|the actual number}}. - Jmabel ! talk 17:25, 28 February 2025 (UTC)
- @Jmabel: |accession number = sounds pretty much like the thing I am searching for, but I wonder if this can also be included in {{Information}}. The general parameters of {{Artwork}} work somewhat, but don't really fit all that well either. Additionally it looks a little bit of overkill to the one line I actually need in the information template. --D-Kuru (talk) 07:16, 27 February 2025 (UTC)
February 27
Cascade protection
Apparently, the cascade protection is not working properly. I saw a spam edit from a recently created account here and was able to revert it without any issues. I tested it, and it seems I could edit the page as an IP. Is this a recognized issue, or am I mixing things up? RodRabelo7 (talk) 04:54, 27 February 2025 (UTC)
- Of course, there's a warning stating the "page is currently protected, and can be edited only by administrators". RodRabelo7 (talk) 04:55, 27 February 2025 (UTC)
- @RodRabelo7: That looks like a bug, please see mw:How to report a bug. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 07:35, 27 February 2025 (UTC)
- There have been some fixes to cascade protection this week see phab:T24521, to fix the years long issue that the file description was protected instead of the actual file. I'm assuming it is related to those changes. —TheDJ (talk • contribs) 10:07, 27 February 2025 (UTC)
- @TheDJ: Protecting just the description sounds very unprofessional. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 16:51, 27 February 2025 (UTC)
- Previously the file description page and and image itself was protected when the media was transcluded, but this caused issues for people that wanted to nominate images for deletion or make improvements to the caption or file description. Now only the image itself is proected. The message is leftover that needs to be removed. Dylsss (talk) 21:55, 27 February 2025 (UTC)
- @Dylsss: AIUI, part of the point of the cascading protection is that files which are on the main pages of our project and many other projects are high-visibility targets for vandals, and should have their file description pages fully protected for the durations of their stays on said main pages. COM:AN can be used to make legitimate suggestions for changing anything on those file description pages. Just protecting from upload vandalism does not mitigate other types of vandalism. Where did the community have a chance to vote on this change? — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 18:10, 28 February 2025 (UTC)
- @Jeff G. "the point of the cascading protection" This is what it has been used for. But the point of cascade protection is to protect the things that are transcluded into the protected page. This didn't work for files and it seems we have since used it to indirectly protect the file pages. But if I make a link on wikipedia, that also doesn't protect the article that we link to, and changing the file description does not change the original page that the file is transcoded into either, indicating that file description pages being protected is not the intended functionality. —TheDJ (talk • contribs) 14:40, 3 March 2025 (UTC)
- @Dylsss: AIUI, part of the point of the cascading protection is that files which are on the main pages of our project and many other projects are high-visibility targets for vandals, and should have their file description pages fully protected for the durations of their stays on said main pages. COM:AN can be used to make legitimate suggestions for changing anything on those file description pages. Just protecting from upload vandalism does not mitigate other types of vandalism. Where did the community have a chance to vote on this change? — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 18:10, 28 February 2025 (UTC)
- Previously the file description page and and image itself was protected when the media was transcluded, but this caused issues for people that wanted to nominate images for deletion or make improvements to the caption or file description. Now only the image itself is proected. The message is leftover that needs to be removed. Dylsss (talk) 21:55, 27 February 2025 (UTC)
- @TheDJ: Protecting just the description sounds very unprofessional. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 16:51, 27 February 2025 (UTC)
February 28
Summaries of the last two Commons Community Conversations now available
Hello all! The summaries from our last two Commons Community Conversations are now available on Commons:
- Community call on Tool investment priority (January 2025)
- Community call on Impact and funding model (February 2025)
If you have more feedback coming about the topics we discussed, you can do so in the Community calls talk page.
Thank you very much for participating and sharing your feedback! Sannita (WMF) (talk) 15:32, 28 February 2025 (UTC)
- @Sannita (WMF): Thanks! When do you anticipate them being available for the first four converstions? — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 18:12, 28 February 2025 (UTC)
- All four summaries (and the summaries of the two meetings before the conversations) are already available at Commons:WMF_support_for_Commons/Commons_community_calls#Past_discussions. Sannita (WMF) (talk) 17:14, 1 March 2025 (UTC)
- @Sannita (WMF): Thanks! I'm sorry, I must have missed those. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 17:59, 1 March 2025 (UTC)
- @Jeff G. No problem at all! I also lose track of discussions sometimes, that why I'm happy about notifications and pings :) Sannita (WMF) (talk) 15:19, 3 March 2025 (UTC)
- The textured meshes are hot stuff --PantheraLeo1359531 😺 (talk) 17:20, 5 March 2025 (UTC)
- @Jeff G. No problem at all! I also lose track of discussions sometimes, that why I'm happy about notifications and pings :) Sannita (WMF) (talk) 15:19, 3 March 2025 (UTC)
- @Sannita (WMF): Thanks! I'm sorry, I must have missed those. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 17:59, 1 March 2025 (UTC)
- All four summaries (and the summaries of the two meetings before the conversations) are already available at Commons:WMF_support_for_Commons/Commons_community_calls#Past_discussions. Sannita (WMF) (talk) 17:14, 1 March 2025 (UTC)
UploadWizard and license review
Currently, other than the special case that they UploadWizard has for direct uploads from Flickr, when a user uses UploadWizard to upload a file sourced from a third-party site, there is no built-in way to request license review. This certainly results in some link rot, because source pages go away (or change their license) and for licenses that were never reviewed we have no way to prove the older license. (Sometimes it can be done cumbersomely through the Internet Archive, sometimes not even that.)
I had suggested that whenever page on another website is given as a source for copyrighted free-licensed material, UploadWizard should automatically tag with {{License Review}}. Sannita (WMF) raised the reasonable concern that might go too far the other way, and overburden admins and license reviewers. (I'm not sure if that concern carries the day or not: after all, every unreviewed license of this sort is at risk of us being unable to keep the file for the long term, because its license status could become questionable.)
Sannita and I both agree this requires broader community discussion, so here we are. Obviously, the most affected people are admins and license reviewers, so we would especially like to hear from them, and in particular from people who already do a fair amount of reviewing licenses. - Jmabel ! talk 17:38, 28 February 2025 (UTC)
Support. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 18:14, 28 February 2025 (UTC)
Comment - if we do this - and perhaps even if we don't! - we ought to change the messaging in the wizard to make it clearer that:
- The source URL should, in most cases, be the URL of a web page on the site where the file came from - not just the domain name, nor a direct link to the file itself.
- If the license is not immediately apparent on that web page, another URL should be included which can be used to verify the license.
- As a license reviewer, one of the hardest parts of verifying licenses for content that isn't from major web sites (Flickr, YouTube, etc) is figuring out where the license was specified. It's often hard to distinguish between "the license is there, it's just really hard to find" and "the content was never actually released under a free license". Omphalographer (talk) 19:58, 28 February 2025 (UTC)
- What happens if a file passes license review but was never archived, then the license changes and someone requests takedown? I think a focus on archiving sources when uploading files is also important. REAL 💬 ⬆ 20:12, 28 February 2025 (UTC)
- @999real: good practice by any uploader, but not a burden I'd want to place on the reviewers.
- The whole point of license review is that someone trusted by Commons has verified the license. The scenario you are describing might be an issue for someone outside Commons who does not share that trust, but that's not necessarily our responsibility to deal with. I would assume that the broader Wikimedian community will also trust Commons on this. - Jmabel ! talk 02:16, 1 March 2025 (UTC)
- About archiving I did not mean to say license reviewers should have to do it, but that in the UploadWizard suggesting to uploaders to archive the source could be useful. REAL 💬 ⬆ 02:34, 1 March 2025 (UTC)
- The question remains, why isn't archiving done automatically? The English-language Wikipedia already automatically archives any external link. Maybe we could change the way URL's are displayed at the Wikimedia Commons, that "Archive now" and "Check the archives" become automatic options for any URL. Maybe the toolbox for license reviewers could include a option that is "Archive this link" whenever they click on an external link, but not every website allows archiving. I noticed ever since LLM's became popular a few years ago that more and more websites now disallow bots (including the Internet Archive's Wayback Machine) from scraping its content. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 13:29, 1 March 2025 (UTC)
- About archiving I did not mean to say license reviewers should have to do it, but that in the UploadWizard suggesting to uploaders to archive the source could be useful. REAL 💬 ⬆ 02:34, 1 March 2025 (UTC)
- I Support this in general, but I worry this will just create an even bigger backlog, and the same problems (e.g. link rot) will still occur when the license is not reviewed in time. I think before implementing such feature, we need to find ways to reduce the workload of licence reviewers, so we will be well prepared to deal with the influx of license reviews. Tvpuppy (talk) 03:21, 1 March 2025 (UTC)
- Support -- Ooligan (talk) 03:19, 2 March 2025 (UTC)
- Support this proposal/suggestion (as a license reviewer myself, but I unfortunately had no ample time recently to review files that have external links). Yeah, a downside on this is the "bloating" of categories related to licensing reviews. Suggest that, like in enwiki, there should be a bot that will be able to archive external links and automatically add the Wayback Machine links to file description pages. JWilz12345 (Talk|Contributions) 12:50, 2 March 2025 (UTC)
@Jeff G., Omphalographer, 999real, and Tvpuppy: are any of you license reviewers? (& same question to anyone else who may reply here.) - Jmabel ! talk 06:03, 1 March 2025 (UTC)
- I'm not a license reviewer, just wanted to express my opinion on this as an uploader/contributor. Tvpuppy (talk) 06:25, 1 March 2025 (UTC)
- Yes. I haven't had time to do much reviewing lately, but I'm familiar with the process. Omphalographer (talk) 06:27, 1 March 2025 (UTC)
- I am not. To be clear, my intention was to express that I think encouraging uploaders to archive the source (or automatically archiving) at the time of upload is an alternative that burdens license reviewers less and can help anyone later verify the license. REAL 💬 ⬆ 15:08, 1 March 2025 (UTC)
- @Jmabel: Yes, but I haven't had time to review many licenses lately. Perhaps if the source could be split into three parts, that would help with the reviews: raw file URL; page on which the file appears; and page on which the license appears (or exactly how to find it on the page on which the file appears). — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 15:22, 1 March 2025 (UTC)
March 01
Commons Gazette 2025-03
In February 2025, 1 sysop was elected; 1 sysop was removed. Currently, there are 182 sysops.
Election:
Removal:
- User:Spiritia was removed on 12 February due to inactivity. She had served as sysop from 9 April 2008.
We thank her for her service.
Edited by RoyZuo.
Commons Gazette is a monthly newsletter of the latest important news about Wikimedia Commons, edited by volunteers. You can also help with editing!
--RoyZuo (talk) 01:55, 1 March 2025 (UTC)
video2commons not working
Hello everyone,
I am writing an article about Katu Mirim and I found this CC BY video on youtube which would be a great illustration. When I try to pass it through https://video2commons.toolforge.org/ though, I get the error : Error: An exception occurred: DownloadError: b'ERROR: [youtube] RhbJjHhm6LU: Sign in to confirm you\xe2\x80\x99re not a bot.
Could anyone else try, see if you get the same error ? Thank you !
have a good day Vache-crapaud (talk) 22:50, 1 March 2025 (UTC)
- Hello, if you check Commons:video2commons, you will see unfortunately it stopped working for YouTube videos for a while now. The problem came from YouTube itself so currently there are no fix for it. As a workaround, you just have to download the video manually then upload the file through videos2commons. Tvpuppy (talk) 23:53, 1 March 2025 (UTC)
- Thank you! Vache-crapaud (talk) 09:50, 2 March 2025 (UTC)
- Tracked in GitHub
toolforge/video2commons/issues/237
- Created the issue. See Commons:YouTube files/Downloading for info how to download as webm without the tool. Prototyperspective (talk) 15:23, 2 March 2025 (UTC)
March 02
Webservice request timed out for glamorous tool on toolforge
Seems like there is not GitHub repo and the issues are also not tracked in phabricator. I don't understand why that is since that makes it unlikely for other to discover and help develop these useful tools.
Does somebody here know why the glamorous and glamorgan – which can be used to see file uses of files (example) – are getting the 504 Gateway Time-out – is there an issue somewhere?
--Prototyperspective (talk) 16:02, 2 March 2025 (UTC)
Question to native English-speakers about correct category name
Some time ago I created Category:Child victims of National Socialism, and since I'm not a native English-speaker, I used the already existing Category:Child casualties and Category:Child Holocaust victims for guidance on choosing a proper English name for my category - both categories use the singular form for the word "child". Recently, @Blackcat moved[2] the category to the plural form "children": Category:Children victims of National Socialism. I asked[3] Blackcat about the move, because the naming is not in line with the other categories and to me the singular form "child" sounds like the correct form. I might be wrong, of course, but Blackcat also doesn't seem to be a native English-speaker, so I'm hoping to get some input from native English-speakers on the category name. Should it be "child victims" or "children victims"?
(Side note: in the user talk page discussion, you'll see that "Japanese children" and "Children of Japan" were mentioned. This is in reference to some other category moves that Blackcat did (e.g. [4]) and which I absolutely support, because the original category naming in those cases was definitely non-standard and I only had chosen that non-standard naming because there was already a category with that naming pattern when I started to create similar categories for children of other nations; namely, it was this one: [5]. But the non-standard naming also created issues with country-navigation template usage, so I'm glad that Blackcat fixed those with the move.) Nakonana (talk) 17:06, 2 March 2025 (UTC)
- I think that using the singular form "child" sounded more correct. Using the plural form, i.e. "children victims", doesn’t seem correct in the same way as using the plural form for “adult”, i.e. “adults victims”. Tvpuppy (talk) 17:35, 2 March 2025 (UTC)
- "Child victims" is correct. "Children victims" doesn't make sense. --Adamant1 (talk) 17:44, 2 March 2025 (UTC)
- "Child" is correct, and in this context it is an adjective, not a noun. English-language adjectives don't change forms in the plural. - Jmabel ! talk 21:51, 2 March 2025 (UTC)
- "Child victims" is the correct plural. ReneeWrites (talk) 12:10, 3 March 2025 (UTC)
- "Child victim" is a compound noun; plural is "child victims". See https://dictionary.cambridge.org/us/grammar/british-grammar/nouns-compound-nouns Glrx (talk) 17:40, 3 March 2025 (UTC)
- @Glrx: I know that "child" is used as adjective in that context (and as a matter of fact I know that English adjectives don't change in genre and number) but I thought it could be used "children" as noun ("Children [that are] victims of WWII". Anyway the consensus towards "Child victims" is clear, I'm going to revert my move. -- Blackcat
10:45, 4 March 2025 (UTC)
- I think it might have worked as a noun if there was a dash: "Children — victims of WWII". However, that would be a very unusual category name, and there might be a subtle difference in meaning, too.
- Anyways, thanks for undoing the move, and thanks to everyone else for the input. Nakonana (talk) 17:40, 4 March 2025 (UTC)
- @Glrx: I know that "child" is used as adjective in that context (and as a matter of fact I know that English adjectives don't change in genre and number) but I thought it could be used "children" as noun ("Children [that are] victims of WWII". Anyway the consensus towards "Child victims" is clear, I'm going to revert my move. -- Blackcat
No to intimidation of volunteer contributors
Hello, just for your info, there is an open letter in the French Wikipedia fr:Wikipédia:Lettre ouverte : non à l'intimidation des contributeurs bénévoles in support to a user (also user here) who suffered pressure and threats from a newspaper journalist. Christian Ferrer (talk) 17:50, 2 March 2025 (UTC)
March 03
Nazism vs National Socialism
Hello everyone,
I would appreciate it if other users could participate in this discussion to help reach a consensus. Your feedback and input would be valuable in resolving the matter.
Thanks in advance!
Nebula84912 (talk) 18:11, 3 March 2025 (UTC)
March 04
"This file did not pass file verification."
Hi all
I've just tried to upload some svg files (individual pages of a booklet I've been working on for a Wikimedia chapter) and I'm getting a weird message with about 20% of the pages, it says "This file did not pass file verification". Two things:
- There is no further information about what this means and no link to documentation that explains this. How do I requestion this gets fixed?
- Does anyone know if there is documentation on what this error means and how to fix it?
Thanks
John Cummings (talk) 13:10, 4 March 2025 (UTC)
- @John Cummings: Since you don't say the date or file name it's hard to be sure. You say you "just" did this, but the most recent Filter Log entries I can find for you are almost a week back. Those were for trying to add a permission ticket when you aren't a VRT member. Actually, that's what I see for all Filter Log issued for you in the last month or so. - Jmabel ! talk 18:40, 4 March 2025 (UTC)
- Normally it would mean that the file is not an svg or has the wrong extension (this would not show up in the abuse log). It would help if you could upload the file somewhere else and link to it so we can see. Bawolff (talk) 20:11, 4 March 2025 (UTC)
- Looking at logs, it looks like you tried to upload a 12mb file named "12 Case study pages Sudan.svg". Are you sure that wasn't supposed to be a .pdf instead? Case studies aren't usually in SVG format, and the error you got would be the one you would get if you tried to upload a PDF file with a .svg extension. Bawolff (talk) 09:39, 5 March 2025 (UTC)
- Hi Bawolff thanks, its definately an .svg, Jmabel, I don't understand what ticket you mean, am I doing something wrong? If so I'd like to correct it. To be clear, it won't show up in my uploads because it won't accept it as an upload. Here are the files which don't work, you can see from my recent uploads other svg files in the same series I made at the same time work completely fine Category:WikiGap Brochure...
- I've started a phab ticket here
- Thanks for any suggestions.
- John Cummings (talk) 11:11, 5 March 2025 (UTC)
- @John Cummings: if my theory is right, it wouldn't be a problem with the file, it would be a problem with the accompanying wikitext. If you tried to upload with the {{PermissionTicket}} template, that would be rejected, because only VRT members are allowed to place that in uploads. - Jmabel ! talk 23:31, 5 March 2025 (UTC)
- Hi Jmabel, thanks but I'm completely confused, I didn't try uploading these images with a VRT template, I think I've only ever uploaded anything with the OTRS/VRT pending template.
- @John Cummings It looks like those files have very large embedded JPEGs in them. Commons does not allow raster images embedded in SVGs to be larger than 10mb (after base64 conversion). I think this is the issue you are having. Bawolff (talk) 03:53, 6 March 2025 (UTC)
- Hi Bawolff, thank you very much for explaining, is this documented anywhere? John Cummings (talk) 09:07, 6 March 2025 (UTC)
- I added it to https://commons.wikimedia.org/w/index.php?title=Help:SVG&diff=prev&oldid=912120003 last time this came up. As far as i can tell, its not an intentional change but a change because one of the programs mediawiki uses (libxml) changed its default. So all that would need to be done is for mediawiki to set the LIBXML_PARSEHUGE option to restore the old behaviour. Perhaps @Sannita (WMF) could convince the multimedia team to look into it. Bawolff (talk) 09:21, 6 March 2025 (UTC)
- Hi Bawolff, thank you very much for explaining, is this documented anywhere? John Cummings (talk) 09:07, 6 March 2025 (UTC)
- John Cummings (talk) 11:11, 5 March 2025 (UTC)
I proposed to change the GFDL cut-off date
Hi! Since this place is for discussing of policies I thought I would leave a notice that I made a proposal to change Commons:Licensing here: Commons:Village_pump/Proposals#Proposal_(change_GFDL_cut-off_date). --MGA73 (talk) 19:34, 4 March 2025 (UTC)
March 05
Unsourced Map Used on Many Pages
-
GIF uploaded 27 March 2010 by JWooldridge. 575 × 792. -
GIF uploaded 23 March 2006 by en:User:Andrew c. Talk page reveals he has a vector version. 364 × 500. -
Andrew c's source map. 4 March 2006. © Israel Central Bureau of Statistics.
_(cropped).jpg){kind=link}
I wasn't sure where the right place to discuss this is, but the image Galilee to Judea.gif is a map which was uploaded 15 years ago without comment and which is now used on something like twenty wikipedia articles across several different languages. It makes several claims about borders and political entities without any sources, and is placed very authoritatively at the top of some articles despite that. Is there a policy about this, or could someone familiar with the subject verify the contents of the map? I'm not very familiar with Commons so I'm sorry if this is confusing or if I'm making something straightforward into something very roundabout, but I'm very concerned about the idea of maps and other images which contain unverified claims being presented as authoritative. — Preceding unsigned comment added by Buglover100000 (talk • contribs) 19:15, 5 March 2025 (UTC)
- Looks to me like the source is Andrew c in 2006 with CC-BY 3.0. 364 ≈ 363.005. Aspect ratios are 0.726 and 0.728.
- Andrew states:
- This is a map of first century Iudaea Province that I created using Illustrator CS2. I traced this image for the general geographic features. I then manually input data from maps found in a couple of sources.
- Robert W. Funk and the Jesus Seminar. The Acts of Jesus. HarperSanFrancisco: 1998. p. xxiv.
- Michael Grant. Jesus: An Historian's Review of the Gospels. Charles Scribner's Sons: 1977. p. 65-67.
- John P. Meier. A Marginal Jew. Doubleday: 1991. p. 1:434.
- This is a map of first century Iudaea Province that I created using Illustrator CS2. I traced this image for the general geographic features. I then manually input data from maps found in a couple of sources.
- Glrx (talk) 19:45, 5 March 2025 (UTC)
Is there a reason Commons doesnt allow us to convert MP4 files to WEBM when uploading?
Having to search out external software and websites just to even being allowed to upload videos in the first place is a huge annoyance which only helps discouraging users from uploading content here. --Trade (talk) 23:49, 5 March 2025 (UTC)
- @Trade: Yes, "Commons does not support the more commonly used patent-encumbered video formats such as H.264 and H.265 that are used in MP4 and MOV files, since their use could require royalty payments" per COM:Video#Video formats. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 01:55, 6 March 2025 (UTC)
- That's the whole point of converting the videos Trade (talk) 03:25, 6 March 2025 (UTC)
- @Trade, this was a feature request in 2023: Commons:Requests for comment/Technical needs survey/Video conversion support. That discussion mentions video2commons which may help somewhat. See Help:Converting video. Commander Keane (talk) 03:21, 6 March 2025 (UTC)
- The reason is here: Commons:Requests for comment/MP4 Video. Pyb en résidence (talk) 18:52, 6 March 2025 (UTC)
- That RFC was over ten years ago, though. Consensus can change - as can the facts on the ground; did Wikimedia even support video transcoding at the time? Omphalographer (talk) 19:56, 6 March 2025 (UTC)
- The conversation on this is scattered and needs to be centralized. The relevant mp4 patents will expire in maybe 2027 or 2028. Commons_talk:Requests_for_comment/MP4_Video#6_years_later_-_patents_expiring_-_when_is_MP4_free_enough? I started some other discussion somewhere where WMF staff asked what community wanted for Commons, and the thought there was that whenever mp4 is off patent, it will be trivial for WMF to plan that year to permit mp4 uploads on the day it becomes open technology. Bluerasberry (talk) 21:36, 6 March 2025 (UTC)
- One problem with converting video in high quality is that it requires huge processing power. The other problem is that if we make it possible for everyone to upload their phone video snapshot we will have a huge reviewing problem as we need someone to watch the hole video and check it for copyright violations. GPSLeo (talk) 22:12, 6 March 2025 (UTC)
- We could make mp4 uploads as autopatroller only if necessary when we get to that. But we definitely should have some option in place to upload mp4 once its off-patent. That would certainly make it easier for me to upload videos I've captured off my tablet (as I would need to run them through Video2Commons to convert them to webm) Abzeronow (talk) 23:22, 6 March 2025 (UTC)
- For what it's worth, we already have a pretty serious "reviewing problem" for YouTube imports. It's not helped by the fact that we don't have well-established scope standards for video content. Omphalographer (talk) 23:52, 6 March 2025 (UTC)
- One problem with converting video in high quality is that it requires huge processing power. The other problem is that if we make it possible for everyone to upload their phone video snapshot we will have a huge reviewing problem as we need someone to watch the hole video and check it for copyright violations. GPSLeo (talk) 22:12, 6 March 2025 (UTC)
March 06
Non-confirmed users still allowed to use Upload Wizard?
I previously discussed how to implement the consensus disallowing any more local cross-wiki uploading into Commons. Somehow, I hadn't seen one reply, so the discussion was then archived without such.
Maybe I should've specified further as I'm doing now. Does Commons still allow non-confirmed users to use Upload Wizard, especially to upload files as "free"? (A previous proposal to restrict non-confirmed users from uploading videos and audio clips didn't go well. I'm starting this discussion cautiously before making any more proposals.) George Ho (talk) 22:06, 6 March 2025 (UTC)