There's a grand Commons file page improvements - Google Docs with many ideas.

In T332644#12194553, @gerritbot wrote:

Change #1322683 had a related patch set uploaded (by Simon04; author: Simon04):

[mediawiki/core@master] ImagePage: move TOC element below file link

https://gerrit.wikimedia.org/r/1322683

In T332644#12194522, @Samwilson wrote:

Let's revert for now, until it's clearer what to do.

In T332644#12194337, @TheDJ wrote:

are we sure ? labs seems to indicate otherwise:

Did take having a local file and doing a purge of the page to show up. I think this is an issue. It's going to cause backlash

In T332644#12181820, @Tacsipacsi wrote:

These make the image itself go out of view, which is IMO a regression. The previous #filetoc was designed to cover as little of the file as possible. Would it be possible to keep the current behavior on skins that include the table of contents in the main body (i.e. all but Vector 2022)? Or to include the table of contents below the image and just provide a skin link (similar to the current #filetoc) above it?

Upstream issue: https://github.com/simon04/locator-tool/issues/92

Or everything as one large dialog?

Yes, all skins should be supported (thanks to @Samwilson's review on gerrit).

The number FilesWithMatch is directly returned by the API. The total number of matches can easily be computed in the front-end. If you need it to be returned by the backend, feel free to open an upstream issue. Do you have a particular use-case in mind?

See also T426246.

Nice. For people looking for some example requests:

Image preloading has been removed via I8d0bb2.

We set maxage to 5min for imageinfo requests. This choice seemed to be good enough for the past 12 years.

Does no longer seem relevant. We've performed plenty of refactoring in the past.

Related: T56035 and T426246

Hi all, thank you – I feel honored. 🤗 I will use the new power wisely.

Hi @Ladsgroup, I debugged your tool a bit: You seem to be using the imageinfo...url to compute the filepath. But the newly added ?utm_source=commons.wikimedia.org&utm_campaign=imageinfo&utm_content=original seems to be causing problems and need to be removed.

The underlying analytics endpoint seems to be working nicely, for example https://wikimedia.org/api/rest_v1/metrics/video_plays/v3/per_file/all-referers/all-agents/%2Fwikipedia%2Fcommons%2Fe%2Fe1%2FForschung_zur_Hohen_Birga_an_der_Universit%C3%A4t_Innsbruck.webm/daily/20260501/20260510

In T415202#11851634, @Ladsgroup wrote:

I updated my tool to get videoplays.

I cannot reproduce anymore. Preloading has been reworked/simplified in the past time.

Awesome @Ladsgroup, thank you for your help. 🤗

Is the following a decent replacement? Is there any better way?

Happy 2026! Temporal is natively supported by Chrome 144+, Edge 144+, Firefox 139+, see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal#browser_compatibility

I wonder whether any documentation need to be updated, for instance...

@CCiufo-WMF, please update my patches as needed. My interests shifted to other projects in the meantime.

In the meanwhile, dewiki came up with this template https://de.wikipedia.org/wiki/Vorlage:Chart to link to the chart definition and chart help page ("Diagrammdaten: Definition | Hilfe").

In T392110#10854013, @aude wrote:

I left some comments in the merge request for the service:

https://gitlab.wikimedia.org/repos/mediawiki/services/chart-renderer/-/merge_requests/78

for the scatterplot, should yAxisColumns only have one column? and validate that it is a number column?

if the data is unexpected (e.g. y axis has category data or there are extra columns) then the chart could appear in unexpected ways. Maybe it's up to the user though or use lua to transform the data to the right way.

also if the xAxis has null values then the scatterplot is treated as category data since I think isValidNumberColumn does not consider or filter null values.

if the tabular data is more clean, with only 2 number columns. then the implementation works okay but maybe the service and/or extension could have more validation and handle unexpected data for the scatterplot.

Note that enwiki has implemented a similar functionality for many navigation boxes, see https://en.wikipedia.org/wiki/Innsbruck#External_links for instance and note the V T E buttons on the left.

@CCiufo-WMF, cool, I did not know that this function exists. However, the functionality is very limited:

Is anything blocking the Gerrit patch? Is any help needed to address and implement this enhancement?

Currently, two mappings are in place, (a) in PHP for i18n strings and fetxhing the .tab data, and (b) in Typescript to map our chart definion to ECharts options.

We used to have a showValues option, but this option has been removed in the course of T376656.

The deployment to metawiki is planned for May 6-8, 2025, see https://www.mediawiki.org/wiki/Extension:Chart/Project#Deployment_Timeline.

The deployment to ruwiki is planned for May 13-15, 2025, see https://www.mediawiki.org/wiki/Extension:Chart/Project#Deployment_Timeline.

We used to have a showLegend option, but this option has been removed in the course of T376656.

Related: T393597

@Jdlrobson-WMF in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Chart/+/1141452/comment/ebc6eff9_eb3d9c2a/

Hi @Jdlrobson-WMF, sorry that you couldn't come to the hackathon, I missed you. The hackathon was great. Today I started my adventure back home by bike – approx. 2500km to go.

Avoid custom tags, presumably there is nothing we can do with these

One approach could be to utilize the toolbox of ECharts (top right) and display the links to .chart and .tab there.

ECharts does not have a designated chart type for histograms. Histograms can simply be rendered as a bar chart.