haswbstatement:P170=*[P4174=Username]

should also get the job done.

@TheDJ i'm happy with your solution https://commons.wikimedia.org/w/index.php?title=Template:Category_redirect&diff=prev&oldid=857486910 . now the example cat redirect appears around 600th in the results. no cat redirect in the first 500 results. thx a lot.

someone should do something about the buggy uploads.

1. find a way to check files within these boundaries of multiples of 5 mb for corrupted ones. tag the files.
2. send out reminders to uploaders to ask them reupload.

your analysis makes sense. indeed there're also files cut off at 15 mb https://commons.wikimedia.org/w/index.php?sort=create_timestamp_desc&search=filesize%3A15359%2C15361
e.g.
https://commons.wikimedia.org/wiki/File:Delft_Van_Miereveltlaan_7.jpg
https://commons.wikimedia.org/wiki/File:Changsha_section_of_the_Xiang_River_2023103014.jpg

@Nardog could you please take a look at @Tacsipacsi's comment?

one way you can reduce future usage of redirects is make TemplateWizard and visualeditor insert the target whenever a redirect is selected.

the algorithm probably has some serious problems.

i dont know if this has been mentioned anywhere.

https://commons.wikimedia.org/w/index.php?search=insource%3Anbsp+insource%3A%2F%5C%7Bnbsp%2F&ns10=1

for some reason

adjustable font size is definitely a good feature for the visually impaired.

using firefox 120.0 (64-bit) on win10 laptop.

actually, it would be even better especially for commons users, if new tools that do the following can be developed.

it may be clutter to you, but for novice users the current lack of restriction may mean that they might accidentally contribute their work to a neglected page.

In T352615#9377838, @TheDJ wrote:

Why should it be prohibited ? Does it do harm ? We move and delete pages all the time.

no. https://en.wikipedia.org/wiki/Indian_English langcode is en-IN. and i dont think wikimedia currently supports en-in as an option either.

In T350917#9357740, @MatthewVernon wrote:

Looking at recent uploads, there are definitely >10MB files being uploaded:
https://commons.wikimedia.org/wiki/File:Ambito_veneziano,_Martirio_di_san_Tommaso_Becket,_1260_ca.,_dal_palazzo_vescovile_di_tv,_05.jpg

@TheDJ nothing has ever changed and the problem remains the same since this task was opened in 2020. still possible to add zh-yue captions. old captions still not migrated. there was no reason that this was closed when nothing was changed at all.

it seems the bug has been lurking for years but gone unnoticed.

it's still possible to add zh-yue captions, e.g. https://commons.wikimedia.org/w/index.php?title=File:(20230620)_Dessau_Hbf.jpg&diff=prev&oldid=816157115 .

why the F you switch it off completely? this is a big step backward from T199523 and T258919.

maybe you can come up with a "dos and donts" guideline for template/module design, so that laymen like me dont create junk for the servers.

i'm trying to upload the image downloaded from https://www.nps.gov/media/photo/gallery-item.htm?id=F1A6B858-155D-451F-67881D7E446EDC2A&gid=F17B1C64-155D-451F-6765341D9B8E553F (direct url https://www.nps.gov/npgallery/GetAsset/F1A6B858-155D-451F-67881D7E446EDC2A ).

this should be made a toggle option, with a default of "excluding redirects".
usually it's not helpful to find cat redirects, but sometimes, for example, if i want to determine when a category naming pattern first emerge, it's useful to include redirects in results.

thx guys for all your answers.
glad to know that other users have raised similar issues.
indeed, if those other tasks are resolved, this one will be done too.

@Tgr it doesnt make sense that it can show results if looking for a smaller number (100) but shows nothing for a bigger number (500). this misleads users into thinking those sets of filters cannot find anything, but in reality they just need to lower the number.

another idea would be,

also, my idea is only bumping 1 page.

if you try "nurse", it's even worse. https://commons.wikimedia.org/w/index.php?title=Special:Search&limit=100&offset=0&ns14=1&search=nurse

In T333129#8752137, @TJones wrote:

so, in the typewriter(s) case, there are lots of individual typewriter brands/models that are ranked higher than the plural category

This is so freaking stupid.

the problem with this is, if any one just uses default settings for watchlist, they will miss out all changes to mediawiki and mediawiki talk ns without knowing.

@Novem_Linguae why has this addition not propagated to some wikis? for example, lvwp and yuewp?

thx for the tip. that enabled better codes for https://commons.wikimedia.org/w/index.php?oldid=702252233 .
but in order to do that, one has to know such things exist first. how on earth would i know which things have i18n like this?
even with your tip, i went to translatewiki to try finding the version for abbreviated months. i found it only when i attempt to translate MediaWiki:February, a table of three forms of month names (short, long, genitive) popped up on the side, and i found the code for the short form in the links in that table.
rather extreme manoeuvres to find a mediawiki message.

i used

{{#time:F|February|{{int:lang}}}}

basically to translate it into different languages.

copying from T142082
I'd imagine an interface, where as I type, it suggests properties, like IDE suggesting variables/commands. I choose the property I want to edit, (up to this part is the current behaviour while adding a statement) and it shows me any values the property has right now.

this problem persists. these two yuewp articles were not added to their wd items automatically.

i give up using uploadwizard for flickr files.

after second thought, to be able to overwrite is also good.

i guess this problem persists. i just tried removing audio of https://commons.wikimedia.org/wiki/File:2_Weeks_In_Italy_-_A_Cinematic_Travel_Film.webm without any changes to the video track. the resultant download is only 27 Mb but the original is 498.

problem solved as of today. now old wikitexts are displayed.

Based on edits to a talk page I watch, it was still normal around 8 Aug, so this bug occurred after that, and probably before 27 Aug.