To my knowledge there are now several rate-limits enforced now, that differentiate between client type (those with and without User-Agent, authenticated clients etc.), and when the rate-limit is hit 429 errors are returned.

Looks like deepcat searches are working correctly again :) All linked searches above returning expected results.

From the other ticket, looks like a patch has been made by @ShivaanshSingh (thanks!)

I opened a similar ticket for Commons (looks like this issue is across the board):
https://phabricator.wikimedia.org/T414763

See T413570, may be related. We found that requests for thumbnails that don't have a Referer header would quickly get 429ed.

Ah! I resolved the 429 issue on my end. My webapp uses Helmet.js, which defaults to hiding the Referer header when loading external files. I started allowing the Referer header to be sent when loading upload.wikimedia.org images and images are loading fine again (and I'm now back to using upload.wikimedia.org instead of thumb.php). I'm guessing with whatever recent changes were done to keep AI scrapers at bay, the Referer header became a more important heuristic.

Did a bit more experimenting:

Hi there. Chiming in as another external tool developer who also noticed the 429 issue. I develop https://commons.gallery/, a website funded by Wikimedia CH that allows Wikimedia Commons users to easily create portfolios in a Flickr-like interface. Here is an example of a typical album (this one was 13 photos).

@Nikerabbit if it's not too late, I'd rather the branch be called i18n. Otherwise, twn will be fine. Thank you!

Marking as done, documentation has been revamped and expanded since this issue was opened.
https://meta.wikimedia.org/wiki/View_it!_Tool

Marking as done - documentation has been revamped and expanded since this issue was opened.
https://meta.wikimedia.org/wiki/View_it!_Tool

@abi_ I have granted developer access to l10n-bot. Our main branch is locked down to prevent direct commits. Would we be able to do something like, the bot commits changes to an i18n that we periodically review and merge into main?

i18n folder now in main branch.
https://gitlab.wikimedia.org/kevinpayravi/cite-unseen/-/tree/main/i18n

Ah, thanks for the report! Should now be fixed.

Current strings and localization are in the i18n branch, will be merged into main soon:
https://gitlab.wikimedia.org/kevinpayravi/cite-unseen/-/tree/i18n/i18n

Closing as our September 2025 update has revamped how citation detection works, and it works across most language versions of Wikipedia by extracting info from COinS metadata (and some backup detection).

This is effectively done (see September 2025 newsletter). Cite Unseen now injects a filtering dashboard at the top of references sections that shows what each icon means.

I can vouch for @Supergrey1; we are going to collaborate on https://gitlab.wikimedia.org/kevinpayravi/cite-unseen

A few ideas myself, @LucasWerkmeister, and @Kristbaum discussed:

• Pixelated image guessing game, where an image from Commons is shown with a pixelated overlay. The player has to guess what the image is of (this can utilize depicts statements on Commons). As time passes, the image becomes less pixelated, and the player scores less points the later they guess correctly.
  • To ensure quality and accuracy of depicts statements, the game can be limited to featured images on Commons, or pull from the winners of campaigns like Wiki Loves Monuments and Wiki Loves Earth.
  • See https://www.faceguesser.com/, which is an existing online game that shows the player a pixelated image of a celebrity from Commons to guess.
• GeoGuesser powered by Wikidata. This already exists at https://guessr.blinry.org/ by @blinry and could work well in a mobile app.
• Also mentioned WikiAsteroids (https://asteroids.wiki/), a game I developed earlier this year (see Diff post). It's the classic Asteroids arcade game, but powered by Wikipedia edits (edit = new asteroid, new user = powerup, new article = 1up). Classic arcade games with a Wikipedia-twist have a nice nostalgia to them and could be popular.

Just listing a couple hepful use cases I can think of in my world:

• Through CentralNotice, this could be particularly helpful for photo campaigns like Wiki Loves Monuments. With a number of photo campaigns happening throughout the year, some users have complained that the banners promoting these photo campaigns are too frequent (and I believe photo campaign banner visibility has been reduced in the last few years because of it). Being able to target topic areas could be beneficial (e.g. increasing visibility of Wiki Loves Monuments US banners to articles under WikiProject National Register of Historic Places).
• Some citation highlighting tools (e.g. Headbomb's UPSD or my own Cite Unseen) mark up citations based on their reliability. Some WikiProjects have their own lists of what sources are reliable or unreliable (e.g. WikiProject Video Games). It's potentially useful for these tools to know when an article falls under a WikiProject so that its respective source reliability list can be applied.

Can confirm, global user scripts now load properly on Wikipedia.

The View it! API has been updated to support a ?caption=true query parameter. When provided, the API will return captions in all available languages for each image.

The title attribute has been added to images in both the carousel and full-gallery view. The on-hover UI is in-progress.

This has been fixed via adding width: 0px; min-width: 100%; to the View it! gallery element. This causes the element to have no width for the sake of its parent elements calculating their widths, but it will appear at 100% width of the page contents.

To get this to work, we would probably have to re-initialize MediaViewer after View it!'s carousel has loaded. I've done some investigating, and also got some guidance from @Tgr.

When viewing a Wikidata item without a P18 statement, View it! carousel images will have a "+" icon as shown:

This would probably only be done in source editor, since the alt text is hidden away in a popup menu in Visual Editor.

A "Close View it!" button has been added below the carousel, floated to the right side of the article title next to where article status icons usually go (featured articles, protection lock icons, etc.)

Carousel now works in source editor as well. To get the q-number, the DOM is queried to pull the q-number from the sidebar's "Wikidata item" link. This isn't ideal and more of a quick solution, pending using an API call (though querying the DOM has the added benefit of not having to wait for an API call to complete).

Copy-to-clipboard has been launched and works in both VE and source editor. The copy-to-clipboard button only appears when editing the page.

After discussion, we will be adding a "copy to clipboard" feature for images in the carousal. This is a solid and relatively quick solution that will work in both Visual Editor and source editor. More intricate functionality (like placing an image wherever your cursor is in VE) may be considered in the future.

Image carousel now works when editing via Visual Editor. This was done by setting pointer-event and opacity CSS on the View it! container, in order to overwrite the ve-init-mw-desktopArticleTarget-uneditableContent class that is applied to the container when VE is activated.

Added a blacklist to the script that currently just has Main_Page

Script is in-progress that outputs an expandable image carousal that can be expanded into a grid. The script pulls from the View it! API.

This has been implemented and successfully tested on both desktop and mobile.

The introductory logo+text now only appears on the homepage (i.e. user hasn't performed a search yet).

Oauth authentication is now working; can try it out via https://view-it.toolforge.org/login.

Progress is being made; requested an OAuth consumer key (20f7833888703a9e334d3de1b4501941)

Since clicking the View it! portlet link now opens in a new tab (T317214), it may be a good idea to remove the "return to article" button, as all the user needs to do to return to the article is switch or close tabs. Removing the button also helps reduce how crowded the top of the page is getting, especially with advanced search enabled.

Support for P373 has been added to the UI.

Published changelog here: https://meta.wikimedia.org/wiki/View_it!_Tool/Changelog

Advanced search has been added with a toggle and launched live for everyone:

Published at https://gitlab.wikimedia.org/kevinpayravi/view-it

This has been implemented (see screenshot), in both the UI and API (API parameter is freetext).