FlickreviewR 2 bot, size not found

Tool: User:FlickreviewR 2

Problem: it sometimes has hiccups and returns size not found, e.g. File:12.17 總統接見「美國退伍軍團協會總會長賴斯塔德訪團」 (46350888361).jpg File:Rome 2015 95 2 (20570268974).jpg.

Solution: temporary: i think it'll be a good idea to run the bot thru Category:Flickr images needing human review (for everything, or better only for files that were created with the tags "flickr" or "flickr2commons [1.0]") once a month. or another bot can reinsert {{Flickrreview}} to such files. this can minimise congestion in the human queue.

longterm: fix the problem that leads to "size not found" error in the first place.

Remarks: previously written at User_talk:Zhuyifei1999/Archive_58#Category:Flickr_images_needing_human_review.--RZuo (talk) 13:53, 13 February 2023 (UTC)

Discussion

GlobalUsageUI not working on videos

Tool: MediaWiki:Gadget-GlobalUsageUI.js

Problem: Since switching to the newest video player this gadget does not the show red number in category pages like Category:LVR-Institut für Landeskunde und Regionalgeschichte Raymond 13:32, 2 June 2022 (UTC)

Remarks: previously written at Help_talk:Gadget-GlobalUsageUI#Not_working_for_videos.--RZuo (talk) 06:28, 24 May 2023 (UTC)

Discussion

Search bug

Hi since this afternoon (CET) i can't get searchresults like this test shows : https://commons.wikimedia.org/w/index.php?search=Cat%3AAdrie+V%C3%BCrtheim&title=Special:Search&profile=advanced&fulltext=1&ns0=1&ns4=1&ns6=1 It happens for me in two different browsers tested, so it is probably not a local error on userside. I hope this can be resolved soon, because it is a show stopper. I managed to work around it and create the cat. But the error (and message) is still confusing. Peli (talk) 17:38, 17 June 2023 (UTC) Update. Issue seems resolved.Peli (talk) 10:56, 18 June 2023 (UTC)

"Skip to current candidates" button skips too far on FPC on mobile

Tool: No special tool, simply visit Commons:Featured picture candidates

Languages: En

Problem: "Skip to current candidates" button skips too far on FPC. Mobile Chrome browser on Android phone. Instead of jumping to the first candidate, it goes to halfway down the third candidate. The w:en:WP:FPC "Current candidates" button works as expected. I don't have another mobile device/browser to test the problem. It only happens when viewing the page for the first time. Can anyone reproduce? --Commander Keane (talk) 06:33, 8 July 2024 (UTC)

Other reports:

Discussion @Commander Keane: first, #top: "For bugs related to the Mediawiki software or wikis operated by the Wikimedia Foundation, please file reports on phab:."

i tried opening https://commons.m.wikimedia.org/wiki/Commons:Featured_picture_candidates#Featured_picture_candidates in my android phone in chrome. indeed it jumps to middle of the candidates.

if i just open Commons:Featured picture candidates and click the button, it jumps to the 1st candidate as expected.--RZuo (talk) 10:05, 8 July 2024 (UTC)

"Software used" value in File Details table on Commons shown as incorrect blue link

Tool:

Languages:

Problem: "Software used" value in File Details table on Commons shown as incorrect blue link

Other reports:

Discussion

Jidanni 05:55, 21 August 2024‎ (UTC)

Per T372632, caused by MediaWiki:Exif-software-value adding an interwiki link to English Wikipedia. Probably should be changed to not do that if software values are not really indicative of the presence of an article. stjn^[ru] 11:17, 2 September 2024 (UTC)

@Jidanni@Stjn how do you want the fix to be? what should it be like after fix? RZuo (talk) 11:33, 2 September 2024 (UTC)

IMO, if most links from that field are not to existing pages, the interface message should be removed. stjn^[ru] 11:35, 2 September 2024 (UTC)

A bit hackish, but we can guess whether a (non-redirect) article with the given title exists on enwiki – try to get its Wikidata item using mw.wikibase.getEntityIdForTitle('$1', 'enwiki'), and if we get anything, it exists. (Bonus: link to the Wikipedia article in the user’s language if that exists rather than always English.) —Tacsipacsi (talk) 23:40, 4 September 2024 (UTC)

i thought it's already linking to the wikipedia in the user's ui language, by using :w: ,

but i just found out that it behaves differently in different langauges.

if ui is german, it actually shows two links. if ui is french, it links to enwp. RZuo (talk) 05:36, 5 September 2024 (UTC)

w: always links to the English Wikipedia on Commons (and in other multilingual projects). German behaves differently because it uses MediaWiki:Exif-model-value/de rather than MediaWiki:Exif-model-value. —Tacsipacsi (talk) 22:28, 5 September 2024 (UTC)

Bug when moving files on Santali WP

Tool: 'Move' tool when checking the box for auto-replace; also the default file-mover bot that cleans up after file moves

Languages: sat

Problem: This is a sporadic problem that I've seen for probably a decade now. I've only ever noticed it for WP-sat, but it's quite common when moving files used by that wiki.

Very often, the 'move' tool will fail to move a file on WP-sat. It's sometimes impossible to know if it's this bug, because the auto-file-mover so often fails before it gets to the end of the alphabetical list of wikis using the file. But sometimes wikis further down in the list, such as WP-te and WP-zh, will be fixed but WP-sat will not. Also, when the auto-mover does not get through the full list and the default file-mover bot takes care of the remaining transclusions over the next few days, WP-sat is often neglected. It won't show up under 'global usage' at the file on Commons because it's using a redirect.

If you search Special:GlobalUsage for the original file name, you'll get a spurious article on WP-sat. When you click on it, the page doesn't exist. The problem is a spurious prefix ᱢᱩᱬᱩᱛ before the article name. Remove that prefix, and you'll get the article that uses the file under its old name.

This happened to me again the other day, but I fixed the link on WP-sat, so today I tried moving a couple other files with poorly worded file names that were used on WP-sat. One of them was renamed correctly on WP-sat, the other was not, even though it was renamed correctly on WP-te further down the list. If you search at Special:GlobalUsage for the latter file, Srikakulam .naxal memorial tower.jpg, you'll find that a single transclusion remains -

Usage on sat.wikipedia.org

   ᱢᱩᱬᱩᱛ:ᱱᱟᱠᱥᱟᱞ

The article ᱢᱩᱬᱩᱛ:ᱱᱟᱠᱥᱟᱞ does not exist, but the article ᱱᱟᱠᱥᱟᱞ does, and it uses the file. I won't fix it so that you can see the error

--Kwamikagami (talk) 20:21, 5 March 2025 (UTC)

@Kwamikagami may I ask what ᱢᱩᱬᱩᱛ means? is it a word? RoyZuo (talk) 20:49, 5 March 2025 (UTC)

On Santali WP, ᱢᱩᱬᱩᱛ ᱥᱟᱦᱴᱟ is the title of the Main Page. The second word means 'page', so I'd guess that ᱢᱩᱬᱩᱛ by itself is equivalent to 'main' on English wikis. Gtrans translates it as 'goal', but I doubt it's reliable for an obscure language like Santali.

There's also a page ᱢᱩᱬᱩᱛ:ᱦᱟᱱᱩᱢᱟᱱᱜᱟᱲ with our prefix, where the second word is the city of Hanumangarh; Gtrans translates it as 'Headline: Hanumanga'. That article looks like an error, though -- it's just one line, in Hindi at that, and Santali WP already has a long article on that city. So maybe it's a mistake or vandalism related to this bug, if someone was directed to a non-existent page and decided to write something while they were there. I'm going to tag it for deletion Kwamikagami (talk) 00:05, 6 March 2025 (UTC)

@Kwamikagami if it's a prevalent problem and it involves Special:GlobalUsage, to me it sounds like a problem with the setup of that wiki. i suggest you report the bug to phab:. RoyZuo (talk) 07:50, 6 March 2025 (UTC)

Other reports:

Discussion