Commons:Village pump/Technical

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

Shortcuts: COM:VP/T • COM:VPT

Welcome to the Village pump technical section
Technical discussion
Village pump/Technical
　Bug reports
　Code review
Tools
　Tools/Directory
　Idea Lab



This page is used for technical questions relating to the tools, gadgets, or other technical issues about Commons; it is distinguished from the main Village pump, which handles community-wide discussion of all kinds. The page may also be used to advertise significant discussions taking place elsewhere, such as on the talk page of a Commons policy. Recent sections with no replies for 30 days and sections tagged with {{Section resolved|1=--~~~~}} may be archived; for old discussions, see the archives; recent archives: /Archive/2024/03 /Archive/2024/04.

COMMONS DISCUSSION PAGES (index)
Please note
 

Start a new discussion

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

Cat-a-lot does not work for categories[edit]

There seems to be a technical problem with Help:Gadget-Cat-a-lot: when I click on Preferences, click on "Allow categorising pages (including categories) that are not files", then select one or more subcategories and try to move/copy/delete them to/from another category (like I always do), nothing happens but an endless "Editing page 1 of X". Moving files is no problem. Can this be fixed? JopkeB (talk) 11:05, 16 February 2024 (UTC)[reply]

I am not the only one having troubles, see Commons:Village pump#Cat-a-lot as well. JopkeB (talk) 13:27, 16 February 2024 (UTC)[reply]
Same for me: moving categories does not work, moving files works. --Reinhard Müller (talk) 14:49, 16 February 2024 (UTC)[reply]
I confirm that it is not working. Theklan (talk) 09:36, 24 February 2024 (UTC)[reply]
I can also confirm that it's not working for categories, although it will sometimes say that the category was moved.Smasongarrison (talk) 00:28, 27 February 2024 (UTC)[reply]
Note: If there is specific categories where problem can be replicated then please list them. (ie. fixing requires example cases) --Zache (talk) 15:58, 16 February 2024 (UTC)[reply]
I would like to copy a lot of subcategories in Category:Energy by type of energy to Category:Energy by topic‎ (all except for the 'by' categories). JopkeB (talk) 16:20, 16 February 2024 (UTC)[reply]
It was broken by a change to the HTML structure of the category pages, see phab:T355636#9553616. I hope it will be fixed by another change to the HTML structure, but if not, an interface admin should update the method getMarkedLabels() to account for the change. —Tacsipacsi (talk) 14:02, 18 February 2024 (UTC)[reply]
Same problem for me. I have posted this on MediaWiki talk:Gadget-Cat-a-lot.js but the only replies are people saying "Same problem for me". So nobody is actually looking after this? Cnbrb (talk) 23:19, 27 February 2024 (UTC)[reply]

For me moving categories was never possible with cat a lot. Always moved one by one.Paradise Chronicle (talk) 05:24, 14 March 2024 (UTC)[reply]

Help:Gadget-Cat-a-lot#Preferences. RZuo (talk) 06:31, 14 March 2024 (UTC)[reply]

 Question Is there any chance that we get an indication of:

  • What is the priority to solve this problem?
  • Whether someone is working on the solution of this problem?
  • How long it might take before it is solved?

--JopkeB (talk) 07:13, 5 April 2024 (UTC)[reply]

Tech News: 2024-11[edit]

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Changes later this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 12 March. It will be on non-Wikipedia wikis and some Wikipedias from 13 March. It will be on all wikis from 14 March (calendar). [1][2]
  • After consulting with various communities, the line height of the text on the Minerva skin will be increased to its previous value of 1.65. Different options for typography can also be set using the options in the menu, as needed. [3]
  • The active link color in Minerva will be changed to provide more consistency with our other platforms and best practices. [4]
  • Structured data on Commons will no longer ask whether you want to leave the page without saving. This will prevent the “information you’ve entered may not be saved” popups from appearing when no information have been entered. It will also make file pages on Commons load faster in certain cases. However, the popups will be hidden even if information has indeed been entered. If you accidentally close the page before saving the structured data you entered, that data will be lost. [5]

Future changes

  • All wikis will be read-only for a few minutes on March 20. This is planned at 14:00 UTC. More information will be published in Tech News and will also be posted on individual wikis in the coming weeks. [6][7]

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 23:02, 11 March 2024 (UTC)[reply]

TimedText select list loss[edit]

There is no Montenegrin language (crnogorski cnr) in select language list of TimedText pages. how to fix this? ITZQing (talk) 11:02, 12 March 2024 (UTC)[reply]

you need to write on phab:. you can make one for your language like phab:T354201. RZuo (talk) 12:55, 12 March 2024 (UTC)[reply]

Lossless crop assistance[edit]

File:MartzAction41A-1-.PNG has specific cropping instructions that I have never seen before with suggestion for lossless tools. I would like assistance in cropping this into 4:3 (630px wide) and/or 3:2 (560px wide) proportions using such a tool.-TonyTheTiger (talk) 11:16, 14 March 2024 (UTC)[reply]

That file is a png, so cropping with pretty much any tool is going to be lossless. I assume that is why the template limits its recommendations for lossless tools with the note "if cropping a JPEG...". —RP88 (talk) 11:22, 14 March 2024 (UTC)[reply]
I have extracted with Photo. What do I need to do regarding the metadata to follow the instructions?-TonyTheTiger (talk) 13:13, 14 March 2024 (UTC)[reply]
I think you've already done it. Since the "copy this file metadata" link is just an edit link for the source file, I am pretty sure the template just wants to make sure you copy the contents of the {{Information}} from the source file to the new file. One quibble I would have is that the request was to "Crop to show the woman with the ball" but your cropped file shows both women. I think the goal of the requestor is to have a image of just Jennifer Martz that can be used at d:Q6178597 where it is not ambiguous as to which of the two women in the original image is Jennifer Martz. —RP88 (talk) 13:38, 14 March 2024 (UTC)[reply]
User:RP88, Notice that my crop removed a front facing teammate of Martz'. I think that would be the more important secondary subject to worry about. I think considerations of the backward facing person are less relevant.-TonyTheTiger (talk) 00:04, 15 March 2024 (UTC)[reply]

Images from Commons not being shown on Facebook[edit]

Hello. About two weeks ago Facebook seemed to stop showing images from links to Commons files. I do not know if that problem has been discussed here, but it still persists. For those of us who regularly post links in Facebook groups it is a great inconvenience, also given that all the existing links stopped showing images. Facebook obviously thinks that there is something wrong with the setup of Wikimedia Commons, but it is impossible for a common user as I to ask them what is wrong. Does anybody at Wikimedia Commons know what has changed? Cheers Rsteen (talk) 03:48, 16 March 2024 (UTC)[reply]

This was phab:T359413 and has since been fixed. —TheDJ (talk • contribs) 21:57, 3 April 2024 (UTC)[reply]

Tech News: 2024-12[edit]

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Recent changes

  • The notice "Language links are at the top of the page" that appears in the Vector 2022 skin main menu has been removed now that users have learned the new location of the Language switcher. [8]
  • IP info feature displays data from Spur, an IP addresses database. Previously, the only data source for this feature was MaxMind. Now, IP info is more useful for patrollers. [9]
  • The Toolforge Grid Engine services have been shut down after the final migration process from Grid Engine to Kubernetes. [10][11][12]
  • Communities can now customize the default reasons for undeleting a page by creating MediaWiki:Undelete-comment-dropdown. [13]

Problems

  • RevisionSlider is an interface to interactively browse a page's history. Users in right-to-left languages reported RevisionSlider reacting wrong to mouse clicks. This should be fixed now. [14]

Changes later this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 19 March. It will be on non-Wikipedia wikis and some Wikipedias from 20 March. It will be on all wikis from 21 March (calendar). [15][16]
  • All wikis will be read-only for a few minutes on March 20. This is planned at 14:00 UTC. [17][18]

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 17:37, 18 March 2024 (UTC)[reply]

Logging usage of ajax quickdelete.[edit]

When using the speedy request in auditor, it generates a report in a log file, I was wondering how I could make a similar log for ajax quick delete CSD requests. Alachuckthebuck (talk) 20:15, 21 March 2024 (UTC)[reply]

"According to Exif data"[edit]

I have just discovered the According to Exif data and in the talk page, the user @Arnd had an interesting idea: to use a bot which will automatically add the EXIF data in the template. Would this be possible? Thanks, Erick Soares3 (talk) 20:12, 22 March 2024 (UTC)[reply]

I am running my bot from time to time to add missing dates to the template. To find the files i perform a search like insource:/According to Exif data *\}\}/. Would be nice to have a maintenance category for it. Regards, --Arnd 🇺🇦 (talk) 08:34, 23 March 2024 (UTC)[reply]

Image appears but doesn't appear although appear[edit]

Tarapaca Campaign.svg

In es:Guerra del Pacífico the image File:Tarapaca Campaign.svg doesn't appear but in es:Desembarco y combate de Pisagua the image appears. I guess it is some SVG irregularity in the SVG-Format of the image: the last thumbs in its common-history also doesn't appear. Does any one know the reason?. --Juan Villalobos (talk) 11:57, 23 March 2024 (UTC)[reply]

Sense of which shows is flipped? Guerra del Pacífico shows the image, but Desembarco y combate de Pisagua does not?
view-source:https://es.wikipedia.org/wiki/Desembarco_y_combate_de_Pisagua has
src="//upload.wikimedia.org/wikipedia/commons/thumb/d/d2/Tarapaca_Campaign.svg/300px-Tarapaca_Campaign.svg.png"
which should link to https://upload.wikimedia.org/wikipedia/commons/thumb/d/d2/Tarapaca_Campaign.svg/300px-Tarapaca_Campaign.svg.png
That image is good. ?action=purge of the es.Wiki page did not fix it.
Purging on the Commons file page kills the displayed main image (making it match the history thumbs).
Now the image does not display on Guerra del Pacifico.
Loading the PNG directly shows a server error.
At least everything is consistently broken.
Glrx (talk) 05:51, 24 March 2024 (UTC)[reply]
And now the PNG link displays and both es.Wiki articles display the image. Glrx (talk) 05:53, 24 March 2024 (UTC)[reply]
es:Guerra del Pacífico still doesn't display the image. --Juan Villalobos (talk) 07:33, 25 March 2024 (UTC)[reply]
It don't even see it on File:Tarapaca Campaign.svg. Clicking on some of the resolutions gives "Error
Our servers are currently under maintenance or experiencing a technical problem. Please try again in a few minutes.
See the error message at the bottom of this page for more information." Enhancing999 (talk) 09:03, 25 March 2024 (UTC)[reply]
At the bottom, among others "Error: 429, Too Many Requests at Mon, 25 Mar 2024". Enhancing999 (talk) 09:03, 25 March 2024 (UTC)[reply]
Does not show for me on File page or es:Guerra.
File page fail: 
Request URL: https://commons.wikimedia.org/wiki/File:Tarapaca_Campaign.svg
Request Method: GET
Status Code: 304 Not Modified

Age: 0
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
Date: Mon, 25 Mar 2024 15:09:26 GMT
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Nel: { "report_to": "wm_nel", "max_age": 604800, "failure_fraction": 0.05, "success_fraction": 0.0}
Report-To: { "group": "wm_nel", "max_age": 604800, "endpoints": [{ "url": "https://intake-logging.wikimedia.org/v1/events?stream=w3c.reportingapi.network_error&schema_uri=/w3c/reportingapi/network_error/1.0.0" }] }
Server: ATS/9.1.4
Server-Timing: cache;desc="pass", host;desc="cp1100"
Set-Cookie: NetworkProbeLimit=0.001;Path=/;Secure;Max-Age=3600
Strict-Transport-Security: max-age=106384710; includeSubDomains; preload
Vary: Accept-Encoding,Cookie,Authorization
X-Cache: cp1100 miss, cp1100 pass
X-Cache-Status: pass
On reload, File page succeeds 
Request URL: https://commons.wikimedia.org/wiki/File:Tarapaca_Campaign.svg
Request Method: GET
Status Code: 304 Not Modified
Remote Address: 208.80.154.224:443
Referrer Policy: origin-when-cross-origin

Accept-Ch:
Age: 0
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
Content-Encoding: gzip
Content-Language: en
Content-Type: text/html; charset=UTF-8
Date: Mon, 25 Mar 2024 15:16:03 GMT
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Last-Modified: Mon, 25 Mar 2024 15:03:33 GMT
Nel: { "report_to": "wm_nel", "max_age": 604800, "failure_fraction": 0.05, "success_fraction": 0.0}
Report-To: { "group": "wm_nel", "max_age": 604800, "endpoints": [{ "url": "https://intake-logging.wikimedia.org/v1/events?stream=w3c.reportingapi.network_error&schema_uri=/w3c/reportingapi/network_error/1.0.0" }] }
Server: mw1435.eqiad.wmnet
Server-Timing: cache;desc="pass", host;desc="cp4041"
Set-Cookie: NetworkProbeLimit=0.001;Path=/;Secure;Max-Age=3600
Strict-Transport-Security: max-age=106384710; includeSubDomains; preload
Vary: Accept-Encoding,Cookie,Authorization
X-Cache: cp4041 miss, cp4041 pass
X-Cache-Status: pass
Server ATS/9.1.4 fails but server mw1435.eqiad.wmnet succeeds.
Glrx (talk) 15:26, 25 March 2024 (UTC)[reply]

Sorry, I don't get any server error or even an error message. Simply the image doesn't appear in es:Guerra del Pacífico but it appears in other articles. --Juan Villalobos (talk) 16:06, 25 March 2024 (UTC)[reply]

It's only visible when clicking on some of the links on the file description page at "Other resolutions: 162 × 240 pixels | 323 × 480 pixels | 518 × 768 pixels | 690 × 1,024 pixels | 1,380 × 2,048 pixels | 875 × 1,298 pixels."
In the meantime, on File:Tarapaca Campaign.svg it's back, but not on the "other resolutions". I wonder how many requests it takes to trigger "Too Many Requests". Enhancing999 (talk) 16:32, 25 March 2024 (UTC)[reply]
I just made several different size requests, and all returned good images. All but one were served by Thumbor/7.3.2.
If I load a failing image 
Request URL: https://upload.wikimedia.org/wikipedia/commons/thumb/d/d2/Tarapaca_Campaign.svg/81px-Tarapaca_Campaign.svg.png?20181213201810
Request Method: GET
Status Code: 429 Too Many Requests
Remote Address: 198.35.26.112:443
Referrer Policy: origin-when-cross-origin

Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Age, Date, Content-Length, Content-Range, X-Content-Duration, X-Cache
Content-Length: 1820
Content-Type: text/html; charset=utf-8
Date: Mon, 25 Mar 2024 17:29:25 GMT
Nel: { "report_to": "wm_nel", "max_age": 604800, "failure_fraction": 0.05, "success_fraction": 0.0}
Report-To: { "group": "wm_nel", "max_age": 604800, "endpoints": [{ "url": "https://intake-logging.wikimedia.org/v1/events?stream=w3c.reportingapi.network_error&schema_uri=/w3c/reportingapi/network_error/1.0.0" }] }
Server: Varnish
Server-Timing: cache;desc="int-front", host;desc="cp4049"
Strict-Transport-Security: max-age=106384710; includeSubDomains; preload
Timing-Allow-Origin: *
X-Cache: cp4049 int
X-Cache-Status: int-front
This response looks to be a cached error message from Varnish. Refreshing does not update. Using another browser does not update.
Glrx (talk) 17:38, 25 March 2024 (UTC)[reply]

Sorry, problem is still there. Can you resolve it?. --Juan Villalobos (talk) 08:37, 27 March 2024 (UTC)[reply]

W3C reports 2 errors. Namespace http://www.openswatchbook.org/uri/2009/osb not on whitelist. Used in linearGradient6213 and linearGradient4061. Both are single-stop gradients. Both gradients are unused. Nuked.
File has more than usual Inkscape verbiage. There are a lot of style="...;line-height=0%;...". There are empty g elements.
Still does not display.
Glrx (talk) 18:30, 27 March 2024 (UTC)[reply]

Interwikilinks to german wikipedia with no corresponding german article[edit]

I have found about 2000 pages here in commons with a interwikilink to german wikipedia, but the page does not exist. Examples:

Now the question is: What to do? Ignore? Fix?
I have a Bot in deWP and 7 years experience with this bot, but no idea with the bot policy here. --Wurgl (talk) 17:55, 24 March 2024 (UTC)[reply]

Some of the pages have links added manually they could and should be cleaned up by a bot. But at Category:Adoxaceae in Naturschutzgebiet "St. Arnualer Wiesen" there seems to be a bug presumable in the infobox resulting in the incorrect link. GPSLeo (talk) 19:56, 24 March 2024 (UTC)[reply]
@GPSLeo: Category:Adoxaceae in Naturschutzgebiet "St. Arnualer Wiesen" is getting its missing article link [[de:Adoxaceae in Naturschutzgebiet "St. Arnualer Wiesen"]] added by the [[de:{{PAGENAME}}]] code in {{Districts of Saarbrücken}} that is called by the {{Districts of Saarbrücken Navi}} template on the category page. Author appears to be AnRo0002. Maybe they can offer some insight. —RP88 (talk) 20:27, 24 March 2024 (UTC)[reply]
As I said: About 2000 affected pages for deWP, these 5 are just random examples. (I did not check any other language) --Wurgl (talk) 21:00, 24 March 2024 (UTC)[reply]
Right, but {{Districts of Saarbrücken Navi}} is used on 1586 categories and is the source for 2 of the 5 categories that you chose at random. It might be the cause of a big fraction of the 2000 affected pages that you identified. Commons bot policy is fairly permissive. You can read the policy at Commons:Bots and post at Commons:Bots/Requests if you want permission to run your bot on Commons. It might take a while to get approval, the Bot request board moves slowly. —RP88 (talk) 22:12, 24 March 2024 (UTC)[reply]
Thanks for pointing it out. If you are interested and patient enough to run your bot through this issue on commons, this would be great. Paradise Chronicle (talk) 18:36, 27 March 2024 (UTC)[reply]
FYI: Diff from my bot: https://persondata.toolforge.org/data/common_diff.txt (if you know Unix/Linux "diff -c", it is similar, just very long lines are cut)
There are a 10 lines with "did not match" where that bad link is created magically by some template.
7 cases (use search pattern " ---") seem to by mistyped links to deWP, maybe these could be fixed manually, currently the bot transforms these links into plain text. --Wurgl (talk) 20:22, 9 April 2024 (UTC)[reply]
Thanks for uploading a log of the results, although it is hard to validate the proposed edits since the bot did not log the names of the pages to which the proposed edits applied. From what I am able to ascertain the results are probably OK — it is nice to see that fixing {{Districts of Saarbrücken Navi}} cut the number of pages that needed a fix down to around 500. I would recommend that in the cases where the bot detects what are possibly mistyped links that it not transform them into plain text, it should instead leave them alone (although I certainly wouldn't object to you fixing them manually, should you choose to do so). The suggested edits might also be adding extraneous blank lines, but I couldn't verify that without knowing the pages to which the proposed edits applied. —RP88 (talk) 20:39, 9 April 2024 (UTC)[reply]
Oops. Sorry. I run it again. For the mentioned possible typos, I have code (currently commented out) which changes [[de:article to [[:de:article --Wurgl (talk) 21:07, 9 April 2024 (UTC)[reply]
I've taken a look at your new log. For an example of an edit where the bot should not convert an interwiki link to plain text, see the proposed edit to Category:Coordinates_templates. The bot is proposing to convert {{Category redirect|Commons geocoding}}[[de:Kategorie:Vorlage mit Koordinate]] to {{Category redirect|Commons geocoding}}Kategorie:Vorlage mit Koordinate. The ideal change would be to fix the interwiki to the correct interwiki of [[de:Kategorie:Vorlage:mit Koordinate]]. Since the bot isn't able to make that fix, it should leave the original incorrect interwiki alone, not convert it to plain text. For an example of an edit where the bot is inserting an extraneous blank line, see the proposed edit to Category:Alejandro_Barberón. The bot proposes to add a blank line in the middle of a list of interwiki links. —RP88 (talk) 21:25, 9 April 2024 (UTC)[reply]
I really should not do such tasks in the late evening. I hope it is fixed now. Sorry. Those mentioned 7 cases need manual fixes, they are a little bit to different. --Wurgl (talk) 22:03, 9 April 2024 (UTC)[reply]
@Wurgl: Sorry, I had to step away for a couple of hours. I've looked at your latest log. I noticed the following issues, but I am not sure if they are problems:
  1. Something weird, maybe due to trailing spaces at the end of line, appears to be happening at Category:Riaboshenko,_Anatoli.
  2. It's probably unnecessary, and very nit-picky, but it would be nice that when there is a blank line before and after an interwiki link that ends up being removed, that the two blank lines that are now adjacent be converted into a single blank line. Examples are at Category:Verlegung_Stolperstein_Albert_Richter and gallery Buchholz-Orgel_Stralsund.
  3. There are some blocks of text in the middle of the log that seems to indicate a problem occurred, but not does not appear to be associated with the immediately preceding or following page in the log. Here are three samples, but there are many more:
    • File: Category:1878 in fil/m Pattern @(.\[\[ *)([dD]e *:+ *(Filmjahr[_ ]1878) *(#[^|\]]*)?(\|[^\]]*)?\]\])@s did not match
    • File: Category:Grave of Ludwig Zatzka Pattern @(.\[\[ *)([dD]e *:+ *(Gruppe[_ ]17[_ ]Nummer[_ ]30;[_ ]Mosaik[_ ]Leopold[_ ]Forstner) *(#[^|\]]*)?(\|[^\]]*)?\]\])@s did not match
    • File: Category:Photos by User:Johann56 Pattern @(.\[\[ *)([dD]e *:+ *(Photos[_ ]by[_ ]User\:Johann56) *(#[^|\]]*)?(\|[^\]]*)?\]\])@s did not match
—RP88 (talk) 00:37, 10 April 2024 (UTC)[reply]

Tech News: 2024-13[edit]

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Recent changes

  • An update was made on March 18th 2024 to how various projects load site, user JavaScript and CSS in Vector 2022 skin. A checklist is provided for site admins to follow.

Changes later this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 26 March. It will be on non-Wikipedia wikis and some Wikipedias from 27 March. It will be on all wikis from 28 March (calendar). [19][20]

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 18:53, 25 March 2024 (UTC)[reply]

Bot for archiving closed cfd requests[edit]

https://commons.wikimedia.org/w/index.php?title=Special%3AContributions&target=SteinsplitterBot&namespace=4&wpfilters%5B%5D=associated&tagfilter=&start=&end=2023-12-07&limit=100

SteinsplitterBot (talk · contribs) used to take care of this, but it last archived cfd on 6 dec 2023, so we need a new bot for this task. RZuo (talk) 22:38, 25 March 2024 (UTC)[reply]

@RZuo I just fixed SteinsplitterBot. It looks like when they did the migration to the new jobs system they forgot to migrate this one. But it should be working now, and will run daily in the future. Feel free to ping me if it stops, or if you notice any other issues with SteinsplitterBot (I have full access to the tool.) —‍Mdaniels5757 (talk • contribs) 23:15, 25 March 2024 (UTC)[reply]
@Mdaniels5757: If you have access to SteinsplitterBot, do you know why it stopped updating Commons:Database reports/Getty Images a few months back? Is there any assistance I could provide to you towards getting this SteinsplitterBot job fixed or restarted? —RP88 (talk) 23:02, 28 March 2024 (UTC)[reply]
Looking into this. —‍Mdaniels5757 (talk • contribs) 22:38, 4 April 2024 (UTC)[reply]
@RP88 Fixed (it was a combination of the same issue and a broken dependency). —‍Mdaniels5757 (talk • contribs) 00:54, 5 April 2024 (UTC)[reply]
@Mdaniels5757: Thanks very much! I appreciate you taking the time to investigate and fix the issue. —RP88 (talk) 02:34, 5 April 2024 (UTC)[reply]

rulers[edit]

anyone have a handy userscript or gadget to add rulers around the main image on file namespace pages? of particular interest to me would be percent rulers, for aiding the addition of COM:SDC relative position within image (P2677) statements. Arlo James Barnes 00:24, 31 March 2024 (UTC)[reply]

Table of contents[edit]

Can someone figure out why {{CategoryTOC}} doesn't work on this page: Category:EC-Audiovisual_Center_review_needed, and fix it. Thank you! // sikander { talk } 🦖 17:57, 1 April 2024 (UTC)[reply]

@Sikander: As far as I can tell, the horizontal Category TOC on that page is working fine. I tried several different browsers as well as both logged in and logged out. I suspect the issue is at your end, perhaps try emptying your browser cache. —RP88 (talk) 18:03, 1 April 2024 (UTC)[reply]
It looks for subcategories, but you want files: try Template:FileCategoryTOC. Enhancing999 (talk) 18:04, 1 April 2024 (UTC)[reply]
Actually, no. It's just that they are all sorted under "0-9". Enhancing999 (talk) 18:08, 1 April 2024 (UTC)[reply]
Sort through Template:LicenseReview/layout-reviewme is by pageid. Enhancing999 (talk) 18:15, 1 April 2024 (UTC)[reply]
Ah, seeing Enhancing999's replies led me to think what you might have meant by "doesn't work". In my reply I was saying that I saw {{CategoryTOC}} correctly displaying and working exactly as intended (but apparently not how you probably expected). As Enhancing999 implied, the template {{EC-Audiovisual Center}} invokes {{LicenseReview}}, which (while in the needs review state) uses Template:LicenseReview/layout-reviewme, which sets [[Category:EC-Audiovisual Center review needed|< PAGEID >]]. So the files in this particular category are sorted by their page id, like all other license review needed categories. —RP88 (talk) 18:43, 1 April 2024 (UTC)[reply]
@RP88 and Enhancing999: Ah, sorry for creating some confusion here. My intention is to navigate the contents of Category:EC-Audiovisual_Center_review_needed category by file name and thought {{CategoryTOC}} would work. {{FileCategoryTOC}} is also not doing what I thought it would. Any other suggestions? Thank you. // sikander { talk } 🦖 19:30, 1 April 2024 (UTC)[reply]
Hmm... depending on what exactly you want to do, you might be able to use Special:Search with incategory:"EC-Audiovisual Center review needed" and then adjust the advanced search fields. This won't get you an alphabetically ordered list, but it would let you search the contents of the category. —RP88 (talk) 20:13, 1 April 2024 (UTC)[reply]
Template:LRCategoryTOC has some logic for this type of category. Enhancing999 (talk) 21:13, 1 April 2024 (UTC)[reply]

Tech News: 2024-14[edit]

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Recent changes

  • Users of the reading accessibility beta feature will notice that the default line height for the standard and large text options has changed. [21]

Changes later this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 2 April. It will be on non-Wikipedia wikis and some Wikipedias from 3 April. It will be on all wikis from 4 April (calendar). [22][23]

Future changes

  • The Wikimedia Foundation has an annual plan. The annual plan decides what the Wikimedia Foundation will work on. You can now read the draft key results for the Product and Technology department. They are suggestions for what results the Foundation wants from big technical changes from July 2024 to June 2025. You can comment on the talk page.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 03:33, 2 April 2024 (UTC)[reply]

why does the time scale end in the 49th century BC?[edit]

compare for example Romania in the 35th century BC to Romania in the 54th century BC. I couldn'd find out the lack. anro (talk) 21:18, 2 April 2024 (UTC)[reply]

On an immediate level, that's because the {{Subject by century}} template (which is used to implement templates like {{Centuries BC in Romania}}) only runs from the 50th century BC to the 25th century CE. It will not display categories which lie outside those bounds.
Realistically, the use of year-based categories for time periods well outside recorded history like "49th century BC" may not be appropriate, as the margin of error on dates that far back is often wider than a century. (Nor am I convinced that it's correct to describe subjects like the Turdaș culture as being "in Romania" over five thousand years before any such country existed.) Omphalographer (talk) 00:02, 4 April 2024 (UTC)[reply]

Mobile versions of user talk pages are useless[edit]

Though I'm not active on Commons, I got bored and used my mobile device to look through some deletion requests, then at at a user's talk page. I knew that user had several deletion requests, but saw only one on their talk page. The talk page's history showed that old sections were archived, which was fine, but the page seemed to have no links to those archives.

I couldn't find the 'Read as wiki page' (or whatever it is) option, so out of desperation, I switched to the desktop version of the page. I was shocked at what I found there: not only the archive links, but also a notice that the user had been blocked indefinitely. (Before that, I hadn't seen any reference to a block.)

In summary, the mobile versions of user talk pages (and perhaps talk pages in general) are so crippled as to be useless. Brianjd (talk) 08:22, 4 April 2024 (UTC)[reply]

Yes, the mobile experience has always been really bad and as someone who basically exclusively edits with a mobile device it's not a fun experience. The worst part is that in most of the developing world the vast majority of people who surf the web do so using a mobile device. Not too long ago the experience of talk pages on mobile devices wasn't this bad, but they basically made it worse during an update a few months ago. After many, many years of neglecting the mobile experience I sincerely doubt that the developers are planning on fixing it anytime soon. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 10:47, 9 April 2024 (UTC)[reply]

Viewer to highlight topic on annotated files in category (sample: mountain panoramas)[edit]

Category:Plattenhörner (Vereina) has several photos with the two summits "Plattenhörner" annotated. I think it could be interesting to have a viewer that allows to view that annotated on all files at once, ideally with larger versions of the photos. @Kuhni74 fyi. Enhancing999 (talk) 09:15, 7 April 2024 (UTC)[reply]

Is there any way to get a list of users who uploaded images which appear in a Commons category?[edit]

Hi all

I'm working on some documentation around organising photography events and competitions and would really like to find a way to do this e.g I want to get a list of all the user names of uploaders for all the images in the category and all subcategories for Category:Potatoes. It would be a way to understand who is interested in the topic. I have a feeling this info might also be really useful for people who run the Wiki Loves photo competitions as well e.g 'this many people took part this year' although they may have other ways to do this.

Any suggestions would be really appreciated.

Thanks very much

John Cummings (talk) 09:16, 8 April 2024 (UTC)[reply]

Tech News: 2024-15[edit]

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Recent changes

  • Web browsers can use tools called extensions. There is now a Chrome extension called Citation Needed which you can use to see if an online statement is supported by a Wikipedia article. This is a small experiment to see if Wikipedia can be used this way. Because it is a small experiment, it can only be used in Chrome in English.
  • A new Edit Recovery feature has been added to all wikis, available as a user preference. Once you enable it, your in-progress edits will be stored in your web browser, and if you accidentally close an editing window or your browser or computer crashes, you will be prompted to recover the unpublished text. Please leave any feedback on the project talk page. This was the #8 wish in the 2023 Community Wishlist Survey.
  • Initial results of Edit check experiments have been published. Edit Check is now deployed as a default feature at the wikis that tested it. Let us know if you want your wiki to be part of the next deployment of Edit check. [24][25]
  • Readers using the Minerva skin on mobile will notice there has been an improvement in the line height across all typography settings. [26]

Changes later this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 9 April. It will be on non-Wikipedia wikis and some Wikipedias from 10 April. It will be on all wikis from 11 April (calendar). [27][28]
  • New accounts and logged-out users will get the visual editor as their default editor on mobile. This deployment is made at all wikis except for the English Wikipedia. [29]

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 23:34, 8 April 2024 (UTC)[reply]

New tool for detecting logos[edit]

Hi all! As you already probably know, the Structured Content team is working this year on improving the current user experience with UploadWizard. We already have done some work on the “release rights” step, and we recently concluded a community discussion about the “describe” step. We are currently integrating the feedback received from you into our workflow.

Another thing we are working on is a potential improvement to automatically detect logos when uploaded on Commons through UploadWizard, in order to facilitate their evaluation by the community. A need for machine detection tools was raised in several discussions and user interviews we had in the past with the community, and logos are the second reason for media deletion after Freedom of Panorama, so we decided to work in that direction.

The tool we developed has shown promising results (accuracy is ~96%); in case you’re interested, you can see a brief summary of an evaluation of a sample batch of images. Our intention is for you to discuss and then, if consensus is reached, to integrate the tool in UploadWizard, in a way that would be beneficial for moderation workflow.

We would love to have your input. Do you think this tool could be useful? Do you think this tool could be integrated in UploadWizard, and then integrated in your moderation workflow? Sannita (WMF) (talk) 10:18, 9 April 2024 (UTC)[reply]

Maybe you could run it through the "icons" category to test. Enhancing999 (talk) 10:53, 9 April 2024 (UTC)[reply]
If integrated into the MediaWiki Upload Wizard, how would it work? Would it prevent the uploading of a PD-textlogo or would it detect if an incompatible license or attribution is present? Or would it simply add them to a daily page for community evaluation, akin to "User:Minorax/PD textlogo/2020 June 6"? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:03, 9 April 2024 (UTC)[reply]
@Donald Trung This is actually something that we wanted to discuss with the community. The tool, as of now, only recognises logos with a very high accuracy, but we want to ask the community what to do next. We are open to suggestions. Sannita (WMF) (talk) 11:17, 9 April 2024 (UTC)[reply]
Sannita, I think that it might be wise to index all logos by date of upload on a single page and have the tool also detect the licenses, and then add these into sections like "Logos with Creative Commons licenses tagged as Own work", "Logos with public domain licenses", "Logos with Creative Commons licenses attributed to an external source". That way we can easily go through each type of upload, a lot of (new) users upload free logos as "Own work" with wrong licenses, these are the most problematic, but those uploaded with external links and / or specific licenses tend to be less problematic, so we would immediately know which areas to focus on, but still evaluate the other logos. For example, a very complex logo shouldn't be in "PD-textlogo" and can be deleted if not found to have a free license, which would also be easily detected using such a system. -- — Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:26, 9 April 2024 (UTC)[reply]
For clarification "I think that it might be wise to index all logos by date of upload on a single page and have the tool also detect the licenses" would be a page like "Commons:Image detection/Logos/2024/November/12", I deliberately made logos as a sub-category of image detection because of the suggestions below by user "Adamant1" to also add this for postcards. I think that a tool like this could supersede the groups based on category done by the OgreBot today in the future. The page "Commons:Image detection" could be a central hub where reviewers (in the broadest sense) can use the AI-powered tool to find and detect logos. Heck, maybe in the distant future it can also detect images based on freedom of panorama (exterior images) and many other categories. Logos is a good start, though we should make sure that we don't discourage people from uploading, we should simply make it easier to detect possible copyright ©️ violations. We also used to have a page for uploads by new users, but I am not sure if we still have that (I think that I read somewhere that an update to the MediaWiki software made it difficult to maintain), perhaps the "Image detection" page can also have a sub-category for new users as well.
Heck, maybe we can even use this tool retroactively to group images together on a page like "Commons:Image detection/Logos/2012/December/8" and have like a button that trusted users can press to mark an image on that page as "patrolled" independent from the current solution we have. There are many ways that such a tool could be implemented, however, I sincerely hope that it won't be included before an image is published, as we could be missing out of valuable uploads because a new user (or a Wikipedian not familiar with this website) would be scared off by a warning message. -- — Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 13:21, 9 April 2024 (UTC)[reply]
My own humble suggestion is to disable and dismantle this whole thing, and rather redirect WMF’s funding and priorities to actually useful things requested by the community — like, say, fixing the 10 year old bugs that still plague the unified login process.
I have nothing against some random AI outfit making use of Commons’s publicly available data to “train” their GIGO machines: Good luck with that. But WMF funding should not be used for this sort of useless, misleading, hyped-up nonsensical makework.
And I know that this suggestion will never be given any attention, but that’s how it goes. -- Tuválkin ✉ ✇ 01:14, 10 April 2024 (UTC)[reply]
@Tuvalkin, I'm not sure I'd have ranked it as the top priority (just since the old wizard wasn't especially bad), but I do think that improving the wizard is a reasonable place to focus. We're a media repository, which makes the process for uploading media a pretty essential function. We lose an untold number of contributions (Sannita, do you have any data?) from people who aren't able to go through it successfully, and it's the first line of defense to prevent/fix problematic contributions (which reduces moderation work later). Sdkb talk 04:48, 10 April 2024 (UTC)[reply]
Oh, I don’t think the upload wizzard should exist, at all. So there’s that. (Before you ask, I use Special:Upload or external tools, like Vicuña and Commonist.) I agree that uploading media a pretty essential function — therefore gamified uploads from clueless jokers should be discouraged. You however both bemoan those lost uploaders (can it be lost, that which never existed?…) and also call for a better ratmaze to make sure their “work” is not too deterimental to Commons, in terms of scope and copyright blunders.
At the same time many of the same people who cheer for this sort of continued addition of even more bells and whistles to the upload process, supposedly to avoid that loss of untold poor dears, are the same who constantly decry mass uploads, and who are happy to dance on the grave of the most prolific uploader (both quantity and quality) Commons ever had.
So, basicly not impressed. Wont help the Upload Wizzard this adding to the loop of an opaque step which likely takes pre-published media files away from WMF purview off to some blackbox; the environmental impact of the additional computing resources needed — that’s a cherry on top. (Remings me of: Hop on a jet plane to join all the WMF cronies for needless face-to-face meetings: The cafeteria is 100% vegan because environment, dontcha know?)
To clarify: In my opinion, one-off uploads, especially by editors creating articles in other projects, should be allowed into Commons via a pipeline that’s not the same of mass or “expert” uploading — I presume the Visual Editor has such a function (never used it — unsurprisingly, I think it’s also nonsense). However, it’s not helping this the training of an A.I. (and I’m all out of irony quote marks at this point) who will nag Clippy-style said unexperienced uploader, muddling the process even more. Especially since it will, most of the time, be confusing for logos all kinds of icons, diagrams, maps, flags, and traffic signs.
Was I the only one who shook their head and palmed their face at the apparent fact that the control group for this A.I. training was the contents of Category:Logos, with depth=0…? Yes, that one garbage-bag category where end up stuck all the poorly categorized logos, including, more than any deeper subcat, miscurated images which are anything but logos! Just wow — the more I think of this, the worse it looks like.
But you’re right that this sort of nonsense is (also) «requested by the community». Sad…!
-- Tuválkin ✉ ✇ 06:39, 10 April 2024 (UTC)[reply]
This looks like a super cool tool. I was just wishing there was something similar for detecting images of postcards. I have to agree with Donald Trung that it's probably better to use an indexer of exiting files instead of being directly integrated into UploadWizard. I imagine things like this are going to be the future of detecting and organizing specific types of images anyway and I doubt every use case going forward could be integrated into UploadWizard, but a hub for different types of detected images going forward would be great, starting out with logos and then integrating it with other types in the future. I don't think turning UploadWizard into a metaphorical Swiss Army knife of image detection at the point of upload would really be practical or useful though. From what I've seen most people are usually turned off by that sort of thing. Especially new users. UploadWizard is hard enough to understand and work with as it is already. --Adamant1 (talk) 12:57, 9 April 2024 (UTC)[reply]
This seems like a really useful tool! As far as integration into the Upload Wizard, we could use it to customize the user experience. For instance, there could be a dialogue "This looks like a logo. Is that correct? [Yes] [No]". [Yes] would autocategorize the image and lead to follow-up steps trying to confirm the copyright (e.g. directing them to COM:RELGEN if they claim it's their own work), and [No] would apply a hidden category or add it to a feed of reported false positives. Sdkb talk 16:29, 9 April 2024 (UTC)[reply]
Very nice! The model seems to detect reliable for graphics vs. random photos. Let me suggest some curveballs, from the type of images I often encounter: How does it perform when you include Flags and CoAs into the mixup? Uploads of those categories are also often deleted, but less often than logos. Another test could include Map details (i.e. cutouts) which are usually not deleted.
Also, what would this tool actually do after the detection? Bring the positives into a dedicated (hidden) category for users to evaluate? Yes, I could really see a use in that, for quicker processing of uncategorized uploads. --Enyavar (talk) 12:19, 9 April 2024 (UTC)[reply]
@Enyavar Thanks for your opinion. For now, we limited ourselves to logos because they were easier to detect, but if there is consensus for it, we can expand our work to other kinds of images.
About what the tool can actually do... that's the point of the discussion. We have suggestions to make, but we want to hear from you first, not to influence the discussion. The dedicated category/tag was actually one of the suggestions that we had, to be fair. But we'll take note of this suggestion, thanks! Sannita (WMF) (talk) 14:12, 9 April 2024 (UTC)[reply]
Ah, sorry, I meant something else with my first comment: can the tool reliably detect logos in the presence of these other (similar looking) images? What are the percentages for examples A, B, C, D, E or possibly F, G, H? It won't be totally bad if these get detected as logos with a certainty of 90%+... I'm just curious whether or not files from these categories have a higher false positive rate for the current tool. --Enyavar (talk) 15:08, 9 April 2024 (UTC)[reply]
Good idea, to test on coats of arms, flags and maps in addition to icons I mentioned above.
Wonder if the training set was useful: Commons mainly has simple logos for which it doesn't actually matter that they are also logos. Enhancing999 (talk) 20:04, 9 April 2024 (UTC)[reply]
This doesn't seem un-useful, but I am a bit skeptical that it will move the needle much in terms of checking logos for copyvio/spam. There is already an overwhelming backlog of this stuff -- 118,798 files in Category:Unidentified logos alone. The most likely outcome is another backlog. Gnomingstuff (talk) 20:42, 9 April 2024 (UTC)[reply]
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Technical&oldid=867167557"