Commons:Village pump/Technical

Shortcuts: COM:VP/T • COM:VPT

• Community portal
  • introduction
• Help desk
• Village pump
  • copyright
  • proposals
  • technical
• Administrators' noticeboard
  • vandalism
  • user problems
  • blocks and protections

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/10 /Archive/2024/11.

COMMONS DISCUSSION PAGES

• Commons Help desk
• Village pump (general discussion)
  • Copyright
  • Proposals
  • Technical
• Graphics and photography discussion
  • Photography critiques
  • Image improvement
    • Illustration workshop
    • Map workshop
    • Photography workshop
    • Video and sound workshop
• Categories for discussion
• Undeletion requests
• Deletion requests
• Volunteer Response Team/Noticeboard
• Translators' noticeboard
• Work requests for bots

---

• Contact administrators
  • Vandalism
  • User problems (Dispute resolution)
  • Blocks and protections
• Bureaucrats' noticeboard
• CheckUser requests
• Oversight requests

---

• Telegram
• IRC ^webchat
• Commons mailing list (archive)
• Commons' bugs on Phabricator

Please note

• Feature or bug reports should be filed on Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).
• Have you read the FAQ?
  
  

 

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.

How to use temporal media fragments to link to audio chapters in file description?

With videos it is possible to specify a start (and end) time of the video – see Commons:Video#Temporal media fragments.

• Is it possible to link to times of the videos in the file description?
• Is that already possible somehow for audio files?

I think it would be very useful if in the file description of Spoken Wikipedia audio files, like those that I just uploaded, there were links to the different sections of the article. If one is only interested in a particular section of the article one could jump to it directly and listen to only that. It also gives some orientation where one is currently at when listening to articles. Linking to chapters is possible on YouTube and probably many users have already noticed some ways this can be useful. For example, I'd like to link the timestamps in the description here and add timestamp links to the different exercises here.

This doesn't seem to work with videos either as one would have to append ?start=00:26 but can only append things like #start=00:26. Is there some issue about these things? Prototyperspective (talk) 12:46, 22 August 2024 (UTC)

There isn't really a universal chapter methodology in HTML5 video. The HTML5 idea is that you create your own VTT file (which we don't yet support). These could refer to Commons link (they can be anything you like, as all support for it is completely custom work). Then you write custom Javascript to listen to the timedtext events, read the 'text' (a description and link in this case) and go do something with that (wrapped inside a videojs custom plugin).

Related tickets about this in phabricator. phab:T116154, phab:T301826. —TheDJ (talk • contribs) 18:08, 25 August 2024 (UTC)

You can link to start points in the file description page using start= and end= query params like:

File:Using_a_Power_Rack_in_bodybuilding,_powerlifting,_strength_training,_resistance_exercise.webm?start=00:10&end=00:15, but it is not that useful, as there is no autoplay etc. —TheDJ (talk • contribs) 18:14, 25 August 2024 (UTC)

• The two issues you linked don't seem to be related to this at all. What you wrote is about annotations like a link or a balloon message informing about an inaccuracy in the video at specific times of the video. In contrast this post here is about video chapters and linking to different times of the video in the file description.
• Yes, I know that one can link to start points that way and explicitly said that in the last paragraph. As said, one would need to link to these from there like #start=00:26 because when including a link like your example, it opens the video in a new tab at that starting point instead of directly jumping to it.
• This is really important for Spoken Wikipedia where you may like to jump to a particular section. There also needs to be some proper audio player, with the current one only being the fallback, that for example is wider so you can jump to some timing better and with a -10 seconds feature.

Prototyperspective (talk) 10:49, 26 August 2024 (UTC)

It generally needs a modern improved audio-player that has not only chapter/timestamp-link functionality, but also several other widely established standard features (one could use an existing open source audio player). Prototyperspective (talk) 10:54, 18 September 2024 (UTC)

Wishlist proposal for this now is here: meta:Community Wishlist/Wishes/Video & audio chapters (jump to timestamp). Prototyperspective (talk) 18:15, 16 October 2024 (UTC)

Better triage for users starting cfd

Quite often we see cfd like Commons:Categories for discussion/2024/09/Category:Deforestration in Turkey, which doesnt need cfd but a simple speedy tag, but MediaWiki:Gadget-AjaxQuickDelete.js doesnt currently have any info about this.

short term solution: add info to the popup so users can see the easier way before they start a cfd and copypaste the speedy tag.

long term solution: let the popup provide two modes for users to choose from: speedy and cfd.

the code to change is probably around MediaWiki:Gadget-AjaxQuickDelete.js#L-493. RoyZuo (talk) 12:24, 2 October 2024 (UTC)

It could be added explained on MediaWiki:Gadget-AjaxQuickDelete.js/DiscussCategoryInfo if that was displayed by default.
 ∞∞ Enhancing999 (talk) 09:14, 12 October 2024 (UTC)

How to search fields of files' Information template?

For example, how could one search file description for a term like "Kathmandu" (as asked about by another user here) like on can search with intitle. description:"Kathmandu" does show some results but I don't know what it does and the results don't have that word in their description. I could not find info on this at mw:Help:CirrusSearch either. Info how to search specified fields of {{Information}} should be added here.

One could also use this to infer categories (such as by reading the date field and then adding it to a category by date like "Videos of {year}") as proposed here. This may also be needed for a date range filter, see phab:T329961. I'd like to search the date field but there is no information on how to do that at Help:Searching but I think it's already possible if I remember correctly. For example, I found that many files in deepcategory:"NASA videos from unidentified year" deepcategory:"Videos of 2020‎" have been miscategorized into Videos of 2020 (and thus should not be copied into "NASA videos in 2020" from there) where they have the correct date in the date field which is why I'd like to use that to correct that as well as copy them to their year category in Category:Videos from NASA by year. Prototyperspective (talk) 19:03, 6 October 2024 (UTC)

• Another example: one could set subcats of Category:Media from scholarly journals depending on the link in the source field. For example, files with an URL starting with https://www.nature.com/ or a DOI that resolves to one should be in a respective subcat of Category:Media from Nature Publishing Group journals.
• One could also search the source field to put files into cats like Category:Audio files from Soundcloud.com and so on.

Prototyperspective (talk) 12:16, 10 October 2024 (UTC)

Here EBernhardson (WMF) said Unfortunately, the image description is simply an argument to a template. CirrusSearch doesn't do anything at that level and can't be that specific..

I think the best workaround currently would be to use the insource search operator with the field name first so for example I searched for insource:"|source=[https://soundcloud.com to identify files for Category:Audio files from Soundcloud.com. I think easily searching fields of the File pages' Information template could be enabled by

1. Developing some regex that searches for any content after e.g. |source=
2. Creating some alias for it so instead of writing some complex regex query every time one can simply enter e.g. info-source:"soundcloud.com"

Please comment what you think about this proposed way to make this possible and if you have any info on what would be needed for that. Prototyperspective (talk) 13:06, 23 October 2024 (UTC)

Bug? Preview of captions in diff and permalink shows wrong revision

Example: An edit to a file changed its [en] caption to "28th September 2024 Sunday", but the preview in its diff and permalink displays not that but another text: "An introduction to persistent identifiers as part of a FAIR data landscape", which is the caption from the latest revision (made in diff). Previews in diffs and permalinks should display their specified revision, not the latest. -- Wotheina (talk) 05:05, 7 October 2024 (UTC)

My guess is that it shows always the latest caption? Another note, the caption box is not visible with OS X and Safari browser when I am looking the old revisions of the file pages. --Zache (talk) 07:07, 7 October 2024 (UTC)

I think Wotheina's bug has confused me before too. Is there a Phabricator: task for it? I did a quick search but I am not the best at finding bugs there. Also the Safari bug should be filed too. Commander Keane (talk) 21:45, 23 October 2024 (UTC)

Tech News: 2024-41

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

• Communities can now request installation of Automoderator on their wiki. Automoderator is an automated anti-vandalism tool that reverts bad edits based on scores from the new "Revert Risk" machine learning model. You can read details about the necessary steps for installation and configuration. [1]

Updates for editors

• Translators in wikis where the mobile experience of Content Translation is available, can now customize their articles suggestion list from 41 filtering options when using the tool. This topic-based article suggestion feature makes it easy for translators to self-discover relevant articles based on their area of interest and translate them. You can try it with your mobile device. [2]
• View all 12 community-submitted tasks that were resolved last week.

Updates for technical contributors

• It is now possible for <syntaxhighlight> code blocks to offer readers a "Copy" button if the copy=1 attribute is set on the tag. Thanks to SD0001 for these improvements. [3]
• Customized copyright footer messages on all wikis will be updated. The new versions will use wikitext markup instead of requiring editing raw HTML. [4]
• Later this month, temporary accounts will be rolled out on several pilot wikis. The final list of the wikis will be published in the second half of the month. If you maintain any tools, bots, or gadgets on these 11 wikis, and your software is using data about IP addresses or is available for logged-out users, please check if it needs to be updated to work with temporary accounts. Guidance on how to update the code is available.
• Rate limiting has been enabled for the code review tools Gerrit and GitLab to address ongoing issues caused by malicious traffic and scraping. Clients that open too many concurrent connections will be restricted for a few minutes. This rate limiting is managed through nftables firewall rules. For more details, see Wikitech's pages on Firewall, GitLab limits and Gerrit operations.
• Five new wikis have been created:
  • a Wikipedia in Komering (w:kge:) [5]
  • a Wikipedia in Mooré (m:mos:) [6]
  • a Wiktionary in Madurese (wikt:mad:) [7]
  • a Wikiquote in Gorontalo (q:gor:) [8]
  • a Wikinews in Shan (n:shn:) [9]

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

MediaWiki message delivery 23:37, 7 October 2024 (UTC)

image updates

Hi all, the attached image here updates as the user uploads new version every day. I would like to put a version which is current at a particular time but does not update itself when the user uploads a new version. How can I do this? Thanks in advance. Gryllida (talk) 01:20, 8 October 2024 (UTC)

Another way to phrase this would be how to specify a version of a file when using a file from WMC in other Wikimedia projects like Wikipedia. This would also be very useful for Our World in Data datagraphics where one may want to show a particular year in some article but have this site not get flooded with 100 or so charts per subject and the file by default always be up to date. I'd like to know how the specify the file version as well and if it's not yet possible please link the code issue on phabricator if there is any. See also Category:Wikipedia updating. Prototyperspective (talk) 13:00, 8 October 2024 (UTC)

@Gryllida: As the template on File:Milton 2024 track.png says, "If you wish to use a specific version of the file without it being overwritten, please upload the required version as a separate file." So download the file as it currently is and upload it under a different name (for instance with the date and time at the end of the name). The fiddly bit will be getting the description right: you might be able to work out how to modify the description of the existing file to be appropriate for a static one, but I'd be inclined towards the lazy approach of just making a generic description using {{Information}} or the Upload Wizard. As long as you get the copyright information right, it should be fine. --bjh21 (talk) 14:38, 8 October 2024 (UTC)

I would use mapframe from mw:Help:Extension:Kartographer. You can add JSON to specify tracks, markers and colors.

Glrx (talk) 17:09, 8 October 2024 (UTC)

I don't think @Supportstorm has a json version for this? Gryllida (talk) 03:28, 9 October 2024 (UTC)

Bjh21 is correct in that if you want a specific version of the file it needs to be uploaded separately. These hurricane tracks get updated consistently until the final best track is published. I've experimented with the map extension before, but it's really restrictive in what track maps should be. I could export the dataframe in my code to json for a map, but I don't want to spend time making a map look "pretty." Someone else would need to do that. Supportstorm (talk) 05:01, 9 October 2024 (UTC)

It's not too hard to generate the JSON, but I can't see any way to make the markers show up on their own, without the upside-down-teardrop callouts. That style works fine for maps of locations of cities or whatnot, but it's not right for this type of map. Might need a feature request.

Example: Track of Hurricane Milton. (I haven't implemented full marker rendering in this demo; if this were the real thing the markers would be different shapes and would be colored.) Omphalographer (talk) 23:37, 10 October 2024 (UTC)

Misleading link to Phabricator for feature and bug requests?

Is the statement at the header of Commons:Village pump/Technical: Feature or bug reports should be filed on Phabricator misleading?

See discussion at phab T367888: I'd say the Commons is welcome to fix misleading statements on Commons:Village pump/Technical - it's up to each developer/maintainer where they prefer to maintain/plan their software and its feature requests or issues. :) Waddie96 (talk) 15:43, 11 October 2024 (UTC)

1. That developers could do so doesn't mean that they do so. 2. If they do so then it would not be this page but e.g. MediaWiki talk:Gadget-HotCat.js. 3. Code issues are often discussed here first before an issue is created and this is good for many reasons in various circumstances and for various kinds of issues.

However, it could be altered to say that this is about MediaWiki core and core tools managed through phabricator and one could also add that even such things can still be discussed here. Prototyperspective (talk) 17:49, 11 October 2024 (UTC)

Template:Numbercategory-vrp broken

The template needs some fixes, see Template talk:Numbercategory-vrp.
 ∞∞ Enhancing999 (talk) 07:36, 12 October 2024 (UTC)

Vector-2022 and night mode

I think it's time to make Wikimedia Commons switch both to Vector-2022 skin and enable the night mode for anonymous users, just like the English Wikipedia. Many Wikipedia's have Vector-2022 as the default skin and many more is getting it https://phabricator.wikimedia.org/T375549 and having night mode more exposed to regular contributors of Wikimedia Commons is essential to know we our file descriptions that are fetched to different Wikipedia languages are also compatible with night mode and latest UI changes of Wikipedia. −Ebrahim^talk 08:40, 12 October 2024 (UTC)

Has anything changed about Vector-2022's suitability for Commons? Otherwise we might as well wait for Vector-2025. Nightmode should be made available for all skins.
 ∞∞ Enhancing999 (talk) 09:11, 12 October 2024 (UTC)

100% support. switching will highlight the errors and will get people to fix them. Waiting is just delaying to do the same thing after the delay. —TheDJ (talk • contribs) 12:19, 14 October 2024 (UTC)

If it's already known to not work, better spare it then.
 ∞∞ Enhancing999 (talk) 14:36, 14 October 2024 (UTC)

Wikimedia Commons could be asked to be included to https://night-mode-checker.wmcloud.org/ also and then next step could be to start to fix the known errors. --Zache (talk) 16:45, 14 October 2024 (UTC)

Templates in description field cause empty caption in Media Viewer

Putting some templates inside description= field causes Media Viewer to display contents of the template (usually poorly able to describe what can be seen) instead of what is inside description=. See the problem in action: navigate to File:Bodegas de Mileștii Mici, Moldavia, 2023-11-02, DD 74.jpg, observe the nice description is there ('Wine cellars of Mileștii Mici'), click 'Open in Media Viewer' and you will be displayed only 'This file illustrates a cultural heritage monument in Moldova, ID' (additionally, ID will be cropped, but it's not that important).

Note the severity of the problem: every time a visitor clicks a photo on en.wikipedia.org, they execute the Media Viewer, and may see a confusing, broken caption like I gave as an example above. This is not the best User Experience. Another thing is that POTY voting page displays descriptions in the gallery of candidate pictures using the same logic.

What do you think? Derbeth ^talk 18:10, 13 October 2024 (UTC)

I also saw one more scenario, involving 'Captions' section. If you have a caption, and description= field is empty, Media Viewer correctly uses the caption. But I saw files where a caption was given but 'description' was just a template on cultural heritage. Or sometimes just {{Commonist}}. With such a form of 'description', Media Viewer replaces the useful caption with a generic text about cultural heritage, or even displays blank caption (probably in the case of commonist template, but I don't remember the exact situation). What should be the solution? Changing the page by copying caption to the 'description' field, alongside the template? Changing the page by moving the template outside of {{Information}}, for example just below it in the 'Summary' section? Changing Media Viewer to do some guessing and use 'Captions' instead of 'description' in case 'description' consists exclusively of some 'undesired' template, like cultural heritage, and nothing more (note how hard it's to implement when templates are created, removed and renamed)? --Derbeth ^talk 18:34, 13 October 2024 (UTC)

The same happens at Special:MediaSearch when selecting an image.

There was some discussion at Commons_talk:WMF_support_for_Commons/Upload_Wizard_Improvements about reducing clutter in "description=", but apparently, this is not a priority for WMF.
 ∞∞ Enhancing999 (talk) 19:20, 13 October 2024 (UTC)

Dear colleagues, after comparing various photos, I noticed that there are also monument templates that do not negatively affect the description in the Media Viewer and are displayed despite being placed in the summary field: e.g. 01, 02, 03 and 04. So this could be an indication that the cause lies in certain monument templates that need to be adjusted. But I could be wrong, it is just an indication that I noticed. Best regards, -- Radomianin (talk) 12:10, 14 October 2024 (UTC)

Addendum to the log: This discussion was preceded by a discussion on the colleague's user page. Best regards, -- Radomianin (talk) 09:33, 17 October 2024 (UTC)

One has "noprint noexcerpt" as classes, maybe one of them helps?
 ∞∞ Enhancing999 (talk) 14:20, 14 October 2024 (UTC)

I just checked that those classes alone don't help. I edited a template, checked File:Lodochnaya_stancia.jpg again, and both CSS classes appear in the web inspector, but the caption in MediaViewer is still the wrong one. Should be 'Boating station in Ukrainian city Kriviy Rig' (taken from 'Captions'), but is 'This is a photo of a natural heritage site in Ukraine' (template in 'description='). --Derbeth ^talk 08:22, 17 October 2024 (UTC)

I tried those classes too, but it doesn't seem to be sufficent. Maybe @TheDJ has further details on how it's generated.
 ∞∞ Enhancing999 (talk) 15:49, 18 October 2024 (UTC)

"Mediaviewer replaces it" Just a note, Mediaviewer does not such thing, the MetaData api does this. Of which Mediaviewer is simply the most prominent consumer. —TheDJ (talk • contribs) 12:12, 14 October 2024 (UTC)

Thanks for the explanation TheDJ. Would you like to help with reporting the bug to MediaWiki API in a way that gives the best chance it is picked for development? --Derbeth ^talk 08:22, 17 October 2024 (UTC)

Tech News: 2024-42

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 Structured Discussion extension (also known as Flow) is starting to be removed. This extension is unmaintained and causes issues. It will be replaced by DiscussionTools, which is used on any regular talk page. A first set of wikis are being contacted. These wikis are invited to stop using Flow, and to move all Flow boards to sub-pages, as archives. At these wikis, a script will move all Flow pages that aren't a sub-page to a sub-page automatically, starting on 22 October 2024. On 28 October 2024, all Flow boards at these wikis will be set in read-only mode. [10][11]
• WMF's Search Platform team is working on making it easier for readers to perform text searches in their language. A change last week on over 30 languages makes it easier to find words with accents and other diacritics. This applies to both full-text search and to types of advanced search such as the hastemplate and incategory keywords. More technical details (including a few other minor search upgrades) are available. [12]
• View all 20 community-submitted tasks that were resolved last week. For example, EditCheck was installed at Russian Wikipedia, and fixes were made for some missing user interface styles.

Updates for technical contributors

• Editors who use the Toolforge tool Earwig's Copyright Violation Detector will now be required to log in with their Wikimedia account before running checks using the "search engine" option. This change is needed to help prevent external bots from misusing the system. Thanks to Chlod for these improvements. [13]
• Phabricator users can create tickets and add comments on existing tickets via Email again. Sending email to Phabricator has been fixed. [14]
• Some HTML elements in the interface are now wrapped with a <bdi> element, to make our HTML output more aligned with Web standards. More changes like this will be coming in future weeks. This change might break some tools that rely on the previous HTML structure of the interface. Note that relying on the HTML structure of the interface is not recommended and might break at any time. [15]

In depth

• The latest monthly MediaWiki Product Insights newsletter is available. This edition includes: updates on Wikimedia's authentication system, research to simplify feature development in the MediaWiki platform, updates on Parser Unification and MathML rollout, and more.
• The latest quarterly Technical Community Newsletter is now available. This edition include: research about improving topic suggestions related to countries, improvements to PHPUnit tests, and more.

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

MediaWiki message delivery 21:16, 14 October 2024 (UTC)

CategoryTree arrows

Since yesterday, I see all CategoryTree arrows in grey, even for categories with subcategories. They are still clickable, but they appear to be grey. Only blue arrows that remain are those with sub-sub-categories. How can it be fixed? Is it this issue? — Draceane ^talk_contrib. 07:48, 18 October 2024 (UTC)

Do you still have this problem? If so please link an example. I see blue expandable arrows at categories with subcategories. Prototyperspective (talk) 10:51, 18 October 2024 (UTC)

Ok, it's probably just me... Safemode works well. Could be connected to the recent Cat-a-lot update? — Draceane ^talk_contrib. 11:15, 18 October 2024 (UTC)

Wikidata link maintenance category does not update

I am working on the maintenance category Category:Cultural heritage monuments in Berlin without linked Wikidata and noticed that even after purging and null edit to category page and template the category members are not updated many hours after they were linked to Wikidata. Are there any ideas on the reason and suggestions how to solve this? GPSLeo (talk) 08:21, 18 October 2024 (UTC)

Normally null edits to category page connected to the Wikidata item work. In general, it's the issue discussed at User_talk:Mike_Peel#Infoboxes_missing_(2024-10).
 ∞∞ Enhancing999 (talk) 18:30, 18 October 2024 (UTC)

W3C validator has been basically down for months

Where I and these folks are from, we cannot use the link provided by {{Valid SVG}}. The validator always says "429: Too many requests". The page loads, but the "external validation service" doesn't. Aaron Liu (talk) 20:47, 19 October 2024 (UTC)

The link may fail for many reasons. I'm often run into the problem of unable to validate because the DOCTYPE is not known; I just select SVG 1.1 and ignore the minor errors.

Chealer reports failure for File:Netscape_icon.svg. That file did not have {{Valid SVG}} or {{Igen}}, so I added them and {{Invalid SVG}}.

Igen created a working URL that said the file was valid

• https://validator.w3.org/check?uri=https%3A%2F%2Fcommons.wikimedia.org%2Fwiki%2FSpecial%3AFilepath%2FNetscape_icon.svg&doctype=Inline&ss=1

{{Valid SVG}} gave the message that validity was not checked. That suggests a broken template.

{{Invalid SVG}} said the file was invalid (that's its job), but the URL said it was valid.

• https://validator.w3.org/check?uri=https%3A%2F%2Fcommons.wikimedia.org%2Fwiki%2FSpecial%3AFilepath%2FNetscape_icon.svg&doctype=Inline&ss=1

That link is the same as above. However, a second click complained "Sorry! This document cannot be checked." The problem was the external checker was not available.

Note: I can do a control-Reload and sometimes get a good result.

The previous succeeding checks used SVG 1.1 + xHTML + MathML, but the failing clicks did not recognize a Document type. However, I could select "SVG 1.1" and revalidate resulting in the URL

• https://validator.w3.org/check?uri=https%3A%2F%2Fupload.wikimedia.org%2Fwikipedia%2Fcommons%2F0%2F08%2FNetscape_icon.svg&charset=%28detect+automatically%29&doctype=SVG+1.1&ss=1&group=0&user-agent=W3C_Validator%2F1.3+

The new URL reports 46 errors and 1 warning. The inkscape and rdf namespaces are not treated as warnings.

Somebody may be limiting the requests or there may be a race condition that the Nu validator does not respond quickly enough.

First, I think it is poor practice for the templates to use uri=https%3A%2F%2Fcommons.wikimedia.org%2Fwiki%2FSpecial%3AFilepath%2FNetscape_icon.svg.

The more direct method would use

• {{filepath:Netscape icon.svg}} → https://upload.wikimedia.org/wikipedia/commons/0/08/Netscape_icon.svg
• https://validator.w3.org/check?uri=https://upload.wikimedia.org/wikipedia/commons/0/08/Netscape_icon.svg&doctype=Inline&ss=1

But that validation fails for files without a DOCTYPE. Supply an explicit SVG 1.1:

• https://validator.w3.org/check?uri=https://upload.wikimedia.org/wikipedia/commons/0/08/Netscape_icon.svg&doctype=SVG+1.1&ss=1

Which, of course, does not recognize inkscape or rdf namespaces because they are not in the SVG 1.1 DTD and reports dozens of errors.

Perhaps the doctype parameter was used to encourage switching to the Nu validator. Here's the URL without the parameter.

• https://validator.w3.org/check?uri=https://upload.wikimedia.org/wikipedia/commons/0/08/Netscape_icon.svg&ss=1

That URL fails with the external checker not being available.

Second, the problem seems to be the validator wants to hand off the request to the Nu validator. It may do this when the SVG file does not have a DOCTYPE.

The GitHub issue used the W3C Nu validator, https://validator.w3.org/nu/ , directly. The Special URL was not an issue.

Instead of using that, go directly to Nu. Chealer offers

• https://validator.nu/?doc=https://upload.wikimedia.org/wikipedia/commons/archive/b/bd/20060301044618%21Flag_of_Cuba.svg&group=1&schema=http%3A%2F%2Fs.validator.nu%2Fsvg-xhtml5-rdf-mathml.rnc+http%3A%2F%2Fs.validator.nu%2Fhtml5%2Fassertions.sch+http%3A%2F%2Fc.validator.nu%2Fall%2F&parser=xml&showsource=1#result

That old version of the file has a DOCTYPE, so the old W3C validator does a reasonable validation:

• https://validator.w3.org/check?uri=https://upload.wikimedia.org/wikipedia/commons/archive/b/bd/20060301044618%21Flag_of_Cuba.svg&ss=1

The current version of File:Flag of Cuba.svg does not have an XML processing instruction or a DOCTYPE. Force SVG 1.1

• https://validator.w3.org/check?uri=https://upload.wikimedia.org/wikipedia/commons/b/bd/Flag_of_Cuba.svg&doctype=SVG+1.1&ss=1

Conceivably, SVG 1.1 could be forced all the time, but that raises numerous inkscape and rdf errors.

Conclusion. I would use the Nu validator without the schema parameter.

• https://validator.nu/?doc=https://upload.wikimedia.org/wikipedia/commons/0/08/Netscape_icon.svg&showsource=1
• https://validator.nu/?doc=https://upload.wikimedia.org/wikipedia/commons/b/bd/Flag_of_Cuba.svg&showsource=1
• https://validator.nu/?doc=https://upload.wikimedia.org/wikipedia/commons/archive/b/bd/20060301044618%21Flag_of_Cuba.svg&showsource=1

Glrx (talk) 17:36, 22 October 2024 (UTC)

Tech News: 2024-43

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 Mobile Apps team has released an update to the iOS app's navigation, and it is now available in the latest App store version. The team added a new Profile menu that allows for easy access to editor features like Notifications and Watchlist from the Article view, and brings the "Donate" button into a more accessible place for users who are reading an article. This is the first phase of a larger planned navigation refresh to help the iOS app transition from a primarily reader-focused app, to an app that fully supports reading and editing. The Wikimedia Foundation has added more editing features and support for on-wiki communication based on volunteer requests in recent years.

iOS Wikipedia App's profile menu and contents

Updates for editors

• Wikipedia readers can now download a browser extension to experiment with some early ideas on potential features that recommend articles for further reading, automatically summarize articles, and improve search functionality. For more details and to stay updated, check out the Web team's Content Discovery Experiments page and subscribe to their newsletter.
• Later this month, logged-out editors of these 12 wikis will start to have temporary accounts created. The list may slightly change - some wikis may be removed but none will be added. Temporary account is a new type of user account. It enhances the logged-out editors' privacy and makes it easier for community members to communicate with them. If you maintain any tools, bots, or gadgets on these 12 wikis, and your software is using data about IP addresses or is available for logged-out users, please check if it needs to be updated to work with temporary accounts. Guidance on how to update the code is available. Read more about the deployment plan across all wikis.
• View all 33 community-submitted tasks that were resolved last week. For example, the South Ndebele, Pannonian Rusyn, Obolo, Iban and Tai Nüa Wikipedia languages were created last week. [16][17][18][19][20]
• It is now possible to create functions on Wikifunctions using Wikidata lexemes, through the new Wikidata lexeme type launched last week. When you go to one of these functions, the user interface provides a lexeme selector that helps you pick a lexeme from Wikidata that matches the word you type. After hitting run, your selected lexeme is retrieved from Wikidata, transformed into a Wikidata lexeme type, and passed into the selected function. Read more about this in the latest Wikifunctions newsletter.

Updates for technical contributors

• Users of the Wikimedia sites can now format dates more easily in different languages with the new {{#timef:…}} parser function. For example, {{#timef:now|date|en}} will show as "6 November 2024". Previously, {{#time:…}} could be used to format dates, but this required knowledge of the order of the time and date components and their intervening punctuation. #timef (or #timefl for local time) provides access to the standard date formats that MediaWiki uses in its user interface. This may help to simplify some templates on multi-lingual wikis like Commons and Meta. [21][22]
• Commons and Meta users can now efficiently retrieve the user's language using {{USERLANGUAGE}} instead of using {{int:lang}}. [23]
• The Product and Tech Advisory Council (PTAC) now has its pilot members with representation across Africa, Asia, Europe, North America and South America. They will work to address the Movement Strategy's Technology Council initiative of having a co-defined and more resilient technological platform. [24]

In depth

• The latest quarterly Growth newsletter is available. It includes: an upcoming Newcomer Homepage Community Updates module, new Community Configuration options, and details on new projects.
• The Wikimedia Foundation is now an official partner of the CVE program, which is an international effort to catalog publicly disclosed cybersecurity vulnerabilities. This partnership will allow the Security Team to instantly publish common vulnerabilities and exposures (CVE) records that are affecting MediaWiki core, extensions, and skins, along with any other code the Foundation is a steward of.
• The Community Wishlist is now testing machine translations for Wishlist content. Volunteers can now read machine-translated versions of wishes and dive into discussions even before translators arrive to translate content.

Meetings and events

• 24 October - Wiki Education Speaker Series Webinar - Open Source Tech: Building the Wiki Education Dashboard, featuring Wikimedia interns and a Web developer in the panel.
• 20–22 December 2024 - Indic Wikimedia Hackathon Bhubaneswar 2024 in Odisha, India. A hackathon for community members, including developers, designers and content editors, to build technical solutions that improve contributors' experiences.

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

MediaWiki message delivery 20:48, 21 October 2024 (UTC)

Category:Pages using the JsonConfig extension

This just materialized on a file I was editing, so I quickly turned the red link blue and found that it's popped up on 800+ files. What is this? Why is it here? —Justin (koavf)❤T☮C☺M☯ 16:05, 24 October 2024 (UTC)

I noticed this too. I got as far as figuring out that {{#invoke:ISOdate|ISOdate|1=2006-07-24}} adds the category. I'm not too versed in Lua modules, so can't really continue the hunt. Cryptic-waveform (talk) 19:02, 24 October 2024 (UTC)

And so does {{#invoke:DateI18n|Date|year=2000|month=1|day=1}}. Cryptic-waveform (talk) 19:06, 24 October 2024 (UTC)

May be related to https://github.com/wikimedia/mediawiki-extensions-JsonConfig/commit/db05e3251393d734605d20c98a63dbd7f93d9426. Cryptic-waveform (talk) 19:13, 24 October 2024 (UTC)

@Cscott: Is this related to your change? And is it a desired outcome? Cryptic-waveform (talk) 19:15, 24 October 2024 (UTC)

@Koavf, @Cryptic-waveform & @Cscott - FYI, I used the CropTool today and the extracted photo file has the this same hidden category as the the original photo file here: File:Zheng Jianbang in 2023 (cropped).jpg.

• 1. Does this category still apply to cropped images extracted from files within this new category?
• 2. Was a there any "notice" or other advance communication about this small, but highly noticable "hidden" category? -- Ooligan (talk) 22:11, 24 October 2024 (UTC)

1. I guess? ¯\_(ツ)_/¯
2. No.

—Justin (koavf)❤T☮C☺M☯ 22:34, 24 October 2024 (UTC)

Related: https://en.wikipedia.org/wiki/Wikipedia:Categories_for_discussion/Log/2024_October_24#Category:Pages_using_the_JsonConfig_extension. Cryptic-waveform (talk) 19:21, 24 October 2024 (UTC)

See also mw:Extension:JsonConfig. No idea why this is something that needs to be tracked. —Justin (koavf)❤T☮C☺M☯ 19:43, 24 October 2024 (UTC)

• Could someone please have a look at Commons:Categories for discussion/2024/10/Category:Nazi symbols status and Nazi symbols status. This category should be empty but it's weirdly populated. Files in this category have the category Pages using the JsonConfig extension. Is this in any way related to this? Ratekreel (talk) 07:55, 6 November 2024 (UTC)

Requested fix

Commons:Administrators'_noticeboard#Interface_admin_request. —Justin (koavf)❤T☮C☺M☯ 22:38, 24 October 2024 (UTC)

The category is empty now. Good to delete? _Regards, Aafi ^(talk) 13:46, 5 November 2024 (UTC)

Perhaps also good to keep a look at phab:T378352. _Regards, Aafi ^(talk) 13:47, 5 November 2024 (UTC)

Emptying was predicted to complete at the end of december. File File:Chrysalis5504.jpg had Category:Pages using the JsonConfig extension and it was red, whereas the cat itself was empty. No change after "null edit". Fixed after real edit. Now nazi file File:Deutsches_Reichsgesetzblatt_33T1_126_0846.jpg has that cat (see above). Strange. Taylor 49 (talk) 19:29, 6 November 2024 (UTC)

File:Deutsches_Reichsgesetzblatt_33T1_126_0908.jpg pretends to be in "Category:Pages using the JsonConfig extension" (red and empty, should NOT be there) and in "Category:Nazi symbols" (OK), OTOH it does NOT show "Category:Nazi symbols status", but when looking into that cat, it is listed there. Commons is severely broken today. Taylor 49 (talk) 19:34, 6 November 2024 (UTC)

Should Template:Compressed version be used with Lossy WebP?

It's unclear to me what the role of Template:Archival version is now in 2024. Although it makes a lot of sense in a world where GIF, PNG, and JPEG were the "Big Three" commonly supported image formats on the web (ignoring BMP, which I think did enjoy an era of support most associated with the early web), it seems a bit technical whether or not the Template:Archival version & Template:Compressed version templates should still be used on new uploads today with the advent of WebP.

I'm not an expert, but I think modernly, Mediawiki is happy to take PNG and shunt it to WebP automatically, as a display format that saves bandwidth without conscious change of workflow on part of the user. The transparent nature of these bandwidth savings is less applicable to JPEG (which can also be automatically converted to WebP for bandwidth savings), but when that's done, the converted WebP still must deal with the limitations of the legacy JPEG format. Namely: lack of support for alpha transparency, and converting lossy-to-lossy (necessarily degrading the image, versus if the user had just embraced lossy WebP to begin with).

I'm new to Wikimedia, and trying to determine the best way to upload my images so that:

1. Pages that include my images continue to load fast
2. My images are stored at the highest resolution possible and in the best quality possible

To satisfy both of these goals, I thought I should hijack Template:Archival version and Template:Compressed version as an "existing structure" and seemingly "best practice" put into place during an era when it was expected that the Template:Compressed version would be a JPEG. Lending legitimacy to this, the Template has a (deprecated) field named "Filetype", implying that at least in the past, it was appropriate to use the template with more than just JPEG images.

So I went ahead and tried it:

• Archive version: File:Connection Machine CM-2 and DataVault at Computer Museum of America.png
• Compressed version: File:Connection Machine CM-2 and DataVault at Computer Museum of America.webp

However, there are currently a few problems with this.

1. Although Template:Compressed version claims filetype can be omitted and then defaults to an "intelligent guess", it seems that in reality, it has not been able to detect usage of the template with WebP, and instead defaults to the text to "This image is a JPEG version [...]" when used with WebP. If this is a valid usecase of the template, the text can be changed to support detection of WebP easily enough.
2. Although I hoped that by using WebP for the compressed thumbnail version instead of JPEG I would gain access to alpha transparency (improving dark mode support on Wikipedia), it seems that the thumbnail generated at w:Connection Machine filled the transparency with the colour white, which is especially unfortunate for this primarily black object where it is hard to discern detail against a white background. Although in this specific case, I may want to consider a permanently dark background to set this object against instead of transparency, it can be imagined that there are cases where it would be nice for thumbnails to adapt to Light Mode and Dark Mode versions of Wikipedia.
   I am told that the lack of support for transparent thumbnails of WebP images is caused by "Phab:T283646 which leads to this ImageMagick issue" but I wonder if it might also have been done on purpose, to avoid issues where people have uploaded transparent images in the era of Wikipedia not supporting dark mode, not expecting them to be set against anything other than a white background...
3. I'm not completely sure that any of this makes sense for me to worry about, and perhaps it is actually fine to upload only a 60 MB PNG and let Mediawiki worry about bandwidth efficiency. I need to check in with people more familiar with the technology involved, which is what I'm doing right now here at the Village Pump.

I would note that Mediawiki doesn't seem to be doing a great job with my 60 MB PNG, still serving it as a 4 MB thumbnail image at least in File: namespace, while the WebP I uploaded is 2 MB at full resolution (barely discernible loss of quality), is converted to a 1.13 MB PNG for display in File: namespace, a 75% savings.

I'd note it is a little frustrating that it converted my WebP to PNG, but I suppose this was done to ensure compatibility. https://caniuse.com/webp claims WebP support is up to 95.69% among browsers that are currently used. The remaining 4.3% is still a sizable portion to support, especially in the context of Wikipedia, but it seems like it would at least be possible to read my useragent and determine that like almost all browsers released in the past 5 years, my browser supports WebP and can be served a smaller file.

In summary, please leave your thoughts on if using Lossy WebP in Template:Compressed version is valid and useful, or if there is some better technical way going forward, such as uploading only a Lossless WebP (which unlike PNG, does properly support photo metadata). —Hubcapp^(talk) 18:37, 25 October 2024 (UTC)

1. {{Archival version}} is to indicate "don't mess with this, so that others can mess with the same reference at a later time". Now we could say that this is somewhat dated, as we already don't allow most people to change the version of an image, asking people to upload them separately.

2. Storing VERY high resolution images, means that the thumbnail has to take a huge leap from large to small. And it needs to do this with settings that are 'OK' for most of the images. This at times can result in suboptimal results. For that reason, it may be better to make your own slightly smaller version, applying self selected settings, and then uploading that smaller version of the file, for 'general use' in the Wikipedia, where often images get downscaled to something like 220px or smaller. However, in MOST cases, the images aren't used that widely and that critical that this is warranted, and it can always be done later.

3. Compressed version: This template indeed was not handling webp. I have updated its dependency to provide support for this.

4. In general, you should not worry about data and bandwidth usage. Where required and useful, as well as permitting time and money, the engineers will use newer technologies as they become ubiquitously available. In many cases having a simpler more 'wasteful' flow, makes up by being way faster and easier to manage and understand in the short term. (At the same time, this is not a license for uploading multi gigabyte files with little value and/or use). —TheDJ (talk • contribs) 15:44, 29 October 2024 (UTC)

Re 2.: There exists Template:No scaled down dupes, which implies it is improper to upload a lower resolution version of an image. Do you mean it's actually OK to upload a "smaller" version (in terms of resolution), or by "smaller" did you mean "more optimally compressed but still at full resolution"? And to clarify, you're saying that the Archival/Compressed versions dichotomy is in fact still useful for new uploads (but generally only for very high traffic images where it matters more)?

Re 3.: Thank you for clarifying it's OK to use WebP in Template:Compressed version and providing support for it!

Re 4.: Is it perhaps a good idea to upload *only* Lossless WebP? In my case, the resolution of my camera is roughly 6000 by 4000, so I'm not in multi-gig territory. However "Very Large Image" seems to be both a matter of opinion, and a definition that has changed as technology has advanced.

Thanks, —Hubcapp^(talk) 02:34, 30 October 2024 (UTC)

Wikimaps Warper edits not working

Somehow Special:OAuthListConsumers/view/d3308b00209d49e5a1d764aee019f83c stopped working for me. The tool sets the bounding box for maps depending on definitions of control points at https://warper.wmflabs.org . It's unclear who currently maintains the tool. @Chippyy: seems inactive.

For several, including Here, I had to complete the infobox fields manually. It doesn't seem to be a problem of the other content on file description pages, as this didn't get updated either.

It does work for @Kognos at [25] and a few other contributors [26].
 ∞∞ Enhancing999 (talk) 10:19, 27 October 2024 (UTC)

Also, it doesn't appear to depend on the absence of SDC statements: [27] failed too.

It doesn't seem to work for other users any more either: [28] by @Groupsixty.
 ∞∞ Enhancing999 (talk) 11:25, 27 October 2024 (UTC)

I'm afraid I have no idea why it's not working for others. I have had problems with the warper in the past, but it has been working OK, if sometimes a bit slow, recently. As you have noticed, I use the warper quite a lot. I set the template to Map, then click on the "Georeference..." button. If I am not currently logged on to the warper I get a logon page, select log on through Commons, then allow Oauth. I then georeference the map, and the bounds are automatically updated. I guess this is no different from what others are trying to do. I agree that the lack of any clear path to support is frustrating. I have been quite unclear in the past as to where any requests for help should be posted, and have had little success in getting support. The Wikimaps Warper category is useful, but there is still no indication as to who actually owns the project. Any enlightenment appreciated! Kognos (talk) 18:09, 28 October 2024 (UTC)

Maybe it's a browser issue, It used to work for me last year. The category is at Category:Wikimaps Warper.
 ∞∞ Enhancing999 (talk) 18:39, 28 October 2024 (UTC)

@Susannaanas do you know who is maintaining wikimaps warper? --Zache (talk) 18:27, 28 October 2024 (UTC)

Can category content be viewed by date?

Hi. Category content is always sorted by alphabet as the default. This can be unconvenient when parts of series become scattered all over the list. Is it possible or could it be possible to overview the contents by date at the push of a button? This would be pretty neat. I will give two examples : 1 sorted by alphabet and 2 sorted by date, (more coherent). As you can see this link is very long and can be hard to put into a short working link (such as a text button). I would like (the option) to keep the layout ot example 1 in favor of listed as in 2, because it shows images next to eachother and gives overall a better overview per viewed segment of pages, like as if looking trough a category. This project idea would make the category contents available, to more people in a more appealing format, to have series more or less grouped by upload-date, and not scattered by alphabet. This would be more ergonomic and visually intuitive. Can this be done? Thanks. Peli (talk) 14:26, 28 October 2024 (UTC)

Currently if you enable Help:Gadget-DeepcatSearch it lets you 1 click to a deepcat search of the cat you are viewing. with a few more clicks you can get to a sorted-by-upload-date list.

i have considered expanding its functionality to include more direct links to oldest-first, newest-first... lists.

it's also not difficult to make some user js to make those links. RoyZuo (talk) 14:48, 28 October 2024 (UTC)

Honestly, having a one-click sort by date would be super appreciated. I could only wish to have the ability to make custom js. — Huntster (t @ c) 17:46, 28 October 2024 (UTC)

Ah cool. But it would not be available to all visitors unless they install it? I wanted to do a post script of previous request. :: Earlier trials to install it on that page failed, but now the link is on the page. This fixes my issue, and keeps this as wanted extention to all cat pages if possible in any way. To me this sorting method means a incredible release of the pressure to rush to categorize everything (over 100k items) just to be able to overlook some parts of this material as more coherent series. Especially now the tool Cat-a-lot has become a much too slow tool for this scale projects. Thanks. I had that gadget enabled and just now explored the sort options, seems to work well to find other points of departure to explore this huge 'unsorted' category. Peli (talk) 14:26, 28 October 2024 (UTC)

• I think it would be great if that gadget would be enabled by default. However, for that to happen the deepcategory problems (at least phab:T376440) would need to be solved.
• The link currently shows items directly in the category as well as in subcategories – if you only want to see items directly in the category, change "deepcategory" to "incategory".
• Another issue is that one can only sort by upload date, but not by date of what's in the media file (the date field in the file's {{Information}}) – see e.g. phab:T329961 and the things linked there. Cat-a-lot has recently been improved so should be faster again.

Prototyperspective (talk) 21:43, 28 October 2024 (UTC)

If you want to sort by date, ppl need to get on the CommonsData bandwagon, because that is the only way that will ever become a reality. —TheDJ (talk • contribs) 15:18, 29 October 2024 (UTC)

Disagree. What would be needed is to make use of the Information template – see #How to search fields of files' Information template?. I don't care whether the data from that template is 1. read and written to structured data and 2. kept in sync with structured data or whether it can be searched another way, I just disagree that this is required and also see an issue where this data would need to be written to over 100 million files and thus may not be feasible while one can already search data in the file information template via insource which could readily be improved upon. (If it doesn't become a reality otherwise, that is because of ideology and/or having invested much into a somewhat redundant techcomponent that makes it hard for some to see or consider, possibly–likely better, alternatives.) Prototyperspective (talk) 16:44, 29 October 2024 (UTC)

Is that (whatever it means or implies) really needed, just to find out the upload-date? This can be done already in special search. Pelikana (talk) 15:29, 29 October 2024 (UTC)

No, the comment was about the date the media was recorded. I think I overread "upload-date" and the title was unclear on whether you mean upload-date or date the file was taken but it's also relevant in general so I thought it was relevant enough to mention. Prototyperspective (talk) 16:50, 29 October 2024 (UTC)

@TheDJ do you mean sdc or...? RoyZuo (talk) 19:06, 1 November 2024 (UTC)

Ok. tx Any way to get around alphabetical order can be helpful in some huge unsorted categories. On smaller cats and sorted cats by crafted sortkeys the option would be needless and to be avoided. Maybe it could be just an optional piece of code to put in the header of the most relevant huge unsorted categories. I have another topic to ask attention for, it is on the [talk page of visual file change]. Open question and request about scrolling by keyboard. Peli (talk) 10:21, 31 October 2024 (UTC)

Requested more than a decade ago (phab:T71417) and triaged as "Low" priority. 😒 — Draceane ^talk_contrib. 20:16, 1 November 2024 (UTC)

The API also supports by date added to the category (Not neccessarily the same thing as date created) - https://commons.wikimedia.org/w/api.php?action=query&list=categorymembers&cmtitle=Category:Uncategorized_images_of_the_Rijksmuseum&cmsort=timestamp&cmlimit=max . In theory it would be easier to add support for sorting categories in that way than other forms of sort by "date". Someone would still have to do it though. Bawolff (talk) 06:31, 4 November 2024 (UTC)

That would also be very useful. Maybe that should be added to that linked phab issue? I don't think it would be as useful as sorting by date taken however. Prototyperspective (talk) 10:54, 4 November 2024 (UTC)

Upload Wizard very slow

Tracked in Phabricator
Task T378276
DUPLICATE

Tracked in Phabricator
Task T378385
RESOLVED

Tracked in Phabricator
Task T379035

For the past few days, Upload Wizard has been very slow. Uploads that used to take secs now take mins. The behaviour I see: when I start uploads, it runs at 1-2 MB/sec for a few seconds. Then it slows down to < 1KB/sec for long periods. Intermittently, there is a burst of 1-2 MB/sec for a few seconds.
When I use chunked upload for a new version of a file, with chuck size 4 MB, the chunks upload fast, but then finishing and posting takes several minutes.
Others have reported similar issues @廣九直通車 and MPF: . Would appreciate any suggestions and help. Tagooty (talk) 14:51, 28 October 2024 (UTC)

I just uploaded 3 images with Upload Wizard, each with around 10MB size. It took me almost 9 minutes to upload, compose and queue the files, and after populating the files with descriptions and categories, it takes me another 3 minutes to finish the whole upload procedure. Moreover, during the first 9 minutes, I remember Upload Wizard reported errors with server connection. What's the problem? Should I send the matter to Phabricator?廣九直通車 (talk) 08:04, 29 October 2024 (UTC)

Dito, also have errors when uploading larger files --PantheraLeo1359531 😺 (talk) 08:08, 29 October 2024 (UTC)

Interestingly, I also tried direct upload from Flickr. Everything works perfectly fine in this case. Interesting...廣九直通車 (talk) 10:08, 29 October 2024 (UTC)

Today, I'm unable to upload any picture with Upload Wizard. I have opened a new thread on a help page about it. -- Jakubhal 17:33, 29 October 2024 (UTC)

Hi all, I would suggest you to open a Phabricator ticket about the problems you're having, and then kindly link it back to me, so that I could solicitate some action from the devs. Is it possible? Sannita (WMF) (talk) 18:43, 29 October 2024 (UTC)

I guess this is phab:T378276 Bawolff (talk) 02:50, 31 October 2024 (UTC)

Well, as of 31 October, it appears that the problem is largely solved. Just uploaded a total of 55MB of files, and the process is smooth. This thread may be kept in case things break again, however.廣九直通車 (talk) 08:29, 31 October 2024 (UTC)

Seems like the underlying cause is phab:T378385. Basically, the upload wizard (chunked upload) jobs share infrastructure with other jobs that only get triggered rarely. All of a sudden flagged revisions extension started making a lot of a type of job that normally does not get triggered very often. This meant that the UploadWizard jobs had to wait for those to complete first, slowing things down. It seems like that situation resolved, so upload wizard should be back to normal now. Bawolff (talk) 21:27, 31 October 2024 (UTC)

Sounds like weird planning when batch jobs meant to do stuff in off-hours to reduce load for day-to-day operations in one wiki sink regular operations in another wiki.
 ∞∞ Enhancing999 (talk) 07:13, 1 November 2024 (UTC)

Similiarly: phab:T378385#10282871
 ∞∞ Enhancing999 (talk) 22:33, 1 November 2024 (UTC)

Tech News: 2024-44

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

• Later in November, the Charts extension will be deployed to the test wikis in order to help identify and fix any issue. A security review is underway to then enable deployment to pilot wikis for broader testing. You can read the October project update and see the latest documentation and examples on Beta Wikipedia.
• View all 32 community-submitted tasks that were resolved last week. For example, Pediapress.com, an external service that creates books from Wikipedia, can now use Wikimedia Maps to include existing pre-rendered infobox map images in their printed books on Wikipedia. [29]

Updates for technical contributors

• Wikis can use the Guided Tour extension to help newcomers understand how to edit. The Guided Tours extension now works with dark mode. Guided Tour maintainers can check their tours to see that nothing looks odd. They can also set emitTransitionOnStep to true to fix an old bug. They can use the new flag allowAutomaticBack to avoid back-buttons they don't want. [30]
• Administrators in the Wikimedia projects who use the Nuke Extension will notice that mass deletions done with this tool have the "Nuke" tag. This change will make reviewing and analyzing deletions performed with the tool easier. [31]

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

MediaWiki message delivery 20:52, 28 October 2024 (UTC)

Russian txt in English field

Is it possible to automatically switch all the descriptions created by Aleksandr Patil from English to Russian? He apparently is not aware that he is using the English field. Hjart (talk) 21:09, 1 November 2024 (UTC)

I guess we need a friendly bot owner. Ymblanter (talk) 21:55, 1 November 2024 (UTC)

How to copy texts from Wikipedia articles via browser automatically?

Illustration of process I'm looking to automate more

Does somebody know how to automatically fetch Wikipedia article content into local files? The caveat here is that the API probably can't be used since the content is modified via CSS based on the CSS classes of the text content. Scraping the full HTML files and then converting these to text locally after the CSS modifications would probably be too difficult – I think automating the browser would be easier and maybe there are further methods.
The content I'm looking to copy is the article contents up to the See also/Notes/References section. It would be best if all tables removed via hiding their CSS classes mark the file somehow so depending on the table one can insert the table in list format manually (this is under development, it would be best if it automatically converted tables or added a note that 'Table XYZ is not included here'). Prototyperspective (talk) 12:27, 3 November 2024 (UTC)

Template:LicenseReview, where to find the dropdown menu messages?

Hello,

as a license reviewer, I'll have the option to click either "[license +]" or "[license -]". On "license -", I get a dropdown choice of different options, like "all rights reserved" or "non-commercial". Where are these text strings located? Where is a good place to ask for additions to them (maybe here?)? I'd like to have something like License review failed -> Reason: "Source link dead & archived versions unusable." to document the reality. Regards, Grand-Duc (talk) 22:01, 3 November 2024 (UTC)

Tech News: 2024-45

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

• Stewards can now make global account blocks cause global autoblocks. This will assist stewards in preventing abuse from users who have been globally blocked. This includes preventing globally blocked temporary accounts from exiting their session or switching browsers to make subsequent edits for 24 hours. Previously, temporary accounts could exit their current session or switch browsers to continue editing. This is an anti-abuse tool improvement for the Temporary Accounts project. You can read more about the progress on key features for temporary accounts. [32]
• Wikis that have the CampaignEvents extension enabled can now use the Collaboration List feature. This list provides a new, easy way for contributors to learn about WikiProjects on their wikis. Thanks to the Campaign team for this work that is part of the 2024/25 annual plan. If you are interested in bringing the CampaignEvents extension to your wiki, you can follow these steps or you can reach out to User:Udehb-WMF for help.
• The text color for red links will be slightly changed later this week to improve their contrast in light mode. [33]
• View all 32 community-submitted tasks that were resolved last week. For example, on multilingual wikis, users can now hide translations from the WhatLinksHere special page.

Updates for technical contributors

• XML data dumps have been temporarily paused whilst a bug is investigated. [34]

In depth

• Temporary Accounts have been deployed to six wikis; thanks to the Trust and Safety Product team for this work, you can read about the deployment plans. Beginning next week, Temporary Accounts will also be enabled on seven other projects. If you are active on these wikis and need help migrating your tools, please reach out to User:Udehb-WMF for assistance.
• The latest quarterly Language and Internationalization newsletter is available. It includes: New languages supported in translatewiki or in MediaWiki; New keyboard input methods for some languages; details about recent and upcoming meetings, and more.

Meetings and events

• MediaWiki Users and Developers Conference Fall 2024 is happening in Vienna, Austria and online from 4 to 6 November 2024. The conference will feature discussions around the usage of MediaWiki software by and within companies in different industries and will inspire and onboard new users.

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

MediaWiki message delivery 20:46, 4 November 2024 (UTC)

Please fix the Edit summary link

When editing a page the link above the edit summary link to meta:Special:MyLanguage/Help:Edit summary but that page is now a redirect. Please change that link to its new target. Links to redirects should be avoided in general but it's also a problem if one has enabled to see redirect pages. It seems like that page is not redirect anyway and only has the note "This page has been moved to Help:Edit summary on mediawiki.org.". Prototyperspective (talk) 13:44, 5 November 2024 (UTC)

@Prototyperspective: You might want to submit an edit request on MediaWiki:Summary (and possibly MediaWiki:Summary/cs, MediaWiki:Summary/sl, and MediaWiki:Summary/fi), which is where the text on the edit page comes from. --bjh21 (talk) 14:36, 5 November 2024 (UTC)

Thanks, done. Prototyperspective (talk) 14:40, 5 November 2024 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 14:40, 5 November 2024 (UTC)