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]

the solution would be to revert phab:T355636. Can someone do that? Enhancing999 (talk) 15:25, 17 April 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]
Thanks for the info. I can see that the phab was assigned on March 6, so it would have been nice to get an answer at an earlier date from one of those involved with the phab. Cheers Rsteen (talk) 03:22, 12 April 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]
I have rewritten parts of the code, should be better now.
There are a few of those links which I do not understand where they come from, however these links are in the database, see: quarry:query/81908 I tried a null-edit and a purge in Category:Dietersdorf_bei_Fürstenfeld but it did not help, in d:Q72607475 I do not see this magic "Wikipedia:WikiProjekt Österreich/HF/Dietersdorf" … no idea? --Wurgl (talk) 14:52, 10 April 2024 (UTC)[reply]
Well, at Category:Dietersdorf_bei_Fürstenfeld where the interwiki points to de:Dietersdorf bei Fürstenfeld but Quarry says it points to de:Wikipedia:WikiProjekt_Österreich/HF/Dietersdorf_bei_Fürstenfeld is due to the move of that page earlier today, the corresponding edit to d:Q72607475, and the fact that your query at Quarry ran on a database (commons uses s4) with a replication lag that is currently 25 hours. I fixed 数字手势 earlier today, but the fix is still in the replication lag window. Hopefully both of these should be fixed in Quarry in several hours. The broken "Filmjahr <year>" interwiki links are coming from {{Filmcat}}. The broken "Road to Le Mans <year>" interwiki links are coming from {{RtLMyear}}. —RP88 (talk) 20:41, 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). [1][2]

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. [3]

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). [4][5]

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]
should mobile view on Commons be deactivated? Enhancing999 (talk) 15:18, 17 April 2024 (UTC)[reply]
That might go to far, to be honest, the best solution would be to make the mobile version identical to the desktop version but tailored for smaller screens, though the Wikimedia Foundation (WMF) have confirmed multiple times that they will not do that. I have no idea why they insist on delivering an inferior and often infuriating experience to us mobile users, but there doesn't seem to be much we can do about it. De-activating it would break more than it would fix. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 15:44, 17 April 2024 (UTC)[reply]
I wonder what there is to break. Consider file description pages: mobile version lacks have of the content (categories).
I think the skin running on each WMF site is determined by the communities. Accordingly, e.g. dewiki doesn't use the same as enwiki, as they consider it not suitable. Enhancing999 (talk) 15:49, 17 April 2024 (UTC)[reply]
@Enhancing999 If you login in mobile view, select settings from top right menu and then toggle Advanced mode to be enabled then the categories are visible. --Zache (talk) 17:37, 17 April 2024 (UTC)[reply]
I don't think it's available without login. We could keep the default mobile view from logged in users who require it (e.g. WMF staff for testing purposes). Enhancing999 (talk) 18:14, 17 April 2024 (UTC)[reply]
Yes, this "solution" only works if you have a Wikimedia SUL account and happen to know where to find the button to enable it. Imagine you're a re-user looking for similar images (or other files) from a certain category and can't figure out how to do that. Most people surf the web on mobile devices these days, this is especially true for people from developing countries. When I was in the rural Philippines a few weeks ago I met several people who have never worked with or used a laptop or desktop computer in their lives but all use smartphones, even homeless people have smartphones, these are the most affordable internet-connected devices for most people in the world. Yet, for whatever reason "the mobile experience" of Wikimedia websites is beyond bad. If possible we should put it to a vote to show the MediaWiki developers that we don't want to suppress vital information for a major part of the audience. Files are for re-users and if they can't find the files then there's something seriously wrong with the system. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 18:34, 17 April 2024 (UTC)[reply]
I have been impression that "advanced mode" is for things in beta testing, not ready for primetime, for whatever reason. We could though ask what are plans to primetime it. --Zache (talk) 18:40, 17 April 2024 (UTC)[reply]
In mobile view parent categories aren't even visible. How useful can that be? Enhancing999 (talk) 19:34, 17 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]

@John Cummings: It’s possible using the API: query+imageinfo can be used to get uploaders from a given category (but not subcategories), and query+categorymembers can be used to get the direct subcategories of a category. I don’t know about any ready-to-use user-friendly solutions. —Tacsipacsi (talk) 19:33, 14 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. [6][7]
  • Readers using the Minerva skin on mobile will notice there has been an improvement in the line height across all typography settings. [8]

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). [9][10]
  • 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. [11]

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]
Re training using a depth of 0, oof — Sannita, you all should rethink that.
Re your braoder point, you seem to be pursuing a world in which it's far harder for newcomers to contribute to Wikimedia. That's a world in which our projects have more systemic bias and less overall content, which is not what I'd want. Sdkb talk 14:17, 10 April 2024 (UTC)[reply]
@Tuválkin: thanks for your comments. Logo samples in the evaluation dataset were collected via a PetScan query with a category depth > 0. I'm sorry I couldn't retrieve the exact depth from that query.
Cheers, MFossati (WMF) (talk) 16:55, 11 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]
Hi @Enyavar and Enhancing999: {{u}} here, I'm the main technical point of contact behind this effort. Thanks for your feedback, very useful and appreciated! Here are the probability scores of the images you mentioned:
  • A = 77.82 %
  • B = 48.96 %
  • C = 88.9 %
  • D = 97.9 %
  • E = 99.87 %
  • F = 0.45 %
  • G = 0.36 %
  • H = 43.29 %
A few observations:
  • all scores but D and E seem low enough to be cut out;
  • as a human, I'd consider D and E as logos if I didn't know what coat of arms are. The model was indeed trained on logos and non-logos, so it hasn't got any notion of coat of arms;
  • probability threshold selection will be crucial to tune the amount of what we’d like to consider as true positives.
Anyway, I definitely think that your suggestions make a lot of sense: testing the robustness of the model against visually similar inputs is now in my to-do list.
Cheers, MFossati (WMF) (talk) 11:03, 10 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]
What would probably make it a lot more useful is if it was used for flow control in the upload wizard. If an image is detected as a logo and the user confirms that it's a logo, that could eventually shunt the user into a workflow that asks them for logo-specific information, e.g. "what does this logo stand for", "where did you find this logo", etc. Omphalographer (talk) 18:57, 10 April 2024 (UTC)[reply]
I can see both sides and arguments here. Tuvalkin is strictly against adding such "another whistle and bell" to the upload wizard (I find it tedious too, and I can understand how a Clippy-style intervention during the upload would frustrate the more experienced uploaders). On the other hand, this addition to the wizard could immensely enrich the descriptions of uploaded logos by one-time contributors (often by the companies/brands who hold copyright of the logo, i.e. these are officially sanctioned uploads that we'll be able to use) who we can never contact again even a week later for clarification on their uploads. --Enyavar (talk) 09:32, 11 April 2024 (UTC)[reply]

Thanks all for your interventions! We've already identified some good things we can work on, even though we would like the discussion to go on and let you continue have your say. We would like the discussion to go on some more days, to try to get some consensus going on. Sannita (WMF) (talk) 10:17, 15 April 2024 (UTC)[reply]

How do I flag my bot’s edits as coming from a bot?[edit]

I'm the operator of the bot User:FlickypediaBackfillrBot. I've been through the bot approval process and it was approved by User:Krd in March. The user appears in the list of bots on Special:ListUsers.

I'm using the wbeditentity API and setting the bot=1 query parameter like it suggests, but the edits aren't being flagged as bot edits. This means that when I run the bot, the edits can overwhelm people’s watch lists (see feedback here: User talk:FlickypediaBackfillrBot#BOT flag).

I notice the wbeditentity API says This URL flag will only be respected if the user belongs to the group "Bots" – but this user is part of the "Bots" user group, isn't it?

I've extracted a minimal version of the code here, and you can see me setting the bot=1 parameter on L28: https://gist.github.com/alexwlchan/0acdb92d2e94a1c47d54fcef5b3e1fe9 I got this by looking at the equivalent code in mwclient.

Is this a bug in my code, or is there some other step in the bot approval procedure that I’ve missed? Alexwlchan (talk) 11:54, 10 April 2024 (UTC)[reply]

@Alexwlchan, i tried to replicate the problem and by using pywikibot your post parameters are looking good. Maybe one thing what you could try is to check if the bot flag is working when you are doing edits through pywikibot? (to see if there is some problem with the user rights. Though afaik bot flag should be working.)
My example code
Running the code‎
:python3 -m venv ./venv
:source venv/bin/activate
:pip install pywikibot
:echo "usernames['commons']['commons'] = 'YourBotUserName'" > user-config.py
:python editcaption.py
:‎
-- Zache (talk) 12:48, 11 April 2024 (UTC)[reply]
Also, you can use Quarry to check if the edits are bot flagged (example: https://quarry.wmcloud.org/query/81935 ) -- Zache (talk) 12:49, 11 April 2024 (UTC)[reply]
Thanks User:Zache!
If I run your code, I do see my edits showing up with the bot flag, so it must be a bug on my side. I'll have a look through the pywikibot code to understand what I’m doing differently and find my mistake. Alexwlchan (talk) 13:30, 11 April 2024 (UTC)[reply]
Right, the issue seems to be how I'm authenticating – I'm using a Personal API token whereas the Pywikibot code is using some login cookies to make its request. I think I need to take a closer look at my auth code. :) Alexwlchan (talk) 15:20, 11 April 2024 (UTC)[reply]
For the sake of future readers: one of the key steps in debugging was observing the HTTP requests made by pywikibot. I've written about how I did that here: https://alexwlchan.net/til/2024/how-to-see-pywikibot-http-requests/ Alexwlchan (talk) 15:34, 12 April 2024 (UTC)[reply]
Thank you for the debugging example! --Zache (talk) 17:40, 12 April 2024 (UTC)[reply]

New tool for cropping and rotating images (proposal)[edit]

MediaWiki or at least Commons should have a function that allows to crop images and save them as separate ones directly, including the original description.

Why would we need it when most phones can crop or even rotate images?

  • preserve image resolution
  • preserve metadata
  • ensure derivation is annotated on original file

We currently have a bot and a user tool that have some of the functionality, but this lags behind a reasonable functionality. Maybe WMF development can be facilitated by adopting some of their code. Enhancing999 (talk) 08:13, 12 April 2024 (UTC)[reply]

Enhancing999, CropTool has no lag for me. You ask to crop an image, you crop it and it is immediately uploaded. I use it regularly and I do not have any complains about it. Rotatebot also seems to work fine. You tag a file for rotating and within 24 hours it is rotated. I guess we could have a tool to rotate immediately, but the current approach is not bad. --Jarekt (talk) 00:42, 18 April 2024 (UTC)[reply]
There are two years of open bug reports and feature requests on the tools talk page.
I agree it works on files of 500 KB, but larger ones fail now, especially when attempt to fix rotation by a few degrees. Rotatebot can't handle that. Also the automated border detection fails. Enhancing999 (talk) 08:15, 18 April 2024 (UTC)[reply]
Lots of miscellaneous failures over the last few years, and no one committed to maintaining it.
I'd be glad to see a group of three or more volunteers take it on, or WMF, but finding one more individual to do it just postpones collapse, because the environment keeps changing. - Jmabel ! talk 12:46, 18 April 2024 (UTC)[reply]
Isn't development of key features meant to be done by paid WMF staff? It's not a content/editorial issue. Enhancing999 (talk) 07:41, 20 April 2024 (UTC)[reply]

Tech News: 2024-16[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.

Problems

  • Between 2 April and 8 April, on wikis using Flagged Revisions, the "Reverted" tag was not applied to undone edits. In addition, page moves, protections and imports were not autoreviewed. This problem is now fixed. [12][13]

Changes later this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 16 April. It will be on non-Wikipedia wikis and some Wikipedias from 17 April. It will be on all wikis from 18 April (calendar). [14][15]
  • Default category sort keys will now affect categories added by templates placed in footnotes. Previously footnotes used the page title as the default sort key even if a different default sort key was specified (category-specific sort keys already worked). [16]
  • A new variable page_last_edit_age will be added to abuse filters. It tells how many seconds ago the last edit to a page was made. [17]

Future changes

  • Volunteer developers are kindly asked to update the code of their tools and features to handle temporary accounts. Learn more.
  • Four database fields will be removed from database replicas (including Quarry). This affects only the abuse_filter and abuse_filter_history tables. Some queries might need to be updated. [18]

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

MediaWiki message delivery 23:26, 15 April 2024 (UTC)[reply]

changes to Module:Autotranslate[edit]

Module:Autotranslate was altered today to use more efficient test for presence of a language subtemplate. The new version was tested extensively, but please be on a lookout for any issues with templates using it. Please ping me if any issues are found or suspected. Jarekt (talk) 13:34, 18 April 2024 (UTC)[reply]

Deletions on "structured tab"[edit]

Anybody know if the feature is still being maintained? I reported a problem a while back about the impossibly to remove wrong statements, but it's still broken. Enhancing999 (talk) 07:44, 20 April 2024 (UTC)[reply]

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