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/2026/01/Archive/2026/02.
Latest comment: 21 days ago2 comments2 people in discussion
Hi. I made a new public domain template specifically for Saint Helena, Ascension and Tristan da Cunha: {{PD-SHN}}. Please comment on it to see if I got the template code format correctly, thanks. – Howardcorn33 (💬) 22:53, 24 December 2025 (UTC)Reply
Latest comment: 24 days ago6 comments5 people in discussion
Most images sent to Discord from Wikimedia Commons do not load their preview images in the embed, ever since 2 or 3 days ago. Some do, my testing shows a trend that images featured on the current main page for Wikipedia tend to load, (sending myself https://commons.wikimedia.org/wiki/File:Neptune_Voyager2_color_calibrated.png on discord loads the preview image in the embed, for example) yet most others do not (sending myself the non-main page image https://commons.wikimedia.org/wiki/File:Neptune_-_August_19_1989_(39736246694).jpg refuses to load the preview image in the embed, as a counter-example), though it's not entirely consistent. Old Wikimedia Commons links sent in Discord have also had their previously loadable preview embeds fail to load upon cache refresh. Other websites like YouTube, (Fx)Twitter and Internet Archive still load embeds fine. I love sending images that I find in Wikimedia Commons to my friends a lot, so finding help would be important, though since my issue is technically based on another website / app, I'm not entirely sure if posting here is appropriate. Jd vance don't like me (talk) 02:58, 28 December 2025 (UTC)Reply
Probably relates to the recent limiting of what image sizes can be generated, same thing that messed up the TinEye and Google Lens tools. - Jmabel ! talk07:39, 28 December 2025 (UTC)Reply
Nothing that I'm aware of, but I gather this briefly broke the links to TinEye and Google Lens, because they were using a specific hard-coded size that is no longer supported. Can't recall where I heard that, sorry. - Jmabel ! talk01:29, 5 January 2026 (UTC)Reply
It's not possible, without modifying the svg. A workaround here is to explicitly add German translations, the same way you added the English ones. (It may seems duplicative, since the default text is already German, but it would work.) If you do that, you'd get 3 options 'English - German - default' in the dropdown. – Ammarpad (talk) 18:22, 4 January 2026 (UTC)Reply
The semantics of SVG's systemLanguage attribute imply the default clause does not have a language. Consequently, a multilingual SVG file should have an explicit systemLanguage for each language and a default clause to cover all other languages. Otherwise, strange behavior happens. For example, if my browser prefers German over English, I expect to see German when displaying File:Wissenschaftssprachen NatWi.svg in my browser, but my browser will display English text. The browser does not know the default clause is German, so it displays the less-preferred (but known) English.
It would be nice if SVG Translate learned the default language and copied the default clause to an explicit language clause.
The simple fix is to use SVG Translate to translate the default language to German.
Thanks for your elaborations – so would the optimal solution be for SVG Translate to be changed to detect or allow the user to specify the name of the SVG's default language and then copy "the default clause to [the] explicit language clause"? If that was done, would a SVG with one language when translated into a second language then have three values in the dropdown? (Here German, English, default language.) If so, I'd create a code issue about that. I think it would be better if after translating there were just two values (Here German (default), English) but don't know how that would be possible. Prototyperspective (talk) 23:55, 5 January 2026 (UTC)Reply
@Prototyperspective: Fixing SVG Translate would be a solution, but it would still list a separate default language. A separate default language makes sense given the semantics of systemLanguage. It also makes practical sense: a file may use the ISO date 2026-01-06 as the default, but use "Jan. 6, 2026" for an English date and other appropriate INTL dates for other languages. I would not create an issue because SVG semantics do not mean German (default), English. Multilingual SVG has many issues. Glrx (talk) 20:45, 6 January 2026 (UTC)Reply
Another way to look at it, is that SVG knows no default language. There is only fallback text of an unspecified language. This is actually pretty common in media formats as language information is generally not so critical. Commons itself does the same. Commons has the file information template, but there is no requirement on users to define which language they are using. We sometimes add that with the language templates, but its optional and thus cannot be relied upon. —TheDJ (talk • contribs) 21:05, 6 January 2026 (UTC)Reply
…hence the question about enabling users to specify what the file's default language is. Also the UploadWizard, the most-used recommended default way to upload files, asks the user to specify the language of the file description. Prototyperspective (talk) 23:59, 6 January 2026 (UTC)Reply
A separate default language makes sense Are you saying German, English, default language here makes more sense than just having German (default), English? If so, I don't understand why. because SVG semantics do not mean German (default), English This is also an enigma to me – I only added that I think it would be best if there were just two values in this case instead of three (one redundant as exactly the same as default language). The main issue here is about enabling users to specify what that unspecified "(default language)" of the file is which currently has just the (default language) label in the dropdown which means people can't see 1 of the languages the file is available in, the language of the original SVG. Could you elaborate? Prototyperspective (talk) 00:04, 7 January 2026 (UTC)Reply
For this file, the default text would be the same as the German, so for this file German (default), English makes sense. However, that is not the general case. Multilingual SVG files should include default as a separate option. Many multilingual SVG files do not have separate translations for numerical values — they just default to "123" for all languages.
The language for the default clause is not specified; it could be any language or no language at all. That's why I gave the ISO 8660 date example. That the language is recognizable as German or English or Swahili in some SVG files does not mean that is the case in all SVG files. The SVG specification is the problem. It does not allow us to say display a preferred language if available but otherwise display German (or French or English). It only allows a fallback to an unspecified language.
MW also contributes to the confusion. An author creates an SVG image in German, and the image displays in German. Then somebody uses SVG Translate to add English labels. After that, MW displays the image English rather than German. Something that probably confuses the original author. Commons displays English; if English is not available, then it displays the default. The original German image displays German not because German is asked for but because English is asked for but not available.
To put it bluntly, MW did not know the original version was in German. GNU Plot did not add xml:lang="de" or lang="de". Even if it did that, most utilities and MW would ignore the attribute. The language was default at the beginning.
Given the semantics of SVG, the simplest thing to do is to show a default language.
Multilingual SVG is a hack. It is easy for browsers to support because it is simple and follows other conditional constructs. However, few tools support the generation or editing of multilingual SVG.
Well wouldn't the solution to this simply be to not require the language to be specified but also allow the (default language) value with language unspecified? That could be used e.g. for charts with just numbers that are used across very many languages and not specific to one.
However, I wasn't asking about making it a requirement to specify the language or whether SVGs can always detect and display the language – just about specifying the language in the ambiguous (default language) to be specifiable for the translated data graphics where there the default is in a specific language (probably >98% of cases). Or if it's already possible, how to do so.
I think you're talking about a separate issue where SVG can't show the version in the language the user has specified in the config. But my prior comment and originally this thread is not about that. It's about what the user sees when they click on the languages dropdown, not which language version displays by default. So I think we have been talking past each other a bit. I think your issue warrants a separate discussion and/or issue. Prototyperspective (talk) 01:11, 8 January 2026 (UTC)Reply
Latest comment: 17 days ago7 comments3 people in discussion
Trying to use chunked upload to overwrite File:Port of Seattle map, 1918.jpg with an even higher-resolution file, I got an error that MwJSBot is not defined. File I was uploading shows in MS Windows "properties" as 100MB, but is apparently a tad too large for a non-chunked upload. - Jmabel ! talk23:46, 4 January 2026 (UTC)Reply
It might indicate that something is conflicting with a gadget you have enabled or a custom user script you have. Even if that script doesn't work, you should still be able to use upload wizard to upload large files [Older versions of upload wizard didn't let you overwrite files, but i think that changed now] Bawolff (talk) 08:00, 14 January 2026 (UTC)Reply
@JayCubby: thanks, yes that is what I had. And, yes, I was aware I could have uploaded to a different file name and merged, but I would think the chunked upload ought to work in the obvious manner, from "Upload new version". If the problem is somehow specific to me, that is less of an issue. - Jmabel ! talk20:10, 14 January 2026 (UTC)Reply
Change in wiki commons rate-limiting? Getting frequent 429 - errors on wiki commons image requests
Latest comment: 12 days ago13 comments4 people in discussion
I have an app (ios / android) that is displaying images from wikimedia commons (Hotlinking) that has been out for over a year. About a week ago I started seeing a massive increase of 429 - Too many Requests responses. Nothing on our side has changed, the requests come from user devices (and IPs) and the 429 responses come after about 10-20 requests (request volume hasn't changed either). This seems to be a problem for other projects as well as evidenced by this reddit thread and this bug report. I am sending a user agent with requests as recommended here. Bbbub (talk) 11:14, 5 January 2026 (UTC)Reply
I understand that wikimedia needs to guard it's resources against misuse but to me it doesn't seem like normal ratelimiting, we see these 429 responses with very low requests (10-20), other developers (in the linked thread) mentioned getting it for single requests. Additionally other requests sent directly afterwards might go through. Bbbub (talk) 08:01, 6 January 2026 (UTC)Reply
@Bbbub Oh, another thing is, that only specific thumbnail sizes are still allowed. If you are manipulating URLs to get your image to fit to a certain dimension, you will also see this erroring with 429s. —TheDJ (talk • contribs) 12:43, 5 January 2026 (UTC)Reply
I am working with different thumbnail size brackets (..., 640, 800, 960, ...) for different screen sizes. I am pretty sure I got the sizes originally from Wikimedia, but let me know if there has been a change or a source for the allowed thumbnail sizes so I can verify. Bbbub (talk) 07:37, 6 January 2026 (UTC)Reply
Another problem. You should set the loading=lazy attribute on the img, so that you only download images that are actually likely to be within view. This is especially needed for things like this kind of gallery code. —TheDJ (talk • contribs) 12:46, 5 January 2026 (UTC)Reply
This is a pretty important one for you specific use case. If you are requesting 30 images that all still need to be generated, even though only 15 are visible, then you will quite quickly run into rate limits. —TheDJ (talk • contribs) 13:25, 5 January 2026 (UTC)Reply
We're only loading the images that come into view, and we're seeing 429 responses with 10-15 images loading already, and in the linked reddit thread others described seeing it for one-off loads as well. Bbbub (talk) 07:43, 6 January 2026 (UTC)Reply
I'm the other poster. Perhaps ironically, thumb.php was an unideal workaround I figured out. upload.wikimedia.org would return 429s while thumb.php would not. ~Kevin Payravi (talk) 08:21, 6 January 2026 (UTC)Reply
Chiming in as another external developer who ran into this: hotlinked images loaded clientside (in-browser) were getting 429ed, even in situations where I was only loading a few images. I realized that my webapp was not sending in the Referrer header when requesting hotlinked images. After restoring the Referrer header, I could load thumbnails just fine. So I'm guessing the lack of the Referrer header was one heuristic that (combined with others) resulted in the 429 errors. More details on the Phab thread. ~Kevin Payravi (talk) 08:21, 6 January 2026 (UTC)Reply
I corresponded with WMF developers using the e-mail address given in the error message, and the problem was fixed almost immediately. – Jonesey95 (talk) 21:00, 19 January 2026 (UTC)Reply
The problem is that it is not an SVG, it's a PNG image that has been put inside of an SVG. It should probably be deleted, or someone has to vectorize it properly. —TheDJ (talk • contribs) 12:40, 5 January 2026 (UTC)Reply
It would probably be good to somehow get a list of such files and then convert them all to PNGs. For example SVG Translate doesn't work on these. Apparently as this example shows one can redirect the SVGs to PNGs (so that links to them don't break). May not be worth the effort for now. Nevertheless, maybe at least a warning note template including a category could be added to these files if there's a way to scan all the SVG files for these. Prototyperspective (talk) 23:49, 5 January 2026 (UTC)Reply
Showing the approximate location as text, not just geocoordinates in file description
Latest comment: 24 days ago3 comments2 people in discussion
For example in this file File:White cabbage butterflies flying.webm, the user added "Franklin County Ohio, USA" below the template. The same has been done for many of the other videos by the user except the most recent as well as by many other users. Worse, for many other videos there is no textual name of the region at all and just the geocoordinates which are unreadable – people don't know which approximate location such as which country it is just by a text like 40° 02′ 38.4″ N, 83° 02′ 31.2″ W.
The related effort seems to be Commons:Reverse geocoding but that's (so far) only adding data to the structured data and the categories, not to the content of the file information template such as the {{Location}} template.
Is there a way to automatically parse the region location from the geocoordinates and then add that next to next to the {{Location}} template (probably by a bot)? For the files where geolocation structured data has been written, I think that SD could be used to add that info to the file description box, maybe into a new parameter of Template:Location like |name= that has the location in text string format. Would be great if somebody could add this info to the files' Information template.
I do this too but not every user knows of and looks at the categories which for >99.9% of visitors are either at the bottom (many don't scroll to there) or, if on mobile, not visible at all.
Secondly, many videos are left out by this – e.g. quite many videos of that user who uploaded the example video but also many more. And it doesn't scale well and even if it did, it would be better to automate this more so that more contributor time is freed up and less videos without the region as text. Moreover, often the location is not really key to a video because it doesn't show the location and otherwise is unlikely of interest to people browsing the category for a region like Franklin County, Ohio so people don't add the category or if they add it, it's then causing the problem of cluttering a category with videos that aren't really of interest to the user. (For example a screencast video of some software may have been produced in a certain place but it's not related much to that place and shows nothing of the place; likewise a microscopic video of an animal under the microscope could have been taken somewhere but it's also not really about the place.) Prototyperspective (talk) 22:46, 7 January 2026 (UTC)Reply
How to see why a file is somewhere underneath a category?
Now it works for me too. Looks like FastCCI is up again – that's great!
However, it's been down most of the time in the past and was down shortly after whenever it was running again. FastCCI is a great tool with a lot of potential but I don't try using it anymore (I did before creating this thread of course) because there's a low chance of it being up at any time. I hope eventually somebody will fix whatever causes it to go down all the time.
Another issue is that this hacky way is cumbersome to use: one has to go the category go to Tools -> Page information, then copy that ID, then open the one specific image (there's usually many) in a new tab, and then manually append the remembered ?fastcci_from= with the copied ID. A tool even if it's just a bookmarklet would be a great help.
Btw for people clicking the link above: I fixed the miscategorizations of the examples so nothing may display there anymore.
Lots of categories have offtopic files somewhere underneath them so this could be used by many to substantially improve Commons by using the deepcategory view on categories and scanning any offtopic files. Help:Gadget-DeepcatSearch makes this easy (just 2 clicks to see the wall of images).
For example, the searchbox for categories {{Search in category}} should not be added if the deepcat search fails on the category – and this often is the case because of some miscategorization that adds in a very deep huge category branch that's not supposed to be underneath the category or needs to be more specific (via adding a subcat of it instead). This was probably the case for Category:World statistics where the deepcat search fails so it can get a searchbox once the deepcat results have been updated. Prototyperspective (talk) 23:47, 8 January 2026 (UTC)Reply
Latest comment: 22 days ago8 comments3 people in discussion
Hi!
Sometimes, probably due to an upload error, some files don't get a description with license etc. How can I look up files uploaded by user X that have no file description? Thanks --PantheraLeo1359531 😺 (talk) 08:56, 8 January 2026 (UTC)Reply
The problem is that one can't search uploads of a user. Thought about making a thread about this broader issue. See the linked phab issue. If the files were not just uploaded but created by the user or all in some category or have some other text in them, you can use Category:Media lacking a description e.g. by using the incategory search operator to search through it. Prototyperspective (talk) 15:31, 8 January 2026 (UTC)Reply
Oh, that's a pity. I would really support a thread. Unfortunately, this affects many users, and it would be a shame if some files must be deleted because lost information cannot be retrieved. Thank you for your answer! --PantheraLeo1359531 😺 (talk) 18:40, 8 January 2026 (UTC)Reply
"can't search uploads of a user." if you have to, you can use a quarry query of course. Part of the problem here is that the database design for current and old versions of files was never modernized the way that pages and revisions were in 2005. However this is currently in progress and soon the img tables will be replaced with file, file_revision and file_archive tables. That should make it a bit easier to filter on actors on those file revisions. —TheDJ (talk • contribs) 12:50, 9 January 2026 (UTC)Reply
Even that workaround can't often be used because it doesn't display the results in Commons where one can use this to filter, search, and sort files via MediaSearch. For now, the only way to get the full functionality seems to be creating a user-category and adding it to all the relevant uploads using cat-a-lot and then using incategory:"new user category".
img tables will be replaced with file, file_revision and file_archive tables. That should make it a bit easier to filter on actors on those file revisions will this enable searching files by uploader or will adding that functionality only become possible (but maybe not be done) after this is built or something else? Prototyperspective (talk) 14:56, 9 January 2026 (UTC)Reply
I was a bit surprised when I saw Special:MediaStatistics today. It seems we have unknown/flac, unknown/mpeg and even video/mp4. MP4 could be problematic because of pending patents. The flac and mpeg seems to have no support for on-page play (also missing information like duration or bit rate). --PantheraLeo1359531 😺 (talk) 10:15, 10 January 2026 (UTC)Reply
I apologize for cross-posting my question. I have posted it to the Help Desk a few days ago, but have received no reply so far. If there is a more appropriate forum for asking this question, please let me know.
I have uploaded the video File:Construction of the 600-cell.webm on 6 January. Transcoding to the low-resolution versions up to VP9 480P was successful. However, the transcoding to VP9 1080P has been in the queue for almost four days now. The same problem seems to happen for the video File:Construction of the 600-cell (cell-first).webm that I uploaded yesterday. I am wondering why the transcoding to VP9 1080P is not being performed and what can be done about it. Is there any way to diagnose what the cause of the problem is? Is there any way to transcode the videos manually or to cause the transcoding to be executed? Any hints will be much appreciated. Carsten Steger (talk) 07:15, 11 January 2026 (UTC)Reply
Latest comment: 19 days ago1 comment1 person in discussion
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Weekly highlight
The Wikimedia Foundation has shared some guiding questions for the July 2026–June 2027 Annual Plan on Meta and Diff. These focus on global trends, faster and healthier experimentation, better support for newcomers, strengthening editors and advanced users, improving collaboration across projects, and growing and retaining readership. Feedback and ideas are welcome on the talk page.
Updates for editors
As part of the current work of Community Tech team on the Multiple watchlists project, the display of EditWatchlist will be updated as a first step towards multiple watchlists. Additionally, the pagination on Search will be updated too, as a part of the work on the Revamp pagination / page navigation wish. [1]
The Global Watchlist is a MediaWiki extension that lets you see your watchlists from different wikis on the same page. It was recently updated to look more like the regular Watchlist, such as preparing it for temporary accounts in IP masking (including rerouting user links to contributions pages), making page titles bold, and opening links in edit summaries and tags in new browser tabs. [2][3][4][5]
View all 28 community-submitted tasks that were resolved last week. For example, the issue where global blocks did not have the option to disable sending emails, has now been fixed, and will be available for use in the week of January 13. [6]
Hi, since today i notice that this special seach query is not delivering the expected results. "Georg Scholz" -deepcategory:"Georg_Scholz" . Expected to exclude but it does include the cat. I tested this in 2 browsers. Has anything been changed? Maybe one more of the available special search buttons of the categorie MORE menu is affected. Like: deepcategory:"Georg_Scholz" should show all but shows nothing. Looks like these 2 actions are inversed somehow. Can this be fixed please? Thanks Peli (talk) 15:11, 15 January 2026 (UTC)Reply
It is not working for me either. Strangely for me, deepcat only works for categories with only one word in its title (i.e. title without any spaces), all other category names does not work. Thanks. Tvpuppy (talk) 20:36, 15 January 2026 (UTC)Reply
Thanks, but on Wikimedia commons in categories I still see these errors of not showing any deepcategory items on empty query, and of not properly excluding the category contents upon using -deepcategory. I'm not sure if I need to purge a page or something, beacause I tested it in 3 browsers and the reslults are: never the requested items, in all 3 cases. Peli (talk) 18:49, 17 January 2026 (UTC)Reply
Today I found a bug in cases where the query has an "&". Example: deepcat:"Pellerin & Cie" Try a deepcat search in deepcat:"Pellerin & Cie" results in this search: deepcategory:"Pellerin_ No matches because wrong folder name. The folder name to look in is truncated after the "&". I know there must be a patch for this since my branched button that automates " " -deepcat:" " ("Pellerin & Cie" -deepcat:"Pellerin_&_Cie") has such a patch and works well at this time. The fork is hosted and patched by User @Samwilson: . I hope the regular button/function can be patched as well, without affecting opposite functions. i.e Search outside of category. Peli (talk) 11:15, 22 January 2026 (UTC)Reply
So not only a caching issue, but one not fixed by action=purge (which I had already tried). So just wait and hope it "heals"? - Jmabel ! talk19:08, 16 January 2026 (UTC)Reply
Latest comment: 11 days ago2 comments2 people in discussion
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Updates for editors
The tray shown on Special:Diff in mobile view has been redesigned. It is now collapsed by default, and incorporates a link to undo the edit being viewed, making it easier for mobile editors and reviewers to take action while keeping the interface uncluttered. [8]
The Global Watchlist lets you view your watchlists from multiple wikis on one page. The extension continues to improve — it now automatically determines the text direction (ensuring correct display of sites with unusual domain names) and shows detailed descriptions for log actions. Later this week, a new permanent link for page creations and CSS classes for each entry element will be added. [9][10][11][12]
View all 32 community-submitted tasks that were resolved last week. For example, the previously observed issue in Vector 2022, where anchor link targets were obscured by the sticky header, has now been addressed. [13]
Updates for technical contributors
As mentioned in the October 2025 deprecation announcement, MediaWiki Interfaces team will begin sunsetting all transform endpoints containing a trailing slash from the MediaWiki REST API the week of January 26. Changes are expected to roll out to all wikis on or before January 30th. All API users currently calling them are encouraged to transition to the non-trailing slash versions. Both endpoint variations can be found, compared, and tested using the REST Sandbox. If you have questions or encounter any problems, please file a ticket in Phabricator to the #MW-Interfaces-Team board.
The WMF Wikidata Platform team (WDP) has published its January 2026 newsletter. It includes updates on the legacy full-graph endpoint decommissioning, the User-Agent policy change, the monthly Blazegraph migration office hours, and efforts to reduce regressions caused by the legacy endpoint shutdown. As a reminder, you can subscribe to the WDP newsletter!
The Wikimedia Hackathon Northwestern Europe 2026 will take place on 13-14 March 2026 in Arnhem, the Netherlands. Applications opened mid-December and will close soon or when capacity is reached. It's a two-day, technically oriented hackathon bringing together Wikimedians from the region. Hope to see you there!
A cluttered unoverseeable sea of blue that's exhausting to go through – really an improvement?Great to see some work on the Global Watchlist – it includes a button to see a diff of all unseen changes with a click. I don't know how people can use the Watchlist without such a button. However, it's still not really usable in practice because unless you check all your Watchlist items each and every day there are seas of blue of username-links and that diff button is at an always varying location after the article title, impeding opening up many diffs one after another. Here's two wishes calling for this to be changed; I don't think the Global Watchlist is usable really in its current shape so I hope somebody will eventually fix these problems (at least via options):
I have just uploaded the file 5-Cell Schlegel Diagram.stl. All the previews have been rendered correctly. However, when I display the file in the media viewer, it is rendered incorrectly: basically, the entire object is displayed in pure white, as if the object was completely overexposed. The display problem occurs under Linux as well as under iOS. Is there a way to diagnose why this is happening? What can I do to make the STL file render correctly in the media viewer? Any suggestions will be much appreciated. Carsten Steger (talk) 14:34, 20 January 2026 (UTC)Reply
I get the same incorrect rendering under Windows with Firefox and Internet Explorer. Since the preview rendering with 3d2png works correctly, I suspect this is a bug in the 3D extension of the media viewer. Maybe the bug can be spotted by comparing the code of 3d2png to that of the 3D extension? Carsten Steger (talk) 07:58, 21 January 2026 (UTC)Reply
Help with changing links based on display language
@Immanuelle: Those are not in the SVG. Those are just ImageNotes (which contain Wikitext). You can do pretty much anything inside an ImageNote that you can do anywhere else on a page in Commons, and you do it exactly the same way. - Jmabel ! talk01:22, 21 January 2026 (UTC)Reply
Oh, interesting, the two ImageNotes (which were what I instantly noticed as clickable) can serve something of the same function, which is why I was confused. I know there are ways to do multilingual SVGs, and I imagine the issues are the same for links in the SVG as for text, but I'm out of my depth there. You might ask one or more of the people who participated in #How to specify a SVG file's default language? above, which is clearly a closely related issue. - Jmabel ! talk01:50, 21 January 2026 (UTC)Reply
For links directly in the SVG when viewed directly, you can use the <switch> element. However this will use the browser's language which is sometimes different than the language the user expects (And different from whatever site they are viewing). If you want to use this in Wikipedia, I would suggest using an Image map instead. Bawolff (talk) 23:35, 21 January 2026 (UTC)Reply
One option is to link to Wikidata items instead of wiki articles. For example, instead of linking to https://en.wikipedia.org/wiki/R%C4%81gar%C4%81ja, link to its Wikidata item: Rāgarāja (Q1188900). The en.Wiki article will give you the link on the right-hand side. The user can then scroll down to the bottom of the Wikidata page and click a link to his favorite wiki.
A more involved option is a URL that takes the Wikidata item and the HTTP Accept-Language header. The URL would then redirect the user to the user's preferred wiki article if it exists. If it doesn't exist, then the URL would redirect to the Wikidata item.
Latest comment: 10 days ago3 comments2 people in discussion
Hi, I have a VBA script that I use to download the photos, in practice now usually a recent subset of them, that I have uploaded to Wiki Commons. (I won't go into the reason why I want to download photos that I have already uploaded, but there is a reason.) This used to (say a year or two ago) work perfectly even for hundreds and hundreds of images. Now it struggles to do a dozen or so, before I am blocked, I believe for making too many requests in too short a time. Then eventually it will start working again and let me do a few more, slowing down to a trickle. I suppose this blocking must be a feature recently introduced? I have never been blocked from browser access, however. Even immediately after the script being blocked, I can open pages in the browser (from the same IP address). Anyway, I can try adding pauses between downloads. I've tried five or ten second pauses but it seems to make little difference so far. Anyway, I wouldn't have thought my volume was particularly unreasonable on the scale of server traffic generally. Anyone got any info about what is and isn't permitted, or what I can do to mitigate this issue? Thank you. ITookSomePhotos (talk) 22:02, 21 January 2026 (UTC)Reply
Since relatively recently, there now is a tool – or more use of that tool – which allows the upload of hundreds of OWID files at once (which is great!)
There also now is a gadget that uses these hundreds of files to allow semi-interactive viewing, the OWID Gadget (also great!)
However, categories are missing for both the files and those pages. Now I'd like to also categorize these; I was thinking:
The files belonging to one visualization (one topic) should be in one category which can then be categorized as described above and get a charts and a maps subcategory – this would best be done at upload via the OWIDUploader tool. This is especially so because there usually are hundreds of files with one per country which each should go into Category:Charts by country. This is why I'd only lake to do the next things and hope more things get done at User talk:Jmh649/2#OWID uploads with false and missing categories, including for files already uploaded. Any updates on this @Doc James: ? (e.g. I saw Category:Our World in Data graphs by country has been created but I still often come across uncategorized OWID files)
The interactive visualizations (example below) should also be categorized into categories like e.g. Category:Meat statistics. Would the best way for that be to categorize pages in Category:Pages using gadget owidslider (indexed also in Commons:List of interactive data graphics)? If so, how could one comprehensively categorize these (e.g. see which of these haven't yet been categorized into a topical cat) and isn't it a problem that the page with so many files loads quite long and incomplete? If not, what would be the better way – what about creating some kind of separate page with just the visualization which is ready to use, loads quickly, and can more easily be categorized (e.g. a page like OWID: Daily meat consumption per person in the meat statistics cat instead of Template:OWID/daily meat consumption per person)?
I posted this on your normal talk page. This is just the name of your archive page which is in your responsibility to rename or keep as is. Okay.
There are many examples of these files missing categories, here's a recent one I came across which may also elucidate the complexities involved here (e.g. do we want these hundreds of files to show up in deepcategory wall-of-images views or somehow separate them?):
Regarding separation or enabling the user to exclude the hundreds of files from OWID mass-uploads, maybe it would be good to better make sure files are put into Category:Uploaded by OWID importer tool so the user can exclude these and maybe add a note about this at the relevant places. I think views/scans usually should only show one or two page/file per set – a page with the interactive data graphic. Prototyperspective (talk) 12:20, 23 January 2026 (UTC)Reply
With respect to OWID: this is a namespace and would require permission to put content in it. If you can request and get consensus for that would be happy to put these all there by bot.
So that graphs by country cat is populated by a bot; if so that sounds good – then there's less need to set the cat at time of upload and it could explain why you say "it might be easier to do more categorization after the upload rather than during". With respect to OWID: this is a namespace Don't understand what you mean. Basically the main issue of the thread is that the files are missing in the topic categories like Category:Meat statistics or Category:Renewable energy statistics and because it could clutter the pages and the category's search results, that may be good but the interactive visualization should be in these categories – so for example a page OWID: Daily meat consumption per person that loads quickly and contains just the interactive visualization embedded above. The OWID there is not the namespace but the page title (just standardized to have the OWID prefix) so it would be in the "Main"/gallery namespace in this case. If this is a good/best solution to that issue, then it would still need all those visualizations indexed (mostly or entirely?) in Category:Pages using gadget owidslider to get one of such page each. Prototyperspective (talk) 18:47, 27 January 2026 (UTC)Reply
All the pages with the OWID visualizations are listed here Category:Pages_using_gadget_owidslider About 500 of them.
Could you please address the questions – I linked that category in the comment you're replying to. Please see the part around and isn't it a problem…above. I thought it would be a good idea to discuss this instead of me figuring out myself what the best solution would be and then unilaterally implementing whatever it is without discussion but this is not much of a discussion. If you were saying you think a new separate namespace would be a good approach, that's not clear and I don't understand why that's needed or would be better than e.g. to create the mentioned kind of mainspace pages. Prototyperspective (talk) 00:09, 28 January 2026 (UTC)Reply
What I am saying is we cannot use the title "OWID:Text" unless we get approval from the community at large as that is a new namespace.
I personally think the Category:Pages_using_gadget_owidslider is sufficient for me to find all these. If you want just the interactive graphs placed on a separate page we could do that, and would just need a naming structure.
Thanks for clarifying. Okay so it can't be colons in the prefix as that for pages in the "main"/gallery namespace indicates/requires a new namespace. One could also have the prefix be OWID – or OWID/ for example – the particular suggestion was just an idea/illustration.
I personally think the Category:Pages_using_gadget_owidslider is sufficient for me to find all these as elaborated above, the issue is making these findable for those looking for statistics of a certain topic via either browsing the associated category page or the search. Just having them in that category doesn't achieve that – it's about surfacing these visualizations to people who could be interested in them / to which these are useful.
If you want just the interactive graphs placed on a separate page we could do that do you know if there's a way to do that for all the pages in the Pages_using_gadget_owidslider cat? (maybe using some bot or tool) would just need a naming structure that's what the OWID: visualization name was all about – do you have another suggestion or which prefix(/suffix) would you prefer?
but not sure we need this as explained in the post starting the thread, these pages take long to load and are problematic to edit. It requires downloading lots of data and HotCat does not work on these so one can't edit the usual way and with autocomplete. Opening the wikitext editor takes long and is prone to failing. Also linking to these pages is probably confusing where people wonder what all the many files on the page are about and/or browse these instead of the interactive visualization. An alternative approach would be to remove the files from the template page but I'm not sure if that causes the visualization to break. The pages could link to each other. Prototyperspective (talk) 13:57, 28 January 2026 (UTC)Reply
Asking a wider audience is what I was/am doing here; I thought and think this is the most appropriate large-audience place to discuss this. I pinged you in the comment not because this was addressed to just you. Okay so like this OWID/daily_meat_consumption_per_person? Yes, exactly, thanks. I edited the page to make the visualization larger and center it, what do you think? And also is there a way to create these pages for all the visualizations? Then I'd remove the cats on the large template pages and add them to these pages similar to how files are categorized (nearly all files in Category:Our World in Data except for these OWID Importer mass uploads are by now categorized by subject so this is basically the remaining issue to complete the topical categorization of these data graphics). Prototyperspective (talk) 13:19, 29 January 2026 (UTC)Reply
Thanks, but is that module for SDC in addition to Wikidata? The data values of the 2 files mentioned (at least those in the Summary/Information section) are pulled from SDC, although the properties are from Wikidata. I found core.editAtSDC and core.editAtWikidata in the meantime. Perhaps both modules are to be edited? whym (talk) 12:01, 28 January 2026 (UTC)Reply
Is it possible to check file EXIF data with edit filters?
Latest comment: 4 days ago9 comments7 people in discussion
Is it possible create an edit filter that would check file EXIF "user comment" field? Many copyvios have user comment "Screenshot" and it would be useful to automatically tag such uploads. Preventing is not necessary as there are legitimate files as well. MKFI (talk) 12:21, 25 January 2026 (UTC)Reply
Let me hasard a guess: it's not possible, unfortunately (at least right now). Perusing Commons:Abuse filter and mediawikiwiki:Extension:AbuseFilter/Rules format, I didn't see any mention of (pre-made) EXIF-related variables. If, and that's a large if, the software could allow for arbitrary user-defined variables, then it's conceivable that such an EXIF-specific rule may be developed, but that's way beyond my own abilities. Pinging @Lustiger seth: whom I know as being knowledgeable about the edit filter technique, he may be able to provide a technical insight. Regards, Grand-Duc (talk) 13:26, 25 January 2026 (UTC)Reply
Currently i don't see any possibility for using exif variables.
There are file attributes such as file_mime, file_size, file_width, but nothing for file content (incl. exif data). So i guess you should create a feature requesting ticket at https://phabricator.wikimedia.org. The only related ticket i found was https://phabricator.wikimedia.org/T170251, but that's only related vaguely.
@Doc James: that's a really dirty way of removing metadata and, forcibly, reducing the quality. May I suggest that you edit the EXIF directly? There are hints for that in COM:Exif, I'd say "Use EXIFTool and EXIFToolGUI" (as long as you're on Windows), handy pieces of software for that. Regards, Grand-Duc (talk) 10:56, 27 January 2026 (UTC)Reply
Latest comment: 5 days ago3 comments2 people in discussion
I have a problem with the VRTS release generator. While I'm trying to use the generator in Hebrew, I'm getting error message Uncaught SyntaxError (see the file in the right). and the generator stuck on "Loading..." (see he below). when I'm trying to do the same in English I'm not getting the error message but still it stuck on "Loading..." (see en below).
Latest comment: 5 days ago1 comment1 person in discussion
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
All users with registered accounts can now use passkeys for two-factor authentication (2FA). Passkeys are a simple way to log in without using a second device. They verify the user's identity using a fingerprint, face scan, or a PIN code. To set up a passkey, first set up a regular 2FA method. Currently, to log in with a passkey, users must also use a password. Later this quarter, passwordless login will allow users to log in with a single click and a passkey. Users with advanced rights will also be required to have 2FA enabled. This is part of the Account Security project.
Unregistered contributors on blocked IPs or blocked IP ranges can now interact on-wiki to appeal a block by creating a temporary account to appeal a block on the user talk page, unless the "prevent this user from editing their own talk page" is enabled. This solves the problem of logged-out users unable to use the default unblock process via user talk page. [14]
View all 20 community-submitted tasks that were resolved last week. For example, the Two-Factor Authentication (2FA) methods description on the management page has been updated. It is now clearer and easier for users to understand and make use of. [15]
Updates for technical contributors
A new AbuseFilter variable, account_type, has been added to provide a reliable way to determine the account type being created in the createaccount and autocreateaccount actions. As part of this change, the variable accountname has been renamed to account_name, and accountname is now deprecated. Edit filter managers should update any filters that use hardcoded account type checks or the deprecated variable. [16]
Image thumbnails that are requested in non-standard sizes, and using non-standard methods such as direct requests to upload.wikimedia.org/… will stop working in the near future. This change is to prevent ongoing external abuse by web-scrapers and bots. Some users with custom CSS/JS, Interface Admins who can fix gadgets and local skins, and Tool-authors, will need to update their code to use standard thumbnail sizes. Details, search-links, and examples of how to fix them, are available in the task.
Latest comment: 2 days ago3 comments3 people in discussion
Is it only me, or are annotations broken for anybody else as well? I neither see any existing annotations nor does the button "Add note" appear. And no, I didn't switch it off in my settings. Chianti (talk) 22:20, 28 January 2026 (UTC)Reply
Works for me. That's about the last thing to load, via JavaScript, after a whole bunch of other JavaScript, so if any other JS is broken, or if your JS times out, it could be missed. If you are enough of a techie to use the browser console, you may find a coherent error message, possibly very tangentially related to the symptom. - Jmabel ! talk05:49, 29 January 2026 (UTC)Reply
Works for me in Chrome, Safari, and Firefox, but not Vivaldi, and it doesn't give any errors. While testing, I found that annotations won't show if the window is too narrow (less than about 830 pixels wide), so if your browser is blocking access to the window size (or you're using it on a phone in portrait orientation), that might be the problem. --Carnildo (talk) 22:17, 29 January 2026 (UTC)Reply
Latest comment: 2 days ago1 comment1 person in discussion
As you probably know, there is not a lot of WMF developer support for Commons these days. The one thing I'm aware of that is moving forward is that they have a contractor working on video2commons. At meta:Product and Technology Advisory Council/Unsupported Tools Working Group#January 2026 they report some recent work; what is probably of most general interest is support for playlists and user-library uploads, better subtitle extraction, and several aspects of support for importing from YouTube.
From what I can tell, the one contractor currently working directly on this is doing good work; still, I continue to believe that Commons could benefit greatly from far more WMF dev support. It is good that they've shown that certain work can be successfully contracted out, but it is equally clear that most cannot, and that we need people at least a handful of developers who bring or, well, develop an understanding of Commons, not just of some individual tool. (With reference to "equally clear that most cannot", I was party to some of the discussions of where to focus this resource, and several higher priorities were rejected because handing them to a contractor would set that contractor up to fail.) - Jmabel ! talk18:01, 29 January 2026 (UTC)Reply
I noticed that the "hist" link on Special:Watchlist and Special:Contributions now says "history". Is there a reason this was changed? I'm not sure it's necessary and the fact it's wider than "diff" makes it look very awkward. - The Bushranger (talk) 06:05, 31 January 2026 (UTC)Reply
I found that weird, too. But my main reaction is: I'm sorry anyone put any time into changing that, and hope they don't then waste more time changing it back. - Jmabel ! talk23:47, 31 January 2026 (UTC)Reply